Diskless Clients
 

Getting diskless clients to work requires to build up an environment for them to boot from and to import the necessary file systems:
 

There are several aspects of the server that require attention. The first step is to install the software, the second to setup DHCP to assign IP addresses to the client machines, and the third is to configure the NFS server so that the clients can import their file systems.
 

One obvious question is why do we have to install the distribution a second time for the client machines. Can't we just use the server's filesystems and export them to the clients and only keep copies of the variable parts for each client? The answer is actually 'yes'. But...
 
Keeping the clients and the server separate from each other has a couple of advantages. First of all, you may want to have different versions of software on the clients than you want to have on the server. Servers tend to run for a long time with only a few updates which are mostly security related. Clients, on the other hand, often require that you have the latest version of the software available. So you may pay for 2 Gigabytes of cheap disk space with possibly lots of trouble in keeping your sever installation in a sane state. Where you can have a very slim installation for the server, with only the few tools you need to run it, you may need a full blown installation for your client machines. Whenever possible, you should keep the server uncluttered and loaded only with those applications that are necessary, but keep your clients as up-to-date as possible with their versions.
 
Another reason is that you might want to give the client administration to someone other than the person who is responsible for the server machines. Developers often have their own ideas on what a system looks like and prefer to have as many recent versions of as many tools as possible. These tools may be OK for client machines, but for a server you want to be assured that you have the most reliable software available, not the latest and least tested. This is why we will have separate incarnations of SuSE Linux on the server machine in this installation example.
 
OK, but now how do we install a second copy of the distribution on a machine? Even if the SuSE distribution isn't really designed to support diskless clients, YaST has a useful feature which helps us install the packages we need. When you Start YaST, select the Adjustments of installation menu. The last option in this menu is Installation to a directory. Select this option and you get a form where you can enter the directory which will be used as the root directory for the installation.
 
This directory will be the root directory of the client machine. You can put the client installation where ever you have disk space. In this example we will use /Clients/192.168.0.129 as root directory for the first client. You may already see the purpose behind this numbering scheme. /Clients will contain all client root directories. The actual client directories are named using the IP number the client will get. This scheme provides a clear naming pattern for a random number of client machines. You also can use the client's names as directory names, which would work the same way.
 

To assign an IP address to the client machine, we need to set up DHCP. In chapter 21 we covered DHCP and the general structure of the DHCP configuration file /etc/dhcpd.conf.
 
Because the client uses the BOOTP protocol we can't use DHCP's dynamic IP feature and reserve a group of addresses to the clients. We have to create a separate entry for each client machine which will map its MAC (Media Access Control) address to an IP address. The MAC address is a unique number assigned to the network card by the card's manufacturer. No two cards have the same number. This is why this address is often used for autoconfiguration purposes, because it offers a unique identification for the networked machine.
 
The second setting that is passed to the client is the directory which will be mounted from the server as the client's root file system. The configuration shown below illustrates a working setup for one client:
 

# 
# dhcpd.conf 
# 
# Configuration for diskless clients 
# 

 

