The container tests generally don't need this, it seems to work fine
so far, and this could genuinely be useful in image-based deployments.
Why an error instead of inheriting the setting?
Containers do not and should not inherit a parent setting like this.
If a container declares requiring too much, that's the mistake.
If the host does not support a container's declared environment, that's
a host problem.
If the container inherits the setting from the parent, the container's
configuration is not respected.
Example of the error message:
nodes.machine.containers.web-noip requires a Nix daemon but the host does not provided it, as option nodes.machine.nix.daemon.enable is disabled
In a13b423085 ("nixos-containers: allow hard-coding container veth MAC address &
add IPv6 SLAAC test case (#462775)") I had a typo in the `localMacAddress`
setting used for the dummy container config to generate the systemd service
template. I don't think this actually causes any breakage, but it's good to fix
for consistency's sake nonetheless.
lib.network.ipv6.fromString tries to parse the address and fails with
IPv4-mapped addresses, but we actually just want to extract the prefix,
so do this using string operations, as for IPv4.
Fixes issue #530543.
The fix in #523016 fixes an issue with the default gateway, however it
does so by unconditionally defining `networking.interfaces.eth0`. This
makes so if you had other methods of defining the addresses for eth0,
those now get blanked out.
Instead, move the logic around so we only define
networking.interfaces.eth0 if we really have to.
Fixes issue reported here https://github.com/NixOS/nixpkgs/pull/515773#issuecomment-4501563586
Containers with privateNetwork have an eth0 interface configured
imperatively by the container setup script, so the networking-interfaces.nix module
doesn't know about it. Specifying the default gateway then fails
silently, unless this setup is mirrored in networking.interfaces.eth0
inside the container.
/usr/bin is load bearing and needs to be inside a root before nspawn
will pivot to it.
This will allow us to drop systemd/0003-Fix-NixOS-containers.patch
When using a NixOS container with `privateNetwork = true;` (i.e., a
veth network device), it automatically gets assigned a random, locally
administered unicast MAC address. While this is fine for many
purposes, when attaching this container to a larger Layer 2 network
where it interacts with other services, like an external DHCP server
or IPv6 gateway sending out router advertisements, the MAC address of
the container matters.
This commit thus adds a `macAddress` option to containers. If set,
this MAC address will be assigned to the container-side of the `veth`
interface very early during container boot (before executing the stage
2 init script). This is crucial to ensure that no services run in the
container using the prior, random MAC automatically assigned to the
`veth` device. Otherweise, I've had problems using systemd units or
the activation scripts to set the address early enough during
container boot to use it, for example, for IPv6 SLAAC address
assignment.
There are a bunch of components such as incus or LXC that also use
`boot.isContainer`, so we'd have to differentiate between "OS container"
and "actually nspawn".
This became necessary for the file-systems part where nspawn takes care
of setting up special filesystems like `/proc`, `/dev` etc., but others
don't.
To allow for a `boot.isContainer` being less overloaded, this introduces
`boot.isNspawnContainer` that is exclusively used for nspawn-specific
things. When `true`, `boot.isContainer = true;` is implied.
Integrated the flake container setup into the spawn script for systemd-nspawn.
The trickiest part of this was ensuring the underlying per-container is built.
With the .conf file created, running `nixos-container update` creates all the necessary per-container structure.
We call this command at start to ensure the structure is created only if the per-container system isnt there.
Note: This also means the flake gets updated to branch HEAD when the container is started for the first time.
While the nixos-container command allows for the creation of containers pointing to a flake, the declarative module doesn't have this option.
Adds the flake option for nixos-container declarative approach. Creates the /etc/nixos-container .conf file similar to how the command preforms it.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
I think this is the norm in NixOS modules. This allows to start a
container with '--volatile=overlay --link-journal=host' in order to
persist logs across runs of a container running with a temporary root.
While '--ephemeral' omits '--link-journal=try-guest', it's not possible
to run an ephemeral container when linking the journal:
https://github.com/systemd/systemd/issues/1666
The description for options.nixpkgs.system already hints at this:
Neither ${opt.system} nor any other option in nixpkgs.* is meant
to be read by modules and configurations.
Use pkgs.stdenv.hostPlatform instead.
We can support this goal by not elaborating the systems anymore, forcing
users to go via pkgs.stdenv.
This will prevent problems when making the top-level package sets
composable in the next commit. For this to work, you should pass a fully
elaborated system to nixpkgs' localSystem or crossSystem options.
`/etc/os-release` of NixOS containers, which are
`/var/lib/nixos-containers/*/etc/os-release` on the host, are usually
symlinks to the absolute path `/etc/static/os-release` but it doesn't
exist in non-NixOS host. Since `startScript` is evaluated by the host
system, both `[ -e "$root/etc/os-release" ]` and
`touch "$root/etc/os-release"` fail, so that the container fails to
start on the second boot (on the first boot, the symlink doesn't exist,
so the command succeeds).
This commit avoids `touch "$root/etc/os-release"` if
`$root/etc/os-release` is a symlink, so imperative NixOS containers are
usable on non-NixOS host.
