rsync server over SSH

[Dave Dykstra]

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