# DHCP needs at least one subnet definition 
subnet 192.168.0.0 netmask 255.255.255.0 { 

 

# For each diskless client we need to assign the IP address  
# and the root filesystem 
host DiskLess1 { 
      option root-path "/Clients/192.168.0.129"; 
      hardware ethernet 00:80:c8:e8:33:04; 
      fixed-address 192.168.0.129; 
}  

In the last section we assigned a directory of the server as the root directory for the client. During the boot process, the client will mount this directory via NFS. Therefore, we have to export this directory to the server machine. In chapter 20 we learned about the /etc/exports file and how it is used to export directories over the network. This is exactly what we need here. All we have to do is create an entry in this file allowing the client to mount the assigned directory:
 

# 
# /etc/exports 
# 

 

# root directory for diskless client 
/Client/192.168.0.129           192.168.0.129(rw,no_root_squash) 

The most important part of the boot floppy is the kernel. We have to create a custom kernel for the clients which will enable the root file system to be mounted over NFS. What differentiates this kernel from 'regular' kernels like the ones provided by SuSE is that it has to be able to get its network configuration and the location of its root file system at boot time from the DHCP server. Another special setting allows the kernel to mount the root file system over NFS.
 

To create the customized kernel, start by configuring the kernel as usual by running make menuconfig as root in the directory /usr/src/linux. Continue as if you were creating a regular kernel for the client machine.
 

Besides the kernel, we need a file system, a LILO configuration, and a the boot loader on the floppy disk. To create the file system, insert an empty floppy disk in the floppy drive and run mke2fs to create the file system on device /dev/fd0:
 

# mke2fs -m 0 /dev/fd0 

 

mke2fs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 
Linux ext2 filesystem format 
Filesystem label= 
360 inodes, 1440 blocks 
0 blocks (0.00%) reserved for the super user 
First data block=1 
Block size=1024 (log=0) 
Fragment size=1024 (log=0) 
1 block group 
8192 blocks per group, 8192 fragments per group 
360 inodes per group 
Writing inode tables: done 
Writing superblocks and filesystem accounting information: done 

# mount /dev/fd0 /floppy 

# cp /boot/boot.b /floppy 

 
To run lilo we must also have a lilo-configuration. The configuration file for the boot floppy could live anywhere in the file system. But to keep things together so that we can reference to them later and or make changes to the configuration, we'll put it on the floppy disk too. In this case, we should consider what we want the configuration look like. We need to assign lilo to put its boot strapping code on the floppy disk and to use the kernel on the floppy to boot the system. Furthermore, the kernel has to be assigned to mount the root file system via NFS. The following example shows a lilo.conf that fills these needs:
 

#  
# LILO Configuration for Diskless Clients 
# 

 

boot    = /dev/fd0 
install = /floppy/boot.b 
map     = /floppy/map 
read-only 
prompt 
timeout = 0 
vga     = normal 
image   = /floppy/vmlinuz 
root    = /dev/nfs 
label   = Linux 

# cp /usr/src/linux/arch/i386/boot/bzImage /floppy/vmlinuz 

# lilo -C /floppy/lilo.conf 
Added Linux * 

Before we can use the installation on the server to boot our client machine, we have to edit some files and perform some simple customizations. YaST doesn't support diskless clients. We tricked it to install the distribution to a directory tree other than /, but this is all it can do for us in this case.
 
To get the client working we have to make some edits in the configuration and slightly revise some of the rc-scripts to make them work properly in a diskless environment.
 

The first step is to edit the fstab file of the client. This location specifies which partitions are mounted to which particular mount-points. As there is no disk in the client, no physical partitions are mounted anywhere. The root file system is mounted from the server machine using NFS. This means the fstab should look like this:
 

192.168.0.200:/Clients/192.168.0.129   /            nfs     defaults    0 0 
192.168.0.1:/home                      /home        nfs     defaults    0 0 
/dev/fd0                               /floppy      auto    noauto,user 0 0 
none                                   /proc        proc    defaults    0 0 
none                                   /dev/pts     devpts  defaults    0 0 

[...] 

 

# 
# do fsck and start sulogin, if it fails. 
# 
FSCK_RETURN=0 
if test ! -f /fastboot -a -z "$fastboot" ; then 
    # on an umsdos root fs this mount will fail, so direct error messages 
    # to /dev/null. 
    # this seems to be ugly, but should not really be a problem. 
    mount -n -o remount,ro / 2> /dev/null 
    if test $? = 0; then 
        ECHO_RETURN=$rc_done_up 
        echo "Checking file systems..." 
        fsck -A -a 
        # A return code of 1 indicates that file system errors 
        # were corrected, but that the boot may proceed. 
        # A return code of 2 or larger indicates failure. 
        FSCK_RETURN=$? 
        if test $FSCK_RETURN -gt 1; then 
            echo -e "$rc_failed_up" 
            if test -x /sbin/init.d/kbd ; then 
                /sbin/init.d/kbd start 
            fi 
            echo 
            echo "fsck failed.  Please repair manually and reboot. The root" 
            echo "file system is currently mounted read-only. To remount it" 
            echo "read-write do:" 
            echo 
            echo "   bash# mount -n -o remount,rw /" 
            echo 
            echo "Attention: Only CONTROL-D will reboot the system in this" 
            echo "maintenance mode. shutdown or reboot will not work." 
            echo 
            PS1="(repair filesystem) # " 
            export PS1 
            # XXX /sbin/sulogin /dev/console 
            /sbin/sulogin /dev/tty1 
            # if the user has mounted something rw, this should be unmounted 
            echo "Unmounting file systems (ignore error messages)" 
            umount -avn 
            # on umsdos fs this would lead to an error message. so direct 
            # errors to /dev/null 
            mount -no remount,ro / 2> /dev/null 
            sync 
            reboot -f 
        fi 
        echo -e "$ECHO_RETURN" 
        sync 
        mount -n -o remount,rw / 
    else 
        mounts=/etc/mtab 
        test -r /proc/mounts && mounts=/proc/mounts 
        while read des fs type rest; do 
            case "$fs" in 
                /) break ;; 
                *)       ;; 
            esac 
        done < $mounts 
        if test "$type" != "umsdos" ; then 
            echo 
            echo "*** ERROR!  Cannot fsck because root is not read-only!" 
            echo 
        fi 
    fi 
