Fixes: bd19c007 ("Add configuration to retain prometheus data for 1 year")

Reduce heftig's access to the default vault and the Matrix server

Closes #567

See merge request !796

heftig has agreed to have his access reduced, as a way to reduce the
number of people with access to the "super" vault.

With this change the matrix vault is moved from the "super" vault to the
"default" vault as that is needed for maintaining the matrix server.

Fix #567

mariadb: Add switch for innodb_snapshot_isolation

See merge request !896

With the 11.6.2 release mariadb has made snapshot isolation a default
setting which recently caused issues on the AUR and the Forums, where
the respective database engines would fail due to the table changing
since the last time they read it:

    PHP Fatal error:  Uncaught mysqli_sql_exception: Record has changed since last read in table 'fluxbb_online' in /srv/http/fluxbb/include/dblayer/mysqli_innodb.php:79
    Stack trace:
    #0 /srv/http/fluxbb/include/dblayer/mysqli_innodb.php(79): mysqli_query()
    #1 /srv/http/fluxbb/include/functions.php(485): DBLayer->query()
    #2 /srv/http/fluxbb/include/common.php(162): update_users_online()
    #3 /srv/http/fluxbb/viewtopic.php(10): require('...')
    #4 {main}

We therefore introduce a config switch to restore the old behavior and
apply the changed setting on the two services.

Link: https://mariadb.com/kb/en/mariadb-11-6-2-release-notes/#innodb
Link: https://bbs.archlinux.org/viewtopic.php?id=301802
Link: aurweb#525


Signed-off-by: Christian Heusel <christian@heusel.eu>

Onboard ptr1337 as Package Maintainer

See merge request !895

Peter has previously been a Junior Package Maintainer and since the two
month period is now up and his changes in the packaging ecosystem
were all good so far they can be promoted as outlined in RFC 14.

Signed-off-by: Christian Heusel <christian@heusel.eu>

Repos are growing and we were getting notifications about 91% utilization.
That's a bit close IMO and we should just make sure to increase it to be outside
of our own thresholds.

The project membership must also be extended, if not the user is simply
deleted when the membership expires (defeating the purpose of extending
the access tokens).

Fixes: 639101e6 ("gitlab: Add ruby script for continuous extending of bot tokens")

Add alert for Fastly cost

See merge request !812

If the cost exceeds $0, it indicates that we have run out of credit
and/or are doing something wrong, in either case we want to be alerted.

Remove the WG private keys from the vault and store them only on the servers

See merge request !891

With the support for network.wireguard.* credentials[1] in systemd
v256[2], we can now easily avoid storing the credentials centrally in
our ansible vault, which is preferable as it makes the private keys less
exposed. It may also make fine-grained access easier in the future[3] as
there is no longer a vault file for each server.

All the keys have been rotated and the new private keys are only stored
on the servers.

[1] https://github.com/systemd/systemd/pull/30826
[2] https://github.com/systemd/systemd/releases/tag/v256
[3] #64

libvirt-executor improvements

See merge request !881

There is no technical reason for this at the moment, but UEFI is the de
facto firmware for x86-64, so let's be modern.

This should not change anything as the VMs are short-lived (15 minutes
at the most), so it is just added for good measure.

From the kernel patch series[1]:
"This series provides an asynchronous means of reporting free guest
pages to a hypervisor so that the memory associated with those pages can
be dropped and reused by other processes and/or guests on the host.
Using this it is possible to avoid unnecessary I/O to disk and greatly
improve performance in the case of memory overcommit on the host."[1]

The runner hosts may be memory overcommitted if there is too many
running VMs and containers at the same time, which this should help to
avoid.

[1] https://lore.kernel.org/linux-mm/20200211224416.29318.44077.stgit@localhost.localdomain/

It makes more sense to build the image in arch-boxes than building it on
each runner, especially considering that arch-boxes already have all the
necessary infrastructure, so we can avoid maintaining similar code in
two repositories and avoid running losetup, mount, arch-chroot etc. (as
root) on the runners.

The arch-boxes MR[1] has a little more context.

[1] arch-boxes!200

This reverts commit 466230e4.

This has been fixed in pacman[1], so it is no longer unreasonably slow.
Some quick testing at runner1 indicates that this only saves five
seconds at best, so IMO it is not worth the complexity to continue doing
this.

This revert does not revert the timeout back to 60 seconds, but keeps it
at 30 seconds.

[1] pacman/pacman!16

This means that there is no need to make runner-specific changes to the
image, so in theory the image could be build centrally (e.g. in the
arch-boxes project[1]) and then distributed to the runner hosts.

This change also make the SSH keys ephemeral.

[1] https://gitlab.archlinux.org/archlinux/arch-boxes

All libvirt volume management is now handled through virsh instead of
direct file system access. As a volume cannot be uploaded in an atomic
way, the current active volume is now tracked in a file on disk.

This may allow us to run the script with less privileges and use polkit
for libvirt access control[1].

[1] https://libvirt.org/aclpolkit.html

The prepare stage runs "echo "Running on $(hostname)...""[1], resulting
in "bash: line 7: hostname: command not found" and it outputting
"Running on ..." as the hostname command is provided by inetutils, which
is not installed.

Fix it by "monkey patching" it to use "hostnamectl hostname" and inject
the hostname with SMBIOS[2][3]. Injecting creds with SMBIOS may also be
useful in the future, e.g. for injecting an ephemeral SSH public key.

[1] https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v17.5.2/shells/bash.go?ref_type=tags#L452-L456
[2] https://systemd.io/CREDENTIALS/
[3] https://github.com/systemd/systemd/pull/30814

This removes 13 instances of [1] and 1 instance of the IP address from
the job log.

The latter was fixed by no longer waiting for SSH in the "run" stage,
which is unnecessary as we wait for SSH in the "prepare" stage.

[1] Warning: Permanently added '192.168.122.xxx' (ED25519) to the list of known hosts.

It was forgotten once[1] to update it in both places, so avoid that
issue in the future, by moving it to a variable.

[1] c370c9d0 ("gitlab_runner: Update concurreny math to reflect the new VM size")

Fixes #641

Signed-off-by: Christian Heusel <christian@heusel.eu>

The project now has a centralized landing page hosted in the root
directory which we can observe instead of the docs for one specific
crate.

Related to signstar#124
Related to signstar!131



Signed-off-by: Christian Heusel <christian@heusel.eu>

The project now has a centralized landing page hosted in the root
directory which we can observe instead of the docs for one specific
crate.

Related to archlinux/alpm/alpm#76
Related to archlinux/alpm/alpm!57



Signed-off-by: Christian Heusel <christian@heusel.eu>

We had load problems before and this seems to fix it for now.

We are hitting a lot of permission problems lately for sources that are
co maintained. The culprint were wrong facl permissions that have not
been adjusted since we renamed TU to Packager.
Reflect this change by fixing the groups in the archbuild tasks to use
junior-dev and junior-packager.

tf-stage1: Add GitLab Pages for Signstar

See merge request !892

Requested by dvzrv[1] and implemented in this MR[2].

[1]: signstar#91
[2]: signstar!125



Signed-off-by: Christian Heusel <christian@heusel.eu>

tf-stage2: use 1h timeout for keycloak pw resets

See merge request !889

Recently somebody complained that the email only reached them after the
password reset link had already become invalid, which is definitely
something that can happen with the previously set 5min timeout. 5
minutes timeout are too short aswell for any complex email analysis
setup or greylisting, and we therefore bump this value to one hour,
which is still short enough from a security perspective but gives our
users a bit more time to act on the reset.

Signed-off-by: Christian Heusel <christian@heusel.eu>