Solaris Advanced Installation Guide

Chapter 9 Using Optional Custom JumpStart Features

This chapter describes the optional features available for custom JumpStart installations, and is a supplement to Chapter 8, Preparing Custom JumpStart Installations.

Note -

Instructions in this chapter are valid for either an x86 or SPARC 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 could provide custom JumpStart files for both SPARC-- and x86-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 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 upgrading

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 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, 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:

Adding files
Adding packages or patches
Customizing the root environment
Setting the system's root password

This section provides finish script examples for all of these tasks.

Adding Files With a Finish Script

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:

How to Add Files With a Finish Script

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

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 would copy the 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 and Patches

You can create a finish script to automatically add packages and patches after Solaris is installed on a system. This will not only save you time, but it can ensure consistency in what packages and patches are installed on various systems at your site. When using the pkgadd(1M) or patchadd(1M) commands in your finish scripts, you should use the -R option to specify /a as the root path.

Example 9-1 provides an example finish script to add packages.

Example 9-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, patchadd(1M), to force the pkgadd(1M) command not to perform checks (and prompt for questions) when installing a package. This enables you to maintain a hand-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. Although this is not recommended, there may be some packages or patches that will not work with the -R option. In those instances, you must create a fake /etc/mnttab file in the /a root path before using the chroot command. The easiest way to do this is to add the following line to your finish script.

cp /etc/mnttab /a/etc/mnttab

Customizing the Root Environment With a Finish Script

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

Example 9-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 the 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. 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, which is shown in Example 9-3. This allows the initial reboot of the system to be completed without prompting for a root password.

Example 9-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
 [Removes the temporary /a/etc/shadow file.]  #remove the temporary file
  rm -f /a/etc/shadow.orig
 [Changes 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.]  # 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}

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.

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: How to Create Disk Configuration Files

Disk configuration files enable you to use pfinstall from a single system to test profiles against different disk configurations. Follow this procedure to create single-- or multiple-disk configuration files for a SPARC-based system:

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

Become root.

Create a single disk configuration file by redirecting the output of the prtvtoc command to a file:
# prtvtoc /dev/rdsk/device_name > disk_config
/dev/rdsk/device_name

Is the device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2.

disk_config

Is the name of the disk configuration file.

If you want to test installing Solaris software on multiple disks, concatenate single disk configuration files together and save the output to 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

If you've created a multiple-disk configuration file, and the target numbers in the disk device names are not unique, you must edit this file and make them unique.

For example, if you concatenated two disk configuration files together that each had target numbers of t0, you would have to change the second target number to t2 as shown:
* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map

Where to Go Next

You have completed creating disk configuration files for a SPARC-based system. To use disk configuration files to test profiles, see "Testing a Profile".

Example

The following example creates a single disk configuration file, 104_test, on a SPARC-based system with a 104-Mbyte disk.

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

# prtvtoc /dev/rdsk/c0t3d0s2 > 104_test

The 104_test file would 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

x86: Creating Disk Configuration Files

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

x86: How to Create Disk Configuration Files

Disk configuration files enable you to use pfinstall from a single system to test profiles against different disk configurations. Follow this procedure to create single-- and multiple-disk configuration files for an x86-based system:

Locate an x86 based system with a disk that you want to test.

Become root.

Create part of the single disk configuration file by saving the output of the fdisk command to a file:

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

`disk_config`	Is the name of a disk configuration file.
`/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`.

Append the output of the prtvtoc command to the disk configuration file:
# prtvtoc /dev/rdsk/device_name >> disk_config
/dev/rdsk/device_name

Is the device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2.

disk_config

Is the name of the disk configuration file.

If you want to test installing Solaris software on multiple disks, concatenate single disk configuration files together and save the output to 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

If you've created a multiple-disk configuration file, and the target numbers in the disk device names are not unique, you must edit this file and make them unique.

For example, if you concatenated two disk configuration files together that each had target numbers of t0, you would have to change the second target number to t2 as shown:
* /dev/rdsk/c0t0d0p0 default fdisk table ... * /dev/rdsk/c0t2d0p0 default fdisk table

Where to Go Next

You have completed creating disk configuration files for an x86 based system. To use disk configuration files to test profiles, see "Testing a Profile".

Example

The following example creates a single disk configuration file, 500_test, on an x86-based system with a 500-Mbyte disk.

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

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

The 500_test file would look 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 would 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

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

`/dev/rdsk/device_name`	Is the device name of the system's disk. `device_name` must be in the form `cwtxdys2` or `cxdys2`.
`disk_config`	Is the name of the disk configuration file.