diskless alphalinux nodes

[Gregory R. Warnes]

On Tue, 6 Jun 2000, Robert G. Brown wrote:

  RGB>> On Tue, 6 Jun 2000, Mathew Lee wrote:
  RGB>> 
  RGB>> > ....additionally I searched the archives for diskless and found a reference from
  RGB>> > Oct. 1998, where you talk about a diskless booting sequence 

	[snip]

  RGB>> 
  RGB>> I largely abandoned this particular approach because new kernels came
  RGB>> out that supported much better methods.  The most intriguing is Greg
  RGB>> Warnes NFS hack that permits the normal installation of just one server
  RGB>> to support N nodes without creating any host-specific export directories
  RGB>> at all -- I think he posted it last week.

The NFS mod that Robert mentions is called ClusterNFS and has a home
page at http://ClusterNFS.sourceforge.net 

  RGB>> Greg's NFS hack allows a single fs to be exported but gives writability
  RGB>> and remapped identity to files via an IP-based tag, so e.g.
  RGB>> /etc/ld.so.cache as mounted on host xxxxxxxx is really exported as
  RGB>> /etc/ld.so.cache_xxxxxxxx on the server.  IIRC, that is (he may correct
  RGB>> me).  I'd expect that his changes are moderately portable since they are
  RGB>> likely well above the machine hardware layer of the kernel.

Actually, ClusterNFS runs entirely in userspace, so that *no* kernel
modifications are required on either the server or the client. Since
ClusterNFS is a simple extension to the standard Universal-NFS server,
which is reported to work on a wide variety of OS's and CPU's, I expect it
will compile and work out-of-the-box with Alpha-Linux.  (Of course, I
haven't actually tried anything but Intel Linux.  Let me know if something
doesn't work.)

  RGB>> However, once you've figured out how to build a NFS lilo boot floppy
  RGB>> (which isn't that difficult from the current howtos and e.g. mkinitrd)
  RGB>> it is also pretty simple to go diskless by just giving each node e.g.
  RGB>> /exports/[b1,b2,b3...] exported to each host as its root and then
  RGB>> cloning everything BUT /usr into it (that is, make /usr a separate
  RGB>> filesystem on the server, usually, and export it RO to all the hosts).
  RGB>> This wastes a bit of space but space is cheap.  You'll still need to
  RGB>> periodically rsync the node roots with a carefully determined exclusion
  RGB>> list, as otherwise e.g. RPM installs on the server won't properly
  RGB>> propagate to the nodes.

I created ClusterNFS explicitly to get away from the need to keep separate
directories for each client (either on NFS or on the client itself).  
Keeping {track of, propagating} changes to all of the appropriate
directories gets hairy fast.  Even if you use rsync, it is quite difficult
to figure out everything that should be {in,ex}cluded.  I used to do this
on our cluster, and every couple of months I'd discover that something
else needed to be excluded that wasn't.  In addition, particularly painful
things happen when rsync tries to update the libraries it is using on the
clients....

-Greg