Using JumpStart | Solaris 9 Sun Certified System Administrator Study Guide

JumpStart is one of the four installation methods you can use to install Solaris. The others that you learned about in Chapter 2 are suninstall, Web Start, and Solaris Live Upgrade. Jump-Start is a flexible and comprehensive installation program that has two versions: custom JumpStart and factory JumpStart.

The factory JumpStart installation program is commonly referred to just as JumpStart, whereas the custom method is almost always clarified by its "custom" moniker. Factory JumpStart installations are automated but do not give the administrator flexibility when installing Solaris.

What factory JumpStart does is automatically install Solaris 9 on a new SPARC-based computer when you insert the Solaris 9 DVD or Solaris 9 Software 1 of 2 CD into the computer and reboot it. Detecting the system type and disk size, factory JumpStart installs Solaris according to a default profile. The profile determines slice layout as well as the software installed on the computer. Although it's a handy installation method, it's not the most accommodating.

The JumpStart that this chapter focuses on is custom JumpStart. Custom JumpStart enables you to install several systems based on profiles that you create. In the profile, you can include which software components to install, as well as specify pre- and post-installation tasks to complete.

Note

Because this chapter concentrates on custom JumpStart, all references to JumpStart from this point forward refer to custom JumpStart.

Creating installation profiles takes time. In fact, if you're installing only a few computers, it might take more time to create profiles than to install the computers. But if you have a large number of installations to make or if you frequently reinstall client computers, the profiles can save you a significant amount of time.

In a nutshell, custom JumpStart is designed to efficiently install Solaris on a large number of computers, while ensuring that the computers have a specific software configuration. By combining a custom JumpStart profile with a sysidcfg file to provide system information, you can make a custom JumpStart installation totally automated.

Overview of JumpStart

JumpStart is a client-server program used to install Solaris client computers with little to no interaction required from the administrator. The larger the number of clients you need to install, the more efficient JumpStart becomes.

For JumpStart to work properly, you must configure one or more JumpStart servers. These servers will help the client computer boot, identify the client, and provide installation and configuration files to help install Solaris. These servers will be covered in depth in the "Configuring JumpStart Servers" section later in this chapter.

A scenario can best help you understand how the overall JumpStart process works. In this scenario, you are installing Solaris 9 on 100 client computers, none of which have an operating system currently installed. Fifty of the computers are for your research and development group, and the other fifty are for the administrative group, which includes accounting, human resources, and other administrative staff. The R&D group will need to have the Developers software group installed, whereas the administrative staff will need the standard End User software group.

You can see that there are two distinct configurations that you need to install. For each configuration, you must create a rules file as well as a profile. The rules file will determine which configuration is installed, based on some characteristic of the computer that the software will be installed on. The rules file points to the profile, which performs the installation based on parameters you've specified within the profile. So, as the administrator, you create two rules files and two profiles, one each for the R&D group and the administrative group. These files will be stored in a JumpStart directory on the profile server.

Because you will be installing over the network, you also need to configure a boot server. To make things easier, you are going to make one server your JumpStart server, meaning that it performs boot as well as installation services for clients.

With your server properly configured, you need to boot your clients from the network. After the client boots, it will begin installing Solaris.

Obviously, this scenario is a simplified version of what you, the administrator, need to do to get JumpStart to work properly. Hopefully, though, you now have a good idea of the basic concepts of JumpStart and of how the process works.

Planning for Installation

Before you start your installation, you need to carefully plan it out. This concept was drilled repeatedly in Chapter 2, but it's more important now. Why? Because now that you're dealing with JumpStart, it can be assumed that you are installing a large number of client computers. Each of these computers will have certain software requirements. You will want to install the systems in the shortest amount of time possible, but of course with the correct parameters. This can't be done haphazardly. Plan before you install.

Some of the questions you can ask before installing include the following:

Who will be using the computer?
What software will they need to access?
Is this going to be an upgrade of Solaris or a new installation?
Where is the computer located?
Will the installation be local or over the network?

These questions can also bring up other questions. For example, engineering or development employees might require more virtual memory (meaning more swap space) than users who might do only light data entry or word processing. Also, based on the users' needs, you might need to install a specific Solaris software package, as well as third-party applications.

After you have answered these questions and decided what each computer needs, you need to create the two configuration files used to perform a JumpStart installation of Solaris. These files can be placed on either a floppy disk or a profile server. If your computers are not networked, or if you will be installing Solaris locally from the CD-ROM or DVD-ROM drive, you can use the disk. If you're installing over the network, then the configuration files will be on the profile server.

Knowing the JumpStart Commands

Setting up and configuring JumpStart requires several commands. There currently is no way to set up JumpStart through a graphical interface. Table 16.1 lists some of the commands used with JumpStart.

