Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Software Distributor Administration Guide: HP-UX 11i v1, 11i v2, and 11i v3 > Chapter 11 Using Control Scripts

Introduction to Control Scripts

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

SD-UX supports execution of both product and fileset control scripts. These shell scripts allow you to perform additional, customized checks and operations as part your regular software management tasks. The swinstall, swconfig, swverify, swask, and swremove commands can execute one or more of these scripts. Control scripts are usually supplied by software vendors, but you can write your own. All control scripts are optional.

Product level control scripts are run when any fileset within that product is selected for installation, configuration, verification, or removal so the activities in product control scripts must pertain to all filesets in that product, but not to any fileset in particular. Actions you want to apply to every fileset in a product should be in the appropriate product level control script.

Fileset scripts must pertain only to the installation, configuration, or removal of that fileset, and not to any other fileset or to a parent product.

Control scripts can perform a wide variety of customization and configuration tasks, such as (but not limited to):

  • Verifying if someone is actively using the product and, if so, preventing reinstallation, update or removal.

  • Ensuring the local host system is compatible with the software (scripts can check beyond the compatibility enforced by the product’s uname attributes).

  • Removing obsolete files or previously installed versions of the product.

  • Creating links to, or additional copies of, files after they have been installed.

  • Copying configurable files into place on first-time installation.

  • Conditionally copying configurable files into place on later updates.

  • Modifying existing configuration files for new features.

  • Rebuilding custom versions of configuration files.

  • Creating device files or custom programs.

  • Killing and/or starting daemons.

Types of Control Scripts

Here are the control scripts that SD-UX supports:

  • Checkinstall Script

    This script is run by swinstall during its Analysis phase to insure that the installation (and configuration) can be attempted. For example, the OS run state, running processes, or other prerequisite conditions beyond dependencies could be checked. It should not change the state of the system.

    A checkinstall script’s chief merit is its ability to detect if the system contains a hardware configuration that might lead to catastrophe - an unbootable system or file system corruption - if the installation of the selected software was allowed to proceed. It also acts as the test for conflicts with other software selections or with software already installed.

  • Preinstall Script

    This script is run by swinstall before loading the software files. For example, this script could remove obsolete files, or move an existing file aside during an update.

    A preinstall script is called during the Execution Phase of the swinstall command. The preinstall script for each file is executed just before that fileset’s files are installed onto the target system. A product level preinstall script is called before the filesets in the product.

    Preinstall scripts for all kernel filesets and their prerequisites are all run before the kernel build takes place. If the kernel build fails and swinstall exits, the preinstall scripts are removed from the system. Product level preinstall scripts are invoked twice for all products that contain kernel filesets: once when the kernel filesets are their prerequisites are installed; a second time when the remaining filesets are installed.

  • Postinstall Script

    This script is run by swinstall after loading the software files. For example, this script could move a default file into place.

    The postinstall script is part of the Load phase of the swinstall command. After the files are loaded, the fileset’s postinstall script is run. Then, the products’s postinstall script (if any) is run.

  • Unpreinstall Script

    Unpreinstall scripts are executed during the load phase of swinstall if recovery is initiated.

    All undo scripts are executed in the reverse order of the normal scripts. For each fileset being recovered, the unpostinstall script is run, the fileset files are restored, and the unpreinstall script is run. An undo script is executed if its corresponding script was executed.

    An unpreinstall script should undo any operation that the preinstall script did. For example, if the preinstall script moved a file, the unpreinstall script should move it back. If the preinstall script copied a file, the unpreinstall script should remove it.

    For a product to be recoverable, no files should be removed by preinstall or postinstall scripts. Configure scripts are a good place to remove obsolete files.

    A product unpreinstall script is run after the fileset unpreinstall scripts.

  • Unpostinstall Script

    Unpostinstall scripts are executed during the load phase of swinstall if recovery is initiated.

    All undo scripts are executed in the reverse order of the normal scripts. An undo script is executed if its corresponding script was executed.

    An unpostinstall script should undo any operation that the postinstall script did. For example, if the postinstall script moved a file, the unpostinstall script should move it back. If the postinstall script copied a file, the unpostinstall script should remove it.

    For a product to be recoverable, no files should be removed by preinstall or postinstall scripts. Configure scripts are a good place to remove obsolete files.

    NOTE: Product level unpostinstall scripts are not supported.
  • Configure Script

    This script is run by swinstall or by swconfig to configure the host for the software, or configure the software for host-specific information. For example, this script could change a host’s specific configuration file such as /etc/services, add the host name or other host resources such as available printers to its own configuration file, or perform compilations.

    Configure scripts are run by swinstall for all products (in prerequisite order) after the products have completed the Load phase. However, they are only run when installing to a system that will actually be using the software. They are deferred when installing to an alternate root (for example, for diskless or building test file systems) and run instead by the swconfig command when the alternate root is now the root of the system using the software.

    The swconfig command can also be used to rerun configure scripts that failed during a normal install. A successful execution of the configure step (whether there is a script or not) moves the software from the installed state to the configured or ready-to-use state. Configure scripts (and all others) must be able to be run many times (that is, they must be re-executable).

    Configure scripts are a good place to remove obsolete files.

    Configure scripts are not run for installations to alternate roots.

  • Verify Script

    Verify scripts are run by the swverify command any time after the software has been installed and configured. Like other scripts, they are intended to verify anything that the SD-UX software management tools do not verify by default. For example, this script could check to see that the software is configured properly and that you have a proper license to use it.

  • Fix Script

    Defines the fix script run by swverify to correct and report problems on installed software. The fix script can create missing directories, correct file modifications (mode, owner, group, major, and minor), and recreate symbolic links.

  • Unconfigure Script

    A script run by swconfig or swremove to undo a host or software configuration originally performed by a configure script. For example, an unconfigure script could remove the configuration from the /etc/services file. (The unconfigure task moves the software from the configured state back to the installed state.)

    Only the swremove command actually removes software, although you can run unconfigure scripts using swconfig. Unconfigure scripts are not run for removals from alternate roots.

  • Checkremove Scripts

    The checkremove script is run by swremove during the remove analysis phase to allow any checks before the software is permanently removed. For example, the script could check whether anyone was currently using the software before removing it.

  • Preremove Scripts

    This script is executed just before removing files. It can be destructive to the application because files will be removed next. It could remove files that the postinstall script created. For example, a preremove script could save a specific fileset to another location before removing the rest of the filesets in the product.

    This script and the postremove script are part of the Remove phase of swremove. Within each product, preremove scripts are run (in the reverse order dictated by any prerequisites), files are removed, then all postremove scripts are run.

  • Postremove Scripts

    This script is executed just after removing files. It is the companion script to the postinstall script. For example, if this was a patch fileset, then the preinstall script could move the original file aside, and this postremove script could move the original file back if the patch was removed.

  • Request Scripts

    This interactive script requests a response from the user as part of software installation or configuration. 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.

  • Other Scripts

    You can include other control scripts, such as a subscript that is sourced by the above scripts. The location of the control scripts is passed to all scripts via the SW_CONTROL_DIRECTORY environment variable, and are denoted by the keyword control_file within the PSF.

