|
» |
|
|
|
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. 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: 1.1 $
########
#
# (c) Copyright MyCompany, 2001
#
########
|
|