On Fri, 7 Jun 2002, Stew Benedict wrote: > > > > Of course, links to the SRPMs > > > > (http://www.fensystems.co.uk/SRPMS.fensys/) are usually more useful. > > > I'll have a look. Sounds like much the same approach I was taking. > > It's a fairly neat way to solve the problem. Rather than creating a > > separate LTSP root, you just export your own root filesystem as read-only > > and all_squash (i.e. only files accessible to all users are visible on the > > export). You need to be running in security level 2 for this to work (in > > 3 and higher mode o+r is missing from many crucial files). > > This means that any application installed on the server is instantly > > available to be run as a local app on the diskless terminal. > The only issue I see immediately with that is if you're hosting clients > that are other archs. I was building a seperate ltsp root, from the live > system, which also has the same problem. I suppose in practice, that > scenario probably doesn't arise that often.
Probably not often enough to justify the (rather large) extra effort. FHS does sort of allow for one root filesystem supporting multiple architectures, doesn't it? Should it not be possible to have e.g. a /lib64 directory alongside /lib? Maybe RPM could be extended to allow installation of "foreign" architecture packages in this way? That would be a more generic solution. > > A small patch to Etherboot (which has been added to Etherboot CVS; I have > > commit access) causes the NIC to identify itself to the DHCP server. The > > mkinitrd-net package takes care of creating initrds for each network > > module and sets up the DHCP server so that the correct kernel+initrd > > automatically gets selected by the Etherboot code. Very painless. > Sound like you've got it all worked out. Wish I knew this a week ago :) Join the Etherboot-developers list; I did announce it there :-) Michael
