GitLab

When we designed our current mirror pool, we dismissed the server-side options mainly because of reasons that are all now moot:

• We did not host our website ourselves → we now do.
• We had no place of our own to host such a redirector → we now have this.
• We lacked sysadmin resources to implement something server-side → we could now decide to prioritize this if we wanted.
• We were worried about our web server becoming a SPOF → our current client-side mirror picking code relies on our web server and has the same problem.

Then we decided to pick the mirror on the client-side. It felt pretty cool at the time but experience shows that as a consequence of this solution, we have a whole set of other problems to solve:

• https://gitlab.tails.boum.org/tails/blueprints/-/wikis/HTTP_mirror_pool#improve-ux-and-lower-maintenance-cost-2021
• We have to maintain our mirror pool manually, which is tedious, repetitive, and stressful
• We have to write, maintain, and improve, custom code to:
  • monitor our mirrors (check-mirrors + integration into our infra)
  • pick a mirror on the client side, using programming languages very few of us are comfortable with (JavaScript + integration into our Perl Upgrader)
• Even seemingly simple changes require careful planning and coordination between developers, technical writers, mirror pool maintainers, and release managers. Quite often the update must be released in several stages. This sometimes leads technical writers to instead implement JS/CSS hacks to bypass the design, instead of integrating their change into the design, which suggests the design is not great.
• Only 1 person has the big picture in mind.

All of these need more work in order to make our current implementation sustainable. So I think it's time to consider cutting down our costs, stopping investing into this design, and ditching the whole thing in favor of a server-side redirector.

Additional benefits

• As we see all downloads, we can do stats about downloads and upgrades ⇒ UX has more useful data to do their job
• We can ditch the DNS fallback pool, so:
  • One less piece of infra (Git hook & code that updates the dl.a.b.o DNS zone)
  • No more hard-coded IP addresses that may change without upstream notifying us
• We can simplify our website: no need to differentiate clients with/without JavaScript anymore, one less piece of JS to integrate

Candidates

The most popular option these days seems to be Mirrorbits (in Debian Bookworm).