Execution of Control Scripts

The agent runs as the superuser, therefore control scripts are always executed as the superuser. Use appropriate caution.

Control scripts are only executed for software being installed, removed or verified in the primary root (“/”) or an alternate root directory. Scripts are never executed for software in a depot.

Each script must set its own PATH variable, using SW_PATH.

Neither swinstall nor swremove require that the system be shut down. Control scripts must work correctly on both quiet single-user systems and active multi-user systems. They must deal properly with unremovable running programs. They might have to shut down or start up processes that they own themselves to succeed.

Control scripts can be re-executed. If a script is run more than once, it should produce the same results each time. The second execution should not produce any error messages or leave the system in a state different than before it was run.

A script should be executable after its fileset was loaded without damaging the new fileset with which it is associated.

For example, if you must copy a file from under /usr/newconfig to another location, use the cpio -p command to copy it rather than the cp command to move it, or check for the absence of the /usr/newconfig version before attempting the move. (The cpio(1) command may be preferred over cp(1) because cpio copies the mode, owner, and group permissions.)

Control scripts can exit with one of the following return values:

All messages produced by control scripts are redirected to the agent logfile.

The set of control scripts executed during a particular phase of a task are always executed in prerequisite order the scripts of each prerequisite product/fileset are executed before the script of the dependent fileset.

All control scripts are readable by any other control script.

Checkinstall scripts are executed during the Analysis phase of a swinstall session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}checkinstall

A checkinstall script must not modify the system.

A checkinstall script determines whether the product/fileset can be installed by performing checks beyond those performed by swinstall. Example checks include checking to see if the product/fileset is actively in use, or checking that the system run-level is appropriate.

If you are using a request script as part of the install, the checkinstall script should:

If the checkinstall script fails, the fileset will not be installed. The interactive interface of swinstall will notify you that the checkinstall script has failed. Then you can: diagnose the problem, fix it and re-execute the analysis phase; or unselect the product/fileset. The non-interactive interface tells you about each individual checkinstall failure and the filesets are not installed.

A checkinstall script is executed for installations into the primary root (“/”) or an alternate root. Since most of the actions of this script will involve checking the current conditions of a running system (that is, the primary root), it may not need to perform any actions when the product/fileset is being installed into an alternate root.

Preinstall scripts are executed during the Load phase of a swinstall session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}preinstall

The preinstall script for a product is executed immediately before the fileset’s files are installed.

A preinstall script should perform specific tasks preparatory to the files being installed. The swinstall session will proceed with installing the files regardless of the return value from a preinstall script. Example actions include removing obsolete files (in an update scenario).

A preinstall script is executed for installations into the primary root (“/”) or an alternate root. The scope of actions of a preinstall script should be within the product itself (that is, the files within the product’s directory).

Postinstall scripts are executed during the Load phase of a swinstall session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}postinstall

The postinstall script for a product is executed immediately after the fileset’s files are installed.

A postinstall script should perform specific tasks related to the files just installed. The swinstall session will proceed with the remainder of the session (for example, configuration) regardless of the return value from a postinstall script. Example actions include adding a kernel driver to the system file or moving a file from under /usr/newconfig to its correct place in the file system.

A postinstall script is executed for installations into the primary root (“/”) or an alternate root. The scope of actions of a postinstall script should be within the product itself (that is, the files within the product’s directory).

The customization or configuration tasks that must be performed to enable the product/fileset for general use should not be done in the postinstall script, but the configure script (described below).

Configure scripts are executed during the Configuration phase of a swinstall session. SD expects configure scripts at system start-up if the swinstall session triggers a system reboot. The swconfig command can also execute configure scripts. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}configure

A configure script is only executed for installations into the primary root (“/”). If you choose to defer configuration in the swinstall session, then the configure script will be executed by a swconfig session at some time after the installation completes.

A configure script is usually executed only when the product/fileset is in the installed state.

A configure script is the primary way to move a product/fileset from the installed state to the configured state. The script should perform all (or most of) the activities needed to enable the product/fileset for use.

A configure script can use configuration information provided by the user and collected by a request script.

When an existing version of a product is updated to a new version, the configure script(s) for the new version must perform any unconfigurations-configurations of the old version that are necessary to properly configure the new version. The unconfigure script(s) for the old version are not executed.

Configure scripts are for architecture-dependent actions because they will always be run on the architecture of the install target.

Configure scripts are the best place for removing files and updating the IPD, since the system is not in transition (i.e. as in an update).

