test

Solaris 10 8/07 Installation Guide: Custom JumpStart and Advanced Installations

Chapter 4 Using Optional Custom JumpStart Features (Tasks)

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

Note –

Instructions in this chapter are valid for either a SPARC server or an x86 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 based systems and x86 based systems.

Creating Begin Scripts

A begin script is a user-defined Bourne shell script that you specify in the rules file. A begin script performs tasks before the Solaris software is installed on a system. You can use begin scripts only when using custom JumpStart to install the Solaris software.

Use a begin script to perform one of the following tasks:

Important Information About Begin Scripts

Note –

For the Solaris 10 release, a sample JumpStart script, set_nfs4_domain, was provided on media to prevent being prompted during a JumpStart installation. This script suppressed the NFSv4 prompt during installation. This script is no longer required. Starting with the Solaris 10 8/07release, use the sysidcfg keyword, nfs4_domain that suppresses being prompted. The set_nfs4_domain script no longer works to suppress a prompt.

If you have non-global zones installed and the new nfs4_domain keyword exists in the sysidcfg file, the first boot of a non-global zone sets the domain. Otherwise, the Solaris interactive installation program comes up and you are prompted to provide a domain name before the boot process completes.

See nfs4_domain Keyword in Solaris 10 8/07 Installation Guide: Network-Based Installations

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. For example, you might need to use derived profiles for identical system models that have different hardware components, such as systems that contain different frame buffers.

To set up a rule to use a derived profile, you must perform the following tasks:

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.

The following is an example of a begin script that creates the same derived profile every time. You can write a begin script to create different derived profiles that depend on the evaluation of rules.

Example 4–1 Begin Script That Creates a Derived Profile

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

In the example, 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, ensure the script does not have any errors. A derived profile is not verified by the check script because derived profiles are not created until the execution of the begin script.

Creating Finish Scripts

A finish script is a user-defined Bourne shell script that you specify in the rules file. A finish script 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.

Tasks that you can perform with a finish script include the following:

Important Information About Finish Scripts

ProcedureTo Add Files With a Finish Script

Through a finish script, you can add files from the JumpStart directory to an already installed system. You can add the files because the JumpStart directory is mounted on the directory that is specified by the SI_CONFIG_DIR variable. The directory 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.

  1. Copy all of the files that you are adding to the installed system to the JumpStart directory.

  2. Insert the following line in the finish script for each file that you want to be copied to the newly installed file system hierarchy:

    cp ${SI_CONFIG_DIR}/file_name /a/path_name
Example 4–2 Adding a File With a Finish Script

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: 

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 the Solaris software is installed on a system. By adding packages with a finish script, you reduce time and ensure consistency in which packages and patches are installed on different systems at your site.

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

Example 4–3 Adding Packages With a Finish Script

  #!/bin/sh
 
  BASE=/a
  MNT=/a/mnt
  ADMIN_FILE=/a/tmp/admin
 
  mkdir ${MNT}
  mount -f nfs sherlock:/export/package ${MNT}
  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
 
  /usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz 
  umount ${MNT}
  rmdir ${MNT}

The following describes some commands for this example.

Example 4–4 Adding Patches With a Finish Script

 #!/bin/sh 

########
#
# USER-CONFIGURABLE OPTIONS
#
########

# The location of the patches to add to the system after it's installed.
# The OS rev (5.x) and the architecture (`mach`) will be added to the
# root.  For example, /foo on a 8 SPARC would turn into /foo/5.8/sparc
LUPATCHHOST=ins3525-svr
LUPATCHPATHROOT=/export/solaris/patchdb
#########
#
# NO USER-SERVICEABLE PARTS PAST THIS POINT
#
#########

BASEDIR=/a

# Figure out the source and target OS versions
echo Determining OS revisions...
SRCREV=`uname -r`
echo Source $SRCREV

LUPATCHPATH=$LUPATCHPATHROOT/$SRCREV/`mach`

