On Fri, 7 Jun 2002, Matthew Tedder wrote: > > 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). > Seems a bit inflexible and a method prone to many unknowns. That would make > me nervous until and unless I saw it running for a time at many a variety of > sites to ensure it can still be twisted to meet the specific requirements of > each.
Not at all inflexible if you use ClusterNFS or something similar, since it allows you to create files that appear differently for each client if so desired. > > This means that any application installed on the server is instantly > > available to be run as a local app on the diskless terminal. > Yes... I very nice upside.....although there are good arguments for not > having this.......including security, differentiation for different hardware, > etc. What's the security argument? Differentiation for different hardware is a non-issue: see below. > > It also uses the stock Mandrake kernel, instead of requiring LTSP kernels. > > 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. > I was under the impression that a lot of work was done in getting the images > for LTSP as it is. Each different piece of hardware may very likely require > different kernals. Not only that, but different X servers. The ThinkNIC, > for example, requires the xvesa server in order not to blur graphics on > screen. Many particularities exist for various different motherboards. > Intel's DX810E requires USB drivers for the mouse/keyboard and printer. This > is all likely to be very different then for the host. Every piece of hardware doesn't require a different kernel: that's what kernel loadable modules are for. X servers and some other hardware will require slightly different *configuration files* for some clients, yes. There are many ways to solve this problem, for example: 1. XFree86: have X started up using /etc/X11/XF86Config.hostname, falling back to /etc/X11/XF86Config if this doesn't exist (trivial). If you want to be more sophisticated, use a PCI scan for the graphics card and use /etc/X11/XF86Config.PCIID. 2. Any software package: use ClusterNFS' capability for serving up different files to different clients. If you create the file /etc/X11/XF86Config$$CLIENT$$ then any NFS client will see the contents of this file in place of /etc/X11/XF86Config. This approach (single software installation, differentiation of the configuration files) is far more elegant than duplicating (triplicating, etc.) package installations. If you take a look at the terminal-server package, you'll see the way that X configuration is handled: /etc/X11/XF86Config$$CLIENT$$ is symlinked to /tmp/XF86Config.test. /tmp is mounted as tmpfs on the clients (as indicated via /etc/fstab$$CLIENT$$ - obviously the clients need a different fstab to the server). This means that you can boot up a client, with the root filesystem mounted read-only via NFS, and immediately run XFdrake to generate your X config files in /tmp (XFdrake is available to run on the client simply because it is installed on the server). scp these back to the server (again, scp is installed on the server and therefore available on the client) and away you go. I have a planned improvement: X should fall back to framebuffer mode if it hasn't been configured yet for that machine (in the same way that the graphical installer uses framebuffer X). The "share your own root filesystem" approach is an order of magnitude easier to maintain than the "separate ltsp root" approach. If you install mkinitrd-net and terminal-server then you have a working terminal server, with the ability to boot from any network card you have a module for and to run any software that you have installed on the server. Nothing else needs to be done - just install and play. Michael
