Planning for LTSP EPEL-6

[Warren Togami Jr.]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20130205/cb273d4a/attachment.html>