With the final lists migrated to mailman3[1], the mailman2 server can
finally be killed.

When the mailman3 server was initially setup[2], it was done on a
separate server because the mailman and mailman3 packages conflicted,
and the traffic was routed over wireguard (HTTP, LMTP and SMTP).

Instead of installing mailman3 on the original lists.al.org server and
transferring the data, it was easier just to install the missing pieces
(basically Postfix and adjusting the Nginx configuration) on the ml3
server and move the IPs (to keep the IP mail reputation).

So basically the following was done:
- The IPs for the original lists.al.org was moved to the mailman3.al.org
  server
- The mailman2 datadir was transferred to mailman3.al.org server, so we
  can keep the pipermail links alive, and import missing mails if needed
- The original lists.al.org server was decommissioned
- The mailman3.al.org server was renamed to lists.al.org
- The missing pieces was added to the mailman3 role (basically Postfix +
  Nginx adjustments)
- The mailman role was deleted and the mailman3 role renamed to mailman

[1] 75ac7d09 ("mailman: Fourth and final batch of mailman3 migrated lists")
[2] 9294828f ("Setup mailman3 server")

Fix #59

Going to be served by all our Geo boxes under riscv.mirror.pkgbuild.com.

The WKD logic has been moved to the archlinux-keyring project[1][2].

[1] archlinux/archlinux-keyring!166
[2] archlinux/archlinux-keyring!169

Useful if we wanted to create a Geo-based archive consisting of machines
in the archive_mirrors group (though this will likely not happen because
it'd break archlinux-repro due to the ~4 hour sync delay).

aur4 was apparently some kind of "new aur" hosted on luna, which is long
gone.

Fixes: 79f7d599 ("Goodbye luna")

anthraxx wants some infra for a repos-git POC, so let's give it to him!

The server has been configured with the common and firewalld role, but
is unmanaged.

Its disks were migrated to a new server (prompted by an unsolvable issue
with the previous box's network interface; might have been a mobo issue).

Brings support for managing Primary IPs.

There's a bit of a chicken and egg situation here but it's preferable to
manage the server's attributes the same way as all of the cloud servers.

Ref: archlinux/monthly-reports!1

Ref: repod!65

We want non-DevOps to be able to deploy project documentation (ex:
repod) with GitLab Pages and a separate domain was considered the only
sensible solution due to security issues[1].

[1] https://github.blog/2013-04-09-yummy-cookies-across-domains/

asia.mirror.pkgbuild.com has been offline for 12 days so far while we
wait for a NIC replacement. Should have taken it out of DNS NS duties
earlier but better late than never.

It needs the extra RAM.

[1] https://datatracker.ietf.org/doc/html/rfc8461#section-3.2

Fixes: 0b87cbfd ("mta_sts: Switch to enforce mode and bump max_age to 30 days")

Ansible side of commit 5007c1a8 ("tf-stage1: allow setting the NS
TTL of geo domains"); both values need to match so our geo nameservers
report the same TTL as that returned by the parent zone's nameservers.

When adding a new geo domain or doing other testing, we would want to
use a low TTL to allow for making quick changes to the configuration.

- add the new role to redirect.archlinux.org
- release mirror.pkgbuild.com of all DNS duties

Foxboron wants some infra for a buildbot POC, so let's give it to him!

The server has been configured with the common and firewalld role.

The idea bebind this is to be able to give vault access to new DevOps
members without giving away more important credentials like Hetzner's.

In an effort to stay consistent with the TTL used for the archlinux.org
and pkgbuild.com NS records, as well as slightly improve lookup latency.

New hcloud adds protection fields to servers, volumes and floating IPs.

/srv/gitlab has been moved to local (NVMe SSD) storage; hopefully it
won't grow too large and thus require transferring back to a volume.

We don't want mirror.pkgbuild.com's DNS server to be a
single-point-of-failure, so this commit adds multiple authoritative DNS
servers for the zone. The extra DNS servers are run on the geomirror
servers.

The _acme-challenge zone, used for obtaining certificates, is run solely
on mirror.pkgbuild.com's DNS server, to avoid syncing DNS records
between the servers (KISS).

We had a GeoIP mirror in the past based on nginx and its GeoIP module,
but it didn't perform very well, due to the high latency (asking a
central server for the package and then redirected to the closest
mirror).

One of the reasons for offering this service, is so we can relieve
mirror.pkgbuild.com which is burning a ton of traffic (50TB/month),
likely due to it being the default mirror in our Docker image. Another
reason is so we can offer a link to our arch-boxes images in libosinfo
(used by gnome-boxes, virt-install and virt-manager), with good enough
performance for most users.

This time we take a different approach and use a DNS based solution,
which means the latency penalty is only paid once (the first DNS
request). The downside is that the mirrors must have a valid certificate
for the same domain name, which makes using third-party mirrors a
challenge. So for now, we are just using the sponsored mirorrs
controlled by the DevOps team.

Fix #101

This hasn't seen much growth in the past two months and is chilling
around 13G. We can easily bump it once we have more debug packages.

With the PHP->Python port done[1][2], there isn't much need for aur-dev
anynmore. Most things can also be tested locally and aur-dev haven't got
any love since the port (ex: allowing the aurweb maintainers to deploy
without asking DevOps).

[1] https://lists.archlinux.org/pipermail/aur-general/2022-February/036786.html
[2] !525

The default TTL of 3600 seems a bit short for these.

Almost all of our DNS records have a TTL of 86400 (24 hours) with a few
using a TTL of 600 (some MX and TXT records). The former is too long to
be flexible when a need for fast change(s) arises, and the latter don't
benefit from the low TTL. Standardize on a TTL of 3600 (1 hour) for all
our records.

Gives the option to downgrade a server in the future, similar to the
default on Hetzner's Cloud Console ("CPU and RAM only").

250 is not a nice round number, whereas 200 is.

This reverts commit c8d1a39a

[1] https://gitlab.archlinux.org/archlinux/btw

Better bang for buck; unfortunately it doesn't seem any faster.