The pkgs.nixos used to only expose system.build, which kind of made
sense in theory, but asking everyone to write modules when to want
to pull something out of a NixOS configuration is just not realistic.
In fact it's very inconvenient when you're trying to debug something.
This adds the config, options and anything that eval-config.nix
produces. Although this introduces the potential for attributes
of eval-config.nix output to shadow system.build, I don't expect
naming collisions to be commonplace, or to remain undetected during
evaluation. Also such an error should be easy to resolve, by explicitly
querying (pkgs.nixos {}).config.system.build.X, or by renaming X
to something other than config, options, extraArgs.
Passwords should not be stored in plain text by default. On existing
installations the next time a users user accounts will automatically
be upgraded from plain to hashed one-by-one as they log in.
since 2.8.5, shairport-sync uses the directory path sysconfdir to
determine where to place the configuration file shairport-sync.conf.
This led to shairport-sync complaining at startup:
> configuration file name "/nix/store/i8gb0hsb2zczdl8g1h73pbcb952585l9-shairport-sync-3.2.2/etc/shairport-sync.conf" can not be resolved.
Looking for a configuration file there doesn't make much sense, as we'd
have to include configuration in the shairport-sync derivation itself.
By setting sysconfdir to /etc/, shairport-sync will try to read its
configuration from /etc/shairport-sync.conf, which is a more sane
default.
With `sshd -t` config validation for SSH is possible. Until now, the
config generated by Nix was applied without any validation (which is
especially a problem for advanced config like `Match` blocks).
When deploying broken ssh config with nixops to a remote machine it gets
even harder to fix the problem due to the broken ssh that makes reverts
with nixops impossible.
This change performs the validation in a Nix build environment by
creating a store path with the config and generating a mocked host key
which seems to be needed for the validation. With a broken config, the
deployment already fails during the build of the derivation.
The original attempt was done in #56345 by adding a submodule for Match
groups to make it harder screwing that up, however that made the module
far more complex and config should be described in an easier way as
described in NixOS/rfcs#42.
For some Go projects a go.mod file is included but there are no listed
dependencies. When this is encountered the Go toolchain will not create
a cache folder for downloaded dependencies which causes buildGoModule to
fail.
An example of a project like this that is widely used is:
https://github.com/golang/protobuf
This commit adds a mkdir command to ensure that the directory always
exists so it can be copied and prevent the failure.
