Article

may2000.tar

Building a Jumpstart Server for Solaris

Peter van der Weerd

In today's computing environments, machines are often just a means to get to the data storage media. They are either there to offer you a place to log into and work from, or to create a path to your data and applications. Every machine that you use, regardless of its purpose, must first be configured. Minimally, you will have to install the OS and perhaps also install additional packages and configure application-dependent files or scripts.

To reduce this installation time, every UNIX variant has some product that offers automated installation of clients. As it happens, most of these tools have a graphical interface. This article deals with the Solaris version of network install. Solaris and graphical user interfaces have never been the best match (no offense); the same goes for the Solaris network installation product, “Jumpstart”. To get a working Jumpstart server, you will have to do some additional configuring that cannot be done by using a GUI. To avoid the use of a GUI altogether, I will discuss a complete manual configuration.

How Does Jumpstart Work?

A new machine (client) is physically connected to a network segment. You switch it on, and the client has one or more disks with nothing on them -- not even a bootblock. The client will end up in the Open Boot Prom. In the case of a bootable disk, you can interrupt the boot sequence by pressing <Stop>+<a>.

From the Open Boot Prom, you type boot net - install. This will cause a reset and subsequent boot from the network with the option “install” added to it. Keep in mind that this only applies to Sun's sparc machines. Other vendors also support network install clients and servers, but the options and arguments will differ:

1. All the client knows is its own Ethernet address. What it needs, however, is its IP address. To get its IP address, the client broadcasts a RARP request. A boot server, running the in.rarpd daemon, receives the request and checks its ethers table /etc/ethers for the Ethernet address. This boot server must be in the same subnet because RARP works on the Ethernet level and cannot be routed. The ethers file holds the client's Ethernet address and hostname. The hostname is used to find the client's IP address in the host file /etc/hosts. The server replies to the request, thus providing the client with its IP address.

2. The client now needs a bootimage. This bootimage is obtained with a tftp request. The tftp request is a built-in request initiated from the open boot PROM and fully automatic because of the net option in the boot net -install command. The server holds a bootimage for every client in the tftpboot directory /tftpboot. This directory holds the hexadecimal IP address that is linked to the client stub:

C00C6E0A - > inetboot.SUN4U.Solaris_2.6-1

This example is a machine with Ultra architecture using a 2.6 bootimage and has the IP address 192.12.110.10.

3. When the client has loaded the bootimage, it will request further parameters concerning identification, software, and configuration. This information will be rendered by the bootparams daemon on the server: rpc.bootparamd. The bootparams information is stored in the server's /etc/bootparams file.

4. Among other things that I will cover, the bootparams file contains the Solaris software directory on the server. The client needs this to get the kernel /kernel/genunix. The client mounts the root filesystem (/) from the server and loads the kernel.

5. Finally, the client connects to the configuration server, which is also in the bootparams file and may well be the same server as the boot server. This configuration server holds the necessary information for the client to identify itself (sysidtool) and run a proper installation (suninstall).

Installation Procedure

Solaris installation basically consists of three steps:

System identification (sysidtool)
Software installation (suninstall)
Configuration of installed software

These three steps can be fully automated and configured to your own needs. This is what the client needs to find:

Directory where the Solaris software (including the kernel) resides
Directory for system identification script
Directory for suninstall scripts

System Identification

The client will need the following information to be identifiable by itself and others:

1. Language and locale
2. Hostname
3. Whether it is networked or not
4. Network interface
5. IP address
6. Nameservice
7. Netmask
8. Timezone

Regardless of the fact that the client could get the IP address and hostname from the server since it managed to boot, it will still run the system identification tool as if totally ignorant, so you will have to provide it with the information it will normally get from the keyboard. This information is all stored in a system identification configuration file: sysidcfg. This file can be in any directory you like, as long as it is mentioned in the bootparams file. Every client should have its own sysidcfg file.

Suninstall

The client will need to know whether it is going to get an initial install or upgrade. It also must know which software packages or software cluster it is going to get. This information is provided in a “class file”. This file will be in the jumpstart configuration directory. This directory can be any directory on the server but is preferably a dedicated directory. The name of this configuration directory can be regarded as a boot parameter, so it is stored in the /etc/bootparams.

I will first list the files and directories needed, with their respective contents. After that, they will be implemented in an example configuration:

