proposal: Hybrid network stack for Trixie

[Lukas Märdian]

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

[Marco d'Itri]

Post by Lukas Märdian
PS: I know this proposal doesn't please everybody, but I think it's the most

Actually I cannot thing of your proposal having much support from
anybody else.
At this point I am starting to find annoying how hard you alone are
trying to push Netplan on Debian.

Post by Lukas Märdian
actionable option that we have on the table and strikes a good compromise. As a

This is not a "compromise". There is no other "more Netplan" option
which you are not considering.

[Bill MacAllister]

Post by Marco d'Itri

Post by Lukas Märdian
PS: I know this proposal doesn't please everybody, but I think it's the most

Actually I cannot thing of your proposal having much support from
anybody else.
At this point I am starting to find annoying how hard you alone are
trying to push Netplan on Debian.

Well, I for one, support the use of netplan.

Bill

[Chris Hofstaedtler]

Post by Lukas Märdian
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].

Thanks for providing the FAQ and this "Why" section, but it seems to
leave open why we would want or need netplan as the default. As the
FAQ shows, netplan is available as an optional package in many
distros. The same is already true in Debian thanks to you.

For your described usecase groups, which seem to clearly map to the
backends used by netplan, I do not see what netplan brings to the
table. The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.

Who actually wants the configuration interface of netplan,
especially by default?

I see nobody saying "yet another layer is a lot of fun!", and the
usecase groups do not overlap that much, that they both would *need*
the same interface? The opposite seems to apply.

Post by Lukas Märdian
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.

d-i could make (or offer) a choice between networkd and
NetworkManager. Doesn't have to be netplan. I can vaguely see how
d-i might be simpler by writing netplan config, but it still has to
make a choice of the default backend? And then what does netplan
help here?

Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.

Best,
Chris

[Marc Haber]

On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.

Ack. I'd love networkd to have some more robustness features, but
netplan doesnt add anything here.

Post by Chris Hofstaedtler
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.

nack. I truly despise the configuration interface of NetworkManager,
and I have never fully understood it. I still have NetworkManager on
my notebooks because it interfaces nicely with the clickable frontends
in the desktop environment. Will I continue to have that luxury if we
have netplan above n-m?

Another case are setups where some software expects to be able to
configure the network, with docker and libvirt being the most obvious
cases. libvirt comes with its own lay of indirection which has never
gotten enough traction to go beyond very basic support of ifupdown. I
don't know how this works, for example, on Ubuntu or Fedora.

Post by Chris Hofstaedtler
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.

I am all for d-i pre-choosing sane defaults for workstation/notebook
setups. The server people are likely to use the expert install, have
preseeded installs or their completely own installation methods.

Greetings
Marc

[Chris Hofstaedtler]

Post by Marc Haber
On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.

Ack. I'd love networkd to have some more robustness features, but
netplan doesnt add anything here.

Post by Chris Hofstaedtler
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.

nack. I truly despise the configuration interface of NetworkManager,
and I have never fully understood it. I still have NetworkManager on
my notebooks because it interfaces nicely with the clickable frontends
in the desktop environment.

TBH the "interfaces nicely with the clickable frontends" part is
what I meant here. I don't know if anyone likes nm-cli. When I use
NetworkManager on a desktop or laptop, then it is through one of the
GUI frontends. I assume this is what people want.

Post by Marc Haber
Will I continue to have that luxury if we have netplan above n-m?

Very good question.

As far as I understood Lukas' mail, then at least currently not, as
NM in Debian doesn't come with patches to support two-way
configuration with netplan. I would understand if the NetworkManager
maintainers in Debian don't want to apply them as a Debian patch;
without having looked at the patches, the whole objective sounds
like the patches would be quite intrusive.

Post by Marc Haber
I am all for d-i pre-choosing sane defaults for workstation/notebook
setups. The server people are likely to use the expert install, have
preseeded installs or their completely own installation methods.

As pointed out by Simon, this is already done depending on the
desktop selection. Which I didn't know, but sounds like the sane
thing to do!

Chris

[Jonathan Dowland]

Post by Chris Hofstaedtler
TBH the "interfaces nicely with the clickable frontends" part is
what I meant here. I don't know if anyone likes nm-cli.

I prefer it to `ip`, when I can get away with using it instead.

[Andrew M.A. Cater]

Post by Jonathan Dowland

Post by Chris Hofstaedtler
TBH the "interfaces nicely with the clickable frontends" part is
what I meant here. I don't know if anyone likes nm-cli.

I prefer it to `ip`, when I can get away with using it instead.

if you don't have a desktop environment on either a laptop or a server,
then nm-cli / nmtui are a very useful way to do this.

This whole discussion has made me think about trying networkd-systemd to
see what its like.

Andrew Cater

Post by Jonathan Dowland
--
Please do not CC me for listmail.
👱🏻 Jonathan Dowland
🔗 https://jmtd.net

[Hakan Bayındır]

Post by Chris Hofstaedtler
As far as I understood Lukas' mail, then at least currently not, as
NM in Debian doesn't come with patches to support two-way
configuration with netplan.

I think this is a very serious regression for desktop systems. Debian started shipping non-free firmware recently, enabling “one click networking (TM)” in terminal and desktop systems. Taking this capability away from users and expect them to fiddle with their system in the first five minutes to get this capability back will not help Debian’s image, esp. in the eyes of new users and beginners.

Not being able to work with plethora of NetworkManager GUIs already integrated into desktop environments out of the box is both very backwards and is one of the “Debianisms” which people want to prevent.

Best,

H.

[Simon McVittie]

Post by Chris Hofstaedtler
d-i could make (or offer) a choice between networkd and
NetworkManager.

