On Wed 28 Feb 2024, Crystal Kolipe wrote:
> On Wed, Feb 28, 2024 at 09:25:35AM +0000, Pontus Stenetorp wrote:
> > scripting together some sort of "mirror health" tool would be a fairly easy
> > (yet probably valuable)
>
> In principle it might sound 'fairly easy', but once you start to add code to
> deal with things such as sites going down for planned maintenance, being
> unavailable from certain locations due to network problems and so on, your
> simple tool would quickly start to grow in complexity.
>
> In any case, the list of mirrors needs to be manually reviewed. I vaguely
> remember some years ago a previously good mirror started serving a pre-release
> copy of the distribution as if it was the actual release, and was subsequently
> removed.
>
> A simple mirror health tool likely wouldn't catch that.
Agreed, I do not think the task should be fully automated. Rather, I think it would be helpful to have a couple of easy checks that could indicate the health of a mirror, rather than fully determine the health of it. I for example was on a Japanese mirror last year that "lagged" behind security patches for days, if not all the way up to a week, and this is a fairly easy check to automate. I would imagine just a list of all the mirrors on the mirrors list coupled with say a list of outage events, "lag events", releases available, etc. that could be used to get a better overview of the health of a mirror than a sample of a single point in time, while still not aiming for any sort of complete automation. Hopefully this is just a few hundred lines of Perl feeding data into a static page served by httpd(8).
No comments:
Post a Comment