It was easy to accidentally trigger infinite recursion if you depended
on `toplevel` in any way before. For instance, if you used
`CopyBlocks` with an image containing `toplevel`. This was because
`toplevel`'s assertion / warning logic has to be evaluated, but that
means evaluating `image.repart`'s assertions / warnings, which
requires evaluating the `repartConfig` attrsets to check for malformed
`Label`s. That causes the module system to type check *all*
`repartConfig` keys, even though most of them aren't used in the
assertions / warnings. So evaluating `system.build.image` evaluates
`repartConfig.CopyBlocks`, which evaluates `toplevel`, which evaluates
assertions / warnings, which evaluates `repartConfig.CopyBlocks` to
type check it. Infinite loop.
Even ignoring this recursion problem, it's still better for the repart
module to have its own assertions / warnings options. You don't have
to use `toplevel` in a repart image, so its assertions / warnings
would have been ignored in that case anyway. This way they're *always*
checked when you build an image.
Right now it wrongly seems as if you can set
`sshBackdoor.enable = true;` for each test and not only for debugging
purposes.
This is wrong however since you'd need to pass /dev/vhost-vsock into the
sandbox for this (which is also a prerequisite for #392117).
To make that clear, two things were changed:
* add a warning to the manual to communicate this.
* exit both interactive and non-interactive driver early if
/dev/vhost-vsock is missing and the ssh backdoor is enabled.
If that's the case, we pass a CLI flag to the driver already in the
interactive case. This change also sets the flag for the
non-interactive case.
That way we also get a better error if somebody tries to enable this
on a system that doesn't support that.
The current workflow for starting the `linux-builder` on macOS is to run
`nix run nixpkgs#darwin.linux-builder`, which adds keys to the store and
then starts the builder.
Adding the keys requires user input (due to `sudo`) but the actual
builder should just stay running in the background somewhere.
I'd like to automate this process, but it's currently rather complex:
the first part of the script needs user input for `sudo`, and then
there's no signal when the process has finished starting up. The user
will need to see stdout/stderr during the first part, which makes it
challenging to capture it for the second part to determine when startup
has finished.
To fix this, I've split the `create-builder` script into an `add-keys`
script (interactive) and a `run-builder` script (background). These new
scripts are exposed in the `passthru` attributes for external users. The
`create-builder` script is now a simple call of `add-keys` and then
`run-builder`.
See: https://nixos.org/manual/nixpkgs/unstable/#sec-darwin-builder
lib/test.nix relies on `fileset.toSource` which creates a source dir
with the files of interest. `testers.shellcheck` passes all the files in
the source dir to shellcheck. The issue is related to relative path
sourcing, i.e. `source ./lib.sh` where shellcheck cannot make any
assumptions about the working directory.
Options were:
1) Disable this warning with a directive
Prior disabling in the tree:
- pkgs/tools/nix/info/info.sh
- nixos/modules/testing/test-instrumentation.nix
2) Set source-path to SCRIPTDIR with a directive
https://github.com/koalaman/shellcheck/wiki/Directive#source-path
Even though we don't enable external script following for shellcheck
with `-x` flag given every file in the source dir is passed, this
directive seems to capture the intent to help shellcheck a bit
better.
Went with option 2.
Services utilising postsrsd need to connect to it via a Unix socket.
While the path to that socket is static as of now, the discoverability
of that path suffers from the lack of module documentation and a
scattered definition of the individual path components over at least
three lines, even when reading the module source.
By exposing the socket path as a readOnly NixOS option, that value shows
up in the options overview and can be re-used in other parts of NixOS
config.
While we're not (fully) supporting the related features, yet, we already
prevent accidental storage of secrets in the store. This will also avoid
breaking changes in the future, when those features are properly
supported.
