Multiple PC syncronization

Hi.

I have a cluster made by 8 workstations running gentoo linux (kernel
2.4.x, ssh from ssh.com). The infrastructure is based on kerberos 5, afs
and openldap. Now, since those machines are also used by my students,
I'd like to update only one machine and make the others sync themselves.

What do you suggest? I'm thinking about these solutions:

1. SSH with root ssh tickets, tarring necessary directories,
transferring the archive on every machine and untarring it
2. Using rsync over ssh (or stunnel?) sync'ing necessary directories

Now, in the first case, I have to transfer the archive on each machine
and it's a heavy overhead... over 20 gb...

On the other hand, I don't know anything about rsync. Will it delete
files not longer present on the ``master'' machine? Will it update
symlinks if on the master the symlink is against another file, or
changed into a regular file?

What would you suggest? Security is *the* issue for me now...

--
Sensei <mailto:senseiwa@tin.it>

The optimist says "Tomorrow is sunday".
The pessimist says "The day after tomorrow's monday". (Gustave Flaubert)

Sensei wrote:

> I have a cluster made by 8 workstations running gentoo linux (kernel
> 2.4.x, ssh from ssh.com). The infrastructure is based on kerberos 5, afs
> and openldap. Now, since those machines are also used by my students,
> I'd like to update only one machine and make the others sync themselves.
>
> What do you suggest? I'm thinking about these solutions:
>
> 1. SSH with root ssh tickets, tarring necessary directories,
> transferring the archive on every machine and untarring it
> 2. Using rsync over ssh (or stunnel?) sync'ing necessary directories
>
> Now, in the first case, I have to transfer the archive on each machine
> and it's a heavy overhead... over 20 gb...

Well, obviously rsync will have much lower network traffic. That in turn
means that it won't take as long, which further means that you can have
them sync up more often. Indeed, the more often you sync them with rsync,
the less time it will take, since there will be fewer changes! Thus, you
could easily have them set up to sync up every ten minutes or so, just
making sure that if one of them is already syncing, you don't start a new
sync on it.

> On the other hand, I don't know anything about rsync. Will it delete
> files not longer present on the ``master'' machine?

If you tell it to, yes. By default it doesn't, but there is an option
(--delete) for it to do so.

> Will it update
> symlinks if on the master the symlink is against another file, or
> changed into a regular file?

Yes, if you've specified the right options. For this situation, you'll
probably want to use the "-a" option ("archive"), which tells it to copy
recursively, preserve symlinks, ownership, groups, timestamps, permissions,
and copy device files as device files. You may also find "-x" (don't cross
filesystems) to be useful. If you're using hardlinks, you'll also want
"-H" to preserve them.

> What would you suggest? Security is *the* issue for me now...

I'd suggest the rsync. It's faster, which means there's less time for
something to go wrong. You're not transferring all the data every time --
which means that if someone did somehow break the stream, they'll get only
*part* of your data, instead of everything. And doing it over ssh, I don't
see any way in which it's less secure than the tar method, off the top of
my head. I suppose that in theory, an attacker could alter a file to have
the same size and timestamp as one on the "master" server, so rsync's
quick-check would tell it to bypass that file... but if you're really
worried about that happening, there's an option to turn off quick-checking.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

Travis Casey wrote:
> I'd suggest the rsync. It's faster, which means there's less time for
> something to go wrong. You're not transferring all the data every time --
> which means that if someone did somehow break the stream, they'll get only
> *part* of your data, instead of everything. [...]

You've been really neat, thank you very much for the pointers! :)

--
Sensei <mailto:senseiwa@tin.it>

The optimist says "Tomorrow is sunday".
The pessimist says "The day after tomorrow's monday". (Gustave Flaubert)

Sensei <noone@nowhere.org> writes:

]Hi.

]I have a cluster made by 8 workstations running gentoo linux (kernel
]2.4.x, ssh from ssh.com). The infrastructure is based on kerberos 5, afs
]and openldap. Now, since those machines are also used by my students,
]I'd like to update only one machine and make the others sync themselves.

]What do you suggest? I'm thinking about these solutions:

]1. SSH with root ssh tickets, tarring necessary directories,
] transferring the archive on every machine and untarring it
]2. Using rsync over ssh (or stunnel?) sync'ing necessary directories

]Now, in the first case, I have to transfer the archive on each machine
]and it's a heavy overhead... over 20 gb...

]On the other hand, I don't know anything about rsync. Will it delete
]files not longer present on the ``master'' machine? Will it update
]symlinks if on the master the symlink is against another file, or
]changed into a regular file?

