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