Currently, this uses the somewhat crude method of setting LD_PRELOAD in the
system environment. This works, but should be considered a stepping stone to
a more robust solution.
following up #59148
I forgot the default case of the architectures which do not have minor brothers whose code they can run ("westmere" or any of of AMD)
I was pointed towards a small syntax error in the `nixpkgs.overlays`
documentation. There was a trailing semicolon after the overlay
function.
I also aligned the code a bit better so opening and closing brackets can
be visually matched much better (IMO).
https://humdi.net/vnstat/CHANGES
* enable tests
* add hardening options from upstream's
example service
* fix "documentation" setting in service:
either needs to be `unitConfig.Documentation`
(uppercase) or lowercase but not within unitConfig.
Previously, if you, for example, set
services.xserver.displayManager.sddm.enable, but forgot to set
services.xserver.enable, you would get an error message that looked like
this:
error: attribute 'display-manager' missing
Which was not particularly helpful.
Using assertions, we can make this message much better.
The type of ZNC's config option specifies that a configuration like
config.User.paul = null;
should be valid, which is useful for clearing/disabling property sets
like Users and Networks. However until now the config generator
implementation didn't actually cover null values, meaning you'd get an
error like
error: value is null while a set was expected, at /foo.nix:29:10
This fixes the implementation to correcly allow clearing of property
sets.
The kubeconfig provided to the kubernetes-control-plane-online.service
is invalid. However, the apiserver /healthz endpoint can be accessed without auth so it's
simpler to just use curl for that.
The two directories KDB and PTree do not exist before the SKS DB is
build for the first time. If /var/db/sks is empty and the module is
enabled via "services.sks.enable = true;" the following error will
occur:
...-unit-script-sks-db-pre-start[xxx]:
ln: failed to create symbolic link 'KDB/DB_CONFIG': No such file or directory
To avoid this both links have to be created after the DB is build.
Note: Creating the directories manually might be better but the initial
build might be skipped as a result:
unit-script-sks-db-pre-start[xxxxx]: KeyDB directory already exists. Exiting.
unit-script-sks-db-pre-start[xxxxx]: PTree directory already exists. Exiting.
This change was only a temporary workaround and isn't required anymore,
since /etc/systemd/system/system.slice should not be present on any
recent NixOS system (which makes this change a no-op).
This reverts commit 7098b0fcdf.
This change will load all configuration files from /etc, to make it easy
to override them, but fallback to /nix/store/.../etc/sway/config to make
Sway work out-of-the-box with the default configuration on non NixOS
systems.
Unfortunately the changes in ab5dcc7068
introduced a typo (took me a while to spot that...) that broke the
whole module (or at least the sks-db systemd unit).
The systemd unit was failing with the following error message:
...-unit-script-sks-db-pre-start[xxx]: KDB/DB_CONFIG exists but is not a symlink.
The build error has been introduced by 56dcc319cf.
Using a <simplesect/> within a <para/> is not allowed and subsequently
fails to validate while building the manual.
So instead, I moved the <simplesect/> further down and outside of the
<para/> to fix this.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @aaronjanse, @Lassulus, @danbst
The default config of i3 provides a key binding to reload, so changes
take effect immediately:
```
bindsym $mod+Shift+c reload
```
Unfortunately the current module uses the store path of the `configFile`
option. So when I change the config in NixOS, a store path will be
created, but the current i3 process will continue to use the old one,
hence a restart of i3 is required currently.
This change links the config to `/etc/i3/config` and alters the X
startup script accordingly so after each rebuild, the config can be
reloaded.
This allows configuring IP addresses on a tinc interface using
networking.interfaces."tinc.${n}".ipv[46].addresses.
Previously, this would fail with timeouts, because of the dependency
chain
tinc.${netname}.service
--after--> network.target
--after--> network-addresses-tinc.${n}.service (and network-link-…)
--after--> sys-subsystem-net-devices-tinc.${n}.device
But the network interface doesn't exist until tinc creates it! So
systemd waits in vain for the interface to appear, and by then the
network-addresses-* and network-link-* units have failed. This leads
to the network link not being brought up and the network addresses not
being assigned, which in turn stops tinc from actually working.
