[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

proposal: Hybrid network stack for Trixie



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


Reply to: