test

Trusted Solaris Installation and Configuration

Chapter 8 Preparing Custom JumpStart Installations

Definition: Custom JumpStart Installation

A custom JumpStart installation automatically installs the Trusted Solaris software on a workstation based on an administrator-defined profile. You can create customized profiles for different types of users.

Note -

Appendix C, Sample Custom JumpStart Installation provides an example of how a fictitious site prepares and uses custom JumpStart installations.

Reasons to Choose a Custom JumpStart Installation

You should choose a custom JumpStart installation when you have to install Trusted Solaris software on:

For example, the following scenario would be ideal for performing custom JumpStart installations:

These installations would be time-consuming and tedious if you chose to perform an interactive installation on each workstation.

Trusted Solaris Differences in Custom JumpStart

Administrators experienced in setting up custom JumpStart installation should note the differences between installing Trusted Solaris 7 and installing Solaris 7 using custom JumpStart.

Trusted Solaris Custom JumpStart Additions

In the Trusted Solaris environment, administrative jobs are performed by users in administrative roles. Users in the roles admin and root set up custom JumpStart. Also, devices must be allocated and deallocated for use. So,

Trusted Solaris Custom JumpStart Limitations

The following custom JumpStart features are not supported by Trusted Solaris:

Prerequisites for a Custom JumpStart Installation

A custom JumpStart installation can be done on a networked or non-networked workstation.

The non-networked workstation must have

The networked workstation must be on a subnet with the following servers:

Note -

To set up these servers, follow the procedures in Chapter 7, Preparing to Install Trusted Solaris Over a Network.

Tasks to Set up Custom JumpStart Installations

The following table shows the tasks that are required to set up custom JumpStart installations.

Table 8-1 Tasks to Prepare for Custom JumpStart Installations

Task 

 

Description 

Creating a JumpStart directory on a diskette or on a server  

 

Graphic

You must create a JumpStart directory to hold the custom JumpStart files. If you are going to use a diskette for custom JumpStart installations, see "Creating a JumpStart Directory on a Diskette ". If you are going to use a server for custom JumpStart installations, see "Creating a JumpStart Directory on a Server".

 

Enabling all clients to access the JumpStart directory 

 

Graphic

When you use a server to provide the JumpStart directory, you can enable all clients to access the JumpStart directory. See "Enabling Access to the JumpStart Directory" for detailed information.

Creating profiles  

 

Graphic

A profile is a text file used as a template by the custom JumpStart installation software. It defines how to install the Trusted Solaris software on a workstation (for example, initial installation option, system type, disk partitioning, software group), and it is named in the rules file. See "Creating a Profile" for detailed information.

Creating a rules file

 

Graphic

The rules file is a text file used to create the rules.ok file. The rules file is a look-up table consisting of one or more rules that define matches between system attributes and profiles. See "Creating the rules File" for detailed information.

Using check to validate the rules file

 

Graphic

The rules.ok file is a generated version of the rules file, and it is required by the custom JumpStart installation software to match a workstation to a profile. You must use the check script to create the rules.ok file. See "Using check to Validate the rules File" for detailed information.

What Happens During a Custom JumpStart Installation

Figure 8-1 describes what happens after you boot a workstation to perform a custom JumpStart installation.

Figure 8-1 What Happens During a Custom JumpStart Installation

Graphic

The following figure shows an example of how a custom JumpStart installation works on a standalone, non-networked workstation using the workstation's diskette drive.

Figure 8-2 How a Custom JumpStart Installation Works: Non-Networked Example

Graphic

Networked Custom JumpStart Installation

A networked custom JumpStart installation can install multiple workstations with different profiles from from a single server. For example, the JumpStart directory on the server can install workstations in the Engineering group differently from workstations in the Marketing group by using different profiles for machines in those groups. A profile can also be set up for individual workstations, such as Alison's workstation or Pete's workstation.

Creating a JumpStart Directory on a Diskette

You should use a diskette for a custom JumpStart installation if the workstation:

When you use a diskette for custom JumpStart installations, the JumpStart directory must be the root directory on the diskette that contains all the essential custom JumpStart installation files (for example, the rules file, rules.ok file, and profiles). The JumpStart directory should be owned by root and have permissions equal to 755.

Note -

Custom JumpStart diskette installation is more limited than network installation. The following information is not available on the diskette, so you will be prompted for it: hostname, name service, Trusted Solaris configuration values, subnet, netmask, timezone, date, and time.

How to Create a JumpStart Directory on a Diskette

Overview - The procedure to create a JumpStart directory on a diskette involves:

Follow this procedure to create a JumpStart directory on a diskette.

  1. Log onto a SPARC workstation that has a diskette drive and a CDROM drive and assume the role root.

  2. As root, at label admin_low, allocate the diskette drive.

    See "To Allocate a Device" if you are unsure of the steps. The device should be allocated at the label admin_low, and not mounted.


    Do you want floppy_n mounted: (y,n)? n

  3. Insert a diskette into the diskette drive.

  4. If the diskette already has a UFS file system on it, go to Step 7.

    If the mount command fails in Step 7, the diskette does not have a UFS file system on it.

  5. As root, at label admin_low, launch a terminal and format the diskette: 


    # fdformat /dev/rdiskette

  6. Create a file system on the diskette:


    # newfs /dev/rdiskette

  7. As role admin, at label admin_low, create a mount point and mount the diskette: 


    $ mkdir jumpstart_dir_path