d-i *already* makes a choice between ifupdown and NetworkManager: if
NM has been pulled in by a task's dependencies (e.g. this happens when
you install the GNOME or KDE desktop, among others), it writes out NM
config, else it writes out ifupdown config. I believe a 1:1 replacement
of ifupdown with networkd in the packages and configuration provided by
new installations would do what I think you're proposing.

Post by Chris Hofstaedtler
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional.

This is technically true, because sd-networkd is part of systemd.deb which
has Priority: optional, but in practice it gets pulled in by the init
metapackage on full/bootable systems (unless manual steps have been taken
to select a non-default init system).

Whether interfaces are configured by sd-networkd is a matter
of configuration, rather than what packages are installed:
if you want it to be responsible for bringing up networking,
you need to configure it (minimally by copying or symlinking
e.g. /usr/lib/systemd/network/80-ethernet.network.example
into /etc/systemd/network/) and enable it (systemctl enable
systemd-networkd.service).

smcv

[Josh Triplett]

Post by Simon McVittie

Post by Chris Hofstaedtler
d-i could make (or offer) a choice between networkd and
NetworkManager.

d-i *already* makes a choice between ifupdown and NetworkManager: if
NM has been pulled in by a task's dependencies (e.g. this happens when
you install the GNOME or KDE desktop, among others), it writes out NM
config, else it writes out ifupdown config. I believe a 1:1 replacement
of ifupdown with networkd in the packages and configuration provided by
new installations would do what I think you're proposing.

There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.

Currently, NetworkManager has a plugin for ifupdown; it doesn't allow NM
to *manage* interfaces handled by ifupdown (other than bringing them up
or down), but it's enough to ensure that NM doesn't disrupt
ifupdown-managed networking. (That's important, for instance, to make
sure that installing NetworkManager doesn't abruptly disrupt the
network mid-install.)

I am *not* suggesting that a prerequisite would be any kind of *full*
integration with networkd that allows NM to meaningfully configure it.
I'm suggesting that, with systemd-networkd installed and managing some
interfaces, installing NetworkManager should not touch those interfaces
in any way. (Ideally, NM guis would also give some indication of "you
might want to remove the networkd configuration if you want NM to manage
these interfaces, such as automatically switching between wired and
wireless".)


Apart from that, +1 for the plan of choosing between networkd and
NetworkManager, and *not* introducing any layer of indirection. The
primary point of NetworkManager is to support its
management/configuration GUIs, so we *especially* shouldn't have a layer
of indirection that doesn't treat the GUI-based configuration as
primary.

[Andrea Pappacoda]

Post by Josh Triplett
There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.

If I'm interpreting correctly what you mean, this should already be
possible, see <https://mastodon.social/@pid_eins/112398647693125514>.

[Josh Triplett]

Post by Andrea Pappacoda

Post by Josh Triplett
There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.

If I'm interpreting correctly what you mean, this should already be

That's exactly what I mean, and that looks promising! As long as the
version of NetworkManager in Debian supports that, this should work
perfectly out of the box, even when a user installs a non-GUI system and
later installs a GUI that includes NetworkManager.

[Lukas Märdian]

Post by Josh Triplett

Post by Andrea Pappacoda

Post by Josh Triplett
There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.

If I'm interpreting correctly what you mean, this should already be

That's exactly what I mean, and that looks promising! As long as the
version of NetworkManager in Debian supports that, this should work
perfectly out of the box, even when a user installs a non-GUI system and
later installs a GUI that includes NetworkManager.

It's great that we now have a more standardize way to define this in udev!

In Netplan we faced this issue a lot over the years, when users had
configurations using multiple backends at the same time, e.g. some
interfaces set to "renderer: networkd" while others were set to
"renderer: NetworkManager" in their Netplan configuration.

It was solved by controlling the ENV{NM_UNMANAGED}="0" variable via udev
rules and configuring the [device-*].managed={true,false} NetworkManager
settings accordingly.

-- Lukas

[Lukas Märdian]

Post by Chris Hofstaedtler

Post by Lukas Märdian
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].

Thanks for providing the FAQ and this "Why" section, but it seems to
leave open why we would want or need netplan as the default. As the
FAQ shows, netplan is available as an optional package in many
distros. The same is already true in Debian thanks to you.

As described in the "Proposal" section and first answer of the FAQ, it's all
about consistency.

There seems to be a tendency for moving towards a hybrid stack, using
sd-networkd and NetworkManager in different contexts/use-cases. But having
fragmented ways of doing network configuration provides bad UX, as it can
confuse users, who first need to understand what sortf of Debian they are
using, before looking for solutions.

Netplan solves this and allows for providing common solution that work
across the system.

The Netplan tooling around that, like "netplan status" or "netplan try"
to query/debug the network configuration or apply, but roll-back
configuration, in case it did not work out as expected, are only added
benefits.

Post by Chris Hofstaedtler
For your described usecase groups, which seem to clearly map to the
backends used by netplan, I do not see what netplan brings to the
table. The "server" group supposedly wants (and I agree) networkd,
but they also want the configuration interface of networkd.
The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.
Who actually wants the configuration interface of netplan,
especially by default?
I see nobody saying "yet another layer is a lot of fun!", and the
usecase groups do not overlap that much, that they both would *need*
the same interface? The opposite seems to apply.

It's sad to see that fellow DDs do not seem to care about consistency
and usability in this regard.

Post by Chris Hofstaedtler

Post by Lukas Märdian
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.

d-i could make (or offer) a choice between networkd and
NetworkManager. Doesn't have to be netplan. I can vaguely see how
d-i might be simpler by writing netplan config, but it still has to
make a choice of the default backend? And then what does netplan
help here?
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional. As
in, even if we would go with netplan in d-i, there is no "default"
anymore and people have to make choices.

As stated below, d-i already makes this choice between ifupdown,
NetworkManager and Netplan, depending on context of installed packages
in the target system. There's also a (stale?) MR to add systemd-networkd
to the mix [1].

Personally, I do not necesarily think showing more options to the users
is better. But I've heard this being suggested several times. So how
do others think about having a network-stack selection in
debian-installer/tasksel? Similar to the desktop-stack selection.

Cheers,
Lukas

[1] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/11

[Marco d'Itri]

Post by Lukas Märdian
As described in the "Proposal" section and first answer of the FAQ, it's all
about consistency.
There seems to be a tendency for moving towards a hybrid stack, using
sd-networkd and NetworkManager in different contexts/use-cases. But having
fragmented ways of doing network configuration provides bad UX, as it can
confuse users, who first need to understand what sortf of Debian they are
using, before looking for solutions.

The problem with this argument is that neither systemd-networkd, nor
NetworkManager, nor ifupdown users are asking for a unified
configuration system, which also happens to be different from what they
are already used to.

Post by Lukas Märdian
It's sad to see that fellow DDs do not seem to care about consistency
and usability in this regard.

I think it's good that fellow DDs are wary of adding an indirection
layer which nobody asked for.

[Marvin Renich]

Post by Lukas Märdian
As described in the "Proposal" section and first answer of the FAQ, it's all
about consistency.
There seems to be a tendency for moving towards a hybrid stack, using
sd-networkd and NetworkManager in different contexts/use-cases. But having
fragmented ways of doing network configuration provides bad UX, as it can
confuse users, who first need to understand what sortf of Debian they are
using, before looking for solutions.
Netplan solves this and allows for providing common solution that work
across the system.

If we had a single network stack that provided a good user interface for
all use cases, that would be great, but we don't anymore (ifupdown used
to be that, a long time ago, which is one of the reasons it is still
around).

Adding a "compatibility layer" that gives a common user interface on top
of multiple different network stacks does not make sense. The people
that _might_ benefit from this fall into two basic categories: novices
and the people who need to configure networking on many different
systems.

Novices are going to accept the default network stack on a desktop
system. They are unlikely to care about networking on any system other
than ones with a desktop installed, and they are only going to use the
GUI provided by the desktop system. They will completely ignore the
"compatibility layer". If they are forced to use a system without their
favorite GUI network widget installed, they will have to learn a second
network stack, whether it is another "native" stack or the
"compatibility layer". _No benefit!_

People who need to configure networking on many different systems need
to learn multiple network stacks, period. Having the "compatibility
layer" as a default, rather than a forced mandatory, means that enough
people with more than a beginner's knowledge of networking are going to
choose the stack more suited to the purpose of their particular
installation, uninstalling or ignoring the "compatibility layer", to
make it necessary for anyone doing networking on a variety of systems to
learn multiple stacks. Adding one more _unnecessary_ "compatibility
layer" is just one more stack to learn. _No benefit!_

I think you realize what would happen if you proposed making netplan a
"forced mandatory" compatibility layer!

Please, can we drop this proposal and this thread?

...Marvin

[Didier 'OdyX' Raboud]

Post by Lukas Märdian

Post by Chris Hofstaedtler

Post by Lukas Märdian
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].

Thanks for providing the FAQ and this "Why" section, but it seems to
leave open why we would want or need netplan as the default. As the
FAQ shows, netplan is available as an optional package in many
distros. The same is already true in Debian thanks to you.

As described in the "Proposal" section and first answer of the FAQ, it's all
about consistency.
There seems to be a tendency for moving towards a hybrid stack, using
sd-networkd and NetworkManager in different contexts/use-cases. But having
fragmented ways of doing network configuration provides bad UX, as it can
confuse users, who first need to understand what sortf of Debian they are
using, before looking for solutions.
Netplan solves this and allows for providing common solution that work
across the system.
The Netplan tooling around that, like "netplan status" or "netplan try"
to query/debug the network configuration or apply, but roll-back
configuration, in case it did not work out as expected, are only added
benefits.

It sounds like having netplan be *available for install* solves that nicely if
one cares about consistency across their fleet of Debian hosts; just make sure
(via d-i preseed, cloud-init, etc) to install netplan when bootstrapping
machines/VM/hosts, and you're good to go, right?

I don't see any additional benefit by enforcing it on all installs by default,
as has been eloquently explained already.

[Daniel Baumann]

Post by Lukas Märdian
It's sad to see that fellow DDs do not seem to care

It's sad to see that in this and the other thread before, the same weak
arguments in favour of netplan are repeated by you without neither
adressing the valid points raised against it, nor providing an actual
counter argument to the discussion: for every point you're making to use
netplan, people pointed out better alternatives to actually do make
things better at the source.

Or in other words - my impression for netplan in one sentence is
"introducing an additional layer to paint over (valid) papercut-bugs
rather than fixing them properly in the original tools or documentation".

In Debian we stick to do the right thing, so, "thanks but no thanks" for
netplan.

Post by Lukas Märdian
about consistency and usability in this regard.

like consistency with any other linux distribution? wrt/ sd-networkd: in
the broader linux community we've pretty much standardized on systemd as
the init system. it just makes no sense to use sd-networkd with an
additional layer on top that nobody else is using. that's cross-distro
consistency and usability that we care for in the plumbing.

Regards,
Daniel

[Simon Richter]

Hi,

The "server" group supposedly wants (and I agree) networkd, but they also want the configuration interface of networkd.

I'm not sure about that -- I'd expect the "server" group to be split into

- "pets": their IP address doesn't change often anyway, anything
beyond "set IP address during boot" is bloat. ifupdown is bloat because
it requires a python interpreter to do what a one-line shell script can
do, and networkd is bloat because it runs an entire service to do nothing.

Nobody cares about either kind of bloat, because resources are cheap --
what people do care about is interface stability, which is why switching
the interface naming scheme was so controversial back then.

- "cattle": the IP configuration comes from a central place, and is
integrated with asset management. If it's a small operation, they use
DHCP, but anything more sophisticated brings their own management
solution, and whatever system we provide needs to be able to go out of
the way.

- "container": the IP address is managed from outside. The OS
installation we generate should not interfere.

The "laptop" group supposedly wants (and I agree) NetworkManager,
but they also want the configuration interface of NetworkManager.

They specifically want the user interface. The configuration interface
is less of a contract and more of a guideline, but that doesn't matter
to the users, because they will only ever use the integrated solution
where system and UI components are provided by the same package, and are
kept consistent that way.

Providing a typesafe interface for passing the privilege-separation
boundary is hard, but it is much more difficult if that interface also
needs to be long-term stable. Anything that wants to replace N-M is
either a rewrite with the same basic structure (tightly coupled
interfaces on both sides of the privilege separation boundary, upgraded
in lock step) or a massive sink of manpower that, frankly, no one has.

Who actually wants the configuration interface of netplan,
especially by default?

I can see it in the server space, because we need the integration with
other tools that contribute fragments of network configuration without
wanting to take over (libvirt and docker), and with tools that take over.

Integrating these tools into a consistent whole would be the core task
of a distribution.

ifupdown defines a policy that works reasonably well on servers: "do not
interfere." That is, if libvirt or docker change something because they
need it (like moving the default route into a bridge), then ifupdown
does not revert that change. It's shit, but it works.

systemd-networkd, for good reasons, deviates from this, but this means
further integration work is required from the distribution because the
end result needs to be consistent again. If netplan can provide the
"consistent whole", then it makes sense not to reinvent the wheel.

My expectation as a user is that I should be able to install libvirt and
docker on a server, and configure bridged networking in both without
losing connectivity.

Right now, it works by accident, which is bad, but breaking it in the
name of correctness will make a lot of people very angry, like renaming
all the interfaces or requiring "nofail" in the fstab to continue
booting did.

Simon

[Ansgar 🙀]

Hi,

Post by Lukas Märdian
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

The FAQ states: "If native backend configuration is applied on top of
that, Netplan will now know, nor care about it (unless they try to
configure an interface controlled by Netplan in a conflicting way)."

What does that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?

Ansgar

[Lukas Märdian]

Hi!

Post by Ansgar 🙀

Post by Lukas Märdian
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

The FAQ states: "If native backend configuration is applied on top of
that, Netplan will now know, nor care about it (unless they try to
configure an interface controlled by Netplan in a conflicting way)."
What does that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?

This is a very good question, also asked by Chris above.

If users want to control their network configuration through the NetworkManager
UI, they can just continue to do that as always, it's a case of configuration at
the native layer. NM will continue to function as always, storing its profiles
in /etc/NetworkManager/system-connections. Netplan would not know about those
connection-profiles, but would not interfere, as long as people do not try to
configure the same interface through /etc/netplan/ settings.

The benefit that Netplan would provide in such cases is that debian-installer
installs a /etc/netplan/01-network-manager-all.yaml config file, reading:

network:
version: 2
renderer: NetworkManager

This sets Netplan's default renderer to NetworkManager, so that any configuration
added in /etc/netplan/ would show up in the NetworkManager UI, and the interface
will be handled by the NetworkManager daemon. Still, config files in /etc/netplan/
need to be driven through Netplan settings.

In Ubuntu we carry patches, which had been discussed with [upstream] (but were
rejected back then). Those might need some more refinement before wider adoption.
Those allow to configure interfaces through Netplan and NetworkManager at the same
time, e.g. a config originating from /etc/netplan/ can be modified via the UI tooling
provided by NetworkManager. In my [blog] I wrote about how we utilize this in Ubuntu.

Cheers,
Lukas

[blog] https://blog.slyon.de/2023/11/12/netplan-brings-consistent-network-configuration-across-desktop-server-cloud-and-iot/
[upstream] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

[Ansgar 🙀]

Hi,

Post by Lukas Märdian

Post by Ansgar 🙀

Post by Lukas Märdian
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

The FAQ states: "If native backend configuration is applied on top of
that, Netplan will now know, nor care about it (unless they try to
configure an interface controlled by Netplan in a conflicting way)."
What does that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?

This is a very good question, also asked by Chris above.
If users want to control their network configuration through the NetworkManager
UI, they can just continue to do that as always, it's a case of configuration at
the native layer. NM will continue to function as always, storing its profiles
in /etc/NetworkManager/system-connections. Netplan would not know about those
connection-profiles, but would not interfere, as long as people do not try to
configure the same interface through /etc/netplan/ settings.
The benefit that Netplan would provide in such cases is that debian-installer
   version: 2
   renderer: NetworkManager

So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?

And if it does manage some interfaces, it is probably a regression to
break GUI network management...

Ansgar

[Lukas Märdian]

Post by Ansgar 🙀

Post by Lukas Märdian

Post by Ansgar 🙀

Post by Lukas Märdian
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

The FAQ states: "If native backend configuration is applied on top of
that, Netplan will now know, nor care about it (unless they try to
configure an interface controlled by Netplan in a conflicting way)."
What does that mean on desktop systems? What will happen when a user
wants to change the configuration using the UI (which usually talks to
NetworkManager)?

This is a very good question, also asked by Chris above.
If users want to control their network configuration through the NetworkManager
UI, they can just continue to do that as always, it's a case of configuration at
the native layer. NM will continue to function as always, storing its profiles
in /etc/NetworkManager/system-connections. Netplan would not know about those
connection-profiles, but would not interfere, as long as people do not try to
configure the same interface through /etc/netplan/ settings.
The benefit that Netplan would provide in such cases is that debian-installer
   version: 2
   renderer: NetworkManager

