[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Easier use, authentication



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". 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), so while this can indeed be done, it does
make that program rather complicate: this creation and deletion of
files would need either shell code to be sent over ssh that does it,
or a wrapper be present on the server that translates between the
command line api I'm asking for and the configuration files, and when
reaching that latter point why not just build it into the nbd-server
itself?

> 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? In case of error, just retry with the next free
device?

> 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.

Christian.



Reply to: