On Tue, Apr 16, 2002 at 01:04:09PM +1000, Martin Pool wrote: > I haven't had a chance to test this recently, but Dave just reminded > me that it ought to merge soon and I agree. > > I was thinking about this the other day in the context of the > Bitkeeper "bk url" manpage (if Colin will forgive me :-). > > http://www.bitkeeper.com/manpages/bk-url-1.html > > They have basically the same problem of wanting to do access locally, > over a native protocol, and over ssh. I'm not suggesting we adopt > their scheme. > > It seems like people might want to set up accounts (called say > "backup") whose login shell is set to 'rsync --daemon'. I'd like that > to work if it can. It kind of overlaps with command-limited ssh keys, > but I think some admins would feel more comfortable with the former.
That's easily done without modifying rsync any more than JD's current patch. A login shell has to be a program or #! script, and it can easily be written to ignore the args and always do rsync --daemon, or to print an error and exit if the args are not '-c "rsync --daemon"' which is the syntax I've observed being passed to restricted login shells that I've written. > SSH2 also has a "subsystem" configuration option that seems to let it > provide tunnelled servers directly. I wonder if we can integrate with > that? I don't know much about it, but from what I can see I don't think there's much value in the SSH subsystem stuff, especially not for rsync. I think it's probably only useful for services that are standard in the SSH package and not for add-on things like an rsync server. > I'm not sure if I said so before, but I'm not completely comfortable > with the -e option invoking the rsync-over-ssh behaviour. I can see > how from one point of view this is quite elegant, but I'm concerned > that it overloads the behaviour of the option in a confusing way: it > would change it from merely modifying a mode selected by a > single-colon url, to choosing a new mode of behaviour. (Imagine, for > example, somebody who has a shell alias that sets up rsync -e.) If somebody has an alias set to rsync -e then they're currently getting big warnings whenever they use "::" or "rsync://". They should instead be setting $RSYNC_RSH. > A clearer way to put that is that at the moment we have six modes of > operation; this will make eight (counting upload and download > separately). I think it's fair to insert rsync-over-ssh at that > level. It is already a source of confusion and we have to be careful > not to make it worse. > > All of the others are distinguished by whether the source and > destination contain colons, etc. I think we ought to try to retain > that convention if possible. I see your point, but what syntax would you suggest? JD's original suggestion was to use three colons instead of two. Uggh! Perhaps a URL-based selection similar to what Bitkeeper uses could be made to be OK, but I can't envision it. We need some way to specify what the transport program is, be it rsh or ssh or remsh or whatever. I think JD's current implementation is the best we're going to do to reduce confusion. > Thanks again for the patch. These issues should be pretty easy to > decide, and I think it will be a large improvement in utility. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html