search for: exportnames

When “nbdkit ... --run 'nbdinfo ...' > out” is expected to fail, we cannot be sure of the content of the "out" file. In particular nbdinfo produces its output incrementally, so in JSON mode there's usually a stray "{" in the output, and in non-JSON mode it usually prints the "protocol: " line. Thus it's not correct to test for the output file

...afe by updating the extent list when the filter sees writes and trims +nbdkit-exportname-fitler: + +* find a way to call the plugin's .list_exports during .open, so that + we can enforce exportname-strict=true without command line redundancy + +* add a mode for passing in a file containing exportnames in the same + manner accepted by the sh/eval plugins, rather than one name (and no + description) per config parameter + Filters for security -------------------- -- 2.28.0

...> filter sees writes and trims > > +nbdkit-exportname-fitler: > + > +* find a way to call the plugin's .list_exports during .open, so that > + we can enforce exportname-strict=true without command line redundancy > + > +* add a mode for passing in a file containing exportnames in the same > + manner accepted by the sh/eval plugins, rather than one name (and no > + description) per config parameter > + > Filters for security > -------------------- All looks pretty sensible to me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.re...

To allow filters to modify the export name as it passes through the layers this commit makes several changes: The filter .open callback now takes an extra parameter, the export name. This is always non-NULL (for oldstyle it is ""). This string has a short lifetime and filters that need to hang on to it must take a copy. The filter must pass the exportname parameter down to the next

When using ext2file=exportname to pick the file to server from the client's export name, we do not want to leak the underlying plugin's export list. While touching this, take advantage of string lifetimes via nbdkit_strdup_intern and similar for less cleanup bookkeeping. Note that we don't actually implement a full .list_exports; doing that with NBD_OPT_LIST is likely prohibitive

Here's changes to the file plugin (which I'm happy with) and a new exportname filter (which is still at RFC stage; I need to finish implementing strict mode in .open, and add tests). I also discovered that we really want .list_exports and .open to know when they are used on plaintext vs. tls clients for --tls=on, and we may want to split out a new .default_export callback rather than

Now that we can differentiate content based on export name, we also need to be able to differentiate content for a --tls=on server, since TLS is optional according to whether the client has authenticated. For internal code and filters, this means adding a new parameter; the sh plugin can do likewise. For plugins, we can't add a parameter until the V3 protocol, so in the meantime, we add

On 7/21/20 3:47 PM, Richard W.M. Jones wrote: > To allow filters to modify the export name as it passes through the > layers this commit makes several changes: > > The filter .open callback now takes an extra parameter, the export > name. This is always non-NULL (for oldstyle it is ""). This string > has a short lifetime and filters that need to hang on to it must

...;. This option implies I<--foreground>. -=item B<-e> EXPORTNAME - -=item B<--export> EXPORTNAME - -=item B<--export-name> EXPORTNAME - -=item B<--exportname> EXPORTNAME - -Set the exportname. - -If not set, exportname C<""> (empty string) is used. Exportnames are -not allowed with the oldstyle protocol. - =item B<-f> =item B<--foreground> diff --git a/docs/synopsis.txt b/docs/synopsis.txt index 07b9dcff..caf49922 100644 --- a/docs/synopsis.txt +++ b/docs/synopsis.txt @@ -1,5 +1,4 @@ -nbdkit [-D|--debug PLUGIN|FILTER|nbdkit.FLAG=N] -...

Applies on top of my pending series for the exportname filter, addressing one of the todo's in that cover letter. Eric Blake (2): filters: Add .export_description wrappers ext2: Supply .list_exports and .default_export filters/ext2/nbdkit-ext2-filter.pod | 3 +- tests/Makefile.am | 16 +++- filters/ext2/ext2.c | 125 +++++++++++++++++++---------

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

Now that a filter can open a backend as many times as it wants, there's no longer a technical reason we can't retry .open. However, adding retry logic here does mean we have to weaken an assert in the server backend code, since prepare can now be reached more than once. Test coverage will be added in a separate patch, so that it becomes easy to swap patch order and see that the test

...) != 0) { > - putc ('/', fp); > - uri_quote (exportname, fp); > - } > - fprintf (fp, "\\?socket="); > + fprintf (fp, "nbd+unix://\\?socket="); > uri_quote (unixsocket, fp); > } Hmm. When we do allow plugins to advertise exportnames, we'll probably want a way to specify the right exportname (suppose a plugin advertises both "a" and "b" and serves different content accordingly, --run then has to know which one to go with, rather than assuming "" will work). But I don't mind that being f...

On Tue, Jul 21, 2020 at 07:41:21PM -0500, Eric Blake wrote: > On 7/21/20 3:47 PM, Richard W.M. Jones wrote: > >+++ b/server/plugins.c > >@@ -278,12 +278,30 @@ plugin_preconnect (struct backend *b, int readonly) > > } > > static void * > >-plugin_open (struct backend *b, int readonly) > >+plugin_open (struct backend *b, int readonly, const char *exportname)

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update

While we are unlikely to change our decision that -e should not control our response to NBD_OPT_LIST (because we intend to add a new callback .extents_list for that), it turns out that it is a lot easier to write: nbdkit -U - -e foo info --run 'nbdsh -u "$uri" -c "print(h.pread(3, 0))"' than it is to write the equivalent: nbdkit -U - info --run 'nbdsh -u

On Tuesday 11 March 2014 23:13:46 Richard W.M. Jones wrote: > diff --git a/src/drives.c b/src/drives.c > index 2c85b52..68e37f7 100644 > --- a/src/drives.c > +++ b/src/drives.c > @@ -115,7 +115,8 @@ static struct drive * > create_drive_file (guestfs_h *g, const char *path, > bool readonly, const char *format, > const char *iface,

Implementing .default_export with its 'const char *' return is tricky in the sh plugin: we must return dynamic memory, but must avoid a use-after-free. And we don't want to change the return type of .default_export to 'char *', because that would make our choice of malloc()/free() part of the API, preventing either nbdkit or a plugin from experimenting with an alternate

Implementing .default_export with its 'const char *' return is tricky in the sh plugin: we must return dynamic memory, but must avoid a use-after-free. And we don't want to change the return type of .default_export to 'char *', because that would make our choice of malloc()/free() part of the API, preventing either nbdkit or a plugin from experimenting with an alternate

Note this patch requires a non-upstream qemu patch that I've been experimenting with. See qemu-devel list. Rich.