Whole document tree

Whole document tree

Root over NFS - Another Approach: Introduction Next Previous Contents

1. Introduction

This document does not resemble a common HOWTO, meaning referencing to general principles, but it is rather an on-hand approach to a by nature complex matter. It borrows the structure of the current Root over NFS , but differs from it in the following points:

  • It provides a working solution fom the distribution used. The distribution specific points should be applicable to all major distributions (RedHat,SuSE,Debian).
  • It uses more up to date tools, ex NFS v3.0, kernel 2.4.0, dhcp instead of bootparamd.
  • All steps are described in detail, letting the reader to adapt them to his own system. No scripts!

This HOWTO expects that you have a general knowledge of what you are up to, so first read the Diskless Nodes HOW-TO.

1.1 The setting

It is a common case a University computer lab to have a lot PC's running Windows 98 or/and NT and a powerful UNIX server to satisfy the need of an alternative operating environment. This UNIX server is most of times idle or meerly accessed by telnet and running stupid tasks. On the other hand, students, especially those attending a computer science department, feel like taking full advantage of it, just for fun or for "educational purposes" (breaking in, hacking it...). The restrictive environment of telnet does not allow us to enjoy the use of a power server.There are 2 alternatives to that:

  • Try to persuade the department' s headmaster to approve of the purchase of a bunch of new Unix workstations.
  • Try to persuade the same guy to approve of transforming the server to a diskless node server.

The network at the computer lab consists of the following.

  • UNIX server: SUN Enterprise 3500 with 2 64 bit SPARC@366 Mhz processors and 512 MB of memory. A real monster, isn't it?
  • "Dumb" target workstations: 60-70 PC's with variable configurations, ranging from PII 266 to PIII 450 with 64-128 MB RAM.

The task I had to accomplish was the following: Provide a complete working solution without new expenses and without modifying anything but the necessary on the server.

1.2 The alternatives

Being the responsible for the project, I had to choose between a variety of solutions about it. I choose the following, for the reasons illustrated:

  • The new 2.4 kernel: It provides a robust and fast solution, using less memory than the old 2.2 series. If it is important for your users to attach devices to their PC's then it is the only solution. Also provides NFS v3, and more efficient memory management.
  • The KDE 2.1.1 desktop environment: VERY stable, easy to use, Internet enabled, makes the transition from Windows to Linux desktop almost effortless. GNOME + Afterstep is another option, but not as mature as a solution as KDE.
  • SuSE 7.0 distribution: My favorite one, IMHO the most balanced between ease of use and understanding of a Linux system structure.

1.3 General Principles

To be able to boot a Linux system, you have to provide it with the following:

  • The /sbin directory. There exists the init programm, which is responsible for starting other programms and start up scripts during the boot process. Also, the /sbin directory contains the startup scripts in the case of SuSE, some useful programms like the portmap programm and many other programms that are needed before you mount the /usr directory.
  • The /lib directory. It contains the libc libraries that are absolutely necessary if your init is dynamically linked.
  • The /bin directory. It contains file commands and shells for running startup scripts.
  • The /etc directory. It contains configuration files for most programms and the rc.d directories that is the default for startup scripts.
  • The /var directory. It is a spool area for programms that want to write somewhere. It is divided into many subdirectories with alternate usability.
  • The /dev directory. It contains character and block special devices that allow programms to communicate with the computers devices via the kernel.
You should notice that after a clean install, the total size of these directories is not that big, ranging from 30 to 40 MB. The main load of files exists in the /usr and /opt directories. So, it is possible to create a directory for every diskless client containing the above listed directories and mount points for directories like /usr that will be exported by the server. The boot process, as assumed by this document, is the following:
  1. The user reboots the computer, and using a diskette boots the Linux kernel.
  2. The kernel takes control of the system, identifies the system devices, and uses BOOTP to obtain the IP address matching the NIC 's hardware address.
  3. The init programm is started. Before switching to a run level, it calls a script described in the /etc/inittab file. This script is responsible for building the library cache, initialise and mount a swap file, load some system specific kernel modules and set the hostname.
  4. The boot script finishes and the init programm switches to the specified runlevel. It starts to execute the scripts located into the /etc/rc.d/rcX directory where 'X' is the name of the runlevel. These scripts are responsible for starting the portmapper and mounting the NFS exported /usr, /home and /opt directories.
  5. The user is able to login.
To sum up, the system administrator has to do the following tasks:
  • Prepare a clean install of the system to be exported to the diskless hosts.
  • Create the host specific directories
  • Control what is going to be started during the diskless clients' boot proces
  • Prepare the server to export some directories and start a bootp service.

Next Previous Contents