Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #113424 > unrolled thread

proposal: Hybrid network stack for Trixie

Back to article view | Back to linux.debian.devel

Contents

  proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-20 13:20 +0200
    Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-20 15:50 +0200
      Re: proposal: Hybrid network stack for Trixie Bill MacAllister <bill@ca-zephyr.org> - 2024-09-20 22:20 +0200
    Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-22 12:30 +0200
      Re: proposal: Hybrid network stack for Trixie Marc Haber <mh+debian-devel@zugschlus.de> - 2024-09-22 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-22 13:50 +0200
          Re: proposal: Hybrid network stack for Trixie "Jonathan Dowland" <jmtd@debian.org> - 2024-09-22 16:50 +0200
            Re: proposal: Hybrid network stack for Trixie "Andrew M.A. Cater" <amacater@einval.com> - 2024-09-22 17:20 +0200
          Re: proposal: Hybrid network stack for Trixie Hakan Bayındır <hakan@bayindir.org> - 2024-09-22 23:30 +0200
      Re: proposal: Hybrid network stack for Trixie Simon McVittie <smcv@debian.org> - 2024-09-22 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Josh Triplett <josh@joshtriplett.org> - 2024-09-22 20:10 +0200
          Re: proposal: Hybrid network stack for Trixie "Andrea Pappacoda" <andrea@pappacoda.it> - 2024-09-22 22:40 +0200
            Re: proposal: Hybrid network stack for Trixie Josh Triplett <josh@joshtriplett.org> - 2024-09-23 00:10 +0200
              Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:40 +0200
      Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-23 14:10 +0200
        Re: proposal: Hybrid network stack for Trixie Marvin Renich <mrvn@renich.org> - 2024-09-23 14:50 +0200
        Re: proposal: Hybrid network stack for Trixie Didier 'OdyX' Raboud <odyx@debian.org> - 2024-09-23 15:00 +0200
        Re: proposal: Hybrid network stack for Trixie Daniel Baumann <daniel@debian.org> - 2024-09-24 08:10 +0200
      Re: proposal: Hybrid network stack for Trixie Simon Richter <sjr@debian.org> - 2024-09-24 14:20 +0200
    Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-22 16:30 +0200
      Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:30 +0200
        Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-23 12:50 +0200
          Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 13:20 +0200
            Re: proposal: Hybrid network stack for Trixie Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-09-23 13:40 +0200
              Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-24 15:40 +0200
                Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-27 10:10 +0200
            Re: proposal: Hybrid network stack for Trixie Bjørn Mork <bjorn@mork.no> - 2024-09-23 14:20 +0200
          Re: proposal: Hybrid network stack for Trixie Steve Langasek <vorlon@debian.org> - 2024-09-27 20:20 +0200
            Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-27 21:10 +0200
    Re: proposal: Hybrid network stack for Trixie Sirius <sirius@trudheim.com> - 2024-09-22 17:50 +0200
      Re: proposal: Hybrid network stack for Trixie Jonas Smedegaard <jonas@jones.dk> - 2024-09-22 23:50 +0200
        Re: proposal: Hybrid network stack for Trixie Sirius <sirius@trudheim.com> - 2024-09-23 08:30 +0200
          ifupdown-ng source stanza (Was: proposal: Hybrid network stack for  Trixie) Daniel Gröber <dxld@darkboxed.org> - 2024-09-23 11:00 +0200
            Re: ifupdown-ng source stanza (Was: proposal: Hybrid network stack  for Trixie) Sirius <sirius@trudheim.com> - 2024-09-24 13:40 +0200
    Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 10:10 +0200
      Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 10:20 +0200
        Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 10:30 +0200
          Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-23 11:10 +0200
            Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:10 +0200
            Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 12:10 +0200
              Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 12:30 +0200
    Re: proposal: Hybrid network stack for Trixie Pierre-Elliott Bécue <peb@debian.org> - 2024-09-23 11:40 +0200
      Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 12:30 +0200
        ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Daniel Gröber <dxld@darkboxed.org> - 2024-09-23 13:50 +0200
          Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Philipp Kern <pkern@debian.org> - 2024-09-23 17:50 +0200
            Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Noah Meyerhans <noahm@debian.org> - 2024-09-24 00:20 +0200
        Re: proposal: Hybrid network stack for Trixie Pierre-Elliott Bécue <peb@debian.org> - 2024-09-24 10:50 +0200
    Re: proposal: Hybrid network stack for Trixie Antoine Beaupré <anarcat@debian.org> - 2024-10-07 18:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#113424 — proposal: Hybrid network stack for Trixie

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#113428

