Managing NFS and NIS, 2nd Edition - Mike Eisler [96]
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.
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.