| Jeff Abrahamson on Wed, 20 Nov 2002 23:00:07 -0500 |
|
On Wed, Nov 20, 2002 at 09:51:11PM -0500, gabriel rosenkoetter wrote:
> On Wed, Nov 20, 2002 at 06:56:46PM -0500, epike@isinet.com wrote:
> > thanks...i was wondering what would be running on the server end
> > didnt realize it was also rsync (i'd have thought there was
> > a rsyncd or something more complicated on the other end).
>
> rsync has a daemon mode. I thought it involved doing its own layer
> 7 protocol, precluding use of ssh as the transport, but looking at
> the man page again, I may be mistaken.
Everything gets confusing when one tries to assign things to layers of
the OSI model. Layer seven is application layer, and a strong argument
could be made that ssh establishes a session layer (layer five) and
that rsync is talking presentation layer (layer six).
The best advice I ever heard about the OSI stack is to remember that
no one has implemented much of anything real in it, and that tcp/ip
was so successful in part because they ignored the OSI model. Your
opinions may vary.
More practically, rsync implements a network protocol that says things
like the following messages:
"I want a signature for file X"
"Here's a signature for file X"
"Move the block at offset Y in file X to offset Z"
"Here's a block, put it at offset Y in file X"
"Finished with file X"
It can say these things over an ssh connection as well as over a
telnet connection. What's the difference? That's the session layer, if
you want to talk OSI. But it's easier to think of it as the difference
between having what goes into your sockets encrypted or not.
> Look at the --daemon option in rsync(1) and all of rsyncd.conf(5).
Where you'll also find you can set up an rsync server. You can still
use ssh. (Use port forwarding as a non-privileged user and have the
rsync server only listen to connections from localhost.) This might
solve the problem, since you can connect as an unprivileged user, but
the rsync server can be running as root.
(Is the issue that files are owned by different users? How many users
are there? Could you just have an rsync process by each user? That
doesn't scale, but if the number of users won't grow much, it might be
easier.)
> > maybe by diskettes, to be removed after booting. I'll
> > also make sure the backup machines are behind a firewall...
>
> Presuming you trust everyone with physical access to the machine,
> you *should* be okay trusting Unix permissions for the protection
> of the key files. (cs.swarthmore.edu used--and probably still uses,
> I'm not a sysadmin there anymore--a hack of mine to replace NIS
> with rsync. It doesn't scale very well, but it works just fine in
> a limited environment. I still want to get back to cleaning that
> system up a bit.)
>
> The caveat to this is that if anyone gets root on a system with
> keys, you lose. So don't run dangerous daemons, or run them non-
> root in a chroot(8) environment (many daemons, like BIND 9, Postfix,
> and INN have built-in provisions for this).
If you can use diskettes at boot, I should think you could also use
keys with pass phrases. I don't follow what you want to do with the
diskettes, though.
--
Jeff
Jeff Abrahamson <http://www.purple.com/jeff/>
Attachment:
pgpIftg5km4nE.pgp
|
|