Configuring Your Installation (swconfig)

The swconfig command lets you explicitly configure, unconfigure and reconfigure software products that are installed on a local host by executing the configure script. These scripts are only executed on the host that will actually be running the software. A fileset can also include an unconfigure script to undo a configuration. For more information on scripts, see Chapter 11 “Using Control Scripts ”

You can use the swinstall and swremove commands to perform many configuration or unconfiguration tasks. However, the swconfig command lets you work independently of these commands. For example, you can configure or unconfigure hosts that share software from another host where the software is actually installed. swconfig can also be useful when a configuration fails, is deferred, or must be changed.

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 start-up processes after the system reboots.

Syntax

The syntax for swconfig is:

swconfig [-p ][-u][-v][-c catalog] [-C session_file] [-f software_file] [-S session file] [-t target_file] [-x option=value] [-X option_file]
[software_selections] [@ target_selections]

Sample Configurations

To configure productA, located in the default depot 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

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

Command Options

The swconfig command supports the following options. (Except for the -u option, all swconfig options are a subset of those for swinstall.)

Option Action

-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.
-u: Causes swconfig to unconfigure the software instead of configuring it.
-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.
-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=as_needed or
-x ask=true). Response files are also stored in the Installed Products Database.
-C session file: Run the command and save the current option and operand values to a file for re-use in another session.
-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 Operands ”.
-S session file: Run the command based on values saved from a previous session.
-t target file: Specifies multiple shared roots on the local host. -t reads a list of these targets from a separate file instead of from the command line.
-u: Causes swconfig to unconfigure the software instead of configuring it.
-v: Turns on verbose output to stdout. (The swconfig log file is not affected by this option.) Verbose output is enabled by default.
-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 Default Options” for more information on changing defaults.
-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/.swdefaults. 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.

Command Operands

The swconfig command supports the standard software_selections syntax. For more details on software selection syntax and an example of a software selection file, see “Software Selections”.

Changing Default Options

In addition to the command-line option listed above, several swconfig behaviors and policy options can also be changed by editing extended option and default values found in the system-wide defaults file: /var/adm/sw/defaults

or in the user-specific defaults file:

$HOME/.swdefaults

Values in these files are specified using the command.option=value syntax. For example:

swconfig.agent_auto_exit=true

Table 3-1 Configuration Default Options

agent_auto_exit=true	logdetail=false
agent_timeout_minutes=10000	logfile=/var/adm/sw/swconfig.log
allow_incompatible=false	loglevel=1
allow_multiple_versions=false	mount_all_filesystems=true
ask=false	reconfigure=false
autoremove_job=false	rpc_binding_info=ncacn_ip_tcp:2121 ncadg_ip_udp:[2121]
autoselect_dependencies=true	rpc_timeout=5
autoselect_dependents=false	select_local=true
controller_source=	software=
enforce_dependencies=true	targets=
job_title=	verbose=1
log_msgid=0	write_remote_files=false

See Appendix A “Default Options and Keywords ” for a complete listing and description of default options.

Using Session Files

Each invocation of the swconfig command defines a configuration session. The invocation options, source information, software selections, and target hosts for this session 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 configuration is automatically saved to the file $HOME/.sw/sessions/swconfig.last. This file is overwritten at each invocation of swconfig.

You can save a session configuration to a specific file by executing swconfig with the -C session_file option.

If you do not specify a specific path for the session file, the default location is $HOME/.sw/sessions/.

To re-execute a session file, specify the session file as the argument for the -S session__file option of swconfig.

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 swconfig take precedence over the values in the session file

Environment Variables

SD programs are affected by external environment variables and environment variables set for use by control scripts. For a description of external environment variables, see Chapter 11, Control Scripts.

Understanding 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 ensure 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).

Selection Phase

For information on how to start a session, specify hosts, select software and specify products see Chapter 2 “Installing and Copying Software ” for complete information.

Analysis Phase

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 (unconfigure), 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 sequence of configure 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 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. With the exception of request scripts, configure and unconfigure scripts must be non-interactive.

For more information on scripts, see Chapter 11 “Using Control Scripts ”.