wtogami (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} wtogami) wrote,@ 2008-02-06 23:06:00 |
|
LTSP in Fedora, a Status Update
Work is progressing on the LTSP Fedora integration. Some of the current problems...
https://code.launchpad.net/~ltsp-upstrea
ltsp.src.rpm builds ltsp-client and ltsp-server packages. ltsp-server contains a script "ltsp-build-client" that upstream LTSP wants to be the common command to build a LTSP client chroot.
LTSP client chroot installation
A chroot must be built and provided over the network, which is booted by the thin clients. Earlier prototypes of LTSP on Fedora used the distro's own "anaconda" package with a kickstart file to install the chroot. It was done this way because it was a quick and easy way to install into a chroot from kickstart definition and provide the user with progress indicators. Unfortunately we keep running into problems on both target platforms Fedora 8 and Fedora 9 with various bugs and issues within Anaconda itself. It has become clear that we cannot depend on Anaconda for a production version of LTSP because even if we have fixes for Anaconda, we cannot push updates to a stable release of that package.
Jeremy Katz informed me that dramatic improvements are coming to Fedora 9 in the livecd creation tools. It was made into a library so it should be easier to consume for non-LiveCD things now. This is clearly the way forward for this part of the problem. He said these should hit rawhide later this week.
LDM Issues
https://code.launchpad.net/~ltsp-upstrea
LDM is a simple display manager to handle ssh-based authentication between thin clients and terminal servers. We initially ran into some issues due to Debian-specific assumptions made in LDM. For example, Debian uses alternatives to provide the available desktop sessions instead of the GNOME/KDE standard of /usr/share/xsessions/*.desktop files. Vagrant Cascadian discovered that Debian actually does ship those *.desktop files, so ldm was quickly modified to work upon those files instead of rely upon alternatives.
LDM also used Debian's /etc/environment to find the system's default LANG. We apparently don't have this, but it does live in a Fedora-specific /etc/sysconfig/i18n. In order to maximize distro-neutrality in upstream's LDM we changed it to get LANG from the output of the locale command instead.
There remains one major problem in LDM that prevents it from being usable on Fedora. LDM currently in use on Debian uses locale -a in order to get a listing of available system supported languages. This works on Debian where it returns only 17 languages. But on Fedora 8 it returns 696 languages. The LDM gtkgreeter as it is written now chokes on more than ~200 languages. Even if it could handle that many languages it wouldn't be a usable interface at all with that many choices to scroll through.
This particular problem wont be a quick fix. What is the best way to represent an arbitrarily large number of languages in a login dialog chooser? The old gdm wasn't exactly the best in usability in this regard. I consulted Red Hat's Desktop team. It turns out that Ray Strode and Jon Mccann has been thinking about exactly this problem for the current rewrite of gdm happening for upstream GNOME and Fedora 9.
I decided to punt on this problem for now. My goal is to get LDM working with minimal changes in the short-term, then later return to improve its interface later. Perhaps by then the GNOME guys would have wrote their new shiny language chooser interface that could be re-used, and I would also have the opportunity to polish the LDM interface in some ways like displaying localized language names. It is also a long-term goal to explore the possibility of "standardizing" LDM's protocol to make it suitable to support directly from more prevalent display managers like GDM.
Work is progressing on the LTSP Fedora integration. Some of the current problems...
https://code.launchpad.net/~ltsp-upstrea
ltsp.src.rpm builds ltsp-client and ltsp-server packages. ltsp-server contains a script "ltsp-build-client" that upstream LTSP wants to be the common command to build a LTSP client chroot.
LTSP client chroot installation
A chroot must be built and provided over the network, which is booted by the thin clients. Earlier prototypes of LTSP on Fedora used the distro's own "anaconda" package with a kickstart file to install the chroot. It was done this way because it was a quick and easy way to install into a chroot from kickstart definition and provide the user with progress indicators. Unfortunately we keep running into problems on both target platforms Fedora 8 and Fedora 9 with various bugs and issues within Anaconda itself. It has become clear that we cannot depend on Anaconda for a production version of LTSP because even if we have fixes for Anaconda, we cannot push updates to a stable release of that package.
Jeremy Katz informed me that dramatic improvements are coming to Fedora 9 in the livecd creation tools. It was made into a library so it should be easier to consume for non-LiveCD things now. This is clearly the way forward for this part of the problem. He said these should hit rawhide later this week.
LDM Issues
https://code.launchpad.net/~ltsp-upstrea
LDM is a simple display manager to handle ssh-based authentication between thin clients and terminal servers. We initially ran into some issues due to Debian-specific assumptions made in LDM. For example, Debian uses alternatives to provide the available desktop sessions instead of the GNOME/KDE standard of /usr/share/xsessions/*.desktop files. Vagrant Cascadian discovered that Debian actually does ship those *.desktop files, so ldm was quickly modified to work upon those files instead of rely upon alternatives.
LDM also used Debian's /etc/environment to find the system's default LANG. We apparently don't have this, but it does live in a Fedora-specific /etc/sysconfig/i18n. In order to maximize distro-neutrality in upstream's LDM we changed it to get LANG from the output of the locale command instead.
There remains one major problem in LDM that prevents it from being usable on Fedora. LDM currently in use on Debian uses locale -a in order to get a listing of available system supported languages. This works on Debian where it returns only 17 languages. But on Fedora 8 it returns 696 languages. The LDM gtkgreeter as it is written now chokes on more than ~200 languages. Even if it could handle that many languages it wouldn't be a usable interface at all with that many choices to scroll through.
This particular problem wont be a quick fix. What is the best way to represent an arbitrarily large number of languages in a login dialog chooser? The old gdm wasn't exactly the best in usability in this regard. I consulted Red Hat's Desktop team. It turns out that Ray Strode and Jon Mccann has been thinking about exactly this problem for the current rewrite of gdm happening for upstream GNOME and Fedora 9.
I decided to punt on this problem for now. My goal is to get LDM working with minimal changes in the short-term, then later return to improve its interface later. Perhaps by then the GNOME guys would have wrote their new shiny language chooser interface that could be re-used, and I would also have the opportunity to polish the LDM interface in some ways like displaying localized language names. It is also a long-term goal to explore the possibility of "standardizing" LDM's protocol to make it suitable to support directly from more prevalent display managers like GDM.
