This chapter describes the optional features available for custom JumpStart installations, and it is a supplement to Chapter 8, Preparing Custom JumpStart Installations.
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 systems with the same or different platform type as the server. For example, a SPARC server could provide custom JumpStart files for both SPARC and x86 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 the system. Begin scripts can be used only with custom JumpStart installations.
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.
Begin scripts should be owned by root and have permissions equal to 644.
You could set up begin scripts to perform the following tasks:
Creating derived profiles
Backing up files before upgrading
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 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.
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 the system, but before the system reboots. Finish scripts can be used only with custom JumpStart installations.
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.
Finish scripts should be owned by root and have permissions equal to 644.
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.
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).
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 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 |
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 on 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.
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
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.
#!/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. 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.
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.
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.
Creating 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 |
You have completed creating disk configuration files for a SPARC based system. To use disk configuration files to test profiles, see "Testing a Profile".
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 |
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.
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 |
You have completed creating disk configuration files for an x86 based system. To use disk configuration files to test profiles, see "Testing a Profile".
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 |
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 |