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.

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

Sven considers this location to have higher capacity and reliability.

Follow-up to [1]; while most of our cloud servers are in Helsinki, the
latency from most of Europe is lower when accessing servers in Germany.

Pinging from multiple locations using ping.pe, the latency to Nuremberg
from most locations appears to be 10-20ms lower (compared to Helsinki).

[1] !500

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

With Hetzner now having a datacenter in the US[1], we don't want to
accidentally create a server in the US, so let's always create them in
Helsinki where most of our cloud servers are.

[1] https://www.hetzner.com/news/11-21-usa-cloud/

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

Now that misc/get_key.py checks if the vault file passed to it exists,
we cannot pass paths only resolvable from the root directory. Instead,
use paths that make sense relative to the current directory and avoid
calling chdir when loading the vault file.

Fixes: 77542146 ("Rewrite get_key.py to use click instead of typer")

Closes #207

https://lists.archlinux.org/pipermail/arch-dev-public/2021-July/030471.html

Fix #86

Fix #356

nginx, certbot, postfix and mailman are still missing and the DNS is
still pointing to luna.

Loki is using a lot of storage (~8GB per week).

Fix #354

Sven-Hendrik Haase authored 3 years ago and Kristian Klausen committed 3 years ago

Co-authored-by: Kristian Klausen <kristian@klausen.dk>

The TU Bylaws is currently deployed as part of the aurweb role which
makes it more work for devops and with gitlab pages TU's can deploy it
themself.

The WKD setup for master-key.archlinux.org requires this domain to
obtain the master keys via WKD. As WKD falls back to archlinux.org which
contains no .well-known/openpgpkey entry.

Eg. https://whatcanidoforfedora.org/ and
https://whatcanidoformozilla.org/. Mea culpa.

Loki keeps logs it returns in ram, resulting in the oom killer on 2GB's
of ram.

Fix #303

[1] https://gitlab.archlinux.org/archlinux/archlinux-bugs-snapshotter

This allows us to get proper certificates for loki which will run on logging.archlinux.org
on the same machine as monitoring.archlinux.org.