Invoke xrandr to actually connect the device.
Additionally, we let systemd create the logs directory and use our module loader
instead of handling it manually.
It seems that dnsdist doesn't actually request CAP_NET_BIND_SERVICE, which is why normally it's executed and root and setuids to another, unprivileged, user. This means that as it is, dnsdist will be unable to bind to any port under 1024 and will fail with access denied.
Removing CAP_SETGID and CAP_SETUID is also related to this as we don't actually change the uid or gid after the fact as we use DynamicUser. (That part isn't strictly NEEDED but there's no reason to have those capabilities if we don't use them).
There are also some additional sandboxing we can remove from the service definition as they are assumed true or strict by DynamicUser: specifically PrivateTmp and ProtectSystem respectively.
ProtectHome is still there, despite being assumed read-only as setting it to true means they are seen as empty. I don't think it really matters as I don't know if systemd will ignore it or not, but I didn't see any reason to go hunting for excuses to make it a bigger change.
The recent custom endpoint addition allows us to directly point
certbot to the custom Pebble directory endpoint.
Thanks to that, we can ditch the Pebble patch we were using so far;
making this test maintenance easier.
Add a new option permitting to point certbot to an ACME Directory
Resource URI other than Let's Encrypt production/staging one.
In the meantime, we are deprecating the now useless Let's Encrypt
production flag.
- spawn the geoclue-agent directly instead of running it via bash
- document why we cannot use DynamicUser = true
- have systemd create the home directory instead of using an explicit
tmpfiles.d fragment
* lm_sensors: add fancontrol module + nixos test
fancontrol is a small script that checks temperature sensors and adapts
fan speeds accordingly. It reads a text config file that can be
auto-generated by running the pwmconfig wizard on the live system.
Both options were introduced in systemd v243[1]. Those options can be
used to ensure that LinkLocalAddressing is only configured for a given
interface if DHCPv4 fails. To quote `systemd.network(5)`:
```
If "fallback" or "ipv4-fallback" is specified, then an IPv4
link-local address is configured only when DHCPv4 fails. If "fallback", an IPv6 link-local
address is always configured, and if "ipv4-fallback", the address is not configured. Note
that, the fallback mechanism works only when DHCPv4 client is enabled, that is, it requires
"DHCP=yes" or "DHCP=ipv4".
```
[1] 8bc17bb3f7
Default behavior is to continue executing the script even when one or
multiple steps fail. We want to abort early if any part of the
initialization fails to not run with a partially initialized state.
Default behavior also allows dereferencing non-existent variables,
potentially resulting in hard-to-find bugs.
