SD-UX Concepts

Understanding SD-UX concepts, terms, and model of software management will help you use the commands and programs most effectively. For additional definitions, see the Glossary.

Important Terminology

Host refers to any system on which software is to be installed or managed using the SD-UX commands. A local host is the system on which you invoke SD-UX commands.

When you have enabled remote operations, you can use SD-UX to operate on one or more remote hosts—a host other than the system on which the SD-UX command has been invoked. (See Chapter 7: “Remote Operations Overview” for more information on remote operations.)

A controller is the SD-UX program or command (swinstall, swcopy, etc.) that you invoke on your system. The controller may work with data or start processes on other systems.

A depot is a repository of software products that can be managed by SD-UX. A depot consists of either a (specially formatted) directory, or physical media such as tapes, CD-ROMs or DVDs. (CD-ROM and DVD depots are really just special instances of directory depots). Directory depots are useful because you can access them via a network. They are often used to store collections of software copied from other depots.

In general, the term target refers to either a host (specifically, the host’s file system) or a depot that resides on a host. The term source refers to a depot from which software is being installed or copied (sometimes referred to as a source depot).

For example, a basic install operation with the swinstall command involves installing software from a source depot to a target location on the host itself. The source depot might be physical media accessible from the target, or a directory depot on some server on the network. The target host might be the same host on which the command was invoked (i.e., the local host) or, if remote operation is enabled, some other host on the network.

A basic copy operation (using the swcopy command) is very similar, except that the target is a depot on the host, rather than the host itself.

For most operations, controller programs access hosts and depots using an agent called swagent, which performs the basic software management tasks. The agent is accessed via a daemon called swagentd. When SD-UX operates on the local host, both controller and agent run on the local host. For remote operations, the agent runs on a remote host.

Figure 1-1: “SD-UX Systems”, shows how software can be developed and then packaged into SD-formatted media, which can either be accessed directly or copied to a depot directory on a server and accessed via the network.

Figure 1-1 SD-UX Systems

Software Structure

SD-UX commands work on a hierarchy of software objects that make up the applications or operating systems components you want to manage.

Software Objects

Bundles

Collections of filesets, possibly from several different products, “encapsulated” for a specific purpose. Bundles can reside in software depots, and SD-UX commands act on bundles as single entities. All HP-UX OS software is packaged in bundles. Bundles can consist of groups of filesets or of products. Customer creation of bundles is not supported.

Products

Collections of filesets or (optionally) subproducts and control scripts. The SD-UX commands maintain a product focus but still allow you to specify subproducts and filesets.

Different versions of a product can be defined for different platforms and operating systems, as well as different revisions (releases) of the product itself. Several different versions could be included on one distribution media or depot.

Subproducts

If a product contains several filesets, subproducts can be used to group logically related filesets.

Filesets

Filesets include all the files and control scripts that make up a product. Filesets can only be part of a single product but they can be included in several different HP-UX bundles or subproducts. Like products, different versions of a fileset may be defined for different platforms and OSs.

Filesets are the lowest level of object managed by SD-UX.

Figure 1-2 Example of HP-UX Software Structure

Installed Products Database

SD-UX uses the Installed Products Database (IPD) to keeps track of what software is installed on a system. The IPD is a series of files and subdirectories that contain information about all the products that are installed under the root directory (/). (For depots, this information is maintained in catalog files beneath the depot directory.)

The swinstall, swconfig, swcopy, and swremove commands automatically add to, change, and delete IPD and catalog file information as the commands are executed. The swlist and swverify commands use IPD and catalog information to affect command behavior.

The IPD keeps track of the software state, which includes conditions such as installed or configured.

Control Scripts

Products and filesets can contain control scripts that perform checks and other tasks not performed by SD-UX commands. SD-UX supports the following types of scripts:

