It's been discussed in the past, but I thought it worth having a
semi-formal and documented discussion about it.
Do we think setting up mirrorbrain[0] would be a worthwhile service? For
those not familiar, the elevator pitch is that it's an open-source download
redirector to coordinate a simple CDN. It is used by a number of
open-source projects such as vlc, Gnome, KDE, LibreOffice and OpenSUSE.
Architecturally speaking, it maintains a list of our mirrors and local copy
of our repos, and monitors those mirrors for availability and staleness.
HTTP(s) clients (ie, pacman) are then redirected to an appropriate mirror
based on the clients geographic location and mirror health.
Benefits include:
1. Ensuring users always receive up-to-date packages (mirrorbrain won't
redirect to a mirror if that mirrors version of that package is outdated
compared to the authoritative repository).
2. Automated monitoring of our mirror network to proactively detect stale
or broken mirrors. Mirrorlist files (ie, /etc/pacman.d/mirrorlist) can be
automatically generated based on MirrorBrain's data.
3. Reduced load on core mirrors, and load-balancing (for example, a 1Gbit
mirror can be weighted to receive 10x the traffic of a 100MBps mirror).
4. Automatic MetaLink and Torrent file generation, with web-seeds
(currently handled by hefur on luna?).
Exceptions to redirection can be applied, for example to ensure
security-sensitive files (checksum files perhaps) are always served
directly from the authoritative repo.
Requirements are pretty basic; apache with mod_asn, postgresql, and some
python+perl modules. It can be run behind a reverse-proxy if we wanted to
hide apache behind nginx.
It's not a particular fast-moving project (last release 2014) but that's a
reflection of it's stability IMHO.
What do others think? I'm happy to take on the implementation project.
Cheers,
~p
[0] http://mirrorbrain.org/
Hi all,
On 2018-07-28 there were some discussions in #archlinux-devops around setting up
some sort of centralized logging/monitoring/alerting solution for the various
services on Apollo (and maybe other?) server(s). I had mentioned possibly using
the ELK[1] stack for this task. There was some back and forth about it
potentially being a bit heavy handed for what was needed and how we would most
likely need to repurpose/dedicate something like nymeria to handle the stack.
There was also the suggestion of possibly using something like tenshi[2] if
we're aiming for a low overhead solution, however, there would be much writing
of the regexes.
With that being said, the purpose of this email is to have a more formal
discussion around what we're trying to capture from the logs, the actions we
want to have taken with what ends up being captured, and possibly come to a
consensus on what tool(s) we could leverage.
Thoughts?
Regards,
Andrew
[1] https://www.elastic.co/de/elk-stack
[2]https://github.com/inversepath/tenshi