Software Distributor

Software Distributor (SD) is the Hewlett-Packard company's name for their HP-UX software package management system.

SD provides a set of tools for creating packages that will install software on a system running the HP-UX operating system. The packages can be grouped together into a software repository called a depot, and a server can be configured to host multiple depots for installation of software packages and even entire systems.

SD was first available with release 10.0 of HP-UX in 1995. Since then it has undergone several enhancements and bug fixes, and now provides a reliable software installation tool. It uses a client-server arrangement to distribute software using a background daemon called swagentd. A software distributor provides its customers with the ability to purchase software licenses from multiple sources. This agent is started at boot time, and communicates using either the TCP or UDP protocols through RPC. The SD packages are normally stored and transmitted in compressed form, using either the gzip or compress programs.

Commands

The tools for performing SD operations are normally accessed from the command line. SD includes the following commands:

• swacl — access to the software products or depots can be controlled at a fine-level by means of an Access Control List. This list can be managed by the swacl command.
• swask — run interactive software request scripts and store the responses for later use by the swinstall and swconfig files.
• swconfig — configure or unconfigure an installed software package.
• swcopy — copy software packages to a depot.
• swinstall — install one or more software products on a local or remote system. This will cause a system reboot when the installed packages are marked as requiring a system restart.
• swjob — create and monitor SD batch jobs.
• swlist — list installed software products on a system or the contents of a depot. A considerable number of package parameters can be displayed by using the correct arguments to this command.
• swmodify — modify the particulars of a software package installed on a system or loaded into a depot.
• swpackage — a specification file is passed to this command, directing it about how a software package should be built. The resulting package can then be added to a depot or onto media for shipment.
• swreg — register or unregister a depot. Only registered depots will be shown using a depot-level swlist of a remote server.
• swremove — remove a software package from a system or depot. This will cause a system reboot when the removed packages are marked as requiring a system restart.
• swverify — test an installed software product to determine if the install state is what was expected.

These commands include a broad range of command-line options that allow relatively fine control of the task being performed. In addition to command-line programs, several of these tools can also launch GUI versions in an X Window System display. The GUI version of swinstall performs some filtering of the software list to match software packages with the system where it is being run.

The commands log messages to an administrative area, which can be useful for diagnosing installation issues or just tracking what software is loaded or removed.

Packaging

Software packages are built by means of a specification file, a set of install scripts, and the actual software content. The install scripts are executed during software installation, verification, and removal, and can be used to prepare a system for the software and to perform activation or deactivation of the package. The specification file determines how the software package will be organized, list the locations of the various files to be loaded into the package, restrict the systems on which the package can be installed, and determine the security configuration of the package. It also provides various information about the package, such as a name, version, and description.

Software packages are organized in a hierarchy of containers, with the highest level being a bundle or product and the lowest being the filesets and then files. The hierarchy is arranged as follows:

• Bundle
  • Product(s)
    • Subproduct(s)
      • Fileset(s)
        • Files

Only the Product and Fileset levels are actually needed for many packages. The Subproduct level is sometimes used to group together Filesets, while the Bundle provides a higher-level grouping for related products. There can be one or more filesets in a Product, and one or more products in a Bundle. The Fileset level is used specifically for loading the files. A product can be installed without all of its associated filesets, etc.

The filesets and products can be linked together by various requirement tags, which cause swinstall to select the appropriate dependencies automatically.

Each fileset can have multiple control scripts specific to the files it will load. These scripts are executed in the following order during an installation:

• checkinstall — run during a pre-install analysis phase to check if the fileset can be loaded on the system.
• preinstall — run just prior to loading the files in the fileset.
• postinstall — run immediately following the file load, and before a reboot, if any.
• configure — run after postinstall script and after a reboot, if any, to perform final configuration of the installed package.

There is a corresponding set of scripts that are executed in the reverse order during a swremove:

• checkremove
• unconfigure
• preremove
• postremove

Other scripts include verify for performing a sanity check with the swverify command, unpreinstall, and unpostinstall. All, some, or none of these scripts can be included in the package, depending on the requirements of the installation. They are useful for performing cleanup of previous packages, creating links, adding the software directory to various search environment variables, and so forth.

See also

• Installation
• Installer/Uninstaller