Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 14, 2023 at 09:33:12AM -0400, Jeremy Bícha wrote: > On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > > (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.) > > Does that already exist in Ubuntu 23.10 "Mantic"? Yes, we enabled it in Ubuntu just recently. The code can be found here: https://git.launchpad.net/network-manager/tree/debian/patches/netplan Cheers, Lukas signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
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
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > >>>>> "Lukas" == Lukas Märdian writes: > > > Lukas> Therefore, I'd love to see Netplan to be used in combination > Lukas> with this! It's a clean, declarative configuration language > Lukas> not specifically tied to systemd-networkd as an > Lukas> implementation. So it could also be used on desktop installs > Lukas> where NetworkManager is important, for example to handle > Lukas> roaming between varying WiFi networks. It would also allow > Lukas> for d-i to install a single, common default network > Lukas> configuration, independently of the underlying daemon. > > I currently use netplan.io when I need to interact with cloud-init and > network configs. > > I think netplan is a great tool when > > 1) You need to interact with cloud-init > > or > > 2) When a human is generating systemd-networkd config or NetworkManager > config. > systemd-network splits its config across multiple files in a way that's > really nice when you have some provisioning system generating it, but > isn't so nice when you are wanting to look at the config all in one > place as a human. > NetworkManager's config is a bit fiddly to generate by hand, much less > so than netplan.io. I agree, cloud-init is a strong use-case. And another one is the ability to support systemd-networkd and NetworkManager with a common configuration file, which can be amended by a human or another package (like NetworkManager) shipping a drop-in config, to amend which networking daemon is configured. Let me give a specific example below... > However, there are some significant disadvantages to netplan: > > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. It is an extra layer, but this also brings the benefit of being compatible with networkd and NetworkManager. Let me give an example: D-i could install a basic Netplan config to "run dhcp on my ethernet", e.g. /etc/netplan/90-default.yaml: ``` network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ``` This would generate systemd-networkd (Netplan's default backend) configuration at boot time in /run/systemd/network/10-netplan-eth0.network Now, if a desktop task is pulling in the network-manager package, that could ship a /usr/lib/netplan/00-network-manager-all.yaml Netplan drop-in config: ``` network: version: 2 renderer: NetworkManager ``` Which would change the default setup to now generate NetworkManager config in /run/NetworkManager/system-connections/netplan-eth0.nmconnection instead. This is without any changes to the installation system or the file shipped in /etc/netplan/90-default.yaml. Of course, users can still override that decision (even on the interface level) by specifying the "renderer" setting explicitly in some /etc/netplan/ config. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). Yes, you can easily define your own /etc/systemd/network/* config besides any /etc/netplan/* config that generates files in /run/systemd/network. Netplan tries to always play nice with any interfaces configured outside of /etc/netplan/, for example manually configured Open vSwitch bridges. In fact, you can also easily amend or override systemd-networkd configuration generated by Netplan, using systemd's usual override-config approach. Picking up the example above, you could create a file in: /etc/systemd/network/10-netplan-eth0.network.d/override.conf Which can add or change anything configured by Netplan in: /run/systemd/network/10-netplan-eth0.network > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. Netplan has evolved a lot since its early days in 2016 and there are many more possiblities, e.g. a libnetplan.so for deeper integration in other tools (e.g. to validate Netplan YAML configs from a 3rd party tool). > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networkd sounds like a better option. > > In the wifi case thoug
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jul 10, 2023 at 09:39:52AM -0400, nick black wrote: > Helmut Grohne left as an exercise for the reader: > > And yeah, please work on changing that ifupdown by default. I'm faced > > with having to uninstall it from more and more systems. In case, you > > do a straw poll, I vote for systemd-networkd, which happens to be > > installed by default. Would there be any volunteers doing the d-i > > integration? > > I'd be interested in taking this on, though I wouldn't want to > step on anyone's toes, so if someone with a feeling of ownership > would rather take it, please let yourself be known. I'd want > clarity as to whose approval I need to merge code (and their > buy-in to the effort overall) before starting. > > I've messed with d-i and systemd-networkd both a good bit, and > like you (I assume) believe systemd-networkd to be the best > option at this time, and also moving forward. Having touched both of those projects sounds like a good starting point! I agree we should be going with systemd-networkd for minimal/server setups. It is slim and comes pre-included with systemd, so is already part of many Debian installations. 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). 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. It would also allow for d-i to install a single, common default network configuration, independently of the underlying daemon. The Netplan + systemd-networkd stack is already being used in Bookworm cloud-images [1]. So going with that in d-i as well, would have the additonal benefit of common network configuration accorss different variants. Cheers, Lukas [1] https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ signature.asc Description: PGP signature
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Thu, Jun 22, 2023 at 01:39:02PM +0800, Paul Wise wrote: > On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > > > Netplan allows to configure both of those tools and is already being > > used across Ubuntu and in Debian cloud-images for this purpose. All > > while keeping full flexibility to use the underlying tool's native > > config files, should Netplan's simple YAML settings not be enough for > > a given complex usecase. > > Is Netplan able to parse an existing native config for each of the > tools and then output either Netplan configs or native configs for each > of the other network config tools? For example could you use Netplan to > auto-migrate from ifupdown to systemd-networkd or NetworkManager etc? Netplan is implemented as a systemd-generator [1] and primarily intended to be used as a one-directional genreator from Netplan YAML -> native config. We've been making some moves in adding bidirectional parsing capabilities for NetworkManager's keyfiles, though, e.g.: NM keyfile <-> Netplan YAML And there's also an ifupdown migration prototype, but that is pretty limited, didn't see much love in the recent years and might not live up to expectations, e.g.: ENABLE_TEST_COMMANDS=1 netplan migrate Cheers, Lukas [1] https://manpages.debian.org/testing/systemd/systemd.generator.7.en.html signature.asc Description: PGP signature
