5.2 Understanding Server Software Packages

Policy and Distribution Services provides the means to automate and standardize the distribution and installation of server files and applications. This includes your ability to standardize NLM™ versions, configuration files, databases, and more. Review the following sections:

5.2.1 Understanding Server Software Packages and Components

To distribute server files and applications for installation on a server, you must include the software in a software package. You create the software packages under the Server Software Packages namespace in ConsoleOne®. Creating software packages is like building a software installation executable.

Figure 5-1 illustrates the relationship between software packages and package components:

Figure 5-1 Server Software Packages Sample Tree

Note the following:

  • Software Package objects are displayed under the Server Software Packages namespace

  • A Software Package object can contain multiple Component objects

  • Component objects can contain files and directories

  • Each software package can include all of the files for one or several applications

  • Software Package configuration files (.spk and .cpk) are stored on a server or workstation file system

5.2.2 Understanding Software Package and Component Configurations

Software packages and their components contain configuration information and installation requirements. Because each Component object is governed by its own set of configuration parameters and installation requirements, you might have multiple components for a software package, such as pre-installation actions, installation actions, and post-installation actions.

You can configure every aspect of the distribution and installation of server files and applications, including the following:

  • Requiring a specific operating system

  • Specifying how much RAM the target server needs

  • Specifying how much disk space the target server needs

  • Requiring certain SET commands on the target server

  • Making changes to the target server’s registry

  • Replacing files on the target server

  • Requiring specific products.dat entries

Requiring Software Package Installation Prerequisites

Not only can a software package have installation prerequisites, but each of its components can also have its own installation prerequisites. The hierarchy for adhering to prerequisites to determine installation eligibility is:

  • If the prerequisites for the package are not met, none of the components are installed.

  • If the prerequisites for the package are met, the components are eligible to be installed.

  • If the prerequisites for a component are not met, that component is not installed.

Because some components can be installed while others are not, a partial installation of the software package is possible.

IMPORTANT:When you specify prerequisites, be sure to create prerequisites at the software package level that would apply equally to all of its components, and create prerequisites at the component level that are specific to that component.

Naming Software Packages

When you create a software package, you initially give it a .spk extension, which represents a software package that has not yet been compiled. This file contains all of the installation requirements for the software package and all of its components.

WARNING:Do not use double-byte characters in the software package name. This causes an error in any report you run on the software package.

5.2.3 Determining the Installation Order of Software Packages

There are two issues concerning the ordering of Server Software Packages in Distributions:

Forcing the Software Package Distribution Order Using Multiple Distributions

If you want to include multiple software packages in one Distribution, consider the following:

  • Multiple software packages are not gathered into a Distribution in any particular order when the Distribution is built

  • Multiple software packages are not applied to a server in any guaranteed order when the Distribution is extracted and installed

  • Multiple software packages that are contained in one Distribution and start their installations in a certain order might not all finish in that same order

To install software packages in a particular order:

  1. Place each software package in its own Distribution (one software package per Distribution).

  2. Control the order of software package installations by scheduling the order when the Distributions are sent and extracted.

Forcing the Software Package Distribution Order Using Dependencies

Another way to ensure software package installation order is to use dependencies with multiple Software Package Distributions, such as placing a dependency in a subsequent software package that is established in previous software package.

For example:

  1. Create Software Package Distribution 1.

  2. Create Software Package Distribution 2 with a dependency on something that is installed from Software Package Distribution 1.

  3. Send both Distributions.

  4. If the Subscriber attempts to extract Software Package Distribution 2 first, it will fail.

  5. The Subscriber extracts Software Package Distribution 1, which provides the dependency on the Subscriber required by Software Package Distribution 2.

  6. The Subscriber can now successfully extract Software Package Distribution 2.

With this scenario, you do not need to use schedules to control the installation order.

How Rollback Is Affected by Software Package Ordering

Rollback is also affected by the fact that multiple software packages contained in one Distribution won’t necessarily finish extracting in the same order that they started.

Although you can specify the order for processing software packages that are contained in a Distribution, this order is not guaranteed. This is because the length of time it takes for software packages to finish processing can be different for each package, and it is the finishing time for a software package that determines its rollback order.

In other words, you can only roll back the last software package that was successfully processed, and then other software packages only in the reverse order of when they finished processing.

You can use the Package List command to view the order in which software packages finished processing. An asterisk marks the next package that is available for rollback.

For more information on rollback, see Section 5.2.11, Rolling Back Software Package Installations.

5.2.4 Executing Extracted Files

In a Software Package Distribution, some of the files that the software package copies to a server might be executables that you want to have execute in conjunction with extracting the Software Package Distribution.

