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