This chapter describes the optional features that are available to create additional custom JumpStart installation tools.
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.
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.
Creating derived profiles
Backing up files before upgrading
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.
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.
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.
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
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.
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:
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 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 |
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.
#!/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
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.
#!/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 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.
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.
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.
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:
Locate a SPARC based system with a disk you want to test.
Become superuser.
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.
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 |
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 |
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.
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.
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:
Locate an IA based system that contains a disk you want to test.
Become superuser.
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.
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.
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 |
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 |
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.
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 |
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.
Table 7-1 Installation Environment Variables
This environment variable |
Is set to |
---|---|
SI_ARCH |
The hardware architecture of the install client. This variable is set when the arch keyword is used in the rules file. |
SI_BEGIN |
The name of the begin script, if one is used. |
SI_CLASS |
The name of the profile used to install the install client. |
SI_DISKLIST |
A comma-separated list of disk names on the install client. This variable is set when the disksize keyword is used and matched in the rules file. The SI_DISKLIST and SI_NUMDISKS variables are used to determine the physical disk to use for the rootdisk (described in "How the System's Root Disk Is Determined"). |
SI_DISKSIZES |
A comma-separated list of disk sizes on the install client. This variable is set when the disksize keyword is used and matched in the rules file. |
SI_DOMAINNAME |
The domain name. This variable is set when the dommainname keyword is used and matched in the rules file. |
SI_FINISH |
The name of the finish script, if one is used. |
SI_HOSTADDRESS |
The install client's IP address. |
SI_HOSTNAME |
The install client's host name. This variable is set when the hostname keyword is used and matched in the rules file. |
SI_INSTALLED |
The device name of a disk with a specific operating system on it (Solaris, SunOS, or System V). This variable is set when the installed keyword is used and matched in the the rules file. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED. |
SI_INST_OS |
The name of the operating system. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED. |
SI_INST_VER |
The version of the operating system. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED. |
SI_KARCH |
The install client's kernel architecture. This variable is set when the karch keyword is used and matched in the rules file. |
SI_MEMSIZE |
The amount of physical memory on the install client. This variable is set when the memsize keyword is used and matched in the rules file. |
SI_MODEL |
The install client's model name. This variable is set when the model keyword is used and matched in the rules file. |
SI_NETWORK |
The install client's network number. This variable is set when the network keyword is used and matched in the rules file. |
SI_NUMDISKS |
The number of disks on an install client. This variable is set when the disksize keyword is used and matched in the rules file. The SI_NUMDISKS and SI_DISKLIST variables are used to determine the physical disk to use for the rootdisk (described in "How the System's Root Disk Is Determined"). |
SI_OSNAME |
The operating system release on the Solaris 8 Software 1 of 2 SPARC Platform Edition or Solaris 8 Software 1 of 2 Intel Platform Edition CD image. You can, for example, use this variable in a script if you want to install Solaris on systems based on the version of the operating system on the Solaris 8 Software 1 of 2 SPARC Platform Edition or Solaris 8 Software 1 of 2 Intel Platform Edition CD image. |
SI_ROOTDISK |
The device name of the disk represented by the logical name rootdisk. This variable is set when the disksize or the installed keyword is set to rootdisk in the rules file. |
SI_ROOTDISKSIZE |
The size of the disk represented by the logical name rootdisk. This variable is set when the disksize or the installed keyword is set to rootdisk in the rules file. |
SI_TOTALDISK |
The total amount of disk space on the install client. This variable is set when the totaldisk keyword is used and matched in the rules file. |