Future of Stateless Linux

[Rudi Chiarito]

I was reading the Stateless Linux tutorial last night. I have a few
questions regarding some issues and how the project will tackle them, if
at all.

I haven't actually tried the software yet, but at work we're having a
new cluster shipped today and this means I have an official excuse to
play with stuff later this week. My perspective focuses mostly on the
needs of clusters and similar setups (blade servers, etc.). I understand
that, at least initially, the project will mainly target desktop
clients. I also understand that we're still in the early stages.

On to the issues.

1) IP addresses

There are several sides to this. The basic premise is that some might
prefer static IP addresses and names for boxes. If I have, say, 30
blades, I would like the blade with the sticker "20" on it to actually
be called "node020". And the one next to it to be called "node021". The
tutorial simply avoids the issue, showing how to set up a DHCP setup
with 100% dynamic IPs. You could consider this issue orthogonal to
serving images and root filesystems, but I think an integrated approach
is preferrable.

The obvious solution here is to resort to Ethernet MAC addresses.
Section 5 (Setting up diskless clients) "solves" the issue by just
saying "Determine the MAC address of the client(s)". That's not as
automated as one would wish and, more importantly, still doesn't take
care of IP addresses and names - it just changes the PXE boot image for
that MAC address. My question here is: are there any plans to tackle
this?

There is an approach that I have used in the past. It worked for me, but
it might need to be made more flexible and robust, to support all the
scenarios that Stateless Linux hopes to enable.

You need, of course, to have a list of MAC addresses. Even better,
several lists of MAC addresses - e.g. for several groups/profiles. You
can enter them manually or, if you're lazy enough, you'll want the
clients and the server to register them automatically.

I do this at the time that the kickstart file is served (I don't serve
images yet, but the idea is the same). A simple CGI script looks at the
IP at the remote end, retrieves the MAC address using ARP and appends it
to the list of addresses for that group. This is the common case, where
you add hosts sequentially by booting them in order, one by one. Of
course you can edit the MAC address lists manually if a NIC needs e.g.
to be replaced.

Another script takes care of creating new configuration files for DHCPD
and BIND, starting from the lists of MAC addresses and some parameters
associated to them. E.g., you'll want to specify that Group 1 lives in
the 10.23.45.0/24 subnet and its symbolic names follow the format string
"desktop%03d". You can even tell dhcpd to add/update entries without
restarting the process, using OMAPI - it's a bit funky, but it can be
made to work in a reliable manner.

A consequence of this is that you can now assign "unregistered" hosts to
a special address range, if you need it. A malicious system can still
spoof another MAC address, but you can at least deal with the more
common case of a system that is misconfigured or was never configured.
Or a Windows system.

2) Live updates

With the current design and implementation, updates happen only at a
snapshot level. There's no support for live updates that do not require
a reboot. I am not sure if this is set in stone, but I can understand
the rationale behind it. It makes sense for desktop systems, but a bit
less for servers.

Is there an answer to the inevitable question, "how do we minimise the
downtime associated with switching to a new image?"? One could imagine
using kexec:

http://www-106.ibm.com/developerworks/linux/library/l-kexec.html

Or, if the kernel doesn't change between images, one could envision a
hack that does the equivalent of going to single-user mode and switching
the root filesystem - unless there's some gotcha that makes it
impossible. The fact that / is already read-only should help, I guess.

3) USB drives

This is a minor issue, but I think it's worth starting to address.
Floppies are dead - the sheer size of the 2.6 kernel makes them unfit
for the purpose - and maybe CDs should be next. USB flash drives are
faster, handier, do not necessitate the extra step of creating an ISO
image and do not require a drive that consumes precious space and power
(well, you could use an USB CD drive, if you're that masochistic).

If tools are going to be developed to create caching client boostrap
images and "live" images, it might be worth considering support for
USB/Firewire drives from the start. It should be a subset of the CD
case, since you are avoiding the creation of an ISO image.

This is all for now.

-- 
Rudi