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

[Brad H. <bh...@bi...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 11 Jun 2003 11:25 am, Martin Pool wrote:
> That could be a pretty nice thing. =A0We 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=
=20
mean a software implementation, but a user / admin configuration. Think=20
Standard Operating Procedures.
The other thing that would be nice would be a search capability - "find me =
the=20
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=
=20
passwords. I admire clever attacks as much as the next guy, but the next gu=
y=20
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 purp=
ose=20
(not the efficiency).  The ability to do stuff like:
[rsyncftp]
        path =3D /var/ftp/pub/rsync
        comment =3D rsync ftp area (approx 6 MB)
By "fine grained", some basic ACL support would be nice. Support for=20
classes/groups of users (ideally with inheritance) is useful.

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

4. Well delimited - various RFCs do protcol design differently. Here's an=20
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? =A0How can that happen on a
> TCP channel?
Why run this _only_ over TCP? Obviously you don't want to re-invent TCP/IP=
=20
error handling, but the protocol shouldn't rely on such a system. File=20
transfer can potentially run connectionless.

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

iD8DBQE+6GzxW6pHgIdAuOMRAm6VAKCeeVF1XApyQkr1RpIDU/ic5Y2ZiwCcDeKf
mFl+RNmJT3DE+GhHjuNTl3s=3D
=3DSAHh
=2D----END PGP SIGNATURE-----