Diskless workstations

[Paul Iadonisi]

On Wed, 2003-07-23 at 17:40, Stephen Smoogen wrote:
> Hi one thing that has come up over and over again (here) is that Debian
> is easier to install into a diskless workstation environment than Red
> Hat. I being the RH bigot that I am have not tried this yet, but I get
> the feeling that it is.
> 
> I would really like to see some work on making a Heavy Diskless
> Workstation install possible in the future. [Heavy Diskless means boxes
> that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.]
> THere are many environments that use this heavy duty, and right now I am
> having to admin 4 different ways of killing the problem with no one
> absolutely correct. 

  Well, if I understand what you are asking for, the K12LTSP project (at
http://www.k12ltsp.org/) serves this purpose quite well.  Version 3.1.1
is Red Hat 9 with updates (through around June 24), ltsp packages from
http://www.ltsp.org/ and a few additional packages suitable for an
educational environment.
  So a *lot* of this (excellent) work has already been done by Eric
Harrison and Paul Nelson who head up the project.  I've been able to do
an install of a server and *even before ever logging into the server* to
tweak even a single setting, I'm able to boot a thin client with a PXE
enabled network card and have a working desktop.  Fabulous work on Eric
and Paul's part.
  What does require some work is the ltsp packages themselves.  They
most certainly won't meet any Red Hat criteria.  The K12LTSP project
takes them directly from the LTSP project and makes some minor tweaks
but they suffer from what I consider a nasty problem: they are built
from binary tarballs created by lifting binaries directly from an
existing distribution (in this case, Red Hat 7.1, I believe).
  The ltsp packages included in K12LTSP 3.1.1 are based on ltsp version
3.x.  The new ltsp version 4.x (I think still currently in alpha stage)
takes an entirely different approach.  What they do now is build an
entire cross-compiling, chrooted environment to build all packages
(tarballs, really) for the thin clients.  This allows the LTSP project
to be more distribution agnostic, but it isn't much better from a
perspective of fitting into Red Hat neatly.
  I've been working on (and am willing to take on the task of doing so
for the Red Hat Linux project) coming up with better ltsp packages that
will fit nicely into Red Hat.  No binary tarballs in the src rpms, no
special build environments, but very specific to Red Hat.  There are
some issues to be worked out, however:

1) It seems the LTSP project has been concerned about disk space for the
thin client tree (defaults to /opt/ltsp/i386), as is evidenced in their
use of busybox instead of the real tools.  I ask, what's the point? 
It's all stored on the server and it takes no additional RAM on the
clients.  Heck, the commands are barely (if at all) even used outside
the boot process.  So why not just install second copies of the rpms
that are needed by the thin clients into an alternate root (like
/opt/ltsp/i386)?  There's other stuff that needs to be added (config
files an the like), but those can be in additional packages.

2) Is it reasonable to ask for a change to anaconda to allow for these
rpms to be installed in this alternate root?  It would probably be an
invasive change, as it's not currently done anywhere in anaconda, to the
best of my knowledge, except that the actually installer *does* in fact
install the entire distribution into an alternate root (after, how else
would you do it?).  What's different is that now I'm asking for anaconda
to switch gears in the middle of the installation and install a specific
list of packages in a different alternate root.

3) If the above isn't considered the best approach, another possibility
is to rebuild the required rpms (and probably rename them with an
'ltsp-' prefix or some such distinction), with a different prefix
directory.  That seems like potentially a lot of extra build time and
complexity, however, especially since both the (mknbi enabled) kernel
and XFree86 are needed.  Thoughts?

4) The last approach that I can think of is having a single ltsp-config
package (or equivalent, name it whatever) that has includes all the
additional ltsp stuff (config files, etherboot images, etc.) and a
single script that checks to make sure all the rpms required for the
thin client tree are actually installed in the normal root directory.
and just copies all the required binaries into place in the
/opt/ltsp/i386 tree.  Alternatively, the script might not require that
the rpms be installed on the server, but instead take a directory with
the required rpms so that the appropriate rpms can be extracted.  Of
course, this approach has the problem of issuing errata: the script
would have to be run whenever any relevant errata was issued.

So I'd like some input into how to approach this and I'd also like to
hear if there is sufficient interest in having this included in the Red
Hat Linux project.  If so, looks like I found my niche!  (Unless of
course Eric Harrison is on this list and would like to do it himself --
I tend to doubt it, though, given how busy he already is. ;-))