else 
    echo "File systems are NOT being checked." 
    mount -n -o remount,rw / 
fi 
# 
# clean up 
# 
rm -f /etc/mtab* /etc/nologin /nologin /fastboot 

 

[...] 

# 
# clean up 
# 
rm -f /etc/mtab* /etc/nologin /nologin 

To get a clean shutdown of the diskless client, we have to be certain that the network services, especially the NFS service, stays up until the very end. To ensure that the network connection stays alive, we need to disable the shut down of:
 

[...] 
    stop) 
        if test -x /usr/bin/wall ; then 
            echo "Network is going down now!" | /usr/bin/wall 
            sleep 1 
        fi 
        for I in $NETCONFIG; do 
            eval NETDEV=\$NETDEV$I 
            case $NETDEV in 
              ippp*|ppp*|isdn*) ;; 
              *:*) 
                # 
                # *:* is probably an alias and will fail to ifconfig down 
                # so omit error message 
                # 
                ifconfig $NETDEV down 2> /dev/null 
                ;; 
              *) 
                echo -n "Shutting down network device $NETDEV" 
                ifconfig $NETDEV down || return=$rc_failed 
                echo -e "$return" 
                ;; 
            esac 
        done 
        ;; 
[...] 

[...] 
    stop) 
        echo -n "The network interfaces can't be shut down for this client" 
        echo -e "$return" 
        ;; 
[...] 

If you've carefully followed all the instructions on setting up the server and made the suggested modifications on the client's script as described, you should be able to boot your client machine now. Use the boot floppy you created to boot the client. In the boot messages you should see the BOOTP requests which were sent from the client and the IP address the client received from the server. The client then mounts its root filesystem and goes on as if it were a regular file system on a local disk. The output should look like this:
 

[...] 
eth0: VIA VT3043 Rhine at 0xfc80, 00:80:c8:e8:33:04, IRQ 11. 
eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link 0000. 
Sending BOOTP requests.... OK 
IP-Config: Got BOOTP answer from 192.168.0.200, my address is 192.168.0.129 
IP-Config: Guessing netmask 255.255.255.0 
Looking up port of RPC 100003/2 on 192.168.0.200 
Looking up port of RPC 100005/1 on 192.168.0.200 
VFS: Mounted root (NFS filesystem) read-only. 
[...] 

Jul 6 05:07:09 Maggie dhcpd: BOOTREQUEST from 00:80:c8:e8:33:04 via eth0 
Jul 6 05:07:09 Maggie dhcpd: BOOTREPLY for 192.168.0.129 to MrBurns  
                             (00:80:c8:e8:33:04) via eth0 

Up to this point, we've only talked in terms of a single client. Of course, this was just the beginning. It's a waste of time to repeat the process for each client. Remember, the motivation was to ease and reduce the number of administrative tasks. So what's a clever way to get more clients up and running? Do you remember the table 1-1 in chapter 1 where we classified file systems into sharable vs. not shareable and static vs. variable? Now we're at the point were we can profit from this classification. Only one copy of the shareable data is needed for all clients. Only the unsharable data has to be present in separate copies for each client. Creating a new client setup means to creating copies of the unshareable parts of the filesystem onto the NFS server and making these copies available to the new client machine. This and a new entry in the DHCP configuration for the new client is all that is needed for each new machine that you want to integrate into your network. We'll go step-by-step through a practical example which will point out the tasks required to set up the new client. We assume that the hardware of the new machine is similar to out first client, so we don't have to create a new boot floppy. If this is not the case for you, refer to the section above to create a floppy for the client. The procedure is exactly the same as for the initial client.
 

