[K12OSN] Plans for K12Linux EL6 and Future Fedora

[Rob Owens]

Warren has already recommended Debian as a viable alternative for folks
on this list.  I can understand wanting to stick with Fedora and CentOS
if that's what you know best.  How about this:

Use Debian as the LTSP server that boots up your thin clients.  Then,
using the "next server" option in dhcpd.conf, get your GUI from a Fedora
or CentOS server of your choice.  (Assuming that functionality is still
present in recent Fedora and CentOS).  Or... Use VNC or something similar to
connect from a stripped-down Debian thin client to a machine of your
choice.

Both of these solutions give you the easy management of LTSP, with the
Fedora/CentOS/other user experience you might be looking for.  These
solutions only add one extra server to your system, and it can be a
really, really low end system if all it's going to do is PXE boot your
thin clients.

Or you could just use Debian like Warren mentioned.  I use it, and it
works nicely.  The LTSP package manager for Debian is easy to get in
touch with on the ltsp-discuss mailing list.

-Rob

On Sun, May 08, 2011 at 02:50:37AM -1000, Warren Togami Jr. wrote:
> Hi folks,
> 
> It has been a LONG while since I've been able to look at
> k12linux.org, but I haven't forgotten about this project.  2007
> through 2009 Red Hat generously supported my time to work on this
> project.  In 2010 I've since left Red Hat in order to help my
> parents with the family business and prepare for grad school.
> 
> K12Linux LTSP EL6
> =================
> I soon plan on working on a version of LTSP based on EL6.
> 
> Since CentOS *still* hasn't released their EL6 clone, I am thinking
> to base it on SL6.  I suspect it wont be much work to adapt Gavin's
> work to make a EL6 based K12Linux since not much changed between F13
> and EL6 and they both use Upstart.
> 
> BIGGEST PROBLEM: 32bit EL6 supports a minimum of i686 and they have
> excluded certain kernel modules required by LTSP like nbd.ko.  For
> this reason, we may need clients of EL6 to boot images based on
> Fedora 12/13?/14? that still have userspace capable of running on
> i586.  I would need to see what are the supported archs and kernels
> in those versions of Fedora.
> 
> At the moment I suspect this might be doable with about a week of my
> effort.  I've entirely given up on expecting development help from
> you the community after I've asked in vain from you folks these past
> years.  That's OK.  I will try.  But I am only able to pick the low
> hanging fruit.  If I cannot quickly make it work, then this will be
> the end.
> 
> (If someone is willing to financially sponsor my time, I may be
> willing to put more effort into this.  Contact me privately if
> interested.)
> 
> The LTSP based on EL6 would likely be the LAST version of LTSP for a
> RH-derived distribution.  Given the LONG lifespan of EL6 this should
> give the considerable numbers of existing LTSP deployments many
> years of life.  However, since the only maintainable way we can
> build the client images for EL6 is from a particular old Fedora
> version, this effectively means that K12Linux LTSP EL6 will be
> frozen forever in client hardware support.
> 
> Fedora 15+?  LTSP IS OBSOLETE
> =============================
> Theoretically LTSP upstream could be adapted to work with Fedora
> 15+, but for a number of reasons it has become impractical to expect
> continued support for LTSP in Fedora.
> 
> * LTSP relies on the ancient and almost now untested functionality
> of remote X.  Fedora 8 through 12 I was effectively the only Red Hat
> engineer working on remote X desktop and netboot issues.  The entire
> Fedora distro will continue to further drift away from working
> remote X desktops as it simply was never a priority.
> 
> * Fedora 15+'s GNOME 3 will be totally incompatible with the vast
> majority of LTSP client hardware incapable of compositing, while the
> non-composited fallback is likely to be poorly tested and poorly
> supported, especially in the remote X case which nobody but LTSP
> would use.
> 
> * As Fedora progresses, its 32bit kernel and userspace will drop
> support for the majority of LTSP client hardware, if it hasn't
> already happened.
> 
> * A possible way to keep Fedora LTSP somewhat working for a few more
> years might be to switch the default desktop to something else like
> KDE or XFCE that relies on just plain non-composited X.  But that is
> still a non-trivial amount of effort to make it a smooth user
> experience since remote X is poorly tested there as well.
> 
> For these reasons, and the fact that I am no longer sponsored to
> work on this, it seems unlikely that LTSP will ever again be
> officially supported by Fedora.
> 
> Next Generation of K12Linux: Desktop Virtualization
> ===================================================
> http://en.wikipedia.org/wiki/Desktop_virtualization
> I have been thinking about a theoretical next generation technology
> replacement for LTSP.  Fedora contains the remote desktop protocol
> SPICE and kvm, the Open Source core components of a VDI solution.
> 
> A theoretical K12Linux based on SPICE would have each user's desktop
> running within their own virtual machine on a pool of centralized
> servers.  Maybe each user's desktop VM would be hibernated to disk
> when their client disconnects in order to conserve central server
> resources.
> 
> The desktop GUI and sound would be forwarded over the network and
> viewable with the SPICE client running on thin clients.  This would
> theoretically allow K12Linux deployments to connect to any mix of
> both Windows or Linux virtualized desktop machines, although
> K12Linux would only document the Linux case.
> 
> SPICE requires much beefier client hardware.  It appears that first
> generation Intel Atom with i950 video is only borderline powerful
> enough to handle it.
> 
> I suspect that SPICE will never support compositing.  So a VDI-based
> Fedora 15+ would be using the non-compositing fallback (which I've
> only heard about but never tried).  At least it wont rely on the
> almost untested remote X functionality.
> 
> Youtube sucks much less over the SPICE protocol than with remote X
> of LTSP.  Modern expectations of stuff like video are another nail
> in the coffin for the old LTSP model.
> 
> This is all very theoretical.  The problems involved to make this a
> smooth user experience may make this plan infeasible for volunteer
> developers.
> 
> Warren Togami
> warren at togami.com
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>