Partner Update

Overview

Partner Update is the application and subsystem responsible for maintaining the coherency of all Partner installations.

Update follows a hierarchical model, where installations of higher authority update those of lower authority, but those of lower authority can have increasingly specific configuration that they control.

Update is responsible both for initial installation and for upgrading existing installations.

Update directly modifies the following types of files in an installation:

  • config
  • modules
  • system
  • os

Update indirectly modifies data files through the Migration subsystem.

The Partner System has always been designed as a tool for organizations, rather than single users. As such, we have tried to simplify installation maintenance as much as possible by automating the installation and installation update process.

Update uses standard web server protocols to distribute file updates. Updates flow from “source” installations, which are generally some sort of master copy, to “destination” installs. Compression and incremental update techniques are used to minimize bandwidth usage. When started, the Map Viewer application checks with its last update source to see if updates are available, and if so asks the user if they want to update.

Java Web Start

Partner Update itself runs using the operating system’s copy of Java. See Java for details.

The reason for this is that, under Microsoft Windows operating systems, Update is responsible for updating the embedded version of Java that Partner uses. Microsoft Windows is aggressive about file locking and it is impossible to remove files that are in use.

Update Hierarchy

Updates follow a hierarchical scheme, where every installation is updated from an install with the authority to overwrite some portion of the installation filesystem.

Installations “higher” in the hierarchy are more generic than those that are “lower”. Thus, each level of the hierarchy adds its own customizations, which it has sole responsibility for.

The filesystem has been specifically designed to simplify updates, and to make it clear which files are controlled by which installation. Since there is no overlap in responsibility, you can go to a any higher level install for an update. This is useful when, for example, you want to try a new version of the code without replacing your local configuration or installing the untested code on your Central Hub.

Here are the levels of the hierarchy, from most generic to most specific:

  • distribution
  • provider
  • customer
  • hub
  • site
  • seat

distribution

The software as distributed by Partner, with no user-specific configuration at all. Distribution files are located in the system/ and os/ directories.

provider

Software, configuration, and data provided by a third-party reseller. Provider files are located in config/provider and modules/provider.

customer

Software, configuration, and data provided by the customer organization. Customer files are located in config/customer/, modules/customer, and maps/.

hub

Hub is a bit of an anomaly; it’s managed at the same level as customer but is only propagated to hub-type installations. Typical configuration and modules in hub are database servers and web servers. Hub files are located in config/hub and modules/hub.

site

Software, configuration, and data provided by the district, workgroup, or other site. Site files are located in config/site and modules/site.

seat

Software, configuration, and data that is only available on a specific installation. Seat files are located in config/seat and modules/seat.

Install Types

Installation types are related to the hierarchy levels, but also reflect specific roles for an installation in the system.

  • Distribution
  • Provider
  • Master Install
  • Central Hub
  • Site Hub
  • User

More may be added in the future.

The type is defined in the file update/info/InstallType.txt.

Mechanics

This is how the installer works:

  1. user goes to source installation web page
  2. user chooses a standard or custom installation (configuring the custom with install type and path).
  3. user runs the updater from the web page
  4. the updater installs to the correct directory, doing an incremental update as described below

This is how the updater works:

  1. user starts the Map Viewer, which checks checksums and determines if an update is required,
  2. if the user says yes, update is run from the last website installed from
  3. update goes to the source web site to see what’s available
  4. update compares the install types of the source and destination (update/InstallType.txt)
  5. update determines which packages need to be propagated
  6. for each package:
  1. checksums are compared between source and destination
  2. if they differ the package (update/packages/*.boxcar.gz) file is downloaded
  3. existing directory trees in the package are deleted to ensure that cruft doesn’t accumulate
  4. the package file is unpacked
  1. final scripts (icon generation etc.) are run
  2. Map Viewer restarts

If anything goes wrong, an error message is shown to the user. Otherwise the program silently exits.

Often, running the program again will fix any problems.

You can manually run the Updater from e.g. os/windows/programs/Update.bat or from the shortcut in the Start Menu.

Using a shared hosting service

Partner uses Dreamhost, a Debian Linux-based shared web hosting provider, to host all software updates and demos. We have done our best to make scenarios such as this easy. In general, simply uploading the Partner4.4/update directory from the Map Publisher is sufficient.

For example, suppose you are a service provider that generates maps for several customers, and you want to provide them as Partner Map Viewer installs on a shared-hosting web server. Set up multiple translators, one per customer, and configure them to upload the Partner4.0 directory to different places in your shared hosting account. You could even secure it with the right configuration, so they need a password. Suppose Partner had such a service organization (we don’t, and won’t, but just suppose). The domain might be mapservice.partnersoft.com, and you might have the following installs available:

Headless(NoGui) Update using a Windows Task Schedule

(See also: [http://developer.partnersoft.com/mediawiki/index.php?title=Administration#Installing_and_Updating_Partner_in_an_Active_Directory_Domain]

Partner provides a batch file that can be scheduled via Windows Task Scheduler so updates will run during off hours and a user does not need to be logged in to the system.

‘’‘The batch file to be scheduled is [Partner installation]oswindowsterminalpartner-update.bat. <br> ‘’’ To schedule this update make sure you follow the following procedure:<br>

‘’‘Checking the Task Scheduler Service’‘’<br>

#The Task Scheduler service must be running and properly configured to run tasks. If you had stopped scheduled tasks manually from the Scheduled Tasks window, the service stops and does not initialize the next time you start the computer. If the service is not configured to log on as the local system account it may not start.

‘’‘To check the settings for the service:’‘’

#Click Start, click Control Panel, and then double-click Administrative Tools. #Click Computer Management. #Expand Services and Applications, and then click Services. #Right click the Task Scheduler service, and then click Properties. #On the General tab, make sure that the startup type is set to automatic, and that the service status is Started. If the service is not running, click Start. #On the Log On tab, make sure that the local system account is selected, and that the Allow service to interact with desktop check box has a check mark. #Click OK, and then quit Computer Management.

‘’‘To schedule a new task:’‘’ Schedule Task Manager for XP is found under Programs–>Accessories–>System Tools–>Scheduled Tasks, in Vista and Win7 and Windows Server 2008 just type Task Scheduler in the Search box, Windows Server 2003 you should be using Schtasks.exe

#Double-click Add Scheduled Task to start the Scheduled Task Wizard, and then click Next in the first dialog box.

#The next dialog box displays a list of programs that are installed on your computer, either as part of the Windows operating system, or as a result of software installation. ‘’‘Use the following procedures:’‘’ #Click Browse, maneuver to [PartnerInstallation]oswindowsterminal and select the file partner-update.bat #Type a name for the task (can be any name I usually leave it partner-update), and then choose one of the following options: ##Weekly ##Monthly ##One time only ##When my computer starts (before a user logs on) ##When I log on (only after the current user logs on) #Click Next, specify the information about the day and time to run the task, and then click Next #Note that the information about the day and time to run the task varies depending on the selection that you made in the previous wizard dialog box: For example, if you chose Weekly , you must indicate the day of the week, the time, and if the task should run every week, every 2 weeks, every 3 weeks, and so on. #Type the name and password of the user who is associated with this task. Make sure that you choose a user with sufficient permissions to run the program. By default, the wizard selects the name of the user who is currently logged on. This user must be an administrator. #Click Next, and then click Finish after you verify the choices that you have made. #Right click the task, and then click Properties. Make sure not tick “Run only if logged on”. #Please ensure you do not run other 3rd-party schedule task software.