Chapter 7 Using Optional Custom JumpStart Features

This chapter describes the optional features that are available to create additional custom JumpStart installation tools.

• "Creating Begin Scripts"

• "Creating Finish Scripts"

• "SPARC: Creating Disk Configuration Files"

• "IA: Creating Disk Configuration Files"

• "Using a Site-Specific Installation Program"

• "Custom JumpStart Environment Variables"

Instructions in this chapter are valid for either a SPARC or IA server that is being used to provide custom JumpStart files (called a profile server). A profile server can provide custom JumpStart files for different platform types. For example, a SPARC server can provide custom JumpStart files for both SPARC and IA based 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 a system. You can use begin scripts only when using custom JumpStart to install Solaris.

Possible Uses of Begin Scripts

• Creating derived profiles

• Backing up files before upgrading

Important Information 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 JumpStart cannot mount the file systems onto /a, an error occurs and installation fails.

• Output from the begin script is deposited in /var/sadm/begin.log.

• Ensure that root owns the begin script and that its permissions are set to 644.

Creating Derived Profiles With a Begin Script

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 might need to use derived profiles for identical system models that have different hardware components (for example, systems that contain 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 creates a derived profile depending on the system on which you intend to install Solaris.

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 can write a begin script to create different derived profiles depending on the evaluation of rules.

#!/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.

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 a system, but before the system reboots. You can use finish scripts only when using custom JumpStart to install Solaris.

Possible Uses of Finish Scripts

• Adding files

• Adding individual packages or patches in addition to the ones installed in a particular software group

• Customizing the root environment

• Setting the system's root password

Important Information About Finish Scripts

• The Solaris 8 Interactive 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 is deposited in /var/sadm/finish.log.

• Ensure that root owns the finish script and that its permissions are set to 644.

Adding Files With a Finish Script

Through a finish script, you can add files from the JumpStart directory to an 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).

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:

To Add Files With a Finish Script

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 line in a finish script copies site_prog from the JumpStart directory into a system's /usr/bin directory during a custom JumpStart installation:

cp ${SI_CONFIG_DIR}/site_prog  /a/usr/bin

Adding Packages or Patches With a Finish Script

You can create a finish script to automatically add packages or patches after Solaris is installed on a system. Adding packages in this way not only saves time, but ensures consistency in what packages and patches are installed on different systems at your site.

When using the pkgadd(1M) or patchadd(1M) commands in your finish scripts, use the -R option to specify /a as the root path.

Example 7-1 shows an example of a finish script that adds packages.

Example 7-1 Adding Packages With a Finish Script

	#!/bin/sh
 
  BASE=/a
  MNT=/a/mnt
  ADMIN_FILE=/a/tmp/admin
 
  mkdir ${MNT}
 [Mounts a directory on a server that contains the package to install.]  mount -f nfs sherlock:/export/package ${MNT}
 [Creates a temporary package administration file, admin, to force the pkgadd(1M) command not to perform checks
(and prompt for questions) when installing a package. This enables you to maintain a hands-off installation when you are adding packages.]  cat >${ADMIN_FILE} <<DONT_ASK
  mail=root
  instance=overwrite
  partial=nocheck
  runlevel=nocheck
  idepend=nocheck
  rdepend=nocheck
  space=ask
  setuid=nocheck
  conflict=nocheck
  action=nocheck
  basedir=default
  DONT_ASK
 
 [Adds the package by using the -a option (specifying the package administration file) and the -R option (specifying the root path).]  /usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz
 
  umount ${MNT}
  rmdir ${MNT}

In the past, the chroot(1M) command was used with the pkgadd and patchadd commands in the finish script environment. In the rare instances in which some packages or patches do not work with the -R option, you must create a dummy /etc/mnttab file in the /a root path before issuing the chroot command.

To create a dummy /etc/mnttab file, add the following line to your finish script:

cp /etc/mnttab /a/etc/mnttab

Customizing the Root Environment With a Finish Script

You can also use finish scripts to customize files already installed on a system. For example, the finish script in Example 7-2 customizes the root environment by appending information to the .cshrc file in the root (/) directory.

Example 7-2 Customizing the Root Environment With a Finish Script

#!/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 a System's Root Password With a Finish Script

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

