Allow to generate Netplan configuration (using systemd-networkd or NetworkManager backend)

Hi @slyon -- just watched your talk (Thanks :-) ), and would like to help with this.

(I'm fil on IRC, but am not at DC23 :-/ )

There seem to be 2 things that one could aim at here:

setting up the new system to use netplan for its configuration
using netplan within D-I itself to bring its own network up during the install

I'm guessing that you were only initially considering the first of those?

Your patch introduces neplan-generator as a dependency for netcfg (a udeb), which in turn depends on systemd and libc6 -- that's not going to work.

D-I is a little distribution in its own right, and doesn't have either systemd nor libc6. There are bits of systemd one can rely on, such as udev-udeb and libsystemd0, but it's not the init during D-I.

If we wanted to get to the second target of using netplan to bring up D-I's network during install, I suspect that the first step on that road would be to convert D-I to using systemd as its init, which seems like a quite a lot of work for approximately no gain, so that's liable not to happen any time soon.

That probably doesn't matter though, because it is possible to rely on a normal debian environment as long as you do it in the target system, after it is mostly installed. For example, see:

https://salsa.debian.org/installer-team/netcfg/-/blob/master/finish-install.d/55netcfg-copy-config#L21

I'm guessing that you were only initially considering the first of those?

Your patch introduces neplan-generator as a dependency for netcfg (a udeb), which in turn depends on systemd and libc6 -- that's not going to work.

Right, I wasn't really sure about that one. Netplan has some strong ties with systemd, so introducing it as an udeb dependency is probably not what we want here. We should rather focus on approach "1. setting up the new system to use netplan for its configuration".

The network bringup in D-I itself is minimalistic AFAICT, but it's mature and proofed code, which we should probably keep as-is.

FTR: After some discussions with @philh there are a few points we should consider:

There's some customized CI setup, which allows for much easier testability of D-I code changes: https://salsa.debian.org/philh/netcfg/-/pipelines/578320
A first step could be to introduce a debconf variable to choose between ifupdown and netplan config generation, to avoid getting the two tools in conflict and fighting over interface control, to allow for easy testing and potential toggling of the defaults in the future, without breaking existing code or setups.

added 10 commits

fb4d99ee...c66161b6 - 7 commits from branch installer-team:master
904c8990 - Allow to generate Netplan configuration
7e583599 - finish-install: Netplan enablement, if installed
ec0c74eb - Update changelog

Compare with previous version

added 1 commit

3870815a - Update changelog

Compare with previous version

changed title from [RFC] Bring up networking using Netplan + systemd-networkd to Allow to generate Netplan configuration (using systemd-networkd or NetworkManager backend)

changed the description

As discussed with @philh I changed the MR to only enable Netplan in the installed target system. I'm now also using the netcfg/target_network_config debconf variable for testing, but that's usually not needed, as the code will automatically switch to netcfg/target_network_config=netplan if the netplan-generator package is detected in the target system, which can be achieved by using preseed, e.g.:

# https://people.ubuntu.com/~slyon/d-i/netplan-preseed.cfg
d-i preseed/late_command string in-target apt-get -y install netplan-generator

@philh May I ask you to have another look at this MR and maybe also run it through your CI pipeline?

@alpernebbi @holgerw May I ask for your feedback, too?

I also prepared some more preseed files, that allow for easy testing of this change. Those install the relevant packages at the correct point of time during the installation process to trigger the Netplan and/or NetworkManager configuration to be installed.

Afterwards, netplan status can be used alongside networkctl or nmcli to check the target systems network configuration.

@kibi May I also ask your opinion on this, please?

It's fine to add a new option, I'm not convinced making it the default immediately is reasonable though.

(Edit: I realize there are various moving pieces here, depending on if and when Netplan components get into the base system, but I can't really spend more time on this right away.)

Thanks for the feedback @kibi!

It's not making it the default, only in case when the netplan-generator package is detected to be installed in the target system. Otherwise, it will keep the original logic.

Would that work for you?

See https://blog.slyon.de/2024/04/25/creating-a-netplan-enabled-system-through-debian-installer/ for a demo of this work.

added 11 commits

3870815a...a218ebab - 8 commits from branch installer-team:master
88be6490 - Allow to generate Netplan configuration
e619fd86 - finish-install: Netplan enablement, if installed
31133d1c - Update changelog

Compare with previous version

Rebased, now that things start to work again in unstable.

I've started looking at the updated branch (thanks!), and I'm discovering we would be losing WEP support entirely? I know it's old and insecure and everything, but it feels weird.

Spotting a 32 default value for the netmask, have you seen !10 (merged)?

This is a bit orthogonal to the merge request, but seeing how the netcfg/target_network_config template is getting updated, that's going to lead to translation updates; maybe it would make sense to fix the ifupdown vs. loopback discrepancy? We configure ifupdown for “ethernet” (which should be “Ethernet”) but also for wireless connections (even if that only got fixed during the bookworm release cycle, some fun in netcfg and some extra fun in ifupdown).

I was a bit surprised by shelling out to mkdir and rm at first but I see there are a lot of di_exec_shell*() already.

Thanks for implementing the suggestion regarding the comment in the last part of the finish-install script.

That's all for an initial, cursory look, without knowing anything about Netplan, its format, or its interactions with N-M. Overall, nothing stands out as particularly crazy (kibi-speak for “good work!”, as I'm always worried about jinxing things…).

Next up is building things and trying it out, first in VMs, then on real systems (with IPv4/IPv6 over WPA2, and/or Ethernet — probably sticking to automated settings though, meaning ISP box-provided DHCP & RA). That is still lined up as “in the next few days”.

I've built an ISO with modified netcfg udebs, and run some tests from within a VM; its wired interface only has access to IPv4 (and DHCP) while its wireless interface comes from a USB dongle passed through via libvirt, accessing both IPv4 (and DHCP) and IPv6 (via RA).

Pausing the install at the tasksel screen, manually installing netplan-generator within /target, I'm seeing appropriate network configuration in the installed system in both cases: IPv4/DHCP on the wired interface, IPv4/DHCP + IPv6/RA on the wireless interface.

Not pausing the install at that screen, I'm still getting the usual /e/n/i configuration.

I haven't tried to run a full desktop install to verify the Netplan vs. N-M case, but things look good enough at the moment.

In addition to the various remarks from last week, I think it would be much better if debian/changelog detailed what's changing. Namely the changed precedence: Netplan is configured if netplan-generator is detected, then N-M is configured if network-manager is detected, with ifupdown as the fallback.

added 10 commits

31133d1c...2e90cc70 - 4 commits from branch installer-team:master
26d3685d - Allow to generate Netplan configuration
8fc5ddf2 - finish-install: Netplan enablement, if installed
4cc217b3 - netplan: Do not bail out on insecure WEP wifi connections
f4194db2 - netplan: Install an 'onlink' route for IPv4 /32 or IPv6 /128 netmasks
dc2653e0 - netcfg:templates: Rephrase netcfg/target_network_config to clear up some confusion
45ad3da3 - Update changelog

Compare with previous version

@kibi Thank you so much for all the input and testing. I think I addressed all of your concerns with my latest commits added on top of the existing work.

I just rebased and pushed the new changes. Let me know what you think!

changed the description

added 7 commits

5b6e85b7 - 1 commit from branch installer-team:master
ba497037 - Allow to generate Netplan configuration
458019d6 - finish-install: Netplan enablement, if installed
3ab33e18 - netplan: Do not bail out on insecure WEP wifi connections
8c3b7b91 - netplan: Install an 'onlink' route for IPv4 /32 or IPv6 /128 netmasks
48820b51 - netcfg:templates: Rephrase netcfg/target_network_config to clear up some confusion
43d30698 - Update changelog

Compare with previous version

My focus drifted a little… I haven't looked at the most recent push yet, but I'd like to know if you consider you're all done for this merge request?

added 6 commits

2c08c481 - Allow to generate Netplan configuration
ab2c17ee - finish-install: Netplan enablement, if installed
9a1af2af - netplan: Do not bail out on insecure WEP wifi connections
26bc8ba0 - netplan: Install an 'on-link' route for IPv4 /32 or IPv6 /128 netmasks
b5906368 - netcfg:templates: Rephrase netcfg/target_network_config to clear up some confusion
676b0ad5 - Update changelog

Compare with previous version

added 3 commits

9128b4c0 - netplan: Implicitly enable (stateless) DHCPv6 in SLAAC environments
6b98ac45 - netcfg:templates: Rephrase netcfg/target_network_config to clear up some confusion
3ab1e742 - Update changelog

Compare with previous version

Hi @kibi I rebased my branch and did some more testing today. I also applied some tiny fixes around the on-link route and the SLAAC handling. I think all of your remarks are addressed and it should be ready to be merged. Do you see any other blocker?

My testing was especially around the /32 usecase implemented in !10 (merged) and the full-desktop install, to verify the Netplan+NetworkManager usecase. Both /etc/netplan/{00-installer-config,01-network-manager-all}.yaml are installed correctly and NetworkManager brings up the interface and can be used as usual.

After installing the netplan.io CLI on a default desktop/GNOME system, I can see the following results (similar to using $EDITOR to check /etc/netplan/{00-installer-config,01-network-manager-all}.yaml without the Netplan CLI). That is, after manually configuring 10.0.2.15/32 with gateway 10.0.2.2 and DNS 10.0.2.3 manually through the D-I interface:

root@debian:/home/test# /sbin/netplan status
     Online state: online
    DNS Addresses: 127.0.0.53 (stub)
       DNS Search: .

●  1: lo ethernet UNKNOWN/UP (unmanaged)
      MAC Address: 00:00:00:00:00:00
        Addresses: 127.0.0.1/8
                   ::1/128

●  2: enp0s1 ethernet UP (NetworkManager: enp0s1)
      MAC Address: 52:54:00:12:34:56 (Red Hat, Inc.)
        Addresses: 10.0.2.15/32
                   fec0::5054:ff:fe12:3456/64
                   fe80::5054:ff:fe12:3456/64 (link)
    DNS Addresses: 10.0.2.3
           Routes: default via 10.0.2.2 metric 100 (static)
                   fe80::/64 metric 256
                   fec0::/64 metric 256
                   default via fe80::2 metric 1024 (ra)
root@debian:/home/test# /sbin/netplan get
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp0s1:
      optional: true
      addresses:
      - "10.0.2.15/32"
      nameservers:
        addresses:
        - 10.0.2.3
      routes:
      - on-link: true
        to: "default"
        via: "10.0.2.2"

Screenshot of NetworkManager UI & CLI:

Looping in @cjwatson who implemented this (I know ~ nothing about that at the moment).

If you're all done otherwise, I'll have another look before merging/uploading.

Preparing the upcoming point releases (Debian 11 & 12) is going to be higher priority, but hopefully I'll manage to tackle that once point release preps are over.

If you're all done otherwise, I'll have another look before merging/uploading.

Yes, all done from my side.

@cjwatson o/ The changes related to your merge-request !10 (merged) are mostly isolated in this commit: !9 (26bc8ba0)

Hopefully we can still get this landed ahead of DebConf'24 (next month) as this would allow me to have some more solid follow-up discussions, building upon this work.

I haven't looked over your whole MR, but the particular commit you highlighted looks fine to me, as does your netplan status output. I'm assuming you also tested that outbound connectivity actually works in that situation!

I haven't looked over your whole MR, but the particular commit you highlighted looks fine to me, as does your netplan status output. I'm assuming you also tested that outbound connectivity actually works in that situation!

Thanks for double-checking it so quickly! Yes, I confirmed that I have client & server (in-/outbound) connections working with this setup. While connected to a hostbridge on my local machine, the VM is serving sshd and I can login to VM via SSH. From inside the VM I can also reach the internet (e.g. using web-browser, or ping'ing some server).

changed the description

added 5 commits

bc78babb - netplan: Do not bail out on insecure WEP wifi connections
02051625 - netplan: Install an 'on-link' route for IPv4 /32 or IPv6 /128 netmasks
b0c7e344 - netplan: Implicitly enable (stateless) DHCPv6 in SLAAC environments
7d5524c5 - netcfg:templates: Rephrase netcfg/target_network_config to clear up some confusion
6412a9f2 - Update changelog

Compare with previous version

@cjwatson @kibi this has been tested and reviewed multiple times, so I think this is ready to merge

mentioned in merge request !11

I've been experimenting with various network stacks lately, merging this is next up.

BTW I think the if $FLAG style of test is fragile (we don't use it elsewhere in D-I AFAICT), so would rather see that as something like if [ true = "$FLAG" ]

However, having seen that, and then looking at the rest of the script, I think the whole thing could be rather nicer, so I'm looking at refactoring it -- no need to wait for me, as I think it makes sense to merge what we have here, then change the result afterwards (so far I've written some tests in shUnit2 to try to ensure that a modified version produces the same outcomes https://salsa.debian.org/philh/netcfg/-/commits/copy-config_refactor )

While testing Netplan stuff on Debian 12, that showed up a couple of times (in particular in Debian-provided Cloud Images):

Permissions for /etc/netplan/90-default.yaml are too open. Netplan configuration should NOT be accessible by others.

(I have yet to check what the situation is with testing/unstable, and whether a bug report exists already.)

While permissions for the NM config are managed in the hook, that seems to be taken care of while writing the file in the d-i context (via fchmod(), long before it gets copied into /target) so the Netplan code should be fine in that regard.

I'd guess that wildcarding the chmod 600 might help with that: philh/netcfg@8ce785c4 (although if the source files are already 600, then the cp really ought to preserve that)

Well, as mentioned in what was mainly a note to myself to make sure I didn't forget to double check: that should be good already. Having just checked, that's the case.

Edit: Using a wildcard here wouldn't fix a possible issue with file permissions, as that only happens in the Netplan and NetworkManager case…

Alright, one fun thing spotted while testing: in a VM with a USB-passthrough-provided wireless dongle, using a WPA2 connection on which DHCPv4 and IPv6 RAs are available, run d-i until say the tasksel prompt, install netplan-generator in /target, then resume d-i.

After installation, networkctl status returns all green with State: routable and Online state: online.
Since it isn't pulled by any dependencies and wasn't installed manually, netplan.io is not installed, and one can't netplan status.
After installing netplan.io, netplan status returns a red Online state: offline while the wireless interface is reported with a green UP, including default routes.
Of course, both IPv4 and IPv6 are working fine (tested a few ICMP and HTTPS connections).
Edit: This issue persists after a reboot following netplan.io's installation, so it doesn't seem to be due to some temporary state/inconsistency.

Since I'm not diving into the details of those components right now, and since I don't consider this as a blocker, I'm going to let @slyon pick it up from here and debug/file bug reports appropriately.

Doing the same test with both netplan-generator and network-manager is a tad more challenging as some dependencies try and access the debconf DB which is locked, but nothing that resists editing out some postinst scripts…

After installation, networkctl status returns an error, as systemd-networkd doesn't seem to be running. Now I know what happens when that competes with NetworkManager.
Even if nothing configured ens3 (default NIC in this libvirt-with-QEMU-backend VM) during the installation, I suppose NetworkManager's defaults are a little different, and this interface was brought up automatically, with DHCPv4, and without any kind of IPv6 settings (that's consistent with the default QEMU network in libvirt, only providing DHCPv4).
The wireless interface is configured as before, both with DHCPv4 and IPv6 RA's, still connected to the home network (≠ libvirt-provided network).
Both IPv4 and IPv6 are working fine (tested a few ICMP and HTTPS connections — don't forget to reinstall ca-certificates if you butchered its postinst).
There are two default routes, and the wired one is preferred over the wireless one via the usual metric system (100 vs. 600).

Installing netplan.io and running netplan status is similar as above: red Online state: offline, with a yellow UNKNOWN/UP for the loopback (I didn't mention it earlier, but that was the case as well), two green UP wired and wireless interfaces. These results persist after rebooting.

Same test again, this time with netplan-generator only and with manual IPv4 settings (using an IP that's different from the one attributed via DHCP earlier, with a different netmask to make sure… 192.168.0.77/24 → 192.168.0.222/25), again on the wireless interface and the home network (still providing RAs).

After installation, networkctl status is happy again.
/etc/netplan/00-installer-config.yaml still lists the SSID and the passphrase as before, but also the manually-specified 192.168.0.222/25 address and netmask, plus 192.168.0.254 as the gateway and the DNS nameserver.
The running configuration matches this, and the wired connection is left unconfigured again (same as in the first test).
I'm still getting IPv6 connectivity with RAs.
Both IPv4 and IPv6 are working fine (ICMP and HTTPS).
Same as above regarding apt-get install netplan.io and netplan status's report (without or with a reboot).

Of course all the above were just smoke tests but I really wanted to make sure such basic things were still working nominally, as not having network access makes everyone's life harder (especially when it comes to debugging d-i).

All in all, thanks for the awesome merge request and for dealing with the feedback/comments, @slyon!

Have fun discussing the future of the networking stack(s), be it on dd@ or at DebConf! I'll happily take a backseat and let “others” come up with a consensus there.

All in all, thanks for the awesome merge request and for dealing with the feedback/comments, @slyon!

Thank you very much for all your input, testing and time you spent on this. Your help is much appreciated!

Have fun discussing the future of the networking stack(s), be it on dd@ or at DebConf! I'll happily take a backseat and let “others” come up with a consensus there.

Haha, let's see where it takes us. Hopefully we will have a fruitful discussion to the overall benefit of Debian!

merged manually

Allow to generate Netplan configuration (using systemd-networkd or NetworkManager backend)

Future work

Merged by Cyril Brulebois 1 year ago (Jul 15, 2024 9:35am GMT+0900) 1 year ago

Activity

Allow to generate Netplan configuration (using systemd-networkd or NetworkManager backend)

Future work

Merge request reports

Merged by Cyril Brulebois 1 year ago (Jul 15, 2024 9:35am GMT+0900) 1 year ago

Activity