Table 16.1: JumpStart Commands
Command	Description
add_install_client	Adds network installation information about a client to the JumpStart server.
add_to_install_server	Copies additional Solaris packages to an existing installation server configuration.
check	Validates the rules file and creates a rules.ok file.
modify_install_server	Modifies an existing package on the install server.
pfinstall	Performs a trial run installation. Used to see if any potential problems exist.
rm_install_client	Removes client information from the JumpStart server.
setup_install_server	Performs the initial installation of the JumpStart server.

Most of the commands associated with JumpStart are used to set up and configure the server. Considering that the majority of work needed to get JumpStart running properly is done during setup, this makes perfect sense.

Configuring JumpStart Servers

The three servers that are required for JumpStart are the boot, install, and profile servers. For cost and convenience, one server can perform all three functions, and that's how most Jump-Start installations are configured. To learn how JumpStart works, though, it's best to think of them as three separate servers.

Installing a Boot Server

The boot server is the first computer that JumpStart clients will come into contact with during the installation process. Although some client computers might have an existing operating system installed, you can assume that clients using JumpStart are a blank slate. They have no operating system, meaning that they also have no boot files. The boot server provides the files that clients need to boot.

Tip

If your client does not have an operating system installed, you can boot from the network with the boot net command at the ok prompt.

When a client is first booted, it broadcasts on the network to look for a boot server. Specifically, the client computer is looking for boot files and an IP address. Because client computers broadcast looking for information, the boot server must be on the same subnet as the client computer for the boot process to work properly. If you have several IP subnets, you will need one boot server per subnet.

Note

An alternative to having boot servers on each subnet is to have the routers also function as boot servers. However, this configuration can result in performance degradation, especially on heavily utilized networks. Another alternative to using boot servers on each subnet is to use the Dynamic DNS (DDNS) service along with DHCP for your network clients.

The boot server needs to be running the Reverse Address Resolution Protocol (RARP) daemon, named in.rarpd, to service the clients' requests. If this daemon is running and it receives a network boot request, it will look up the client's Ethernet address in the local /etc/ethers file. The daemon then passes the located address back to the client computer.

Warning

If the in.rarpd daemon is not running, JumpStart will fail.

After the IP address is passed back to the client, the boot server looks for the appropriate boot file for the client, based on the client processor architecture. The boot file is transmitted to the client via the Trivial File Transfer Protocol (TFTP) and its associated daemon, in.tftpd. The client uses the boot program to start up.

The boot program tries to mount the root file system (/) on the client. To do this, it issues a whoami request, asking for the client's host name. The boot server, using the rpc.bootparamd daemon, looks up the host name and returns it to the client. Then, the boot program uses a getfile request to locate the client's root file system (/) and swap space. The boot server gets this data from its local /etc/bootparams file and returns it to the client.

After obtaining its boot parameters, the boot program mounts the local root file system (/) from the boot server. Then, the kernel is loaded on the local system, and the init process is started. After init loads, the boot server redirects the client computer to the profile server. At this point, the client computer has a very rudimentary, skeletal version of Solaris running. It is not the whole operating system and is not yet usable by people.

Using the information obtained from bootparams, the client searches for the profile server. After the server is located, the client locates the directory where the Solaris installation files are located and then begins the installation with the suninstall program.

Note

This boot process seems complex, and although it is, the back-and-forth queries and loading are completed relatively quickly. It's not like you will be sitting there for hours waiting for the boot process to complete.

The files that are important to the boot process (and therefore must be properly configured on the boot server) are /etc/ethers, /etc/hosts, /etc/bootparams, /etc/dfs/dfstab, and /tftpboot:

/etc/ethers This file contains a mapping of Ethernet addresses to IP addresses. When a client computer boots, it will know its Ethernet address but not its IP. Using RARP, the client can obtain the needed address from this file.

You can manually create entries in /etc/ethers, but this can be a painstaking process. The easier way to modify this file is to use the add_install_client command, which will create the entries for you.

/etc/hosts By now, you should know that the hosts file resolves computer names to IP addresses. When the client looks for its host name (provided that it found a valid IP address in /etc/ethers), this file will be consulted. If you are running a name service such as DNS or NIS, then the name service will take the place of this file.

/etc/bootparams This file contains boot parameters, such as root file system and swap space location, for network-based clients. For the server to properly respond to a client requesting this information, the rpc.bootparamd daemon must be running.

/etc/dfs/dfstab This file, as you might remember, lists local file systems to be shared on the network. If the root file system (/) is not shared, then clients will not be able to access files from it.

/tftpboot This is actually a directory, not a file. When you run the add_install_client program, a boot file for the JumpStart client will be added to this directory. The boot file will be associated with the client based on the client's IP address, expressed in hexadecimal format.

The first command that you need to run to set up the boot server is setup_install_server -b. The -b option specifies that this computer will be a boot server. After this command is completed, clients can be added with the add_install_client command.

Setting Up the Install Server

