|
» |
|
|
|
NAMEswinstall, swcopy — install and configure software products; software products for subsequent installation or distribution; respectively SYNOPSISswinstall
[XToolkit Options]
[-i]
[-p]
[-r]
[-v]
[-c
catalog]
[-C
session_file]
[-f
software_file]
[-J
jobid]
[-Q
date]
[-s
source]
[-S
session_file]
[-t
target_file]
[-x
option=value]
[-X
option_file]
[software_selections]
[@
target_selections] swcopy
[XToolkit Options]
[-i]
[-p]
[-v]
[-C
session_file]
[-f
software_file]
[-J
jobid]
[-Q
date]
[-s
source]
[-S
session_file]
[-t
target_file]
[-x
option=value]
[-X
option_file]
[software_selections]
[@
target_selections] RemarksThis command supports operation on remote systems. See the
Remote Operation
section below for details. swinstall
and
swcopy
support an interactive user interface that can be invoked alone or by
the
sd
command. See
Interactive Operation
below. For an overview of all SD commands, see the
sd(5)
man page by
typing
man 5 sd
on the command line.
DESCRIPTIONThe
swinstall
command installs the
software_selections
from a software
source
to either the local host or to one or more
target_selections
(root filesystems). By default, the software is configured for use on
the target after it is installed. (The software is not configured
when installed into an alternate root directory.) The
swcopy
command copies or merges
software_selections
from a software
source
to one or more software depot
target_selections.
These depots can then be accessed as a software source by the
swinstall
command. Remote OperationYou can enable Software Distributor (SD) to manage software on remote
systems. To let the root user from a central SD
controller
(also called the
central management server
or
manager node)
perform operations on a remote
target
(also called the
host
or
agent"): - 1)
Set up the root, host, and template Access Control Lists (ACLs) on the
remote machines to permit root access from the controller system. To do
this, run the following command on each remote system: /usr/lib/sw/mx/setaccess controller NOTES:
controller
is the name of the central management server. If remote system is 11.00, make sure SD patch PHCO_22526 or a
superseding patch is installed on remote system before running
setaccess. If remote system is older than 11.00 or for some other
reason does not have
setaccess
in place, copy
setaccess
script from an
11.11 or higher system to the remote system.
- 2)
swinstall,
swcopy ,
and
swremove
have enhanced GUI interfaces for remote operations. Enable
the enhanced GUIs by creating the
.sdkey
file on the controller. Use this command: touch /var/adm/sw/.sdkey
NOTE: You can also set up remote access by using
swacl
directly on the remote machines to grant root or non-root access to
users from the controller system. Interactive Operationswinstall
and
swcopy
each support a graphical user interface (GUI). (If your terminal or
display cannot support the GUI, these commands also provide a terminal
user interface, in which screen navigation is done with the keyboard
and no mouse.) To invoke the GUI, enter
or
on the command line (without any command-line options). You can also invoke the GUI by including the
-i
option with any other command-line options. The
sd
command provides an interactive interface for monitoring and
scheduling software jobs. You can also use
sd
to invoke the
swinstall,
copy,
and
swremove
GUIs. If you have enabled SD's remote operations features,
swinstall,
swcopy, and
swremove
provide enhanced GUIs to support operations on remote targets. See
Remote Operation
above for details about enabling remote operations and the enhanced GUIs. The command-line version of
swinstall
can also function interactively when the
ask
option is set to
true.
This option executes an interactive
request script.
Request scripts can also be executed by
swconfig
and
swask.
See
swconfig(1M)
and
swask(1M),
and the
ask=false
default option for more information. Updating the Operating SystemTo perform an operating system update, HP recommends that you use the
update-ux
command. This command replaces
swgettools
to update the operating system to HP-UX
11.11 or higher.
update-ux
is not available on 11.00 systems. To
perform an update from 11.00 to 11.11 or higher, install
update-ux
from the new operating system media. Then use
update-ux
to update the OS. See
update-ux(1M)
on an 11i system for more information. Reinstalling SDIf your copy of SD becomes unusable or if you want to install a newer
version of SD, HP recommends that you use the
install-sd
command. This command reinstalls SD and also installs any SD patches
that exist in the source depot.
install-sd
does not exist on HP-UX
11.00 systems. For 11.00, use the swgettools command to reinstall SD,
then install the latest 11.00 SD patch. See
install-sd(1M)
or
swgettools(1M)
for more information. Installing Kernel SoftwareIn HP-UX, the kernel installation process requires that the system
boots using the kernel at
/stand/vmunix.
Make sure that your system is booted to the
/stand/vmunix
kernel before you install any kernel software or perform an operating
system update. Dependencies Between SoftwareThe
swinstall
command supports
dependencies,
which is software that must be present or absent before or during the
installation of another piece of software. Dependencies apply between
filesets and other filesets and products. SD supports three types of
dependencies:
prerequisites
that must be installed and configured before the dependent fileset is
installed and configured (respectively);
corequisites
that must be installed and configured before the dependent is usable.
exrequisites
that prevent a dependent fileset from being installed or configured
when they are present. If a
software_selection
specifies a dependency on other filesets and/or products,
swinstall
automatically select that software. By default, all dependencies must be resolved before
swinstall
can proceed. You can override this policy using the
enforce_dependencies
option. Note that if you specify a dependency for a fileset and the fileset is
superseded by another fileset as part of a patch,
swinstall
still recognizes the dependency. Features and Differences between swinstall and swcopyThe key difference between
swinstall
and
swcopy
is that
swinstall
performs the software installation, while
swcopy
copies software into a depot, making it available as a source for
installation by
swinstall. NOTE: To copy to a tape, see the
swpackage(1M)
manpage. Other features (differences) include:
The
swinstall
command executes several vendor-supplied scripts during the installation
and configuration of the
software_selections.
The
swcopy
command does not execute these scripts.
The
swinstall
command supports the following scripts:
- request
a script that asks the user questions and stores responses in a
response
file. The response
file can then be used by configuration or other scripts. - checkinstall
a script executed during the analysis of a
target_selection,
it checks that the installation can be attempted.
If this check fails, the software product is not installed. - preinstall
a script executed immediately before the software's files are installed. - postinstall
a script executed immediately after the software's files are installed. - configure
a script executed during the configuration of a
target_selection,
it configures the target for the software (and the software for the target).
The
preinstall
and
postinstall
scripts are not intended to be used for configuration tasks.
They are to be used for simple file management needs such as
removing obsolete files from the previous revision (which was just updated). - unpreinstall
a script executed immediately after the software's actual files are
restored if the software install will fail and the
autorecover_product
option is set to
true.
The script undoes the steps performed by
preinstall
script. - unpostinstall
a script executed immediately before the software's actual files are
restored if the software install failed and the
autorecover_product
option is set to
true.
The script undoes the steps performed by
postinstall
script.
When a depot is created or modified using
swcopy,
catalog files
are built that describe the depot (comparable to the
Installed Products Database
(IPD) files that are built by the
swinstall
command). By default,
the
swinstall
command only allows the selection of compatible software from the
source.
This constraint ensures that the architecture of the software matches
that of the
target_selections.
No compatibility checks are performed by the
swcopy
command.
(A depot can be a repository of software targeted for a variety of
architectures and operating systems.) By default,
swinstall
supports updates to higher revisions of software.
If a
software_selection
of the same revision
is already installed,
swinstall
will not reinstall it.
If a
software_selection
has a lower
revision than the same software which is already installed,
swinstall
will not reinstall it.
(The user can override these behaviors with control options.) The
swinstall
command creates hard links and symbolic links as specified for the software.
If it encounters a symbolic link where it expected a regular file,
swinstall
follows the symbolic link and updates the file to which it points. The
swinstall
command does not remove a product's current files before installing
the new ones. A fileset's install scripts can do that, if necessary.
Files being replaced are overwritten unless they are in use. If in use,
they are unlinked or moved to
#<file>.
If the
autorecover_product
option is set to
true;
all files are saved to
#<file>,
and restored if the install fails. The
swinstall
command supports kernel building scripts and rebooting. Before or
after software that modifies the kernel is installed or updated,
swinstall
executes system-specific scripts to prepare for or build the new
version of the kernel. The remaining
software_selections
are then installed. These scripts are defined in
swagent
options and include:
install_setup_cmd,
system_prep_cmd,
kernel_build_cmd,
and
install_cleanup_cmd.
Please Note: Transition links do not exist on 11.31 and newer
releases so there are no install setup and cleanup steps to perform;
therefore, the
install_setup_cmd
and
install_cleanup_cmd
are never
executed for these releases. After software that requires a system reboot is installed or updated,
swinstall
automatically reboots the system. The reboot command is defined
by the
swagent
option:
reboot_cmd. When updating the operating system (see
update-ux(1M)
for more information.), you should install kernel software first to
ensure that a new kernel can be generated before the rest of the
operating system is updated. After all the
software_selections
are updated or installed,
swinstall
reboots using the new kernel, then executes the configure scripts for
each
software_selection.
After these scripts complete, it reboots the system again to restore
it to its normal state. No kernel building or system reboots are performed by
swcopy. Both the
swinstall
and
swcopy
commands perform various checks prior to installing or copying the
software_selections,
for example disk space analysis.
Optionsswinstall
and
swcopy
support the following options:
- XToolKit Options
The
swinstall
and
swcopy
commands
support a subset of the standard
X Toolkit options to control the appearance of the GUI.
The supported options are:
-bg,
-background,
-fg,
-foreground,
-display,
-name,
-xrm,
and
-synchronous.
See the
X(1)
manual page by typing
man X
for a definition of these options. - -i
Runs the command in interactive mode (Graphical User Interface). See
the
Interactive Operation
and
Remote Operation
headings above for details. - -l
(Applies only to
HP-UX 10.X.)
Runs the command in
linkinstall
mode which makes software installed
under a server's
shared root
available to a diskless client's
private root
(HP-UX only). When run in the
linkinstall
mode,
swinstall:
Creates NFS mounts to the software to make it accessible from the target.
This may involve delayed mounting for alternate roots. Modifies the target's
fstab
file. Modifies the source's
exports
file to add mount permission for the target.
Mounts are created by examining the
share_link
product attribute.
Not all products support
linkinstall.
Some products may be visible without creating a new mount if they
reside under an old one. - -p
Previews an install task by running the session through the analysis phase
only. - -r
Causes
swinstall
to operate on alternate root directories, which must be specified the
@ target_selections
option. Configuration scripts are not run on alternate roots. (This
option is not required for alternate root operations but is maintained
for backward compatibility. See the
Alternate Root Directory and Depot Directory
heading in
sd(5)
for more information.) - -v
Turns on verbose output to stdout.
(The
swinstall
or
swcopy
logfile is not affected by this option.)
Verbose output is enabled by default; see the
verbose
option below. - -c catalog
Specifies the pathname of an exported catalog which
stores copies of the response
file or files created by a request
script (if
-x ask=true
or
-x ask=as_needed).
The response
files are also stored in the
Installed Products Database
after the installation process is complete. - -C session_file
Save the current options and operands to
session_file.
You can enter a relative or absolute path with the file name.
The default directory for session files is
$HOME/.sw/sessions/.
You can recall a session file with the
-S
option. - -f software_file
Read the list of
software_selections
from
software_file
instead of (or in addition to) the command line. - -J jobid
Executes the previously scheduled job. This is the syntax used by the
daemon to start the job. - -Q date
Schedules the job for this date. You can change the date format by
modifying the
/var/adm/sw/getdate.templ file. - -s source
Specifies the source depot (or tape) from which software is installed
or copied. (SD can read both
tar
and
cpio
tape depots.) The default source type is
directory.
The syntax is: [host][:][/directory] A host may be specified by its host name, domain name, or Internet
address. A directory must be specified by an absolute path. - -S session_file
Execute
swinstall
or
swcopy
based on the options and operands saved from a previous session,
as defined in
session_file.
You can save session information from a command-line session
with the
-C
session_file
option. - -t target_file
Read the list of
target_selections
from
target_file
instead of (or in addition to) the command line. - -x option=value
Set the session
option
to
value
and override the default value (or a value in an alternate
option_file
specified with
the
-X
option).
Multiple
-x
options can be specified. - -X option_file
Read the session options and behaviors from
option_file.
OperandsThe
swinstall
and
swcopy
commands support two types of operands:
software selections
followed by
target selections.
These operands are separated by the "at"
(@)
character. This syntax
implies that the command operates on "software selections at targets". Software SelectionsThe
selections
operands consist of
software_selections. swinstall
and
swcopy
support the following syntax for each
software_selection:
bundle[.product[.subproduct][.fileset]][,version]
product[.subproduct][.fileset][,version]
The
=
(equals) relational operator lets you specify selections
with the following
shell wildcard and pattern-matching notations:
For example, the following expression installs all bundles and
products with tags that end with "man":
swinstall -s sw_server *man
Bundles
and
subproducts
are recursive.
Bundles
can contain other
bundles
and
subproducts
can contain other
subproducts.
For example:
swinstall bun1.bun2.prod.sub1.sub2.fset,r=1.0
or (using expressions):
swinstall bun[12].bun?.prod.sub*,a=HP-UX
The
\*
software specification selects all products. Use this specification
with caution.
The
version
component has the form:
[,r <op> revision][,a <op> arch][,v <op> vendor]
[,c <op> category][,q=qualifier][,l=location]
[,fr <op> revision][,fa <op> arch]
location
applies only to installed software and refers to software installed to
a location other than the default product directory. fr
and
fa
apply only to filesets. r
,
a
,
v
,
c
, and
l
apply only to bundles and products. They are applied to the
leftmost bundle or product in a software specification. The
<op>
(relational operator) component can be of the form:
=,
==,
>=,
<=,
<,
>,
or
!=
which performs individual comparisons on dot-separated fields. For example,
r>=B.10.00
chooses all revisions greater than or equal to
B.10.00.
The system compares each dot-separated field to find
matches. The
=
(equals) relational operator lets you specify selections with the
shell wildcard and pattern-matching notations:
For example, the expression
r=1[01].*
returns any revision in version 10 or version 11. All version components are repeatable within a single specification (e.g.
r>=A.12,
r<A.20).
If multiple components are used, the selection must match all
components. Fully qualified software specs
include the
r=,
a=,
and
v=
version components even if they contain empty strings. For installed
software,
l=
is also included. No space or tab characters are allowed in a software selection. The software
instance_id
can take the place of the version component. It has the form:
within the context of an exported catalog, where
instance_id
is an integer that distinguishes versions of products and bundles with
the same tag.
The
\*
software specification selects all products. It is not allowed when
removing software from the root directory
/. Target SelectionThe
swinstall
and
swcopy
commands support the following syntax for each
target_selection.
The colon
(:)
is required if both a host and directory are specified.
A host may be specified by its host name, domain name, or Internet
address. A directory must be specified by an absolute path. For
linkinstall,
on HP-UX 10.X systems: if the
[directory]
part of the selection is a relative path, then the value of
default.shared_root=true
is pre-pended for sources and the value of
default.private_root=true
is pre-pended for targets. These are normally
/export/shared_roots
and
/export/private_roots,
respectively. EXTERNAL INFLUENCESDefault OptionsIn addition to the standard options, several SD behaviors and policy options
can be changed by editing the default values found in:
- /var/adm/sw/defaults
the system-wide default values. - $HOME/.swdefaults
the user-specific default values.
Values must be specified in the defaults file using this syntax: [command_name.]option=value The optional
command_name
prefix denotes one of the SD commands. Using the prefix limits the
change in the default value to that command. If you leave the prefix
off, the change applies to all commands. You can also override default values from the command line with the
-x
or
-X
options: command -x option=value
command -X option_file The following section lists all of the keywords supported by the
swinstall
and
swcopy
commands. If a default value exists,
it is listed after the
=. - admin_directory=/var/adm/sw (for normal mode)
- admin_directory=/var/home/LOGNAME/sw (for nonprivileged mode)
The location for SD logfiles and the default parent directory for the
installed software catalog. The default value is
/var/adm/sw
for normal SD operations. When SD operates in nonprivileged mode
(that is, when the
run_as_superuser
default option is set to
true):
The default value is forced to
/var/home/LOGNAME/sw. The path element
LOGNAME
is replaced with the name of the invoking user, which SD reads from
the system password file. If you set the value of this option to
HOME/path,
SD replaces
HOME
with the invoking user's home directory (from the system password
file) and resolves
path
relative to that directory. For example,
HOME/my_admin
resolves to the
my_admin
directory in your home directory. If you set the value of the
installed_software_catalog
default option to a relative path, that path is resolved relative to
the value of this option.
SD's nonprivileged mode is intended only for managing applications
that are specially designed and packaged. This mode cannot be used to
manage the HP-UX operating system or patches to it. For a full
explanation of nonprivileged SD, see the
Software Distributor Administration Guide,
available at the
http://docs.hp.com
web site. See also the
installed_software_catalog
and
run_as_superuser
options. - agent_auto_exit=true
Causes the target agent to automatically exit after Execute phase, or after
a failed Analysis phase. This is forced to
false
when the controller is using
an interactive UI, or when
-p
(preview) is used. This enhances network
reliability and performance. The default is
true
- the target agent automatically exits when appropriate.
If set to
false,
the target agent will not exit until the controller ends the session. - agent_timeout_minutes=10000
Causes a target agent to exit if it has been inactive for the
specified time. This can be used to make target agents more quickly
detect lost network connections since RPC can take as long as 130
minutes to detect a lost connection. The recommended value is the
longest period of inactivity expected in your environment. For command
line invocation, a value between 10 minutes and 60 minutes is
suitable. A value of 60 minutes or more is recommended when the GUI
is used. The default of 10000 is slightly less than 7 days. - allow_downdate=false
(Applies only to
swinstall.)
Prevents the installation of an older revision of fileset that already
exists at the target(s). (Many software products do not support
"downdating".) If set to
true,
the older revision can be installed. - allow_incompatible=false
(Applies only to
swinstall.)
Requires that the software products which are being installed be
"compatible" with the target selections. (All of the target selections
must match the list of supported systems defined for each selected
product.) If set to
true,
target compatibility is not enforced. - allow_multiple_versions=false
(Applies only to
swinstall.)
Prevents the installation of another, independent version of a product
when a version already is already installed at the target. If set to
true,
another version of an existing product can be installed into a new
location. Multiple versions can only be installed if a product is
locatable. Multiple configured versions will not work unless the
product supports it. - allow_split_patches=false
Permits the use of single patch filesets without "sibling" filesets.
In the default state of
false,
installation or copying of a single fileset from a multi-fileset patch
automatically includes any other fileset that are part of the patch,
based on the ancestor filesets of the target fileset. (This behavior
applies to filesets selected directly by the user and to filesets
automatically selected by SD to resolve software dependencies.) When set to
true,
SD allows a single patch fileset to be installed or copied without
including the sibling filesets. This allows a target to contain a
patch that has been "split" into its component filesets. WARNING:
Splitting a patch can create a situation in which one fileset in a
sibling group would be updated by a patch, while the other filesets
would remain at an earlier release. - ask=false
(Applies only to
swinstall.)
When
ask=true,
executes a request
script which asks for a user response. If
ask=as_needed,
the
swinstall
command first determines if a response
file already exists in the
catalog specified in the
-c
option or source depot and executes the request
script only when a response
file is absent. If set to
ask=true,
or
ask=as_needed,
you can use the
-c
catalog
option to specify the pathname of an exported catalog to
store copies of the response
file or files created by the request script. See
swask(1M)
for more information on request
scripts. - autoreboot=false
(Applies only to
swinstall.)
Prevents the installation of software requiring a reboot from the
non-interactive interface.
If set to
true,
this software can be installed and the target system(s) will be
automatically rebooted. An interactive session always asks for confirmation before software requiring
a reboot is installed. - autorecover=false
This option permits automatic recovery of original filesets if an
installation error occurs. The cost is a temporary increase in disk
space and slower performance. The default value of
false
causes
swinstall
to remove the original files as a fileset is updated. If an error
occurs during the installation (e.g. network failure), then the
original files are lost, and you must reinstall the fileset. If set to
true,
all files are saved as backup copies until the current fileset
finishes loading. If an error occurs during installation, the
fileset's original files are replaced, and
swinstall
continues to the next fileset in the product or the product
postinstall
script. When set to
true,
this option also affects scripts. For example, if a
preinstall
script fails, this option causes the corresponding
unpreinstall
script to execute. See
Software Distributor Administration Guide
for complete information. - autorecover_product=false
(Applies only to
swinstall.)
This option permits automatic recovery of original product files if an
installation error occurs. The cost is a temporary increase in disk
space and slower performance. The default value of
false
causes
swinstall
to remove any existing product files as a product is updated. If an
error occurs during installation (e.g. network failure), then the
original files are lost, and you must reinstall the product. If set to
true,
all files for a product are saved as backup copies until the entire
product finishes loading. Then the files are removed. If an error
occurs during installation, the original product files are replaced,
and
swinstall
exits. When set to
true,
this option also affects scripts. For example, if a
preinstall
script fails, this option causes the corresponding
unpreinstall
script to execute. See
Software Distributor Administration Guide
for complete information. - autoremove_job=false
Controls automatic job removal of completed jobs. If the job is
automatically removed, job information (job status or target logfiles)
cannot be queried with
swjob. - autoselect_dependencies=true
Automatically select dependencies when software is being selected.
When set to
true,
and any software which has dependencies is selected for install,
swinstall
or
swcopy
makes sure that the dependencies are met. If they are not already
met, they are automatically selected for you. If set to
false,
automatic selections are not made to resolve requisites. When set to
as_needed,
autoselected dependencies are operated only if the dependency is not
already met on the target. - autoselect_patches=true
Automatically selects the latest patches (based on superseding and
ancestor attributes) for a software object that a user selects for a
swinstall
or
swcopy
operation. When set to
false,
the patches corresponding to the selected object, are not automatically
selected. The
patch_filter=
option can be used in conjunction with
autoselect_patches. - autoselect_reference_bundles=true
If
true,
bundles that are
sticky
are automatically installed or copied, along with the software it is
made up of. If
false,
the software can be installed, or copied, without automatically
including sticky bundles that contain it. - codeword=
Provides the "codeword" needed to unlock protected HP CD-ROM software. Some HP software products are shipped on CD-ROM as "protected"
products. That is, they cannot be installed or copied unless a
"codeword" and "customer ID" are provided. The codeword is found on
the CD-ROM certificate which you received from HP. You may use this
default specification on the command line or the SD-UX Interactive
User Interface to enter the codeword. This default stores the codeword for future reference, and you need to
enter the codeword only once. If you purchase a new HP product and a
previous codeword has already been entered for that CD-ROM, just enter
the new codeword as usual and the codewords will be merged internally. NOTE: For HP-UX B.10.10 and later systems, SD searches the
.codewords
file on the server that is providing protected software to other hosts.
It looks for valid customer_id/codeword pairs. In doing so, SD eliminates
the need to enter codewords and customer_ids on every host that is "pulling"
the software. To properly store the customer_id/codeword for a CD-ROM, run
swinstall -p
or
swcopy -p
on the host serving the CD-ROM. After the codeword has been stored, clients
installing or copying software using that host and CD-ROM as a source
will no longer need a codeword or customer_id. - compress_files=false
If set to
true,
uncompressed files are compressed before transfer from a source. This
enhances performance on slower networks for
swcopy
and
swinstall,
and results in smaller depots for
swcopy
and
swpackage,
unless the
uncompress_files
option is also set to
true. - compress_index=false
Determines whether SD commands create compressed INDEX and INFO
catalog files when writing to target depots or roots. The default of
false
does not create compressed files. When set to
true,
SD creates compressed and uncompressed INDEX and INFO files. The
compressed files are named
INDEX.gz
and
INFO.gz,
and reside in the
same directories as the uncompressed files. Compressed files can enhance performance on slower networks, although
they may increase disk space usage due to a larger Installed Products
Database and depot catalog. SD controllers and target agents for
HP-UX 11.01 and higher automatically load the compressed INDEX and
INFO files from the source agent when:
The source agent supports this feature. INDEX.gz
or
INFO.gz
exist on the source depot. INDEX.gz
or
INFO.gz
are not older than the corresponding uncompressed
INDEX or INFO files.
The uncompressed INDEX or INFO file is accessed by the source agent if
any problem occurs when accessing, transferring, or uncompressing the
INDEX.gz
or
INFO.gz
file. - controller_source=
Specifies the location of a depot for the controller to access to
resolve selections. Setting this option can reduce network traffic
between the controller and the target. Use the target selection syntax
to specify the location:
[host][:][/directory] The
controller_source_option
supports the same syntax as the
-s source
option. This option has no effect on which sources the target uses and is
ignored when used with the Interactive User Interface. - create_target_path=true
Causes the agent to create the target directory if it does not already
exist. If set to
false,
a new target directory is not created. This option can prevent the
erroneous creation of new target depots or new alternate root
directories. - create_time_filter=0
For cumulative source depots, this option allows consistent software
selections over time by
swlist,
swcopy,
and
swinstall.
The default of zero includes all bundles, products, subproducts, and
filesets in the source depot as candidates for selection (and
autoselection of dependencies and patches), based on the software
selections and other options. When set to a time (specified as
seconds from epoch), only those bundles, products, and filesets (and
the subproducts in the product) with a create_time less than or equal
to the specified value are available for selection (or autoselection).
To list the create_time of bundles, products and filesets, use: swlist -a create_time -a create_date - customer_id=
This number, also printed on the Software Certificate,
is used to "unlock" protected
software and restrict its installation to a specific site or owner.
It is entered using the
-x
customer_id=
option or by using the Interactive User Interface. The
customer_id
can be used on any HP-UX 10.0X or later system. - defer_configure=false
(Applies only to
swinstall.)
Causes
swinstall
to automatically run configure scripts for the
software_selections
after they are installed. (Alternate root directories are not configured.) When set to true,
swinstall
does not run configure scripts. If you want to configure the software
later, you must run the
swconfig
command. NOTES:
Multiple versions of a product will not be automatically
configured if another version is already configured. Use the
swconfig
command to configure multiple versions separately. SD ignores this option when it installs software that causes a
system reboot.
- distribution_source_directory=/var/spool/sw
Defines the default location of the source depot (when the
source_type
is
directory).
You can also use the
host:path
syntax. The
-s
option overrides this default. - distribution_target_directory=/var/spool/sw
(Applies only to
swcopy.)
Defines the default location of the target depot. - enforce_dependencies=true
Requires that all dependencies specified by the
software_selections
be resolved either in the specified source, or at the
target_selections
themselves. The
swinstall
and
swcopy
commands will not proceed unless the
dependencies have also been selected or already exist at the target in
the correct state (INSTALLED or AVAILABLE). This prevents
unusable software from being installed on the system. It also ensures
that depots contain usable sets of software. If set to
false,
dependencies are still checked, but not enforced. Corequisite
dependencies, if not enforced, may keep the selected software from
working properly. Prerequisite dependencies, if not enforced, may cause
the installation or configuration to fail. - enforce_dsa=true
Prevents the command from proceeding past the analysis phase if the disk
space required is beyond the available free space of the impacted
filesystem(s). If set to
false,
the install or copy operation uses the filesystem's minfree
space and may fail because it reaches the filesystem's absolute limit. - enforce_kernbld_failure=true
(Applies only to
swinstall.)
Prevents
swinstall
from proceeding past the kernel build phase if the kernel build processes fail.
If set to
false,
the install operation continues (without suspension if in the
interactive mode) despite failure or warnings from either the system
preparation process or the kernel build process. When set to the default value of
true,
this option generates an error if a command tries to relocate a
non-relocatable fileset. (Relocatable filesets are packaged with the
is_relocatable
attribute set to
true).
When set to
false,
the usual error handling process is overridden, and SD permits the
command to relocate the fileset. - enforce_scripts=true
Controls the handling of errors generated by scripts. If
true,
and a script returns an error, an error message appears reporting that
the execution phase failed. If
false,
swinstall
attempts to continue operation. A warning message appears saying that
the analysis or execution phase succeeded. The message identifies the
specific
swinstall
phase (checkinstall, preinstall, postinstall, or configure). - fix_explicit_directories=false
Controls the
swinstall
response to explicitly packaged software (software packaged with
explicit file specifications). The default value of
false
causes
swinstall
to set permissions (as specified in the product specification file) on
new directories but never on pre-existing directories. When set to
true, swinstall
also sets the permissions on pre-existing directories. - installed_software_catalog=products
(Applies only to
swinstall.)
Defines the directory path where the Installed Products Database (IPD)
is stored. This information describes installed software. When set to
an absolute path, this option defines the location of the IPD. When
this option contains a relative path, the SD controller appends the
value to the value specified by the
admin_directory
option to determine the path to the IPD. For alternate roots, this
path is resolved relative to the location of the alternate root. This
option does not affect where software is installed, only the IPD
location. This option permits the simultaneous installation and removal of
multiple software applications by multiple users or multiple
processes, with each application or group of applications using a
different IPD. Caution: use a specific
installed_software_catalog
to manage a
specific application. SD does not support multiple descriptions of the
same application in multiple IPDs. See also the
admin_directory
and
run_as_superuser
options, which control SD's nonprivileged mode. (This mode is intended
only for managing applications that are specially designed and
packaged. This mode cannot be used to manage the HP-UX operating
system or patches to it. For a full explanation of nonprivileged SD,
see the
Software Distributor Administration Guide,
available at the
http://docs.hp.com
web site.) - job_title=
This is an ASCII string giving a title to a job. It is displayed
along with the job ID to provide additional identifying information
about a job when
swjob
or
sd
is invoked. The default value is to have no title. If a title is
specified, it should be enclosed in quotes. - layout_version=1.0
(Applies only to swcopy.)
Specifies the POSIX
layout_version
to which the SD commands conform when writing distributions and
swlist
output. Supported values are "1.0" (default) and "0.8". SD object and attribute syntax conforms to the
layout_version 1.0
specification of the
IEEE POSIX 1387.2 Software Administration
standard. SD commands still accept the keyword names associated
with the older layout version, but you should use
layout_version=0.8
only to create distributions readable by older versions of SD. See the description of the
layout_version
option in
sd(5)
for more information. - logdetail=false
Controls the amount of detail written to the logfile. When set to
true,
this option adds detailed task information (such as options specified,
progress statements and additional summary information) to the
logfile. This information is in addition to log information controlled
by the
loglevel
option. See
loglevel=1
and the
sd(5)
manual page by typing
man 5 sd
for more information. - logfile=/var/adm/sw/swremove.log
This is the default command log file for
the
swinstall
command. - loglevel=1
Controls the log level for the events logged to the command logfile, the
target agent logfile, and the source agent logfile. This information
is in addition to the detail controlled by the
logdetail
option. (See
logdetail=false
and the
sd(5)
manual page for more information.)
A value of:
- 0
provides no information to the logfile. - 1
enables verbose logging to the logfiles. - 2
enables very verbose logging, including per-file messages, to the logfiles.
- log_msgid=0
Adds numeric identification numbers at the beginning of SD logfile
messages:
- 0
(default) No identifiers are attached to messages. - 1
Adds identifiers to ERROR messages only. - 2
Adds identifiers to ERROR and WARNING messages. - 3
Adds identifiers to ERROR, WARNING, and NOTE messages. - 4
Adds identifiers to ERROR, WARNING, NOTE, and certain other
informational messages.
- match_target=false
(Applies only to
swinstall.)
If set to
true,
software selection is done
by locating filesets on the source that match the target system's
installed filesets. If multiple targets are specified, the first in
the list is used as the basis for selections. - max_targets=25
When set to a positive integer, SD limits the number of concurrent
install or copy operations to the number specified. As each copy or
install operation completes, another target is selected and started
until all targets have been completed. Server and network performance determines the optimal setting; a
recommended starting point is 25 (the default value). If you set this
option to a value of less than one, SD attempts to install or copy to
all targets at once. - mount_all_filesystems=true
Attempt to mount all filesystems
in the
/etc/fstab
file at the beginning of the analysis phase,
to ensure that all listed filesystems are mounted before proceeding.
This policy helps to ensure that files are not loaded
into a directory that may be below a future mount point. If set to
false,
the mount operation is not attempted, and no check of the current mounts
is performed. - os_name
(Applies only to
swinstall.)
This option can be used in conjunction with
os_release
to specify the desired OS name during an HP-UX update. The
os_name
option should only be specified from the command line. Refer to the SD
readme
file for correct syntax. You can display the
readme
file by entering: swlist -a readme -l product SW-DIST - os_release
(Applies only to
swinstall.)
This option can be used in conjunction with
os_name
to specify the desired OS release during an HP-UX update. The
os_release
option should only be specified from the command line. Refer to the SD
readme
file for correct syntax. You can display the
readme
file by entering: swlist -a readme -l product SW-DIST - patch_filter=software_specification
This option can be used in conjunction with the
autoselect_patches
or
patch_match_target
options to filter the selected patches to meet the criteria specified by
software_specification.
The default value of this option is
*.*. - patch_match_target=false
If set to
true,
this option selects the latest patches (software identified by the
is_patch=true
attribute) that correspond to software on the target root or depot. The
patch_filter=
option can be used in conjunction with
patch_match_target. - patch_save_files=true
(Applies only to swinstall)
Saves the original versions of files modified by patches, which
permits the future rollback of a patch. Patched files are saved to
/var/adm/sw/save.
When set to
false,
patches cannot be rolled back (removed) unless the base software
modified by the patch is removed at the same time. To commit a patch by removing the corresponding saved files, use the
swmodify
command's
patch_commit
option. - polling_interval=2
Defines the polling interval, in seconds, used by the interactive GUI
or TUI of the controller. It specifies how often each target agent is
polled to obtain status information about the task being performed.
When operating across wide-area networks, the polling interval can be
increased to reduce network overhead. - preserve_create_time=false
(Applies only to
swcopy.)
Preserves the original create time when you copy depots, which
produces consistent results when you use the copies. The default of
false
sets the create_time of software bundles, products, and filesets
equal to the time the object was created in the depot. When set to
true,
the create_time of software bundles, products, and filesets is
set to that specified in the source depot. Note that using this
option when copying to a master depot can change the objects that are
visible when you use the
create_time_filter
option. - recopy=false
(Applies only to
swcopy.)
Do not copy a fileset that is already available on the target at the
same version. If
recopy=true,
copy the fileset in any case. - register_new_depot=true
(Applies only to
swcopy.)
Causes
swcopy
to register a newly created depot with the local
swagentd.
This action allows other SD commands to automatically "see" this depot.
If set to
false,
a new depot is not automatically registered. It can be registered
later with the
swreg
command. - register_new_root=true
(Applies only to
swinstall.)
Causes alternate roots to be registered during
swinstall.
These can be listed with
swlist. - reinstall=false
When re-installing an existing revision of a fileset, this option
causes that fileset to be skipped, i.e. not re-installed. If set to
true,
the fileset is re-installed. See also
recopy=false. - reinstall_files=false
Controls the overwriting of files, which may enhance performance on
slow networks or disks. At the default value of false, SD compares
each file in a source fileset to corresponding files on the target
system. SD compares the files based on size, timestamp, and
(optionally) the
checksum
(see
reinstall_files_use_cksum).
If the files are identical the files on the target system are not
overwritten. When set to true, SD does not compare files and overwrites any
identical files on the target. - reinstall_files_use_cksum=true
Controls the use of checksum comparisons when the
reinstall_files
option is set to false. At the default value of true, this option
causes SD to compute and compare checksums to determine if a new file
should overwrite an old file. Use of checksums slows the comparison
but is a more robust check for equivalency than size and time stamp. If set to false, SD does not compute checksums and compares files only
by size and timestamp. - remove_obsolete_filesets=false
(Applies only to
swcopy.)
Controls whether
swcopy
automatically removes obsolete filesets from target products in the
target depot. If set to
true,
swcopy
removes obsolete filesets from the target products that were written
to during the copy process. Removal occurs after the copy is
complete. Filesets are defined as obsolete if they were not part of
the most recent packaging of the product residing on the source depot. - retry_rpc=1
Defines the number of times a lost source connection is retried during
file transfers in
swinstall
or
swcopy.
A lost connection is one that has timed out. When used in conjunction
with the
rpc_timeout
option, the success of installing over slow or busy networks can be
increased. If set to zero, any
rpc_timeout
to the source causes the task to abort. If set from 1 to 9, the
install of each fileset is attempted that number of times. The
reinstall_files
option should also be set to false to avoid installing files within
the fileset that were successfully installed. This option also applies to the controller contacting the agent. If
the agent session fails to start for any reason, the controller tries
to recontact that agent for the number of times specified in
retry_rpc,
using the values from the
retry_rpc_interval
option to determine how long to wait between each attempt to recontact
the agent. - retry_rpc_interval={0}
Specifies in minutes the length of the interval for repeated attempts
to make a connection to a target after an initial failure. Used in
conjunction with the
retry_rpc
option. If the number of values in this option equals the value of
retry_rpc,
SD tries reestablishing a source connection for the number of times
specified in
retry_rpc.
If the number of values in
retry_rpc_interval
is less than the value in
retry_rpc,
SD repeats the final interval value until the number of retries
matches
retry_rpc. For example, if a session failed to start and
retry_rpc
was set to 9 and
retry_rpc_interval
was set to {1 2 4 8 15} to allow long waits to handle transient
network failures, the SD controller
would attempt to recontact the agent after 1 minute for the first
retry, then 2 minutes for the second retry, 4 for the third, then 8,
then 15 for all additional retries until nine retries were
attempted. With these values, a file load failure could cause the
operation to pause for 90 minutes (1+2+4+8+15+15+15+15+15). If
retry_rpc
was set to 5 and
retry_rpc_interval
was set to {1 2 4 8 15}, the controller would try
to contact the target five times over a 30-minute period. - rpc_binding_info=ncacn_ip_tcp:[2121] ncadg_ip_udp:[2121]
Defines the protocol sequence(s) and endpoint(s) on which the daemon
listens and the other commands contact the daemon. If the connection
fails for one protocol sequence, the next is attempted. SD supports
both the tcp
(ncacn_ip_tcp:[2121])
and udp
(ncadg_ip_udp:[2121])
protocol sequence on most platforms. See the
sd(5)
man page by typing
man 5 sd
for more information. - rpc_binding_info_source=
Defines the protocol sequence(s) and endpoint(s) on which commands
contact the daemon for source access only. If the connection fails
for one protocol sequence, the next is attempted. If this is set to
no value (default) the values from
rpc_binding_info
are used to contact the daemon for source access. See
rpc_binding_info
(above) for more information. - rpc_binding_info_target=
Defines the protocol sequence(s) and endpoint(s) on which commands
contact the daemon for target access only. If the connection fails
for one protocol sequence, the next is attempted. If this is set to
no value (default) the values from
rpc_binding_info
are used to contact the daemon for target access. See
rpc_binding_info
(above) for more information. - rpc_timeout=5.
Relative length of the communications timeout. This is a value in the
range from 0 to 9 and is interpreted by the DCE RPC. Higher values
mean longer times; you may need a higher value for a slow or busy
network. Lower values give faster recognition on attempts to contact
hosts that are not up or not running
swagentd.
Each value is approximately twice as long as the preceding value.
A value of 5 is about 30 seconds for the
ncadg_ip_udp
protocol sequence.
This option may not have any noticeable impact when using the
ncacn_ip_tcp
protocol sequence. - run_as_superuser=true
This option controls SD's nonprivileged mode. This option is ignored
(treated as true) when the invoking user is super-user. When set to the default value of true, SD operations are performed
normally, with permissions for operations either granted to a local
super-user or set by SD ACLs. (See
swacl(1M)
for details on ACLs.) When set to false and the invoking user is local and is
not
super-user, nonprivileged mode is invoked:
Permissions for operations are based on the user's file system
permissions. Files created by SD have the uid and gid of the invoking user, and the
mode of created files is set according to the invoking user's umask.
SD's nonprivileged mode is intended only for managing applications
that are specially designed and packaged. This mode cannot be used to
manage the HP-UX operating system or patches to it. For a full
explanation of nonprivileged SD, see the
Software Distributor Administration Guide,
available at the
http://docs.hp.com
web site. See also the
admin_directory
and
installed_software_catalog
options. - select_local=true
If no
target_selections
are specified,
select the default root directory
/
(swinstall),
or the default
target_directory
(swcopy),
at the local host as the target of the command. - software=
Defines the default
software_selections.
There is no supplied default.
If there is more than one software selection, they must be separated by spaces. - software_view=all_bundles
Indicates the software view to be used as the default level for
the software listing in the GUI.
It can be set to
all_bundles,
products,
or a bundle category tag (to indicate to show only bundles of that
category). - source=
Specify a source to automatically bypass the GUI and CLI source
selection dialog box. This has the same effect as the
-ssource
command line option. Specify the source using the following syntax. [path] - source_cdrom=/SD_CDROM
Defines the default location of the source CD-ROM using the syntax
[host]:[path]. - source_tape=/dev/rmt/0m
Defines the default location of the source tape, usually the
character-special file of a local tape device. You can also use the
[host]:[path]
syntax, but the host must match the local host.
The
-s
option overrides this value. (Note that SD can read both
tar
and
cpio
tape depots.) - source_type=directory
Defines the default source type:
cdrom,
directory,
or
tape.
The source type derived from the
-s
option overrides this value. (SD can read both
tar
and
cpio
tape depots.) - targets=
Defines the default
target_selections.
There is no supplied default (see
select_local
above).
If there is more than one target selection, they must be separated by spaces. - uncompress_files=false
(Applies only to
swcopy.)
If set to
true,
files being transferred from a source are uncompressed before
swcopy
store them on the target depot. - use_alternate_source=false
Empowers each target agent to use its own, configured alternate source, instead
of the one specified by the user.
If
false,
each target agent uses the same source (the source specified by
the user and validated by the command).
If
true,
each target agent uses its own configured value for the source. - verbose=1
Controls the verbosity of the output (stdout). A value of
- 0
disables output to stdout. (Error and warning messages
are always written to stderr). - 1
enables verbose messaging to stdout.
- write_remote_files=false
Prevents the installation or copying of files to a target which exists
on a remote filesystem. All files destined for a remote filesystem
are skipped. If set to
true
and if the superuser has write permission on the remote filesystem,
the remote files are installed or copied.
Session FileEach invocation of the
swinstall
or
swcopy
command defines an installation or copy session. The invocation
options, source information, software selections, and target hosts are
saved before the installation or copy task actually commences. This
lets you re-execute the command even if the session ends before proper
completion. Each session is saved to the file
$HOME/.sw/sessions/swinstall{swcopy}.last.
This file is overwritten by each invocation of
swinstall
or
swcopy. You can also save session information from interactive or command-line
sessions.
From an interactive session, you can save session information
into a file at any time by selecting the
Save Session
or
Save Session As
option from the
File
menu.
From a command-line session, you can save session information by
executing
swinstall
or
swcopy
with the
-C
session__file
option. A session file uses the same syntax as the defaults files.
You can specify an absolute path for a session file. If you do
not specify a directory, the default location for a session file is
$HOME/.sw/sessions/. To re-execute a saved session from an interactive session, use the
Recall Session
option from the
File
menu. To re-execute a session from a command-line, specify the
session file as the argument for the
-S
session__file
option of
swinstall
or
swcopy. Note that when you re-execute a session file, the values in the session
file take precedence over values in the system defaults file.
Likewise, any command line options or parameters that you specify when
you invoke
swinstall
or
swcopy
take precedence over the values in the session file. Software and Target ListsMost SD commands support software and target selections from separate
input files (see the
-f
and
-t
command-line options). Software and targets specified in these files
will be selected for operation.
swinstall
and
swcopy
also support an interactive read and save of target and software
groups. Target and software groups can be saved in files (default
location
$HOME/.sw/targets/
and
$HOME/.sw/software/)
and then selected in subsequent
swinstall
and
swcopy
operations. Additionally, the
swinstall
and
swcopy
interactive user interfaces read a default list of hosts on which to
operate. The list is stored in:
- /var/adm/sw/defaults.hosts
the system-wide default list of hosts - $HOME/.swdefaults.hosts
the user-specific default list of hosts
For each interactive command, target hosts containing roots and target
hosts containing depots are specified in separate lists (
hosts,
hosts_with_depots,
respectively). The list of hosts are enclosed in {} braces and
separated by white space (blank, tab and newline). For example:
swinstall.hosts={hostA hostB hostC hostD hostE hostF}
swcopy.hosts_with_depots={hostS} The
swinstall
and
swcopy
interactive user interfaces read a default list of patch filters that
you can use as selection criteria for patch software. The list is
stored in:
- /var/adm/sw/defaults.patchfilters
the system-wide default list of patch filters. - $HOME/.sw/defaults.patchfilters
the user-specific default list of patch filters.
The list of patch filters is enclosed in braces {} and
separated by white space (blank, tab, or newline). For example:
swinstall.patch_filter_choices={
*.*,c=enhancement
*.*,c=critical
}
swcopy.patch_filter_choices={
Product.Fileset,c=halts_system
} Environment VariablesThe environment variables that affect the
swinstall
command are:
- LANG
Determines the language in which messages are displayed.
If LANG is not specified or is set to the empty string, a
default value of
C
is used.
See the
lang(5)
man page by typing
man 5 sd
for more information. NOTE: The language in which the SD agent and daemon log messages
are displayed is set by the system configuration variable script,
/etc/rc.config.d/LANG.
For example,
/etc/rc.config.d/LANG,
must be set to
LANG=ja_JP.SJIS
or
LANG=ja_JP.eucJP
to make the agent and daemon log messages display in Japanese. - LC_ALL
Determines the locale to be used to override any values for locale
categories specified by the settings of
LANG
or any environment variables beginning with
LC_. - LC_CTYPE
Determines the interpretation of sequences of bytes of text data as
characters (e.g., single-versus multibyte characters in values for
vendor-defined attributes). - LC_MESSAGES
Determines the language in which messages should be written. - LC_TIME
Determines the format of dates
(create_date
and
mod_date)
when displayed by
swlist.
Used by all utilities when displaying dates and times in
stdout,
stderr,
and
logging. - TZ
Determines the time zone for use when displaying dates and times.
Environment variables that affect scripts: - SW_CATALOG
Holds the path to the Installed Products Database (IPD), relative to
the path in the
SW_ROOT_DIRECTORY
environment variable. Note that you
can specify a path for the IPD using the
installed_software_catalog
default option. - SW_CONTROL_DIRECTORY
Defines the current directory of the script being executed, either
a temporary catalog directory, or a directory within in the
Installed Products Database (IPD).
This variable tells scripts where other
control
scripts for the software
are located (e.g. subscripts). - SW_CONTROL_TAG
Holds the tag name of the
control_file
being executed. When packaging
software, you can define a physical name and path for a control file
in a depot. This lets you define the
control_file
with a name other
than its tag and lets you use multiple control file definitions to
point to the same file. A
control_file
can query the - SW_LOCATION
Defines the location of the product, which may have been changed from
the default product directory. When combined with the
SW_ROOT_DIRECTORY,
this variable tells scripts where the product files are located. - SW_PATH
A PATH variable which defines a minimum set of
commands available to for use in a
control
script
(e.g.
/sbin:/usr/bin). - SW_ROOT_DIRECTORY
Defines the root directory in which the session is operating, either
"/" or an alternate root directory.
This variable tells
control
scripts the root directory in which the
products are installed. A script must use this directory as a prefix to
SW_LOCATION
to locate the product's installed files.
The configure script is only run when
SW_ROOT_DIRECTORY
is
/. - SW_SESSION_OPTIONS
Contains the pathname of a file containing the value of every option
for a particular command, including software and target
selections. This lets scripts retrieve any command
options and values other than the ones provided explicitly by
other environment variables. For example, when the file pointed to by
SW_SESSIONS_OPTIONS
is made available to a request script, the
targets
option contains a list of
software_collection_specs
for all targets specified for the command. When the file pointed to by
SW_SESSIONS_OPTIONS
is made available to other scripts, the
targets
option contains the single
software_collection_spec
for the targets on which the script is being executed. - SW_SOFTWARE_SPEC
This variable contains the fully qualified software specification of
the current product or fileset. The software specification allows the
product or fileset to be uniquely identified.
Additional environment variables that affect scripts for
swinstall: - SW_DEFERRED_KERNBLD
This variable is normally unset. If it is
set, the actions necessary for preparing the
system file
/stand/system
cannot be
accomplished from within the
postinstall
scripts, but instead must be accomplished by
the
configurescripts.
This occurs whenever
software is installed to a directory other
than
/,
such as for a cluster client system.
This variable should be read only by the
configure
and
postinstall
scripts of a kernel fileset. The
swinstall
command sets these environment variables for use by the kernel
preparation and build scripts. - SW_INITIAL_INSTALL
This variable is normally unset. If it is
set, the
swinstall
session is being run as the
back end of an initial system software
installation ("cold" install). - SW_KERNEL_PATH
The path to the kernel. The default value is
/stand/vmunix,
defined by the
swagent
option or
kernel_path. - SW_SESSION_IS_KERNEL
Indicates whether a kernel build is scheduled for the current
install/remove session. A
TRUE
value indicates that the selected kernel fileset is scheduled for
a kernel build and that changes to
/stand/system
are required.
A null value indicates that a kernel build is not scheduled and that
changes to
/stand/system
are not required. The value of this variable is always equal to the value of
SW_SESSION_IS_REBOOT. - SW_SESSION_IS_REBOOT
Indicates whether a reboot is scheduled for a fileset selected for
removal. Because all HP-UX kernel filesets are also reboot filesets,
the values of this variables is always equal to the value of
SW_SESSION_IS_KERNEL. - SW_SESSION_IS_UPDATE
A value of
1
indicates the SD command was invoked by the
update-ux
command during an Operating System update.
This variable is set by the
update-ux
command. - SW_SYSTEM_FILE_PATH
The path to the kernel's system file. The
default value is
/stand/system.
SignalsThe
swinstall
and
swcopy
commands catch the signals SIGQUIT, SIGINT, and SIGUSR1. If
these signals are received, the command prints a message, sends a
Remote Procedure Call (RPC) to the agents to wrap up after completion,
and then exits. The agent ignores SIGHUP, SIGINT, and SIGQUIT. It immediately exits
gracefully after receiving SIGTERM, SIGUSR1, or SIGUSR2. Killing the
agent may leave corrupt software on the system, and thus should only
be done if absolutely necessary. Note that when an SD command is
killed, the agent does not terminate until completing the task in
progress. The daemon ignores SIGHUP, SIGINT and SIGQUIT. It immediately exits
gracefully after receiving SIGTERM and SIGUSR2. After receiving
SIGUSR1, it waits for completion of a copy or remove from a depot
session before exiting, so that it can register or unregister depots
if necessary. Requests to start new sessions are refused during this wait. LockingSD commands use a common locking mechanism for reading and modifying
the Installed Products Database (IPD) and software depots. This mechanism
allows multiple readers but only one writer on an IPD or depot: Write Locksswinstall
commands that modify the IPD are restricted from simultaneous
modification using
fcntl(2)
locking on the file
<IPD location>/swlock
(e.g.
/var/adm/sw/products/swlock). swcopy
commands that modify a software depot are restricted from
simultaneous modification using
fcntl(2)
locking on the file
<depot directory>/catalog/swlock
(e.g.
/var/spool/sw/catalog/swlock). Read LocksBoth
swinstall
and
swcopy
commands set
fcntl(2)
read locks on source depots using the
swlock
file mentioned above.
When a read lock is set, it prevents all SD commands from performing
modifications (i.e. from setting write locks). Terminal SupportFor in-depth information about terminal support refer to:
The
Software Distributor Administration Guide
manual Start the GUI or TUI, select the
Help
menu, then select the
Keyboard...
option to access the
Keyboard Reference Guide.
RETURN VALUESAn interactive
swinstall
or
swcopy
session always returns 0.
A non-interactive
swinstall
or
swcopy
session returns:
- 0
The
software_selections
were successfully installed/copied. - 1
The install/copy operation failed on
all
target_selections. - 2
The install/copy operation failed on
some
target_selections.
DIAGNOSTICSThe
swinstall
and
swcopy
commands write to stdout, stderr, and to specific logfiles. Standard OutputAn interactive
swinstall
or
swcopy
session does not write to stdout.
A non-interactive
swinstall
or
swcopy
session writes messages for significant events.
These include:
a begin and end session message, selection, analysis, and execution task messages for each
target_selection.
Standard ErrorAn interactive
swinstall
or
swcopy
session does not write to stderr.
A non-interactive
swinstall
or
swcopy
session writes messages for all WARNING and ERROR
conditions to stderr. LoggingBoth interactive and non-interactive
swinstall
and
swcopy
sessions log summary events at the host where the command was invoked.
They log detailed events to the
swagent
logfile associated with each
target_selection.
- Command Log
The
swinstall
and
swcopy
commands log all stdout and stderr messages to the the logfile
/var/adm/sw/swinstall.log
(/var/adm/sw/swcopy.log).
Similar messages are logged by an interactive
swinstall
and
swcopy
session.
The user can specify a different logfile by
modifying the
logfile
option. - Target Log
A
swagent
process performs the actual install or copy operation at each
target_selection.
For install tasks,
the
swagent
logs messages to the file
var/adm/sw/swagent.log
beneath the root directory (e.g.
/
or an alternate root directory).
For copy tasks,
the
swagent
logs messages to the file
swagent.log
beneath the depot directory (e.g.
/var/spool/sw). You can view the command and target log files with the
swjob
or
sd
command. - Source Depot Audit Log
If both source and target machine are updated to SD revision B.11.00
or later, the system administrator at the source depot machine can
track
which
user pulls
which
software from a depot on the source machine and
when
the software is pulled. (Note that a user running
swinstall/swcopy
from a target machine cannot set this option; only the administrator
of the source depot machine can set it. See the
source_depot_audit
option in the
swagent(1M)
man page.)
swagentd DisabledIf the
swagentd
daemon has been disabled on the host, it can be enabled
by the host's system administrator by setting the
SW_ENABLE_SWAGENTD
entry in
/etc/rc.config.d/swconfig
to
1
and executing
/usr/sbin/swagentd -r. EXAMPLESswinstallTo invoke an interactive session of
swinstall:
Select the C and Pascal products from the network source software server
(sw_server) and start an interactive session:
swinstall -i -s sw_server cc pascal Install the C and Pascal products to a set of remote hosts:
swinstall -s sw_server cc pascal @ hostA hostB hostC Update the HP Omniback product from a CD-ROM mounted at
/cd:
swinstall -s /cd/swmedia Omniback Install an incompatible version of HP Omniback into the directory
/exports: swinstall -x allow_incompatible=true -s/products Omniback,a=arch \
@ /exports Install all products from the cartridge tape
/dev/rmt/0:
swinstall -s /dev/rmt/0 \* Reinstall the
software_selections
listed in the file
/tmp/install.products
on the hosts listed in the file
tmp/install.hosts: swinstall -x reinstall=true -f/tmp/install.products \
-t/tmp/install.hosts Execute
swinstall
interactively using the session file
/tmp/case.selections
as a basis:
swinstall -i -S /tmp/case.selections Install all the software from local depot
/tmp/sample.depot.1,
using any response files generated by request scripts:
swinstall -s /tmp/sample.depot.1 -x ask=true \* Install
Product1
from remote depot
/tmp/sample.depot.1
on host
swposix
and use an existing response file (previously generated by the
swask
command) located in
/tmp/bar.depot:
swinstall -s swposix:/tmp/sample.depot.1 -c /tmp/bar.depot Product1 Install all products in remote depot
/tmp/sample.depot.1
on host
swposix,
use any response files generated by request scripts, create catalog
/tmp/bar.depot
and copy all response files to the new catalog: swinstall -s swposix:/tmp/sample.depot.1 -c /tmp/bar.depot \
-x ask=true \* Install all products in remote depot
/tmp/sample.depot.1 on host
swposix,
use response files, run request scripts only when a response file is absent,
create catalog
/tmp/bar.depot
and copy all response files to the new catalog: swinstall -s swposix:/tmp/sample.depot.1 -c swposix:/tmp/bar.depot \
-x ask=as_needed \* Install all patches in the depot that correspond to currently
installed software and are of the
critical
category: swinstall -s /tmp/sample.depot.1 -x patch_match_target=true \
-x patch_filter=\"*.*, c=critical\" The following example applies to HP-UX 10.X only.
To
linkinstall
the product TEST to the clients
clientA, clientB
from the server:
swinstall -l -r -s :OS_700 TEST @ clientA clientB The following example applies to HP-UX 10.X only.
To
linkinstall
product TEST2 to your own "/" directory from an application
server on "serve":
swinstall -l -s serve TEST2 swcopyInvoke an interactive session of
swcopy:
Invoke an interactive session, using default depot at hostX as the source:
Copy all products from the cartridge tape
/dev/rmt/0m
to the default depot on the local host:
Load the
software_selections
listed in the file
/tmp/load.products
using the default source/depot:
swcopy -f /tmp/load.products Copy the C and Pascal products to some local and remote depots:
swcopy -s sw_server cc pascal @ /var/spool/sw hostA:/tmp/sw hostB
FILES- $HOME/.swdefaults
Contains the user-specific default values for some or all SD
options. If this file does not exist, SD looks for user-specific
defaults in
$HOME/.swdefaults.hosts. - $HOME/.sw/defaults.hosts
Contains the user-specific default list of hosts to manage. - $HOME/.sw/defaults.patchfilters
Contains the user-specific default list of patch filters. - $HOME/.sw/sessions/
Contains session files automatically saved by the SD commands or
explicitly saved by the user. - /usr/lib/sw/sys.defaults
Contains the master list of current SD options with their default values. - /var/adm/sw/
The directory which contains all of the configurable
and non-configurable data for SD.
This directory is also the default location of logfiles. - /var/adm/sw/defaults
Contains the active system-wide default values for some or all SD options. - /var/adm/sw/defaults.hosts
Contains the system-wide default list of hosts to manage. - /var/adm/sw/defaults.patchfilters
Contains the system-wide default list of patch filters. - /var/adm/sw/getdate.templ
Contains the set of date/time templates used when scheduling jobs. - /var/adm/sw/products/
The Installed Products Database (IPD), a catalog of all products
installed on a system. - /var/adm/sw/queue/
The directory which contains the information about all active and complete
install jobs, copy jobs, and other jobs initiated by the SD commands. - /var/spool/sw/
The default location of a source and target software depot.
AUTHORswinstall
and
swcopy
were developed by the Hewlett-Packard Company and Mark H. Colburn (see
pax(1)). SEE ALSOswacl(1M),
swagentd(1M),
swask(1M),
swconfig(1M),
swjob(1M),
swlist(1M),
swmodify(1M),
swpackage(1M),
swreg(1M),
swremove(1M),
swverify(1M),
update-ux(1M)
on
11i,
sd(4),
swpackage(4),
sd(5). Software Distributor Administration Guide,
available at
http://docs.hp.com. SD customer web site at
http://docs.hp.com/en/SD/.
|