To run executable files that are delivered through a software package, configure the pre or post execution actions, including order of execution, of the files in the software package. Pre and post actions are available when creating the Server Software Package and when creating the Software Package Distribution.

For more information, see Section 3.4.6, Pre and Post Processing for Distributions, and Configuring the Software Package Components.

5.2.5 Compiling Software Packages

After you have defined your software packages, including configuring the components, you must compile the software package. This process compresses the files and applications and their configurations into one file for distribution.

The default extension for a compiled software package is .cpk. The compiled version contains all of the files necessary to install the files and applications that the software package represents.

IMPORTANT:If you provide the path and filename of the .spk when you are prompted for the compiled filename, the .spk is overwritten and can no longer be edited. Be sure to use the .cpk extension when naming the compiled version.

A .cpk file has the potential to be very large (hundreds of megabytes), because software packages can include many large files to be copied. Therefore, .cpk files should generally be stored on a server where you have sufficient free disk space.

However, software packages can perform simple functions, which would make the .cpk files’ sizes relatively small, so that you could store them on a workstation. For example, a software package could be configured to just delete directories on a file server (see Section 5.5, Using Server Software Packages to Delete Directories on Servers).

When a rollback-enabled software package is successfully installed, a rollback package is created on the server. Processing this rollback package returns the server to its original state (before the package was installed). For more information, see Section 5.2.11, Rolling Back Software Package Installations.

5.2.6 Accessing Software Packages

Where you save software packages (on workstations or on servers) depends on how you want to manage the software packages.

Because the Server Software Packages component uses a namespace in ConsoleOne, it enables you to have access to software packages from any workstation or server where you are running ConsoleOne.

However, you should be aware of the following issues:

For information on managing software packages from multiple workstations, see Section 5.2.9, Managing Server Software Packages.

Running ConsoleOne from a Workstation

If you run ConsoleOne from a workstation and save a software package to that workstation, the package is not available in ConsoleOne to other workstations or servers running ConsoleOne.

Running ConsoleOne from a Server

You must have the same drive mapping to a server on different workstations if you run ConsoleOne from the server at those workstations. Otherwise, any software package you save to that server cannot be read at the different workstations.

For example, the following scenario illustrates when a package can be found:

  1. You run ConsoleOne from Workstation A to access Server A.

  2. Server A is mapped as drive S: for Workstation A.

  3. You save pkg_a.spk to Server A.

  4. You run ConsoleOne from Workstation B to access Server A.

  5. Server A is also mapped as drive S: for Workstation B.

  6. Pkg_a.spk can be found because both workstations were mapped to drive S:.

The following scenario illustrates when a package cannot be found:

  1. You run ConsoleOne from Workstation A to access Server A.

  2. Server A is mapped as drive S: for Workstation A.

  3. You save pkg_a.spk to Server A.

  4. You run ConsoleOne from Workstation B to access Server A.

  5. Server A is mapped as drive T: for Workstation B.

  6. Pkg_a.spk cannot be found because you are looking for the package on drive T: when it was previously saved to drive S:.

The only difference between the scenarios is the drive letter mappings to Server A for each workstation.

5.2.7 Distributing Software Packages

Distributions can include software packages, which are installed, or file groupings, which are extracted.

The Policy/Package Agent extracts or installs Software Package Distributions on the Subscriber server.

When software packages are created, they can contain system requirements that must be met before you install the package on the target Subscriber’s server. If the Subscriber meets these requirements, the subscription schedule determines when the package is actually installed.

5.2.8 Distributing Software Packages to a Cluster

When you send a Distribution containing software packages to a cluster to update the sys: volume for each node, the only node in the cluster that receives it is the one that currently has the Subscriber software running.

Because the machines comprising the nodes in the cluster run the Subscriber software, only one node at a time in a cluster is actively running the Subscriber software.

Therefore, if you want to use a Software Package Distribution to update files on a sys: volume for each node in a cluster, you must do this manually by updating one node, bringing it down so that the next node in the failover sequence sees that the previous node has failed and start running the Subscriber software, then update that machine, bring it down, and so on, until all of the machines in the cluster have been updated. Then restart all of the downed servers in the cluster and the primary node’s machine takes over again.

You can use a Software Package Distribution to update files on the cluster machine itself, such as Tiered Electronic Distribution .ncf files, because the Subscriber software is contained on the cluster machine’s shared hard drive.

5.2.9 Managing Server Software Packages

The following sections explain where to store Server Software Package files, and how to manage them:

Understanding Server Software Package Files

