Am Montag, 7. Juni 2004 11:59 schrieb John Sutton: > Hi there > To date I have been using netboot's mknbi (version 0.8, just because it was > easier to compile than etherboot's mknbi back in 1998 and I haven't seen > any need to change it since ;-) while at the same time using etherboot's > rom code dowloaded from romomatic.net as and when I get new cards. Anyway, > it seems like the world has been passing me by as it now appears that > etherboots nbi code is capable of booting up a kernel image which has got > an initrd strapped to the end of it? Hence it is no longer necessary to > build all the network drivers into the kernel, which is a big plus for
Using more recent etherboot version, you'll need a recent mknbi as well. You have been warned :-) There is a lot more possible with mknbi & etherboot, like booting DOS etc... > abandoning my own config. But this extract from the docs has confused me: > > --------------------------------------------- > LTSP - Linux Terminal Server Project - v3.0 > > Chapter 1. Theory of operation > > 16. dhclient will then be run, to make another query from the DHCP server. > We need to do this separate user-space query, because if we depend on the > query that comes from Etherboot, it will get swallowed up by the kernel. > And, the kernel will ignore any NFS server that might have been specified > in the root-path. This is important if you want the NFS server to be > different from the TFTP server. > -------------------------------------------- > > Surely all the info from the initial dhcp query is available on the kernel > command line so why is it necessary to do a second one? I wouldn't expect all initial info to be available on cmdline. This will especially be true in setups where the ltsp kernel + initrd are started from harddrive instead of network or from CD or whatever. Running dhclient makes the initrd much more generally usable. > Finally, in my own config I mount the servers root as root for the clients > as well and then mount private /etc /var /tmp & /dev-state on top for each > client individually. Probably this is considered a security no-no? In my > own environment it works fine and IMHO reduces considerably the maintenance > required when upgrading the whole system, but I'd be interested in reading > any discussions of these security issues with a view to changing my mind! The first reason for not doing so is that you need a same-architecture server in your setup. LTSP is, contrary to this, able to run off a Win NT server even, or any Linux/ppc, Sun Solaris, Open/FreeBSD, Linux/ia64 etc. pp servers. Only stuff the server must support (can be splitted to different servers even) are NFS-server, DHCP-server, X-login manager or RDP server, depending on what you want to do. The second reason is of course security considerations, as having / exported over NFS might reveal /etc/passwd etc. over the wire - If you can do without, the better. LTSP only needs a separate subtree available with NFS. The third reason is that LTSP has some non-typic setups (like local-devices etc) that can be much easier supported when the system is in a separate directory. Updating LTSP is easy as "tar -xzf" anyway, you can usually just unpack the new tarballs (remember to save your config before doing so). HTH Anselm ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
