[Bug 8188] Mechanism for taking an rsync server down for maintenance
Brian K. White
brian at aljex.com
Wed Jun 1 15:08:54 MDT 2011
On 6/1/2011 3:26 PM, Matt McCutchen wrote:
> On Wed, 2011-06-01 at 14:57 -0400, Brian K. White wrote:
>> I like the built-in idea as I don't happen to use rsync via inetd/xinetd
>> or any other on-demand starter.
>> It's not an actual problem for me, today, but that's no excuse to avoid
>> doing the right thing once you recognize it.
> And "the right thing" for upstream rsync is in Wayne's sole discretion.
> In my view, the perl script is a fine solution and what convenience
> there may be in a built-in option does not merit the effort of
> maintaining the feature as part of rsync.
That is a work-around, not a solution. It's great in that, if you can
meet it's requirements and live with it's deficiencies, it's something
you can usually do right now without needing anyone else to fix or
enhance anything. It's also great in that, probably most people _can_
meet the requirements and live with the deficiencies since they are not
The work-around requires using (x)inetd, and there are many and various
reasons, from mere admin flexibility, to performance, to security, for
wanting to avoid all use of any inetd, and why rsync and many other
servers offer the ability to handle their sessions themselves.
If the service aims to be usable stand-alone, which rsync clearly does,
then imo this is just part of that. A nicity perhaps, not critical, but
trivial to implement and maintain in comparison with things like
child/session management which are definitely in there solely to support
standalone daemon operation.
Not every such service incorporates such a feature, but the provided
common examples of proftpd and apache that do provide that feature
pretty well express that, and why, it is wanted in a stand-alone daemon
if it is to ever be heavily used, especially in a public context.
To argue against it very strongly is essentially to say "Nah, we don't
care if rsync is really good for heavy and/or public use."
Given the other features that have been there since day one, and that
still go in daily, I extremely doubt that.
Come to think of it, this would matter to me a lot I just realized, as a
I have a devil of a time maintaining my opensuse install repo mirrors
because the server has no proper way to tell me not to sync right now
because it's in the process of being updated itself at the moment.
There are other problems too, relating to the difference between "This
directory was deleted from the source and so you DO want to delete it in
your mirror.", vs "This directory was removed only because the entire
tree was removed because we are no longer supporting this old version of
the distribution, you probably do NOT want to delete it from your
private copy just because we removed it from our public site."
That second problem is arguable both ways as being something rsync
should provide an answer for, or not. It's easy to say why not. But
what's the point of writing rsync? So people _won't_ use it?
More information about the rsync