How to Update Applications, ZENworks Application Objects, and snAppShots Residing on Multiple Servers: Part 1
Articles and Tips: article
Directory Engineer
Phoenix Home Life
Michael_LeeE@phl.com
01 Aug 2000
This series demonstrates the ability to transfer new or updated ZENworks Application objects to other servers. Part 1 discusses snAppShots, copying an application, software replication system design and goals, and development tools.
SnAppShots
To build a ZENworks Application object, you can use the internal process called snAppShot. Running on a Windows PC, this process captures the changes an installation procedure makes to the PC. These changes may be new or updated files on a local hard drive, as well as new or updated entries in the Windows Registry. The end-result of the snAppShot process is a ZENworks Application object in the NDS tree and a series of Application Files stored in a directory on a NetWare server.
The Application Files are copies of the files that snAppShot determined were added or modified on the PC during the install process. They are named using the 8.3 naming convention of #.FIL, replacing the # with a number starting with 1. The first of these files is named 1.FIL, the second file is 2.FIL, with the remainder being numbered sequentially.
The ZENworks Application object created from the snAppShot process stores both the list of these files and the corresponding actual name of the file stored on the Windows PC. This gives the Application object the information it needs to properly create directories and copy the files with the correct name.
An NDS user will not be able to launch or install a ZENworks application until the Application object is associated with either the user object, a group object of which the user is a member, or an NDS container from which the association will flow down to the user or group object.
Multiple ZENworks application objects can be what is called "GUID synchronized." A GUID, or Global Unique Identifier, is a number used to create a unique identity for an entity, such as an application. When ZENworks Application objects are created, they are given a unique internal GUID number. Objects that are GUID synchronized are each given the same internal GUID number. When applications are installed on a PC, these internal numbers are stored within the Windows registry. When an application is launched, ZENworks searches in the registry for the application's GUID number. If the GUID number is not found, ZENworks installs the application onto the PC. This is important because applications may come packaged together with other applications, but you may want them to be installed on a PC as one application.
A perfect example of this is an "office suite" software package, for which you would probably want the word processor, spreadsheet, and other applications in the suite to be installed together on a PC. You would also want the user to see separate icons for each individual application. Not having the office applications GUID synchronized would cause undesirable behavior. For instance, when any individual application (such as word processing) is launched for the first time, the whole office package will install before launching the individual application. On the launch of another office application, the whole office package will be installed again although it has already been installed.
The desired behavior occurs when the office application objects are GUID synchronized. When any of these applications is launched on a PC, the GUID number will be found within the registry (if the application has been installed) and the application will be launched without reinstalling the whole office package.
Copying an Application
There are times when you may want or need duplicates of the same ZENworks Application object. For example:
When you have multiple NDS trees
To keep an Application object close to the User objects within the tree
To have users' Application objects point to users' local servers (this can allow ZENworks installs to copy files from the local server so the files will not have to travel across the WAN)
Rather than running the SnAppShot process to create each Application object needed, you can create new objects from the initial SnAppShot object. One method of recreating Application objects is by using Novell's NAL Toolkit utilities which can be found at:
http://www.novell.com/coolsolutions/ZENworks/downloadables.html
The APPXPORT program will create an AOT file from an Application object. (We do not use the AOT created during the snAppShot process because the Application object may be changed during our testing phase). The APPCREAT program can then be used to create an Application object from this AOT file. Once the ZENworks Application object is created, the NetWare Administrator (NWAdmin) utility can be used to check the Application object.
Because an AOT file cannot be viewed, the AOTXPORT program can be used to convert an AOT file to an AXT file. An AXT file is a file that stores the ZENworks Application object's information in a text file. The APPASSOC program can be used to associate the object and the GUIDSYNC program can be used to GUID synchronize the new objects.
Along with creating a new ZENworks Application object, you must copy the Application Files to the location on the server that the %SOURCE_PATH% variable points to. This variable can be found in the ZENworks Application's details by clicking on the Macros button. If drive mappings to a NetWare volume are used, copy the Application Files to the drive mapping's server's volume. For example, if the initial ZENworks Application object points its Application Files to the Q:\APP.1 directory, the new ZENworks Application object created will also attempt to get its files from the Q:\APP1 directory. So be sure to copy the Application Files to the correct server's volume/directory.
Software Replication System Design and Goals
Phoenix Home Life needed a method to replicate applications and snAppShots of software (both developed in-house and/or purchased), along with their newly created or updated ZENworks Application objects, to over eighty field offices across the WAN. Field offices are connected to the home office by 64kbps Frame Relay links. The updated software would be distributed from the home office. Since no application existed to handle this, an in-house application was written to accomplish this.
Our servers were configured to have four volumes:
|
SYS: |
2GB (standard NetWare operating system) |
|
APPL: |
2GB (application programs stored on the server) |
|
DIST: |
3GB (programs distributed to desktop, mostly snAppShots) |
|
DATA: |
5GB (data and users' home directories) |
Each office's container was created looking similar to that shown in Figure 1.
Figure 1: Typical office container.
The goals of the software replication system became:
To optimize the limited bandwidth to the field offices
To create and move new ZENworks application objects into the correct container after software updates are correctly applied
To update log files back in the home office
To include a rollback feature in case of a problem with an update; this entails moving all files back, removing new files and directories, and moving old ZENworks application objects back
To make the system easy to use for persons in charge of distributing the software
To make the system flexible enough to work with applications that install to multiple volumes, have data reside in the same directory as the programs, update ASCII files, unload or load NLMs, or do other manipulations
To be able to date the rollout so all field servers can be updated on the same date
Because of my familiarity with Perl, I decided to write the software replication system in Perl. Perl runs on NetWare servers and on PCs and is very good at parsing and manipulating data. A staging server was created with the same volumes as the field office servers, along with four additional volumes:
|
RSYS: |
2GB (reference SYS: volume) |
|
RAPPL: |
2GB (reference APPL: volume) |
|
RDIST: |
3GB (reference DIST: volume) |
|
RDATA: |
5GB (reference DATA: volume) |
The directories and programs on these "reference" volumes are configured to be exactly the same as the field servers' volumes. (The purpose of these volumes will be explained shortly.)
The logic of the "Software Replication System" goes like this:
Each application update, or ZENworks SnAppShot, will update the staging server's regular volumes: SYS:, APPL:, DIST:, DATA:. The initial ZENworks Application object is created at this point. Any additional changes that need to be made to the object are made at this point.
The "Step 1" process compares the directories and files (which may exist on multiple volumes) where the program resides to the staging server's corresponding reference volumes. The Step 1 process finds all directories and files changed during the installation/update process. At this point, AOT files are automatically created from the Application objects created during the SnAppShot process.
During the "Step 2" process, a package which consists of a control file, a zip file, and (if needed) a ZENworks Application object, is created. The control file documents all the changes that should occur on a server. The zip file consists of all the files that were determined to be added or modified during the Step 1 process. During Step 2, when a server or office is determined to get this package, a control file and the zip file are created and scheduled to be sent to the server. Once the zip file is created, it may be reused for other servers. The ZENworks Application object is also created at this time but is placed in a holding container.
On the staging server, the sending process automatically starts at 5:00 p.m. and runs until 6:00 a.m. daily. On a Saturday or Sunday, the sending process will continue all weekend, if needed. This Sendoff process copies (via FTP) the package to a predetermined holding area on the server.
At 4:00 a.m. on each field server, the Replicat process starts looking for any packages to apply to the server on this date. If a package is to be applied, the zip files are unzipped and the control file tells the server which files to distribute to the appropriate volume/directory. The control file also tells the Replicat process whether to create or delete directories. After all modifications have been made without error, the ZENworks Application objects are moved to the correct containers for that office.
This process meets all the goals stated earlier:
Only the small control file and the compressed, zipped files, which contain only the added or modified files, are FTPed to each field office optimizing the bandwidth utilization. During the Sendoff process, these files are being sent concurrently to up to twenty servers at a time.
The Replicat process unzips the files and moves them to their correct location. If errors occur, the script automatically rolls any updates back.
On the staging server, logs are updated during each Replicat process so they can be easily checked the next morning. They are also updated during the Step 1 and Step 2 processes.
Modified or deleted files, along with the control file, are not deleted but are actually moved to a saved area. Application objects are also moved to a saved container. If the Rollback process is run, files and Application objects are all moved back to their original locations. These saved files are purged after 31 days.
The configuration files are created by a technical person familiar with the process. For each application there is a configuration file that tells the Step 1 and Step 2 processes the volumes and directories in which the application's files reside, the names of the ZENworks Application objects and where they reside in the tree, the associations that are made with the Application objects, and the objects which will be GUID synchronized. The person whose job is to roll out these packages needs to know only the name of the application, the name of the office receiving the package, the rollout date (or use the default of "tomorrow"), and the number of the package.
The process easily handles updates on more than one volume. Added or modified files are renamed to an 8.3 naming convention before being stored into the zipped file for that volume. (This is done because PKZIP version 2.04g does not store long file names.) These files are moved and renamed to their correct name during the Replicat process on the field server. This information is stored within the control file. Because these files are being moved, not copied, to their correct location, the original file modification dates and times are preserved. During the Replicat process an additional Perl script is executed in case any special logic needs to be applied to the server, such as NLMs needing to be unloaded and reloaded for RCONSOLE password changes. The whole process will work for updates that involve ZENworks applications, and also for updates that do not include ZENworks applications.
Development Tools
Various development tools were used to put this whole process together. The PC can be running any version of Windows. Tools on the PC side include
Perl
Perl Tk modules (to allow a GUI interface from Perl)
NDSm Perl modules (to allow NDS calls from Perl)
ZENworks Toolkit
PKZIP
On the server side, the tools include:
Novell Perl
NDSm Perl modules (to allow NDS calls from Perl)
FTP Perl module (to allow FTP transfer during the Sendoff process)
UNZIP.NLM
CRON.NLM
Part 2 of this series discusses the software replication system process, Sendoff, Replicat, Syncup, Resetsnd, and logic pieces.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.