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.

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: 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/

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.

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.

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.

The `https://archlinux.org/.well-known/matrix/server` response is used
over the SRV record in all cases. We haven't been listening on 8448
since e9e4c114 (June 2019).

With Loki needing roughly 108GiB[1] and Prometheus at least[2]
116GiB[3], 200GiB sounds like a good starting point.

[1] increase(loki_ingester_chunk_stored_bytes_total[1w]) / 7 * 90
[2] https://www.robustperception.io/how-much-disk-space-do-prometheus-blocks-use
[3] (rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1w]) /
    rate(prometheus_tsdb_compaction_chunk_samples_sum[1w])) *
    increase(prometheus_tsdb_head_samples_appended_total[1w]) / 7 * 365

Ref: archlinux/service-agreements!16

This subdomain hosts gitlab CI produced and updated notes for
unreproducible packages.

Archiving arch-commits mails maxes out the single vCPU of CX11 and
results in High CPU Prometheus alert. If we decide not to maintain
mail archive for arch-commits, then we can likely scale back down.

CPU: Intel Xeon E5-2620 -> E-2288G
Disk: 2x~1TB -> 2x~500GB