There are three file types associated with software packages:

  • Configuration file (.spk): When you create a Server Software Package, you initially create a configuration file (.spk) for it. This file’s configuration is created in the properties of the software package object in the Server Software Packages namespace in ConsoleOne.

    A .spk file is generally small (around 100 KB). Therefore, it can generally be stored on the workstation running the instance of ConsoleOne that you are using to create and manage software packages.

  • Compiled file (.cpk): When you compile a software package, a .cpk file is created from the .spk file’s configuration information. This provides the content of the software package, such as files or functions. The .cpk file is used to install the software package’s content on a server.

    You should generally store .cpk files on a server where there is sufficient free disk space, because compiled software packages might contain many files. However, you can store small .cpk files that only contain functions on a workstation.

  • Preferences file (.ser): The preferences file (snapinprefs.ser) is automatically created on the workstation being used to create a software package. It contains pointers to the .spk files for the software packages.

    This preferences file allows you to see the software packages in the namespace in ConsoleOne. In other words, software packages are displayed in the Server Software Packages namespace for an instance of ConsoleOne only if the .spk file’s path is listed in the preferences file located on the workstation running that instance of ConsoleOne.

When you create a new software package, you specify the local path for the .spk file. When you compile a software package, you specify the server’s path for the .cpk file. After you exit ConsoleOne, any time you have created, deleted, or compiled a software package, the .spk file paths are logged to the snapinprefs.ser file.

The path to the .cpk file is also logged to the snapinprefs.ser file. The next time you compile the software package, the wizard displays the .cpk file’s previous location so that you do not need to remember it each time you compile the package. However, you need to note where you store the .cpk files for when you want to distribute them using Tiered Electronic Distribution, because the .cpk files’ locations are not stored in the software package’s properties.

Understanding Your Software Package Management Options

If you are using only one specific workstation for viewing, creating, and managing all of your software package files, then you can store the .spk files on that workstation.

It is also possible to manage your software packages from multiple workstations. This requires that you centralize your .spk file storage to a network server. This method also requires the use of a master snapinprefs.ser file so that you can view all of your software packages from any workstation.

The next two sections explain these management options.

Storing and Managing .Spk Files Using One Workstation

If you use only one workstation for viewing, creating, and managing your software packages, you can store the .spk files on the workstation and the .cpk files on a server.

Whether you are running ConsoleOne from the workstation where it is installed or from a workstation that uses an installation of ConsoleOne on a network server, the snapinprefs.ser file is updated on the workstation being used to run ConsoleOne.

Storing .Spk Files on a Network Server and Managing Them from Multiple Workstations

If you want to use multiple workstations for viewing, creating, and managing the same set of software packages, you need to store all .spk files on a network server so that they can be accessed by each workstation.

You might also want to use different workstations for managing different sets of software packages. Any workstation used to create .spk files has a software package preferences file of its own created on the workstation used to manage the software packages.

You can manage all of your software packages from multiple workstations if you use a master copy method for the snapinprefs.ser file.

Understanding the Software Package Preferences File

When you create a Server Software Package object in ConsoleOne, a software package preferences file (snapinprefs.ser) is created in the following location on the workstation running ConsoleOne:

c:\documents and settings\user_ID\.consoleone (Windows 2000)

where user_ID is the user directory associated with how you are logged in, such as Administrator.

The full path and filename for a software package is drive-dependent. The snapinprefs.ser file contains the drive letter, path, and package name for each .spk created by the workstation.

The snapinprefs.ser file is unique for each workstation. It is the preferences file that is updated whenever you add or remove .spk files using that workstation. Therefore, if you use three different workstations to create .spk files, you have three different snapinprefs.ser files, each on its own workstation.

When you start ConsoleOne, it checks to see if a snapinprefs.ser file was created for that workstation by the instance of ConsoleOne being run on the workstation, and whether ConsoleOne is installed on that workstation or is being run on that workstation from an instance installed on a server. If the file does not exist, a snapinprefs.ser file is created when you exit ConsoleOne. If it exists, the snapinprefs.ser file is updated with the full paths to any new .spk files.

You can copy a snapinprefs.ser file from one workstation to another. However, after replacing a snapinprefs.ser file with a copy from another workstation, you need to restart ConsoleOne to see any change.

A software package can become unusable if you change drive mappings after creating the package, because the snapinprefs.ser file’s location to the package is then different. However, if you use a UNC path, this is not an issue as long as the workstation has access to that UNC path.

If you replace the snapinprefs.ser file on a workstation, you need to manually insert any software packages missing from the newly copied snapinprefs.ser file. Otherwise, the software packages listed in the snapinprefs.ser file that was replaced would be inaccessible on the workstation.

