On never kernels, a swappiness of 0 means "disable swap completely"
where it would before ~ 2.6.32 would still allow the kernel to swap
in certain emergency situations.

We have alerting in place in case of any swapping, hoping we can react
quickly enough to catch problems of runaway machines before they have
to haywire OOM or reboot.

Command: `rg -l swappiness | xargs sed -i 's/swappiness" = 0/swappiness" = 1/'`
(but not adding the change to the virtual hardware for the local grid).

Signed-off-by: Benoit Donneaux <benoit@leastauthority.com>

Signed-off-by: Benoit Donneaux <benoit@leastauthority.com>

Signed-off-by: Benoit Donneaux <benoit@leastauthority.com>

Signed-off-by: Benoit Donneaux <benoit@leastauthority.com>

.. that I forgot earlier.

The default log level ("WARN") means borgbackup does not output
anything (and exits with a "0" return code) on success.

We'd like to have some more insight into long-running monthly
backup repo checks and turn up the log level to "INFO" with
this change.

See https://borgbackup.readthedocs.io/en/stable/usage/general.html#common-options .

Fixes #136.

That makes working with its output in Grafana easier.
Good documentation can be found at
https://borgbackup.readthedocs.io/en/stable/internals/frontends.html#json-output

We want to have this in our own monitoring

Fixes #118

This reverts commit c8a13555.

Sadly, Borg says this is not a good idea: https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-backup-from-multiple-servers-into-a-single-repository

Spoiler:  This won't work, Borg does not guarantee consistency with
parallel writers to the same repo as I now found out.

It's not really a key, and not really public, but not secret either.
This way, the tests can run.

Since that describes it better, especially now that I have
moved the one line that wasn't about the VPN out of it.

Tom Prince authored 3 years ago and Florian Sesser committed 3 years ago

This includes the host-based metrics collector, and the VPN client setup (including key deployment).

... and fix that option the other commit introduced

Do some name resolution for those poor computers

Improve factoring by removing those `/etc/hosts` entries

And avoid the infinite loop @tomprince was encountering in !258

morph offers an auto-passed `nodes` parameter from which we can read all of
the nodes in the morph "network".  We can dig around in this to find the
monitoring node and then read its configured IP address.

It may be worth noting that this address appears in at least two places in the
configuration.  It appears in our "input" configuration which grid.nix
defines.  This change reads it from there.  We also have a NixOS module
`nixos/modules/monitoring/vpn/server.nix` which reads this "input" and uses it
to configure `networking.wireguard.interfaces.monitoringvpn`.  This is fed
onwards to <nixos> to generate actual system configuration.

It seems better to use the former than the latter because we have more direct
control over it and if we consider the whole configuration system a function
then it is more like an argument we are supplying rather than an obscure
implementation detail.

This reverts commit 3113a3e6.

Thinking a second time:  While the staging grid is deployed to
by an automaton anyway and it taking a minute longer won't bother
us, 20 % space savings is probably not worth slowing down
development interactivity.