So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?

Because it allows to add configuration in a way that is common with server, cloud
and other instances of Debian. It's not about enforcing this, or breaking people's
use-cases. But about working towards unified network configuration.

-- Lukas

[Richard Lewis]

Post by Lukas Märdian

Post by Ansgar 🙀

Post by Lukas Märdian
The benefit that Netplan would provide in such cases is that
debian-installer
   version: 2
   renderer: NetworkManager

So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?

Because it allows to add configuration in a way that is common with server, cloud
and other instances of Debian

Could you give an example of why this is useful to unify?

For example: is there a scenario in which someone is using
systemd-networkd but then finds they need to do X, which they cant
essily do using systend but which nm support is better--- therefore if
they are using netplan they can simply install network-manager, change a
netplan setting and gain X with no need to understand the differences
between the network-manager and systemd configuration languages?

(or swapping the roles of NM and systemd-neyworkd, or using ifupdown99
instead)

[Lukas Märdian]

Post by Richard Lewis

Post by Lukas Märdian

Post by Ansgar 🙀

Post by Lukas Märdian
The benefit that Netplan would provide in such cases is that debian-installer
   version: 2
   renderer: NetworkManager

So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?

Because it allows to add configuration in a way that is common with server, cloud
and other instances of Debian

Could you give an example of why this is useful to unify?
For example: is there a scenario in which someone is using
systemd-networkd but then finds they need to do X, which they cant
essily do using systend but which nm support is better--- therefore if
they are using netplan they can simply install network-manager, change a
netplan setting and gain X with no need to understand the differences
between the network-manager and systemd configuration languages?

My ideas was not so much about switching from one networking daemon to another.
In most cases users will probably stick to the network stack of their chosen
environment. With systemd-networkd and NetworkManager being good candidates for
their corresponding scenarios.

But knowledge builds up over the years in our community and spreads around forums,
stack overflow, etc.

Those are the places where we figure out "How to setup a bond on Debian?",
"How to connect a headless embedded board to the WiFi network" or "How to change
the embedded-switch mode on SR-IOV physical functions?". We find solutions and
help each other out, which is great!

But with fragmented network-configuration tooling those solutions will not work
in many cases, as they depend on a specific context of the base-image in use
(e.g. server vs desktop vs embedded vs cloud).

With Netplan I'm hoping to avoid such frustration by providing a way to configure
the network that works independently of the base-image context. Of course without
forcing people to use it or impacting the lower layer to be configured directly.

-- Lukas

[Ansgar 🙀]

Hi,

Post by Lukas Märdian
My ideas was not so much about switching from one networking daemon to another.
In most cases users will probably stick to the network stack of their chosen
environment. With systemd-networkd and NetworkManager being good candidates for
their corresponding scenarios.
But knowledge builds up over the years in our community and spreads around forums,
stack overflow, etc.
Those are the places where we figure out "How to setup a bond on Debian?",
"How to connect a headless embedded board to the WiFi network" or "How to change
the embedded-switch mode on SR-IOV physical functions?". We find solutions and
help each other out, which is great!
But with fragmented network-configuration tooling those solutions will not work
in many cases, as they depend on a specific context of the base-image in use
(e.g. server vs desktop vs embedded vs cloud).
With Netplan I'm hoping to avoid such frustration by providing a way to configure
the network that works independently of the base-image context. Of course without
forcing people to use it or impacting the lower layer to be configured directly.

But this only works for features for which all the following is true:

1. The feature is supported by systemd-networkd,
2. The feature is also supported by NetworkManager,
3. The feature is also supported by netplan.

Any feature not supported by all three will lead to fragmentation: one
would first have to make sure to switch to, for example, the
NetworkManager backend, but then might just find out that netplan
doesn't support the feature and one has to configure NetworkManager
without netplan anyway.

At that point just making NM the default without additional layers
might be better: the feature set covered by just

- The feature is supported by NetworkManager

is larger than the earlier feature set.

Ansgar

[Bjørn Mork]

Post by Lukas Märdian

Post by Ansgar 🙀
So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?

Because it allows to add configuration in a way that is common with server, cloud
and other instances of Debian. It's not about enforcing this,

So using netplan is optional. The system will work as before without
netplan. netplan won't replace any packages. NM, systemd-networkd or
ifupdown* are still required with or without netplan.

What are we discussing here, actually? Making someones pet project
default to increase the install count? No thanks. That's bloat.


Bjørn

[Steve Langasek]

Post by Ansgar 🙀
So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?
And if it does manage some interfaces, it is probably a regression to
break GUI network management...

As a longtime Ubuntu desktop power user, I can tell you concretely that I
made use of this because I absolutely 100% wanted NetworkManager to manage
the wifi interface on my laptop (correctly selecting networks from the list
of those available an autoconnecting, etc) and I also absolutely 100% did
NOT want NetworkManager managing my ethernet port and had it configured via
netplan instead.

[Ansgar 🙀]

Hi Steve,

Post by Steve Langasek

Post by Ansgar 🙀
So on desktop installations including NetworkManager, netplan will be
configured to do nothing? Why install netplan at all on desktop systems
then?
And if it does manage some interfaces, it is probably a regression to
break GUI network management...

As a longtime Ubuntu desktop power user, I can tell you concretely that I
made use of this because I absolutely 100% wanted NetworkManager to manage
the wifi interface on my laptop (correctly selecting networks from the list
of those available an autoconnecting, etc) and I also absolutely 100% did
NOT want NetworkManager managing my ethernet port and had it configured via
netplan instead.

And you think that using two different network managers for different
interfaces, here NetworkManager and netplan using either NetworkManger
or systemd-networkd, on desktop systems is such a common configuration
that we should install netplan by default to enable this?

