On 11.07.24 02:18, Thomas Goirand wrote:
On 7/10/24 20:03, Michael Biebl wrote:
Since there is a lot of support for this idea, the next logical step as smcv said, would be to make d-i/netcfg networkd aware. At the beginning, this could be opt-in (for testing purposes) and we could make it the default later on.
Any takers?
If someone were to add that support in d-i for Trixie, that'd be great. Even better IMO, if it had support for Netplan. Then we could switch the default for Forky?
We're actually pretty close in getting D-I support for Netplan merged [d-i/netcfg !9], which would enable Netplan+systemd-networkd for new installations by default. In addition to that it supports Netplan+NetworkManager backend for Desktop installations,
as it is today.
That way, we will be able to rely on the two most popular, well tested and well maintained networking daemons (systemd-networkd & NetworkManager), while also being able to use the common Netplan configuration language, controlling both (optionally!).
Everybody is still free to write their own custom sd-networkd .network or N-M .nmconnection in /etc/ or configure the daemon through corresponding D-Bus APIs or GUI/TUI applications, by just not putting any configuration for a given interface into /etc/
netplan/.
Netplan should be considered a unification layer on top of those networking daemons, which allows Debian as a project to use common language around networking, e.g. in Debian-Installer [d-i/netcfg !9], [cloud] deployments or [documentation], independent
of the chosen backend daemon (sd-networkd on Cloud & Server, NetworkManager on Desktop).
Additional benefits of Netplan:
* Already used on Debian Bookworm [cloud] images by default
* Well tested (big autopkgtest suite) and supported by a company
* Lots of knowledge, Q/A & tutorials on the internet, as its being used by millions of people since many years
* Proven track record, being the default for several Ubuntu LTS releases
* Python dependency considered optional, base installations only need the "netplan-generator" package
* Solid documentation and a stable API for libnetplan, as of [Netplan 1.0]
This would allow us to combine the best of two worlds, while leaving everybody with full flexibility for custom configurations.
In addition to that, I'd propose to keep ifupdown in maintenance mode for a transitional period (Trixie at least), to keep backwards compatibility for existing systems and give people some time in transitioning to new networking tools.
Cheers,
Lukas
PS: If you happen to be at Debconf in Korea in a few weeks, please join my [networking BoF].
[d-i/netcfg !9]
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9
[cloud]
https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/
[documentation]
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_cloud
[Netplan 1.0]
https://blog.slyon.de/2024/04/04/netplan-v1-0-paves-the-way-to-stable-declarative-network-management/
[networking BoF]
https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)