From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMGCf-0000JQ-NU for qemu-devel@nongnu.org; Thu, 21 Jan 2016 09:27:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMGCe-0003tt-BV for qemu-devel@nongnu.org; Thu, 21 Jan 2016 09:27:13 -0500 Date: Thu, 21 Jan 2016 14:26:54 +0000 From: "Daniel P. Berrange" Message-ID: <20160121142654.GO19835@redhat.com> References: <1453208963-16834-1-git-send-email-berrange@redhat.com> <1453208963-16834-10-git-send-email-berrange@redhat.com> <569E60E8.2040001@redhat.com> <20160119164443.GP26662@redhat.com> <56A0B34B.6060103@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56A0B34B.6060103@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org 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 :|