I would expect this to be a quite uncommon scenario, not something that
must be covered by the selection of packages included in the default
install.

Ansgar

[Sirius]

On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote:
[snip]

Post by Lukas Märdian
# 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

If at all possible, permit it to also run without systemd and/or
Network-Manager in the mix, for use-cases where all the bells and whistles
(and complications, and deep integration into things it does not need to
integrate into, nor necessarily should integrate into, like SSH server)
is not required.

To have Netplan as an option (which should be the case for systemd and
Network-Manager as well, options) seems very sensible IMHO.

Post by Lukas Märdian
# 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].

Question: is ifupdown-ng geared at replacing ifupdown as soon as the next
major release, and should those that today use ifupdown migrate to
ifupdown-ng proactively? And does Netplan generate ifupdown-ng
configuration, or it this strictly a helper-tool for systemd/NM?

Post by Lukas Märdian
# Compatibility
We do not want to break existing systems or people that want to keep using the
classic way of /etc/network/interfaces.

Very glad to hear that.

[Jonas Smedegaard]

Quoting Sirius (2024-09-22 17:22:21)

Post by Sirius
[snip]

Post by Lukas Märdian
# 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

If at all possible, permit it to also run without systemd and/or
Network-Manager in the mix, for use-cases where all the bells and whistles
(and complications, and deep integration into things it does not need to
integrate into, nor necessarily should integrate into, like SSH server)
is not required.
To have Netplan as an option (which should be the case for systemd and
Network-Manager as well, options) seems very sensible IMHO.

Netplan seems like *different* bells and whistles, rather than none.

If you want no belss or whistles, then install neither of ifupdown,
network-manager nor systemd-networkd, and operate your network using ip
and (unless you also consider that a too large bell) iwd.


- Jonas

[Sirius]

Post by Jonas Smedegaard
Netplan seems like *different* bells and whistles, rather than none.

True.

Post by Jonas Smedegaard
If you want no belss or whistles, then install neither of ifupdown,
network-manager nor systemd-networkd, and operate your network using ip
and (unless you also consider that a too large bell) iwd.

I did switch to ifupdown-ng (as it seems the regular ifupdown is on its
way out) and the one thing I noticed was that ifupdown-ng does not handle
the include directive for /etc/network/interfaces.d/. Not a big issue, did
not take long to consolidate the interfaces into /etc/network/interfaces
and then it works great.

iwd and ifupdown{,-ng} works, and works well, but what I like about them
most is that they have lean dependencies and focus on one thing in true
unix fashion. I can sidestep both systemd and Network-Manager entirely
with a few rebuilt packages. That works for me.

[Daniel Gröber]

Hi Sirius,

Thanks for taking ifupdown-ng for a spin.

Post by Sirius

Post by Jonas Smedegaard
If you want no belss or whistles, then install neither of ifupdown,
network-manager nor systemd-networkd, and operate your network using ip
and (unless you also consider that a too large bell) iwd.

I did switch to ifupdown-ng (as it seems the regular ifupdown is on its
way out) and the one thing I noticed was that ifupdown-ng does not handle
the include directive for /etc/network/interfaces.d/.

I think you're using the version in stable? I upstreamed a patch for
'source' stanza glob pattern support as we use for interfaces.d a while
ago. We've had it in Debian since 0.12.1-1, but its not in stable. I'll
upload a backport as soon as I feel -ng is ready.

Post by Sirius
iwd and ifupdown{,-ng} works, and works well, but what I like about them
most is that they have lean dependencies and focus on one thing in true
unix fashion. I can sidestep both systemd and Network-Manager entirely
with a few rebuilt packages. That works for me.

When using ifupdown with wpa_supplicant we have per-SSID configuration
support (cf. wpa_action.8) I wonder if a similar integration would be
possible with iwd?

--Daniel

[Sirius]

Post by Daniel Gröber
Hi Sirius,
Thanks for taking ifupdown-ng for a spin.

No problem at all. Thank you for being patient for my response, I have
been working out some kinks around finit to get the system spitting out a
graphical session. :-D

Post by Daniel Gröber

Post by Sirius
I did switch to ifupdown-ng (as it seems the regular ifupdown is on its
way out) and the one thing I noticed was that ifupdown-ng does not handle
the include directive for /etc/network/interfaces.d/.

I think you're using the version in stable? I upstreamed a patch for
'source' stanza glob pattern support as we use for interfaces.d a while
ago. We've had it in Debian since 0.12.1-1, but its not in stable. I'll
upload a backport as soon as I feel -ng is ready.

I am. It really is no problem, it arrives when it arrives. In the
meantime, having the stanzas directly in /etc/network/interfaces works. No
problem at all.

Post by Daniel Gröber

Post by Sirius
iwd and ifupdown{,-ng} works, and works well, but what I like about them
most is that they have lean dependencies and focus on one thing in true
unix fashion. I can sidestep both systemd and Network-Manager entirely
with a few rebuilt packages. That works for me.

When using ifupdown with wpa_supplicant we have per-SSID configuration
support (cf. wpa_action.8) I wonder if a similar integration would be
possible with iwd?

With iwd, you run iw and then find the SSID and give it the secret for the
SSID and it then stores that in its database. As long as system dbus and
iwd is running when you ifup the interface, it works. No wpa_supplicant
needed.

And while it may be an Intel piece of software, it works with any wifi
card. My system has a MediaTek and it works just as well as the Intel card
on my laptop.

[Holger Levsen]

hi,

I miss ifupdown2 in this discussion.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Change is coming whether you like it or not.

[Chris Hofstaedtler]

Post by Holger Levsen
I miss ifupdown2 in this discussion.

In the older thread, it was pointed out that ifupdown2 might be
currently in a bad place maintenance-wise;
https://github.com/CumulusNetworks/ifupdown2/pulse/monthly and
https://github.com/CumulusNetworks/ifupdown2/graphs/contributors
could be indicative.

