This solution addresses the drawbacks described in the case studies in "Modifying a File Using Standard Classes and Class Action Scripts" and "Modifying a File Using the sed Class and a postinstall Script". Only one short file is needed (beyond the pkginfo and prototype files). The file works with multiple instances of a package since the PKGINST parameter is used, and no postinstall script is required since the init q command can be executed from the build class script.

Case Study Files

The pkginfo File

PKG=case6
NAME=Case Study #6
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=build

The prototype File

i pkginfo
e build /etc/inittab ? ? ?

The Build File

# PKGINST parameter provided by installation service
# remove all entries from the existing table that
# are associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab ||
exit 2
if [ "$1" = install ]
then
# add the following entry to the table
echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" ||
exit 2
fi
/sbin/init q ||
exit 2
exit 0

Modifying crontab Files During Installation

This case study modifies crontab files during package installation.

Techniques

This case study demonstrates the following techniques:

• Using classes and class action scripts

  For more information, see "Writing Class Action Scripts".

• Using the crontab command within a class action script

Approach

The most efficient way to edit more than one file during installation is to define a class and provide a class action script. If you used the build class approach, you would need to deliver one build class script for each crontab file edited. Defining a cron class provides a more general approach. To edit crontab files with this approach, you must:

• Define the crontab files that are to be edited in the prototype file.

  Create an entry in the prototype file for each crontab file that will be edited. Define the class as cron and the file type as e for each file. Use the actual name of the file to be edited.

• Create the crontab files for the package.

  These files contain the information you want added to the existing crontab files of the same name.

• Create an installation class action script for the cron class.

  The sample i.cron script performs the following procedures:

  • Determines the user ID (UID).

    The i.cron script sets the variable user to the base name of the cron class script being processed. That name is the UID. For example, the base name of /var/spool/cron/crontabs/root is root, which is also the UID.

  • Executes crontab using the UID and the -l option.

    Using the -l option tells crontab to send the contents of the crontab file for the defined user to the standard output.

  • Pipes the output of the crontab command to a sed script that removes any previous entries added with this installation technique.

  • Puts the edited output into a temporary file.

  • Adds the data file for the root UID (that was delivered with the package) to the temporary file and adds a tag so you will know where these entries came from.

  • Executes crontab with the same UID and gives it the temporary file as input.

• Create a removal class action script for the cron class.

  The r.cron script is the same as the installation script except there is no procedure to add information to the crontab file.

  These procedures are performed for every file in the cron class.

Case Study Files

The i.cron and r.cron scripts described below are executed by superuser. Editing another user's crontab file as superuser may have unpredictable results. If necessary, change the following entry in each script:

crontab $user < /tmp/$$crontab ||

to

su $user -c "crontab /tmp/$$crontab" ||

The pkginfo Command

PKG=case7
NAME=Case Study #7
CATEGORY=application
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1.0
CLASSES=cron

The prototype File

i pkginfo
i i.cron
i r.cron
e cron /var/spool/cron/crontabs/root ? ? ?
e cron /var/spool/cron/crontabs/sys ? ? ?