$ mount -F ufs /dev/diskette jumpstart_dir_path

    In this command,

    jumpstart_dir_path

    Is the absolute directory path where the diskette is mounted.

    For example, the following command would mount a diskette on the /jumpstart directory: 


    mount -F -ufs /dev/diskette /jumpstart

    Note -

    If the mount command fails, go back to Step 5 to format the diskette.

  8. Determine your next step based on the location of the Trusted Solaris CD image.

    If You Want to Use the ... 

    Then ... 

    Trusted Solaris CD in the local CDROM drive 

    1. As root, create a mount point at admin_low. For example:

      mkdir /cdrom

    2. Insert the Trusted Solaris CD into the CDROM drive.

    3. Go to Step 9.

     

    Trusted Solaris CD image on the local disk

    1. Change the directory to the Trusted Solaris CD image on the local disk. For example:

      cd /export/install/ts7_sparc

    2. Do Step 11.

  9. As root, at label admin_low, allocate the CDROM drive and mount it.


    Do you want cdrom_n mounted: (y,n)? y

  10. Change the directory to the mounted CD:


    # cd /cdrom/cdrom0

  11. Copy the custom JumpStart installation files from the jumpstart_sample directory into the JumpStart directory (root directory) of the diskette: 


    # cp -r Trusted_Solaris_7/Misc/jumpstart_sample/* jumpstart_dir_path
    Note -

    • jumpstart_dir_path is the absolute directory path where the diskette is mounted.

    • The custom JumpStart installation files must be in the root directory of the diskette.

  12. Deallocate the CDROM drive and the diskette drive. Label the diskette.

    See "To Deallocate a Device" if you are unsure of the steps.

    You have completed creating a JumpStart directory on the diskette. To continue, see "How to Create a Profile".

Creating a JumpStart Directory on a Server

If you want to perform custom JumpStart installations by using a server on the network, you must create a JumpStart directory on the server. When you use a server for custom JumpStart installations, the JumpStart directory is a directory on the server that contains all the essential custom JumpStart files (for example, the rules file, rules.ok file, and profiles). The JumpStart directory should be owned by root and have permissions equal to 755.

How to Create a JumpStart Directory on a Server

Overview - The procedure to create a JumpStart directory on a server involves:

Follow this procedure to create a JumpStart directory on a server.

  1. Log on and assume the role root on the server where you want the JumpStart directory to reside.

  2. As root, at label admin_low, launch a terminal and create the JumpStart directory anywhere on the server.


    # mkdir jumpstart_dir_path

    In this command,

    jumpstart_dir_path

    Is the absolute path of the JumpStart directory.

    For example, the following command would create the directory called jumpstart in the root file system: 


    # mkdir -p /jumpstart

  3. Share the directory.

    For details, see "How to Share a File System".

    1. Add the following entry:


      share -F nfs -o ro,anon=0 jumpstart_dir_path

      For example, the following entry would be correct for the example shown in Step 2:


      share -F nfs -o ro,anon=0 /jumpstart

  4. Share the file system.

    For example, 


    # share /jumpstart

  5. Determine the next step based on the location of the Trusted Solaris image.

    If You Want to Use The ... 

    Then ... 

    Trusted Solaris CD in the local CDROM drive 

    1. As root, create a mount point at admin_low. For example:

      mkdir /cdrom

    2. Insert the Trusted Solaris CD into the CDROM drive.

    3. Go to Step 6.

    Trusted Solaris CD image on the local disk  

    1. Change the directory to the Trusted Solaris image on the local disk. For example:

      cd /export/install/ts7_sparc

    2. Do Step 8.

  6. As root, at label admin_low, allocate the CDROM drive and mount it.


    Do you want cdrom_n mounted: (y,n)? y

    See "To Allocate a Device" if you are unsure of the steps.

  7. Change the directory to the mounted CD:


    # cd /cdrom/cdrom0

  8. As root, at label admin_low, copy the contents of the jumpstart_sample directory into the JumpStart directory: 


    # cp -r Trusted_Solaris_7/Misc/jumpstart_sample/* jumpstart_dir_path

    For example, the following command would copy the jumpstart_sample directory into the JumpStart directory created in Step 2:


    # cp -r Trusted_Solaris_7/Misc/jumpstart_sample/* /jumpstart

  9. Deallocate the CDROM drive.

    See "To Deallocate a Device" if you are unsure of the steps.

    You have completed creating a JumpStart directory on the server.

  10. Continue with "Enabling Access to the JumpStart Directory".

Enabling Access to the JumpStart Directory

The JumpStart directory must be added to the bootparams database for successful network installation. You should use the same procedure you chose to use to "Add Client Information for a Network Install". You can also directly edit the bootparams database on the install server.

Note -

The following procedure is not necessary if you are using a diskette for the JumpStart directory.

How to Enable Access to the JumpStart Directory

Follow the same procedure that you used to set up the network servers in Chapter 7, Preparing to Install Trusted Solaris Over a Network.

Method 1: Host Manager

  1. As role admin, at label admin_low, launch the Host Manager using the same naming service you did for setting up network install, and select a workstation.

    See "Add Client Information Using the Host Manager" for a description of the Host Manager interface.

  2. Enter jumpstart_dir_path as the Profile Server entry and click OK.

    For example, enter stork:/jumpstart.

  3. Choose File > Save Changes.

    When you save the entry, the Host Manager places the information in the bootparams database.

  4. Repeat for all hosts to be installed with custom JumpStart, then exit the Host Manager.

  5. As role admin, at label admin_low, launch the Database Manager using the same naming service you did for setting up network install.

  6. Load the bootparams database.

  7. To fully automate custom JumpStart, add an ns entry before the initial entry. Leave a space between it and the next entry.

    ns=nis+_server:nisplus(netmask)

    For example,

    ns=grebe:nisplus(255.255.255.0)

