On 2016-12-06, Wouter Verhelst wrote: > On Tue, Dec 06, 2016 at 10:38:34AM +0200, Vagrant Cascadian wrote: >> On 2016-12-04, Vagrant Cascadian wrote: >> nbdroot=serverip:path (e.g. 192.168.67.1:/opt/ltsp/amd64) > > Well, even though the variables refer to it as a "path", nbd does not (and > will > not ever) *require* the use of something that looks like a path.
Understood. Several debian releases ago, we didn't use a path-looking
export in LTSP; once we added code to use ROOTPATH from dhcp to the nbd
client initramfs script, it became much easier to support both NBD and
NFS rootfs on the same network with a menu.
>> 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/}
>
> Right.
>
> Unfortunately, the code as it existed previously *required* the
> existence of a / in the export name. Since that's not how NBD works, I
> think the request in #840612 was reasonable, and removed the stripping
> of that bit of it.
I don't suggest to simply revert it; that bug is/was definitely
valid. I'm just trying to figure out how to keep that correct behavior
without breaking the configuration LTSP has been using for the last 2 or
so Debian releases.
> I can see a few possible solutions to the problem:
>
> - We change the definition of the ip:port/exportname syntax so that the
> / is only stripped if an IP address and/or a port was specified, too;
> i.e., if you don't specify anything before a /, then it is assumed
> that the / is part of the export name, rather than it being a
> separator.
That sounds workable.
I think an additional case statement match roughly like so might work:
case nbdroot in
^/*|*:/*) nbdpath= ...
nbdsrv= ... ;;
esac
As that handles path only, and serverip with path (and no port).
I'm not sure if serverip + port + path works with the original ipv4
match. Or for that matter, if the ipv6 match works without specifying a
port...
> Not sure whether that fixes the issue for LTSP (in fact,
> not even sure whether it's valid currently to specify only the
> exportname, but ignoring that)
Well, it contains this code to handle the path-only case:
# If host is omitted, use ROOTSERVER from DHCP.
case "$nbdsrv" in
''|dhcp)
nbdsrv=$ROOTSERVER
;;
esac
Worked a bit to convince you to include all these features, so will keep
working to keep them working for our use case. :)
> - I could be convinced of a transitional fix that would be supported
> during Stretch (possibly Buster too, but certainly not later) wherein
> if a leading / isn't found in an exportname and the export couldn't be
> found either, we try adding a / and try connecting again. This would
> be a somewhat more ugly solution, but it would work.
Yeah, not too fond of that approach...
Thanks for the responses, will try to come up with a patch if you don't
beat me to it! :)
live well,
vagrant
signature.asc
Description: PGP signature
