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

It was getting very cramped with only a few MBs left. It appears currently we only get about 6 months worth of data out of 20G
so 100G seems reasonable.

The file should not be on the main domain as it adds unnecessary
complexity to the archweb role and there is a bigger chance that we
unintentionally break connectivity checking (which has happened in the
past[1][2]).

This doesn't remove the file from the main domain[3], as we need to ship
a updated NetworkManager package first.

[1] https://www.reddit.com/r/archlinux/comments/keai0g/does_anyone_know_if_this_is_normal/
[2] https://www.reddit.com/r/gnome/comments/ke9ytm/network_manager_popup/
[3] http://www.archlinux.org/check_network_status.txt

Fix #239

This adds a collaborative markdown editor as newly offered service which
is available via login for all Arch Linux Staff with an option to allow
anonymous edits by users (not default). Users are managed via keycloak
and require the Staff role to be allowed in, non staff keycloak users
currently will receive an internal server error due to an upstream
issue.