Scripts can customize the archive. Use these scripts for the following purposes:
A precreation script validates the archive at creation time and prepares the archive for later customization, especially differential archives. This script also can create a user-defined section in the archive.
A predeployment script validates the archive during installation and prepares the archive for later customization.
A postdeployment script reconfigures a new system image on a clone system.
A reboot script processes a final reconfiguration after the system is rebooted.
For guidelines about creating scripts, see Guidelines for Creating a Custom Script.
To Create a Precreation Script
This script runs during archive creation. The script has various uses.
Validates the contents and the integrity of the software. The script fails the archive creation if the integrity is broken.
Prepares products for later customization on clone system.
Registers other installation scripts dynamically during archive creation.
Adds a message to the flash-creation summary file. The message must be short and record only that scripts were started and finished and the results. You can view the results in the summary section.
Example 3.1. Excerpts From a Precreation Script
The following examples are excerpts from a precreation script.
To log the start time in the summary section, use the following example:
echo "MyApp precreation script started">> $FLASHDIR/summary
To check the software integrity, use the flcheck command. This command cannot be used at the command line. The syntax for this command is as follows:
flcheck software component files and directories
...| -
For example, to validate the files and directories, use the following example:
flcheck software component files and directories
If Not in selection - refuse creation
echo "Myapp Integrity Damage">>$FLASHDIR/summary
Or, to keep new files and directories that are unexpected and not fail the archive creation, use the following example:
flchecksoftware component files and directories
If Not in selection include by force flincludesoftware component
To register deployment scripts and data, use the following example:
Copy the script to the following directory:
cp predeployment script
/etc/flash/predeployment
Or, to register the script dynamically during archive creation, copy the script to the following directory.
cp predeployment script
$FLASHDIR/predeployment
To see application-specific data in a user-defined section, use the following example:
cp custom section
$FLASHDIR/custom_sections/MyApp
To log the success of the installation in the summary section, use the following example:
echo "product one flash preparation started." >>$FLASH_DIR/summary ... echo "product one flash preparation finished successfully">>$FLASH_DIR/summary
Example 3.2. Precreation Script
#!/bin/sh echo "Test precreation script started" >> $FLASH_DIR/summary cat /opt/TestApp/critical_file_list | flcheck - if [ $? != 0 ]; then echo "Test precreation script failure" >> $FLASH_DIR/summary exit 1 if echo "Test precreation script started" >> $FLASH_DIR/summary /opt/TestApplication/license_cloning $FLASH_DIR/predeployment/.TestApplicationLicenceTransfer \ $FLASH_DIR/custom_sections/TestApplicationLicenceCounter echo "Test precreation script finished" >> $FLASH_DIR/summary exit 0
A precreation script can create a user-defined section in the archive to provide
specific application information. This section is intended for archive maintenance.
The script must be put in the $FLASH_DIR/sections
directory.
The Solaris Flash archive does not process a user-defined section. For example,
a section could contain a description of the archive or perhaps a script to check
the integrity of an application.
A user-defined section requires the following format.
Must be line oriented
Must terminate with newline (ASCII 0x0a) characters
Can have unlimited length of individual lines
Must encode binary data by using base64 or a similar algorithm
To Create a Predeployment Script
This script is run before the installation of the archive. If the script is meant to validate the archive, it is kept in the archive. If the script is meant to preserve local configurations on the clone system, it is kept on the clone system. This script also can analyze and collect local data necessary for later customization. For example, client-specific information can be saved before being overwitten by files about to be extracted. This information can then be used in the final stage after extraction.
Create the predeployment script. Follow the guidelines that are described in Guidelines for Creating a Custom Script.
Store the script in one of the following directories.
For archive validation, store in the /etc/flash/predeployment
directory.
If you are referencing with a precreation script, store in the $FLASH_DIR/preinstall
directory.
If you are preserving configurations on a clone system, provide the
path to the script that is stored on the clone system with the local_customization
keyword in the JumpStart profile.
Example 3.3. Predeployment Script
#!/bin/sh $FLASH_DIR/TestApplication/check_hardware if [ $? != 0 ]; then echo Unsupported hardware exit 1 fi $FLASH_DIR/TestApplication/check_licence_key if [ $? != 0 ]; then echo No license for this host exit 1 fi $FLASH_DIR/TestApplication/deploy_license_key \ $FLASH_DIR/TestApplication/.TestApplicationLicenceTransfer $FLASH_DIR/TestApplication/save_data_files $FLASH_DIR/flash exit 0
To Create a Postdeployment Script
This script is kept in the archive or stored in a local directory on the clone system and runs after installation. The script reconfigures a new system image on a clone system. If the script is stored in the archive, the changes affect all the clone systems. If the script is stored in a local directory on the clone system, the changes affect only the clone system. For example, client-specific information that is saved by a predeployment script can be applied to the clone environment, completing the installation.
Postdeployment scripts can also be used to clean up files after the archive
is installed. For example, log files such as those files in /var/adm
can
be cleaned out.
Not all log files need a script for cleanup. Log files in /var/tmp
can be excluded when the archive is created.
Create the postdeployment script. Follow the guidelines that are described in Guidelines for Creating a Custom Script.
Store the script in one of the following directories.
To affect all clone systems, store the script in the /etc/flash/postdeployment
directory.
To affect only a local clone system, provide the path to the script
that is stored on the clone system with the local_customization
keyword
in the JumpStart profile.
To Create a Reboot Script
This script is kept in the archive and runs after the system is rebooted. The script does any final configuration after system reconfiguration.
After you install the Solaris Flash archive on a clone system, some host-specific
files are deleted and are re-created for the clone machine. The installation program
uses the sys-unconfig(1M) command and the sysidtool(1M)
programs to delete and re-create host-specific network configuration files. The files
that are re-created include, for example, /etc/hosts
, /etc/defaultrouter
, and /etc/defaultdomain
. You can
use the reboot script for any final reconfiguration.