Space Files

The space control file is not a script. It lets you define additional disk space requirements for the filesets and notes positive disk space impact on any directory or file that results from the actions of control scripts.

Each fileset or product may contain a space file. The space file lists a path and a byte size for each path. For example:

/tmp/space_dummy1 2000 /opt/space_dummy2 2000 /tmp/space_dummy3 3000 /mydir/ 4000

For each directory or file path listed in the space file, swinstall adds the size in bytes to the disk space requirements. The size reflects the maximum transient or permanent disk space required for the install.

Script Interpreter

By default, SD interprets scripts with a POSIX shell (sh). You can specify other script interpreters in two ways.

First, any control script can define an interpreter in the first line of the script.

Second, you can use the interpreter keyword to define a different interpreter for specific scripts. The syntax is:

interpreter interpreter_name

For example:

control_file source scripts   tag    checkinstall interpreter  ksh

SD checks that the interpreter is available. If the interpreter is not available, the script fails. (To avoid this problem, you can use a checkinstall script to verify the existence of any script interpreters that you specify.) If SD finds the interpreter, it processes the script normally using the interpreter that you specified.

Control Script Format

A control script should be a shell script (as opposed to a binary) and written to be interpreted by the Posix.2 shell /sbin/sh. Korn shell (formerly /bin/ksh) syntax is acceptable to the Posix.2 shell. A script written for csh is not supported.

The script should have a simple header similar to the example below. Included in the header should also be comment lines which state the product and fileset to which the script belongs, the name of the script, the revision string as required by the what(1) command, and a simple copyright statement.

#! /sbin/sh ######## # Product: <PRODUCT> # Fileset: <FILESET> # configure # @(#) $Revision: 1.1 $ ######## # # (c) Copyright MyCompany, 2001 # ########
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1997, 2000-2003, 2006, 2007, 2008 Hewlett-Packard Development Company, L.P.