Checkinstall: Analyzes each target to determine if the installation and configuration can take place. (Executed by swinstall.)
Checkremove: Analyzes each target to determine if removal and unconfiguration can take place. (Executed by swremove.)
Configure: Configures installed filesets or products. (Executed by swconfig and swinstall.)
Fix: Corrects and reports on problems in installed software. (Executed by swverify.)
Postinstall: Performs additional install operations immediately after a fileset or product has been installed. (Executed by swinstall.)
Postremove: Performs additional remove operations immediately after a fileset or product has been removed. (Executed by swremove.)
Preinstall: Performs file operations (such as removing obsolete files) immediately before installation of software files. (Executed by swinstall.)
Preremove: Performs additional file operations (such as removing files created by a preinstall script) immediately before removal of software files. (Executed by swremove.)
Request: Requests an interactive response from the user as part of the installation or configuration process. (Executed by swask, swconfig, and swinstall.)
Unconfigure: Undoes configurations performed by configure scripts. (Executed by swconfig and swremove.)
Unpostinstall: Undoes operations performed by a postinstall script in case swinstall must initiate recovery during the installation process. (Executed by swinstall.)
Unpreinstall: Undoes operations performed by a preinstall script in case SD must initiate recovery during the install process. (Executed by swinstall.)
Verify: Verifies the configuration of filesets or products (in addition to the standard swverify checks.) (Executed by swverify.)

For More Information

See Chapter 11: “Using Control Scripts ”.

Environment Variables

SD-UX commands and programs are affected by external environment variables (such as language and charset variables) and variables for use by control scripts. For a description of external environment variables, see Chapter 11: “Using Control Scripts ”.

Software Dependencies

Software that depends on other software to install or run correctly is considered to have a dependency. When you specify software for the swconfig, swcopy, swinstall, swremove, swverify commands, these commands may automatically select additional software to meet dependencies.

How Commands and Options Interact with Dependencies

Command options let you control how software dependencies are handled. For example, dependency handling in swinstall and swcopy is affected by the enforce_dependencies command option.

Another option that regulates dependencies is the autoselect_dependencies option. This option determines if the system should automatically mark software for installation or copying based on whether it meets dependencies. (See “Using Command Options” for more information on options.)

How Dependencies Are Resolved

For a dependency to be resolved with respect to other software on the source depot it must be:

Complete (if the dependency is an entire product or subproduct it must exist completely in the source depot)
In the proper software state on the source (that is, available)
Free of errors (for example, no incompatibility errors)

If the dependency is not available from the source during a swconfig, swcopy, swinstall, or swverify operation, the dependency must:

Exist on the target host
Be complete (if the dependency is an entire product or subproduct it must be completely installed)
Be in the proper software state (the dependency must be configured if the software dependent on it is to be installed and configured, installed if software dependent on it is to be installed but not configured, or available if the software dependent on it is to be copied)
Be free of errors (for example, no incompatibility errors).

If you select software that has a dependency and more than one available object resolves that dependency, SD-UX automatically selects the latest compatible version.

Types of Dependencies

Software packagers can define corequisites, prerequisites, and exrequisites as dependencies. These dependencies can be specified between filesets within a product, including expressions of which versions of the fileset meet the dependency. Dependencies can also be specified between a fileset and another product. Expressions for revisions and other product attributes are supported.

Corequisites: An object requires another to operate correctly, but does not imply any load order.
Prerequisites: An object requires another to be installed and/or configured correctly before it can be installed or configured respectively. Prerequisites do control the order of operations.
Exrequisite: An object requires the absence of another object before it can be installed or configured.

Working with Protected Software

Some HP software products are protected software. That is, you cannot install or copy the software unless you provide a codeword and customer ID. The customer ID uniquely identifies the owner of the codeword and lets you restrict installation to a specific owner. To find your codeword and customer ID, examine the CD certificate shipped with your software.

It is your responsibility to ensure that the codeword and software are used properly in this manner.

One codeword unlocks most or all of the products on your media. When you purchase additional protected products, HP provides additional codewords. SD-UX keeps tracks of codewords as you enter them. This means you do not have to enter the codeword each time you access the software.

The swinstall, swcopy, and swlist commands make use of codewords in managing software.