Even if a workstation has never been used to create a software package, you can copy a snapinprefs.ser file from another workstation to the appropriate location (c:\....\.consoleone). Then, when you start ConsoleOne, you can see all of the software packages that are listed in the snapinprefs.ser file that you copied.

For more information, see Example: Using a Master Snapinprefs.ser File.

Managing Software Packages from Multiple Workstations

If you are using multiple workstations for creating, deleting, and compiling the same set of software package files, you should do the following:

  1. Store the .spk files on one network server (usually the server where you are storing their corresponding .cpk files), so that the software packages can all be accessed from any workstation.

  2. When mapping a workstation to the server where the .spk and .cpk files are stored, use the same drive letter for all workstations.

  3. Create a master snapinprefs.ser file to use for keeping all workstations updated with their latest software package additions, deletions, and compilations (see Setting Up the Master Snapinprefs.ser File).

  4. Create a batch file for starting and stopping ConsoleOne on a workstation (see Creating and Using the ConsoleOne Batch File). This batch file does two things:

    • Automatically upload the latest snapinprefs.ser file from the storage server to the workstation any time ConsoleOne is started on that workstation.

      This allows you to see all software packages from the workstation where you started ConsoleOne.

    • Automatically download the revised snapinprefs.ser file from the workstation to the storage server when ConsoleOne is exited on that workstation.

      This creates a new master copy of the .ser file containing the workstation’s latest software package additions.

  5. Run the batch file from any workstation where you want to manage software packages (see Using the ConsoleOne Batch File).

General Rules for Managing Software Packages from Multiple Workstations

Using a master copy for the snapinprefs.ser file works only if you exit ConsoleOne on one workstation, then start it on another workstation. This sequential method does not work for concurrently running instances of ConsoleOne where each instance is updating its local snapinprefs.ser file. The instance of ConsoleOne that is exited last overwrites the master copy with its local .ser file.

IMPORTANT:Creating, deleting, or compiling software packages in ConsoleOne are the only functions that cause logging to the snapinprefs.ser file. Therefore, you can use ConsoleOne to manage software packages, such as viewing and editing properties, without starting ConsoleOne from the batch file. Just make sure that you do not add, delete, or compile any .spk files in ConsoleOne if you do not start ConsoleOne with the batch file.

To manage software packages using this master copy/single server/multiple workstation method, observe the following general rules:

  • Always exit ConsoleOne after creating a new software package (.spk file) or compiling a new package (.cpk file). This causes the master snapinprefs.ser file to contain the newest software package links.

  • Never have two or more workstations concurrently managing software packages. The batch file used to start ConsoleOne on these workstations could cause paths to any newly created software packages to be lost.

  • Never use the batch file to start ConsoleOne when you do not intend to manage software packages. Instead, start ConsoleOne without using the batch file.

    You need to do this because the batch file always overwrites the master copy on the software package storage server when ConsoleOne is exited (if ConsoleOne was started by the batch file). You could inadvertently overwrite the master snapinprefs.ser file and lose links to newly created software packages.

    For example, on Workstation_A you run the batch file to start ConsoleOne, do administrative work other than software packages, for some reason go to Workstation_B where you decide to create a new software package (so you use the batch file again), exit ConsoleOne on Workstation_B, then later exit ConsoleOne on Workstation_A. Your new software packages created on Workstation_B no longer have links to them in the master snapinprefs.ser file.

The Best Scenario for Using Multiple Workstations to Manage Software Packages

The best scenario is that you have one administrator who can use multiple workstations to manage your software packages. If you have multiple administrators, they need to coordinate so that they don’t overwrite each other’s latest software package additions and deletions in the master snapinprefs.ser file.

For more information, see Example: Using a Master Snapinprefs.ser File.

Example: Using a Master Snapinprefs.ser File

Keeping the master copy on the server properly updated is a matter of timing. For example, in the following scenario, the first snapinprefs.ser file was initially created on Workstation A, then copied to the network server to be the master snapinprefs.ser file. Both workstations are using Windows 2000.

