Setting up a diskless client (Managing NFS and NIS, 2nd Edition)

8.2. Setting up a diskless client

To set up a diskless client, you must have the appropriate operating system software loaded on its boot server. If the client and server are of the same architecture, then they can share the /usr filesystem, including the same /usr/platform/<platform> directory. However, if the client has a different processor or platform architecture, the server must contain the relevant /usr filesystem and/or /usr/platform/<platform> directory for the client. The /usr filesystem contains the operating system itself, and will be different for each diskless client processor architecture. The /usr/platform directory contains subdirectories that in turn contain executable files that depend on both the machine's hardware implementation (platform) and CPU architecture. Often several different hardware implementations share the same set of platform specific executables. Thus, you will find that /usr/platform contains lots of symbolic links to directories that contain the common machine architecture.

Platform architecture and processor architecture are not the same thing; processor architecture guarantees that binaries are compatible, while platform architecture compatibility means that page sizes, kernel data structures, and supported devices are the same. You can determine the platform architecture of a running machine using uname -i:

% uname -i 
SUNW,Ultra-5_10

You can also determine the machine architecture the platform directory in /usr/platform is likely symbolically linked to:

% uname -m 
sun4u

If clients and their server have the same processor architecture but different platform architectures, then they can share /usr but /usr/platform needs to include subdirectories for both the client and server platform architectures. Platform specific binaries for each client are normally placed in /export on the server.

In Solaris, an unbundled product called AdminSuite is used to set up servers for diskless NFS clients. This product is currently available as part of the Solaris Easy Access Server (SEAS) 2.0 product and works on Solaris up to Solaris 7.

For each new diskless client, the AdminSuite software can be used to perform the following steps:

Give the client a name and an IP address, and add them both to the NIS hosts map or /etc/hosts file if desired.

Set up the boot parameters for the client, including its name and the paths to its root and swap filesystems on the server. The boot server keeps these values in its /etc/bootparams file or in
the NIS bootparams map. A typical bootparams file entry looks like this:
```
buonanotte      root=sunne:/export/root/buonanotte \ 
                swap=sunne:/export/swap/buonanotte
```
The first line indicates the name of the diskless client and the location of its root filesystem, and the second line gives the location of the client's swap filesystem. Note that:
- The swap "filesystem" is really just a single file exported from the server.
- Solaris diskless clients do not actually use bootparams to locate the swap area; this is done by the diskless administration utlities setting up the appropriate entry in the client's vfstab file.

The client system's MAC address and hostname must be added to the NIS ethers map (or the /etc/ethers file) so that it can determine its IP address using the Reverse ARP (RARP) protocol. To find the client's MAC address, power it on without the network cable attached, and look for its MAC address in the power-on diagnostic messages.
Add an entry for the client to the server's /tftpboot directory, so the server knows how to locate a boot block for the client. Diskless client servers use this information to locate the appropriate boot code and to determine if they should answer queries about booting the client.
Create root and swap filesystems for the client
on the boot server. These filesystems must be listed in the server's /etc/dfs/dfstab file so they can be NFS-mounted. After the AdminSuite software updates /etc/dfs/dfstab, it will run shareall to have the changes take effect. Most systems restrict access to a diskless client root filesystem to that client. In addition, the filesystem export must allow root to operate on the NFS-mounted filesystem for normal system operation. A typical /etc/dfs/dfstab entry for a diskless client's root filesystem is:
```
share -F nfs -o rw=vineyard,root=vineyard
/export/root/vineyard
share -F nfs -o rw=vineyard,root=vineyard /export/swap/vineyard
```
The rw option prevents other diskless clients from accessing this filesystem, while the root option ensures that the superuser on the client will be given normal root privileges on this filesystem.

Most of these steps could be performed by hand, and if moving a client's diskless configuration from one server to another, you may find yourself doing just that. However, creating a root filesystem for a client from scratch is not feasible, and it is easiest and safest to use software like AdminSuite to add new diskless clients to the network.

TheAdminSuite software comes in two forms:

A GUI that is launched from the solstice
command:
```
# solstice &
```
You then double click on the Host Manager icon. Host Manager
comes up as simple screen with an Edit menu item that lets you add new diskless clients, modify existing ones, and delete existing ones. When you add a new diskless client, you have to tell it that you want it to be diskless. One reason for this is that Host Manager is intended to be what its name implies: a general means for managing hosts, whether they be diskless, servers, standalone or other types. The other reason is that "other types" includes another kind of NFS client: cache-only clients (referred to as AutoClient hosts in Sun's product documentation). There is another type of "diskless" client, which Host Manager doesn't support: a disk-full client that is installed over the network. A client with disks can have the operating system installed onto those disks, via a network install (netinstall ). Such netinstall clients are configured on the server in a manner very similar to how diskless clients are, except that unique root and swap filesystems are not created, and when the client boots over the network, it is presented with a set of screens for installation. We will discuss netinstall later in this chapter, in Section 8.8, "Brief introduction to JumpStart administration".
A set of command line tools. The command admhostadd, which will typically live in /opt/SUNWadm/bin, is used to add a diskless client.

It is beyond the scope of this book to describe the details of Host Manager, or its command-line equivalents, including how to install them. You should refer to the AdminSuite documentation, and the online manpages, typically kept under /opt/SUNWadm/man.

Regardless of what form of the AdminSuite software is used, the default server filesystem naming conventions for diskless client files are shown in Table 8-1.

Table 8-1. Diskless client filesystem locations

Filesystem	Contents
/export/root	Root filesystems
/export/swap	Swap filesystems
/export/exec	/usr executables, libraries, etc.

The /export/exec directory contains a set of directories specific to a release of the operating system, and processor architecture. For example, a Solaris 7 SPARC client would look for a directory called /export/exec/Solaris_2.7_sparc.all/usr. If all clients have the same processor architecture as the server, then /export/exec/<os-release-name>_<processor_name>.all will contain symbolic links to the server's /usr filesystem.

To configure a server with many disks and many clients, create several directories for root and swap filesystems and distribute them over several disks. For example, on a server with two disks, split the /export/root and /export/swap filesystems, as shown in Table 8-2.

Table 8-2. Diskless client filesystems on two disks

Disk	Root Filesystems	Swap Filesystems
0	/export/root1	/export/swap1
1	/export/root2	/export/swap2

Some implementations (not the AdminSuitesoftware) of the client installation tools do not allow you to specify a root or swap filesystem directory other than /export/root or /export/swap. Perform the installation using the tools' defaults, and after the client has been installed, move its root and swap filesystems. After moving the client's filesystems, be sure to update the bootparams file and NIS map with the new filesystem locations.

As an alternative to performing an installation and then juggling directories, use symbolic links to point the /export subdirectories to the desired disk for this client. To force an installation on /export/root2 and /export/swap2, for example, create the following symbolic links on the diskless client server:

server# cd /export 
server# ln -s root2 root 
server# ln -s swap2 swap

Verify that the bootparams entries for the client reflect the actual location of its root and swap filesystems, and also check the client's /etc/vfstab file to be sure it mounts its filesystems from /export/root2 and /export/swap2. If the client's /etc/vfstab file contains the generic /export/root or /export/swap pathnames, the client won't be able to boot if these symbolic links point to the wrong subdirectories.