Overview

This chapter describes the optional features available for custom JumpStart installations, and it is a supplement to Chapter 4, "Preparing Custom JumpStart Installations." You can use the following optional features to enhance and test custom JumpStart installations:

• Begin scripts
• Finish scripts
• pfinstall
• Site-specific installation program

---

Note - This chapter is valid for either an x86 or SPARC server that is being used for custom JumpStart installations. An x86 server can provide custom JumpStart files for SPARC systems and a SPARC system can provide custom JumpStart files for x86 systems.

---

Creating Begin Scripts

What Is a Begin Script

A begin script is a user-defined Bourne shell script, specified within the rules file, that performs tasks before the Solaris software is installed on the system. Begin scripts can be used only with custom JumpStart installations.

Important Information About Begin Scripts

The following information is important to know about begin scripts:

• Be careful that you do not specify something in the script that would prevent the mounting of file systems onto /a during an initial or upgrade installation. If the Solaris installation program cannot mount the file systems onto /a, an error will occur and the installation will fail.
• Output from the begin script goes to /var/sadm/begin.log.
• Begin scripts should be owned by root and have permissions equal to 644.

Ideas for Begin Scripts

You could set up begin scripts to perform the following tasks:

• Creating derived profiles
• Backing up files before upgrade

Creating Derived Profiles With Begin Scripts

A derived profile is a profile that is dynamically created by a begin script during a custom JumpStart installation. Derived profiles are needed when you cannot set up the rules file to match specific systems to a profile (when you need more flexibility than the rules file can provide). For example, you may need to use derived profiles for identical system models that have different hardware components (for example, systems that have different frame buffers).

To set up a rule to use a derived profile, you must:

• Set the profile field to an equal sign (=) instead of a profile.

• Set the begin field to a begin script that will create a derived profile depending on which system is being installed.

When a system matches a rule with the profile field equal to an equal sign (=), the begin script creates the derived profile that is used to install the Solaris software on the system.

An example of a begin script that creates the same derived profile every time is shown below; however, you could add code to this example that would create a different derived profile depending on certain command's output.

#!/bin/sh echo "install_type initial_install" > ${SI_PROFILE} echo "system_type standalone" >> ${SI_PROFILE} echo "partitioning default" >> ${SI_PROFILE} echo "cluster SUNWCprog" >> ${SI_PROFILE} echo "package SUNWman delete" >> ${SI_PROFILE} echo "package SUNWolman delete" >> ${SI_PROFILE} echo "package SUNWxwman delete" >> ${SI_PROFILE}

As shown above, the begin script must use the SI_PROFILE environment variable for the name of the derived profile, which is set to /tmp/install.input by default.

---

Note - If a begin script is used to create a derived profile, make sure there are no errors in it. A derived profile is not verified by the check script, because it is not created until the execution of the begin script.

---

Creating Finish Scripts

What Is a Finish Script

A finish script is a user-defined Bourne shell script, specified within the rules file, that performs tasks after the Solaris software is installed on the system, but before the system reboots. Finish scripts can be used only with custom JumpStart installations.

Important Information About Finish Scripts

The following information is important to know about finish scripts:

• The Solaris installation program mounts the system's file systems onto /a. The file systems remain mounted on /a until the system reboots. Therefore, you can use the finish script to add, change, or remove files from the newly installed file system hierarchy by modifying the file systems respective to /a.
• Output from the finish script goes to /var/sadm/finish.log.
• Finish scripts should be owned by root and have permissions equal to 644.

Ideas for Finish Scripts

You could set up finish scripts to perform the following tasks:

• Installing patches
• Restoring backed up files
• Setting up print servers
• Adding entries to the automount map

The following finish scripts are provided as examples:

• Adding files
• Customizing the root environment
• Setting the system's root password

Adding Files With Finish Scripts

Through a finish script, you can add files from the JumpStart directory to the already installed system. This is possible because the JumpStart directory is mounted on the directory specified by the SI_CONFIG_DIR variable (which is set to /tmp/install_config by default).

---

Note - You can also replace files by copying files from the JumpStart directory to already existing files on the installed system.

---

The following procedure enables you to create a finish script to add files to a system after the Solaris software is installed on it:

1. Copy all the files you want added to the installed system into the JumpStart directory.

2. Insert the following line into the finish script for each file you want copied into the newly installed file system hierarchy.

cp ${SI_CONFIG_DIR}/file_name /a/path_name

For example, assume you have a special application, site_prog, developed for all users at your site. If you place a copy of site_prog into the JumpStart directory, the following finish script would copy the site_prog from the JumpStart directory into a system's /usr/bin directory during a custom JumpStart installation:

#!/bin/sh cp ${SI_CONFIG_DIR}/site_prog /a/usr/bin

Customizing the Root Environment

