• Choose a category
• All
• Classic-Fiction

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/_.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.

Diskless client boot process

Debugging any sort of diskless client problems requires some knowledge of the boot process. When a diskless client is powered on, it knows almost nothing about its configuration. It doesn't know its hostname, since that's established in the boot scripts that it hasn't run yet. It has no concept of IP addresses, because it has no hosts file or hosts NIS map to read. The only piece of information it knows for certain is its 48-bit Ethernet address, which is in the hardware on the CPU (or Ethernet interface) board. To be able to boot, a diskless client must convert the 48-bit Ethernet address into more useful information such as a boot server name, a hostname, an IP address, and the location of its root and swap filesystems.

Reverse ARP requests

The heart of the boot process is mapping 48-bit Ethernet addresses to IP addresses. The Address Resolution Protocol (ARP) is used to locate a 48-bit Ethernet address for a known IP address. Its inverse, Reverse ARP (or RARP), is used by diskless clients to find their IP addresses given their Ethernet addresses. Servers run the rarpd daemon to accept and process RARP requests, which are broadcast on the network by diskless clients attempting to boot.

IP addresses are calculated in two steps. The 48-bit Ethernet address received in the RARP is used as a key in the /etc/ethers file or ethers NIS map. rarpd locates the hostname associated with the Ethernet address from the ethers database and uses that name as a key into the hosts map to find the appropriate IP address.

For the rarpd daemon to operate correctly, it must be able