Planning for LTSP EPEL-6

[Warren Togami Jr.]

On Tue, Feb 5, 2013 at 5:46 PM, Warren Togami Jr. <wtogami at gmail.com> wrote:

> *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.
> *
> *
>

http://sourceforge.net/mailarchive/message.php?msg_id=29687242
https://bugzilla.novell.com/show_bug.cgi?id=776027
It seems our current nbd-2.9.20 is the last version that was compatible
with xinetd, the old way of serving nbd images to arbitrary clients.

The SuSE dev cyberorg told me that upstream didn't intend to break xinetd.
 But 3.2 nbd-client used in the old way (IP address and port) can continue
to work if the nbd-server running as a standalone daemon is configured with
"oldstyle = true".

It seems if we are concerned about current EPEL-6 nbd-server users (who are
they?), we shouldn't update nbd in Fedora or EPEL-6 until they fix
nbd-server's ability to operate with xinetd.



> **
> *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.
>

http://togami.com/~warren/archive/2013/switch_root.c
Note for Joshua: I thought switch_root would attempt to delete the real
root, but it actually stops at the mount barrier.  If not, perhaps a lazy
unmount of the real root prior to switch_root might successfully protect it
without breaking the fuse overlay.  Needs testing.

Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20130205/2cbb2791/attachment.htm>