Most of the time, the boot server and the install server are the same computer. However, they have different duties. The boot server provides the client with a boot configuration, and the install server contains the source files used to install Solaris. While the boot server must be on the same subnet as the client computer, the install server can be located virtually anywhere on the network.

The install server is configured with the setup_install_server command. When you execute this command, you will need to specify an empty directory in which you want the Solaris source files to be installed. The directory can be any directory you choose, but the directory must be shared so that JumpStart clients can access it across the network. Some administrators like to use /export/install as the source directory, whereas others like to create a /jumpstart/install directory.

The biggest requirement for the install server is disk space. You will be copying the installation files for Solaris 9 to the hard disk, so it's best to make sure that you have about 1GB of free space. Also, if you're copying Solaris for both SPARC and Intel platforms, you can count on needing double the free space.

Because most of the time your boot server and install server will be the same computer, you can set both of them up at once. After inserting the Solaris 9 Installation CD, here's what you need to do:

 # cd /cdrom/cdrom0/s0/Solaris_9/Tools # ./setup_install_server /jumpstart/install

The first command line shows you the directory you need to be in. The second command line issues the setup_install_server command, with the /jumpstart/install directory as the JumpStart source directory. If you're using the CD-ROM version of Solaris as the source files, you will also need to copy both Solaris 9 Software CDs to the install directory as well. (If you're using the DVD-ROM version, all required files are located on the single DVD.) Here's how you can expedite that process (insert the Solaris 9 Software 1 of 2 CD first):

 # ./add_to_install_server /jumpstart/install

The add_to_install_server program will add the Solaris Software 1 of 2 CD to the image on the server. If you don't want to add the entire CD, but only a subset of packages, use the add_to_install_server -s option. When the copy process is finished, repeat the process with the Solaris Software 2 of 2 CD, and the Solaris 9 Languages CD, if needed. After the software is copied, you can also use the patchadd -c command to patch the image, so that clients will not need to be patched after their initial installation.

Configuring the Profile Server

The profile server contains the rules files and profiles for Solaris installations. These files will be located in a JumpStart directory. This directory can be any directory you want as long as it's in the root directory (/) of the profile server. For convenience, many administrators create a /jumpstart directory. The profile server can be the same computer as the install and/or boot servers, or it can be a different computer.

You must have superuser or equivalent privileges to create this directory. Here's how to create the JumpStart directory that will contain the rules files and profiles:

Create the JumpStart directory. It can be called anything you want, but it must be located in the root directory of the profile server. The permissions should be set to 755.
```
 # mkdir -m 755 /jumpstart 
```
Edit the /etc/dfs/dfstab file to share the new directory. You want to allow anonymous access.
```
 # share -F nfs -o ro,anon=0 /jumpstart 
```
Share the new directory.
```
 # shareall 
```
The directory is now created and shared. If you have already created your rules files and profiles, you can now copy them to this location. If, instead, you would like to copy some sample files from the Solaris 9 Software 1 of 2 CD, use the following command:
```
 # cp -r /cdrom/cdrom0/s0/Solaris_9/Misc/jumpstart_sample/* /jumpstart 
```

Now that your JumpStart directory is created, you need to allow client computers access to the directory.

Configuring Clients to Access the Profile Server

You can grant access to clients in one of three ways:

Use the add_install_client -c command
Use the boot command
Edit the /etc/bootparams file

Perhaps the most convenient way is to use the add_install_client -c command. It needs to be run once for each client.

By using the boot command, you can specify the location of the JumpStart directory when you boot the client computer. For this to work correctly, you must first compress the custom JumpStart configuration files into one file by using tar, compressed tar, zip, or bzip tar formats. Next, store the compressed file on an NFS server, an HTTP server, or local media for the client system to access. Then issue the following command:

 ok boot cdrom:net - install url:ask

This syntax might be a bit confusing if you're not familiar with the boot command. The first option specifies to boot from either the CD-ROM or the network. You use either cdrom or net as your option. The -install argument is the key, as it tells the boot program that you are attempting an installation. Finally, you can specify a URL pointing to the configuration files, or use the argument ask, which will prompt you for the location of the compressed configuration file after the client computer boots and attaches to the network.

Table 16.2 lists some examples of URL syntax to use with the boot command.

Table 16.2: *boot* Command URL Examples
File Location	Syntax
Local hard disk	file://jumpstart_dir/compressed_config_file file://jumpstart/config.tar
NFS server	nfs://server_name:server_IP/jumpstart_dir/compressed_ config_file nfs://Athena/jumpstart/config.tar nfs://192.168.0.33/jumpstart/config.tar
HTTP server	http://server_name:server_IP/jumpstart_dir/compressed_ config_file http://www.solarisbook.com/jumpstart/config.tar http://192.168.0.34/jumpstart/config.tar
HTTP server behind a proxy server	http://server_name:server_IP/jumpstart_dir/compressed_config_file&proxy_info http://www.solarisbook.com/jumpstart/config.tar&proxy =192.168.0.35

