wtogami ([info]wtogami) wrote,
@ 2008-03-07 01:10:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Help Needed: LTSP5 for Fedora
I finally have LTSP5 mostly working.  It took many months of work to whip upstream into an actual upstream project (the hard part) and to adapt Debianisms or rewrite stuff to work with Fedora (slightly less hard).  It currently is ready for early testing.  I would really appreciate feedback and especially patches to help bang this into shape for Fedora 9.  Fedora 8 works a bit better than Fedora 9 currently.  See below for details.



Packages of LTSP5 in Fedora

ltsp-vmclient: (screenshot above) This package is a convenient way to test LTSP with PXE boot qemu-kvm.  You don't need the hassle of plugging in extra hardware in order to test your LTSP server setup.
ltsp-client: This package installs into the client chroot only.
ltsp-server: This package installs on the LTSP server only.
ldm: This package contains the LTSP Display Manager.  LDM runs on the client, asking the user for username & password, and optionally to choose a desktop session (GNOME, KDE, XFCE, etc.) and non-default language.  When the user types a name and password it attempts to login to the server via SSH.  This needs perhaps the most work of all LTSP components before Fedora 9.
ltspfs: Handles "local device" support for CD-ROM, floppy, and USB sticks.  These local devices are mounted and visible on the server.
pulseaudio: Pulseaudio handles sound over the network.

Important Scripts within ltsp-server
ltsp-build-client:
This script installs a client chroot into /opt/ltsp/i386.  If your host is Fedora 8, it installs a Fedora 8 chroot.  If Fedora 9 host, you get a Fedora 9 chroot.  You can override the OS of the chroot to install with --release=X.  These client chroots are mounted over the network by the thin clients, allowing them to boot and run ldm.
ltsp-server-initialize: This script is meant to enable services and configure things to make a Fedora machine into a LTSP server.  Currently this doesn't work at all.  It needs lots of improvements to do the right thing, and even then it is probably is not entirely safe for all users.  See the directions below for minimal configurations necessary to run a LTSP server.
ldiminfod: This is the main thing needed on a server in order to support LDM client connections.  It advertises to LDM clients available desktop sessions, languages and a "rating" of how busy the server is.  In the future ldminfod will be split into its own package.

Status
  • The current state is pre-alpha.  It might work, but all sorts of things could still change including the location or contents of config files.
  • Remote sound with pulseaudio is currently broken.  The pulseaudio daemon flags called from /usr/sbin/ltsp-client-launch would be the first place I would look.  See /usr/share/ltsp/ltsp-init-common in ltsp-client if you want to help.
  • ltsp-build-client on F8 host requires the livecd-tools from F9.  I put it into the temporary repository for F-8.  It is safe as long as you are not making any LiveCD's.
  • LDM (default X connection type) is broken in a F-9 chroot due to Bug #436230.  If you understand how xauth works some help to fix LDM would be appreciated.  If you want to try LTSP with a Fedora 9 host use ltsp-build-client --release=8 to install a Fedora 8 chroot instead.  A possible alternative is to edit /var/lib/tftp/ltsp/i386/lts.conf and change SCREEN_07 to xdmcp instead of ldm.  You would get a plain X -query.  (Conversely you can test a Fedora 9 chroot on a Fedora 8 hosts with ltsp-build-client --release=9.)
  • I could use some help getting these snapshots into package reviews for Fedora 9.  (Some packages already have earlier versions approved or in review.)
  • See the Bugzilla Tracker for other current issues.
