8.2. 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/
<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/<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 root=sunne:/export/root/buonanotte \
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, "Brief introduction to JumpStart administration".
-
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.
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/<os-release-name>_<processor_name>.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.
| | |
8. Diskless Clients | | 8.3. Diskless client boot process |