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). <div class="gmail_quote">On Thu, May 12, 2011 at 8:01 AM, Rob Owens <<a href="mailto:rowens@ptd.net">rowens@ptd.net</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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 <div class="im"> 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 > <a href="http://k12linux.org" target="_blank">k12linux.org</a>, 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. > </div>> 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. <div class="im">> > 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. > </div>> 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 > =================================================== > <a href="http://en.wikipedia.org/wiki/Desktop_virtualization" target="_blank">http://en.wikipedia.org/wiki/Desktop_virtualization</a> > 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 > <a href="mailto:warren@togami.com">warren@togami.com</a> <div><div></div><div class="h5">> > _______________________________________________ > K12OSN mailing list > <a href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/k12osn" target="_blank">https://www.redhat.com/mailman/listinfo/k12osn</a> > For more info see <<a href="http://www.k12os.org" target="_blank">http://www.k12os.org</a>> _______________________________________________ K12OSN mailing list <a href="mailto:K12OSN@redhat.com">K12OSN@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/k12osn" target="_blank">https://www.redhat.com/mailman/listinfo/k12osn</a> For more info see <<a href="http://www.k12os.org" target="_blank">http://www.k12os.org</a>> </div></div></blockquote></div> -- -- 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