Version 257.1 of systemd changed[1] the PrivateTmp setting for the
systemd-timesyncd service from "yes" to "disconnected", which broke our
systemd-timesyncd test.
The reason for this is because the systemd-tmpfiles-setup.service is
*only*[2] added as a dependency of systemd-timesyncd.service if
PrivateTmp is set to "yes" but not when it is set to "disconnected"
(which would make sense given that the tmpfiles.d mechanism was
originally designed for temporary files).
Commit 339a866b7c switched the activation
script to using systemd-tmpfiles, but the commit in question doesn't
provide an explanation why this was necessary in this particular case.
However the pull request[3] lists an ongoing effort to get rid of Perl
and in the future get also rid of BASH for activation. The reasons for
doing this are outlined in the document[4]:
> The simple presence of interpreters on a system pose a security risk.
> An attacker that gains access to a system can abuse them to execute
> arbitrary commands. Mitre lists this as technique T1059. The most
> radical yet simple solution to mitigate this exploit is to remove all
> interpreters from a system (Mitre M1042). This radical solution is
> only really feasible and/or interesting for appliances (i.e.
> non-interactive) systems. Especially for high-security solutions this
> mitigtation is interesting.
I personally don't think this is a very compelling reason, at least for
our activation scripts, since an attacker could simply drop an
executable binary. Nevertheless, getting rid of additional dependencies
on eg. Perl or BASH is something worth pursuing to trim down moving
parts.
To address this, I decided to implement this as a normal systemd service
unit, since we need to guarantee that it's started before
systemd-timesyncd.service and with a dedicated unit we can ensure
explicit ordering. This has the advantage that we don't interfere with
the effort of getting rid of Perl/BASH for activation/boot and also
don't risk running into race conditions (again) because it's very
unlikely that systemd will change/deprecate explicit unit ordering in
the near future.
[1]: 1f6e192848
[2]: 30675a6ee9/src/core/unit.c (L1274)
[3]: https://github.com/NixOS/nixpkgs/pull/263203
[4]: https://pad.lassul.us/nixos-perlless-activation
Signed-off-by: aszlig <aszlig@nix.build>
Fixes this eval warning:
evaluation warning: The option `services.hound.config' defined in `makeTest parameters' has been changed to `services.hound.settings' that has a different type. Please read `services.hound.settings' documentation and update your configuration accordingly.
This allows for instance to reject switching into a configuration, while
still allowing to reboot into that same configuration.
This can be useful for instance to reject switching to a configuration
with a new systemd major version, but setting that same configuration as
the new boot default with `switch-to-configuration boot` is fine.
Now that we are disabling telemetry by default, we should attempt to
override it and other options in existing mutable configs,
if the user had a mutable config and advances their system.stateVersion.
We should disable telemetry but enable security update checks. Make both
controlable in the module without digging into settings.
Disabling telemetry also makes NixOS tests faster because the server
tries to send telemetry on first start.
Every postgresql testcase essentially does the following things:
* Filter `postgresqlVersions` for server packages
* Filter postgresql server packages for suitable ones (i.e. extensions
must support the given version)
* Generate an attribute-set of testcases
The first item became necessary in
7ab1e88833 given that
`postgresql/default.nix` now exposes JIT and non-JIT servers AND a
`libpq` that is not suitable for the tests here.
This changes restructures this a little bit, i.e.:
* Having an attribute-set that contains a bunch of postgresql servers
and a single client package seems odd (and the sole consumer of
`postgresqlVersions` in nixpkgs, the test suite, has to take that into
account). Hence, postgresql's default.nix now provides `libpq` (the client)
and a `postgresqlVersions` attribute with all supported JIT and non-JIT
variants of postgresql.
* Each test-case gets a third argument, a function called `genTests`:
this function sets `recurseForDerivations = true;` and generates an
attribute-set of tests for each postgresql version given a function
that returns a testcase or multiple test-cases (`makeTestFor`). The
argument to `makeTestFor` is a postgresql server package.
This function also accepts a filter predicate that is passed against
`filterAttrs` to remove postgresql server packages that are not
suitable for the test (e.g. because the version isn't supported by the
extension to test).
I checked by making sure that the `.drv` doesn't change on staging with
this change on top for postgresq, postgresql-jit,
postgresql-wal-receiver, postgresql-tls-client-cert, anonymizer, pgjwt,
pgvecto-rs, timescaledb, tsja and wal2json.
While it is possible to globally enable or disable security wrappers, it
isn't possible to disable only a subset of them. Consequently, users
will have to overwrite the security wrappers completely and re-add the
desired subset in case they want to disable a subset of those set up by
the NixOS modules.
Address this usecase by adding a new per-wrapper enable option.
The `autoDeployCharts` option further improves the auto deploying
capabilities of the k3s module by allowing to deploy and configure Helm charts
that are then instaled via the k3s Helm controller. Although this was
also previously possible by using auto deploying manifests, it required
some knowledge of the k3s Helm controller and led to a lot of
boilerplate code.
A couple of improvements:
1. Avoid the generally discouraged apply argument to options, as it has
quite weird semantics
2. Avoid issues when a user calls a preSwitchCheck `script`, which
would've been silently overridden by the existing implementation.
Reliance on a special attribute name like that is bound to lead to a
very-hard-to-debug problem for someone at some point
3. Use writeShellApplication so that the preSwitchChecks are checked by
shellcheck and and so that they run with basic bash guardrails
4. Fix shellcheck issue (testing the value of $?)
5. Add a positive preSwitchCheck to the nixos test, to make sure that
that works as intended
