Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
After upgrading to NixOS 20.03, I've got the following warning:
nginx: [warn] could not build optimal types_hash, you should increase either types_hash_max_size: 2048 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
The documentation states that "if nginx emits the message requesting
to increase either hash max size or hash bucket size then the first
parameter should first be increased" (aka types_hash_max_size).
In 19.03, the size of mime.types was around 100 entries. In 20.03, we
are around 900 entries. This is due to ff0148d868 which makes nginx
use mailcap mime.types.
In ff0148d868, nginx configuration was modified to use mime.types
from mailcap package as it is more complete. However, there are two
places where mime.types is included in configuration. When the user
was setting `cfg.httpConfig`, the mime.types from nginx was still
used. This commit fix that by moving the common snippet in a variable
of its own and ensure it is used at both places.
The volumeID will now be in the format of:
nixos-$EDITON-$RELEASE-$ARCH
an example for the minimal image would look like:
nixos-minimal-20.09-x86-64-linux
It's impossible to move two major-versions forward when upgrading
Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16)
and trying to upgrade to 20.03 (using Nextcloud 18 by default).
This patch implements the measurements discussed in #82056 and #82353 to
improve the update process and to circumvent similar issues in the
future:
* `pkgs.nextcloud` has been removed in favor of versioned attributes
(currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that
approach we can safely backport major-releases in the future to
simplify those upgrade-paths and we can select one of the
major-releases as default depending on the configuration (helpful to
decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be
used on 20.03 and `master` atm).
* If `system.stateVersion` is older than `20.03`, `nextcloud17` will be
used (which is one major-release behind v16 from 19.09). When using a
package older than the latest major-release available (currently v18),
the evaluation will cause a warning which describes the issue and
suggests next steps.
To make those package-selections easier, a new option to define the
package to be used for the service (namely
`services.nextcloud.package`) was introduced.
* If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to
provide more recent Nextcloud versions on older NixOS-releases), an
evaluation error will be thrown by default: this is to make sure that
`services.nextcloud.package` doesn't use an older version by accident
after checking the state-version. If `pkgs.nextcloud` is added
manually, it needs to be declared explicitly in
`services.nextcloud.package`.
* The `nixos/nextcloud`-documentation contains a
"Maintainer information"-chapter which describes how to roll out new
Nextcloud releases and how to deal with old (and probably unsafe)
versions.
Closes#82056
Dropbear lags behind OpenSSH significantly in both support for modern
key formats like `ssh-ed25519`, let alone the recently-introduced
U2F/FIDO2-based `sk-ssh-ed25519@openssh.com` (as I found when I switched
my `authorizedKeys` over to it and promptly locked myself out of my
server's initrd SSH, breaking reboots), as well as security features
like multiprocess isolation. Using the same SSH daemon for stage-1 and
the main system ensures key formats will always remain compatible, as
well as more conveniently allowing the sharing of configuration and
host keys.
The main reason to use Dropbear over OpenSSH would be initrd space
concerns, but NixOS initrds are already large (17 MiB currently on my
server), and the size difference between the two isn't huge (the test's
initrd goes from 9.7 MiB to 12 MiB with this change). If the size is
still a problem, then it would be easy to shrink sshd down to a few
hundred kilobytes by using an initrd-specific build that uses musl and
disables things like Kerberos support.
This passes the test and works on my server, but more rigorous testing
and review from people who use initrd SSH would be appreciated!
Running the manual on a TTY is useless in the graphical ISOs and not
particularly useful in non-graphical ISOs (since you can also run
'nixos-help').
Fixes#83157.
* Removed the use of gnome-screensaver (https://gitlab.gnome.org/GNOME/gnome-flashback/issues/18)
* Flashback's menu-related environment variables are now set in the gnome3.nix module instead of gnome-panel to resolve dependency conflict.
While renaming `networking.defaultMailServer` directly to
`services.ssmtp` is shorter and probably clearer, it causes eval errors
due to the second rename (directDelivery -> enable) when using e.g. `lib.mkForce`.
For instance,
``` nix
{ lib, ... }: {
networking.defaultMailServer = {
hostName = "localhost";
directDelivery = lib.mkForce true;
domain = "example.org";
};
}
```
would break with the following (rather confusing) error:
```
error: The option value `services.ssmtp.enable' in `/home/ma27/Projects/nixpkgs/nixos/modules/programs/ssmtp.nix' is not of type `boolean'.
(use '--show-trace' to show detailed location information)
```
Previously, the NixOS ACME module defaulted to using P-384 for
TLS certificates. I believe that this is a mistake, and that we
should use P-256 instead, despite it being theoretically
cryptographically weaker.
The security margin of a 256-bit elliptic curve cipher is substantial;
beyond a certain level, more bits in the key serve more to slow things
down than add meaningful protection. It's much more likely that ECDSA
will be broken entirely, or some fatal flaw will be found in the NIST
curves that makes them all insecure, than that the security margin
will be reduced enough to put P-256 at risk but not P-384. It's also
inconsistent to target a curve with a 192-bit security margin when our
recommended nginx TLS configuration allows 128-bit AES. [This Stack
Exchange answer][pornin] by cryptographer Thomas Pornin conveys the
general attitude among experts:
> Use P-256 to minimize trouble. If you feel that your manhood is
> threatened by using a 256-bit curve where a 384-bit curve is
> available, then use P-384: it will increases your computational and
> network costs (a factor of about 3 for CPU, a few extra dozen bytes
> on the network) but this is likely to be negligible in practice (in a
> SSL-powered Web server, the heavy cost is in "Web", not "SSL").
[pornin]: https://security.stackexchange.com/a/78624
While the NIST curves have many flaws (see [SafeCurves][safecurves]),
P-256 and P-384 are no different in this respect; SafeCurves gives
them the same rating. The only NIST curve Bernstein [thinks better of,
P-521][bernstein] (see "Other standard primes"), isn't usable for Web
PKI (it's [not supported by BoringSSL by default][boringssl] and hence
[doesn't work in Chromium/Chrome][chromium], and Let's Encrypt [don't
support it either][letsencrypt]).
[safecurves]: https://safecurves.cr.yp.to/
[bernstein]: https://blog.cr.yp.to/20140323-ecdsa.html
[boringssl]: https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2
[chromium]: https://bugs.chromium.org/p/chromium/issues/detail?id=478225
[letsencrypt]: https://letsencrypt.org/docs/integration-guide/#supported-key-algorithms
So there's no real benefit to using P-384; what's the cost? In the
Stack Exchange answer I linked, Pornin estimates a factor of 3×
CPU usage, which wouldn't be so bad; unfortunately, this is wildly
optimistic in practice, as P-256 is much more common and therefore
much better optimized. [This GitHub comment][openssl] measures the
performance differential for raw Diffie-Hellman operations with OpenSSL
1.1.1 at a whopping 14× (even P-521 fares better!); [Caddy disables
P-384 by default][caddy] due to Go's [lack of accelerated assembly
implementations][crypto/elliptic] for it, and the difference there seems
even more extreme: [this golang-nuts post][golang-nuts] measures the key
generation performance differential at 275×. It's unlikely to be the
bottleneck for anyone, but I still feel kind of bad for anyone having
lego generate hundreds of certificates and sign challenges with them
with performance like that...
[openssl]: https://github.com/mozilla/server-side-tls/issues/190#issuecomment-421831599
[caddy]: 2cab475ba5/modules/caddytls/values.go (L113-L124)
[crypto/elliptic]: 2910c5b4a0/src/crypto/elliptic
[golang-nuts]: https://groups.google.com/forum/#!topic/golang-nuts/nlnJkBMMyzk
In conclusion, there's no real reason to use P-384 in general: if you
don't care about Web PKI compatibility and want to use a nicer curve,
then Ed25519 or P-521 are better options; if you're a NIST-fearing
paranoiac, you should use good old RSA; but if you're a normal person
running a web server, then you're best served by just using P-256. Right
now, NixOS makes an arbitrary decision between two equally-mediocre
curves that just so happens to slow down ECDH key agreement for every
TLS connection by over an order of magnitude; this commit fixes that.
Unfortunately, it seems like existing P-384 certificates won't get
migrated automatically on renewal without manual intervention, but
that's a more general problem with the existing ACME module (see #81634;
I know @yegortimoshenko is working on this). To migrate your
certificates manually, run:
$ sudo find /var/lib/acme/.lego/certificates -type f -delete
$ sudo find /var/lib/acme -name '*.pem' -delete
$ sudo systemctl restart 'acme-*.service' nginx.service
(No warranty. If it breaks, you get to keep both pieces. But it worked
for me.)
* nixos/nixpkgs.nix: Allow just using config in system
This assertion requires system to work properly. We might not have
this in cases where the user just sets config and wants Nixpkgs to
infer system from that. This adds a default for when this happens,
using doubleFromSystem.
* parens
`$toplevel/system` of a system closure with `x86_64` kernel and `i686` userland should contain "x86_64-linux".
If `$toplevel/system` contains "i686-linux", the closure will be run using `qemu-system-i386`, which is able to run `x86_64` kernel on most Intel CPU, but fails on AMD.
So this fix is for a rare case of `x86_64` kernel + `i686` userland + AMD CPU
Previously, systemd.network.links was only respected with networkd
enabled, but it's really udev taking care of links, no matter if
networkd is enabled or not.
With our module fixed, there's no need to manually manage the text file
anymore.
This was originally applied in 3d1079a20d,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
This mirrors the behaviour of systemd - It's udev that parses `.link`
files, not `systemd-networkd`.
This was originally applied in 36ef112a47,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
Broken by 0f973e273c284a97a8dffeab7d9c0b09a88b7139 in #73533
The type of the checkReversePath option allows "strict" and "loose" as
well as boolean values.
If the host network stack is slow to start, the alertmanager fails to
start with this error message:
caller=main.go:256 msg="unable to initialize gossip mesh" err="create memberlist: Failed to get final advertise address: No private IP address found, and explicit IP not provided"
This bug can be reproduced by shutting down the network stack and
restarting the alertmanager.
Note I don't know why I didn't hit this issue with previous
alertmanager releases.
* Linkify all service options used in the code-examples.
* Demonstrated the use of `riot-web.override {}`.
* Moved the example how to configure a postgresql-database for
`matrix-synapse` to this document from the 20.03 release-notes.
Fixes some dependency ordering problems at boot time with services that
require DNS. Without Type=notify these services might be started before
stubby was ready to accept DNS requests.
The v7 series is very different.
This commit introduces the 3 packages: fahclient, fahcontrol and
fahviewer. It also rebuilds the NixOS module to map better with the new
client.
Previously the assertion passed if the kernel had support OR the
filter was *enabled*. In the case of a kernel without support, the
`checkReversePath` option defaulted to false, and then failed the
assertion.
...even when networkd is disabled
This reverts commit ce78f3ac70, reversing
changes made to dc34da0755.
I'm sorry; Hydra has been unable to evaluate, always returning
> error: unexpected EOF reading a line
and I've been unable to reproduce the problem locally. Bisecting
pointed to this merge, but I still can't see what exactly was wrong.
extraModprobeConfig could be applied too late i.e. if the driver has been
loaded in initrd, while the harddrive is still encrypted.
Using a kernelParams works in all cases however.
To quote the XDG specification:
There is a single base directory relative to which user-specific
data files should be written. This directory is defined by the\
environment variable $XDG_DATA_HOME.
Rather than adding another directory to $HOME, I think that it's better
to follow this standard to avoid a cluttered home-dir.
Running haproxy with "DynamicUser = true" doesn't really work, since
it prohibits specifying a TLS certificate bundle with limited
permissions. This revives the haproxy user and group, but makes them
dynamically allocated by NixOS, rather than statically allocated. It
also adds options to specify which user and group haproxy runs as.
Previously, systemd.network.links was only respected with networkd
enabled, but it's really udev taking care of links, no matter if
networkd is enabled or not.
With our module fixed, there's no need to manually manage the text file
anymore.
This is to facilitate units that should _only_ be manually started and
not activated when a configuration is switched to.
More specifically this is to be used by the new Nixops deploy-*
targets created in https://github.com/NixOS/nixops/pull/1245 that are
triggered by Nixops before/after switch-to-configuration is called.
When blocklists are built with a derivation, using extraHosts would
require IFD, since the result of the derivation needs to be converted to
a string again.
By introducing this option no IFD is needed for such use-cases, since
the fetched files can be assigned directly.
- Fix misspelled option. mkRenamedOptionModule is not used because the
option hasn't really worked before.
- Add missing cfg.telemetryPath arg to ExecStart.
- Fix mkdir invocation in test.
The allowed values have changed in bd3319d28c.
0.15:
--log.level="info" Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal]
--log.format="logger:stderr"
Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true"
0.17:
--log.level=info Only log messages with the given severity or above. One of: [debug, info, warn, error]
--log.format=logfmt Output format of log messages. One of: [logfmt, json]
This avoids a possible surprise if the user is using `nixpkgs.system`
and `nesting.children`. `nesting.children` is expected to ignore all
parent configuration so we shouldn't propagate the user-facing option
`nixpkgs.system`. To avoid doing so, we introduce a new internal
option for holding the value passed to eval-config.nix, and use that
when recursing for nesting.
Add a cage module to nixos. This can be used to make kiosk-style
systems that boot directly to a single application. The user (demo by
default) is automatically logged in by this service and the
program (xterm by default) is automatically started.
This is useful for some embedded, single-user systems where we want
automatic booting. To keep the system secure, the user should have
limited privileges.
Based on the service provided in the Cage wiki here:
https://github.com/Hjdskes/cage/wiki/Starting-Cage-on-boot-with-systemd
Co-Authored-By: Florian Klink <flokli@flokli.de>
* prometheus-nginx-exporter: 0.5.0 -> 0.6.0
* nixos/prometheus-nginx-exporter: update for 0.6.0
Added new option constLabels and updated virtualHost name in the
exporter's test.
Prior to this fix, changes to certain settings would not be applied
automatically and users would have to know to manually restart the
affected service. A prime example of this is
`services.mailman.hyperkitty.baseUrl`, or various things that affect
`mailman3/settings.py`
The current weekly setting causes every NixOS server to try to renew
its certificate at midnight on the dot on Monday. This contributes to
the general problem of periodic load spikes for Let's Encrypt; NixOS
is probably not a major contributor to that problem, but we can lead by
example by picking good defaults here.
The values here were chosen after consulting with @yuriks, an SRE at
Let's Encrypt:
* Randomize the time certificates are renewed within a 24 hour period.
* Check for renewal every 24 hours, to ensure the certificate is always
renewed before an expiry notice is sent out.
* Increase the AccuracySec (thus lowering the accuracy(!)), so that
systemd can coalesce the renewal with other timers being run.
(You might be worried that this would defeat the purpose of the time
skewing, but systemd is documented as avoiding this by picking a
random time.)
The current behavior lets `system` default to
`builtins.currentSystem`. The system value specified to
`eval-config.nix` has very low precedence, so this should compose
properly.
Fixes#80806
Directory mode 755 is standard for running services. Without this,
downloadDirPermissions doesn't have any use since other users can't even
look inside the main transmission directory
* nixos/gdm: Fix pulseaudio tmpfiles structure
Fix the following startup failure of the sound service in the gdm
session that was introduced by #75893:
```
Feb 16 11:44:15 qp pulseaudio[1432]: W: [pulseaudio] core-util.c: Failed to open configuration file '/run/gdm/.config/pulse//daemon.conf': Not a directory
Feb 16 11:44:15 qp pulseaudio[1432]: W: [pulseaudio] daemon-conf.c: Failed to open configuration file: Not a directory
Feb 16 11:44:15 qp systemd[1380]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Feb 16 11:44:15 qp systemd[1380]: pulseaudio.service: Failed with result 'exit-code'.
Feb 16 11:44:15 qp systemd[1380]: Failed to start Sound Service.
```
Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
Note we're not using wayland default in the graphical media because it
could cause headaches for Nvidia users. But the session is still available
if someone logs out.
lego already bundles the chain with the certificate,[1] so the current
code, designed for simp_le, was resulting in duplicate certificate
chains, manifesting as "Chain issues: Incorrect order, Extra certs" on
the Qualys SSL Server Test.
cert.pem stays around as a symlink for backwards compatibility.
[1] 5cdc0002e9/acme/api/certificate.go (L40-L44)
This reverts commit 6a756af3e7.
Currently zshenv by default only set fpath and HELPDIR without exporting them.
A parent shell would also not set those variables usually as they are shell local.
It also sources a file called set-environment but this is protected by an
environment variable called __NIXOS_SET_ENVIRONMENT_DONE. Hence any modification
done by the parent shell should persist as long as __NIXOS_SET_ENVIRONMENT_DONE
is not unset.
This behavior deviates from what we do in bashrc and breaks common setups such
as tmux/mosh or screen.
Fixes#80437
This commit fixes#76620. It moves ExecStartPre and ExecStopPost to
preStart and postStop, as these options are composable. It thus allows
adding additional initialisation scripts or cleanup scripts to the systemd
unit of the docker container.
This leads to inconsistent results between local builds and
Hydra. Also Nix is not a general purpose language, we shouldn't be
parsing .git from inside Nix code.
In 0945178b3c we decided that Perl-based
VM tests should be deprecated and will be removed between 20.03 and
20.09. So let's switch `nixos-build-vms(8)` to python as well (which is
entirely interactive, so other scripts won't break).
In my experience, the test-driver isn't used most of the time, so this
patch is mainly supposed to get rid of the (probably misleading)
deprecation warning when running `nixos-build-vms`. Apart from that, the
interface for python's test-driver is way nicer.
This option allows the user to control whether or not the docker container is
automatically started on boot. The previous default behavior (true) is preserved
* nixos/postgresql: support 0750 for data directory
This is rework of part of https://github.com/NixOS/nixpkgs/pull/46670.
My usecase was to be able to inspect PG datadir as wheel user.
PG11 now allows starting server with 0750 mask for data dir.
`groupAccess = true` now does this automatically. The only thing you have to do
is to set group ownership.
For PG10 and below, I've described a hack how this can be done. Before this PR
hack was impossible. The hack isn't ideal, because there is short
period of time when dir mode is 0700, so I didn't want to make it official.
Test/example is present too.
* postgresql: allow changing initidb arguments via module system
Closes https://github.com/NixOS/nixpkgs/issues/18829
+ some cleanups
* addressed review comments and some fixes
* whoops
* change groupAccess to tristate, to not force `chmod` on dataDir.
Making mask either 0700 or 0750 is too restrictive..
* WIP
* let's not support group mode for versions pre-11.
The only fix is to change mode to 0700 before start, because otherwise postgresql
doesn't start, and error is non-obvious.
In some cases, /dev/stderr may not point to a sensible location. For
example, running nixos-enter inside a systemd unit where the unit's
StandardOutput and StandardError are set to be sockets. In these
cases, this line would fail.
Piping to fd2 directly works just as well, even under strange and
twisted executions.
Co-authored-by: Michael Bishop <michael.bishop@iohk.io>
Originally added in [1], and iwd added StateDirectory to its services
in [2] -- 4 days later.
("StateDirectory wasn't used when tmpfile snippet was added to NixOS")
(nevermind git -> release delay)
[1] 6e54e9253a
[2] upstream iwd git rev: 71ae0bee9c6320dae0083ed8c1700bc8fff1defb
Some display managers (e.g. SDDM) set the XDG_CURRENT_DESKTOP variable accroding to this parameter.
If this variable is not defined, there will be some problems (e.g. MATE doesn't have icons on the desktop).
Fixes https://github.com/NixOS/nixpkgs/issues/71427
3c74e48d9c was a bit too much, it updated
permissions of all files recursively, causing files to be readable by
the group.
This isn't a problem immediately after bootup, but on a new activation,
as tmpfiles.d get restarted then, updating the permission bits of
now-existing files.
This updates the `Z` to be a `z` (the non-recursive variant), and adds a
`d` to ensure a directory is created (which should be covered by the
initrd shell script anyway)
Due to the support of the systemd-logind API the udev rules aren't
required anymore which renders this module useless [0].
Note: brightnessctl should now require a working D-Bus setup and a valid
local logind session for this to work.
[0]: https://github.com/NixOS/nixpkgs/pull/79663
"master" is not a valid SHA-1 commit hash, and it's not even
necessarily the branch used. 'nixos-version --revision' now returns an
error if the commit hash is not known.
Depending on the network management backend being used, if the interface
configuration in stage 1 is not cleared, there might still be some old
addresses or routes from stage 1 present in stage 2 after network
configuration has finished.
This makes predictable interfaces names available as soon as possible
with udev by adding the default network link units to initrd which are read
by udev. Also adds some udev rules that are needed but which would normally
loaded from the udev store path which is not included in the initrd.
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.
