Americas

  • United States
sandra_henrystocker
Unix Dweeb

Setting up Jumpstart clients: Create a profile

Analysis
Jul 17, 20085 mins
Data CenterEnterprise ApplicationsOpen Source

Configuration of Jumpstart clients requires creating a profile as well as adding the client’s hostname, IP address and MAC address to the appropriate files on the

jumpstart server. A client profile can include the type of installation being performed (e.g., an upgrade or initial install), the system type (standalone or server), partitioning information, the particular cluster you want installed (e.g., the entire distribution or end user support) and particular packages that you want to omit or include beyond the specified cluster. Profiles can be extremely skimpy or can include a lot of detail.

Only the install_type is required for Solaris 10 jumpstart installations, plus the root_device specification if the system contains more than one root file system (e.g., if you have an alternate root you can boot from and want both upgraded).

Profiles are simple text files created with your favorite text editor. In the example shown below, we are requesting an initial install using the default partitioning. We are installing the developer cluster, but omitting man pages.

install_type            initial_install
system_type             standalone
partitioning            default
filesys                 any 1024 swap
cluster                 SUNWCprog
package                 SUNWman delete

You can start with the sample_profile provided with the jumpstart setup if you wish. It will look something like this:

install_type    initial_install
cluster         SUNWCXall
partitioning    explicit
filesys         c0t0d0s0 14000 /
filesys         c0t0d0s1 4096 swap
system_type     standalone

Note that this default profile specifies a specific layout of the file systems.

Client profiles can also include patches, though many sysadmins install patches in scripts that are run following the basic installation. Patches are specified with the patch keyword. In this example, the patch is obtained from another system.

patch 118855-33 nfs 10.2.10.1:/jumpstart/patches

The layput_constraint keyword specifies limits you want to place on auto-layout. For example, you can specify a minimal size for file systems as shown in this example in which two file systems must be allocated at least 2 GB each:

layout_constraint c0t0d0s4 changable 2000
layout_constraint c0t0d0s5 changable 2000

Profiles must be referenced in your rules file to tell jumpstart when to use then. In this example, we are telling jumpstart to use the profile boson_profile for the client boson and fermion_profile for fermion. You do not not need to build a profile for every system you are going to jumpstart. If a number of systems are to be installed identically, you can use the same profile for all of them. You might, for example, have a netrax1 profile or an sunfirex4540 profile.

hostname boson - boson_profile -
hostname fermion - fermion_profile -

If you want to run scripts prior to and after the OS installation, but as part of the jumpstart procedure, your rules file might look like this instead:

hostname boson begin boson_profile finish
hostname fermion begin fermion_profile finish

In this example, “begin” and “finish” are the names of your scripts. You might want to have a set of begin and finish scripts for each type of system you are setting up. You could, for example, use a finish script to set up your

/etc/resolv.conf file and set up your /etc/nsswitch.conf file:

#!/bin/sh
# finish_dns

echo "domain mydomain.com" > /etc/resolv.conf
echo "nameserver 10.3.4.5" > /etc/resolv.conf
echo "nameserver 10.10.0.1" > /etc/resolv.conf
echo "search mydomain.com lab.mydomain.comt" > /etc/resolv.conf

cp /etc/nsswitch.dns /etc/nsswitch.conf

Once your rules file is ready, run the check script to verify your rules file and create the rules.ok file. If you specify begin and end scripts, but check doesn’t find them, you will see an error such as this:

# ./check
Validating rules...

Error in file "rules", line 1
        hostname boson begin boson_profile finish
ERROR: Begin script missing: begin

If check finds no errors, it will generate output like this and create a rules.ok file. The rules.ok file looks almost identical to the rules file, but contains a checksum.

# ./check
Validating rules...
Validating profile boson_profile...
Validating profile fermion_profile...
The custom JumpStart configuration is ok.
# cat rules.ok
hostname boson begin boson_profile finish
hostname fermion begin fermion_profile finish
# version=2 checksum=8608

When you boot your client with a “boot net – install” command at the ok prompt, a number of things will happen.

First, your client will issue a RARP request to get its IP address from the boot server (it will be running in.rarpd daemon). The server will look in its /etc/ethers and /etc/hosts files to get the hostname and IP address of the

client. RARP cannot be routed, so the boot server needs to be on same subnet as the client.

Next, the client gets boot image from the boot server using tftp. It gets its bootparameters from rpc.bootparamd running on the server.

Next, the client mounts its root file system from the server and loads the kernel.

The client then connects to llthe insta server and initiates the OS installation.

Client profiles can be extremely terse or can include a lot of detail about the install. In general, the more you put into your profiles, the less information you will have to provide during the install and the easier a time you will have

reinstalling the system back to its original state if you replace a disk or need to start again from a predictable state.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.