A configure script can help with software updates as well as new installs. The script must also be able to handle reinstallation and should include appropriate error control if data destruction is possible.

Unconfigure scripts are executed during the Unconfiguration-Configuration phase of a swremove session. They can also be executed by the swconfig command. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}unconfigure

An unconfigure script is executed only for software installed into the primary root (“/”).

An unconfigure script is re-executed even when the product/fileset is in the configured state.

An unconfigure script is the primary way to move a product/fileset from the configured state back to the installed state. The script should perform all (or most of) the activities needed to disable the product/fileset for use.

An unconfigure script must undo all configuration tasks performed by its companion configure script. The user should be able to configure, unconfigure, configure, etc. an installed product/fileset and always end up with the same configured result.

Verify scripts are executed by the swverify command. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}verify

A verify script must not modify the system.

A verify script is the primary way to check the configuration tasks performed by a configure script for correctness and completeness.

A verify script is executed for installations into the primary root (“/”) or an alternate root. Since most of the actions of this script will involve checking the current conditions of a configured product/fileset (in the primary root), it may not need to perform any actions for a product/fileset installed into an alternate root directory.

An environment variable, SW_IS_COMPATIBLE, can help a verify script determine if installed software is compatible with the system on which it is installed. See “SW_IS_COMPATIBLE”.

Fix scripts are executed by the swverify command. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}fix

A fix script can be used to correct attribute problems detected by a verify script.

A fix script can create missing directories, correct file modifications (mode, owner, group, major, and minor), and recreate symbolic links.

Checkremove scripts are executed during the Analysis phase of a swremove session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}checkremove

A checkremove script must not modify the system.

A checkremove script determines whether the product/fileset can be removed by performing checks beyond those performed by swremove. Example checks include checking to see if the product/fileset is actively in use.

If the checkremove script fails, no filesets in the product will be removed. The GUI/TUI interface of swremove notifies you that the checkremove script has failed. You can then: diagnose the problem, fix it, and re-execute the analysis phase; unselect the target system(s) in question; or unselect the product/fileset. The command line interface notifies you for each individual checkremove failure, and no filesets in that product are removed.

A checkremove script is executed for installations into the primary root (“/”) or an alternate root. Since most of the actions of this script will involve checking the current conditions of a running system (that is, the primary root), it may not need to perform any actions when the product/fileset is being removed from an alternate root.

Preremove scripts are executed during the Remove phase of a swremove session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}preremove

All preremove scripts for a product are executed immediately before the product’s files are removed.

A preremove script should perform specific tasks preparatory to the files being removed. The swremove session will proceed with removing the files regardless of the return value from a preremove script. Example actions include removing files created in the postinstall script.

A preremove script is executed for installations into the primary root (“/”) or an alternate root. The scope of actions of a preremove script should be within the product itself (that is, the files within the product’s directory).

The de-customization or unconfiguration-configuration tasks which must be performed to disable the product/fileset for general use must not be done in a preremove script, instead they should be done in an unconfigure script (described above).

Postremove scripts are executed during the remove phase of a swremove session. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}postremove

All postremove scripts for a product are executed immediately after the product’s fileset files are removed.

A postremove script should perform specific tasks related to the files just removed. The swremove session will proceed with the remainder of the session regardless of the return value from a postremove script. Example actions include:

A postremove script is executed for installations into the primary root (“/”) and an alternate root. The scope of actions of a postremove script should be within the product itself (that is, the files within the product’s directory).

The de-customization or unconfiguration-configuration tasks which must be performed to disable the product/fileset for general use should not be done in the postremove script, instead they should be done in the unconfigure script (described above).

Request scripts are interactive scripts that request a response from the user as part of software installation or configuration. The pathname of the script being executed is:

$ {SW_CONTROL_DIRECTORY}request

Request scripts write information into a response file for later use by the configure script or other scripts. You can run requests scripts by executing the swask command or using the ask option with swinstall or swconfig after selection and before the analysis phase.

The POSIX default for request scripts is a shell script. The shell script must be able to:

The request script stores the user response in a response file. The path of the response file is accessible by the SW_CONTROL_DIRECTORY environment variable.

The POSIX recommendation for response file format is the SVR4 model of attribute/value pairs. Answers should be written to the response file inenv_var=value format so that the response files can be easily used by other control scripts.

When you use a request script to get install information, HP recommends that you use a checkinstall script to check for proper execution of the request script. The checkinstall script should: