[K12OSN] Plans for K12Linux EL6 and Future Fedora

Fri May 13 16:50:09 UTC 2011

I made a mistake.  "next server" in dhcpd.conf is not correct.  If you
specify "SERVER=somefedoraserver" in lts.conf on a separate LTSP
Debian box, you could provide a remote Fedora experience as long as Fedora
supports remote X.  If remote X is not supported, then maybe a screen
script could be made for VNC, NX, or something similar.

But I think Warren's suggestions of simply making a Debian chroot on a
Fedora/RHEL/CentOS machine makes more sense.  Am I wrong, or would you
just need to get Debian's ltsp-build-client to work on Fedora/RHEL?

-Rob

On Thu, May 12, 2011 at 08:35:32AM -0400, Jim Kinney wrote:
> Rob,
> 
> I don't see the issue being server support of pxe boot on CentOS (or RHEL or
> Fedora - cobbler is mainstreamed for all of these). The issue is the OS
> available for the thin clients to use that's provided by the server. The
> minimum hardware supported for Fedora is i686 so many really old i386 and
> alternative cpu systems are automatically off the list.
> 
> However, Debian still supports all the way to the _real_ i386 system as well
> as other very slim distros (I've tinkered with tinycore - runs in 10M ram!).
> 
> So the real work is to fix the servers so they support providing an
> non-server OS to the clients.
> 
> Another issue I hit the wall on a while back was the (ab)use of flash in
> almost all edu web sites. Flash has not become a lighter weight tool either.
> So many teachers are wanting to use youtube and other flash video sites
> (heck, all multimedia) in the classroom and for large installations, that
> will bring a beefy server to it's knees when 30 clients fire up the same
> video. It just doesn't scale.
> 
> So the solution that my team and I were moving towards was what we called a
> "chubby client". PXE boot OS and NFS mount a full root with all binaries
> (not the server OS by default). The system ran X local and thus all
> application ran local, especially firefox with flash. So a single overload
> would not bring down the server but just a single client. The big technical
> hurdle we hit was the need to limit the tab count for firefox (or at least a
> memory usage as there was no plan for swap space - that may change).
> 
> On Thu, May 12, 2011 at 8:01 AM, Rob Owens <rowens at ptd.net> wrote:
> 
> > 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>
> >
> > _______________________________________________
> > K12OSN mailing list
> > K12OSN at redhat.com
> > https://www.redhat.com/mailman/listinfo/k12osn
> > For more info see <http://www.k12os.org>
> >
> 
> 
> 
> -- 
> -- 
> James P. Kinney III
> 
> As long as the general population is passive, apathetic, diverted to
> consumerism or hatred of the vulnerable, then the powerful can do as they
> please, and those who survive will be left to contemplate the outcome.
> - *2011 Noam Chomsky*

> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>