TODO (in priority order)
  • Fix Bug #436230 so LDM works in a F-9 chroot.
  • Install k12ltsp-temporary .repo files into the client chroot so it can yum update itself.
  • Submit all packages for review.
  • Write iptables rules to allow dhcpd, NFS server and other needed services to work without disabling the firewall.  Lokkit integration?  I don't know what the best way is here.
  • Fix ltsp-server-initialize so it actually works.
  • Fix pulseaudio launching for remote sound.
  • Detect  and fail upon mismatch between /etc/xinet.d/tftp setting and what it should be on the target OS during ltsp-build-client.  F-8 was /tftpboot while F-9 was /var/lib/tftp.
  • LDM needs the ability to launch all sessions through Xsessions instead of running them directly like it does now.  For example, running gnome-session directly means the stuff in /etc/X11/xinit/xinitrc.d are bypassed.
  • Fix cdpinger segfault.
  • Verify that local devices (CD-ROM, floppy, USB key, etc.) are auto-mounted and visible on the server.  This possibly needs ConsoleKit integration so device permissions are set properly upon login (not sure).
  • Implement NBD root handling in mkinitrd (better and faster than NFS for network boot)
  • Make LDM's ldminfod "protocol" versioned.
  • Move ldminfod into the LDM source tree and make it into its own sub-package.  It could be installed independently of ltsp-server.
  • LDM needs to be localized, and to display language choices in native localizations depending on the default locale.  This will definitely need ldminfod protocol changes.
  • Implement x86_64, ppc, and other arch client recipes.
  • Implement optional offline install from media of client chroot (many target users don't have an Internet connection, or too slow)
Installation
  • Read all the above notes.  Lots of stuff is broken so you must be prepared.
  • Install k12linux-temp-release [F8] [F9].  Until we have everything fully integrated into Fedora, this temporary repository will contain stuff needed for the LTSP server and clients.
  • WARNING: This temp repository replaces two packages on Fedora 8.  A newer livecd-tools is needed on the host in order to install the client chroots.  A newer mkinitrd is needed in the client for network boot related functionality.  For safety purposes this mkinitrd is not in the k12linx-temp repository and it is installed only into the F8 chroot from the kickstart file.
  • yum update livecd-tools
  • yum install ltsp-server
  • yum install ltsp-vmclient if you want the qemu-kvm PXE boot client launcher.  Requires hardware virtualization support or it will be very slow and possibly unusable.
  • Uncomment the option_cache_value line in /etc/ltsp/ltsp-build-client.conf if you want to keep a local cache of packages to be installed in the client chroot.  This might be useful if you keep testing newer versions of ltsp-server and you will be reinstalling the client chroot.  Erase /var/cache/chroot if you no longer need this cache.
  • ltsp-build-client
  • The below steps can theoretically be done by running ltsp-server-initialize.  However it is currently broken.  Anyhow you probably want to do it manually yourself the first time so you know exactly what is going on.
  • echo "/opt/ltsp *(ro,async,no_root_squash)" >> /etc/exports
  • ifup ltspbr0
  • for service in xinetd ltsp-dhcpd rpcbind nfs sshd; do chkconfig $service on; service $service start; done
  • for server in ldminfod nbdrootd nbdswapd; do chkconfig $server on; done
  • Disable your firewall during these tests.  It will interfere with DHCP and other incoming connections.
  • At this point ltsp-vmclient will theoretically work.  If you want to boot a real thin client read below.
Network Setup
  • I am experimenting with a unique way of handling LTSP networking by default.  LTSP5 in Fedora automatically configures itself to run on a virtual bridge device instead of a real Ethernet interface.  ifcfg-ltspbr0 is installed by default, creating bridge ltspbr0 with a default network of 172.31.100.0/24.  This network is self-contained on the server allowing internal testing with ltsp-vmclient if desired.
  • If you want to connect real thin clients to this LTSP server, you must add Ethernet interfaces to this virtual bridge.  brctl addif ltspbr0 ethX can be used in a temporary fashion, which is handy if you are plugged directly into a single thin client for quick testing.  This can even be done on a laptop conveniently if you disable NetworkManager's auto-connect on the eth0 interface.  For permanent networks you would define a ifcfg-ethX interface to add itself to the bridge (no IP address needed for itself).
  • This setup has two key benefits:
    • Easier to Understand: Sysadmins only need to know to add an Ethernet interface to ltspbr0 if they want to connect thin clients through that interface.  This requires an explicit action and it is much easier than configuring interfaces and matching dhcpd.conf's in separate places.
    • Safer: dhcpd can be explicitly limited to serve only to ltspbr0.  This reduces the chances of accidentally screwing your home/school/work/district-wide network by becoming a rogue DHCP server. =)
  • I realize that this method of LTSP server network configuration is very different from the past.  I intend on better documenting it soon to make it easier to understand and deploy.  Your comments on this idea would be appreciated.