Method 2: add_install_client Command

  1. As root, at label admin_low, go to "Add Client Information with the add_install_client Command".

  2. Use the -c option to the add_install_client command to add JumpStart details to the local bootparams database. 

    # ./add_install_client -c [server:jumpstart_dir_path] [-e ethernet_address \
host_name platform_group

    In this command,

    -c

    Specifies a JumpStart directory for custom JumpStart installations. This option and its arguments are required for custom JumpStart.

    server:jumpstart_dir_path

    server is the host name of the server on which the JumpStart directory is located. jumpstart_dir_path is the absolute path of the JumpStart directory.

    For example, issuing the following command on an install/boot server modifies the local bootparams database to look for custom JumpStart information in the stork:/jumpstart directory.: 


    # ./add_install_client -e 8:0:20:17:22:a4 \
 
-c stork:/jumpstart \
-s heron:/export/install/ts7_sparc willet sun4m

    The result: The client willet can be installed with custom JumpStart. Its Trusted Solaris 2.5.1 image will come from heron (as will its boot information), and its custom JumpStart installation profile will come from stork.

How to Check Access to the JumpStart Directory

If you want to check the bootparams database file directly:

  1. On the install server, as role admin at label admin_low, edit the bootparams database.

    For details, see "To Open and Modify a Solstice_Apps Database".

  2. Scroll through a host's entry to locate the keyword=value pairs: install_server=server:install_dir_path install_config=server:jumpstart_dir_path

    For example, the following keyword=value pair in a workstation's bootparams entry would enable it to access the /jumpstart directory on the server named stork:

    install_config=stork:/jumpstart

    The following keyword=value pair in the same workstation's bootparams entry would enable it to access the Trusted Solaris installation image on heron. Together, these keyword=value pairs enable custom JumpStart:

    install_server=heron:/export/install/ts7_sparc

    All workstations can now access the JumpStart directory.

  3. Continue with "Creating a Profile".

Creating a Profile

A profile is a text file used as a template by the custom JumpStart installation software. It defines how to install the Trusted Solaris software on a workstation (for example, system type, disk partitioning, software group), and it is named in the rules file.

A profile consists of one or more profile keywords and their values. Each profile keyword is a command that controls one aspect of how the Trusted Solaris installation program will install the Trusted Solaris software on a workstation. For example, the following profile keyword and value indicate to the Trusted Solaris installation program to install the workstation as a server.

system_type server

Note -

If you created the JumpStart directory by using the procedures on "Creating a JumpStart Directory on a Diskette " or "Creating a JumpStart Directory on a Server", example profiles have been placed in the JumpStart directory.

Requirements for Profiles

The following are requirements when creating a profile:

Recommendations for Trusted Solaris Profiles

Every Trusted Solaris rule should call a finish script. In the script, you can accomplish the following task:

For an example of a rule that calls a finish script, see "Recommendations for Trusted Solaris Rules".

How to Create a Profile

Overview - The procedure to create a profile involves:

