This chapter describes the optional features that are available to create additional custom JumpStart installation tools.Creating Begin Scripts Creating Finish Scripts Creating a Compressed Configuration File Creating Disk Configuration Files Using a Site-Specific Installation Program 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. 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:Creating derived profiles Backing up files before upgrading 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 JumpStart program cannot mount the file systems onto /a, an error occurs and installation fails. During the installation, output from the begin script is deposited in /tmp/begin.log. After the installation is completed, the log file is redirected to /var/sadm/system/logs/begin.log. Ensure that root owns the begin script and that the permissions are set to 644. You can use custom JumpStart environment variables in your begin scripts. For a list of environment variables, see Custom JumpStart Environment Variables. Save begin scripts in the JumpStart directory. In prior releases, the /etc/.NFS4inst_state.domain file was created by the sysidnfs4 program. This file would suppress the prompt for an NFSv4 domain name during installation. This file is no longer created. Use the sysidcfg keyword, nfs4_domain, instead. 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: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 that depends 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. 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. #!/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. 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. 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:Adding files Adding individual packages or patches in addition to the ones that are installed in a particular software group Customizing the root environment Setting the system's root password Installing additional software The Solaris installation program mounts the system's file systems on /a. The file systems remain mounted on /a until the system reboots. You can use the finish script to add, change, or remove files from the newly installed file system hierarchy by modifying the file systems that are respective to /a. During the installation, output from the finish script is deposited in /tmp/finish.log. After the installation is completed, the log file is redirected to /var/sadm/system/logs/finish.log. Ensure that root owns the finish script and that the permissions are set to 644. You can use custom JumpStart environment variables in your finish scripts. For a list of environment variables, see Custom JumpStart Environment Variables. Save finish scripts in the JumpStart directory. 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. You can also replace files by copying files from the JumpStart directory to already existing files on the installed system. Copy all of the files that you are adding to the installed system to the JumpStart directory. 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 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 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 pkgadd1M or patchadd1M commands in finish scripts, use the R option to specify /a as the root path. Example 4–3 shows an example of a finish script that adds packages. Example 4–4 shows an example of a finish script that adds patches. #!/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.The following command mounts a directory on a server that contains the package to install.mount -f nfs sherlock:/export/package ${MNT} The following command creates a temporary package administration file, admin, to force the pkgadd1M command not to perform checks or prompt for questions when installing a package. Use the temporary package administration file to maintain a hands-off installation when you are adding packages.cat >${ADMIN_FILE} <<DONT_ASK The following pkgadd command 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 #!/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 In the past, the chroot1M 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 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.#!/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 } 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.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. #!/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.The following command sets the variable PASSWD to an encrypted root password that is obtained from an existing entry in a system's /etc/shadow file.#create a temporary input file The following command creates a temporary input file of /a/etc/shadow.cp /a/etc/shadow /a/etc/shadow.orig The following command changes the root entry in the /etc/shadow file for the newly installed system by using $PASSWD as the password field.if ( $1 == "root" ) The following command removes the temporary /a/etc/shadow file.rm -f /a/etc/shadow.orig The following command 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 by using the variable SI_SYS_STATE, which has a value currently of /a/etc/.sysIDtool.state. To avoid problems with your scripts if this value changes, always reference this file by using $SI_SYS_STATE. The sed command that is 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.$$ 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.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 installer1M. 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. For SPARC based systems, you specify the location of the file in the boot command For x86 based systems, you specify the location of the files by editing the GRUB entry in the GRUB menu The compressed configuration file can be one of the following types:tar Compressed tar zip bzip tar Change the directory to the JumpStart directory on the profile server.# cd jumpstart_dir_path Use a compression tool to compress the custom JumpStart configuration files into one file.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. Save the compressed configuration file on an NFS server, an HTTP server, or on a local hard disk. 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.# cd /jumpstart # tar -cvf config.tar * a profile 1K a rules 1K a rules.ok 1K a sysidcfg 1K This section describes how to create single-disk and multiple-disk configuration files. Disk configuration files enable you to use pfinstall1M from a single system to test profiles against different disk configurations.Locate a SPARC based system with a disk you want to test. &suStepA;Create a single–disk configuration file by redirecting the output of the prtvtoc1M command to a file.# prtvtoc /dev/rdsk/device_name >disk_config_file/dev/rdsk/device_nameThe device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2. disk_config_fileThe name of the disk configuration file. 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_configThe new file becomes the multiple-disk configuration file, as in the following example.# cat 104_disk2 104_disk3 104_disk5 >multi_disk_test 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 mapChange the second target number to t2, as shown here:* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map 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 that is named 104_test:# prtvtoc /dev/rdsk/c0t3d0s2 >104_testThe 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 /spaceYou have created disk configuration files for a SPARC based system. Testing a Profile contains information about using disk configuration files to test profiles. Locate an x86 based system that contains a disk that you are testing. &suStepA;Create part of the single-disk configuration file by saving the output of the fdisk1M command in a file.# fdisk -R -W disk_config_file -h /dev/rdsk/device_namedisk_config_fileThe name of a disk configuration file. /dev/rdsk/device_nameThe device name of the fdisk layout of the entire disk. device_name must be in the form cwtxdys0 or cxdys0. Append the output of the prtvtoc1M command to the disk configuration file: # prtvtoc /dev/rdsk/device_name >>disk_config/dev/rdsk/device_nameThe device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2. disk_configThe name of the disk configuration file. 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_configThe new file becomes the multiple-disk configuration file, as in the following example.# cat 104_disk2 104_disk3 104_disk5 >multi_disk_test 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 mapChange the second target number to t2, as shown here:* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map 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. 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/c0t0d0p0The 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 2050140Second, you append the output of the prtvtoc command to the 500_test file: # prtvtoc /dev/rdsk/c0t0d0s2 >>500_testThe 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 422987You have created disk configuration files for an x86 based system. Testing a Profile contains information about using disk configuration files to test profiles. 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