[K12OSN] K12Linux EL6 Preliminary Feasibility Assessment

[Warren Togami Jr.]

I did some quick hacking of LTSP upstream on SL6 in order to determine 
what works and what is broken.

GOOD
====
* Installed /opt/ltsp/i386 with lots of error messages.
* WORKING: Client Login to GNOME desktop.
* WORKING: Remote sound, Youtube video played with audio in sync.

BAD, BUT I KNOW HOW TO FIX
==========================
* LOTS OF ERROR MESSAGES DURING BOOT
* nc syntax seems to have changed (?)
* qemu-kvm changed to discourage direct use.  SDL-mode longer supported. 
  This means ltsp-vmclient cannot be used anymore as method for rapid 
thin client testing.  I suspect this could be worked around by manually 
modifying a virt-manager VM configuration to connect to ltspbr0 and PXE 
boot.
* nbd-server changed, need to redo how LTSP handles both the client and 
server side of NBD.
* Wow.  My documentation on k12linux.org sucks a lot.

BAD, NOT SURE HOW TO FIX YET
============================
* BROKEN: Something is seriously wrong with pxelinux.  I was able to 
manually boot only by typing in parameters.
* BROKEN: K12LINUX themed ldm is broken.
* BROKEN: Remote USB storage (ltspfs)
* CONFUSING: Various parts of GNOME desktop like PackageKit are confused 
because ConsoleKit has no awareness of ssh logins, manifesting in 
various broken dialogs and annoying pop-up login screen during every 
user login.
* BROKEN: Crippling blocker issue with locked screens, need to talk to 
GNOME developers ...

BAD, LIMITATIONS OF EL6 HARDWARE SUPPORT
========================================
i686 with PAE minimum means the majority of existing LTSP client 
hardware are unsupported.  Additionally, EL6 kernel lacks nbd.ko.

Partial Solution: Kernel-only replacement for /opt/ltsp/i386.  i686 
without PAE with nbd.ko included would support *more* hardware, but 
still a large percentage of LTSP client hardware that is i586 will not work.

Full Solution: Rebuild 500+ client packages to i586 or use Debian for 
/opt/ltsp/i386.  Either option is bad because of significant effort to 
initially create it, and long-term support issues.

Analysis
========
This is significantly more broken than I expected.  Worrisome are the 
broken parts of GNOME, because we likely cannot get patches into 
upstream EL6, and any patched packages that we ship ourselves will be a 
long term maintenance burden.

I will do a little more feasibility testing later, but I already can say 
that this is looking like too much work for the previous cost estimate.

In short: Yes, this appears feasible.  But it will be a LOT of work to 
make it an acceptable solution.

Warren Togami
warren at togami.com