Through a finish script, you can customize files already installed on the system. For example, the following finish script customizes the root environment by appending information to the .cshrc file in the root directory.

#!/bin/sh # # Customize root's environment # echo "***adding customizations in /.cshrc" test -f a/.cshrc || { cat >> a/.cshrc <<EOF set history=100 savehist=200 filec ignoreeof prompt="\$user@`uname -n`> " alias cp cp -i alias mv mv -i alias rm rm -i alias ls ls -FC alias h history alias c clear unset autologout EOF }

Setting the System's Root Password With Finish Scripts

After Solaris software is installed on a system, the system reboots. Before the boot process is completed, the system prompts for the root password. This means that until someone enters a password, the system cannot finish booting.

The auto_install_sample directory provides a finish script called set_root_pw that sets the root password for you. This allows the initial reboot of the system to be completed without prompting for a root password.

The set_root_pw file is shown below.

#!/bin/sh # # @(#)set_root_pw 1.4 93/12/23 SMI # # This is an example bourne shell script to be run after installation. # It sets the system's root password to the entry defined in PASSWD. # The encrypted password is obtained from an existing root password entry # in /etc/shadow from an installed machine. echo "setting password for root" # set the root password (1) PASSWD=dKO5IBkSF42lw mv /a/etc/shadow /a/etc/shadow.orig nawk -F: '{ if ( $1 == "root" ) (2) printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,passwd,$3,$4,$5,$6,$7,$8,$9 else printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,$2,$3,$4,$5,$6,$7,$8,$9 }' passwd="$PASSWD" /a/etc/shadow.orig > /a/etc/shadow (3) # set the flag so sysidroot won't prompt for the root password sed -e 's/0# root/1# root/' ${SI_SYS_STATE} > /tmp/state.$$ mv /tmp/state.$$ ${SI_SYS_STATE}

There are three main things you must do to set the root password in a finish script.

(1)

Set the variable PASSWD to an encrypted root password obtained from an existing entry in a system's /etc/shadow file.

(2)Change the root entry in the /etc/shadow file for the newly installed system using $PASSWD as the password field.

(3)Change the entry from 0 to a 1 in the state file, so that the user will not be prompted for the root password. The state file is accessed using the variable SI_SYS_STATE, whose value currently is /a/etc/.sysIDtool.state. (To avoid problems with your scripts if this value changes, always reference this file using $SI_SYS_STATE.) The sed command shown here contains a tab character after the 0 and after the 1.

---

Note - If you set your root password by using a finish script, be sure to safeguard against those who will try to discover the root password from the encrypted password in the finish script.

---

Using pfinstall to Test Profiles

Why Use pfinstall

When install_type initial_install is defined in a profile, you can use the pfinstall command to test the profile without actually installing the Solaris software on a system. pfinstall shows the results of how a system would be installed according to the specified profile, before you actually perform a custom JumpStart installation.

---

Note - You cannot use pfinstall to test a profile using the upgrade option (when the initial_type upgrade is defined in a profile).

---

Ways to Use pfinstall

pfinstall enables you to test a profile against:

• The system's disk configuration where pfinstall is being run.
• A disk configuration file that you can create with the prtvtoc command. A disk configuration file is a file that represents a structure of a disk (for example, bytes/sector, flags, slices). Disk configuration files enable you to use pfinstall from a single system to test profiles on different sized disks.

You must run pfinstall on an x86 system to test profiles for x86 systems (using the x86 system's disk configuration or an x86 disk configuration file). Conversely, you must run pfinstall on a SPARC system to test profiles for SPARC systems (using the SPARC system's disk configuration or a SPARC disk configuration file).

· How to Use pfinstall to Test a Profile

Overview - The procedure to use pfinstall to test a profile involves:

• Changing the directory to the JumpStart directory
• Using the pfinstall command to test the profile

Follow this procedure to use pfinstall to test a profile.

1. To test the profile with a specific system memory size, set SYS_MEMSIZE to the specific memory size in Mbytes:

$ SYS_MEMSIZE=memory_size $ export SYS_MEMSIZE

2. Change the directory to the JumpStart directory where the profile resides:

$ cd jumpstart_dir_path

For example, the following command would change the directory to the jumpstart directory on the root file system.

  cd /jumpstart

3. Run the pfinstall -d or pfinstall -D command to test the profile:

$ /usr/sbin/install.d/pfinstall -D | -d disk_config [-c path] profile

In this command,

-D..........Tells pfinstall to use the current system's disk configuration to test the profile against. You must be root to execute pfinstall with the -D option.

-d disk_config	Tells pfinstall to use a disk configuration file, disk_config, to test the profile against.
-c path	Is the path to the Solaris CD. This is required if the Solaris CD is not mounted on /cdrom. (For example, use this option if you copied the Solaris CD image to disk or mounted the Solaris CD on a directory other than /cdrom).
profile	The name of the profile to test.

