| gabriel rosenkoetter on Wed, 20 Nov 2002 22:10:05 -0500 |
|
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. Look at the --daemon option in rsync(1) and all of rsyncd.conf(5). > I was also thinking of having another login just for a remote > backup but i'd have to give that a uid of 0 and that doesnt > really help minimize the problem... Why is that only root can read these files? (Not saying it's not valid, but it's worth questioning...) > 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). -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpBSlNbqAxqB.pgp
|
|