 |
» |
|
|
|
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 swinstall's
Execution Phase. 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
a product's filesets. 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 swinstall's Load
phase. 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. 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.
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. 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. 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: 10.30 $
########
#
# (c) Copyright MyCompany, 2001
#
######## |
Printable version
