Bug#846998: nbd-server: Broken NBD configurations using a leading slash

[Vagrant Cascadian]

On 2016-12-04, Vagrant Cascadian wrote:
> Unfortunately, it appears the fix to #840612 breaks LTSP's use of NBD:
>
>   #840612  initrd forces NBD section name to start with the slash
>
>
> A presumably unintended side-effect of that fix breaks LTSP's
> long-standing "default" configuration for NBD on amd64
...
> nbdroot=/opt/ltsp/amd64 or nbdroot=1.2.3.4:/opt/ltsp/amd64 are both
> options used for configuring NBD root in LTSP, or if not specified,
> falling back to the root-path specified similarly.

so, I'm trying to wrap my head around the code in
initramfs-tools/scripts/local-top/nbd, but what's kind of a blocker is I
don't know what values for nbdroot are considered valid. in
debian/nbd-client.initrd I see roughly four case statements...


case "$nbdroot" in
        *,*,*)
                nbdsrv="${nbdroot%%,*}"
                nbdpath="${nbdroot%,*}"
                nbdpath="${nbdpath##*,}"
                # root= parameter overrides three-option nbdroot= parameter
                if [ -z "$nbdrootdev" ]
                then
                        nbdbasedev="${nbdroot##*,}"
                        nbdrootdev=/dev/$nbdbasedev
                fi
                ;;
        *,*)
                nbdsrv="${nbdroot%,*}"
                nbdport="${nbdroot#*,}"
                ;;
        \[*\]*)
                # [ipv6]:port/path
...
        *)
                # ipv4:port/path


I think, if I'm reading this right, that gives us:

nbdroot=

  serverip,path,device
  serverip,port
  serveripv6:port/path
  serverip:port/path

It's not clear to me how a port definition is intended to look on the
last two.


LTSP typically uses one of:

  nbdroot=serverip:path (e.g. 192.168.67.1:/opt/ltsp/amd64)
  nbdroot=path (e.g. /opt/ltsp/amd64)

These last two cases are failing due to the "*" case stripping the
leading "/" in the line:

                nbdpath=${nbdportpath#$nbdport/}

So that it produces a path such as  "opt/ltsp/amd64"


I'm not sure what all the valid examples for all the various cases are
attempting to solve, so I'm having difficulty coming up with a better
patch that doesn't break LTSP's typical use-case.

In the ipv4:port/path and ipv6:port/path cases, what are some examples
that are supposed to work? I haven't used alternate ports at all, is the
intention to define them using a "/" ? that makes it awfully hard to use
"/" in the path.


live well,
  vagrant

signature.asc
Description: PGP signature