Re: [PATCH for discussion] doc: Define a standard URI syntax for NBD URIs.
On Sun, May 26, 2019 at 10:24:11AM +0100, Richard W.M. Jones wrote:
> On Sun, May 26, 2019 at 10:00:18AM +0100, Richard W.M. Jones wrote:
> > I intended to write a cover letter, got distracted while sending it
> > and forgot ...
> >
> > Anyway I was going to say:
> >
> > - There's no way to specify abstract Unix domain sockets. Should
> > there be? I'm not aware of any server that supports them. Luckily
> > the common approach of using `@` at the beginning should work:
> > https://unix.stackexchange.com/questions/206386/what-does-the-symbol-denote-in-the-beginning-of-a-unix-domain-socket-path-in-l
> >
> > - As Wouter already picked up in his review, should we allow a
> > default Unix domain socket? The corollary to this is: Should we
> > make the authority mandatory for TCP/IP sockets? Are there
> > sensible defaults for the authority (localhost:10809 probably).
> >
> > - I notice that proto.md has a text symlink (proto.txt). Would we
> > need one for url.txt -> url.md?
>
> A few more things:
>
> - I wrote a libnbd implementation of NBD URIs last night:
> https://github.com/libguestfs/libnbd/commit/d2dfefcefdf64864acae7a75c30d3f54e9a63ea6
> Of course thisis based off the draft spec, but I can amend this
> implementation as we work towards a final spec. One annoying thing
> is that libxml2 provides no support for parsing the query
> parameters, and doing it by hand in C is a PITA ...
Yeah, I was actually hoping there might be a "liburi" or some such to leech URI
parsing off of...
> - libnbd supports `nbds+unix` (ie. require TLS over a Unix domain
> socket). We use this for testing, and of course it's "useless" for
> real life, which is why I omitted it from the spec. (QEMU doesn't
> support TLS over Unix domain sockets; nbd-server looks like it
> could support it, but I didn't test it).
I haven't tested it myself either, TBH, but I suspect it might magically
work. I agree it doesn't make much sense other than for test suites etc.
> - On the subject of requiring TLS, I made `nbds` mean that TLS is
> required, while `nbd` means that TLS can be used opportunistically
> but is not required. Not sure what people think about that.
> There's no "definitely don't use TLS" setting, but given we have
> observed a 10x slowdown when TLS is enabled on a Unix domain socket
> between libnbd & nbdkit[*] maybe there should be.
Yeah, I think that's perfectly reasonable. I liked that.
"nbd://" means you're allowed to use TLS if it's available, but won't
break if not. "nbds://" means you will.
Why would you ever forbid using TLS in a URL? That seems silly. There
are implementation details where using TLS is not a good idea
(i.e., kernel NBD), but I think those are the exception rather than the
rule, and we shouldn't build toward them. Besides, there is now an
in-kernel TLS implementation that I've been planning to add support for
to nbd-client[1], so that's also helpful, and once that's done I would
probably lean towards making TLS the default in nbd-server, too.
[1] that does require support from a userland TLS implementation though,
which OpenSSL has but GnuTLS, TTBOMK, does not. I'd probably have to
add that before I can look at adding kernel TLS support to
nbd-client...
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: