Tracking scripts in particular, cannot be included in extraOpts, because script declaration has to be above script usage in keepalived.conf.
Changes are fully backward compatible.
This introduces an option that 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.
Aside from adding a NixOS VM test it also restructures the type of the
security.dhparams.params option, so that it's a submodule.
A new defaultBitSize option is also there to allow users to set a
system-wide default.
I added a release notes entry that described what has changed and also
included a few notes for module developers using this module, as the
first usage already popped up in NixOS/nixpkgs#39507.
Thanks to @Ekleog and @abbradar for reviewing.
Always enable both tty and serial console, but set preferred console
depending on cfg.graphical.
Even in qemu graphical mode, you can switch to the serial console via
Ctrl+Alt+3.
With that being done, you also don't need to specify
`systemd.services."serial-getty@ttyS0".enable = true;` either as described in
https://nixos.wiki/wiki/Cheatsheet#Building_a_service_as_a_VM_.28for_testing.29,
as systemd automatically spawns a getty on consoles passwd via cmdline.
This also means, vms built by 'nixos-rebuild build-vm' can simply be run
properly in nographic mode by appending `-nographic` to `result/bin/run-*-vm`,
without the need to explicitly add platform-specific QEMU_KERNEL_PARAMS.
This allows to set the default bit size for all the Diffie-Hellman
parameters defined in security.dhparams.params and it's particularly
useful so that we can set it to a very low value in tests (so it doesn't
take ages to generate).
Regardless for the use in testing, this also has an impact in production
systems if the owner wants to set all of them to a different size than
2048, they don't need to set it individually for every params that are
set.
I've added a subtest to the "dhparams" NixOS test to ensure this is
working properly.
Signed-off-by: aszlig <aszlig@nix.build>
When trying to run NSD to serve the root zone, one gets the following
error message:
error: illegal name: '.'
This is because the name of the zone is used as the derivation name for
building the zone file. However, Nix doesn't allow derivation names
starting with a period.
So whenever the zone is "." now, the file name generated is "root"
instead of ".".
I also added an assertion that makes sure the user sets
services.nsd.rootServer, otherwise NSD will fail at runtime because it
prevents serving the root zone without an explicit compile-time option.
Tested this by adding a root zone to the "nsd" NixOS VM test.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @hrdinka, @qknight
lib.optional returns a singleton or an empty list. Therefore the
argument does not need to be wrapped in a list.
An alternative patch could have used lib.optionals but seems like no
more elements are going to be added to the optional list.
This is apparent from the service file directory in plymouth:
├── multi-user.target.wants
│ ├── plymouth-quit.service -> ../plymouth-quit.service
│ └── plymouth-quit-wait.service -> ../plymouth-quit-wait.service
Leaving it unspecified caused gdm-wayland to crash on boot, see #39615.
The change made other display managers not quit plymouth properly however. By
removing "multi-user.target" from `plymouth-quit.after` this is resolved.
The following changes have been applied:
- the property `http.headers.X-Content-Type-Options` must a list of
strings rather than a serialized list
- instead of `/etc/docker/registry/config.yml` the configuration will be
written with `pkgs.writeText` and the store path will be used to run
the registry. This reduces the risk of possible impurities by relying
on the Nix store only.
- cleaned up the property paths to easy readability and reduce the
verbosity.
- enhanced the testcase to ensure that digests can be deleted as well
- the `services.docker-registry.extraConfig` object will be merged with
`registryConfig`
/cc @ironpinguin
@Ekleog writes in https://github.com/NixOS/nixpkgs/pull/39526:
> I think a default of 4096 is maybe too much? See certbot/certbot#4973;
> Let's Encrypt supposedly know what they are doing and use a
> pre-generated 2048-bit DH params (and using the same DH params as
> others is quite bad, even compared to lower bit size, if I correctly
> remember the attacks available -- because it increases by as much the
> value of breaking the group).
> Basically I don't have anything personal against 4096, but fear it may
> re-start the arms race: people like having "more security" than their
> distributions, and having NixOS already having more security than is
> actually useful (I personally don't know whether a real-size quantum
> computer will come before or after our being able to break 2048-bit
> keys, let alone 3072-bit ones -- see wikipedia for some numbers).
> So basically, I'd have set it to 3072 in order to both decrease build
> time and avoid having people setting it to 8192 and complaining about
> how slow things are, but that's just my opinion. :)
While he suggests is 3072 I'm using 2048 now, because it's the default
of "openssl dhparam". If users want to have a higher value, they can
still change it.
Signed-off-by: aszlig <aszlig@nix.build>
The ability to specify "-drive if=scsi" has been removed in QEMU version
2.12 (introduced in 3e3b39f173).
Quote from https://wiki.qemu.org/ChangeLog/2.12#Incompatible_changes:
> The deprecated way of configuring SCSI devices with "-drive if=scsi"
> on x86 has been removed. Use an appropriate SCSI controller together
> "-device scsi-hd" or "-device scsi-cd" and a corresponding "-blockdev"
> parameter instead.
So whenever the diskInterface is "scsi" we use the new way to specify
the drive and fall back to the deprecated way for the time being. The
reason why I'm not using the new way for "virtio" and "ide" as well is
because there is no simple generic way anymore to specify these.
This also turns the type of the virtualisation.qemu.diskInterface option
to be an enum, so the user knows which values are allowed but we can
also make sure the right value is provided to prevent typos.
I've tested this against a few non-disk-related NixOS VM tests but also
the installer.grub1 test (because it uses "ide" as its drive interface),
the installer.simple test (just to be sure it still works with
"virtio") and all the tests in nixos/tests/boot.nix.
In order to be able to run the grub1 test I had to go back to
8b1cf100cd (which is a known commit where
that test still works) and apply the QEMU update and this very commit,
because right now the test is broken.
Apart from the tests here in nixpkgs, I also ran another[1] test in
another repository which uses the "scsi" disk interface as well (in
comparison to most of the installer tests, this one actually failed
prior to this commit).
All of them now succeed.
[1]: 9b5a119972/tests/system/kernel/bfq.nix
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edostra, @grahamc, @dezgeg, @abbradar, @ts468
Previously the script would contain an empty `if` block (which is invalid
syntax) if both `data.activationDelay == null` and `data.postRun == ""`. Fix
this by adding a no-op `true`.
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
mke2fs has this annoying property that it uses getrandom() to get random
numbers (for whatever purposes) which blocks until the kernel's secure
RNG has sufficient entropy, which it usually doesn't in the early boot
(except if your CPU supports RDRAND) where we may need to create the
root disk.
So let's give the VM a virtio RNG to avoid the boot getting stuck at
mke2fs.
Ubiquiti has both a LTS and current version of their Unifi controller software.
The latter adds new features, but may drop support for some devices.
This adds the capability to use either for the unifi module but defaults
to the LTS version, which was the previous behavior.
Previously we indirectly suggested that the user use
services.printing.extraConf to set this, but this doesn't work with the
default merge ordering. Fix this by making it an independent option.
Fixes#39611.
@cleverca found this bug in the declarative hooks config. Any shell
variables referenced in a hook script would get expanded by the hooks
directory builder.
Prevent variable expansion by quoting the here doc limit string.
Allow out of band communication between qemu VMs and the host.
Useful to retrieve IPs of VMs from the host (for instance when libvirt can't analyze
DHCP requests because VMs are configured with static addresses or when
there is connectivity default).
First of all let's start with a clean up the multiline string
indentation for descriptions, because having two indentation levels
after description is a waste of screen estate.
A quick survey in the form of the following also reveals that the
majority of multiline strings in nixpkgs is starting the two beginning
quotes in the same line:
$ find -name '*.nix' -exec sed -n -e '/=$/ { n; /'\'\''/p }' {} + | wc -l
817
$ find -name '*.nix' -exec grep "= *'' *\$" {} + | wc -l
14818
The next point is to get the type, default and example attributes on top
of the description because that's the way it's rendered in the manual.
Most services have their enable option close to the beginning of the
file, so let's move it to the top.
Also, I found the script attribute for dhparams-init.service a bit hard
to read as it was using string concatenation to split a "for" loop.
Now for the more substantial clean ups rather than just code style:
* Remove the "with lib;" at the beginning of the module, because it
makes it easier to do a quick check with "nix-instantiate --parse".
* Use ConditionPathExists instead of test -e for checking whether we
need to generate the dhparams file. This avoids spawning a shell if
the file exists already and it's probably more common that it will
exist, except for the initial creation of course.
* When cleaning up old dhparams file, use RemainAfterExit so that the
unit won't be triggered again whenever we stop and start a service
depending on it.
* Capitalize systemd unit descriptions to be more in par with most
other unit descriptions (also see 0c5e837b66).
* Use "=" instead of "==" for conditionals using []. It's just a very
small nitpick though and it will only fail for POSIX shells. Bash on
the other side accepts it anyway.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
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
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
