[Bug 8188] Mechanism for taking an rsync server down for maintenance

[Brian K. White]

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 
that much.

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 
client.
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?

-- 
bkw