Hi all! After hosting a networking [bof] at DebConf 2024, consulting with the networking [team] and receiving comments from others on this mailing list, I'd like to summarize the state of affairs in our network tooling discussion and make a formal proposal of how we can move forward. The change from deprecated ISC dhclient to dhcpcd-base (Bug #1038882) has been a long time coming and was finally accepted (kudos to Martin-Éric, Santiago and Sean for moving that case forward!), but that's not enough and we should re-consider our full network stack. There's also a write-up on this case by LWN.net, if you're looking for another summary, but in the end it boils down to having consensus that we want to get off ifupdown/status quo (as has been discussed for so many years) and therefore we should to consider the modern and well-maintained alternatives that we have on the table: https://lwn.net/Articles/989055/ # Proposal My proposal is to enable a hybrid network stack, using systemd-networkd (on server/cloud/container/embedded systems) and NetworkManager (on desktop/laptop systems) unified through a common layer of Netplan configuration on top, to avoid fragmentation. This utilizes 3 tools that are under active upstream development and are already used as defaults in certain variants of Debian today. Furthermore, it allows people to control this stack on the native systemd-networkd/NetworkManager layer directly, while at the same time providing a way to describe network configuration that is common across Debian. I've repeated the reasons why I think a hybrid stack using Netplan is a feasible solution many times in previous threads, therefore I'd like to refer to a list of frequently asked questions, instead of spreading more reasons across more replies: https://wiki.debian.org/Netplan/FAQ # Why The ifupdown package is a Debian only solution that is becoming a maintenance burden. We've had plenty of discussions over the years and consensus is that we want to get rid of it. Some variations of Debian have already moved forward with choosing a different stack, such as desktop/laptop installations (using NetworkManager) and cloud images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern re-implementation of the classic tooling, that strives to become drop-in [compatible]. # How Initially, I suggested pulling the minimal "netplan-generator" package into the base installation, but discussions showed that that's not appreciated by fellow DDs and community members. So, I want to propose bumping to "Priority: standard" only, but using the "netplan.io" package (Netplan generator + CLI). This way, Netplan would only be installed and configured for new installations through Debian-Installer, when the "standard system utilities" task is selected. The "standard" task is very easy to opt-out from for people who do not want to use Netplan and already comes with the Python runtime pre-selected, which allows for installing the full Netplan CLI tooling, providing improved usability (e.g. "netplan status" commands) without too much overhead. Myself and others have already laid the technical groundwork in Debian-Installer [d-i], Calamares, FAI and autopkgtest tooling to have Netplan support readily available. So all we need to do is switching the "Priority" of the "netplan.io" binary package. # Compatibility We do not want to break existing systems or people that want to keep using the classic way of /etc/network/interfaces. Therefore, I'm intentionally NOT suggesting to remove ifupdown from the base installation. I would love to see it being replaced by ifupdown-ng, to reduce the maintenance burden of classic ifupdown. This means base installations would still come pre-installed with ifupdown[-ng] and systemd-networkd (as part of the systemd package). This leaves us with some network configuration fragmentation, but still feels like a reasonable step into the right direction. Dropping network related packages from the base installation is not part of this proposal. Let's keep this for another time, after Trixie is released. Thanks for considering my proposal. Cheers, Lukas PS: I know this proposal doesn't please everybody, but I think it's the most actionable option that we have on the table and strikes a good compromise. As a replacement for ifupdown is overdue, we should adopt our network stack for Trixie. Therefore, we should consider making a change at this time of the cycle, so that we still have plenty of time to test, fix integrations or roll back, should it turn out to be a bad decision. [bof] https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/ [team] https://tracker.debian.org/teams/networking/ [faq] https://wiki.debian.org/Netplan/FAQ [d-i] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [compatible] https://github.com/ifupdown-ng/ifupdown-ng/issues/247
Attachment:
signature.asc
Description: PGP signature