[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v3 09/13] nbd: pick first exported volume if no
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-block] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested |
Date: |
Thu, 21 Jan 2016 14:26:54 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jan 21, 2016 at 11:30:35AM +0100, Paolo Bonzini wrote:
>
>
> On 19/01/2016 17:44, Daniel P. Berrange wrote:
> >> > As a first reaction, I would really avoid magic unless the server
> >> > provides a single exports. But even in that case, I would prefer to
> >> > have some synchronization between the server and client command-line.
> >> >
> >> > Is an empty NBD_OPT_EXPORT_NAME valid? What about using new-style
> >> > negotiation with empty NBD_OPT_EXPORT_NAME if TLS is requested?
> > The main goal here is to ensure the NBD client gets a decent error
> > message if it tries to connect without TLS. Even if we are using
> > the fixed new style protocol, the client code will send
> > NBD_OPT_EXPORT_NAME as the first thing it does. Thanks to a bit of
> > crazyness is the NBD protocol spec, the server is unable to reply
> > with an error message to NBD_OPT_EXPORT_NAME.
> >
> > So if the client connected to a server reqiuring TLS and does not
> > request TLS enablement, the server will have no choice but to just
> > close the connection with no error. I think this will be pretty
> > nasty for users trying to debug problems with TLS.
>
> That's fine. I'm just not sold on using the first answer from
> NBD_OPT_LIST as the argument to the subsequent NBD_OPT_EXPORT_NAME.
>
> In other words, I would prefer to do the following for no export name:
>
> 1) server, no TLS: accept either old-style negotiation or new-style
> negotation with an empty ("") export name; NBD_OPT_LIST returns a single
> export name, "".
>
> 2) server, TLS: accept only new-style negotiation with an empty ("")
> export name; NBD_OPT_LIST returns a single export name, "".
>
> 3) client, no TLS: use old-style negotiation; if the server rejects
> old-style negotiation, mention the possibility that the server requires TLS
>
> 4) client, TLS: use new-style negotiation with an empty ("") export name.
>
> The only interesting case for named exports is client, no TLS. Then you
> can just send a dummy NBD_OPT_LIST unconditionally, and use the result
> to provide a good error message if the server requires TLS. If it makes
> the code simpler to use NBD_OPT_LIST always, even if the client supports
> TLS (making the sequence NBD_OPT_STARTTLS, NBD_OPT_LIST,
> NBD_OPT_EXPOR_NAME), then that's fine too.
Ok, I'll have a go at this approach
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-block] [PATCH v3 11/13] nbd: enable use of TLS with NBD block driver, Daniel P. Berrange, 2016/01/19
[Qemu-block] [PATCH v3 13/13] nbd: enable use of TLS with nbd-server-start command, Daniel P. Berrange, 2016/01/19
[Qemu-block] [PATCH v3 12/13] nbd: enable use of TLS with qemu-nbd server, Daniel P. Berrange, 2016/01/19