Trusted Solaris Installation and Configuration

Chapter 9 Using Optional Custom JumpStart Features

This chapter describes the optional features available for custom JumpStart installations, and it is a supplement to Chapter 8, 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

Creating Begin Scripts

A begin script is a user-defined Bourne shell script, specified within the rules file, that performs tasks before the Trusted Solaris software is installed on the workstation. Begin scripts are used 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 installation. If the Trusted 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 task:

Creating derived profiles

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 workstations 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 workstation models that have different hardware components (for example, workstations 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 workstation is being installed.

When a workstation 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 Trusted Solaris software on the workstation.

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

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

Important Information About Finish Scripts

The following information is important to know about finish scripts:

The Trusted Solaris installation program mounts the workstation's file systems onto /a. The file systems remain mounted on /a until the workstation 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:

Rebooting the workstation
Adding files
Customizing the root environment
Setting the workstation's root password

Rebooting the Workstation with a Finish Script

Through a finish script, you can reboot the workstation.

Add the last line in the example finish script to every finish script you create.

#!/bin/sh
/usr/sbin/reboot

Adding Files With Finish Scripts

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

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

Create a Finish Script to Add Files after Installation

Copy all the files you want added to the installed workstation 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, if you are using a custom JumpStart diskette to install Trusted Solaris, place a copy of the site's label_encodings file into the JumpStart directory on the diskette. The following finish script copies the file from the JumpStart directory into a workstation's /etc/security/tsol directory during a custom JumpStart installation:

#!/bin/sh
cp ${SI_CONFIG_DIR}/ label_encodings  /a/etc/security/tsol

Customizing the Root Environment

Through a finish script, you can customize files already installed on the workstation. 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 Trusted Solaris software is installed on a workstation, the workstation reboots. Before the boot process is completed, the workstation prompts for the root password. This means that until someone enters a password, the workstation cannot finish booting.

The jumpstart_sample directory provides a finish script called set_root_pw that sets the root password for you. This allows the initial reboot of the workstation 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 workstation'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
	PASSWD=dKO5IBkSF42lw
	#create a temporary input file
cp /a/etc/shadow /a/etc/shadow.orig

	mv /a/etc/shadow /a/etc/shadow.orig
	nawk -F: '{
		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
	rm -f /a/etc/shadow.orig
	# 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 several things you must do to set the root password in a finish script.

Create a Finish Script to Set the root Password

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

Create a temporary input file of /a/etc/shadow.

Change the root entry in the /etc/shadow file for the newly installed workstation using $PASSWD as the password field.

Remove the temporary /a/etc/shadow file.

Change the entry from 0 to a 1 in the state file, so that the install team 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

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

Ways to Use pfinstall

pfinstall(1M) enables you to test a profile against:

The workstation'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 workstation to test profiles on different sized disks.

How to Use pfinstall to Test a Profile

The procedure to use pfinstall to test a profile involves testing the command in the JumpStart directory.

On an installed and configured Trusted Solaris workstation, log in as a user who can assume the role root.

As root at label admin_low, launch a terminal and see that the pfinstall(1M) command is available in the role's profile shell.
# clist | grep pfinstall
Note -
The name profile shell refers to a shell that recognizes Trusted Solaris execution profiles. It does not refer to the machine profiles being tested here.

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

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

Run the pfinstall -d or pfinstall -D command to test the profile:
$ /usr/sbin/install.d/pfinstall -D | -d disk_config [-c path] profile
Caution -
Without the -d or -D option, pfinstall will install the Trusted Solaris software on the workstation by using the specified profile, and the data on the workstation will be overwritten.

In this command,

-D

Tells pfinstall to use the current workstation's disk configuration to test the profile against. You must be in the role 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 Trusted Solaris CD. This is required if the Trusted Solaris CD is not mounted on /cdrom. (For example, use this option if you copied the Trusted Solaris CD image to disk or mounted the Trusted Solaris CD on a directory other than /cdrom).

profile

The name of the profile to test.

Note -
You should run pfinstall on a workstation running the same version of Trusted Solaris software that will be installed by the profile.

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.

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

You have completed testing the profile. To perform a custom JumpStart installation on a workstation, see Chapter 3, Installing a Workstation.

pfinstall Examples

Below are some examples of using pfinstall(1M) 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/ts7_sparc -basic_prof

SPARC: 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 workstation to test profiles on different sized disks.

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

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

Follow this procedure to create a disk configuration file.

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

Log on as a user who can assume the role root.

As root at label admin_low, launch a terminal and determine the device name for the workstation's disk.

Redirect the output of prtvtoc to create the disk configuration file:
$ prtvtoc /dev/rdsk/device_name > disk_config
In this command,

/dev/rdsk/device_name

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

Note -
Slice 2 must be specified in device_name.

disk_config

Is the disk configuration file name.

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 example creates a disk configuration file, 104_test, on a workstation 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

SPARC: 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 workstation 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:

Concatenate the 104_test file with itself and save the output to another file:
$ cat 104_test 104_test > dual_104_test

Edit the disk configuration file so that each disk device name has a different target number.

For example, the dual_104_test file is shown as follows:

# cat dual_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

* /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

Because dual_104_test file was created by concatenating itself, the following editing was required:

The first disk device name was left as is.
The second disk device name was changed from /dev/rdsk/c0t3d0s2 to /dev/rdsk/c0t0d0s2 so it has a unique target number.

You have completed creating a multiple disk configuration file.

IA: Creating a Disk Configuration File on Intel Architecture

The following procedures enable you to use the -d option of the pfinstall command to test custom JumpStart installations for Intel architecture.

IA: How to Create a Disk Configuration File on Intel Architecture

A disk configuration file represents a disk structure (for example, bytes/sectors, flags, slices), and it enables you to use pfinstall from a single system to test profiles against different sized disks. Disk configuration files for an Intel architecture system must also contain information about a disk's fdisk partitions.

Overview - Creating a disk configuration file for an Intel architecture system involves:

Locating an Intel architecture system with a disk that you want to test a profile against
Saving the output of the prtvtoc command to a file
Saving the output of the fdisk command to a file
Concatenating the two files to create a disk configuration file

Follow this procedure to create a disk configuration file for an Intel architecture system:

Locate an Intel architecture system with a disk that you want to test a profile against.

Determine the device name for the system's disk.

Redirect the output of the following prtvtoc command to a file:
# prtvtoc /dev/rdsk/device_name > file1
where /dev/rdsk/device_name is the device name of the system's disk, and file1 is the file that contains the output of the prtvtoc command. device_name must be in the form cwtxdyp0 or cxdyp0. Partition 0 must be specified in device_name.

Save the output of the following fdisk command to a file:
# fdisk -R -d -n /dev/rdsk/device_name 2>file2
Note -
This version of the fdisk command may not be supported in the next release.

where /dev/rdsk/device_name is the device name of the system's disk. file2 is the file that contains the output of the fdisk command. device_name must be in the form cwtxdyp0 or cxdyp0. Partition 0 must be specified in device_name.

Concatenate the two files to create a disk configuration file:
# cat file1 file2 > disk_config
Note -
The output of the prtvtoc command must be first in a disk configuration file for an Intel architecture system.

Copy the disk configuration file to the JumpStart directory:

# cp disk_config   jumpstart_dir_path

You have created a disk configuration file for an Intel architecture system. The following page provides an example of creating a disk configuration file. This example creates a disk configuration file, 500_test, on an Intel architecture system with a 500-Mbyte disk.

First, you would save the output of the prtvtoc command to a file:

# prtvtoc /dev/rdsk/c0t0d0p0 > output1

The output1 file is shown as follows:

* /dev/rdsk/c0t0d0p0 partition map
*
* Dimensions:
*     512 bytes/sector
*      79 sectors/track
*       7 tracks/cylinder
*     553 sectors/cylinder
*    1481 cylinders
*    1479 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00        553    194103    194655
       1      3    01     194656     65807    260462
       2      6    00          0    819546    819545
       3      6    00     260463     50876    311338
       4      6    00     311339     72996    384334
       6      4    00     384335    434105    818439
       8      1    01          0       553       552

Second, you would save the output of the fdisk command to a different file:

# fdisk -R -d -n /dev/rdsk/c0t0d0p0 2>output2

The output2 file is shown as follows:

fdisk physical geometry:

cylinders[1855] heads[7] sectors[79] sector size[512] blocks[1025815] mbytes[500]

fdisk virtual (HBA) geometry:

cylinders[500] heads[64] sectors[32] sector size[512] blocks[1024000] mbytes[500]

fdisk table on entry:

SYSID ACT BHEAD BSECT BEGCYL   EHEAD ESECT ENDCYL   RELSECT   NUMSECT

6     0   1     1     0        63    32    99       32        204768

130   128 0     1     100      63    96    243      204800    819200

100   0   0     0     0        0     0     0        100       100

100   0   0     0     0        0     0     0        100       100

Finally, you would concatenate the two files (output1 and output2) together to create the disk configuration file named 500_test.

# cat output1 output2 > 500_test

The 500_test file is shown as follows:

* /dev/rdsk/c0t0d0p0 partition map

*

* Dimensions:

*     512 bytes/sector

*      79 sectors/track

*       7 tracks/cylinder

*     553 sectors/cylinder

*    1481 cylinders

*    1479 accessible cylinders

*

* Flags:

*   1: unmountable

*  10: read-only

*

*                          First     Sector    Last

* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory

       0      2    00        553    194103    194655

       1      3    01     194656     65807    260462

       2      6    00          0    819546    819545

       3      6    00     260463     50876    311338

       4      6    00     311339     72996    384334

       6      4    00     384335    434105    818439

       8      1    01          0       553       552

fdisk physical geometry:

cylinders[1855] heads[7] sectors[79] sector size[512] blocks[1025815] mbytes[500]

fdisk virtual (HBA) geometry:

cylinders[500] heads[64] sectors[32] sector size[512] blocks[1024000] mbytes[500]

fdisk table on entry:

SYSID ACT BHEAD BSECT BEGCYL   EHEAD ESECT ENDCYL   RELSECT   NUMSECT

6     0   1     1     0        63    32    99       32        204768

130   128 0     1     100      63    96    243      204800    819200

100   0   0     0     0        0     0     0        100       100

100   0   0     0     0        0     0     0        100       100

IA: How to Create a Multiple Disk Configuration File on Intel Architecture

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

Creating a multiple disk configuration file for an Intel architecture system involves:

Concatenating two or more disk configuration files to create a multiple disk configuration file
Changing the target numbers of disks in the multiple disk configuration file

Note -
Disk device target numbers must be unique on a system.

The following procedure creates a multiple disk configuration file. (The procedure uses the 500_test file from the previous procedure.)

Concatenate a disk configuration file with itself and save it to a file.

The new file becomes the multiple disk configuration file. For example, the following command creates a multiple disk configuration file named dual_500_test:
$ cat 500_test 500_test > dual_500_test

Edit the disk configuration file so that each disk device name has a different target number.

The dual_500_test file is shown as follows:

* /dev/rdsk/c0t0d0p0 partition map

*

* Dimensions:

*     512 bytes/sector

*      79 sectors/track

*       7 tracks/cylinder

*     553 sectors/cylinder

*    1481 cylinders

*    1479 accessible cylinders

*

* Flags:

*   1: unmountable

*  10: read-only

*

*                          First     Sector    Last

* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory

0      2    00        553    194103    194655

1      3    01     194656     65807    260462

2      6    00          0    819546    819545

3      6    00     260463     50876    311338

4      6    00     311339     72996    384334

6      4    00     384335    434105    818439

8      1    01          0       553       552

fdisk physical geometry:

cylinders[1855] heads[7] sectors[79] sector size[512] blocks[1025815] mbytes[500]

fdisk virtual (HBA) geometry:

cylinders[500] heads[64] sectors[32] sector size[512] blocks[1024000] mbytes[500]

fdisk table on entry:

SYSID ACT BHEAD BSECT BEGCYL   EHEAD ESECT ENDCYL   RELSECT   NUMSECT

6     0   1     1     0        63    32    99       32        204768

130   128 0     1     100      63    96    243      204800    819200

100   0   0     0     0        0     0     0        100       100

100   0   0     0     0        0     0     0        100       100

* /dev/rdsk/c0t1d0p0 partition map

*

* Dimensions:

*     512 bytes/sector

*      79 sectors/track

*       7 tracks/cylinder

*     553 sectors/cylinder

*    1481 cylinders

*    1479 accessible cylinders

*

* Flags:

*   1: unmountable

*  10: read-only

*

*                          First     Sector    Last

* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory

0      2    00        553    194103    194655

1      3    01     194656     65807    260462

2      6    00          0    819546    819545

3      6    00     260463     50876    311338

4      6    00     311339     72996    384334

6      4    00     384335    434105    818439

8      1    01          0       553       552

fdisk physical geometry:

cylinders[1855] heads[7] sectors[79] sector size[512] blocks[1025815] mbytes[500]

fdisk virtual (HBA) geometry:

cylinders[500] heads[64] sectors[32] sector size[512] blocks[1024000] mbytes[500]

fdisk table on entry:

SYSID ACT BHEAD BSECT BEGCYL   EHEAD ESECT ENDCYL   RELSECT   NUMSECT

6     0   1     1     0        63    32    99       32        204768

130   128 0     1     100      63    96    243      204800    819200

100   0   0     0     0        0     0     0        100       100

100   0   0     0     0        0     0     0        100       100

Because the dual_500_test file was created by concatenating itself, it required editing as follows:

The first disk device name was left as is

The second disk device name was changed from /dev/rdsk/c0t0d0p0 to /dev/rdsk/c0t1d0p0 so it has a unique target number.

You have created a multiple disk configuration file for an Intel architecture system.

Using a Site-Specific Installation Program

Through the use of begin and finish scripts, sites with special requirements can install the Trusted 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 workstation is installed, instead of the profile and the Trusted 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 workstation named wren (the Trusted Solaris installation program would not be used):

hostname wren x_install.beg - x_install.fin