Online Book Reader

Home Category

Managing NFS and NIS, 2nd Edition - Mike Eisler [95]

By Root 349 0
client's partition from backup or distribution tapes. ND also used a smaller buffer size than NFS, employing 1024-byte buffers for filesystem read and write operations.

In SunOS 4.0 and Solaris, diskless clients are supported entirely through NFS. Two features in the operating system and NFS protocols allowed ND to be replaced: swapping to a file and mounting an NFS filesystem as the root directory. The page-oriented virtual memory management system in SunOS 4.0 and Solaris treats the swap device like an array of pages, so that files can be used as swap space. Instead of copying memory pages to blocks of a raw partition, the VM system copies them to blocks allocated for the swap file. Swap space added in the filesystem is addressed through a vnode, so it can either be a local Unix filesystem (UFS) file or an NFS-mounted file. Diskless clients now swap directly to a file on their boot servers, accessed via NFS.

The second change supporting diskless clients is the VFS_MOUNTROOT( ) VFS operation. On the client, it makes the named filesystem the root device of the machine. Once the root filesystem exists, other filesystems can be mounted on any of its vnodes, so an NFS-mounted root partition is a necessary bootstrap for any filesystem mount operations on a diskless client. With the root filesystem NFS-mounted, there was no longer a need for a separate protocol to map root and swap filesystem logical disk blocks into server filesystem blocks, so the ND protocol was removed from SunOS.

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/ directory. However, if the client has a different processor or platform architecture, the server must contain the relevant /usr filesystem and/or /usr/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

Return Main Page Previous Page Next Page

®Online Book Reader