---

Note - You should run pfinstall on a system running the same version of Solaris software that will be installed by the profile. Otherwise, use pfinstall on the Solaris CD that will be installed by the profile, which is located in the /export/exec/arch.Solaris_2.4/sbin/install.d directory.

---

Run pfinstall from the directory where the profile and disk_config files reside (which should be the JumpStart directory). If the profile or disk_config file is not in the directory where pfinstall is run, you must specify the path.

4. Check to see if the results of pfinstall are as you expected. If not, change the profile and go to Step 3.

You have completed testing the profile. To perform a custom JumpStart installation on a system, see Chapter 9, "Booting and Installing Solaris: Custom JumpStart."

pfinstall Examples

Below are some examples of using pfinstall to test the basic_prof profile against the 104_test disk configuration file:

/usr/sbin/install.d/pfinstall -D basic_prof
/usr/sbin/install.d/pfinstall -d 104_test basic_prof

/usr/sbin/install.d/pfinstall -D -c /export/install basic_prof

· How to Create a Disk Configuration File for a SPARC System

A disk configuration file is a file that represents a structure of a disk (for example, bytes/sector, flags, slices). Disk configuration files enable you to use pfinstall from a single system to test profiles on different sized disks.

Overview - The procedure to create a disk configuration file for a SPARC system involves:

• Locating a SPARC system with a disk that you want to test a profile against
• Using the prtvtoc(1M) command to create the disk configuration file

Follow this procedure to create a disk configuration file.

1. Locate a system with a disk that you want to test a profile against.

2. Determine the device name for the system's disk.

3. Redirect the output of prtvtoc to create the disk configuration file:

$ prtvtoc /dev/rdsk/device_name > disk_config

In this command,

/dev/rdsk/device_nameIs the device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2.

Note: Slice 2 must be specified in device_name.

disk_config........Is the disk configuration file name.

4. Copy the disk configuration file to the JumpStart directory:

$ cp disk_config jumpstart_dir_path

You have completed creating a disk configuration file. The following page provides an example of creating a disk configuration file.

The following example creates a disk configuration file, 104_test, on a system with a 104-Mbyte disk, whose device name is c0t3d0s2.

$ prtvtoc /dev/rdsk/c0t3d0s2 > 104_test

In this example, the 104_test file contains the following information:

# cat 104_test * /dev/rdsk/c0t3d0s2 partition map * * Dimensions: * 512 bytes/sector * 35 sectors/track * 6 tracks/cylinder * 210 sectors/cylinder * 1019 cylinders * 974 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 0 16170 16169 1 3 00 16170 28140 44309 2 5 00 0 204540 204539 6 4 01 44310 160230 204539

· How to Create a Multiple Disk Configuration File for a SPARC System

If you need to test a profile on multiple disks, you can concatenate disk configuration files together to create multiple disk configuration scenarios.

Overview - The procedure to create a multiple disk configuration file for a SPARC system involves:

• Concatenating two or more disk configuration files into one file
• Changing the target numbers of the disks (if needed)

The following procedure creates a disk configuration file to test a profile on two 104-Mbyte disks:

1. Concatenate the 104_test file with itself and save the output to another file:

$ cat 104_test 104_test > dual_104_test

2. Make sure that each disk device name is specified with a different target.

For example, the dual_104_test file is shown as follows:

# cat dual_104_test (1) * /dev/rdsk/c0t3d0s2 partition map * * Dimensions: * 512 bytes/sector * 35 sectors/track * 6 tracks/cylinder * 210 sectors/cylinder * 1019 cylinders * 974 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 0 16170 16169 1 3 00 16170 28140 44309 2 5 00 0 204540 204539 6 4 01 44310 160230 204539 (2) * /dev/rdsk/c0t0d0s2 partition map * * Dimensions: * 512 bytes/sector * 35 sectors/track * 6 tracks/cylinder * 210 sectors/cylinder * 1019 cylinders * 974 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 0 16170 16169 1 3 00 16170 28140 44309 2 5 00 0 204540 204539 6 4 01 44310 160230 204539

This is what was done to the dual_104_test file:

(1)

The first disk device name was not changed.

(2) The second disk device name was changed from /dev/rdsk/c0t3d0s2 to /dev/rdsk/c0t0d0s2. This gives each disk a different target.

You have completed creating a multiple disk configuration file.

Using a Site-Specific Installation Program

Through the use of begin and finish scripts, sites with special requirements can install the Solaris software by creating their own installation program. When a minus sign (-) is specified in the profile field, the begin and finish scripts control how the system is installed, instead of the profile and the Solaris installation program.

For example, if the following rule would match, the x_install.beg begin script and the x_install.fin finish script would install the system named sherlock (the Solaris installation program would not be used):

hostname sherlock x_install.beg - x_install.fin