Re: Network boot & comedi

On Fri, 20 Jun 2003, Tim Holy wrote:

> Hello,
>
> In my lab we currently have 3 Linux data acquisition machines, plus a few
> Linux desktops. Because these machines have been installed at different
> times, lab-wide there are 3 different distributions (if you count versions),
> each has a different kernel, comedi version, etc.. By the end of the year,
> several of the machines will unfortunately have reached their end-of-life
> support as far as security patches from the distributor. For these reasons,
> I'm exploring the possibility of setting up single a Debian system for
> network booting (PXE).
>
> I'm wondering whether anyone on this list has any experience and/or advice
> about whether this is a good or bad idea. From the bit of reading I've done
> so far, one problem seems to be that:
> 1. It's nice to make /root available read-only, so that a single configuration
> can be shared among clients;

What do you do with your /root? I barely ever use that directory.. usually
its only to download rpm's to and install them or something equally doable
in another directory.

> 2. But if the hardware is different, I'll apparently have trouble with a
> single shared /dev filesystem. It's recommended
> (http://www.linux-mag.com/2002-10/netbooting_06.html) that one uses devfs to
> handle the hardware differences between machines. Comedi supports /dev but
> not /devfs, however.
>

Hmm.. I thought I saw comedi do devfs at one point.  I could be wrong and
am too lazy to double-check this :). Sharing /dev sounds so hackish I
would almost recommend it on sheer boldness value.

> While I have no experience in these matters, it seems that it should be simple
> to put /dev (and /var, /tmp, and anything else?) on each of the local
> harddrives, and solve the hardware differences that way. Am I wrong?
>

Yeah you could do that.. but isn't it sexier just to have completely
diskless clients?  Using bootp or something to boot the kernel?  At any
rate you could always have /dev in the ramdisk.. possibly using some boot
scripts to construct /dev on each boot (such as from a .tar.gz or
something).  Or share it.  It kind of sounds so bold to share /dev that I
really think you ought to try it.


> And a couple of points that may be off-topic for this list, but I mention them
> in case they might have implications for comedi:
> 1. Will NFS file locking (http://www.linux-mag.com/2002-10/netbooting_07.html)
> be an issue I need to worry about? Despite trying to find information in man
> pages and from HOWTOs on the web, I don't really understand what locking is,
> or when it would be a problem.

File locking is the mechanism by which programs can lock files.  It is
completely voluntary locking and the kernel doesn't really enforce it
except to tell programs that "this file is locked.. wait" if they try
to acquire a lock on a locked file.

See flock and fcntl manpages for more discussion on file locking...

If you have nfs with file locking services, then it's possible to lock
files across nfs shares provided the programs trying to do the locking use
fcntl and not flock...  So in the end you can throw file locking out the
window when it comes to NFS (because some programs use flock and not
fcntl).  However file locking isn't used too much in most programs, so you
can get away with it not working properly.  Mail readers sometimes use
file locking to lock mbox-style mailboxes, as do MTA's such as postfix.
But I have a feeling these boxes won't have too many local email
accounts..

> 2. I notice that a lot of sites recommend using a ram disk for /var, but I
> don't see why this would be better than the local harddrive.
>

Well, it is a good idea otherwise you will have interleaved and illegible
logs in /var/log.  Also some boot scripts touch files in /var/run, etc.
In generaly.. sharing one /var across more than one machine may break or
otherwise confuse some software unless you are really really careful...

However if it's in a ramdisk then you have issues with things like package
managers that use /var to keep their databases.  So the ramdisk thing is
not perfect either.... because you have to reconcile changes to package
manager databases with the real /var that was used to populate the ramdisk
/var...

:)

-Calin

Received on 2003-06-20Z20:27:53