Keeping the naming scheme and assuming that the second client has the IP address 192.168.0.130, we create the directory /Clients/192.168.0.130 on the server machine. This becomes the root filesystem of the second client:
 

# mkdir /Clients/192.168.0.130 

# cd /Clients/192.168.0.130 
# cp -av ../192.168.0.129/etc . 
# cp -av ../192.168.0.129/root . 
# cp -av ../192.168.0.129/var . 

# cd /Clients/192.168.0.130 
# mkdir home mnt proc usr floppy opt tmp 

# cd /Clients/192.168.0.129 
# find sbin -type d -exec mkdir -p ../192.168.0.130/{}  \; 
# find bin  -type d -exec mkdir -p ../192.168.0.130/{}  \; 
# find lib  -type d -exec mkdir -p ../192.168.0.130/{}  \; 
# find dev  -type d -exec mkdir -p ../192.168.0.130/{}  \; 

# cd /Clients/192.168.0.129 
# find sbin ! -type d -exec bash -c 'f={} ; ln $f ../192.168.0.130/`dirname $f`' \; 
# find bin  ! -type d -exec bash -c 'f={} ; ln $f ../192.168.0.130/`dirname $f`' \; 
# find lib  ! -type d -exec bash -c 'f={} ; ln $f ../192.168.0.130/`dirname $f`' \; 
# find dev  ! -type d -exec bash -c 'f={} ; ln $f ../192.168.0.130/`dirname $f`' \; 

ln: sbin/init.d/init.d: hard link not allowed for directory 

ln: dev/fd: hard link not allowed for directory 

# cd /Clients/192.168.0.130/dev 
# ln -s /proc/self/fd fd 
# cd /Clients/192.168.0.130/sbin/init.d 
# ln -s init.d . 

#!/bin/sh 
# 
# Create new diskless client 
# 
clients=/Clients 
master=192.168.0.129 
new=$1 

 

# Create the new root directory 
mkdir $clients/$new 

 

# Copy the non-sharable parts 
cd $clients/$new 
for dir in etc root var ; do 
  cp -av ../$master/$dir . 
done 

 

# Create mount points and empty directories 
mkdir home mnt proc usr floppy opt tmp 

 

# Create directory tree for data needed on root file system 
# and hard-link files 
cd /$clients/$master 
for dir in sbin bin lib dev ; do 
  echo "Processing $dir ..." 
  find $dir -type d -exec mkdir -p ../$new/{} \; 
  find $dir ! -type d -exec bash -c 'f={} ; ln $f ../'$new'/`dirname $f`; echo $f' \; 
done 

 

# softlink directories 
cd /$clients/$new/dev 
ln -s /proc/self/fd fd 
cd /$clients/$new/sbin/init.d 
ln -s init.d . 

All subsequent clients have to mount the shareable data out of the first client's subdirectory. This means we need a different /etc/fstab file on all other clients. We need to mount the directories usr, opt, and home from the server machine. For /usr and /opt we can use the versions we already have on the server for our master client. We could do the same with /home, but let's say we already have a directory tree for the home directories on a different server that is shared by diskless and regular clients. In this scenario, we need a /etc/fstab file on the client machine like the one shown here:
 

# 
# Client File System Table 
# 

 

# remote file systems 
192.168.0.200:/Clients/192.168.0.130     /         nfs     defaults      0 0 
192.168.0.200:/Clients/192.168.0.129/opt /opt      nfs     defaults      0 0 
192.168.0.200:/Clients/192.168.0.129/usr /usr      nfs     defaults      0 0 

 

192.168.0.1:/home                        /home     nfs     defaults      0 0 

 

# local goodies 
/dev/fd0                                 /floppy   auto    noauto,user   0 0 
none                                     /proc     proc    defaults      0 0 
none                                     /dev/pts  devpts  defaults      0 0 

# Master client 
/Clients/192.168.0.129           192.168.0.129(rw,no_root_squash) 

 

# shared file systems 
/Clients/192.168.0.129/opt       192.168.0.0/255.255.255.0(ro) 
/Clients/192.168.0.129/usr       192.168.0.0/255.255.255.0(ro) 

 

# Clients 
/Clients/192.168.0.130           192.168.0.130(rw,no_root_squash) 
/Clients/192.168.0.131           192.168.0.131(rw,no_root_squash)