Since I'm rambling now, guess I should do the rest of the memory download...
One of the big problems with Linux diskless is it really doesn't scale well, it doesn't allow for clients to run multiple versions of the os, nor for different arch types to co-exist off one server of a different arch type. Additionally, a typical diskless setup exports /usr as a read only file system (which by most definitions, it is supposed to be). Lots of developers ignore this and never think about writing a small file into some /usr/... path during normal operation. Linux is usually much better at leaving /usr read only. But there is an argument that /usr/portage should be /var/portage. But */portage is pretty easy to move, so it's not a big deal. See - http://www.kurobox.com/online/tiki-index.php?page=InstallGentooBeta1 Under the heading - "Configuring Portage" Another not so well thought out diskless problem with Linux is all the setups use one kernel under /tftpboot or, at least the Gentoo Diskless guide uses /diskless, which makes it a bit movable, but then falls into showing the path as - /diskless/xxx.xxx.xxx.xxx (an IP number) instead of using the node name. The other problem, is they all assume only one kernel vs. a kernel for each host. For a good idea of how a robust diskless setup should be done, please see - http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Admin/Diskless_AG/sgi_html/pr01.html The SGI IRIX Diaskless Workstation Administration Guide. So here's a general overview of how a robust diskless infrastructure should be done - - The server should be capable of supporting multipe arch types, even OS types, as long as the NFS' are compatible. - The diskless trees should be capable of being moved to other drives or even servers. - Clients should be known by host name, not IP. The server's /etc/hosts, /etc/resolv.conf should define all that's needed for a client to operate, thus can simply be copied, intact, to each client's /diskless/client-name/etc. - Common files across clients, should reside in common share trees, which are exported read only. - Clients should be capable of operating as full systems, minus having a local disk. - A set of wrapper scripts is needed to allow for package management of share trees and client trees. - Client system management, excluding package management, should be done on the diskless client. - DCHP providing is reserved to the diskless server. Nothing says it can't also provide general DHCP support for other systems beyond the diskless clients. - Diskless nodes should be capable of having attached storage, even shared mounts from NAS and SAN systems. - In a production or a secure environment, diskless should be robust enough to allow changing it on a daily basis - swapping drives out to meet changing needs of visiting clients while still giving access to shared storage. (Linux is not robust in this aspect.) fwiw, here are the weekly diskless things I and my piers do with diskless - Regularly run a 16P O3K booted diskless off a 2P O350 server under IRIX, along with other nodes - some O2s running under a different share tree, and a Voyager system (two pipe Gfx visualization system) booted across multiple sub-nets. Do a weeky update of IRIX on 3 diskless servers and run long term testing - >110hrs, max load on 11 clients of mixed arch types. btw - these servers are all on the same sub-net. Do daily booting and installs via a diakless boot of new Linux kernels on ia64 systems via a fileserver running Gentoo. The systems install kernels and other Linux updates via diskless network boots, then reboot up as regular systems and run automated system testing. Bob - -- gentoo-user@gentoo.org mailing list