Inom
Hitta mer dokumentation
Supportresurser som ingår
| Ladda ner denna bok i PDF
Using Optional Custom JumpStart Features
5
-
Overview
- This chapter describes the optional features available for custom JumpStart installations, and it is a supplement to Chapter 4, "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
-
Note - This chapter is valid for either an x86, PowerPC, or SPARC server that is being used for custom JumpStart installations. An x86 server can provide custom JumpStart files for SPARC and PowerPC systems, a SPARC system can provide custom JumpStart files for x86 and PowerPC systems, and a PowerPC server can provide custom JumpStart files for x86 and SPARC systems.
Creating Begin Scripts
What Is a Begin Script
- 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.
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 or upgrade installation. If the 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 tasks:
-
- Creating derived profiles
- Backing up files before upgrade
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 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.
-
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
What Is a Finish 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.
Important Information About Finish Scripts
- 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.
- 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:
-
- Adding files
- Customizing the root environment
- Setting the system's root password
Adding Files With Finish Scripts
- 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).
-
Note - 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 finish script would copy the site_prog from the JumpStart directory into a system's /usr/bin directory during a custom JumpStart installation:
-
#!/bin/sh
cp ${SI_CONFIG_DIR}/site_prog /a/usr/bin
|
Customizing the Root Environment
- Through a finish script, you can customize files already installed on the system. 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 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. This allows the initial reboot of the system 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 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
(1) PASSWD=dKO5IBkSF42lw
#create a temporary input file
(2) cp /a/etc/shadow /a/etc/shadow.orig
mv /a/etc/shadow /a/etc/shadow.orig
nawk -F: '{
(3) 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
(4) #remove the temporary file
rm -f /a/etc/shadow.orig
(5) # 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. (1)Set the variable PASSWD to an encrypted root password obtained from an existing entry in a system's /etc/shadow file.
(2)Create a temporary input file of /a/etc/shadow.
(3)Change the root entry in the /etc/shadow file for the newly installed system using $PASSWD as the password field.
(4)Remove the temporary /a/etc/shadow file.
(5)Change the entry from 0 to a 1 in the state file, so that the user 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
Why Use pfinstall
- When install_type initial_install is defined in a profile, you can use the pfinstall command to test the profile without actually installing the Solaris software on a system. pfinstall shows the results of how a system would be installed according to the specified profile, before you actually perform a custom JumpStart installation.
-
Note - You cannot use pfinstall to test a profile using the upgrade option (when the initial_type upgrade is defined in a profile).
Ways to Use pfinstall
-
pfinstall enables you to test a profile against:
-
- The system'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 system to test profiles on different sized disks.
-
Note - You must run pfinstall on the same platform type as the profiles you are testing. For example, you must run pfinstall on an x86 system to test profiles for x86 systems (using the x86 system's disk configuration or an x86 disk configuration file).
· How to Use pfinstall to Test a Profile
-
Overview - The procedure to use pfinstall to test a profile involves:
-
- Changing the directory to the JumpStart directory
- Using the pfinstall command to test the profile
- Follow this procedure to use pfinstall to test a profile.
-
-
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:
-
- 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
|
- In this command,
-
| -D | Tells pfinstall to use the current system's disk configuration to test the profile against. You must be 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 Solaris CD. This is required if the Solaris CD is not mounted on /cdrom. (For example, use this option if you copied the Solaris CD image to disk or mounted the Solaris CD on a directory other than /cdrom). |
| profile | The name of the profile to test. |
-
Note - You should run pfinstall on a system running the same version of Solaris software that will be installed by the profile. Otherwise, use pfinstall on the Solaris CD that will be installed by the profile, which is located in the /export/exec/arch.Solaris_2.5/sbin/install.d directory.
- 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 3.
- You have completed testing the profile. To perform a custom JumpStart installation on a system, see Chapter 7, "Booting and Installing Solaris: Custom JumpStart."
pfinstall Examples
- Below are some examples of using pfinstall 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 basic_prof
Creating a Disk Configuration File for a PowerPC System
- The following procedures enable you to use the -d option of the pfinstall command to test custom JumpStart installations for a PowerPC system.
· How to Create a Disk Configuration File for a PowerPC System
- 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 a PowerPC system must also contain information about a disk's fdisk partitions.
-
Overview - Creating a disk configuration file for a PowerPC system involves:
-
- Locating a PowerPC 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 a PowerPC system:
-
-
Locate a PowerPC 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 a PowerPC system.
-
-
Copy the disk configuration file to the JumpStart directory:
-
# cp disk_config jumpstart_dir_path
|
-

- You have created a disk configuration file for a PowerPC system. The following page provides an example of creating a disk configuration file. This example creates a disk configuration file, 500_test, on a PowerPC 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
* 85 sectors/track
* 9 tracks/cylinder
* 765 sectors/cylinder
* 2662 cylinders
* 2660 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 0 00 2295 655605 657899
1 3 01 657900 65790 723689
2 5 00 0 2034900 2034899
4 0 00 723690 654075 1377764
7 0 00 1377765 655605 2033369
8 1 01 0 765 764
9 9 01 765 1530 2294
|
- 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[2694] heads[9] sectors[85] sector size[512] blocks[2060910] mbytes[1006]
fdisk virtual (HBA) geometry:
cylinders[1023] heads[33] sectors[61] sector size[512] blocks[2059299] mbytes[1005]
fdisk table on entry:
SYSID ACT BHEAD BSECT BEGCYL EHEAD ESECT ENDCYL RELSECT NUMSECT
65 0 1 2 0 0 35 1 1 2047
1 128 0 36 1 2 18 4 2048 6144
130 0 2 19 4 26 217 255 8192 2052718
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
* 85 sectors/track
* 9 tracks/cylinder
* 765 sectors/cylinder
* 2662 cylinders
* 2660 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 0 00 2295 655605 657899
1 3 01 657900 65790 723689
2 5 00 0 2034900 2034899
4 0 00 723690 654075 1377764
7 0 00 1377765 655605 2033369
8 1 01 0 765 764
9 9 01 765 1530 2294
fdisk physical geometry:
cylinders[2694] heads[9] sectors[85] sector size[512] blocks[2060910] mbytes[1006]
fdisk virtual (HBA) geometry:
cylinders[1023] heads[33] sectors[61] sector size[512] blocks[2059299] mbytes[1005]
fdisk table on entry:
SYSID ACT BHEAD BSECT BEGCYL EHEAD ESECT ENDCYL RELSECT NUMSECT
65 0 1 2 0 0 35 1 1 2047
1 128 0 36 1 2 18 4 2048 6144
130 0 2 19 4 26 217 255 8192 2052718
100 0 0 0 0 0 0 0 100 100
|
· How to Create a Multiple Disk Configuration File for a PowerPC System
- 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 a PowerPC 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:
-
(1) * /dev/rdsk/c0t0d0p0 partition map
*
* Dimensions:
* 512 bytes/sector
* 85 sectors/track
* 9 tracks/cylinder
* 765 sectors/cylinder
* 2683 cylinders
* 2681 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 0 00 295 660195 662489
1 3 01 662490 68085 730574
2 5 00 0 2051730 2051729
4 0 00 730575 660195 1390769
7 0 00 1390770 660195 2050964
8 1 01 0 765 764
9 9 01 765 1530 2294
fdisk physical geometry:
cylinders[2694] heads[9] sectors[85] sector size[512] blocks[2060910] mbytes[1006]
fdisk virtual (HBA) geometry:
cylinders[1023] heads[33] sectors[61] sector size[512] blocks[2059299] mbytes[1005]
fdisk table on entry:
SYSID ACT BHEAD BSECT BEGCYL EHEAD ESECT ENDCYL RELSECT NUMSECT
65 0 1 2 0 0 35 1 1 2047
1 128 0 36 1 2 18 4 2048 6144
130 0 2 19 4 26 217 255 8192 2052718
100 0 0 0 0 0 0 0 100 100
continued
|
-
(2) * /dev/rdsk/c0t1d0p0 partition map
*
* Dimensions:
* 512 bytes/sector
* 85 sectors/track
* 9 tracks/cylinder
* 765 sectors/cylinder
* 2683 cylinders
* 2681 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 0 00 295 660195 662489
1 3 01 662490 68085 730574
2 5 00 0 2051730 2051729
4 0 00 730575 660195 1390769
7 0 00 1390770 660195 2050964
8 1 01 0 765 764
9 9 01 765 1530 2294
fdisk physical geometry:
cylinders[2694] heads[9] sectors[85] sector size[512] blocks[2060910] mbytes[1006]
fdisk virtual (HBA) geometry:
cylinders[1023] heads[33] sectors[61] sector size[512] blocks[2059299] mbytes[1005]
fdisk table on entry:
SYSID ACT BHEAD BSECT BEGCYL EHEAD ESECT ENDCYL RELSECT NUMSECT
65 0 1 2 0 0 35 1 1 2047
1 128 0 36 1 2 18 4 2048 6144
130 0 2 19 4 26 217 255 8192 2052718
100 0 0 0 0 0 0 0 100 100
|
- Because the dual_500_test file was created by concatenating itself, the following editing was required:
(1)
- The first disk device name was left as is
-

(2) 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 a PowerPC system.
Using a Site-Specific Installation Program
- 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
|
|