FAQ
  • Why are some locations like /opt/ltsp/i386 stupid?
    /opt/ltsp/$arch came from LTSP and has been in use for 8+ years now.  Upstream LTSP5 to be shared between Debian, Ubuntu, Gentoo, OpenSuSE and others all use that location.  It would be nice if everyone came to agreement on a new standard location, but nobody wants to fight that battle right now.
  • Why are there no versions and everything is a snapshot?
    That's the way Ubuntu worked on this for the past 2 years. =(  I'm working on getting actual versions tagged and tarballed soon.
  • GAH!!! LDM and/or LTSPFS is an ugly hack!
    That might be true, but they have working code already in production by thousands of sites today.  Where is your better implementation?  Write it and I'd be happy to consider switching.
  • What about backporting to VERSION 5?  (I'm complying with the corporate master's goodspeak.)
    I hope that I can backport this to VERSION 5 later.  We can't realistically make progress on this until the tools and capabilities are standardized for Fedora 9.  Ask later.
Tips
  • Enable yum install or yum update in the client chroot:
    cp /etc/resolv.conf /opt/ltsp/i386/etc/resolv.conf (or set it appropriately)
    mount /proc
  • Erasing client chroots:
    Make sure everything is unmounted from the chroot before you delete it.  Check /proc/mounts to be 100% sure stuff is unmounted, as /etc/mtab can lie to you if something was mounted within the chroot.  If ltsp-build-client failed for some reason, check for leftover bind mounts before erasing the wreckage and trying it again.
  • If your thin client has Intel video, try enabling compiz after you login. =)
How can I help?
  • Test it!  Report bugs!  Ask questions.  fedora-devel-list or fedora-education-list are both fine places.  If you have a LiveJournal account you may reply to this blog post too.  In a few days there should be Bugzilla components for all these packages so you may be able to post real bugs there.  Please DO NOT SEND ME PERSONAL MAIL.  I am less likely to respond to personal mail than a public mailing list post.
  • Get involved in development.  I wrote tools to make changing stuff and building your own installable test RPMS very quick and easy.  Here's a primer.
    • yum install mkdst bzr rpmdevtools
    • bzr get http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk
    • cd ltsp-trunk
    • ./mkdst --testrpm - This command attempts to build a test RPM based upon whatever is in the directory, whether it is local change checked in or not.  If the build fails it tells you what went wrong.  If you are doing this on a x86_64 host you will likely want to throw the .src.rpm into mock to build a i386 version if you want to upgrade the package in the chroot.
  • Source Repositories



(Post a new comment)

pxelinux.0
[info]pirast
2008-03-08 11:43 am UTC (link)
When using /usr/sbin/ltsp-vmclient it tries to load pxelinux.0 but can't find it (it does not exist in /opt/ltsp/i386).

(Reply to this) (Thread)

Re: pxelinux.0
[info]pirast
2008-03-08 12:10 pm UTC (link)
hm okay, i noticed that it does exist in /tftpboot which should probably work.. weird

(Reply to this) (Parent)(Thread)

Re: pxelinux.0
[info]pirast
2008-03-08 01:28 pm UTC (link)
the problem was caused due to tftp being disabled by default. I had to uncomment the disable in /etc/xinetd.d/tftp

(Reply to this) (Parent)(Thread)

Re: pxelinux.0
[info]pirast
2008-03-08 02:27 pm UTC (link)
so far, it starts now (which is very slow, but this may be caused by qemu). ldm could look a little bit nicer but anyway, when I try to login, I get "the workstation is not authorizized to connect to the server". after, ldm restarts (is this needed?)

(Reply to this) (Parent)

(Reply from suspended user)
dhcpd
[info]pirast
2008-03-09 01:20 am UTC (link)
maybe you'd add a step to disable the default startup of dhcpd (default for package afaik) because there is ltsp-dhcpd already.

(Reply to this)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…