#
# Add the patches needed
#
echo Adding OS patches
mount $LUPATCHHOST:$LUPATCHPATH /mnt >/dev/null 2>&1
if [ $? = 0 ] ; then
	for patch in `cat /mnt/*Recommended/patch_order` ; do
		(cd /mnt/*Recommended/$patch ; echo yes | patchadd -u -d -R $BASEDIR .)
	done
	cd /tmp
	umount /mnt
else
	echo "No patches found"
if
Note –

In the past, the chroot(1M) command was used with the pkgadd and patchadd commands in the finish script environment. In rare instances, 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 that are already installed on a system. For example, the finish script in Example 4–5 customizes the root environment by appending information to the .cshrc file in the root (/) directory.

Example 4–5 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 the 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 types a password, the system cannot finish booting.

A finish script that is named set_root_pw is saved in the auto_install_sample directory. The finish script shows how to set the root password automatically, without prompting. set_root_pw is shown in Example 4–6.

Note –

If you set the system's root password with a finish script, users might attempt to discover the root password from the encrypted password in your finish script. Ensure that you safeguard against users who might try to determine the root password.

Example 4–6 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
 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}

The following describes some of the commands in this example.

Non-Interactive Installations With Finish Scripts

You can use finish scripts to install additional software after the Solaris OS is installed. The Solaris installation program prompts you to enter information during the installation. To maintain a hands-off installation, you can run the Solaris installation program with the -nodisplay or -noconsole options.

Table 4–1 Solaris Installation Options

Option 

Description 

-nodisplay

Runs the installer without a graphic user interface. Use the default product installation unless the installation was modified by the -locales option.

-noconsole

Runs the installation without any interactive text console device. Useful when paired with -nodisplay for UNIX script use.

For more information, see the man page installer(1M).

Creating a Compressed Configuration File

Instead of using the add_install_client command to specify the location of the custom JumpStart configuration files, you can specify the location of the files when you boot the system. However, you can only specify the name of one file. As a result, you must compress all of the custom JumpStart configuration files into one file.

The compressed configuration file can be one of the following types:

ProcedureTo Create a Compressed Configuration File

  1. Change the directory to the JumpStart directory on the profile server.


    # cd jumpstart_dir_path

  2. Use a compression tool to compress the custom JumpStart configuration files into one file.

    Note –

    The compressed configuration file cannot contain relative paths. The custom JumpStart configuration files must be in the same directory as the compressed file.

    The compressed configuration file must contain the following files:

    • Profile

    • rules

    • rules.ok

    You can also include the sysidcfg file in the compressed configuration file.

  3. Save the compressed configuration file on an NFS server, an HTTP server, or on a local hard disk.

Compressed Configuration File Example

The following example shows how to use the tar command to create a compressed configuration file that is named config.tar. The custom JumpStart configuration files are located in the /jumpstart directory.

Example 4–7 Creating a Compressed Configuration File


# cd /jumpstart
# tar -cvf config.tar *
a profile 1K
a rules 1K
a rules.ok 1K
a sysidcfg 1K

Creating Disk Configuration Files

This section describes how to create single-disk and multiple-disk configuration files. Disk configuration files enable you to use pfinstall(1M) from a single system to test profiles against different disk configurations.

ProcedureSPARC: To Create a Disk Configuration File

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

  2. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  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_file
    /dev/rdsk/device_name

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

    disk_config_file

    The name of the disk configuration file.

  4. Determine if you are testing the installation of Solaris software on multiple disks.

    • If no, stop. You are finished.

    • If yes, concatenate the single–disk configuration files 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, as in the following example.


      # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

  5. Determine if the target numbers in the disk device names are unique in the multiple-disk configuration file that you created in the previous step.

    • If yes, stop. You are finished.

    • If no, open the file with a text editor and make the target numbers unique in the disk device names.

      For example, assume that 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: Disk Configuration File 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.

Example 4–8 SPARC: Creating a Disk Configuration File

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


# prtvtoc /dev/rdsk/c0t3d0s2 >104_test

The contents of the 104_test file resemble the following:

* /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 created disk configuration files for a SPARC based system. Testing a Profile contains information about using disk configuration files to test profiles.

Procedurex86: To Create a Disk Configuration File

  1. Locate an x86 based system that contains a disk that you are testing.

  2. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  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_file -h /dev/rdsk/device_name
    disk_config_file

    The name of a disk configuration file.

    /dev/rdsk/device_name

    The device name of the fdisk layout of the entire disk. device_name must be in the form cwtxdys0 or cxdys0.

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


    # prtvtoc /dev/rdsk/device_name >>disk_config
    /dev/rdsk/device_name

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

    disk_config

    The name of the disk configuration file.

  5. Determine if you are testing the installation of Solaris software on multiple disks.

    • If no, stop. You are finished.

    • If yes, concatenate the single-disk configuration files 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, as in the following example.


      # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

  6. Determine if the target numbers in the disk device names are unique in the multiple-disk configuration file that you created in the previous step.

    • If yes, stop. You are finished.

    • If no, open the file with a text editor and make the target numbers unique.

      For example, the file might contain 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

x86: Disk Configuration File Example

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

Example 4–9 x86: Creating a Disk Configuration File

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


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

The 500_test file looks like the following:

 * /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 created disk configuration files for an x86 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 instead of the profile and the Solaris installation program.

For example, if the following rule matches a system, the x_install.beg begin script and the x_install.fin finish script install Solaris software on the system that is named clover:

hostname clover x_install.beg - x_install.fin