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/
