It looks like the test sshd key can never be used, because of too open
permissions. My guess is that the current test script works fine once
the user defined ssh-key has been copied into initrd.
At "nixos-install" however, the user specified host key is not present
in initrd yet and validation fails.
fixes#91486
Otherwise, stage-2-init.sh will complain about not having access to
/dev/fd/62 as of systemd v246.
On IRC, flokli said:
15:14 <flokli> cole-h: hmmm... I could imagine some of the setup inside /dev has been moved into other parts of systemd
15:14 <flokli> And given we run systemd much later (outside initramfs only) it doesn't work properly here
15:17 <flokli> We probably don't invoke udev correctly
This is a temporary fix for #97433. A more proper fix has been
implemented upstream in systemd/systemd#17001, however until it gets
backported, we are stuck with ignoring the error.
After the backport lands, this commit should be reverted.
For UEFI setups, "device" will generally be the special value "nodev"
which represents not running grub-install at all. Using "nodev" for
boot mirrors should therefore be allowed.
The commit enforces buildPackages in the builder but neglects
the fact that the builder is intended to run on the target system.
Because of that, the builder will fail when remotely building a
configuration eg. with nixops or nix-copy-closure.
This reverts commit a6ac6d00f9.
The cyclic dependency of systemd → cryptsetup → lvm2 → udev=systemd
needs to be broken somewhere. The previous strategy of building
cryptsetup with an lvm2 built without udev (#66856) caused the
installer.luksroot test to fail. Instead, build lvm2 with a udev built
without cryptsetup.
Fixes#96479.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This allows the user to configure systemd tmpfiles.d via
`environment.etc."tmpfiles.d/X.conf".text = "..."`, which after #93073
causes permission denied (with new X.conf):
```
ln: failed to create symbolic link '/nix/store/...-etc/etc/tmpfiles.d/X.conf': Permission denied
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
or collision between environment.etc and systemd-default-tmpfiles
packages (with existing X.conf, such as tmp.conf):
```
duplicate entry tmpfiles.d/tmp.conf -> /nix/store/...-etc-tmp.conf
mismatched duplicate entry /nix/store/...-systemd-246/example/tmpfiles.d/tmp.conf <-> /nix/store/...-etc-tmp.conf
builder for '/nix/store/...-etc.drv' failed with exit code 1
```
Fixes#96755
declare -a is not sufficient to make the array variable actually
exist, which resulted in the script failing when the target object did
not have any DT_NEEDED entries. This in turn resulted in some
initramfs libraries not having their rpaths patched to point to
extra-utils, which in turn broke the extra-utils tests.
symlinkJoin can break (silently) when the passed paths contain symlinks
to directories. This should work now.
Down-side: when lib/tmpfiles.d doesn't exist for some passed package,
the error message is a little less explicit, because we never get
to the postBuild phase (and symlinkJoin doesn't provide a better way):
/nix/store/HASH-NAME/lib/tmpfiles.d: No such file or directory
Also, it seemed pointless to create symlinks for whole package trees
and using only a part of the result (usually very small part).
These are now only installed by systemd if HAVE_SYSV_COMPAT is true,
which only is the case if you set sysvinit-path and sysvrcnd-path (which
we explicitly unset in the systemd derivation for quite some time)
From the systemd release notes:
nss-mymachines lost support for resolution of users and groups, and now
only does resolution of hostnames. This functionality is now provided by
nss-systemd. Thus, the 'mymachines' entry should be removed from the
'passwd:' and 'group:' lines in /etc/nsswitch.conf (and 'systemd' added
if it is not already there).
Since systemd 246, these are only installed by systemd if
HAVE_SYSV_COMPAT is true, which only is the case if you set
sysvinit-path and sysvrcnd-path (which we explicitly unset in the
systemd derivation for quite some time)
There's a circular dependency to systemd via cryptsetup and lvm2
(systemd -> cryptsetup -> lvm2 -> udev=systemd).
However, cryptsetup only really needs the devmapper component shipped
with lvm2. So build `pkgs.cryptsetup` with a lvm2 that doesn't come with
udev.
- Give a more accurate description of how fileSystems.<name/>.neededForBoot
works
- Give a more detailed description of how fileSystems.<name/>.encrypted.keyFile
works
This lets users do sneaky things before systemd starts, and
permanently affect the environment in which systemd runs. For example,
we could start systemd in a non-default network namespace by setting
the systemdExecutable to a wrapper script containing:
#!/bin/sh
ip netns add virtual
touch /var/run/netns/physical
mount -o bind /proc/self/ns/net /var/run/netns/physical
exec ip netns exec virtual systemd
_note: the above example does literally work, but there are unresolved
problems with udev and dhcp._
Fixes error
Can't use an undefined value as an ARRAY reference at /nix/store/...-install-grub.pl line 642, <FILE> line 5.
with `/boot/grub/state` being:
```
grub
2.04
no
/dev/sda
/boot
```
I am not sure where the trailing empty line can come from; the script does not
seem to write it. In any case, now we handle that situation as well.
Further, ensure that `extraGrubInstallArgs` defaults to the empty array
if its key is not present in the `jsonState`.
For example, turns the error
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot
into the more useful
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot: Read-only file system
Useful for when you need to build grub modules into your grub kernel
to get a working boot, as shown in the added example.
To store this new value, we switch to more structural JSON approach.
Using one line per value to store in `/boot/grub/state` gets really messy when
the values are arrays, or even worse, can contain newlines (escaping would be
needed). Further, removing a value from the file would get extra messy
(empty lines we'd have to keep for backwards compatibility).
Thus, from now on we use JSON to store all values we'll need in the future.
nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs
The module in this commit adds new options that allows the
integration of an OpenVPN client into the initrd.
This can be used e.g. to remotely unlock LUKS devices.
This commit also adds two tests for `boot.initrd.network.openvpn`.
The first one is a basic test to validate that a failing connection
does not prevent the machine from booting.
The second test validates that this module actually creates a valid
openvpn connection.
For this, it spawns three nodes:
- The client that uses boot.initrd.network.openvpn
- An OpenVPN server that acts as gateway and forwards a port
to the client
- A node that is external to the OpenVPN network
The client connects to the OpenVPN server and spawns a netcat instance
that echos a value to every client.
Afterwards, the external node checks if it receives this value over the
forwarded port on the OpenVPN gateway.
This can be used to explicitly specify a specific dtb file, relative to
the dtb base.
Update the generic-extlinux-compatible module to make use of this option.
Some bootloaders might not properly detect the model.
If the specific model is known by configuration, provide a way to
explicitly point to a specific dtb in the extlinux.conf.
This option exposes the builder command used to populate an image,
honoring all options except the -c <path-to-default-configuration>
argument.
Useful to have for sdImage.populateRootCommands.
Special care needs to be taken w.r.t cross - the populate command runs
on the host platform, the activation script on the build platform (so
the builders differ)
Turns out, #75510 was too restrictive.
We also need to allow str here, as some modules set this to
"/run/wrappers" to bring `/run/wrappers/bin` into $PATH of a unit.
Upstream has this alias too; so that dbus activation works.
What I don't fully understand is why this would ever be useful given
this unit is already started way in early boot; even before dbus is up.
But lets just keep behaviour similar to upstream and then ask these
questions to upstream.
With this systemd buffers netlink messages in early boot from the kernel
itself; and passes them on to networkd for processing once it's started.
Makes sure no routing messages are missed.
Also makes an alias so that dbus can activate this unit. Upstream has
this too.
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
The way this ends up being called with the raspberry pi 4 image builder
ends up not using the `-e` from the shebang.
In turn, the builds fails during cross-compilation. The wrong coreutils
ends up being used, but this is not made apparent.
The issue I faced is already fixed on master, but this ensures no one
ends up with a failed build "succeeding".
Also, remove the dangling systemd.services.systemd-binfmt.wants = [
"proc-sys-fs-binfmt_misc.mount" ]; in systemd.nix.
If boot.binfmt.registrations != {}, systemd will install
proc-sys-fs-binfmt_misc.automount, which will auto-mount
`/proc/sys/fs/binfmt_misc` as soon as systemd-binfmt tries to access it.
Fixes https://github.com/NixOS/nixpkgs/issues/87687
Fixes https://github.com/NixOS/nixops/issues/574
A disabled nscd breaks nss module loading on NixOS, and systemd without
its nss modules doesn't really work either - instead of silently
disabling its nss modules if nscd is disabled, let the assertion in
nsswitch handle this.
nixos/modules/config/nsswitch.nix uses `passwdArray` for both `passwd`
and `group`, but when moving this into the systemd module in
c0995d22ee, it didn't get split
appropriately.
This will make dbus socket activation for it work
When `systemd-resolved` is restarted; this would lead to unavailability
of DNS lookups. You're supposed to use DBUS socket activation to buffer
resolved requests; such that restarts happen without downtime
This reverts commit 764c8203b8.
While this is desireable in principle, some of our modules and services
fail during service startup if no network is available don't currently
properly set Wants=network-online.target.
If nothing pulls in this target anymore, systemd won't try to reach it.
We have many VM tests waiting for `network-online.target`, and after
764c8203b8 fail with the following error
message:
```
error: unit "network-online.target" is inactive and there are no pending jobs
```
Most likely, test scripts shouldn't wait for `network-online.target` in
first place (as `network-online.target` says nothing about whether a
service has been started), but instead, the script should wait for the
network ports of the corresponding service to be open.
Let's revert this for now, and re-apply in a draft PR, fixing the tests
before merging it back in.
This follows upstreams change in documentation. While the `[DHCP]`
section might still work it is undocumented and we should probably not
be using it anymore. Users can just upgrade to the new option without
much hassle.
I had to create a bit of custom module deprecation code since the usual
approach doesn't support wildcards in the path.
You can now specify option for the `[DHCPv6]` section with
`systemd.network.<name>.dhcpV6Config.…`. Previously you could only use
the combined legacy DHCP configuration.
Systemd upstream has deprecated CriticalConnection with v244 in favor of
KeepConnection as that seems to be more flexible:
The CriticalConnection= setting in .network files is now deprecated,
and replaced by a new KeepConfiguration= setting which allows more
detailed configuration of the IP configuration to keep in place.
Not all systems need to be online to boot up. So, don’t pull
network-online.target into multi-user.target. Services that need
online network can still require it.
This increases my boot time from ~9s to ~5s.
1d61efb7f1 accidentially changed the
restartTriggers of systemd-networkd.service` to point to the attribute
name (in this case, a location relative to `/etc`), instead of the
location of the network-related unit files in the nix store.
This caused systemd-networkd to not get restarted on activation of new
networking config, if the file name hasn't changed.
Fix this, by pointing this back to the location in the nix store.
Add a distinctive `unit-script` prefix to systemd unit scripts to make
them easier to find in the store directory. Do not add this prefix to
actual script file name as it clutters logs.
Current journal output from services started by `script` rather than
`ExexStart` is unreadable because the name of the file (which journalctl
records and outputs) quite literally takes 1/3 of the screen (on smaller
screens).
Make it shorter. In particular:
* Drop the `unit-script` prefix as it is not very useful.
* Use `writeShellScriptBin` to write them because:
* It has a `checkPhase` which is better than no checkPhase.
* The script itself ends up having a short name.
systemd-tmpfiles will load all files in lexicographic order and ignores rules
for the same path in later files with a warning Since we apply the default rules
provided by systemd, we should load user-defines rules first so users have a
chance to override defaults.
Commit 1d2c3279311e4f03fcf164e1366f2fda9f4bfccf in the upstream kernel
repository removed support for the scalar x86_64 and i586 AES
assembly implementations, since the generic AES implementation generated
by the compiler is faster for both platforms. Remove the modules from
the cryptoModules list. This causes a regression for kernel versions
>=5.4 which include the removal. This should have no negative impact on
AES performance on older kernels since the generic implementation should
be faster there as well since the implementation was hardly touched from
its initial submission.
Fixes#84842
In contrast to `.service`-units, it's not possible to declare an
`overrides.conf`, however this is done by `generateUnits` for `.nspawn`
units as well. This change breaks the build if you have two derivations
configuring one nspawn unit.
This will happen in a case like this:
``` nix
{ pkgs, ... }: {
systemd.packages = [
(pkgs.writeTextDir "etc/systemd/nspawn/container0.nspawn" ''
[Files]
Bind=/tmp
'')
];
systemd.nspawn.container0 = {
/* ... */
};
}
```
This option allows replacing the tmpfs mounted on / by
the live CD's init script with a physical device
Since nixOS symlinks everything there's no trouble
at all.
That enables the user to easily use a nixOS live CD
as a portable installation.
Note that due to some limitations in how the store is mounted
currently only the non-store things are persisted.
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!
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.
...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.
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.
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).
In some cases like we've noticed in https://github.com/NixOS/nixpkgs/issues/76169,
having duplicate packages in systemd.packages like
```
systemd.packages = [ gnome-shell gnome-shell gnome-session ];
```
breaks.
Here we use an associative array to ensure no
duplicate paths when we symlink all the units listed
in systemd.packages.
This fixes the dhcpcd issue in https://github.com/NixOS/nixpkgs/issues/76969,
which was exposed by https://github.com/NixOS/nixpkgs/pull/75031
introducing changes in the module ordering and therefore option ordering
too.
The dhcpcd issue would also be fixable by explicitly putting
dhcpcd's paths before others, however it makes more sense for systemd's
default paths to be after all others by default, since they should only
be a fallback, which is how binary finding will work if they come after.
When using a modified systemd-package (e.g. to test a patch), it's
recommended to use the `systemd.package`-option to avoid rebuilding all packages
that somehow depend on systemd.
With this change, the modified package is also used by `systemd-nspawn@`
units.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
The options at `systemd.network` (`links`, `netdevs` and `networks`) are
directly mapped to the three different unit types of `systemd-networkd(8)`.
However there's also the option `systemd.network.units` which is
basically used as a container for generated unit-configs that are linked
to `/etc/systemd/networkd`[1].
This should not be exposed to the user as it's unclear whether or not it
should be used directly which can be pretty confusing which is why I decided to
declare this option as internal (including all sub-options as `internal`
doesn't seem to be propagated to submodules).
[1] 9db75ed88f/nixos/modules/system/boot/networkd.nix (L933-L937)
This adds an `extraConfig` option to timesyncd for setting additional
options in `/etc/systemd/timesyncd.conf`.
This is similar to things like `services.journald.extraConfig` and
`services.logind.extraConfig`.
This has been there since v209 [1]
```
The interface name to use. This option has lower precedence than NamePolicy=, so for this setting to take effect, NamePolicy= must either be unset, empty, disabled, or all policies configured there must fail. Also see the example below with "Name=dmz0".
Note that specifying a name that the kernel might use for another interface (for example "eth0") is dangerous because the name assignment done by udev will race with the assignment done by the kernel, and only one interface may use the name. Depending on the order of operations, either udev or the kernel will win, making the naming unpredictable. It is best to use some different prefix, for example "internal0"/"external0" or "lan0"/"lan1"/"lan3".
```
[1] 43b3a5ef61
Adding `systemd-importd` to the build, so that `machinectl`s `import-.*`
may actually do anything. Currently they fail with
```
Failed to transfer image: The name org.freedesktop.import1 was not provided by any .service files
```
as `systemd-importd` is not built. Also registers the regarding dbus
api and service in the systemd module.
Both options were introduced in systemd v243[1]. Those options can be
used to ensure that LinkLocalAddressing is only configured for a given
interface if DHCPv4 fails. To quote `systemd.network(5)`:
```
If "fallback" or "ipv4-fallback" is specified, then an IPv4
link-local address is configured only when DHCPv4 fails. If "fallback", an IPv6 link-local
address is always configured, and if "ipv4-fallback", the address is not configured. Note
that, the fallback mechanism works only when DHCPv4 client is enabled, that is, it requires
"DHCP=yes" or "DHCP=ipv4".
```
[1] 8bc17bb3f7
GDM now specifies ordering between `plymouth-quit` and `display-manager`:
9be5321097
This causes an ordering cycle between GDM and plymouth-quit which can result in
systemd breaking GDM:
```
plymouth-quit.service: Job display-manager.service/start deleted to break
ordering cycle starting with plymouth-quit.service/start
```
Not sure how often this triggers, as I've run my system with plymouth and
9be5321097 without any issues. But I did catch a VM doing this.
NOTE: I also tried to remove the ordering in GDM to see if plymouth managed to
live longer, but it didn't seem to help. So I opted to stick as close to
upstream (upstream GDM specifies ordering, but plymouth does not).
Images generated with nixos-install will be supported by machinectl
problem is that systemd-nspawn's private usersns feature clashes
with DynamicUser and RuntimeDirectory features, which causes NixOS
images to not boot. There is an upstream issue for this
https://github.com/systemd/systemd/issues/13622
In #68792 it was discovered that /dev/fuse doesn't have
wordl-read-writeable permissions anymore. The cause of this is that the
tmpfiles examples in systemd were reorganized and split into more files.
We thus lost some of the configuration we were depending on.
In this commit some of the new tmpfiles configuration that are
applicable to us are added which also makes wtmp/lastlog in the pam
module not necessary anymore.
Rationale for the new tmpfile configs:
- `journal-nowcow.conf`: Contains chattr +C for journald logs which
makes sense on copy-on-write filesystems like Btrfs. Other filesystems
shouldn't do anything funny when that flag is set.
- `static-nodes-permissions.conf`: Contains some permission overrides
for some device nodes like audio, loop, tun, fuse and kvm.
- `systemd-nspawn.conf`: Makes sure `/var/lib/machines` exists and old
snapshots are properly removed.
- `systemd-tmp.conf`: Removes systemd services related private tmp
folders and temporary coredump files.
- `var.conf`: Creates some useful directories in `/var` which we would
create anyway at some point. Also includes
`/var/log/{wtmp,btmp,lastlog}`.
Fixes#68792.
Pretty useful for laptops. I use them with:
```
services.logind.lidSwitch = "suspend-then-hibernate";
environment.etc."systemd/sleep.conf".text = "HibernateDelaySec=8h";
```
boot.kernelPackages: check for conflicts
It's currently possible to set conflicting `boot.kernelPackages` several times.
Nixos now warns when this is the case instead of just picking one.
systemd provides two sysctl snippets, 50-coredump.conf and
50-default.conf.
These enable:
- Loose reverse path filtering
- Source route filtering
- `fq_codel` as a packet scheduler (this helps to fight bufferbloat)
This also configures the kernel to pass coredumps to `systemd-coredump`.
These sysctl snippets can be found in `/etc/sysctl.d/50-*.conf`,
and overridden via `boot.kernel.sysctl`
(which will place the parameters in `/etc/sysctl.d/60-nixos.conf`.
Let's start using these, like other distros already do for quite some
time, and remove those duplicate `boot.kernel.sysctl` options we
previously did set.
In the case of rp_filter (which systemd would set to 2 (loose)), make
our overrides to "1" more explicit.
Add support for custom device-tree files, and applying overlays to them.
This is useful for supporting non-discoverable hardware, such as sensors
attached to GPIO pins on a Raspberry Pi.
This adds handling for WASM binaries to binfmt’s emulatedSystems. To
enable, add this to your configuration:
boot.binfmt.emulatedSystems = [ "wasm32-wasi" ];
After rebuilding with nixos-rebuild switch, you can run wasm binaries
directly.
This is a refactor of how resolvconf is managed on NixOS. We split it
into a separate service which is enabled internally depending on whether
we want /etc/resolv.conf to be managed by it. Various services now take
advantage of those configuration options.
We also now use systemd instead of activation scripts to update
resolv.conf.
NetworkManager now uses the right option for rc-manager DNS
automatically, so the configuration option shouldn't be exposed.
This is needed for tcrypt and the benchmark subcommand. If enabled,
it is also used to unlock LUKS2 volumes and therefore the kernel modules
providing this feature need to be available in our initrd.
Fixes#42163. #54019.
Somewhen between systemd v239 and v242 upstream decided to no longer run
a few system services with `DyanmicUser=1` but failed to provide a
migration path for all the state those services left behind.
For the case of systemd-timesync the state has to be moved from
/var/lib/private/systemd/timesync to /var/lib/systemd/timesync if
/var/lib/systemd/timesync is currently a symlink.
We only do this if the stateVersion is still below 19.09 to avoid
starting to have an ever growing activation script for (then) ancient
systemd migrations that are no longer required.
See https://github.com/systemd/systemd/issues/12131 for details about
the missing migration path and related discussion.
Currently if you want to properly chroot a systemd service, you could do
it using BindReadOnlyPaths=/nix/store or use a separate derivation which
gathers the runtime closure of the service you want to chroot. The
former is the easier method and there is also a method directly offered
by systemd, called ProtectSystem, which still leaves the whole store
accessible. The latter however is a bit more involved, because you need
to bind-mount each store path of the runtime closure of the service you
want to chroot.
This can be achieved using pkgs.closureInfo and a small derivation that
packs everything into a systemd unit, which later can be added to
systemd.packages.
However, this process is a bit tedious, so the changes here implement
this in a more generic way.
Now if you want to chroot a systemd service, all you need to do is:
{
systemd.services.myservice = {
description = "My Shiny Service";
wantedBy = [ "multi-user.target" ];
confinement.enable = true;
serviceConfig.ExecStart = "${pkgs.myservice}/bin/myservice";
};
}
If more than the dependencies for the ExecStart* and ExecStop* (which
btw. also includes script and {pre,post}Start) need to be in the chroot,
it can be specified using the confinement.packages option. By default
(which uses the full-apivfs confinement mode), a user namespace is set
up as well and /proc, /sys and /dev are mounted appropriately.
In addition - and by default - a /bin/sh executable is provided, which
is useful for most programs that use the system() C library call to
execute commands via shell.
Unfortunately, there are a few limitations at the moment. The first
being that DynamicUser doesn't work in conjunction with tmpfs, because
systemd seems to ignore the TemporaryFileSystem option if DynamicUser is
enabled. I started implementing a workaround to do this, but I decided
to not include it as part of this pull request, because it needs a lot
more testing to ensure it's consistent with the behaviour without
DynamicUser.
The second limitation/issue is that RootDirectoryStartOnly doesn't work
right now, because it only affects the RootDirectory option and doesn't
include/exclude the individual bind mounts or the tmpfs.
A quirk we do have right now is that systemd tries to create a /usr
directory within the chroot, which subsequently fails. Fortunately, this
is just an ugly error and not a hard failure.
The changes also come with a changelog entry for NixOS 19.03, which is
why I asked for a vote of the NixOS 19.03 stable maintainers whether to
include it (I admit it's a bit late a few days before official release,
sorry for that):
@samueldr:
Via pull request comment[1]:
+1 for backporting as this only enhances the feature set of nixos,
and does not (at a glance) change existing behaviours.
Via IRC:
new feature: -1, tests +1, we're at zero, self-contained, with no
global effects without actively using it, +1, I think it's good
@lheckemann:
Via pull request comment[2]:
I'm neutral on backporting. On the one hand, as @samueldr says,
this doesn't change any existing functionality. On the other hand,
it's a new feature and we're well past the feature freeze, which
AFAIU is intended so that new, potentially buggy features aren't
introduced in the "stabilisation period". It is a cool feature
though? :)
A few other people on IRC didn't have opposition either against late
inclusion into NixOS 19.03:
@edolstra: "I'm not against it"
@Infinisil: "+1 from me as well"
@grahamc: "IMO its up to the RMs"
So that makes +1 from @samueldr, 0 from @lheckemann, 0 from @edolstra
and +1 from @Infinisil (even though he's not a release manager) and no
opposition from anyone, which is the reason why I'm merging this right
now.
I also would like to thank @Infinisil, @edolstra and @danbst for their
reviews.
[1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-477322127
[2]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-477548395
Currently, if you want to properly chroot a systemd service, you could
do it using BindReadOnlyPaths=/nix/store (which is not what I'd call
"properly", because the whole store is still accessible) or use a
separate derivation that gathers the runtime closure of the service you
want to chroot. The former is the easier method and there is also a
method directly offered by systemd, called ProtectSystem, which still
leaves the whole store accessible. The latter however is a bit more
involved, because you need to bind-mount each store path of the runtime
closure of the service you want to chroot.
This can be achieved using pkgs.closureInfo and a small derivation that
packs everything into a systemd unit, which later can be added to
systemd.packages. That's also what I did several times[1][2] in the
past.
However, this process got a bit tedious, so I decided that it would be
generally useful for NixOS, so this very implementation was born.
Now if you want to chroot a systemd service, all you need to do is:
{
systemd.services.yourservice = {
description = "My Shiny Service";
wantedBy = [ "multi-user.target" ];
chroot.enable = true;
serviceConfig.ExecStart = "${pkgs.myservice}/bin/myservice";
};
}
If more than the dependencies for the ExecStart* and ExecStop* (which
btw. also includes "script" and {pre,post}Start) need to be in the
chroot, it can be specified using the chroot.packages option. By
default (which uses the "full-apivfs"[3] confinement mode), a user
namespace is set up as well and /proc, /sys and /dev are mounted
appropriately.
In addition - and by default - a /bin/sh executable is provided as well,
which is useful for most programs that use the system() C library call
to execute commands via shell. The shell providing /bin/sh is dash
instead of the default in NixOS (which is bash), because it's way more
lightweight and after all we're chrooting because we want to lower the
attack surface and it should be only used for "/bin/sh -c something".
Prior to submitting this here, I did a first implementation of this
outside[4] of nixpkgs, which duplicated the "pathSafeName" functionality
from systemd-lib.nix, just because it's only a single line.
However, I decided to just re-use the one from systemd here and
subsequently made it available when importing systemd-lib.nix, so that
the systemd-chroot implementation also benefits from fixes to that
functionality (which is now a proper function).
Unfortunately, we do have a few limitations as well. The first being
that DynamicUser doesn't work in conjunction with tmpfs, because it
already sets up a tmpfs in a different path and simply ignores the one
we define. We could probably solve this by detecting it and try to
bind-mount our paths to that different path whenever DynamicUser is
enabled.
The second limitation/issue is that RootDirectoryStartOnly doesn't work
right now, because it only affects the RootDirectory option and not the
individual bind mounts or our tmpfs. It would be helpful if systemd
would have a way to disable specific bind mounts as well or at least
have some way to ignore failures for the bind mounts/tmpfs setup.
Another quirk we do have right now is that systemd tries to create a
/usr directory within the chroot, which subsequently fails. Fortunately,
this is just an ugly error and not a hard failure.
[1]: https://github.com/headcounter/shabitica/blob/3bb01728a0237ad5e7/default.nix#L43-L62
[2]: https://github.com/aszlig/avonc/blob/dedf29e092481a33dc/nextcloud.nix#L103-L124
[3]: The reason this is called "full-apivfs" instead of just "full" is
to make room for a *real* "full" confinement mode, which is more
restrictive even.
[4]: https://github.com/aszlig/avonc/blob/92a20bece4df54625e/systemd-chroot.nix
Signed-off-by: aszlig <aszlig@nix.build>
This should make the composability of kernel configurations more straigthforward.
- now distinguish freeform options from tristate ones
- will look for a structured config in kernelPatches too
one can now access the structuredConfig from a kernel via linux_test.configfile.structuredConfig
in order to reinject it into another kernel, no need to rewrite the config from scratch
The following merge strategies are used in case of conflict:
-- freeform items must be equal or they conflict (mergeEqualOption)
-- for tristate (y/m/n) entries, I use the mergeAnswer strategy which takes the best available value, "best" being defined by the user (by default "y" > "m" > "n", e.g. if one entry is both marked "y" and "n", "y" wins)
-- if one item is both marked optional/mandatory, mandatory wins (mergeFalseByDefault)
Right now it's not at all obvious that one can override this option
using `services.logind.extraConfig`; we might as well add an option
for `killUserProcesses` directly so it's clear and documented.
The new reuse behaviour is cool and really useful but it breaks one of
my use cases. When using kexec, I have a script which will unlock the
disks in my initrd. However, do_open_passphrase will fail if the disk is
already unlocked.
The previous version contained a false positive case, where boot would
continue when the stage 2 init did not exist at all, and a false
negative case, where boot would stop if the stage 2 init was a symlink
which cannot be resolved in the initramfs root.
Fixes#49519.
Thanks @michas2 for finding and reporting the issue!
* journald: forward message to syslog by default if a syslog implementation is installed
* added a test to ensure rsyslog is receiving messages when expected
* added rsyslogd tests to release.nix
* Lets container@.service be activated by machines.target instead of
multi-user.target
According to the systemd manpages, all containers that are registered
by machinectl, should be inside machines.target for easy stopping
and starting container units altogether
* make sure container@.service and container.slice instances are
actually located in machine.slice
https://plus.google.com/112206451048767236518/posts/SYAueyXHeEX
See original commit: https://github.com/NixOS/systemd/commit/45d383a3b8
* Enable Cgroup delegation for nixos-containers
Delegate=yes should be set for container scopes where a systemd instance
inside the container shall manage the hierarchies below its own cgroup
and have access to all controllers.
This is equivalent to enabling all accounting options on the systemd
process inside the system container. This means that systemd inside
the container is responsible for managing Cgroup resources for
unit files that enable accounting options inside. Without this
option, units that make use of cgroup features within system
containers might misbehave
See original commit: https://github.com/NixOS/systemd/commit/a931ad47a8
from the manpage:
Turns on delegation of further resource control partitioning to
processes of the unit. Units where this is enabled may create and
manage their own private subhierarchy of control groups below the
control group of the unit itself. For unprivileged services (i.e.
those using the User= setting) the unit's control group will be made
accessible to the relevant user. When enabled the service manager
will refrain from manipulating control groups or moving processes
below the unit's control group, so that a clear concept of ownership
is established: the control group tree above the unit's control
group (i.e. towards the root control group) is owned and managed by
the service manager of the host, while the control group tree below
the unit's control group is owned and managed by the unit itself.
Takes either a boolean argument or a list of control group
controller names. If true, delegation is turned on, and all
supported controllers are enabled for the unit, making them
available to the unit's processes for management. If false,
delegation is turned off entirely (and no additional controllers are
enabled). If set to a list of controllers, delegation is turned on,
and the specified controllers are enabled for the unit. Note that
additional controllers than the ones specified might be made
available as well, depending on configuration of the containing
slice unit or other units contained in it. Note that assigning the
empty string will enable delegation, but reset the list of
controllers, all assignments prior to this will have no effect.
Defaults to false.
Note that controller delegation to less privileged code is only safe
on the unified control group hierarchy. Accordingly, access to the
specified controllers will not be granted to unprivileged services
on the legacy hierarchy, even when requested.
The following controller names may be specified: cpu, cpuacct, io,
blkio, memory, devices, pids. Not all of these controllers are
available on all kernels however, and some are specific to the
unified hierarchy while others are specific to the legacy hierarchy.
Also note that the kernel might support further controllers, which
aren't covered here yet as delegation is either not supported at all
for them or not defined cleanly.
"machine.target" doesn't actually exist, it's misspelled version
of "machines.target". However, the "systemd-nspawn@.service"
unit already has a default dependency on "machines.target"
The improved lspci command shows all available ethernet controllers and
their kernel modules. Previously, the user had to provide the slot name
of a specific device.
The default value for journald's Storage option is "auto", which
determines whether to log to /var/log/journal based on whether that
directory already exists. So NixOS has been unconditionally creating
that directory in activation scripts.
However, we can get the same behavior by configuring journald.conf to
set Storage to "persistent" instead. In that case, journald will create
the directory itself if necessary.
Previously, the activation script was responsible for ensuring that
/etc/machine-id exists. However, the only time it could not already
exist is during stage-2-init, not while switching configurations,
because one of the first things systemd does when starting up as PID 1
is to create this file. So I've moved the initialization to
stage-2-init.
Furthermore, since systemd will do the equivalent of
systemd-machine-id-setup if /etc/machine-id doesn't have valid contents,
we don't need to do that ourselves.
We _do_, however, want to ensure that the file at least exists, because
systemd also uses the non-existence of this file to guess that this is a
first-boot situation. In that case, systemd tries to create some
symlinks in /etc/systemd/system according to its presets, which it can't
do because we've already populated /etc according to the current NixOS
configuration.
This is not necessary for any other activation script snippets, so it's
okay to do it after stage-2-init runs the activation script. None of
them declare a dependency on the "systemd" snippet. Also, most of them
only create files or directories in ways that obviously don't need the
machine-id set.
Evaluation error introduced in 599c4df46a.
There is only a "platformS" attribute in kexectools.meta, so let's use
this and from the code in the kexec module it operates on a list,
matching the corresponding platforms, so this seems to be the attribute
the original author intended.
Tested by building nixos/tests/kexec.nix on x86_64-linux and while it
evaluates now, the test still fails by timing out shortly after the
kexec:
machine: waiting for the VM to finish booting
machine# Cannot find the ESP partition mount point.
This however seems to be an unrelated issue and was also the case before
the commit mentioned above.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @dezgeg
* acquire DHCP on the interfaces with networking.interface.$name.useDHCP == true or on all interfaces if networking.useDHCP == true (was only only "eth0")
* respect "mtu" if it was in DHCP answer (it happens in the wild)
* acquire and set up staticroutes (unlike others clients, udhcpc does not do the query by default); this supersedes https://github.com/NixOS/nixpkgs/pull/41829
Although double '/' in paths is not a problem for GRUB supplied with nixpkgs, sometimes NixOS's grub.conf read by external GRUB and there are versions of GRUB which fail
The background color option is self-explanatory.
The mode is either `normal` or `stretch`, they are as defined by GRUB,
where normal will put the image in the top-left corner of the menu, and
stretch is the default, where it stretches the image without
consideration for the aspect ratio.
* https://www.gnu.org/software/grub/manual/grub/grub.html#background_005fimage
