Planning for LTSP EPEL-6

Hi folks, Joshua Trimm (FAS: enslaver) has joined the K12Linux project, and is currently working on formal integration of LTSP for EL-6. It is our intent for EPEL-6 to eventually contain all components of LTSP. After EPEL-6 is complete, Fedora may be considered. I have largely moved on from this project, but I am helping the transition to new developers. Joshua is doing at least EPEL-6 since his employer relies upon it. In the long-term K12Linux needs more knowledgeable Fedora developers in order to be sustainable. *Packages* Certain: ltsp, ltspfs, ldm, mkdst, nbd, ltsp-client-kernel Possibly: unionfs-fuse *NBD needs to be upgraded in EPEL-6* https://bugzilla.redhat.com/show_bug.cgi?id=695066#c3 Prior versions of NBD lacked initscripts and standard port assignments, but this has changed with recent versions of NBD upstream. https://bugzilla.redhat.com/show_bug.cgi?id=877518 A systemd unit file was proposed here. We would need an equivalent sysvinit script for EPEL-6. *NBD Upgrade Risk Analysis* - EL-6 lacks nbd.ko, so the userspace nbd-client in EPEL-6 could not be used. Thus it is possible nobody was using the userspace-only nbd-server daemon on EL-6? - *Scenarios:* Does 3.2 remain compatible with old nbd client/server and invocation scripts? If command line parameters and the wire protocol remains compatible, then risk to users is negligible. (Joshua is researching this.) - *Yes, safe to upgrade:* The old way of using nbd by manually specifying port numbers is deprecated but supported in nbd-3.2, so users will not notice any difference. - *No, safe to upgrade: *Even though it is not compatible, nobody was actually using nbd-server on EL-6, so we can safely upgrade it. - *No, not safe to upgrade:* Not compatible, and we don't want to risk breaking users who might have relied on the old nbd-server on EL-6. Use a parallel nbd3 package. - Alternative nbd3 package would obviate the risk of upgrading, but it would create an added maintenance burden. nbd has had several CVE advisories in the past, and we really would be better off avoiding the need to maintain redundant daemons. By upgrading nbd in EPEL-6, it will make it easier to maintain in the future as security fixes will not need to be backported. I believe we have a strong case for upgrading under any of the above scenarios. Joshua will research the compatibility issue to better inform us of the actual extent of upgrade risk. * * *unionfs-fuse and dracut module* Currently LTSP clients netboot a dracut-network generated initrd which mounts a read-only NFS or NBD root filesystem and relies upon /etc/rwtab*. In theory rwtab bind mounts copies of files and directories to the read-only filesystem to allow a stateless client to boot. In practice rwtab has significant problems and was never well supported as most developers never test in readonly root stateless mode. As an alternative, Joshua intends to try the fuse-based unionfs overlay to mimic the kernel-based unionfs overlay used by Debian LTSP. http://podgorny.cz/moin/UnionFsFuse http://pkgs.repoforge.org/fuse-unionfs/ Someone made packages, although it hasn't been tried yet. It would theoretically require a dracut module to move /sysroot to another name, then mount the fuse overlay as /sysroot prior to mounting of any auxiliary filesystems (/proc?) and switch_root. The "other name" may need to be protected from the deletion that occurs prior to switch_root. Hopefully fuse will work as expected even after a switch_root. *LTSP Client Kernel* https://www.redhat.com/archives/epel-devel-list/2011-May/msg00059.html LTSP for EPEL-6 will require a LTSP-only embedded kernel as proposed back in May 2011. Please see this previous thread about why it would be safe for EPEL-6. Warren Togami