If you are using a sysidcfg file and placed the file in the compressed configuration file, then you must use the server's IP address instead of the server's name. If you are putting the compressed file on an HTTP server that's behind a proxy server, then you must specify the proxy information, but you do not need to use the IP address of the server.

The final option is to use a wildcard in the /etc/bootparams file on the boot server. The wild-card entry needed in bootparams will look like * install_config=server:jumpstart_dir. For example, if your JumpStart server is named Athena, and the directory is called /jumpstart, your line would be * install_config=Athena:/jumpstart. This will enable all clients to access the profile server, instead of creating lines for each specific client.

Editing the bootparams file to help locate the JumpStart server can cause the following error message to appear on clients attempting to connect:

 WARNING: getfile: RPC failed: error 5: (RPC Timed out).

This error message occurs for one of three reasons. The first is that there are /etc/bootparams files on more than one server with an entry for this client. Check to make sure that only one boot server has an entry for this client (or the wildcard) in /etc/bootparams. The second and closely related possibility is that one boot server on the network has a bootparams entry specifically for the client, whereas another server has the wildcard * install_config= line. Either remove the wildcard line or remove the entry for the specific client computer. The third potential cause is that multiple instances of the /tftpboot or /rplboot directories exist for this client. Make sure that only one exists for the client.

Using Profile Diskettes

So far, the profile server has been discussed, but you have another option for stand-alone client computers. You can create a profile diskette. If you want to install a large number of client computers, but you have no network, this is a great option.

Instead of creating a JumpStart directory on a profile server, you are going to create the same directory, including the rules, rules.ok, profile, and sysidcfg files on the disk. Then, when you install the client by using the local CD-ROM or DVD-ROM, the disk can provide all the necessary answers to complete the automated installation.

First, format a floppy disk, and create a UFS file system on the disk. Then, create a JumpStart directory. If you like using the /jumpstart convention, then by all means keep using it for the floppy. After that directory is created, make sure that the root has ownership of the directory and that the permissions are set to 755. Finally, copy the custom JumpStart configuration files to the /jumpstart directory on the floppy disk.

To use the profile diskette, boot the computer with both the disk and the Solaris 9 Installation CD-ROM inserted, and begin the installation. For example, to boot to the CD-ROM and install, you could use the following command:

 ok boot cdrom - install ask

Provided that your configuration files were created properly, the installation should proceed unattended.

Creating rules Files and Profiles

Now that you've learned about the server roles critical to JumpStart, it's time to focus on the files that make JumpStart work. These files must be located in the JumpStart directory on the profile server or profile diskette.

Understanding rules Files

A rules file is a text file containing a rule for each group of systems that you are going to be installing Solaris on. Each rule identifies a group of computers based on one or more system attributes. When first learning about JumpStart in this chapter, you read an example of installing 100 client computers. Fifty of them were in the R&D group, and the other fifty were in the administrative group. Because you have two groups, you need two rules, one to identify each group. Later in this section, you will learn how you can differentiate the two groups. You can create one rules file with both rules, or separate rules files for each group. Generally, it's better to go with the single rules file as to avoid confusion during installations, but the choice is up to you.

Each rule is responsible for first distinguishing a group of computers and then linking each group to a profile. The rule determines which computers get which profile, and then the profile determines how to install Solaris.

The name of the rules file should not be changed, and for it to work, it must contain at least one rule. The rules file can also contain comments, blank lines, and rules that use multiple lines. To continue a rule on a second line, place a backslash (\) at the end of a line and press Enter. A rules file can be created from any text editor, or you can modify the sample rules file provided on the Solaris 9 Software 1 of 2 CD.

Note

The rules file should be owned by root and have permissions of 644.

Here is part of the sample rules file from the CD-ROM:

 # The rules file is a text file used to create the rules.ok file for # a custom JumpStart installation. The rules file is a lookup table # consisting of one or more rules that define matches between system # attributes and profiles. # # This example rules file contains: #   o syntax of a rule used in the rules file #   o rule_keyword and rule_value descriptions #   o rule examples # # See the installation manual for a complete description of the rules file. # # RULE EXAMPLES # # The following rule matches only one system: # hostname sample_host    -       host_class      set_root_pw # The following rule matches any system that is on the 924.222.43.0 network # and has the sun4c kernel architecture: #    Note: The backslash (\) is used to continue the rule to a new line. network 924.222.43.0 && \         karch sun4c     -       net924_sun4c    - # The following rule matches any sparc system with a c0t3d0 disk that # is between 400 to 600 MBytes and has Solaris 2.1 installed on it: arch sparc && \          disksize c0t3d0 400-600 && \          installed c0t3d0s0 solaris_2.1 - upgrade  - # # The following rule matches all x86 systems: arch i386   x86-begin   x86-class   - # The following rule matches any system: any -   -   any_machine  -

