-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
2000-06-15-04:55:22 Nacho Ruiz:
> Does anybody know how to broadcast a rsync command?
>
> I've several machines conected to a network and I would like to copy several
> file to them.Although the number of machines is small an I can write a
> script, it can change easily (more machines can be added or some can be
> retired).
> I have tried to copy to the broadcast addres, but it seems not to work.
What you want to do, can't be done.
Rsync allows efficient replication of a directory heirarchy from one
system to another, with no prearrangement of any sort necessary. To
do this the src system has to carry on a dialogue with the dst
system, listing files with details like checksums and whatnot, the
two comparing notes and deducing the minimum information that has to
be sent for the dst to reconstruct a perfect copy of the src, using
the transmitted info along with whatever bits can help out that may
be lying about the dst already.
Rsync requires a point-to-point dialogue; it cannot work with
broadcast. Rsync runs over TCP, which is point-to-point; folks
wanting to do broadcast usually run UDP, since TCP cannot work with
broadcast.
You've got two approaches you can take. If you want to continue
using rsync, and just eliminate the manual maintenance of the client
list, you could come up with a separate discovery protocol, to allow
a driver script on ths server to automatically deduce the list of
clients it should push to. If you don't want to deploy any new
protocols, you could do some scripting on ths server; start by using
nmap to scan for available candidate recipients on the local net
that are listening on the port you want to use, e.g. tcp/22 for ssh
transport. Take that candidate list and eliminate any hosts for
which ths server doesn't have permission to get in, or the intended
destination directory doesn't exist. Then loop over the remainder. A
helper to run multiple rsyncs in parallel may buy you something,
depending on available bandwidth, local system resources, and the
nature of the updates you need to push. I have a script I find
convenient for running jobs in parallel, I'll be happy to email it
to anyone who likes.
The other approach would be to assemble something that could
actually distribute the updates in a broadcast. For that to work, it
will be necessary to eliminate the need for a dialogue between the
server and the client to compute the changes. If you keep an
unmodified copy of the src on the server each time you do a push, to
be used to compare with the new state the next time you do a push,
so the server always has two copies, then you can locally compute
the changes and then arrange to broadcast them out.
xdelta[1] seems to be the most actively-developed tool that would
support computing the local changes and then applying them after
they're distributed to each client.
I've recently stumbled across a toolkit for broadcasting data,
called spread[2], but have not yet had time to look at it.
But it might be possible to assemble a genuine "broadcast rsync" out
of those components.
- -Bennett
[1] <URL:http://www.xcf.berkeley.edu/~jmacd/xdelta.html>
[2] <URL:http://www.spread.org/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5SPbVL6KAps40sTYRAk1VAKCEuzMIlePZTrUtYCgoj4qX6SreGwCfbGKz
6brS6hSI51ws94pbO25JPcg=
=9HB6
-----END PGP SIGNATURE-----