I suggest you use rsync.
man rsync
Yes it will delete files which are not on the master if you tell it to.
Yes, it will update soft links and not turn them into files.
rsync uses whatever you tell it to for the remote shell (ssh, rsh,..)
(--rsh option)


]What would you suggest? Security is *the* issue for me now...

No it is not. If it were you would simply unplug the computers, and put
them into the hottest fire you have. Security comes behind use.

Bill Unruh wrote:
> No it is not. If it were you would simply unplug the computers, and put
> them into the hottest fire you have. Security comes behind use.

Security means having a good probability of not being cracked. It's not
having a 120% cracking-proof lan. Otherwise, the ``Rule '' is right:
unplug it. :)

--
Sensei <mailto:senseiwa@tin.it>

The optimist says "Tomorrow is sunday".
The pessimist says "The day after tomorrow's monday". (Gustave Flaubert)

>]What would you suggest? Security is *the* issue for me now...
>
>No it is not. If it were you would simply unplug the computers, and put
>them into the hottest fire you have. Security comes behind use.

So let's assume I've decided to use rsync to update things. What's
the best way to set it up?

Push? Pull?

Can I run it from a cron job?

Do I use a password? If so, where does it come from?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote:

>>]What would you suggest? Security is *the* issue for me now...
>>
>>No it is not. If it were you would simply unplug the computers, and put
>>them into the hottest fire you have. Security comes behind use.
>
> So let's assume I've decided to use rsync to update things. What's
> the best way to set it up?
>
> Push? Pull?

Well, really, it depends on what you're trying to achieve. For a situation
like the one given, here's what I'd suggest:

- first, using NTP on all the machines to keep their clocks in sync. This
will help with the rsync itself, since it'll make sure that comparing
timestamps is accurate. Second, it'll help with running things from cron
if you can be sure that all the machines have the same time.

- second, I'd use a push model. This gives a few things:

- 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 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.

- 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.

> Can I run it from a cron job?

You certainly can. In fact, that's how I'd probably do it. A possible
alternative would be to use 'at'.

> 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.

Note as well that depending on what you're transferring you may not want or
need to use the root account.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

>I'd suggest using ssh with public/private key authentication. That way no
>password is necessary.

But if you run it from a cron job, the private key needs to be available
to the cron job. So it must be stored in-the-clear on the push system.

It's probably protected by the file system, but it isn't also encrypted
with the users passphrase.

Have I got that right? If so, is there any way around that?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote:

>>I'd suggest using ssh with public/private key authentication. That way no
>>password is necessary.
>
> But if you run it from a cron job, the private key needs to be available
> to the cron job. So it must be stored in-the-clear on the push system.
>
> It's probably protected by the file system, but it isn't also encrypted
> with the users passphrase.
>
> Have I got that right? If so, is there any way around that?

Not that I know of, if you want it to be automatic. Obviously, if any human
intervention is required, then the cron job won't be able to run
unassisted.

Depending on the nature of the data, you could do it without a cron job, and
simply run it manually as needed.

I'll note, though, that that's another reason to do it as a push system --
if you want automated copying, it's easier to secure one copy of one
private key than eight copies of one, or eight individual private keys on
eight machines.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

Sensei <noone@nowhere.org> writes:

[snip]
> 1. SSH with root ssh tickets, tarring necessary directories,
> transferring the archive on every machine and untarring it
> 2. Using rsync over ssh (or stunnel?) sync'ing necessary directories
>
> Now, in the first case, I have to transfer the archive on each machine and
> it's a heavy overhead... over 20 gb...
>
> On the other hand, I don't know anything about rsync. Will it delete
> files not longer present on the ``master'' machine? Will it update
> symlinks if on the master the symlink is against another file, or changed
> into a regular file?

rsync -e "ssh -i /some/.ssh/id_file" /usr/portage/packages/ \
otherbox:/usr/portage/packages/ -CavP

> What would you suggest? Security is *the* issue for me now...

See rsync(1). Also, for that matter, see emerge(1) as well, and various
other gentoo-specific bits; it's entirely possible to have emerge attempt
to use local .tbz2 archives in preference to compiling things themselves.

Ideally, you want some custom /etc/make.profile directory on all the boxes,
that doesn't think gcc is a system package, a cluster of identical machines
and one off-cluster box dedicated to building packages (and probably
another `admin'-type box for backups and monitoring...). I think you're on
the right lines.

~Tim
--
Vescere bracis meis |piglet@stirfried.vegetable.org.uk
|http://spodzone.org.uk/pigmail/