Bert,
Hi. If you are still interested in your rsync+ project, changes for
which have evidently been (and are, perhaps, still being?) submitted
to the official, upstream rsync version, you may want to add the
following feature, proffered below, in order to conduce a little
greater batch mode usage flexibility primarily for those with above
average security concerns.
Currently (at least in the current, official, stable rsync version),
batch mode may only be utilized in a fairly rigid, autocratic, master
pushes to slaves mode. Therefore, at least among those slaves with
the necessary minutia in place to allow the master to copy batch mode
filesets to them and perform remote command execution on them at all,
the slaves (like true slaves) have no choice but to make the changes
that have been dictated to them. This circumstance may be okay for
usages where all the slaves can confer implicit trust in their master
(admitedly, probably most), but, for applications where the "slaves"
can't afford to allow this extreme degree of latitude to their
"master," it precludes usage at all as currently implemented. To
remove this preclusion from potential applications for batch mode use
where it would otherwise be desirable, a feature that provided a pull
model usage would seemingly prove adequate and could be implemented
in something like the manner described below.
An additional --request-batch-run option could be added that takes
one or more arguments of either type hostname or file where hostname
type arguments would cause a batch-run-request to be sent to the
specified host and file type arguments would cause the specified
file (containing a list of hostnames) to be read with a batch-run-request
being sent to each host listed. To support this, additional batch
mode logic like the following would have to be added to the daemon
mode feature option.
o A "batch master" global option could be added that specifies
the hostname of the batch "master". If not present, the
batch mode functionality of daemon mode would not be enabled.
o A "batch fileset dir" global option could be added that specifies
the directory containing the batch fileset to retrieve from
the "master".
o A "read batch" global option could be added that specifies
the default batch fileset prefix to use when a batch run
request does not contain a --read-batch=pfx option.
o A "batch destination path" global option could be added that,
when set, specifies the destination tree path to use for
overriding the original destination tree path if they differ.
o Only if a --batch-run-request is accompanied by a valid user
and associated password in the rsync daemon's specified
"secrets file" will the "master's" batch-run-request
be
honored. This requirement would only be needed to prevent
potential DoS attacks by an anonymous user initiatinging many
successive batch-run-requests. Otherwise, anonymous users
could safely be allowed to trigger batch-run-requests since
all they could do is cause the rsync daemon to do a fresh
update using the fileset defined by it's default "read batch"
prefix from it's internally defined "batch fileset dir" of
it's internally defined "batch master".
o An honored batch run request could then automatically rsync
the batch filesets from the "master" and then perform the
the update. In order to facilitate this, the "master" would
need to have an rsync daemon running and configured to support
this. Furthermore, the "slave" could use the same user:password
to perform the update from the "master" that the master used
to initially send the batch-run-request. This way it could
provide a sort of weak-assed shared secret kind of mutual
authentication. I hope that makes sense to you. If not, I
can elaborate.
Bonus:
o Offering a pull model batch mode not only confers the
ultimite decision on whether or not to perform the update
to the machine being updated, it eliminates the need of
additional tools for the entire process other than just
rsync itself.
Additional Possibility:
o It could even be arranged such that rsync could offer the
same pull model batch mode without reliance on rsync's
daemon mode by adding logic such that ssh is used for the
file transfering and remote command execution necessary
to achieve it. Furthermore doing this as well would
provide significantly more confidential authentication
as well as adding confidentiality to the file transfers
(a feature that neither rcp and rsh nor rsync/d provide
at all).
I hope this all made some reasonable sense. Assuming so, I
not only trust that you will see the point and agree with it's
desirability, but that you will also be able to relatively
easily fill in my logical gaps and detail ommissions here
as well extrapolate as necessary.
All the same, batch mode is a nice additional feature as is. Thanks.
I just think it could be better yet. :-) Let me know your thoughts
on this idea. :-)
-- Kyle
P.S. FYI, although I CCd it here, I am not on the rsync mailing list.
--
Kyle Amon, CTO office: 813-979-1633 email: amonk@backwatcher.com
BackWatcher, Inc. cell: 813-363-0035 web: http://backwatcher.com
fax: 813-977-5843 icq: 46479255
KeyID 1024D/4EB96E44
Key fingerprint = E9EC 0046 8487 23D7 C91C D757 7B2A 8AE9 4EB9 6E44
This email Copyright 2002 BackWatcher, Inc., a Florida corporation,
3819 Garden Lakes Terrace, Bradenton, FL 34203-7305: (941) 756-6297
All rights reserved.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20030119/5b0f9442/attachment.bin
