Managing NFS and NIS, 2nd Edition - Mike Eisler [100]
The diskless client mounts its root filesystem from the named boot server and boots the kernel image found there. After configuring root and swap devices, the client begins single user startup and sets its hostname, IP addresses, and NIS domain name from information in its /etc files. It is imperative that the names and addresses returned by bootparamd match those in the client's configuration files, which must also match the contents of the NIS maps.
As part of the single user boot, the client mounts its /usr filesystem from the server listed in its /etc/vfstab file. At this point, the client has root and swap filesystems, and looks (to the Unix kernel) no different than a system booting from a local disk. The diskless client executes its boot script files, and eventually enters multi-user mode and displays a login prompt. Any breakdowns that occur after the /usr filesystem is mounted are caused by problems in the boot scripts, not in the diskless client boot process itself.
Managing boot parameters
Every diskless client boot server has an /etc/bootparams file and/or uses a bootparams NIS map. On Solaris, the /etc/nsswitch.conf file's bootparams entry controls whether the information is read from /etc/bootparams, NIS, or both, and in what order.
Here are some suggestions for managing diskless client boot parameters:
Keep the boot parameters in the bootparams map if you are using NIS. Obviously, if your NIS master server is also a diskless client server, it will contain a complete /etc/bootparams file.
If you have diskless clients in more than one NIS domain, make sure you have a separate NIS bootparams map for each domain.
On networks with diskless clients from different vendors, make sure that the format of the boot parameter information used by each vendor is the same. If one system's bootparamd daemon returns a boot parameter packet that cannot be understood by another system, you will not be able to use the NIS bootparams map. We'll look at the problems caused by differing boot parameter packet formats in Section 15.3.
Eliminating copies of the boot parameter information on the other servers reduces the chances that you'll have out-of-date information on boot servers after you've made a configuration change.
Managing client swap space
Once a client is running, it may need more swap space. Generally, allocating swap space equal to the physical memory on the client is a good start. Power users, or those who open many windows, run many processes in the background, or execute large compute-intensive jobs, may need to have their initial swap allocation increased.
You can increase the swap space on a diskless client, without shutting down the client, provided you have sufficient space on the server to hold both the client's old swap file, the server's new swap file, and a temporary swap file equal in size to the old swap file. Here is the procedure:
Create a temporary swap file on the boot server, using mkfile : wahoo# cd /export/swap
wahoo# mkfile 64M honeymoon.tmp wahoo# ls -l honeymoon.tmp
-rw------T 1 root root 67108864 Jan 9 00:38 honeymoon.tmp
wahoo# share -o root=honeymoon /export/swap/honeymoon.tmp
Make sure you do not use the -n option to mkfile, since this causes the swap file to be incompletely allocated. If the client tries to find a swap block that should have been pre-allocated by mkfile, but doesn't exist, the client usually panics and reboots.
On the client, mount the temporary swap file:honeymoon# mkdir /tmp/swap.tmp
honeymoon# mount wahoo:/export/swap/honeymoon.tmp /tmp/swap.tmp
honeymoon# swap -a /tmp/swap.tmp
What is interesting about this is that a regular file, and not a directory, is exported, and yet it is mounted on