 |
» |
|
|
|
The swconfig
command runs only from the command line interface. There is no Graphical
or Terminal User Interface for swconfig. The swconfig
command provides the following features: It configures the host on which the
software will be run. A fileset can include a configure script to
perform these actions on the host. The swconfig
command also allows software to unconfigure the host on which it
no longer will be run. That is, a fileset can include an unconfigure
script that will undo the configuration done by the configure script. The configure and unconfigure scripts are usually run by swinstall and swremove respectively. They
are not run when an alternate root directory is specified. Instead,
the swconfig
command must be used after that software has been made available
to client hosts, to configure those hosts. Similarly, swconfig must be used on
client hosts to unconfigure those hosts. Automatic configuration can also be postponed on software
installed to the root directory /
(for example, when multiple versions are installed), by using the
defer_configure default. It only supports configuration of compatible software,
controllable through the allow_incompatible
default. If a fileset relies on another software product
for proper operation, that software product must be in a CONFIGURED
state and is controlled by the enforce_dependencies
option. swconfig
configures only one version of a fileset at a time, controllable
through the allow_multiple_versions default. By default, when swinstall
installs software relative to the root directory /, it configures
that software (controllable through the defer_configuration
default). Software cannot be configured from an alternate root directory
(that is, the alternate root directory must become some host's root
directory before the software can be configured). A vendor's configure script is as useful for those
operations required for software updates as it is for new installs.
The script must also be able to handle reinstallation and should
attempt to design-in appropriate error control if data destruction
is possible during downdates. swconfig
performs an analysis to see if the requested software exists, is
in the proper state (INSTALLED) and prerequisites are (or can be)
met. swconfig
moves software between INSTALLED and CONFIGURED states.
| | | |  | NOTE: When the swinstall
session includes a reboot fileset (such as when updating the core
HP-UX operating system to a newer release), the configure scripts
are run as part of the system startup processes after the system
reboots. | | | | |
Configuring Software Using the Command Line | |
The syntax for swconfig
is: swconfig [-v] [-u] [-p] [-x option=value] [-f software
file]
[-t target
file] [-X config file]
[-C session
file] [-S session file]
[software
selections] [@ target
selections] |
The -t
target file option applies to the HP
OpenView Software Distributor product. To configure productA, located in the default depot on the
local host, you would type: To unconfigure the software selections in the file
mysoft that are installed in the default
directory on the local host, you would type: To reconfigure the Omniback product using the default
option: swconfig -x reconfigure=true Omniback |
To configure a particular version of Omniback: See “Command Line Software Selections ” in Chapter 2 “Installing and Copying
Software ” for information
about use of the ,r=
version component.
The swconfig
command supports the following options. (Except for the -u option, all swconfig options are a subset
of those for swinstall.) Title not available (Command Options ) - Option
Action - -u
Causes swconfig
to unconfigure the software instead of configuring it. - -p
Preview a configuration task from the command line by running
it through the Analysis Phase and then exiting. You can use this
option with any other options to understand the impact of a command
before the system actually performs the task. - -v
Turn on verbose output to stdout and display all activity
to the screen. Lets you see the results of the command as it executes. - -x
option=value
Specify a value to override
a default value or a value in an options file (see the -X option file
option). See section “Changing Options and Defaults” for more information on changing
defaults. - -f
software file
Read a list of software
selections from a separate file instead of from the command line.
In this software file, blank lines and lines beginning with # (comments)
are ignored. Each software selection must be specified on a separate
line. For an example of a software selection file, see “Command Line Software Selections ” in Chapter 2 “Installing and Copying
Software ”. - -t
target file
Specifies multiple
shared roots on the local host. This option
also applies to the HP OpenView Software Distributor product, which
allows installation to multiple remote hosts (targets). -t reads a list of these
targets from a separate file instead of from the command line. - -X
option file
Specifies a new option file. The default
values for system options are provided in the file /var/adm/sw/defaults.
You can also provide a personal option file, $HOME/.sw/defaults.
This option file overrides those values in the system defaults file.
For a complete listing of system options, see the file /usr/lib/sw/sys.defaults.
This file lists the possible values and behaviors for each option
for each command. See Appendix A “Default Options and Keywords ”
for a complete listing and description of these defaults. - -C
session file
Run the command and save the current
option and operand values to a file for re-use in another session. - -S
session file
Run the command based on values saved
from a previous session.
Changing Options and Defaults | |
In addition to the command-line option listed above, several
command behaviors and policy options can also be changed by editing
extended option and default values found in the defaults file /var/adm/sw/defaults. Values in this file are specified using the command.option=value
syntax. See Appendix A “Default Options and Keywords ”
for a complete listing and description of these defaults. The Configuration Process | |
The configure process also has three phases: A Selection phase in which the local
host resolves the list of software to configure An Analysis phase where the process goes through
analysis to insure that the software selected can be configured
successfully (existence, prerequisites, etc.) A Configure phase (the actual software configuration)
where the configure or unconfigure scripts are executed and the
software's state is changed between INSTALLED and CONFIGURED (or
UNCONFIGURED).
This phase takes place on the local host. The analysis phase
occurs before the loading of files begins and involves executing
checks to determine whether the installation should be attempted.
The load phase cannot be entered if there are any errors from the
analysis phase. | | | | | NOTE: No aspect of the local host's environment is changed
(except where noted) during the analysis phase. Running the "preview"
option (-p) on
these tasks will not have a negative effect. | | | | |
You can run the preview option to see if there are any errors
or warnings. You can also return to the selection phase at this
point and change selections. Errors in the analysis phase will only
exclude those products that had errors in them. If only WARNINGS
occur, the task will continue. The sequential analysis tasks on the host are: Initiate Analysis Process Software Selections Get information from the Installed Product Database and check
for compatibility. The system checks that all software is compatible with the
host's uname
attributes. This check is controlled by the default option allow_incompatible.
If it is set to "false," the system produces an error; if set to
"true," it produces a warning. Check State of Versions Currently Installed If the product is "non-existent" or CORRUPT, the task issues
an error that says the product cannot be configured and to use swinstall to install and
configure this product. If the versions currently installed are not CONFIGURED and
if the -u option
is set (unconfiguring), the system issues a note that the selected
file or fileset is already unconfigured. If the state of versions currently installed is CONFIGURED
(if configuring), the check is affected by the reconfigure option.
A note saying the fileset is already configured and will (reconfigure=true)
or will not (reconfigure=false) be reconfigured
is issued. Check for Configuring a Second Version. This check is controlled by the allow_multiple_versions
option. If it is set to "false," an error is generated stating that
another version of this product is already configured and the fileset
will not be configured. If it is set to "true," the second version
will also be configured. Check States of Dependencies Needed. An error or warning is issued if a dependency cannot be met.
This is controlled by the enforce_dependencies
option. If enforce_dependencies is set
to "true" the fileset will not be configured. If enforce_dependencies
is "false," the fileset will be configured anyway. If the dependency is a prerequisite, the configuration will
likely fail. If the dependency is a corequisite, the configuration of this
fileset will likely succeed, but the product may not be usable until
its corequisite dependency is installed and configured.
Configure Phase | |
The configure phase is entered once the selections have passed
the analysis phase. This takes place on the local host. The sequential relationship between the configure tasks is
shown in the following list. Products are ordered by prerequisite
dependencies if any. Fileset operations are also ordered by any
prerequisites. (Un)configure each product Run each fileset's (un)configure script Update the Installed Product Database to state (INSTALLED
or) CONFIGURED
Executing Configure Scripts | |
In this step, swconfig
executes vendor-supplied configure or unconfigure scripts. The purpose
of configuration is to configure the host for the software and configure
the product for host specific information. For example, software
may need to change the host's .rc
setup, or the default environment set in /etc/profile.
Or you may need to ensure that proper codewords are in place for
that host or do some compilations. Unconfiguration reverses these
steps. The scripts are executed, checking the return values. If an error occurs, the fileset is left in the state INSTALLED.
If a warning occurs, the fileset will still be configured. Scripts are executed in prerequisite order.
Configure scripts must also adhere to specific guidelines.
For example, these scripts are only executed in the context of the
host that the software will be running on, so they are not as restrictive
as customize scripts. However, in a NFS diskless environment, they
need to use file locking on any updates to shared files, as there
may be multiple configure scripts operating at the same time on
these shared files. Configure scripts cannot write to shared locations
such as /usr because they are read-only
on client systems. Configure and unconfigure-configure scripts must
be non-interactive. For more information on scripts, see Appendix B “Control Scripts ”. |
Printable version