[Multipart message — attachments visible in raw view] — view raw

On Sep 20, Lukas Märdian <slyon@debian.org> wrote:

> 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.

> 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.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#113435

On 2024-09-20 06:49, Marco d'Itri wrote:
> On Sep 20, Lukas Märdian <slyon@debian.org> wrote:
> 
>> 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

-- 
My heart is warm with the friends I make,
   And better friends I'll not be knowing,
Yet there isn't a train I wouldn't take,
   No matter where it's going.

Edna St Vincent Millay

[toc] | [prev] | [next] | [standalone]

#113442

* Lukas Märdian <slyon@debian.org> [240920 13:13]:
> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#113443

On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler
<zeha@debian.org> wrote:
>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.

>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.

>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
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#113445

* Marc Haber <mh+debian-devel@zugschlus.de> [240922 13:08]:
> On Sun, 22 Sep 2024 12:22:50 +0200, Chris Hofstaedtler
> <zeha@debian.org> wrote:
> >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.
> 
> >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.

> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#113448

On Sun Sep 22, 2024 at 12:47 PM BST, Chris Hofstaedtler wrote:
> 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.


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#113450

On Sun, Sep 22, 2024 at 03:45:30PM +0100, Jonathan Dowland wrote:
> On Sun Sep 22, 2024 at 12:47 PM BST, Chris Hofstaedtler wrote:
> > 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
> 
> -- 
> Please do not CC me for listmail.
> 
> 👱🏻	Jonathan Dowland
> ✎	 jmtd@debian.org
> 🔗	https://jmtd.net
> 

[toc] | [prev] | [next] | [standalone]

#113457

> On 22 Sep 2024, at 14:47, Chris Hofstaedtler <zeha@debian.org> wrote:
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#113444

On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote:
> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#113455

Simon McVittie wrote:
> On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote:
> > 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.

[toc] | [prev] | [next] | [standalone]

#113456

[Multipart message — attachments visible in raw view] — view raw

On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
> 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>.

[toc] | [prev] | [next] | [standalone]

#113459

On Sun, Sep 22, 2024 at 10:30:12PM +0200, Andrea Pappacoda wrote:
> On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
> > 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>.

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.

[toc] | [prev] | [next] | [standalone]

#113472

On 22.09.24 23:59, Josh Triplett wrote:
> On Sun, Sep 22, 2024 at 10:30:12PM +0200, Andrea Pappacoda wrote:
>> On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
>>> 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>.
> 
> 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

[toc] | [prev] | [next] | [standalone]

#113474

On 22.09.24 12:22, Chris Hofstaedtler wrote:
> * Lukas Märdian <slyon@debian.org> [240920 13:13]:
>> 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.

> 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.

>> 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

[toc] | [prev] | [next] | [standalone]

#113478

[Multipart message — attachments visible in raw view] — view raw

On Sep 23, Lukas Märdian <slyon@debian.org> wrote:

> 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.

> 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.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#113480

* Lukas Märdian <slyon@debian.org> [240923 07:05]:
> 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

[toc] | [prev] | [next] | [standalone]

#113481

[Multipart message — attachments visible in raw view] — view raw

Le lundi, 23 septembre 2024, 13.04:41 h CEST Lukas Märdian a écrit :
> On 22.09.24 12:22, Chris Hofstaedtler wrote:
> > * Lukas Märdian <slyon@debian.org> [240920 13:13]:
> >> 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.

-- 
    OdyX

[toc] | [prev] | [next] | [standalone]

#113486

On 9/23/24 13:04, Lukas Märdian wrote:
> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#113491

Hi,

On 9/22/24 19:22, Chris Hofstaedtler wrote:

> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.devel

csiph-web