Configuration options

Adding disks to local clients opens two configuration options. You can use the local disk for swap space, or you can build an entire bootable system on it and put the root and swap filesystems on the local disk. This latter configuration is called a dataless client, and makes sense if the client does not need most of the local disk for a very large swap space. If the client has a large swap partition and uses it frequently, adding a local disk may improve performance by reducing the client's traffic to its boot server. In other instances, the local disk provides private storage for sensitive files. Dataless clients contain no user or data files on their local disks. Everything on the local disk can be reconstructed from operating system release tapes or from system installation scripts. The local disks are used for the root and swap filesystems, while /usr and all other filesystems are NFS-mounted. The dataless architecture provides some performance advantages from both the client and server perspective, particularly when the client has a large swap space. A significant portion -- usually more than 50% and sometimes 90% -- of a diskless client's network traffic is caused by reading and writing the root and swap filesystems. Clients with local disks place less of a load on the network and on the boot server by sending their swap traffic to this disk.

Dataless clients

You may choose to use the dataless client configuration if you have to support a few machines of a new client architecture and would have to carve the disk space out of the server's /export partition. Adding a local disk keeps the server configuration simple and puts all files specific to the new client architecture on the local disks. The best network architecture for dataless clients is one in which desktop machines run application sets with large, randomly accessed virtual address spaces. If the machine has a reasonably high level of paging activity, depending on the speed of the network and capacity of the NFS servers, using a local disk improves performance. Dataless clients may appear to be more expensive per seat than diskless clients, since the diskless machines get root and swap space at "bulk" prices from the server. On the other hand, in a pure diskless client environment, you must purchase additional disk space to hold the clients' root and swap filesystems. If you allocate some portion of the server's cost as the cost of replacing local disks, the dataless and diskless architectures have much less of a price differential. Be careful when analyzing client/server cost projections. You'll get the fairest numbers when you compare the total cost of the desktop workstation, any local disk, and the desktop's share of the cost of servers providing root, swap, and user filesystems. When you do add local disks, it's important to choose your disk size carefully. If larger local disks are attached to dataless clients, they become inviting homes for user files that may not be backed up regularly. If you plan to configure dataless clients, use the smallest disk possible to contain the root and swap filesystems, with enough room on the local disk's root partition to contain a very large /var directory. Applications that use enough virtual memory to justify a local disk probably create huge temporary files on /var/tmp as well. Management of dataless nodes is slightly more complex than that of diskless nodes. Even though the local disks contain no user files or tools, they may still have host-specific configuration information in the /etc directory, such as software password files. Use care when modifying the private parts of a dataless node so that the entire node can be recreated from a boot tape or archive tape if the local disk must be replaced. You will probably want to create a script that creates spool directories, copies printer configuration files, and creates NFS mount points on the client; you can use this script on dataless or new diskless clients as well. If possible, mount the dataless client spool directories from an NFS server so that the dataless client's disk contains no host-specific information. Ideally, you should not have to do backups of a dataless client. After Solaris 2.5.1, the AdminSuite product stopped supporting the dataless configuration option. This is a bit of an inconvenience to you, but it is surmountable. Consider that a dataless client is like a disk-full client except that /usr is mounted from an NFS server instead of from a local disk. The steps for doing this are:

Install the operating system on a disk-full client. If possible (depending on how many disks you have and how big they are), install all the software without specify a /usr partition. If you have to, specify a separate /var partition if that is what it takes to prevent a /usr partition from being created. It's OK to have the /usr partition created, but once you mount /usr from the NFS server, the question then is what do you do with the redundant local disk space? You can always mount it as another partition, say /spare, and have it around for future additional needs such as more swap, or more /var space.
Edit /etc/vfstab on the client to mount /usr from an NFS server that has been set up for diskless client support. If there was an entry for /usr in /etc/vfstab, comment it out. For example you might comment out /usr 's vfstab:
```
# /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 1 no -
```
and add:
```
wahoo:/export/exec/Solaris_2.7_sparc.all/usr - /usr nfs - - ro
```
Edit /etc/hosts and add the IP address of the NFS server. Both dataless and diskless clients require this, because while the system is booting, without /usr available, the software needed to access NIS or DNS won't be around, so /etc/hosts is needed to resolve the name of the NFS server to an IP address:
```
wahoo
```
Test this by rebooting the client. If you run into any problems, you can always shut the system down, and boot the system as single user.

There is a drawback to this scheme. Applying some patches and packages will be less straightforward, because patches and packages can contain both /usr and root files, but the dataless client's /usr partition won't be writable by the utilities used to add patches and packages. The workaround for this is very dependent on the patch and packaging scheme used by the operating system. In case of Solaris, the patchadd utility has a -R pathname option, which is normally used to apply patches to a diskless client's root partitions. In that case, patchadd is run on the NFS server. In the case of a dataless client, you would invoke patchadd as:

client # patchadd -R / -M . 107460-03

For a package that contains both root and /usr files, you could invoke the Solaris pkgadd command to install the package in a temporary place, and then copy the non-usr files to the dataless client's root:

client # mkdir /tmp/scratch client # pkgadd -d . -R /tmp/scratch SUNWxxxx client # cd /tmp/scratch client # rm -rf usr client # find . -print | cpio -dump /

Swapping on a local disk

In this configuration option, the client's root and /usr filesystems are NFS-mounted, but swap is from a local disk. The AdminSuite software doesn't provide an option for diskless client accessing local swap, but again it is surmountable. The steps are:

If not already done, add the diskless client to the boot server via the AdminSuite software. Go ahead and define a swap partition on the server so that you don't run the risk of confusing the AdminSuite software.
Boot the client from the boot server.
Identify and create the swap partition from the local disk. In Solaris, the easiest way to this is via the format command. When you invoke the format command, it will display the list of disks attached to the client. You then select one of the local disks and then use the "partition" command from inside format to find an existing partition and resize it, or create a partition with the desired size.
Edit /etc/vfstab on the client to mount swap from the partition you identified in the previous step. For example you might change the two NFS-related swap vfstab entries from:
```
wahoo:/export/swap/honeymoon - /dev/swap nfs - - - /dev/swap - - swap - - -
```
to:
```
/dev/dsk/c0t0d0s7 - - swap - no -
```
Reboot the client via diskless boot.

In general, the swap partition should cover most, if not all, of the local disk. Of course, if you followed the example in "Managing client swap space", then you know you ought to be able to switch from NFS swap to local swap without a client reboot. This is only possible if the local swap partition is at least as big as the NFS-mounted swap file. Instead of rebooting the client in step 5, you would do:

honeymoon# swap -a /dev/dsk/c0t0d0s7  honeymoon# swap -d /dev/swap