This option allows us to turn off stateful generation of Diffie-Hellman
parameters, which in some way is still stateful as the generated DH
params file is non-deterministic.
However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.
Another advantage of this is that we no longer need to take care of
cleaning up the files that are no longer used and in my humble opinion I
would have preferred that #11505 (which puts the dhparams in the Nix
store) would have been merged instead of #22634 (which we have now).
Luckily we can still change that and this change gives the user the
option to put the dhparams into the Nix store.
Beside of the more obvious advantages pointed out here, this also
effects test runtime if more services are starting to use this (for
example see #39507 and #39288), because generating DH params could take
a long time depending on the bit size which adds up to test runtime.
If we generate the DH params in a separate derivation, subsequent test
runs won't need to wait for DH params generation during bootup.
Of course, tests could still mock this by force-disabling the service
and adding a service or activation script that places pre-generated DH
params in /var/lib/dhparams but this would make tests less readable and
the workaround would have to be made for each test affected.
Note that the 'stateful' option is still true by default so that we are
backwards-compatible with existing systems.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog, @abbradar, @fpletz
We're going to implement an option which allows us to turn off stateful
handling of Diffie-Hellman parameter files by putting them into the Nix
store.
However, modules now might need a way to reference these files, so we
add a now path option to every param specified, which carries a
read-only value of the path where to find the corresponding DH params
file.
I've also improved the description of security.dhparams.params a bit so
that it uses <warning/> and <note/>.
The NixOS VM test also reflects this change and checks whether the old
way to specify the bit size still works.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
We're going to make changes to the dhparams module so we really want to
make sure we don't break it, so having a NixOS VM test is to make sure
we don't blow things up and can iterate on it.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
xdotool failed in rare cases when a window was already created
but not yet decorated by the window manager.
also prevent a (never observed but possible) race condition
I know that "devinfo" output does not currently exist, but so does "devman".
It is mentioned in the nixpkgs manual, but no derivation in nixpkgs actually uses it.
HA doesn't mind the configuration being JSON instead of YAML but since YAML is
the official language, use that as it allows users to easily exchange config
data with other parties in the community.
Additionally, some settings based on NixOS configuation is set via defaultConfig
which is then merged with the user provided configration.
For now that just means http port and time zone but others can easily be added.
This partially reverts a change from e88f28965a
which removed the `mount --rbind /sys`.
While true that the activation scripts will mount `sysfs` at `/sys`,
none of the mountpoints lower in the `/sys` tree are handled by the
activation script, which includes `efivarfs`.
This fixes#38477 since it ensures the presence of `efivarfs` in the
`/sys` tree, which is why the systemd-boot installation failed.
This is more in line with what other services do; also looks cleaner.
It changes configuration entries for pre-and post-hooks type to lines from
lists of strings which are more logical for them; coersion is provided for
backwards compatibility.
Finally, add several steps to improve robustness:
1. Load kernel module on start if not loaded;
2. Don't remove wireguard interface on start; it is removed on service stop. If
it's not something is wrong.
