All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested
Date: Thu, 21 Jan 2016 11:30:35 +0100	[thread overview]
Message-ID: <56A0B34B.6060103@redhat.com> (raw)
In-Reply-To: <20160119164443.GP26662@redhat.com>



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.

Paolo

  reply	other threads:[~2016-01-21 10:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 13:09 [Qemu-devel] [PATCH v3 00/13] Implement TLS support to QEMU NBD server & client Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 01/13] nbd: convert block client to use I/O channels for connection setup Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 02/13] nbd: convert qemu-nbd server " Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 03/13] nbd: convert blockdev NBD " Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 04/13] nbd: convert to using I/O channels for actual socket I/O Daniel P. Berrange
2016-01-19 16:08   ` Paolo Bonzini
2016-01-19 16:52     ` Daniel P. Berrange
2016-01-19 18:00       ` Paolo Bonzini
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 05/13] nbd: invert client logic for negotiating protocol version Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 06/13] nbd: make server compliant with fixed newstyle spec Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 07/13] nbd: make client request fixed new style if advertized Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 08/13] nbd: allow setting of an export name for qemu-nbd server Daniel P. Berrange
2016-01-19 16:12   ` Paolo Bonzini
2016-01-19 16:48     ` Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested Daniel P. Berrange
2016-01-19 16:14   ` Paolo Bonzini
2016-01-19 16:44     ` Daniel P. Berrange
2016-01-21 10:30       ` Paolo Bonzini [this message]
2016-01-21 14:26         ` Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 10/13] nbd: implement TLS support in the protocol negotiation Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 11/13] nbd: enable use of TLS with NBD block driver Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 12/13] nbd: enable use of TLS with qemu-nbd server Daniel P. Berrange
2016-01-19 13:09 ` [Qemu-devel] [PATCH v3 13/13] nbd: enable use of TLS with nbd-server-start command Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A0B34B.6060103@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.