Multiple PC syncronization

On Sat, 18 Sep 2004 21:21:08 GMT, Travis Casey <efindel@earthlink.net> wrote:
>
> - second, I'd use a push model. This gives a few things:

I would tend to advocate a pull model for reasons outlined below.
Note that I'm not saying that Travis is wrong, just that choosing
between push and pull has many factors to consider and that in my
opinion, pulling is often better.

>
> - the 'master' has to have access to the 'duplicates', rather than
> vice-versa. Since the 'duplicates' are the ones the students are
> using, having them initiate the rsync gives a greater chance that
> a student could muck with it.

The drawback with pushing is that the master needs write access to all
of the duplicates. If you pull, the duplicates only require read
permission. You have to look at how an attacker can leverage the
compromise of one machine to extend it to the rest of the cluster.

Which is more of a risk: giving N clients read access to a master, or
having a master have write access to N clients? I can think of
scenarios where either is worse than the other. In my opinion, write
access is usually more dangerous, but only the OP can decide for
his/her own situation.

> - the possibility of greater control over when things happen. If you're
> in the middle of doing a big update (like, say, upgrading the OS) and
> you don't want the rsync to happen during it, you only have one place
> to 'switch things off'. If it's pull, there are eight places it has to
> be done. (Or you have to disable rsync or ssh access for those eight
> machines somehow.) On the flip side of this, if you've just done a
> big upgrade, it's likely to be less trouble to 'manually' push to
> everyone else than to 'manually' fire off a bunch of pulls.
>
> - As a second aspect of the former point, it's easier to make sure that
> two 'duplicates' don't try to sync up to the server at the same time,
> since that could cause 'thrashing' of the disk and other performance
> issues.

These can be handled several different ways. You can directly control
the execution time on the duplicates via cron so that no two machines
are syncing at the same time. Another way to do it would be to use
cfengine and set the "splaytime" appropriately (for only 8 machines,
cfengine might be a bit heavyweight).

If you need to block syncs from the master while you do something
major, login to the master and temporarily shut off whatever service
listens for new connections (rsyncd, sshd, kerberized rsh, ...). That
won't affect your existing session, but the duplicates won't be able
to update until you turn it on.

> - Lastly, it'll give you centralized logging -- if you're making sure not
> to run two pushes at once, you can log everything to a file on the
> 'master' easily and have one place to check to see if problems are
> happening.

You can have that with a pull model too. Have the master log the
incoming connections via syslog as usual. Pretty much all daemons
have builtin logging. If you are pushing the updates, you have
to have the daemons on the clients log to a syslog server, collect the
logs yourself, or have your synchonization script/program do its own
logging in the master. It seems to me that centralized logging is
actually easier if you pull.

I have a few boxes here at work that do something similar by pushing
from cron at 5 minute intervals. It's pretty easy to DOS yourself
with this. If one or more clients go down at 5:30 pm on a long
weekend, the rsync errors from the cron jobs will fill you inbox with
hundreds, if not thousands, of email messages.

If you avoid that by redirection of all output from the cron jobs,
then you are stuck with writing customized logging and/or log analysis
into your update scheme.

> > Do I use a password? If so, where does it come from?
>
> I'd suggest using ssh with public/private key authentication. That way no
> password is necessary.

The use of a password may or may not be needed. It depends on your
security needs. If the data itself is not secret, then pulling
from a read-only rsync server would not need a password. SysAdmin
magazine had a recent two-part article on setting up rsync services.

If the data needs to be protected from unauthorized access, then
rsync over ssh would seem to be the way to go. If you are running
automatically (from cron or whatever), then at somepoint you are
pretty much stuck with either passwordless access or a password
(or its equivalent) only protected by filesystem permissions. My
recollection is that the consensus from comp.security.ssh is that
a limited access passwordless keypair is the best you can do for
that. This is another point in favor of pulling; the passwordless
command only needs read privelege instead of read-write.


Mike

--
Michael Zawrotny
Institute of Molecular Biophysics
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069