NAME

swconfig - Configure software

SYNOPSIS

No additional rationale is required under this heading.

DESCRIPTION

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 modify the /etc/rc setup file, or the default environment set in /etc/profile. It may need to ensure that proper codewords are in place for that host, or do some compilations. Unconfiguration undoes these steps.

This utility may be used to perform the following tasks:

• Configuring software on target hosts that will actually be running the software

• Configuring independent of the remove and install utilities

• Configuring or unconfiguring hosts that share software from another host where the software is actually installed

• Reconfiguring when configuration failed, was deferred, or needs to be changed

OPTIONS

No additional rationale is required under this heading.

OPERANDS

No additional rationale is required under this heading.

EXTERNAL INFLUENCES

No additional rationale is required under this heading.

EXTERNAL EFFECTS

No additional rationale is required under this heading.

EXTENDED DESCRIPTION

When there is no script, the software is still transitioned to configured by swconfig. The state of the fileset without any configuration requirements is still changed to denote to the users of the software that the software is ready to use. Having one state for both software that requires configuration, and for software that does not, is easier than checking that all software that requires configuration is in the configured state, and that all software that does not require configuration is in the installed state.

If there are not sufficient (or any for that matter) responses in the response file, the configure script can log that further interaction is required and exit with a failure. This can prompt the user to execute the swconfig utility with ask=true.

The request script is executed at the manager role at the end of the selection phase, after the user has specified the software, but before analysis or execution begins on the target roles. The developers of this Software Administration specification considered defining a separate phase between the selection and analysis phases for swconfig and swinstall, but maintained the request steps as part of the selection phase for simplicity.

Reconfiguration may be useful when some system configuration has changed. This may include running with ask=true so the user can input different information.

There is the case where the configure script is not sufficient for configuring the software. If there is another configuration process that needs to be run, then this process should not change the state of the software to configured. After the other process is run, it can change the state to configured using the swmodify utility. There are also situations where there can be multiple configurations of the same installed_software object. This Software Administration specification does not currently address this except by putting the burden on the software to manage the multiple configurations. This Software Administration specification does support the user rerunning the configure script each time a new configuration is needed. Using swconfig -u can likewise interact with the user to unconfigure one, but not all, of the configurations. For both of these cases, if the script exits with return code 3, the software does not transition to the installed (that is, unconfigured) state.

The configure scripts should 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 diskless or NFS 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. The configure and unconfigure scripts need to be noninteractive, but may use the information in the response files generated by the ask script.

For diskless, cold install (initial OS install), and generally building an OS to a separate disk, swconfig can be automatically run after the system reboots to its real host to configure all unconfigured filesets.

This Software Administration specification does not define how file sharing, including diskless machines, should be implemented. However, separable configuration and installation steps provide the basic building blocks.

One possible file sharing solution involves each client having its own installed software catalog from which the shared software can be configured, and the configured state can be recorded. This catalog can be built by "link installing" the software; instead of loading files and running preinstall and postinstall scripts, link each product's files to the client file system. Then, build the catalog information of this linked software as if it were installed and configure the client.

Another possible solution involves each client recording its configured state in a shared installed software catalog. In order to do this, the installed software could maintain a configured_instances attribute to hold a list of configured client names. Each client's configure and unconfigure script could add or delete its name from this list.

These scripts could also control whether the installed software state attribute was changed from installed to configured via swconfig. If configuring, then the reconfigure option would need to be set to true. If unconfiguring, then the unconfigure script could exit with a return code of 3 (exclude) unless the configured_instances attribute was empty so that the installed software state would remain configured.

Update Capabilities

The 1387.2 standard simply runs a configure script during configuration as part of swinstall or as part of a separate swconfig (likewise it runs unconfigure as part of a swremove or as part of a separate swconfig -u).

The following is not covered by 1387.2, and must be performed in control scripts for distributions conformant with 1387.2:

• Removing obsolete files from previous revisions of a fileset (should be currently done in a configure script or a product postinstall and not a fileset postinstall script, due to recovery considerations)

• "User configurable files" (files that are shipped, but that the user can make changes to) can either be shipped in a "new configuration" location and conditionally copied during configure, or they can be shipped in-place but requiring a preinstall script to save off the existing file

• Any merging of existing user information and new software provided information is not supported by the utilities and must be done in a control script

Although the standard does not address file sharing, the separate configure phase is intended to allow multiple clients to run configure after the software has been installed on a file server.

If one version of software is installed and configured, and a newer version is installed in a different location, then swinstall will not automatically configure the second version. The swconfig utility needs to be run separately to:

• Either unconfigure the first version, then rerun to configure the new version

• By setting the allow_multiple_versions option to true, swconfig will attempt to configure the new version while still having the existing version in the configured state

Managing Updates

Recovery steps will account for the remove ("x") file type, so this no longer needs to be done in configure scripts for shared files. Configure scripts still need to manipulate all private files.

For file sharing considerations, files should be determined to be "shared" or "private". In general, all read-only or binary files are considered shared and should be manipulated in the install execution phase (including the preinstall, file loading and postinstall steps). All user modifiable files are considered private should be manipulated in the configuration phase. In particular, prototypes of user modifiable files should be shipped as "shared" prototypes, and then copied or merged to a writable area (in the client's view), during configure.

New files created by the configure script should be added to the installed software catalog using the swmodify utility.

Example:

 

swmodify -x files="newfile" PRODUCT.FILESET

Instead of merging old and new configuration files that may have been modified by users as well, it is better to design a system that is more updatable, such as a directory that contains system provided and user provided information in separate files. This allows newer versions to simply replace the files that they previously supplied.

EXAMPLES

No additional rationale is required under this heading.

EXIT STATUS

No additional rationale is required under this heading.

CONSEQUENCES OF ERRORS

No additional rationale is required under this heading.