1. /etc/ethers (file) -- Contains Ethernet address and hostname, needed for RARP reply.
2. /etc/hosts (file) -- Contains IP address and hostname, needed for RARP reply.
3. /tftpboot (dir) -- Contains IP address (hexadecimal) and bootimage.
4. /etc/bootparams (file) -- Contains information needed for a number of things. Here's an example:

berlin root=sp5:/cdrom/cdrom0/s0/Solaris_2.6/Tools/Boot
install=sp5:/cdrom/cdrom0/s0
boottype=:in
sysid_config=sp5:/usr/local/jumpstart
install_config=sp5:/usr/local/jumpstart

“Hostname” is “berlin”; “root” specifies the directory for the kernel; “install” specifies the software location; “boottype” specifies the type of client (install); “sysidconfig” specifies the location of the sysidcfg file; “install_config” specifies the directory that contains files needed for suninstall.

5. sysidcfg (file) -- Located in the directory that is specified by the sysid_config entry in /etc/bootparams (see 4). This file identifies the client. Another example:

system_locale=en_US
timezone=MET
name_service=NONE
terminal=dtterm
timeserver=localhost
network_interface=le0 {netmask=255.255.255.0}

This example is not complete and you can specify more or less. I left out the root password, for example.

6. host_class (file) -- This file is located in the directory specified by the install_config entry in /etc/bootparams (see 4). An example:

install_type    initial_install
system_type     standalone
partitioning    explicit
filesys         any     64      swap
filesys         any     free    /
cluster         SUNWCall

Although this file also has more options than shown, these are the most important and most used options. The machine that owns this file will end up as a standalone client with a 64-Meg swap device and a rootslice that covers the rest of the drive. In this particular example, it is not interesting to know what drive is used for the installation of Solaris (value of keyword filesys : any). You can imagine that if you would want the rootslice to be on a particular drive, you replace the value “any” with the slicename. SUNWCall causes the entire distribution to be installed. Other options here would be: SUNWprog (developer), SUNWuser (enduser) and SUNWreq (core OS).

7. begin_script (file) -- This file is also located in the configuration directory (see 4). It is run before the host_class file is run (see 6). The file can contain any instruction you like. It is an optional file.

8. finish_script (file) -- Yet another file for the configuration directory (see 4) and as optional as the begin_script. It is run after the host_class script has been run. Although optional, it is often used to set the root password as well as to install additional files or packages or patches.

9. rules (file) -- Also in the configuration directory. This file has a specific layout:

keyword value begin_script host_class finish_script.

An example is:

hostname berlin  -  sun4u_class_gen copy_passwd
arch_type sun4m  -  sun4m_class_gen -

There are many possible keywords; these are only a few. The sample script offered by Sun will give them all. In the example, the client named “berlin” will use no begin script, but it does have a host_class script and a finish script, sun4u_class_gen and copy_passwd, respectively. The second line specifies that any machine of the sun4m type will use the subsequent scripts on that line.

I hope you're still with me, and you probably now expect me to tell you that you must type out all of these files (like you should). However, Sun provides you with templates for all the files, except /etc/bootparams, but this file can be generated by a single instruction.

And Now for the Practical Example

I have a server called “mercury”, with the IP address 192.12.110.12, that I am going to configure into a jumpstart server. The server has the following drives to use: c0t0d0 (boot drive), and c0t2d0 (4-GB) drive that can be used for the jumpstart purpose. The server runs Solaris 2.6 and has the Solaris distribution CD inserted:

1. Software -- You can leave the OS software on the CD and install from that without a problem, but it will take more time (unless your CD player is faster than the c0t2d0 drive). I am going to use the drive. This also gives me the advantage of being able to install multiple clients with different Solaris versions at the same time.

To set up the install server, I create a 500-Meg partition and filesystem on the c0t2d0 drive and mount it to the directory /Solaris_2.6. This drive will hold the Solaris OS software. I CD to the Tools directory on the distribution CD:

# cd /cdrom/cdrom/0/s0/Solaris_2.6/Tools

I run the script that will copy the software to the newly created filesystem:

# ./setup_install_server /Solaris_2.6

This will take a while.

2. Configuration data -- I am going to set up one client that I want to be able to reinstall whenever I feel like it. I create the jumpstart configuration directory:

# mkdir /usr/local/jumpstart

I CD to the directory that holds the sample files, and copy them to /usr/local/jumpstart:

# cd /cdrom/cdrom/0/s0/Solaris_2.6/Misc/jumpstart_sample
# cp -r * /usr/local/jumpstart

