On Wed, Jul 12, 2023 at 01:33:02PM +0200, Andrey Rakhmatullin wrote: > On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > > From the discussions above, it seems that NetworkManager is relevant as > > > well, > > > though, and is being pulled in whenever a desktop task is installed (in > > > addition to ifupdown or future systemd-networkd). > > > > What happens at the moment is: > > > > - if the tasks install NetworkManager, then d-i translates the install-time > > networking into NetworkManager configuration, together with essentially > > blank ifupdown configuration that makes ifupdown mostly a no-op (it > > might still try to bring up `lo`, but systemd brings that up as an "API" > > interface anyway, and probably so does NM if systemd didn't already) > Something also enables the ifupdown plugin in NM (and does something about > managed=true/false? I'm not familiar with this integration). If we remove > ifupdown this should be changed I think.
We could save that translation step in d-i when using Netplan. We'd just need the network-manager package ship a /usr/lib/netplan/00-network-manager-all.yaml ``` network: version: 2 renderer: NetworkManager ``` > > - otherwise, d-i translates the install-time networking into ifupdown > > configuration > > > > Doing that, but with s/ifupdown/systemd-networkd/ throughout, makes > > sense to me. Is that what others in this thread had in mind? > > > > The practical result would be NM on desktop/laptop class systems, and > > systemd-networkd on server/embedded systems, which as it happens is what > > I'm already doing on my own machines. > I also wonder how complicated would it be to get WiFi configured in the > GUI-less setup. Currently it's easy if NM was installed for some reason > (with nmtui) and not easy otherwise. That would lead to a situation where users would need to differentiate what system they are on when doing their network configuration: Debian Cloud (Netplan) vs Desktop (NetworkManager) vs Server (systemd-networkd) All using different formats and locations to store their configuration. On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > Therefore, I'd love to see Netplan to be used in combination with this! > > It's a clean, declarative configuration language not specifically tied to > > systemd-networkd as an implementation. So it could also be used on desktop > > installs where NetworkManager is important, for example to handle roaming > > between varying WiFi networks. > > One of the major reasons why the desktop tasks use NetworkManager > is that it's well-integrated in desktop environments (particularly > our default GNOME desktop, but also others like KDE Plasma). If GNOME > controls NetworkManager directly, using its client library and D-Bus > API, is that going to conflict/collide with Netplan also trying to > control/configure NetworkManager? If I'm understanding Netplan correctly, > it treats NM and networkd configuration as essentially "write-only" > (like a compiler that inputs its own syntax and outputs NM or networkd > syntax), which doesn't seem compatible with GNOME going behind its back? > > It seems unlikely that GNOME upstream is going to switch to using > a Netplan API and having it as a dependency unless it has extremely > compelling benefits, because they are happy with their design choice to > have tight integration with NetworkManager; and the Debian GNOME team > already does not have the resources to maintain GNOME in Debian as well > as we would like to, so I think I can safely say we aren't going to be > able to maintain a patch for GNOME to use Netplan APIs downstream. I'm > sure other major desktops like KDE Plasma are in the same situation. I fully agree on NetworkManager being very well integrated in desktop environments and I don't want to force the Netplan API onto anybody. It isn't needed. Netplan plays nicely side-by-side with NetworkManager. When Netplan's default "renderer" is set to be "NetworkManager" (see config snippet above, which could be shipped by the network-manager package), Netplan would just feed NM connection profiles into /run/NetworkManager/, while NM is still free to choose which connection profile to use, or add additional profiles in /etc/NetworkManager/ as usual. (We're also working on a bidirectional Netplan-NetworkManager integration, that allows NM to feed back it's configuration into Netplan YAML format. It is a small patch for NetworkManager and is purely optional.) -- Lukas
signature.asc
Description: PGP signature
