Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos: Provide overrideStrategy option for systemd-networkd units #310493

Open
rvl opened this issue May 10, 2024 · 3 comments
Open

nixos: Provide overrideStrategy option for systemd-networkd units #310493

rvl opened this issue May 10, 2024 · 3 comments

Comments

@rvl
Copy link
Contributor

rvl commented May 10, 2024

Describe the bug

I would like to configure a systemd network using an upstream .network unit with a single small modification.

This can be achieved by creating a drop-in .conf file under /etc/systemd/network.

For systemd services, NixOS provides an overrideStrategy option. But there is no corresponding option for systemd.network.{networks,links,netdevs}.

Steps To Reproduce

Currently, to configure a drop-in, we must do:

{
  networking.useNetworkd = true;
  containers.example = {
    privateNetwork = true;
	hostAddress = "192.168.55.1";
    localAddress = "192.168.55.2";
    config = {
      networking.useNetworkd = true;
      environment.etc."systemd/network/80-container-host0.network.d/overrides.conf".text = ''
        [Match]
        Name=eth0
      '';
    };
}

The upstream unit can be found at /run/current-system/sw/lib/systemd/network/80-container-host0.network.

Expected behavior

It would be nicer to be able to configure the drop-in like this:

{
  systemd.network.networks."80-container-host0" = {
    overrideStrategy = "asDropinIfExists";
    matchConfig.Name = "eth0";
  };
}

Possible values for overrideStrategy would be the same as for systemd.services.<name>.overrideStrategy, plus another option "replace". This would be the default value, describing the current behaviour where a network unit defined in NixOS will mask the upstream unit from systemd.packages.

Additional context

This is relevant to configuring systemd-networkd inside NixOS containers, because the container network interface name does not match upstream systemd.

Notify maintainers

cc: @Ma27 who has been working on networkd containers (NixOS/rfcs#108).

Metadata

rodney@tethys:~ % nix-info -m                                         
 - system: `"x86_64-linux"`
 - host os: `Linux 6.8.8, NixOS, 24.05 (Uakari), 24.05.20240502.63c3a29`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/p69bcs7ma6ijj8v9xsrg3nq3nn8ryn95-source`

Add a 👍 reaction to issues you find important.

@Ma27
Copy link
Member

Ma27 commented May 11, 2024

This is relevant to configuring systemd-networkd inside NixOS containers, because the container network interface name does not match upstream systemd.

You can define a fresh unit that is higher up in the directory listing (i.e. has 0-foo.network).
Also IIRC you can't override networkd units. Did you check whether this actually works for systemd?

@rvl
Copy link
Contributor Author

rvl commented May 14, 2024

You can define a fresh unit that is higher up in the directory listing (i.e. has 0-foo.network).

Yes, and also /etc/systemd/network/80-foo.network will override /run/current-system/sw/lib/systemd/network/80-foo.network, but that's not quite what I would like to do.

I would like to provide an option to override rather than replace systemd-networkd config files.

It would make the network interface config for containers shorter and better able to cope with upstream changes.

The option could potentially be useful for overriding (rather than replacing) any network configuration shipped with systemd upstream. At the moment though most upstream .network files in systemd are related to container networking.

Also IIRC you can't override networkd units.

Perhaps that used to be the case, but since at least systemd 255.4 it's possible and documented in the systemd.network(5) man page.

Did you check whether this actually works for systemd?

Yes. Here is an example of a systemd network configured with a drop-in:

[root@example:~]# networkctl status eth0
● 2: eth0
                   Link File: n/a
                Network File: /nix/store/y6mag03hj8b2hnlcj682xvp2aid7yg7y-systemd-255.4/lib/systemd/network/80-container-host0.network
                              └─/etc/systemd/network/80-container-host0.network.d/overrides.conf
                       State: routable (configured)
                Online state: online
                        Type: ether
                        Kind: veth
            Hardware Address: d6:73:8e:0f:9c:b0
                         MTU: 1500 (min: 68, max: 65535)
                       QDisc: noqueue
IPv6 Address Generation Mode: eui64
    Number of Queues (Tx/Rx): 8/8
            Auto negotiation: no
                       Speed: 10Gbps
                      Duplex: full
                        Port: tp
                     Address: 192.168.55.2
                              169.254.89.84
                              fe80::d473:8eff:fe0f:9cb0
                     Gateway: 192.168.55.1
                              fe80::a0bb:5aff:fe42:f780
           Activation Policy: up
         Required For Online: yes
           DHCP6 Client DUID: DUID-EN/Vendor:0000ab11f1abc2fa1306ef1b
                Connected To: tethys on port ve-example

May 07 16:53:43 example systemd-networkd[235]: eth0: Link UP
May 07 16:53:43 example systemd-networkd[235]: eth0: Gained carrier
May 07 16:53:43 example systemd-networkd[235]: eth0: Configuring with /nix/store/y6mag03hj8b2hnlcj682xvp2aid7yg7y-systemd-255.4/lib/systemd/network/80-container-host0.network.
May 07 16:53:44 example systemd-networkd[235]: eth0: Gained IPv6LL

@rvl
Copy link
Contributor Author

rvl commented May 14, 2024

I would be happy to implement this myself, but would first like review from maintainers of the systemd NixOS modules (whoever they are).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants