Re: [Nbd] Easier use, authentication

[Wouter Verhelst <w@...112...>]

On Mon, Sep 26, 2011 at 12:11:44PM -0400, Christian Jaeger wrote:
> 2011/9/26 Wouter Verhelst <w@...112...>:
> > However, I fail to see why this would be useful; what's so wrong with a
> > configuration file?
> 
> As I've described, the way I want to use it is to just do one call of
> a program (script) on the client computer, like
> "give-me-this-path-as-an-ndb-device-path myserver:/foo/bar.img".

Well, you're still going to need some sort of configuration to be able
to do that -- otherwise any person could mount any random file on your
server, which is not a terribly bright idea.

As I've said, you can already use nbd-server in command-line mode, which
does not require a configuration file (just specify '-C /dev/null' to
have it not use the default config file, if you want to try that). This
mode is somewhat limited, but that can't be helped.

But it's a server, and therefore by definition it's going to be doing
things for clients. You can't have a server do any random thing which
any random client asks you about, that's a terribly bad idea. So there
needs to be some sort of configuration limiting what the sysadmin wants
it to do or not to do. There's no way around that.

> If a configuration file on the server is needed for this, this program
> would have to create it on the fly then delete it, which is of course
> doable, but IIRC currently it even needs multiple files (at least one
> with the allowed IPs, too),

No, that's not true; the authorization file is fully optional.

[...]
> > Yeah, that bit is a bit painful currently. A few years back I suggested
> > to Paul that he implement some scheme whereby there would be an
> > 'nbd master' device node on which you could ask for a /dev/nbdX node to
> > be allocated, but I don't think anything has come from it.
> >
> > I could imagine a scheme whereby nbd-client checks for
> > /sys/block/nbdX/pid, but that's going to be racy so would need some
> > locking; this could get pretty ugly.
> 
> What happens if the client simply tries a device (after first checking
> in /sys/block/... whether it should be free) without locking, wouldn't
> it get an error?

Good point. Not sure, to be honest.

> In case of error, just retry with the next free device?

That might work, but it's still rather racy.

> > Indeed. I don't think that [hashing w/o encryption] would buy us much.
> 
> I'm not decided yet, since I haven't got real numbers yet. If the
> hashing costs are low enough to run a client per core (at least on a
> little faster CPU than my Atom) and not slow down remote access to a
> fast hard drive (and full encryption is 3 times slower or worse), that
> would seem quite interesting to me.

Mmm. Yes, well, patches would probably be welcome, but I won't implement
that myself.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a