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:
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:
Note the following:
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:
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:
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.
When you create a software package, you initially give it an .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.
If you want to include multiple software packages in one Distribution, consider the following:
Therefore, if you have software packages that must be installed in a particular order, do the following:
Once 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 .
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 more information on managing software packages from multiple workstations, see What Are My Software Package Management Options? .
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.
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:
The following scenario illustrates when a package cannot be found:
Note that the only difference between the scenarios is the drive letter mappings to Server A for each workstation.
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.
If a server fails to meet any of the software package requirements, it is not installed.
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.
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.
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.
There are two ways you can roll back a software package installation:
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.
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 later 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.