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).
