rsync+ (batch mode) feature suggestion

[Kyle Amon]

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