The two directories will both be accessed by the client through NFS mounts, so I must not forget to share them:

# echo "share -F nfs -o ro /usr/local/jumpstart" >> /etc/dfs/dfstab
# shareall

(If this is the first share, you will have to stop and start the NFS server.)

I only share the configuration directory. The other one I'll deal with later. First, I will configure the clients' system identication and suninstall data.

# vi /usr/local/jumpstart/sysidcfg

     system_locale=en_US
     timezone=MET
     name_service=NONE
     terminal=dtterm
     timeserver=localhost
     root_password=h1HsSZX0qUQuU
     network_interface=le0 {netmask=255.255.255.0} 

# vi /usr/local/jumpstart/host_class

     install_type    initial_install
     system_type     standalone
     partitioning    default
     cluster         SUNWCuser
     cluster         SUNWCown delete
     cluster         SUNWCtltk delete
     cluster         SUNWCxgl delete
     cluster         SUNWCxil delete
     filesys         mercury:/usr/openwin - /usr/openwin ro,intr

My client will have an initial install on an arbitrary drive and with default partitioning and an entire distribution, but it will use the Windows environment from server mercury.

# vi /usr/local/jumpstart/rules

     hostname berlin  -  host_class copy_passwd

Obviously, my client is called berlin. To make sure the syntax and contents of the rules file are okay, I will have to run a check on the file. This check will create a rules.ok file. This is the actual file that will be used by jumpstart:

# cd /usr/local/jumpstart; ./check

Now, I am ready to really configure the client. I decide that the client IP address is going to be 192.12.110.99. On the box, I read the Ethernet address 8:0:20:43:12:ef. (You can also run the “banner” command from the Open Boot Prom on the client.) After I have added berlin to /etc/hosts, I run the following commands:

# cd /cdrom/cdrom0/s0/Solaris_2.6/Tools
# ./add_install_client -e  8:0:20:43:12:ef -i  192.12.110.99 \
  -s mercury:/Solaris_2.6 -c mercury:/usr/local/jumpstart -p \
  mercury:/usr/local/jumpstart berlin sun4u

I see that the instruction changes /etc/ethers, shares /Solaris_2.6 (the one I had neglected earlier), and updates /etc/bootparams. Make sure that /etc/ethers contains the proper information for berlin. Also check /tftpboot. It should contain the bootimage.

As you may have noticed, the finished script I use is called “copy_passwd”. For some reason or other, I want some users to always be able to log into berlin, and since I do not use NIS or NIS+, I will have to make sure that the users are in the /etc/passwd and /etc/shadow file. I do not want to do any manual configuration afterwards, so I ask jumpstart to do it for me. You can do whatever you like in the finished script. The root slice of the client is always mounted on /a during installation; I save the original passwd file and replace it with my own.

# vi /usr/local/jumpstart/copy_passwd

     cp /a/etc/passwd /a/etc/passwd.org
     cp /a/etc/shadow /a/etc/shadow.org
     cp /usr/local/jumpstart/copy_passwd/a/etc/passwd
     cp /usr/local/jumpstart/copy_shadow/a/etc/shadow

Now I stumble to berlin, give it a boot net - install, and sit back.

Troubleshooting Your Jumpstart Server

I could have partially configured the server using the GUI (hostmanager). The advantage of manually configuring the server is that I have to know what goes where and why, not for the sake of knowledge or because this is “UNIX-like”, but simply because I want to be able to troubleshoot my server. You can make your own checklist to troubleshoot. Here is mine:

1. Did I share the relevant directories (/Solaris_2.6 and /usr/local/jumpstart)?
2. Are in.rarpd and rpc.bootparamd running?
3. Did I create the rules.ok file by running check?
4. Is there an entry for my client in /tftpboot?
5. Is there an entry for my client in /etc/bootparams?
6. Is there an entry for my client in /etc/hosts and /etc/ethers?
7. I run snoop to trace the installation of my client.

When you run a test install, it will annoy you that you have to wait until the entire distribution is installed before you notice that the sysidcfg file has errors or even the finished script is incorrect. To speed up test installation, you can use SUNWreq (host_class). This is the smallest software cluster and takes only a couple of minutes to install (depending on the speed of the peripherals, of course).

About the Author

Peter van der Weerd works as a UNIX trainer and consultant for Sun Microsystems and Hewlett Packard in Europe.