invalid test was introduced in 297d1598ef
and it is disabled in the shipped daemon.conf.
I forgot to reflect that in the module, which caused the daemon to print the following on start-up:
FuEngine invalid has incorrect built version invalid
and the command to warn:
WARNING: The daemon has loaded 3rd party code and is no longer supported by the upstream developers!
To reduce the change of this happening in the future, I moved the list of default disabled plug-ins to the package expression.
I also set the value of the NixOS module option in the config section of the module instead of the default value used previously,
which will allow users to not care about these plug-ins.
We switched to unified default session option services.xserver.displayManager.defaultSession
and included fallback path for the legacy options. Unfortunately when only
services.xserver.windowManager.default is set and not services.xserver.desktopManager.default,
it got incorrectly converted to the new option.
This should fix that.
Closes: https://github.com/NixOS/nixpkgs/issues/76684
NixOS has `virtualisation.docker.autoPrune.enable` for this
functionality; we should not do it every time a container starts up.
(also, some trivial documentation fixes)
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Memtest86+ doesn't support EFI, so unfree Memtest86 is used when EFI
support is enabled (systemd-boot currently also uses Memtest86 when
memtest is enabled).
boot.specialFileSystems is used to describe mount points to be set up in
stage 1 and 2.
We use it to create /run/keys already there, so sshd-in-initrd scenarios
can consume keys sent over through nixops send-keys.
However, it seems the kernel only supports the gid=… option for tmpfs,
not ramfs, causing /run/keys to be owned by the root group, not keys
group.
This was/is worked around in nixops by running a chown root:keys
/run/keys whenever pushing keys [1], and as machines had to have pushed keys
to be usable, this was pretty much always the case.
This is causing regressions in setups not provisioned via nixops, that
still use /run/keys for secrets (through cloud provider startup scripts
for example), as suddenly being an owner of the "keys" group isn't
enough to access the folder.
This PR removes the defunct gid=… option in the mount script called in
stage 1 and 2, and introduces a tmpfiles rule which takes care of fixing
up permissions as part of sysinit.target (very early in systemd bootup,
so before regular services are started).
In case of nixops deployments, this doesn't change anything.
nixops-based deployments receiving secrets from nixops send-keys in
initrd will simply have the permissions already set once tmpfiles is
started.
Fixes#42344
[1]: 884d6c3994/nixops/backends/__init__.py (L267-L269)
* Fix documentation example for `jupyter.kernels`
The environment variable loading fails when using the example for `kernels` config, due to incorrect syntax. The error being something along the lines of `path not found`.
Thanks to @Infinisil and @layus for suggestions.
Minor incompatibilities due to moving to upstream defaults:
- capabilities are used instead of systemd.socket units
- the control socket moved:
/run/kresd/control -> /run/knot-resolver/control/1
- cacheDir moved and isn't configurable anymore
- different user+group names, without static IDs
Thanks Mic92 for multiple ideas.
Previously, some files were copied into the Nixpkgs tree, which meant
we wouldn't easily be able to update them, and was also just messy.
The reason it was done that way before was so that a few NixOS
options could be substituted in. Some problems with doing it this way
were that the _package_ changed depending on the values of the
settings, which is pretty strange, and also that it only allowed those
few settings to be set.
In the new model, mailman-web is a usable package without needing to
override, and I've implemented the NixOS options in a much more
flexible way. NixOS' mailman-web config file first reads the
mailman-web settings to use as defaults, but then it loads another
configuration file generated from the new services.mailman.webSettings
option, so _any_ mailman-web Django setting can be customised by the
user, rather than just the three that were supported before. I've
kept the old options, but there might not really be any good reason to
keep them.
We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
It's likely that a user might want to set multiple values for
relay_domains, transport_maps, and local_recipient_maps, and the order
is significant. This means that there's no good way to set these
across multiple NixOS modules, and they should probably all be set
together in the user's Postfix configuration.
So, rather than setting these in the Mailman module, just make the
Mailman module check that the values it needs to occur somewhere, and
advise the user on what to set if not.
This replaces all Mailman secrets with ones that are generated the
first time the service is run. This replaces the hyperkittyApiKey
option, which would lead to a secret in the world-readable store.
Even worse were the secrets hard-coded into mailman-web, which are not
just world-readable, but identical for all users!
services.mailman.hyperkittyApiKey has been removed, and so can no
longer be used to determine whether to enable Hyperkitty. In its
place, there is a new option, services.mailman.hyperkitty.enable. For
consistency, services.mailman.hyperkittyBaseUrl has been renamed to
services.mailman.hyperkitty.baseUrl.
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
This module allows root autoLogin, so we would break that for users, but
they shouldn't be using it anyways. This gives the impression like auto
is some special display manager, when it's just lightdm and special pam
rules to allow root autoLogin. It was created for NixOS's testing
so I believe this is where it belongs.
- the `imageFile` option allows to load an image from a derivation
- the `dependsOn` option can be used to specify dependencies between container systemd units.
Co-authored-by: Christian Höppner <mkaito@users.noreply.github.com>
