On Fri, Sep 23, 2011 at 04:34:37PM -0400, Christian Jaeger wrote: > Hi > > I'm often trying to loop-mount (actually with dmcrypt) remote > (encrypted) filesystem image files. I often do this spontaneously, and > I often already have a mount of the remote filesystem over sshfs, so I > can access these image files over the sshfs mount and my "mounte" tool > automatically takes care of the dmcrypt, thus it's a 1 step process > for me to mount such image files over sshfs. But sshfs is slow > (needless additional encryption) and sometimes not working reliably. > NBD works reliably, but is a pain to setup: I need to configure and > start a server process, start a client process with correct > configuration, then choose the right nbd block file to mount. I'd like > to look into improving that.
Can you explain that a bit? I don't see how you could make that easier, to be honest, but ideas are always welcome. > Also, while at it, I'd hope to improve > the security by offering some kind of challenge-response > authentication. (I've written about the same thing in more length > here: http://lists.debian.org/debian-user/2011/09/msg01453.html) I've been thinking about that too, but it hasn't really happened yet. There is an 'auth' branch in git which contains a proof-of-concept, but it probably needs forward-porting and testing. The reason it hasn't happened is, I guess, that I've let the perfect be the enemy of the good; TCP hijacking isn't exactly difficult, so I wasn't sure authentication on the TCP session was a very good idea. Also, adding authentication requires me to think the security of the whole thing through very very well, which I was looking a bit up to. But then, I don't think all that is a very good reason not to have any decent authentication. If you're willing to look into that, patches are certainly welcome. > If I succeed implementing that, NBD should be perfect to me, except > that it would be nice if the client could try to reconnect if the > connection fails. That's what the -persist option was meant for, but I might've made some mistakes; I've seen reports from people claiming that it didn't work. I need to look into that in some more detail, but haven't had the time. > Ah, and it would be nice to somehow ensure that an image file is only > served at most once for safety :). That could make sense in some situations, yes, but definitely not all. Most importantly, though, it's very hard to implement right, the way nbd-server is currently implemented. > But I guess NBD is still the right way to look into, since the > alternative ENBD isn't included in the mainstream kernel? >From what I've seen, ENBD isn't very active anymore these days, either. But I could be mistaken. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
