The swconfig command runs configuration scripts. Although
swinstall and swremove automatically run configuration or unconfiguration scripts,
swconfig lets you work independently of these commands. This lets
you:
Execute scripts to address problems
if a configuration fails, is deferred, or must be changed.
Explicitly configure, unconfigure or reconfigure
any installed software that has associated configuration scripts.
Configure or unconfigure hosts that share software
located on another host.
Features
and Limitations |
 |
swconfig can execute these kinds of
scripts:
- Configure
Configures installed filesets or products. (Executed by
swconfig and swinstall.)
- Request
Requests an interactive response from the user as part
of the configuration process.
- Unconfigure
Undoes configurations performed by configure scripts.
For example, removing configuration from the host's /etc/profile or /sbin/rc files. This moves the software from the configured state
back to installed.
The swconfig command runs only from the command
line interface.
swconfig configures the host on which the software
will run.
Filesets or products can include configure (unconfigure)
scripts.
swinstall and swremove do not automatically not
run configuration scripts when you specify an alternate root directory
with these commands. You must run swconfig to configure or unconfigure alternate
roots.
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 command option with swinstall or swremove.
By default, swconfig only supports configuration
of compatible software. You can switch this feature on or off with
the allow_incompatible option.
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 option.
swconfig moves software between the installed and
configured states.
swconfig uses dependencies to automatically select
software on which to operate (in addition to any software you specify
directly). See “Software
Dependencies ” for
more information.
|
| |
|
 | NOTE: When a swinstall session includes a reboot fileset (such
as when you update the core HP-UX operating system to a newer release),
the configure scripts are automatically run as part of the system
start-up process after the system reboots. You do not have to run
swconfig to complete the configuration. |
|
| |
|
The
Configuration Process |
|
The configure process has
three phases: selection, analysis, and configuration.
Phase I: Selection
In this phase, swconfig resolves the software selections.
Phase II: Analysis
In this phase, swconfig determines if the software can be
configured successfully (includes checks of software existence,
prerequisites). If you execute swconfig with the -p (preview) option,
the command stops after completing analysis and does not change
anything on the host.
Analysis takes place on the local host. The configuration
phase will not take place if any errors occur during analysis. Errors
in the analysis phase will only exclude those products that had
errors in them. If only warnings occur, the task continues.
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 allow_incompatible command option. 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 (unconfigure) option is set, the system issues a note
that the selected file or fileset is already unconfigured.
If the state of versions currently installed is
configured, the check is affected by the reconfigure option. A note saying the fileset is already configured
and will (reconfigure is true) or will not (reconfigure is false) be reconfigured is issued.
Check for configuring a second version:
If the allow_multiple_versions option 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 the option is set to true,
the second version is also 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
fails.
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.
Phase III: Configuration
In
this phase, the actual software configuration takes place. Configure
or unconfigure scripts are executed and the software state is changed
from installed to configured (or unconfigured).
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 sequence of configuration tasks is shown below. Products
are ordered by prerequisite dependencies, if any. Fileset operations
are also ordered by any prerequisites.
(Un)configure each product.
Run scripts for associated filesets, checking return
values.
If an error occurs, the fileset is left in the installed state.
If a warning occurs, the fileset will still be configured.
Update the IPD to show the proper installed or configured
state.
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 customized scripts. For more information on scripts, see Chapter 11 “Using
Control Scripts ”.
Using
swconfig |
|
Syntax
swconfig [-p] [-u] [-v] [-c catalog] [-C session_file] [-f software_file] [-Q date] [-S session_file] [-t target_file] [-x option=value] [-X option_file]
[software_selections] [@ target_selections]
Options and Operands
- -p
Preview a configuration task by running it through
the Analysis Phase and then exiting.
- -u
Unconfigure the software instead of configuring
it.
- -v
Turn on verbose output to stdout and display all activity to the screen.
- -c catalog
Store copy of a response file or files created by
a request script. See Chapter 11 “Using
Control Scripts ”.
- -C session_file
Run the command and save the current option
and operand values to a session_file for re-use in another session.
See “Session
Files”.
- -f software_file
Read a list of software selections from
a separate file instead of (or in addition to) the command line.
See “Software
Files”.
- -Q date
Schedules a job for the given date when remote operations
are enabled. See “Scheduling
Jobs from the Command Line” and Chapter 6 “Remote
Operations Overview”
- -S session_file
Run the command based on values saved
from a previous installation session, as defined in session_file. See “Session
Files”.
- -t target_file
Read a list of target selections from
a separate file instead of (or in addition to) the command line.
See “Target
Files”.
- -x option=value
Sets a command option to value and overrides default values or a values in options
files. See “Changing Command Options”.
- -X option_file
Read session options and behaviors from option_file. See “Changing Command Options”.
- software_selections
The software objects to be configured.
See “Software
Selections”.
- target_selections
The target of the command. See “Target
Selections”.
Changing Command Options
You
can change the behavior of this command by specifying additional command-line
options when you invoke the command (using the -x option) or by reading predefined values from a
file. The following table shows the options and default values that
apply to swconfig.
Table 2-5 swconfig Command Options and Default Values
admin_directory=/var/adm/sw agent_timeout_minutes=10000 allow_multiple_versions=false autoselect_dependencies=true autoselect_dependents=true enforce_dependencies=true installed_software_catalog=products
| logfile=/var/adm/sw/swconfig.log mount_all_filesystems=true reuse_short_job_numbers=true
|
For More Information
See Appendix A “Command
Options” for
more information about setting options and a complete listing and
description of each option.
Configuration
Tasks and Examples |
|
To configure productA, located in the root on the local host:
swconfig productA
To unconfigure the software selections in the file mysoft that are installed in the default directory on
the local host:
swconfig -u -f mysoft
To reconfigure the Omniback product using the default option
values:
swconfig -x reconfigure=true Omniback
To configure a particular version of Omniback:
swconfig Omniback,r=2.0
To configure the C and Pascal products on the local host:
swconfig cc pascal
To configure Product1, use any associated response files generated by
a request script, and save response files under /tmp/resp1:
swconfig -x ask=true -c /tmp/resp1 Product1
To reconfigure the HP Omniback product:
swconfig -x reconfigure=true Omniback
To configure the version of HP Omniback that was installed
at /opt/Omniback_v2.0:
swconfig Omniback,l=/opt/Omniback_v2.0
To unconfigure the software_selections listed in the file /tmp/install.products on the hosts listed in the file /tmp/install.hosts:
swconfig -u -f /tmp/install.products \
-t /tmp/install.hosts
Printable version