But I guess the reason ifupdown2 is absent from the discussion is,
because nobody in the discussion so far was seriously looking
forward to ifupdown2 becoming one of the defaults?

Chris

[Holger Levsen]

Post by Chris Hofstaedtler

Post by Holger Levsen
I miss ifupdown2 in this discussion.

In the older thread, it was pointed out that ifupdown2 might be
currently in a bad place maintenance-wise;
https://github.com/CumulusNetworks/ifupdown2/pulse/monthly and
https://github.com/CumulusNetworks/ifupdown2/graphs/contributors
could be indicative.

or development slowed down because it does it's job?

this OTOH is quite an impressive graph:
https://qa.debian.org/popcon.php?package=ifupdown2

Post by Chris Hofstaedtler
But I guess the reason ifupdown2 is absent from the discussion is,
because nobody in the discussion so far was seriously looking
forward to ifupdown2 becoming one of the defaults?

ifupdown2 is like ifupdown, just rewritten in python.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

There are many ways to kill. You can stab someone in the guts, take their bread
away, not heal someone from disease, put someone in a bad living space, work
someone to death, drive them to suicide, lead someone to war etc. Only few of
these are prohibited in our state." (Bertolt Brecht)

[Marco d'Itri]

Post by Holger Levsen
ifupdown2 is like ifupdown, just rewritten in python.

Yes, that's the problem: there was a consensus that it is not an
appropriate dependency for the base system.
ifupdown2 will still be around for anybody who wants to install it.

[Lukas Märdian]

Post by Marco d'Itri

Post by Holger Levsen
ifupdown2 is like ifupdown, just rewritten in python.

Yes, that's the problem: there was a consensus that it is not an
appropriate dependency for the base system.
ifupdown2 will still be around for anybody who wants to install it.

Quoting Julien:
"Back in 2016, with Cumulus, we had the goal and ambition to become the default debian network manager, but we realized that the python dependency would be a blocker, so we don't have that goal anymore. And we are happy with the way things are now, supporting our community users and customers."

See: https://lists.debian.org/debian-devel/2024/07/msg00204.html

[Holger Levsen]

Post by Marco d'Itri

Post by Holger Levsen
ifupdown2 is like ifupdown, just rewritten in python.

Yes, that's the problem: there was a consensus that it is not an
appropriate dependency for the base system.

ah! thanks for pointing this out.

Post by Marco d'Itri
ifupdown2 will still be around for anybody who wants to install it.

sure.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Just today, over 800 women will have died due to preventable pregnancy and
birth complications, over 130 due to femicide.
https://www.who.int/news-room/fact-sheets/detail/maternal-mortality
https://en.wikipedia.org/wiki/Femicide#Worldwide

[Chris Hofstaedtler]

Post by Marco d'Itri
ifupdown2 will still be around for anybody who wants to install it.

sure.

Except that right now it has an open r-c bug since June 25, and is
missing from testing since August 6th.

If people want to continue having it, somebody who wants to work on
it needs to be found.

https://bugs.debian.org/1074250
Upstream has applied the trivial fix, but somehow that needs to flow
into Debian too.

Chris

[Pierre-Elliott Bécue]

Post by Lukas Märdian
# 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.

I like ifupdown. It's simple and just works.

IDK what consensus you're talking about, but I'm clearly not part of it.

[Chris Hofstaedtler]

Post by Pierre-Elliott Bécue

Post by Lukas Märdian
# 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.

I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

It's certainly limited in what it can do within reasonable
configuration effort, and it often works. I think both are true for
almost all of the discussed options :-)

Chris

[Daniel Gröber]

Post by Chris Hofstaedtler

Post by Pierre-Elliott Bécue
I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

The "discussion" was about ***@eth0 being in a failed state on a
particular server due to a DAD failure and someone having to manually
intervene.

Chris, what behaviour do you expect here? Below I'm going to assume what
you're getting at is that we should continue to retry DAD.

To me going to a stable failure state seems desirable. Continuing to re-try
for IPs could cause instability in the face of legitimate address
conflicts: when the owning machine reboots the conflicting machine would
now win the IP due to continous retrying. The change in owner would cause
disruption to services entirely unrelated to the machine that was just
rebooted.

Sounds like the setup for a very drawn out and frustrating debugging story
to me.

--Daniel

Post by Chris Hofstaedtler
5.4.5. When Duplicate Address Detection Fails
[...] If the address is a link-local address formed from an interface
identifier, the interface SHOULD be disabled.

[Enhanced DAD] while not directly applicable seems to be under the

Post by Chris Hofstaedtler
3.3. Operational Considerations
[...]the noncompliant device would
follow current behavior and disable IPv6 on that interface due to DAD
until manual intervention restores it.

[ADDRCONF]: RFC 2462 - IPv6 Stateless Address Autoconfiguration
[Enhanced DAD]: RFC 7527 - Enhanced Duplicate Address Detection

[Philipp Kern]

Post by Daniel Gröber

Post by Chris Hofstaedtler

Post by Pierre-Elliott Bécue
I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

particular server due to a DAD failure and someone having to manually
intervene.

I find my ghost being invoked here.

Post by Daniel Gröber
Chris, what behaviour do you expect here? Below I'm going to assume what
you're getting at is that we should continue to retry DAD.
To me going to a stable failure state seems desirable. Continuing to re-try
for IPs could cause instability in the face of legitimate address
conflicts: when the owning machine reboots the conflicting machine would
now win the IP due to continous retrying. The change in owner would cause
disruption to services entirely unrelated to the machine that was just
rebooted.

DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The
kernel subsequently succeeded to configure the network. The script in
question was added in response to [1] and [2] to have a pause during
boot to give the kernel time to resolve the situation before continuing
the bootup. So it left the race around because there's not that much it
can do better as a script-based setup without much state.

Unfortunately there's zero information from ***@eth0 in the process as
to when that happened. Which adds to the frustrating debugging stories
when you can't get enough intel about what happened after the fact.
(Which to be fair, also probably needs env vars to be set with
systemd-networkd to increase the debug level.) As far as I can see
processes started listening on the IP in question (that... again...
wasn't logged because it's eaten by the script) a second afterwards.

So no, it did not enter a stable state. It let the kernel do its thing,
which was to actually enable the address. I don't know why it takes
Linux to run DAD for that long and what the assumptions around that are.
But if you listen on netlink you learn when that happens and don't need
to poll and could send events once that happens.

To be ultimately fair to ifupdown: There was probably not much of a
winning move here. The annoying bit was the systemd service that was
still in a failed state even though the failure condition resolved
itself <1s later.

Kind regards
Philipp Kern

[1] https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705996

[Noah Meyerhans]

Post by Philipp Kern

Post by Daniel Gröber

Post by Chris Hofstaedtler

Post by Pierre-Elliott Bécue
I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

particular server due to a DAD failure and someone having to manually
intervene.

I find my ghost being invoked here.

Post by Daniel Gröber
Chris, what behaviour do you expect here? Below I'm going to assume what
you're getting at is that we should continue to retry DAD.
To me going to a stable failure state seems desirable. Continuing to re-try
for IPs could cause instability in the face of legitimate address
conflicts: when the owning machine reboots the conflicting machine would
now win the IP due to continous retrying. The change in owner would cause
disruption to services entirely unrelated to the machine that was just
rebooted.

DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The kernel
subsequently succeeded to configure the network. The script in question was
added in response to [1] and [2] to have a pause during boot to give the
kernel time to resolve the situation before continuing the bootup. So it
left the race around because there's not that much it can do better as a
script-based setup without much state.

I'm not familiar with the discussion on #debian-admin, so the details
may be different, but I can point to a specific use case where we want
DAD/SLAAC failure handled without marking the interface as failed. The
cloud team wanted to produce working images that would support both
IPv4-only and dualstack environments transparently, without knowing the
type of environment in advance or requiring admin intervention. [1]

We ended up coming up with something that worked, but it would have been
nice if ifupdown could have handled this more gracefully. [2]

We have since transitioned to systemd-networkd and netplan; bullseye is
the last generation of cloud images to use ifupdown. Although the above
issue certainly contributed to this decision, the primary driver for the
netplan change was the cloud-init integration.

noah

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396#17
2. https://salsa.debian.org/cloud-team/debian-cloud-images/-/tree/master/config_space/bullseye/files/etc/network

[Pierre-Elliott Bécue]

Post by Chris Hofstaedtler

Post by Pierre-Elliott Bécue

Post by Lukas Märdian
# 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.

I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

Still looking for the funny bit, except if you're implying that as a DSA
member, I should dislike ifupdown because Philipp had to manually
intervene on a server managed by it. In that case it'd indeed be really
funny, but probably not for the reason you'd think it is.

Post by Chris Hofstaedtler
It's certainly limited in what it can do within reasonable
configuration effort, and it often works. I think both are true for
almost all of the discussed options :-)

Well, netplan has no added value in my environments, contrary to some
big changes we had in the past (systemd, journald - which still forwards
logs to rsyslog, 
), so I'd rather not being force-fed this tool. I'd
react the same if someone were to try making me adopt resolved or
timesyncd.

But in the whole, I don't care that much, I'm perfectly fine with apt
purge netplan.io after bootstrapping a server if the "consensus" is to
force-feed it.

[Antoine Beaupré]

It seems to me this proposal is just a *tad* too ambitious.

I haven't followed the entirety of all threads about this topic (has
anyone?) but it seems to me we're proposing to do two major changes at
once:

1. replace ifupdown with systemd-networkd
2. unify configuration of networkd and NetworkManager with netplan

*Either* of those seems somewhat controversial to me, and after reading
a few messages in this thread, seems that neither has reached consensus.

For example, in my personal opinion, even if netplan could work with an
ifupdown backend (and it can't!) I wouldn't support #2 here. I don't see
why I would need a unified configuration layer between ifupdown (or
systemd-networkd) and NM, it basically never has been a use case for
me. I either configure servers (in which case i use ifupdown or
networkd) or desktops (in which case I use NM).

And then, of course, there's the "systemd question". I've been slowly
converting my personal servers over to systemd-networkd, because I've
been having similar issues than DSA with IPv6 contention issues.

It generally works! And, yeah, it's a couple of config files to
manage, but it's nothing that puppet (or ansible) can't easily handle,
so that's not a problem for me at all.

Yet, that change is a big deal in Debian. ifupdown is one of those
Debian-specific things that has been around since basically
forever. It's in numerous guides and manuals, so lots of documentation
would need to be updated to reflect such a huge change. And that's not
counting all the people who have expressed here and elsewhere that they
just don't *want* to change away from ifupdown.

I happen to think it's the right way to go, personally, but I think the
way to do this would be to first add support for systemd-networkd in d-i
and cloud images, rather than netplan, because that would be far less
controversial. It would still allow people who want to to stick to
ifupdown, for example, it would "just" change defaults.

Either way, coming from the bits from the DPL here, I was hoping to see
a unified proposal that would try to approach consensus, but I don't
feel this is it. netplan is yet another controversial idea, and I don't
think it's consensual.

I would focus on trying to reach consensus to replace ifupdown with
networkd in d-i/images first, in any case. If we *must* use netplan to
do this, as an implementation, then okay, so be it. But just deciding
this is a huge step, and we should focus on that, if that's the
direction we want to go.

Just a thought.