The full sample rules file does a good job of explaining the syntax and options for creating rules. The only problem is that it's more than three pages long. Remember that if you use the sample file to make your own rules, comment out the included rule examples with a pound sign (#).

Here is the syntax for rule entries in the rules file:

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

The brackets ([ and ]) indicate optional fields. The exclamation point (!) is used to negate keywords, and the double and symbols (&&) are used to tie more than one rule keyword and value pair together. Table 16.3 describes the fields within the rules file.

Table 16.3: *rules* Fields
Field	Description
rule_keyword	A predefined term that describes a general system attribute, such as the host name, memory size, hard disk size, or processor architecture.
rule_value	A value that describes the keyword, such as the host name, size of the memory or hard disk, or processor architecture.
begin	An optional Bourne shell (sh) script to run before the installation begins. If you do not want to run a begin script, fill this field with a minus sign (-). All begin scripts must be located in the JumpStart directory.
profile	The name of the profile to be used by computers that fit this rule. All profiles must be located in the JumpStart directory.
finish	An optional Bourne shell (sh) script to be executed after the installation is complete. If you are not using a finish script, place a minus sign (-) in this field. All finish scripts must be located in the JumpStart directory.

At the very least, each rule must contain a keyword, a value, and a profile. Here's a simple entry that you might find in a rules file:

 karch sun4u - profile1 -

The rule_keyword is karch (kernel architecture, or platform group), and the rule_value is sun4u, indicating the sun4u platform. There is no begin or finish script specified, and the profile that all sun4u computers will use is named profile1.

There are 14 rule keywords available for your use. Table 16.4 lists these keywords, the possible value types, and a brief description of each.

Table 16.4: Rule Keywords and Values
Keyword	Value(s)	Description
any	A minus sign (-)	The any keyword matches all computers.
arch	processor_type	The system's processor type, as returned by the uname -p command. An example of a valid value is sparc.
disksize	disk_name size_range	The name and size of the computer's disk, in megabytes. The disk name is in the form of cxtydz, such as c0t3d0, or the word rootdisk. The rootdisk value will match to the disk that has the preinstalled boot image, the c0t3d0 disk, or the first available disk that is found by a kernel probe. The size range must be specified in megabytes. Example: disksize c0t3d0 750-1000.
domainname	domain_name	The name of the domain that the computer belongs to.
hostaddress	IP_address	The IP address of the computer.
hostname	host_name	The name of the computer.
installed	slice version	This keyword is looking for computers that already have Solaris installed. The slice value means a computer with Solaris installed on that slice, and the version value matches to specific versions of Solaris. The slice value is in the form cwtxdysz, or the special word rootdisk. The version value can have a Solaris version name, or the words any or upgrade. If any is used, all Solaris versions are matched. If upgrade is used, then any Solaris 2.1 or compatible version that can be upgraded is matched.
karch	platform_group	The computer's platform group. You can find this information by using the arch -k and uname -m commands.
memsize	physical_memory	The amount of memory in the computer, specified in megabytes. This can be a single number or a range.
model	platform_name	The computer's platform name. You can find this information with the uname -i command or the prtconf command, line 5.
network	network_number	The network address of the computer (not necessarily the entire IP address).
osname	Solaris_x	A version of Solaris already installed on the computer. Example: osname Solaris_8.
probe	probe_keyword	A probe keyword. Probe keywords are used by custom_probe files, which, in a nutshell, ask the computer for information, return a value, and then take a course of action determined by the returned value.
totaldisk	total_disk_size	The total disk size on the computer, specified as a megabyte range. This includes all hard disks installed in the computer.

Note

When calculating disk size or memory size, remember that one megabyte is equal to 1,048,576 bytes. This might throw you off in your ranges. For example, an 800MB hard disk will appear to JumpStart as a 763MB hard disk (800,000,000 / 1,048,576 = 763). Therefore, a range of 775-825 will not match to this hard disk.

As you can see from Table 16.4, some keywords are designed for only one computer (such as hostname or hostaddress), while others can include the entire network (such as domainname or any). When configuring a rules file, you really have all the granularity you could possibly want.

Tip

If you want one profile to be used to install all computers on your network, the rule should read any - - profile_name -, where profile_name is the name of the profile you want to use.

Now that you know the structure of the rules file and what the keywords are, here are five sample entries to look at:

 hostname Sol-1 - sol_profile - network 192.168.0.32 && karch sun4u begin1 4u_profile finish1 network 192.168.0.32 && !karch sun4u begin2 otro_profile finish2 model SUNW,Sun-Blade-100 - blade_profile backup any - - basic_profile -

