-----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-----
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