A batch file is used to start ConsoleOne for the purpose of controlling events before and after using ConsoleOne. For example:

  1. Administrator A starts the batch file on Workstation A to begin ConsoleOne.

  2. The batch file running on Workstation A identifies the storage server as being mapped to drive M: (or it maps drive M: to that server).

  3. The batch file copies the master snapinprefs.ser file from the server at drive M: to the c:\documents and settings\user_ID\.consoleone directory on Workstation A.

  4. Administrator A creates a new software package, naming it ssp1.spk.

  5. Administrator B starts the batch file on Workstation B to begin ConsoleOne.

  6. The batch file running on Workstation B identifies the storage server as being mapped to drive M: (or it maps drive M: to that server).

  7. The batch file copies the master snapinprefs.ser file from the server at drive M: to the c:\documents and settings\user_ID\.consoleone directory on Workstation B.

    This is the same version of snapinprefs.ser that Administrator A had copied to Workstation A, except that it hasn’t been updated yet with Administrator A’s addition of ssp1.spk.

  8. Administrator B creates a new software package, naming it ssp2.spk.

  9. Administrator B exits ConsoleOne, which updates snapinprefs.ser on Workstation B with the ssp2.spk path.

  10. The batch file running on Workstation B updates the master snapinprefs.ser file on the network server at drive M: with the updated snapinprefs.ser file from Workstation B.

    This updated master snapinprefs.ser file now contains the location of ssp2.spk.

  11. Administrator A exits ConsoleOne, which updates snapinprefs.ser on Workstation A with the ssp1.spk path.

  12. The batch file running on Workstation A updates the master snapinprefs.ser file on the network server at drive M: with the updated snapinprefs.ser file from Workstation A.

    This updated master snapinprefs.ser file now contains the location of ssp1.spk. However, the location for ssp2.spk has been lost, because Workstation B’s update of the master snapinprefs.ser file was overwritten by Workstation A’s later update.

This scenario would cause Administrator B to lose access to ssp2.spk, because the master snapinprefs.ser file no longer contains a record of ssp2.spk’s location. It was replaced with Administrator A’s snapinprefs.ser file containing only ssp1.spk’s location. However, you can manually insert ssp2.spk into ConsoleOne (using the Insert Software Package option), so that it is listed in the snapinprefs.ser file along with ssp1.spk.

For this multiple-workstation management method to work, you must ensure that the master snapinprefs.ser file you keep on the network server is only used by one workstation at a time for creating, deleting, or compiling .spk files. However, you can use multiple workstations to simultaneously view or edit a Server Software Package object’s properties, because the viewing and editing functions do not cause updates to a snapinprefs.ser file.

WARNING:You can perform edits to the properties of the Server Software Package object without affecting the snapinprefs.ser file. However, because Server Software Package objects are not in eDirectory™, but only in a name space, the .spk files might not have file-locking protection, unless the server’s operating system provides this functionality. Therefore, you should devise management controls to protect against overwriting .spk files when using multiple workstations to manage software packages.

5.2.10 Failure of Software Package Installations

If a server fails to meet any of the software package requirements, it is not installed:

Failure During an Installation

The system tracks all changes made by the installation of a software package. Except as noted under Section 5.2.11, Rolling Back Software Package Installations, if a server meets the requirements and the installation begins, then a failure condition halts the installation prematurely, the installation program automatically returns the server to the state it was in before the installation began, undoing what had been done to that point.

Failure of a Component

If a server meets the software package requirements, and some of the components meet the installation requirements and some do not, the installation is completed except for the components where the requirements were not met. In this case, you would have a partial installation of the package.

You should organize your software packages and their components so that if this happens, it does not leave disconnected or incomplete files or applications on the target machine.

5.2.11 Rolling Back Software Package Installations

Software package rollback is enabled by default. You should not disable rollback, unless you know the installation never needs to be undone.

Rollback Methods

There are two ways you can roll back a software package installation:

  • On the server containing the package to be rolled back, enter package rollback at the server’s ZENworks Server Management console prompt.

  • Use a Web browser to access the ZENworks Server Management role and select the rollback option. For more information, see Section 2.0, Novell iManager.

The software package is uninstalled, leaving the server as if it had never been installed, except for any changes that might have been made to the server in using the installed application.

Rollback works, even if some components have not been installed during a successful package installation, because the installation program tracks what was and wasn’t installed by the software package.

Rollback of Older Installations

When you roll back a software package installation, it is the last software package installed on that server. If that’s not the one you need to roll back, you must roll back each installation, beginning with the more recent installations first, until you have rolled back the desired package.

For example, you installed three software packages on a server (Package1, Package2, and Package3). Package1 was installed first and Package3 was installed last. If you want to roll back Package2, you must first roll back Package3. To do so, you need to enter package rollback at the server’s ZENworks Server Management console prompt once for Package3, then again for Package2.

Rollback Exceptions

You can normally undo a successful software package installation by rolling it back. However, any software package installation that runs a program such as a NetBasic script, a Java Class, or an NLM that modifies the server cannot be rolled back successfully, because those programs or services might have launched other programs that made changes on the server, which cannot be tracked for rolling back.