The first entry will match to only the Sol-1 computer. It will install by using the sol_profile profile, and not use a begin or a finish script. The second line will match to computers that are on the 192.168.0.32 network and have the sun4u architecture. The 4u_profile will be used, as will the begin1 and finish1 scripts. The third entry will match to the computers on the same network as the second entry, but only those that are not sun4u computers. The profile will be otro_profile, and begin2 and finish2 are the begin and finish scripts. The fourth entry matches to Sun Blade 100 computers, with no begin script, the blade_profile profile, and the backup finish script. The final entry matches to all computers and runs the basic_profile.

Keep in mind that when JumpStart installs, it searches the rules.ok file and uses the profile that it finds when it receives its first client match. So if you put the any entry first, then all computers would get the basic_profile.

Tip

Be familiar with the rules file syntax before you take the exam.

Validating the rules File

Before the rules file can be used, it must be validated with the check script. The check script ensures that the rules file is set up correctly. If so, a validated rules.ok file is created.

The check script is in the Solaris_9/Misc/jumpstart_sample directory on the Solaris 9 Software 1 of 2 CD, as well as on the Solaris 9 DVD. You can also find it in the JumpStart directory on your hard disk if you copied the sample files from your source media. Here's the syntax for check:

 # ./check -p path -r file_name

The -p option enables you to specify a specific path for the check script. The -r option is used if you are using a file named something besides rules. In most cases, you will run check with no command-line options.

If the check script finds no errors in the rules file, it creates a rules.ok file, which is the file used by JumpStart to match client computers. When no errors are encountered, the computer will return the message The custom JumpStart configuration is ok.

Using Begin Scripts

Begin scripts are Bourne shell (sh) scripts that run before the Solaris installation takes place. Begin scripts are called from the rules file and can be used only if you're performing a custom JumpStart installation.

A begin script is used primarily to perform one of two functions: to create a derived profile or to back up existing files before upgrading Solaris.

A derived profile is used when you cannot set up a rules file to match some of your computers to a profile. For example, you might have systems that are the same model, but have different hardware configurations. A begin script can dynamically create a derived profile to match the computers.

To use a derived profile, set the profile field to an equal sign (=) in the rules file for the computers you want to match. Then, specify a begin script that creates a derived profile depending on the system hardware of the computer on which you want to install Solaris. The derived profile will then be used instead of the standard profile.

When creating begin scripts, make sure that root owns the file and that permissions are set to 644. Also, ensure that nothing in the script will prevent the mounting of file systems onto /a during the initial install or upgrade. If JumpStart cannot mount file systems onto /a, the installation will fail. Output from the begin script will be logged in /var/sadm/ begin.log.

Using Finish Scripts

Finish scripts are Bourne shell (sh) scripts that run after the Solaris installation takes place, but before the computer reboots. Finish scripts are called from the rules file and can be used only if you're performing a custom JumpStart installation.

Finish scripts enable you to add additional files to the computer, add individual software packages or patches, customize the root environment, set the computer's root password, and install additional software as needed.

Finish scripts should be located in the JumpStart directory, be owned by root, and have permissions of 644. Also know that the suninstall program mounts file systems on /a during the installation, and those file systems remain mounted on /a until the computer reboots. So if you're modifying file systems with a finish script, remember to modify the correct file system in relation to /a.

You can use custom JumpStart environment variables in finish scripts. Output from finish scripts is logged in /var/sadm/finish.log.

Note

Creating begin and finish scripts is beyond the scope of the Sun Certified System Administrator exams and this book. For detailed information on creating these scripts, see the Solaris 9 Installation Guide, available at docs.sun.com.

Understanding Profiles

After the rules file matches a client computer to one of its rules, the custom JumpStart installation process calls a profile to determine how to install Solaris. A profile is a text file that defines how to install Solaris on that particular computer. There are no restrictions on how you can define rules and profiles. Several rules might use the same profile, or you can have separate profiles for every rule.

Compared to the rules file, the syntax of profiles is pretty basic. All a profile contains is a list of keywords and their associated values. Each keyword controls how a specific aspect of Solaris is to be installed. Enter one keyword and value pair per line.

You can name a profile anything you would like, but it's a good idea to name it something that makes sense based on what you're using it for. For example, an accounting profile might be called acct_profile, or the general network profile might be called basic_profile. Profiles must be located in the JumpStart directory, be owned by root, and have permissions of 644.

Note

Profiles used to be called class files.