A finish script called set_root_pw in the auto_install_sample directory shows how to avoid this problem by setting the root password automatically, without prompting. set_root_pw is shown in Example 7-3.

Example 7-3 Setting the System's Root Password With a Finish Script

	 #!/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
 [Sets the variable PASSWD to an encrypted root password obtained from an existing entry in a system's /etc/shadow file.]  PASSWD=dKO5IBkSF42lw
	 #create a temporary input file
 [Creates a temporary input file of /a/etc/shadow.]  cp /a/etc/shadow /a/etc/shadow.orig
 
	 mv /a/etc/shadow /a/etc/shadow.orig
 	nawk -F: '{
 [Changes the root entry in the /etc/shadow file for the newly installed system using $PASSWD as the password field.]           if ( $1 == "root" )
           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
 #remove the temporary file
 [Removes the temporary /a/etc/shadow file.]  rm -f /a/etc/shadow.orig
 # set the flag so sysidroot won't prompt for the root password
 [Changes the entry from 0 to a 1 in the state file, so that the user is not 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.]  sed -e 's/0 # root/1 # root/' ${SI_SYS_STATE} > /tmp/state.$$
  mv /tmp/state.$$ ${SI_SYS_STATE}

If you set the system's root password by using a finish script, safeguard against those who might attempt to discover the root password from the encrypted password in your finish script.

SPARC: Creating Disk Configuration Files

This section describes how to create single- and multiple-disk configuration files for a SPARC based system. Disk configuration files enable you to test profiles against different disk configurations before actually installing Solaris software.

SPARC: To Create a Disk Configuration File

Disk configuration files enable you to use pfinstall(1M) from a single system to test profiles against different disk configurations. Follow this procedure to create single- or multiple-disk configuration files:

1. Locate a SPARC based system with a disk you want to test.

2. Become superuser.

3. Create a single disk configuration file by redirecting the output of the prtvtoc(1M) command to a file:

   # prtvtoc /dev/rdsk/device_name >disk_config

   where /dev/rdsk/device_name is the device name of the system's disk (device_name must be in the form cwtxdys2 or cxdys2) and disk_config is the name of the disk configuration file.

4. Do you want to test installing Solaris software on multiple disks?

   • If no, stop, you're done.

   • If yes, concatenate the single disk configuration files together and save the output in a new file:

     # cat disk_file1 disk_file2 >multi_disk_config

     The new file becomes the multiple-disk configuration file. For example:

     # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

5. Are the target numbers in the disk device names unique in the multiple-disk configuration file you created in the previous step?

   • If yes, stop, you're done.

   • If no, open the file with the text editor of your choice and make them unique.

     If, for example, the file contains the same target number (t0) for different disk device names as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map

     Change the second target number to t2, as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map

SPARC: Example

The following example shows how to create a single disk configuration file, 104_test, on a SPARC based system with a 104-Mbyte disk.

You redirect the output of the prtvtoc command to a single disk configuration file named 104_test:

# prtvtoc /dev/rdsk/c0t3d0s2 >104_test

The contents of the 104_test file look like this:

* /dev/rdsk/c0t3d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      72 sectors/track
*      14 tracks/cylinder
*    1008 sectors/cylinder
*    2038 cylinders*    2036 accessible cylinders
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       1      2    00          0     164304   164303   /
       2      5    00          0    2052288  2052287  
       3      0    00     164304     823536   987839   /disk2/b298
       5      0    00     987840     614880  1602719   /install/298/sparc/work
       7      0    00    1602720     449568  2052287   /space

You have completed creating disk configuration files for a SPARC based system. "Testing a Profile" contains information about using disk configuration files to test profiles.

IA: Creating Disk Configuration Files

This section describes how to create single- and multiple-disk configuration files for an Intel 32-bit processor architecture (IA) based system. Disk configuration files enable you to test profiles against different disk configurations before actually installing Solaris software.

IA: To Create a Disk Configuration File

Disk configuration files enable you to use pfinstall(1M) from a single system to test profiles against different disk configurations. Follow this procedure to create single- and multiple-disk configuration files:

1. Locate an IA based system that contains a disk you want to test.

2. Become superuser.

3. Create part of the single disk configuration file by saving the output of the fdisk(1M) command in a file:

   # fdisk -R -W disk_config /dev/rdsk/device_name

   where disk_config is the name of a disk configuration file and /dev/rdsk/device_name is the device name of the fdisk layout of the entire disk. device_name must be in the form cwtxdyp0 or cxdyp0.

4. Append the output of the prtvtoc(1M) command to the disk configuration file:

   # prtvtoc /dev/rdsk/device_name >>disk_config

   where /dev/rdsk/device_name is the device name of the system's disk (device_name must be in the form cwtxdys2 or cxdys2) and disk_config is the name of the disk configuration file.

5. Do you want to test installing Solaris software on multiple disks?

   • If no, stop, you're done.

   • If yes, concatenate the single disk configuration files together and save the output in a new file:

     # cat disk_file1 disk_file2 >multi_disk_config

     The new file becomes the multiple-disk configuration file. For example:

     # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

6. Are the target numbers in the disk device names unique in the multiple-disk configuration file you created in the previous step?

   • If yes, stop, you're done.

   • If no, open the file with the text editor of your choice and make them unique.

     If, for example, the file contains the same target number (t0) for different disk device names as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map

     Change the second target number to t2, as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map

IA: Example

The following example shows how to create a single disk configuration file, 500_test, on an IA based system that contains a 500-Mbyte disk.

First, you save the output of the fdisk command to a file named 500_test:

# fdisk -R -W 500_test /dev/rdsk/c0t0d0p0

The 500_test file looks like this:

 * /dev/rdsk/c0t0d0p0 default fdisk table
* Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
*  HBA Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
* systid:
*  1:    DOSOS12
*  2:    PCIXOS
*  4:    DOSOS16
*  5:    EXTDOS
*  6:    DOSBIG
*  86:   DOSDATA
*  98:   OTHEROS
*  99:   UNIXOS
* 130:   SUNIXOS
*
* Id  Act Bhead Bsect   Bcyl  Ehead  Esect  Ecyl Rsect  Numsect
 130  128 44    3       0     46    30     1001 1410   2050140

Second, you append the output of the prtvtoc command to the 500_test file:

# prtvtoc /dev/rdsk/c0t0d0s2 >>500_test

The 500_test file is now a complete disk configuration file:

* /dev/rdsk/c0t0d0p0 default fdisk table	
* Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
*  HBA Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
* systid:
*  1:    DOSOS12
*  2:    PCIXOS
*  4:    DOSOS16
*  5:    EXTDOS
*  6:    DOSBIG
*  86:   DOSDATA
*  98:   OTHEROS
*  99:   UNIXOS
*  130:  SUNIXOS
*
* Id  Act Bhead Bsect Bcyl  Ehead  Esec  Ecyl Rsect  Numsect
 130  128 44    3     0     46    30    1001 1410   2050140
* /dev/rdsk/c0t0d0s2 partition map
*
* Dimensions:
*      512 bytes/sector
*       94 sectors/track
*       15 tracks/cylinder
*     1110 sectors/cylinder
*     1454 cylinders
*     1452 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*                          First    Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       2      5    01       1410   2045910   2047319
       7      6    00       4230   2043090   2047319  /space
       8      1    01          0      1410     1409
       9      9    01       1410      2820     422987

You have completed creating disk configuration files for an IA based system. "Testing a Profile" contains information about using disk configuration files to test profiles.

Using a Site-Specific Installation Program

You can also use begin and finish scripts to create your own installation program to install Solaris software.

When you specify a minus sign (-) in the profile field, begin and finish scripts control how Solaris software is installed on a system (not the profile and the Solaris 8 Interactive Installation Program).

For example, if the following rule matched a system, the x_install.beg begin script and the x_install.fin finish script install Solaris software on the system named sherlock:

hostname sherlock x_install.beg - x_install.fin

Custom JumpStart Environment Variables

There are several useful environment variables you can use in your begin and finish scripts. For example, a begin script could extract the disk size (SI_DISKSIZES) and install or not install particular packages on a system based on the actual disk size the script extracts.

Information gathered about a system is stored in these environment variables, which are generally set or not, depending on the rule keywords and values you use in the rules file.

For example, information about which operating system is already installed on a system is only available (in SI_INSTALLED) after the installed keyword is used.

Table 7-1 describes these variables and their values.