On Tue, Feb 5, 2013 at 5:46 PM, Warren Togami Jr. <wtogami@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.

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.

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.

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.