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 NLMTM versions, configuration files, databases, and more. Review the following sections:


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.

The following illustrates the relationship between software packages and package components:


Server Software Packages sample tree

Note the following:


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:


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 will cause an error in any report you run on the software package.


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

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.


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.


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 enter the path and filename of the .SPK when you are prompted for the compiled filename, the .SPK will be overwritten and can no longer be edited. Be sure to use the .CPK extension when naming the compiled version.

.CPK files have 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 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 will return the server to its original state (before the package was installed). For more information, see Rolling Back Software Package Installations.


Accessing 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 What Are My Software Package Management Options?.


Running ConsoleOne from a Workstation

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

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


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:.

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


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 the package can be installed on the target Subscriber's server. If the Subscriber meets these requirements, the subscription schedule determines when the package will actually be installed.


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 will receive 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 will be 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 will see 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 will take over again.

You can use a Software Package Distribution to update files on the cluster machine itself, such as TED's .NCF files, because the Subscriber software will be contained on the cluster machine's shared hard drive.


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 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 will automatically return 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 met and some do not, the installation will be 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 will not leave disconnected or incomplete files or applications on the target machine.


Rolling Back Software Package Installations

You can 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.

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


Rollback Methods

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

  • Type  package rollback  at the server's ZfS console prompt for the server containing the package to be rolled back.
  • Use a Web browser to access ZfS and select the rollback option. For more information, see Novell iManager.

The software package will be 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 an incomplete package installation, because the installation program tracks what was and wasn't installed.


Rolling Back Previous Installations

When you roll back an installation, it will be the last software package installed on that server. If that's not the one you need to roll back, you must roll back more recent installations first.

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 would type  package rollback  at the server's ZfS console prompt once for Package3, then again for Package2.