Follow this procedure to create as many profiles as you need for your site.

  1. As root, at label admin_low, open the Admin Editor.

  2. Enter a file name (the profile) to be edited.

    You can create a new file or edit one of the sample profiles in the JumpStart directory you created. For example,

    File to Edit: /jumpstart/basic_install_profile

    The name of a profile should reflect how it will install the Trusted Solaris software on a workstation (for example, basic_install_profile, eng_profile, or mktg_profile).

  3. Add profile keywords and profile values to the profile.

    Be aware of these things as you edit the profile:

    • "Profile Examples" provides some examples of profiles.

    • "Profile Keyword and Profile Value Descriptions" provides the list of valid profile keywords and values.

    • You can have as many lines in the profile as necessary to define how to install the Trusted Solaris software on a workstation.

    • You can add a comment after the pound sign (#) anywhere on a line. If a line begins with a #, the entire line is a comment line. If a # is specified in the middle of a line, everything after the # is considered a comment. Blank lines are also allowed in a profile.

    • The profile keywords and their values are case sensitive.

    • Profiles should be owned by root and have permissions equal to 644.

    Note -

    See "Using pfinstall to Test Profiles" for detailed information about testing profiles.

    This completes the procedure to create a profile. To continue setting up for a custom JumpStart installation, see "How to Create the rules File".

Profile Examples

The following profile examples describe how you can use different profile keywords and profile values to control how the Trusted Solaris software is installed on a workstation. See "Profile Keyword and Profile Value Descriptions" for the list of profile keywords and profile values. 

# profile keywords     profile values
# ----------------     -------------------
   install_type        initial_install
   system_type         standalone
   partitioning        default
   filesys             any 80 swap   # specify size of /swap
   cluster             SUNWCprog
   package             SUNWman delete
   package             SUNWolman delete
   package             SUNWxwman delete
   package             SUNWxwdem add
   package             SUNWxwdim add

  1. This profile keyword is required in every profile.

  2. This profile keyword defines that the workstation will be installed as a standalone workstation.

  3. The file system slices are determined by the software to be installed (default value); however, the size of swap is set to 80 Mbytes and it is installed on any disk (any value).

  4. The developer software group (SUNWCprog) is installed on the workstation.

  5. Because the man pages will be mounted remotely, those packages are selected not to be installed on the workstation; however, the packages containing the X Windows demo programs and images are selected to be installed on the workstation. 

# profile keywords     profile values
# ----------------     -------------------
install_type           initial_install
system_type            standalone

partitioning           default
filesys                c0t0d0s0 auto /
filesys                c0t3d0s1 64 swap
cluster                SUNWCall

  1. The file system slices are determined by the software to be installed (default value). However, the size of root is based on the selected software (auto value) and it is installed on c0t0d0s0, and the size of swap is set to 64 Mbytes and it is installed on c0t3d0s1.

  2. The entire distribution software group (SUNWCall) is installed on the workstation. 

# profile keywords      profile values
# ----------------      -------------------
install_type            initial_install
system_type             standalone

fdisk                   c0t0d0 0x04 delete
fdisk                   c0t0d0 solaris maxfree
cluster                 SUNWCall
cluster                 SUNWCacc delete

  1. All fdisk partitions of type DOSOS16 (04 hexadecimal) are deleted from the c0t0d0 disk.

  2. A Trusted Solaris fdisk partition is created on the largest contiguous free space on the c0t0d0 disk.

  3. The entire distribution software group (SUNWCall) is installed on the workstation.

  4. The system accounting utilities (SUNWCacc) are selected not to be installed on the workstation. 

# profile keywords      profile values
# ----------------      -------------------
install_type            upgrade

   package              SUNWbcp delete
   package              SUNWolman add
   package              SUNWxwman add
   cluster              SUNWCumux add
   locale               de

  1. This profile upgrades a system (SPARC only).

  2. The binary compatibility package (SUNWbcp) is selected to be deleted from the system or prevented from being installed.

  3. This code ensures that the OpenLook and X Windows man pages and the universal multiplexor software are selected to be installed if they are not installed on the system. (All packages already on the system are automatically upgraded.)

  4. The German localization packages are selected to be installed on the system.

Profile Keyword and Profile Value Descriptions

Profile keywords and profile values that you can use in a profile are listed and described below.

Profile Keyword and Profile Value Descriptions
client_arch

karch_value

client_arch defines that the server will support a different platform group than it uses. If you do not specify client_arch, any diskless client must have the same platform group as the server. You must specify client_arch once for each platform group.

Valid values for karch_value are sun4d, sun4c, sun4m, and sun4u. (See Solaris 7 Sun Hardware Platform Guide for a detailed list of the platform names of various workstations.)

Restriction: client_arch can be used only when system_type is specified as server.

client_root

root_size

client_root defines the amount of root space (root_size in Mbytes) to allocate for each client. If you do not specify client_root in a server's profile, the installation software will automatically allocate 15 Mbytes of root space per client. The size of the client root area is used in combination with the num_clients keyword to determine how much space to reserve for the /export/root file system.

Restriction: client_root can be used only when system_type is specified as server.

client_swap

swap_size

client_swap defines the amount of swap space (swap_size in Mbytes) to allocate for each diskless client. If you do not specify client_swap, 24 Mbytes of swap space is allocated.

Example: client_swap 64

The example defines that each diskless client will have a swap space of 64 Mbytes.

Restriction: client_swap can be used only when system_type is specified as server.

cluster

group_name

Use for software groups. cluster designates what software group to add to the workstation. The cluster names for the software groups are:

  • End user system support: SUNWCuser

  • Developer system support: SUNWCprog

  • Entire distribution: SUNWCall

You can specify only one software group in a profile, and it must be specified before other cluster and package entries. If you do not specify a software group with cluster, the end user software group (SUNWCuser) is installed on the workstation by default.

cluster

cluster_name [add | delete]

Use for clusters.

cluster designates whether a cluster should be added or deleted from the software group that will be installed on the workstation. add or delete indicates whether the cluster should be added or deleted. If you do not specify add or delete, the cluster is added by default.

cluster_name must be in the form SUNWCname.

For Upgrade (not supported for Trusted Solaris 7):

  • All clusters already on the system are automatically upgraded.

  • If you specify cluster_name add, and cluster_name is not installed on the system, the cluster is installed.

  • If you specify cluster_name delete, and cluster_name is installed on the system, the package is deleted before the upgrade begins.

dontuse

disk_name

dontuse designates a disk that the Trusted Solaris installation program should not use when partitioning default is specified. You can specify dontuse once for each disk, and disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0.

By default, the Trusted Solaris installation program uses all the operational disks on the workstation.

Restriction: You cannot specify the dontuse keyword and the usedisk keyword in the same profile.

filesys

slice size [file_system] [optional_parameters]

Use for creating local file systems.

This instance of filesys creates local file systems during the installation. You can specify filesys more than once.

slice - Choose one of the following:

any

The Trusted Solaris installation program places the file system on any disk.

Restriction: any cannot be specified when size is existing, all, free, start:size, or ignore.

cwtxdysz or cwdysz

The disk slice where the Trusted Solaris installation program places the file system, for example, c0t0d0s0.

rootdisk.sn

The logical name of the disk where the installation program places the root file system. The .sn suffix indicates a specific slice on the disk.

size - Choose one of the following:

num

The size of the file system is set to num (in Mbytes).

existing

The current size of the existing file system is used.

Note: When using this value, you can change the name of an existing slice by specifying file_system as a different mount_pt_name.

auto

The size the file system is automatically determined depending on the selected software.

all

The specified slice uses the entire disk for the file system. When you specify this value, no other file systems can reside on the specified disk.

free

The remaining unused space on the disk is used for the file system.

Restriction: If free is used as the value to filesys, it must by the last filesys entry in a profile.

start:size

The file system is explicitly partitioned: start is the cylinder where the slice begins; size is the number of cylinders for the slice.

file_system - You can use this optional value when slice is specified as any or cwtxdysz. If file_system is not specified, unnamed is set by default, but then you cannot specify the optional_parameters value. Choose one of the following:

mount_pt_name

The file system's mount point name, for example, /var.

swap

The specified slice is used as swap.

overlap

The specified slice is defined as a representation of a disk region (VTOC value is V_BACKUP). By default, slice 2 is an overlap slice that is a representation of the whole disk.

Restriction: overlap can be specified only when size is existing, all, or start:size.

unnamed

The specified slice is defined as a raw slice, so slice will not have a mount point name. If file_system is not specified, unnamed is set by default.

ignore

The specified slice is not used or recognized by the Trusted Solaris installation program. This could be used to ignore a file system on a disk during an installation, so the Trusted Solaris installation program can create a new file system on the same disk with the same name.

optional_parameters - Choose one of the following:

preserve

The file system on the specified slice is preserved.

Restriction: preserve can be specified only when size is existing and slice is cwtxdysz.

mount_options

One or more mount options (-o option of the mount(1M) command) that are added to the /etc/vfstab entry for the specified mount_pt_name.

Note: If you need to specify more than one mount option, the mount options must be separated by commas and no spaces. For example: ro,nodev.

install_type

initial_install | upgrade

install_type defines whether to perform the initial installation option or upgrade option on the system. (Upgrade is not supported for Trusted Solaris 7).

Restriction: install_type must be the first profile keyword in every profile.

locale

locale_name

locale designates that the localization packages associated with the selected software should be installed (or added for upgrade) for the specified locale_name. The locale_name values are the same as the values used for the $LANG environment variable.

The English localization packages are installed by default. You can specify locale once for each localization you need to support.

num_clients

client_num

When a server is installed, space is allocated for each diskless client's root (/) and swap file systems. num_clients defines the number of diskless clients (client_num) that a server will support. If you do not specify num_clients, five diskless clients are allocated.

Restriction: num_clients can be used only when system_type is specified as server.

package

package_name [add | delete]

package designates whether a package should be added to or deleted from the software group that will be installed on the workstation. add or delete indicates whether the package should be added or deleted. If you do not specify add | delete, the package is added.

package_name must be in the form SUNWname. Use the pkginfo -l command on an installed workstation to view detailed information about packages and their names.

For Upgrade (not supported for Trusted Solaris 7):

  • All packages already on the system are automatically upgraded.

  • If you specify package_name add, and package_name is not installed on the system, the package is installed.

  • If you specify package_name delete, and package_name is installed on the system, the package is deleted before the upgrade begins.

  • If you specify package_name delete, and package_name is not installed on the system, the package is prevented from being installed if it is part of a cluster that is designated to be installed.

partitioning

default | existing | explicit

partitioning defines how the disks are divided into slices for file systems during the installation. If you do not specify partitioning, default is set.

default - The Trusted Solaris installation program selects the disks and creates the file systems on which to install the specified software, except for any file systems specified by the filesys keyword. rootdisk is selected first; additional disks are used if the specified software does not fit on rootdisk.

existing - The Trusted Solaris installation program uses the existing file systems on the workstation's disks. All file systems except /, /usr, /usr/openwin, /opt, and /var are preserved. The installation program uses the last mount point field from the file system superblock to determine which file system mount point the slice represents.

Restriction: When specifying the filesys profile keyword with partitioning existing, size must be existing.

explicit - The Trusted Solaris installation program uses the disks and creates the file systems specified by the filesys keywords. If you specify only the root (/) file system with the filesys keyword, all theTrusted Solaris software will be installed in the root file system.

Restriction: When you use the explicit profile value, you must use the filesys profile keyword to specify which disks to use and what file systems to create.

system_type

standalone | server

system_type defines the type of workstation being installed. If you do not specify system_type in a profile, standalone is set by default.

usedisk

disk_name

usedisk designates a disk that the Trusted Solaris installation program will use when partitioning default is specified. You can specify usedisk once for each disk, and disk_name must be specified in the form cwtxdyor cwdy, for example, c0t0d0.

If you specify the usedisk profile keyword in a profile, the Trusted Solaris installation program will only use the disks that you specify with the usedisk profile keyword.

Restriction: You cannot specify the usedisk keyword and the dontuse keyword in the same profile.

How the Size of Swap Is Determined

If a profile does not explicitly specify the size of swap, the Trusted Solaris installation program determines the maximum size that swap can be, based on the workstation's physical memory. The following table shows how the maximum size of swap is determined during a custom JumpStart installation.

Table 8-2 How the Maximum Size of Swap Is Determined

Physical Memory (in Mbytes) 

Maximum Size of Swap (in Mbytes) 

32 - 64 

64 

64 - 128 

64 

128 - 512 

128 

512 > 

256 

The Trusted Solaris installation program will make the size of swap no more than 20% of the disk where it resides, unless there is free space left on the disk after laying out the other file systems. If free space exists, the Trusted Solaris installation program will allocate the free space to swap up to the maximum size shown in Table 8-2.

Note -

Physical memory plus swap space must be a minimum of 64 Mbytes.

Creating the rules File

The rules file is a text file used to create the rules.ok file. The rules file is a lookup table consisting of one or more rules that define matches between workstation attributes and profiles. For example, the rule

karch sun4c - basic_prof -

matches a workstation with a sun4c platform name to the basic_prof profile, which the Trusted Solaris installation program would use to install the workstation.

Note -

If you set up the JumpStart directory by using the procedures "Creating a JumpStart Directory on a Diskette " or "Creating a JumpStart Directory on a Server", an example rules file should already be in the JumpStart directory; the example rules file contains documentation and some example rules. If you use the example rules file, make sure you comment out the example rules that you will not use.

When Does a System Match a Rule

During a custom JumpStart installation, the Trusted Solaris installation program attempts to match the rules in the rules.ok file in order, first rule through the last rule. A rule match occurs when the workstation being installed matches any of the rule values in the rule (as defined in "Rule Keyword and Rule Value Descriptions"). As soon as a workstation matches a rule, the Trusted Solaris installation program stops reading the rules.ok file and begins to install the workstation as defined by the matched rule's profile.

Recommendations for Trusted Solaris Rules

Since a workstation installed with custom JumpStart does not automatically reboot, create a rules file whose entries include a finish script that automatically reboots the workstation. An example finish script is in "Rebooting the Workstation with a Finish Script". A sample rules file:

hostname wren - basic_prof finish.sh

matches a workstation whose hostname is wren to the basic_prof profile, which the Trusted Solaris installation program would use to install the workstation. After installation, the finish.sh script would be executed to reboot the workstation.

How to Create the rules File

Overview - The procedure to create a rules file involves:

  1. As secadmin, at label admin_low, open the Admin Editor.

    See "To Create or Open a File from the Trusted Editor" if you are unfamiliar with the steps.

  2. To edit the sample rules file:

    File to Edit: /jumpstart/rules

  3. To create a rules file in /export/tmp:

    File to Edit: /export/tmp/rules

  4. Add a rule in the rules file for each group of workstations you want to install using custom JumpStart.

    Be aware of these things as you add rules to the rules file:

    An individual rule in the rules file must have the following syntax: 

    [!]rule_keyword rule_value [&& [!]rule_keyword rule_value]...   begin   profile   finish

    The fields of a rule are described below:

    Field Descriptions of a Rule
    !

    A symbol used before a rule keyword to indicate negation.

    [ ]

    A symbol used to indicate an optional expression or field.

    ...

    A symbol used to indicate the preceding expression may be repeated.

    &&

    A symbol that must be used to join (logically AND) rule keyword and rule value pairs together in the same rule. During a custom JumpStart installation, a workstation must match every pair in the rule before the rule matches.

    rule_keyword

    A predefined keyword that describes a general system attribute, such as host name (hostname) or memory size (memsize). It is used with the rule value to match a workstation with the same attribute to a profile. See "Rule Keyword and Rule Value Descriptions" for the list of rule keywords.

    rule_value

    A value that provides the specific system attribute for the corresponding rule keyword. See "Rule Keyword and Rule Value Descriptions" for the list of rule values.

    begin

    A name of an optional Bourne shell script that can be executed before the installation begins. If no begin script exists, you must enter a minus sign (-) in this field. All begin scripts must reside in the JumpStart directory.

    See "Creating Begin Scripts" for detailed information on how to create begin scripts.

    profile

    A name of a text file used as a template that defines how to install Trusted Solaris on a workstation. The information in a profile consists of profile keywords and their corresponding profile values. All profiles must reside in the JumpStart directory.

    Note - There are optional ways to use the profile field, which are described in "Using a Site-Specific Installation Program" and "Creating Derived Profiles With Begin Scripts".

    finish

    A name of an optional Bourne shell script that can be executed after the installation completes. If no finish script exists, you must enter a minus sign (-) in this field. All finish scripts must reside in the JumpStart directory.

    See "Creating Finish Scripts" for detailed information on how to create finish scripts.

    This completes the procedure to create a rules file. To validate the rules file, see "How to Use check to Validate the rules File".

Rule Examples

The following illustration shows several example rules in a rules file. Each line has a rule keyword and a valid value for that keyword. The Trusted Solaris installation program scans the rules file from top to bottom. When the Trusted Solaris installation program matches a rule keyword and value with a known workstation, it installs the Trusted Solaris software specified by the profile listed in the profile field. 

  # rule keywords and rule values  begin script  profile    finish script
  # -----------------------------  ------------  -------    -------------
  hostname eng-1                     -           basic_prof     -
  network 192.43.34.0 && !model \
  'SUNW,Sun 4_50'                    -           net_prof       -
  model SUNW,SPARCstation-LX         -           lx_prof    complete
  network 193.144.2.0 && karch sparc  setup      ultra_prof done
  any  -                             -           generic_prof   -

  1. This rule matches if the workstation's host name is eng-1. The basic_prof profile is used to install the Trusted Solaris software on the workstation that matches this rule.

  2. The rule matches if the workstation is on subnet 192.43.34.0 and it is not a SPARCstation IPXTM(SUNW,Sun 4_50). The net_prof profile is used to install the Trusted Solaris software on workstations that match this rule.

  3. The rule matches if the workstation is a SPARCstation LX. The lx_prof profile and the complete finish script are used to install the Trusted Solaris software on workstations that match this rule. This rule also provides an example of rule wrap, which is defined on "Important Information About the rules File".

  4. This rule matches if the workstation is on subnet 193.144.2.0 and the workstation is a Sun Ultra. The setup begin script, the ultra_prof profile, and the done finish script are used to install the Trusted Solaris software on workstations that match this rule.

  5. This rule matches any workstation that did not match the previous rules. The generic_prof profile is used to install the Trusted Solaris software on workstations that match this rule. If used, -any should always be in the last rule.

Important Information About the rules File

The following information is important to know about the rules file:

Name

The rules file must have the file name, rules.

rules.ok file

The rules.ok file is a generated version of the rules file, and it is required by the custom JumpStart installation software to match a workstation to a profile. You must run the check script to create the rules.ok file, and the rules.ok file should be owned by root and have permissions equal to 644.

Comments

You can add a comment after the pound sign (#) anywhere on a line. If a line begins with a #, the entire line is a comment line. If a # is specified in the middle of a line, everything after the # is considered a comment. Blank lines are also allowed in the rules file.

Note -

When creating the rules.ok file, the check script removes all the comment lines, comments at the end of a rule, and blank lines.

Rule wrap

When a rule spans multiple lines, you can let a rule to wrap to a new line, or you can continue a rule on a new line by using a backslash (\) before the carriage return.

Rule fields

The rule_value, begin, and finish fields must have a valid entry or a minus sign (-) to specify that there is no entry.

Rule Keyword and Rule Value Descriptions

The rule keywords and rule values that you can use in the rules file are listed and described below.

Rule Keyword and Rule Value Descriptions
any

minus sign (-)

Match always succeeds.

arch

processor_type

Matches a workstation's processor type. The uname -p command reports the workstation's processor type.

For example, SPARC is a platform; sparc is a processor_type.

domainname

domain_name

Matches a workstation's domain name, which controls how a name service determines information.

If you have a workstation already installed, the domainname(1M) command reports the workstation's domain name.

disksize

disk_name size_range

  • disk_name -- A disk name in the form cxtydz, such as c0t3d0, or the special word rootdisk. rootdisk should be used only when trying to match workstations that contain the factory-installed JumpStart software. rootdisk is described on Table 8-3.

  • size_range -- The size of the disk, which must be specified as a range of Mbytes (xx-xx).

Matches a workstation's disk (in Mbytes).

Example: disksize c0t3d0 250-300

The example tries to match a workstation with a c0t3d0 disk that is between 250 and 300 Mbytes.

Note -

When calculating size_range, remember that a Mbyte equals 1,048,576 bytes. A disk may be advertised as a "207 Mbyte" disk, but it may have less than 207 million bytes of disk space. The Trusted Solaris installation program will actually view the "207 Mbyte" disk as a 197 Mbyte disk because 207,000,000 / 1,048,576 = 197. So, a "207 Mbyte" disk would not match a size_range equal to 200-210.

hostaddress

IP_address

Matches a workstation's IP address.

hostname

host_name

Matches a workstation's host name.

If you have a workstation already installed, the uname -n command reports the host name.

installed

slice version

  • slice - A disk slice name in the form cwtxdysz, such as c0t3d0s5, or the special words any or rootdisk. If -any is used, any disk attached to the workstation attempts to match. rootdisk should be used only when trying to match workstations that contain the factory-installed JumpStart software.rootdisk is described on Table 8-3.

  • version - A version name, such as Trusted_Solaris_7, or the special word any. If any is used, any Trusted Solaris or SunOS release is matched.

Matches a disk that has a root file system corresponding to a particular version of Trusted Solaris software.

Note -

Factory-installed JumpStart may not be supported by Trusted Solaris software.

karch

platform_group

Matches a workstation's platform name.

Valid values are sun4d, sun4c, sun4m, and sun4u. (See Solaris 7 Sun Hardware Platform Guide.)

If you have a workstation already installed, the arch -k command or the uname -m command reports the workstation's platform group.

memsize

physical_mem

Matches a workstation's physical memory size (in Mbytes). The value must be a range of Mbytes (xx-xx) or a single Mbyte value.

Example: memsize 32-64

The example tries to match a workstation with a physical memory size between 32 and 64 Mbytes.

If you have a workstation already installed, the prtconf(1M) command reports the workstation's physical memory size in line 2. Run the command in the role admin.

model

model_name

Matches a workstation's model number, which is workstation-dependent and varies by the manufacturer. The list shown is not complete.

If you have a workstation already installed, the prtconf command reports the workstation's model number in line 5.

If you have a workstation already installed, the uname -i command reports the workstation's model name.

For example, a system name is different from a model_name:

System Name

Model Name

SPARCstation 1 (4/60)

Sun 4_60

SPARCstation IPX (4/50)

SUNW,Sun_4_50

SPARCstation 10

SUNW,SPARCstation-10

SPARCclassicTM (4/15)

SUNW,SPARCclassic

SPARCstation LX (4/30)

SUNW,SPARCstation-LX

SPARCserver 1000

SUNW,SPARCserver-1000

SPARCcenterTM 2000

SUNW,SPARCcenter-2000

SPARCstation 10 SX

SUNW,SPARCstation-10,SX

SPARCstation 20

SUNW,SPARCstation-20

SPARCstation Voyager

SUNW,S240

Sun UltraTM 1

SUNW,Ultra-1

Sun UltraServer 1

SUNW,Ultra-1

Sun UltraServer 2

SUNW,Ultra-2

Sun UltraEnterprise

SUNW,Ultra-Enterprise

Note: If the model_name contains spaces, the model_name must be inside a pair of single quotes ('). For example: 'SUNW,Sun 4_60'

network

network_num

Matches a workstation's network number, which the Trusted Solaris installation program determines by performing a logical AND between the workstation's IP address and the subnet mask.

Example: network 193.144.2.0

The example would match a workstation with a 193.144.2.8 IP address (if the subnet mask were 255.255.255.0).

osname

Trusted_Solaris_version

Matches a version of Trusted Solaris software already installed on a workstation. Trusted_Solaris_version is the version of the Trusted Solaris environment installed on the workstation: for example, Trusted Solaris 2.5.1.

totaldisk

size_range

Matches the total disk space on a workstation (in Mbytes). The total disk space includes all the operational disks attached to a workstation. The value must be specified as a range of Mbytes (xx-xx).

Example: totaldisk 300-500

The example tries to match a workstation with a total disk space between 300 and 500 Mbytes.

Note -

When calculating size_range, remember that a Mbyte equals 1048576 bytes. A disk may be advertised as a "207 Mbyte" disk, but it may have only 207 million bytes of disk space. The Trusted Solaris installation program will actually view the "207 Mbyte" disk as a 197 Mbyte disk because 207000000 / 1048576 = 197. So, a "207 Mbyte" disk would not match a size_range equal to 200-210.

How the Installation Program Sets the Value of rootdisk

rootdisk is the logical name of the disk where the root file system is placed during an installation. During a custom JumpStart installation, the Trusted Solaris installation program sets the value of rootdisk (that is, the actual disk it represents) depending on various situations; this is described in the following table.

Table 8-3 How the Trusted Solaris Installation Program Sets rootdisk

Situation 

What Happens 

A system contains the factory-installed JumpStart software. (This applies to some SPARC systems only).  

rootdisk is set to the disk that contains the factory-installed JumpStart software before the system tries to match any rules.

rootdisk has not been set and a workstation tries to match the following rule:

 

disksize rootdisk size_range

or 

installed rootdisk version

 

rootdisk is set to c0t3d0 or the first available disk attached to the workstation.

 

After rootdisk is set, the workstation tries to match the rule.

If rootdisk has been set and the workstation tries to match the following rule.

 

disksize rootdisk size_range

or 

installed rootdisk version

 

The workstation tries to match the rule. 

A workstation tries to match the following rule: 

 

installed disk version

If disk is found on the workstation with a root file system that matches the specified version, the rule matches and rootdisk is set to disk.

A workstation tries to match the following rule:

 

installed any version

If any disk is found on the workstation with a root file system that matches the specified version, the rule matches and rootdisk is set to the found disk. (If there is more than one disk on the workstation that can match, the workstation will match the first disk that is found.)

rootdisk has not been set after a system matches a rule and the system is going to be upgraded (which is defined in the profile).

rootdisk is set to the first disk found with a root file system that matches an upgradable version of Trusted Solaris software. If no disk is found, the system proceeds with an interactive installation.

rootdisk has not been set after a workstation matches a rule.

rootdisk is set to c0t3d0 or the first available disk attached to the workstation.

For the Trusted Solaris installation program to use the value of rootdisk, the following conditions must be true in the profile specified for the workstation:

Using check to Validate the rules File

Before the rules file and profiles can be used, you must run the check(1M) command to validate that these files are set up correctly. The check script performs the following steps:

  1. The rules file is checked for syntax.

    check makes sure that the rule keywords are legitimate, and the begin, class, and finish fields are specified for each rule (the begin and finish fields may be a minus sign [-] instead of a file name).

  2. If no errors are found in the rules file, each profile specified in the rules is checked for syntax.

  3. If no errors are found, check creates the rules.ok file from the rules file, removing all comments and blank lines, retaining all the rules, and adding the following comment line to the end:

    # version=2 checksum=num

How to Use check to Validate the rules File

Overview - The procedure to use the check command to validate the rules file involves:

  1. As root, at label admin_low, make sure that the check script resides in the JumpStart directory.

    Note -

    The check script is provided in the jumpstart_sample directory on the Trusted Solaris CD.

  2. Change the directory to the JumpStart directory: 


    # cd jumpstart_dir_path

  3. Run the check script to validate the rules file: 


    # ./check [ -p path ] [ -r file_name ]

    In this command,

    -p path

    Is the path to the Trusted Solaris 7 CD. You can use a Trusted Solaris CD image on a local disk or a mounted Trusted Solaris CD. This option ensures that you are using the most recent version of the check script. You should use this option if you are using check on a workstation that is running a previous version of Trusted Solaris.

    -r file_name

    Specifies a rules file other than the one named rules. Using this option, you can test the validity of a rule before integrating it into the rules file.

    As the check script runs, it reports that it is checking the validity of the rules file and the validity of each profile. If no errors are encountered, it reports: 

    The custom JumpStart configuration is ok.
    and creates a file called rules.ok.

    The rules files is now validated.

Finishing Custom JumpStart

To complete the Custom JumpStart installation the profiles, rules, and rules.ok files you have customized for JumpStart must be added to jumpstart_dir_path. Check that all interactive prompts can be answered.

Copy JumpStart Files to jumpstart_dir_path

  1. As root, at label admin_low, launch a terminal and change to the JumpStart directory.

    If the jumpstart_dir_path is on a diskette, you must allocate the device first. See "How to Create a JumpStart Directory on a Diskette" for the procedure. 


    # cd jumpstart_dir_path

  2. If you are using a working directory rather than the jumpstart_dir_path to create custom JumpStart files, copy them to jumpstart_dir_path.

    All of your profiles, the rules file, the rules.ok file, and the finish script (finish.sh) should be copied to jumpstart_dir_path.

    For example, the following commands copy the contents of the working directory /export/tmp. All custom JumpStart profiles have followed a convention of using "profile" as the last part of the file name.


    # cd /export/tmp
# cp finish.sh *profile* rules rules.ok jumpstart_dir_path

  3. Check file permissions.

    File or Directory 

    Owner 

    Permissions 

    Label 

    jumpstart_dir_path

    root 

    755 

    admin_low[admin_low] 

    profiles 

    root 

    644 

    admin_low[admin_low] 

    rules, rules.ok 

    root 

    644 

    admin_low[admin_low] 

    finish.sh 

    root 

    755 

    admin_low[admin_low] 

  4. As root, at label admin_low, deallocate the diskette drive if the jumpstart_dir_path is on a diskette.

    Result: The custom JumpStart files are available to the installation program.

Check That All Installation Questions Can Be Answered

A custom JumpStart installation prompts you interactively if the installation program cannot get information that it requires.

    Did you complete the following procedures?

To read about the optional features available for custom JumpStart installations, see Chapter 9, Using Optional Custom JumpStart Features.

To install a workstation using custom JumpStart, use the appropriate booting procedure in Chapter 3, Installing a Workstation.