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
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
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
SD-UX commands work on a hierarchy of software objects
that make up the applications or operating systems components you
want to manage.
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.
Collections of filesets
or (optionally) subproducts and control scripts. The SD-UX commands
maintain a product focus but still allow you to specify subproducts
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.
If a product contains
several filesets, subproducts can be used to group logically related
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
The IPD keeps track of the software state, which includes conditions such as installed or configured.
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:
Analyzes each target to
determine if the installation and configuration can take place. (Executed
Analyzes each target to
determine if removal and unconfiguration can take place. (Executed
Configures installed filesets
or products. (Executed by swconfig and swinstall.)
Corrects and reports on
problems in installed software. (Executed by swverify.)
Performs additional install
operations immediately after a fileset or product has been installed.
(Executed by swinstall.)
Performs additional remove
operations immediately after a fileset or product has been removed.
(Executed by swremove.)
Performs file operations
(such as removing obsolete files) immediately before installation
of software files. (Executed by swinstall.)
Performs additional file
operations (such as removing files created by a preinstall script)
immediately before removal of software files. (Executed by swremove.)
Requests an interactive
response from the user as part of the installation or configuration
process. (Executed by swask, swconfig, and swinstall.)
performed by configure scripts. (Executed by swconfig and swremove.)
Undoes operations performed
by a postinstall script in case swinstall must
initiate recovery during the installation process. (Executed by swinstall.)
Undoes operations performed
by a preinstall script in case SD must initiate recovery during the
install process. (Executed by swinstall.)
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 ”.
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 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
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:
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.
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.
An object requires another
to operate correctly, but does not imply any load order.
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.
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