[librsync-devel] Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 11 Jun 2003 11:25 am, Martin Pool wrote:
> That could be a pretty nice thing.  We use little rsync shares on
> workstations here for sharing files, and I know some people do the
> same with FTP.
>
> What aside from SLP would make this more useful?
A standardised way of describing the share would be good. By this, I don't 
mean a software implementation, but a user / admin configuration. Think 
Standard Operating Procedures.
The other thing that would be nice would be a search capability - "find me the 
shares with a copy of rsync-2.5.6.tar.bz2"

> > Go superlifter! For what it is worth, the things I identified during the
> > abortive kioslave / SLPv2 share development:
> > 1. More secure than FTP.
> > 2. Easy to label shares/directories and provide fine grained access
> > control, if desired.
> > 3. Client side library that doesn't require hellish text parsing, or at
> > least hides it from you.
> > 4. Well delimited packets, so you can tell when one has been
> > dropped.
>
> Can you give more detail on those?
1.  I'm thinking about something that, as a minimum, doesn't do plain text 
passwords. I admire clever attacks as much as the next guy, but the next guy 
doesn't want some kewl hax0r with a copy of tcpdump uploading warez either.
Probably SASL is worth a look.

2. The labelling is the main thing that attracted me to rsync for this purpose 
(not the efficiency).  The ability to do stuff like:
[rsyncftp]
        path = /var/ftp/pub/rsync
        comment = rsync ftp area (approx 6 MB)
By "fine grained", some basic ACL support would be nice. Support for 
classes/groups of users (ideally with inheritance) is useful.

3. Client side library is (hopefully) pretty obvious. Note that this needs to 
be well defined (ideally in a companion RFC to the RFC that describes the 
wire-protocol), to allow for multiple implementations. Using rsync(1) meant 
trying to guess what the contents of a message meant (was this motd, was it a 
directory list, is it a file..), and converting the text of the directory 
listing to some bitmasks. 

4. Well delimited - various RFCs do protcol design differently. Here's an 
example from RFC2608:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Version    |  Function-ID  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length, contd.|O|F|R|       reserved          |Next Ext Offset|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Extension Offset, contd.|              XID              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Language Tag Length      |         Language Tag          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



> What do you mean by packets being dropped?  How can that happen on a
> TCP channel?
Why run this _only_ over TCP? Obviously you don't want to re-invent TCP/IP 
error handling, but the protocol shouldn't rely on such a system. File 
transfer can potentially run connectionless.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+6GzxW6pHgIdAuOMRAm6VAKCeeVF1XApyQkr1RpIDU/ic5Y2ZiwCcDeKf
mFl+RNmJT3DE+GhHjuNTl3s=
=SAHh
-----END PGP SIGNATURE-----