similar to: [libnbd PATCH] api: Add nbd_get_structured_replies_negotiated

Similar to the recent --mask-handshake command line added to nbdkit to test client fallbacks to crippled servers, it can be worth testing server fallbacks to crippled clients. And just as we have exposed whether the client will request structured replies, we can also expose whether the client will understand various handshake flags from the NBD protocol. Of course, we default to supporting all

I'm pleased to announce the releases of libnbd 1.2 and nbdkit 1.16. These are a high performance Network Block Device (NBD) client library and server. Key features of libnbd: * Synchronous API for ease of use. * Asynchronous API for writing non-blocking, multithreaded clients. You can mix both APIs freely. * High performance. * Minimal dependencies for the basic library. *

We want to default to requesting structured replies, whether or not that request will be honored (it's essential for efficient sparse file reads and the DF flag for structured pread, as well as for meta context support even if we do not request a default meta context). However, for integration testing, it can be nice to easily request a client that does not request structured replies. We can

It is finally time to introduce our first negotiating option command. With this change, we can now enter NEWSTYLE.START more than once; as such, it needs to know whether it is the first entry (proceed with gflags/cflags, TLS, and structured reply) or a later entry (all nbd_opt_* will cause an IssueCommand event to kick the state machine out of NEGOTIATING, at which point we want to jump to the

When LIBNBD_TLS_ALLOW is used we don't have a way to find out if TLS was really negotiated. This adds a flag and a way to read it back. Unfortunately there is no test yet, because LIBNBD_TLS_ALLOW is not tested -- it really should be but requires quite a complicated set of tests because ideally we'd like to find out whether it falls back correctly for all supported servers. --- TODO

Right now, libnbd has refused to issue a command not advertised as supported by a server, mainly because the NBD protocol does not guarantee what the server will do, and libnbd would rather stay in sync with the server than drop the connection. However, for integration purposes, it can be handy to coerce libnbd into sending something to see how the server will react (whether it be an extension

Document and make it easier for applications to determine which bitmask values were supported at compile time. Also, generating bitmask values in hex tends to be more legible than in decimal, as it makes it obvious that the values are intended for bitwise operations. And it doesn't hurt that this reduces churn in some of the tests if new bits are added. --- docs/libnbd.pod

This is the bare minimum needed to allow the user to take control over the rest of option negotiating. This patch adds several new API: nbd_set_opt_mode() - called during Created to enable the new mode nbd_get_opt_mode() - query whether opt mode is enabled nbd_opt_go() - used in Negotiating state to attempt to use export nbd_opt_abort() - used in Negotiating state to skip Connected state

On 9/17/19 5:02 AM, Richard W.M. Jones wrote: > This commit adds a new API which can be used from the connected to > state to read back which NBD protocol (eg. oldstyle, newstyle-fixed) > we are using. Somewhat of an overlap with my get_handshake_flags (as newstyle-fixed corresponds to whether handshake_flags includes the FIXED_NEWSTYLE flag), but I don't see the redundancy as an

This commit adds a new API which can be used from the connected to state to read back which NBD protocol (eg. oldstyle, newstyle-fixed) we are using. It was helpful to add a new state in newstyle negotiation (%NEWSTYLE.FINISHED) so we can route all successful option negotiations through a single path before moving to the %READY state, allowing us to set h->protocol in one place. ---

On 9/17/19 3:32 AM, Richard W.M. Jones wrote: > This commit documents the limits on export name, encoding, etc. > --- > generator/generator | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > ACK. > diff --git a/generator/generator b/generator/generator > index a72f36c..87a8cdf 100755 > --- a/generator/generator > +++ b/generator/generator > @@

An upcoming commit will add the ability to query which meta contexts a server is advertising; but first we need to be able to present a different list of meta context requests in response to what we learn from the server. Add APIs for reviewing which requests have already been registered, as well as a way to reset the list of requests. This adds some testsuite coverage; and more will appear with

Well, I'm not quite done (I still want to get nbdinfo to work on a single nbd connection for all cases when reading the heads of the file is not required), but I'm happy with patches 1-11, and 12-13 show where I'm headed for getting NBD_OPT_INFO to work. Posting now to see if some of the earlier patches are ready to commit while I continue working on the latter half. Eric Blake (13):

New APIs are added which let you enable or disable features of NBD URIs, mainly for security reasons. tls-psk-file is *disabled* by default for obvious security reasons. All other features are enabled by default. --- generator/generator | 127 +++++++++++++++++++++++++++++++++++++++++++- lib/handle.c | 26 +++++++++ lib/internal.h | 5 ++ lib/uri.c | 31 +++++++++--

This adds new APIs for running a local NBD server and connecting to it using systemd socket activation (instead of stdin/stdout). This includes interop tests against nbdkit and qemu-nbd which I believe are the only NBD servers supporting socket activation. (If we find others then we can add more interop tests in future.) The upstream spec for systemd socket activation is here:

The next strict knob: allow the user to pass unknown flags across the wire (this is different than passing a known flag at the wrong time). It is interesting to note that NBD only permits 16 bits of flags, but we have a signature that takes uint32_t; if we wanted, we could pack libnbd-specific flags in the upper bits that the NBD protocol would never see. --- generator/API.ml | 46

Test both the TLS enabled and fallback paths. nbd-server doesn't appear to support TLS at all, and qemu-nbd is known not to allow fallback to unencrypted, and therefore it only makes sense to test nbdkit at the moment. --- .gitignore | 4 ++++ TODO | 3 --- interop/Makefile.am | 54 +++++++++++++++++++++++++++++++++++++++++++++ interop/interop.c | 30

From: "Richard W.M. Jones" <rjones at redhat.com> To allow us to name the socket passed down to the NBD server when calling nbd_connect_systemd_socket_activation(3), we need to add the field to the handle and add access functions. [Laszlo's note: originally posted by Rich at <https://listman.redhat.com/archives/libguestfs/2023-January/030557.html>. I've renamed

From: "Richard W.M. Jones" <rjones at redhat.com> To allow us to name the socket passed down to the NBD server when calling nbd_connect_systemd_socket_activation(3), we need to add the field to the handle and add access functions. [Laszlo's notes: - Originally posted by Rich at <https://listman.redhat.com/archives/libguestfs/2023-January/030557.html> (Message-Id:

This continues the changes for adding NBD_OPT_LIST support. Now, instead of libnbd malloc'ing storage itself, the user passes a callback that can handle name/description pairs however it likes, and we get rid of the artificial cap at 10000 exports. However, the user will probably end up malloc'ing a list themselves, as we can't call nbd_set_export_name, or even request NBD_OPT_INFO