A profile must contain the install_type keyword as its first entry. Also, if the computer is being upgraded and contains more than one root file system (/) that can be upgraded, the root_ device keyword is needed. Profiles can contain blank lines and can also contain comments preceded with a pound sign (#).

To create a profile, you can use any text editor, or you can use one of the sample profiles provided in the Solaris_9/Misc/jumpstart_sample directory on the Solaris 9 Software 1 of 2 CD, as well as on the Solaris 9 DVD.

Table 16.5 lists the 20 valid profile keywords and the situations when they can be used.

Table 16.5: Profile Keywords
Keyword	Description	To Be Used When…
archive_location	Location of the Web Start Flash archive (if applicable).	Installing a stand-alone non-networked or networked client, or a networked server.
backup_media	Location used to back up file systems if disk space will be reallocated during an upgrade.	Upgrading a computer and using disk space reallocation.
boot_device	Device where JumpStart will install the root file system (/) and boot device.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
client_arch	The platform that the OS server will support, when it's a different platform than what the OS server uses.	Installing an OS server.
client_root	The amount of root file system (/) space reserved for each client.	Installing an OS server.
client_swap	The amount of swap space to reserve for each diskless client.	Installing an OS server.
cluster (adding software groups)	The software group to add to the client computer.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
cluster (adding or deleting clusters)	The cluster to add or delete from the software group.	Installing or upgrading in all situations.
dontuse	One or more hard disks that you don't want JumpStart to use.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
filesys (mounting remote file systems)	Remote file systems that installed clients will automatically mount when they boot.	Installing a stand-alone networked client, a networked server, or an OS server.
filesys (creating local file systems)	Specific local file systems that will be created during the installation.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
geo	The regional locale or locales you want to install.	Installing or upgrading in all situations.
install_type	The installation type, such as initial_install, upgrade, or flash_install.	Installing or upgrading in all situations.
isa_bits	The version of Solaris to be installed (32-bit or 64-bit).	Installing or upgrading in all situations.
layout_constraint	The constraints that auto-layout has on the existing file systems.	Upgrading a computer and using disk space reallocation.
locale	The locale of the packages you want to install or add.	All installation or upgrade situations.
num_clients	The number of diskless clients that the OS sever can support.	Installing an OS server.
package	The software package to be added or deleted from the software group.	Installing or upgrading in all situations.
partitioning	The way that the hard disks will be divided into slices.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
root_device	The installed computer's root disk.	Installing or upgrading in all situations.
system_type	The type of system, such as server or standalone.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.
usedisk	The hard disk that you want JumpStart to use.	Installing a stand-alone non-networked or networked client, a networked server, or an OS server.

Based on this table, you can tell that there are quite a few options you can use with a custom JumpStart installation. Some options are commonly used, whereas others are rarely employed. Following are some examples of profiles, and explanations of the keyword and value combinations used.

Note

The package names for the software groups are: SUNWCreq for Core, SUNWCuser for User, SUNWCprog for Developer, SUNWCall for Entire, and SUNWCXall for Entire Plus OEM.

Examples of Profiles

The sample profiles provided in the Solaris_9/Misc/jumpstart_sample directory on the Solaris 9 Software 1 of 2 CD and the Solaris 9 DVD provide a good place to start if you're not sure what you want in your profile. Even experienced administrators will tell you, though, to get profiles to work exactly the way you want them to takes trial and error.

This first example is one of the easiest profiles you will see. It's designed to perform an initial installation (as opposed to an upgrade) on a stand-alone computer by using default partitioning and installing the End User software group:

 install_type    initial_install system_type     standalone partitioning    default cluster         SUNWCuser

Most of the value types listed in this first example should be self-explanatory. The last value, SUNWCuser, is the designation for the Solaris End User software group. You can specify only one software group in a profile. You can, however, add or remove software clusters from the group. Just make sure to list the group before using other cluster or package keywords.

This next example deletes a cluster, as well as adds a cluster:

 install_type     initial_install system_type      standalone partitioning     default cluster          SUNWCuser cluster          SUNWCxgl delete package          SUNWaudmo add filesys          any 40 swap filesys          any 50 /opt

After this profile installs the End User software group, it deletes the SUNWCxgl cluster and adds the SUNWaudmo package. This profile also places the swap space (40MB) on any slice, and the /opt file system (50MB) on any slice.

Here's one more example initial installation:

 install_type     initial_install system_type      server partitioning     default cluster          SUNWCall num_clients      7 client_swap      32 client_arch      sun4c client_arch      sun4m filesys          c0t3d0s0 20 / filesys          c0t3d0s1 40 swap filesys          c0t3d0s5 80 /opt

This initial installation will install an OS server by using the Entire Solaris software group (SUNWCall). You can tell that this will be an OS server for diskless clients because of the num_clients and three client_* keywords. Also notice that this profile is specific about which slice the root (/), swap, and /opt file systems will be on.

If the first example in this section is one of the easiest to look at, then this next one must be the easiest:

 install_type upgrade

That's it. Remember that the only required keyword is install_type, and in this case, it's an upgrade with no frills. Simply upgrade the computer; that's it.

But because all upgrades aren't that simple, take a look at another upgrade example. This time, the profile will reallocate disk space during the upgrade:

 install_type      upgrade root_device       c0t3d0s2 backup_media      remote_filesystem server1:/export/backup layout_constraint c0t3d0s2 changeable 100 layout_constraint c0t3d0s4 changeable layout_constraint c0t3d0s5 movable cluster           SUNWCall package           SUNWbcp delete package           SUNWxwman add locale            ja

This upgrade profile is the most complex example yet. You can see that it's an upgrade and that the root file system (/) will be placed on c0t3d0s2. This profile also specifies a remote file system located on the server1 server to back up files before the upgrade. You can also see that three file systems have layout constraints placed on them. For the c0t3d0s2 file system, the size can be changed, but the minimum size allowed is 100MB. The c0t3d0s4 file system can also be changed, but because no minimum size was specified, the smallest it can be is 110 percent of its original size. The c0t3d0s5 file system can be moved to a different hard disk if the auto-layout process determines that to be the best course of action. The only other new option in this profile is locale, which specifies the Japanese locale (ja).

As you can see, you can specify a large number of options by using the 20 available keywords. The best way to create a profile is to research your options, create a profile, and then test it to make sure it works. For more information on profile keywords, values, and options, see the Solaris 9 Installation Guide, available at docs.sun.com.

Testing Profiles

It would be annoying to have to perform a complete installation of Solaris to see whether your profile is configured correctly. Because of the obvious need, Sun has developed a tool to help you test profiles. The pfinstall command can be used to test your profile before you begin an installation.

If you're testing an installation of Solaris 9, then you must run the pfinstall program on a Solaris 9 computer. If you don't already have Solaris 9 installed, you can boot to the Solaris 9 Software 1 of 2 CD (or the Solaris 9 DVD), exit the setup program, and perform your test from the shell. If you're testing an upgrade, test it on the computer that you intend on upgrading.

Here is how to test a profile:

Locate a system to perform the test on, and ensure that you have superuser or equivalent privileges.
Create a temporary mount point for the test.
```
 # mkdir /tmp/mount 
```

Mount the directory that contains the profile you want to test.

 # mount -F nfs server_name:path /tmp/mount

 # mount -f ufs /dev/diskette /tmp/mount

If you mounted a directory in step 3, change to that directory. If not, change to the directory that contains the profile, which should be the JumpStart directory.
```
 # cd /tmp/mount 
```
or
```
 # cd /jumpstart 
```

Test the profile.

 # /usr/sbin/install.d/pfinstall -D profile

Warning

If you do not use the -D option, then the install will take place, and your existing data will be overwritten. An alternative to -D is the -d disk_config_file option, if you are using a disk configuration file.

If your profile works, and your rules file has been validated, and your JumpStart servers are up and running, you should be ready to install!

Real World Scenario: Upgrading the Network to Solaris 9

The Pinkeel company has hired you to upgrade their network to Solaris 9. They are in the planning stages of upgrading their current installation and are dedicated to using JumpStart. On their network, they have a centralized server room and 120 client computers. Of those, 90 clients are part of the development group, and 30 are administrative staff, including human resources, accounting, marketing, and general management. The network has four subnets: the server room is one, the development group is equally divided between two subnets, and the administrative staff is on its own subnet.

Most of the clients on the network have Solaris 8 installed, but a handful of computers have older Solaris versions. All computers need to be upgraded to Solaris 9.

The first thing you need to do is create the install server. The company has a server available in the server room, named BigFish, that will serve as the JumpStart server. Use the setup_ install_server command to designate BigFish as the install server and then copy the Solaris software CDs to the server's JumpStart directory. For the sake of ease, you will create and use a directory named /jumpstart. Don't forget to share it!

Because the install server is on a different subnet than the JumpStart clients, you will need a boot server on each subnet. You will need three boot servers: one for each development subnet and one for the administrative subnet. The boot servers can be any computer on the subnet; they don't specifically need to be a server. Use the setup_install_server -b command to set these computers up.

Next, create profiles for the client computers. It's likely that you will need two profiles: one for the development computers and another for the administrative staff. The install_type will be upgrade. Other than that keyword, you can configure the profiles however you want. For example, you could assign the End User software group to the administrative staff, and the Developers software group to the developer staff.

Then, add rules to the rules file. The most logical way to identify computers on this network is based on network address. You can do that with the network keyword. Assign the correct profiles to the rules you create. Then, validate the rules file by running the check script and creating a rules.ok file.

Back on the BigFish server, use the add_install_client command to add the clients you want to install across the network. Because you have 120 clients, this might take a little while.

Finally, on each client, boot to the network by using the boot net -install command at the ok prompt. The installation should begin.

There isn't necessarily a specific order in which you need to complete all of these tasks. For example, you could run add_install_client before you even create the profiles or rules files. Or, you could create the rules file before the profiles. The order of creation doesn't matter, as long as they exist before you begin the installation.

Custom JumpStart installations are flexible and enable you to install a large number of computers in a relatively small amount of time. Using JumpStart takes some setup work, but will likely save you a lot of time in the long run.