FAI and diskless clients

[Toomas Tamm]

On Tue, 2012-01-17 at 22:27 +0100, Andreas B. Mundt wrote:

> Now I create the PXE configuration: 
>   ...
>   kernel vmlinuz-2.6.32-5-486
>   append initrd=initrd.img-2.6.32-5-486 ip=dhcp root=/dev/nfs nfsroot=/opt boot=live

Here is mine for comparison. The host name is "arrhenius":

default linux
LABEL linux
KERNEL vmlinuz.arrhenius
APPEND initrd=initrd.img.arrhenius ip=dhcp root=/dev/nfs nfsroot=10.0.0.33:/export/arrhenius,tcp,hard,intr,nolock rw

Because in our case the root NFS server and the TFTP server are not the
same, a script copies the kernel and initrd from the NFS server to the
TFTP server. This is programmed to happen automatically after security
updates are installed. The additional benefit is that the file name on
the TFTP server stays the same all the time.

> I was not able to figure out what boot=live exactly means.  What is
> the difference to boot=nfs?  Are there other alternatives?

I have not used either, so that can be called a third alternative :-)
It appears to work.

The way I understand it (please someone correct me if I am wrong), a
"live" system keeps all changes to files  local on the machine
(essentially in RAM), unless it explicitly writes something onto some
other server (the latter includes mounting other filesystems, eg home
directories, read-write). After a reboot, you get back to the same
system as after the previous boot. Changes to files on the "live"
directory are lost.

In the opposite case (the way we do it), the root filesystem is exported
read-write from the server and functions just like a local disk. Changes
made to files are stored on the server, and after a reboot you see the
files as the system left them before shutdown.

Both situations have their plusses and minuses. You need to consider,
which suits your conditions and requirements best.

> Problems I encountered before on debian-edu are security aspects:  We
> would like to use Kerberos and NFSv4 for mounting the home
> directories.  Of course a keytab in a readable chroot shared by  
> many machines is not what you want.  Any ideas how to handle that
> best? 

Here you imply that you plan to share the chroot between hosts. In this
case the "live" option seems to be the way to go. You may mount
host-specific directories at specific locations in the live system.

Example: Suppose you have hosts HostA and HostB. The server exports 
/export/local/hosta to HostA'is IP address only and /export/local/hostb
to HostB's IP address only (for security). After boot, you need to
mount /export/local/$HOSTNAME at, eg, "/local", and use symlinks
from /etc into /local to reach the host-specific configuration files.

As long as the hosts are up, it is relatively hard to get at the content
of the exported directories. If they are down most of the time, an
intruder may be able to use Host*'s IP address to impersonate it and get
access to sensitive information. This can be mitigated to some extent by
using iptables on the server, or ACLs on a network switch to allow
access from only limited MAC addresses. Perhaps there are better ways to
do this, which I am not aware of.

One more thing to consider is, how do you plan to apply security updates
to your exported NFS root.

Regards,
Toomas Tamm