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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#113447

Hi,

On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> 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

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

#113470

Hi!

On 22.09.24 15:58, Ansgar 🙀 wrote:
> On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>> 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

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

#113473

Hi,

On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
> On 22.09.24 15:58, Ansgar 🙀 wrote:
> > On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> > > 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

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

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

#113475

On 23.09.24 12:27, Ansgar 🙀 wrote:
> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>> On 22.09.24 15:58, Ansgar 🙀 wrote:
>>> On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>>>> 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
> 
> 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

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

#113476

Lukas Märdian <slyon@debian.org> writes:

> On 23.09.24 12:27, Ansgar 🙀 wrote:
>> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>>> On 22.09.24 15:58, Ansgar 🙀 wrote:
>>>> On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:

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

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

#113494

On 23.09.24 13:33, Richard Lewis wrote:
> Lukas Märdian <slyon@debian.org> writes:
>> On 23.09.24 12:27, Ansgar 🙀 wrote:
>>> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>>>> On 22.09.24 15:58, Ansgar 🙀 wrote:
>>>>> On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
> 
>>>> 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
>>> 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

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

#113523

Hi,

On Tue, 2024-09-24 at 15:34 +0200, Lukas Märdian wrote:
> 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

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

#113479

Lukas Märdian <slyon@debian.org> writes:
> On 23.09.24 12:27, Ansgar 🙀 wrote:
>
>> 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

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

#113536

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

On Mon, Sep 23, 2024 at 12:27:13PM +0200, Ansgar 🙀 wrote:
> 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.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

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

#113537

Hi Steve,

On Fri, 2024-09-27 at 11:01 -0700, Steve Langasek wrote:
> On Mon, Sep 23, 2024 at 12:27:13PM +0200, Ansgar 🙀 wrote:
> > 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

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

#113451

On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote:
[snip]
> # 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.

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

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

-- 
Kind regards,

/S

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

#113458

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

Quoting Sirius (2024-09-22 17:22:21)
> On fre, 2024/09/20 at 13:12:36 +0200, Lukas Märdian wrote:
> [snip]
> > # 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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

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

#113460

On sön, 2024/09/22 at 23:41:56 +0200, Jonas Smedegaard wrote:
> Netplan seems like *different* bells and whistles, rather than none.

True.

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

-- 
Kind regards,

/S

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

#113464 — ifupdown-ng source stanza (Was: proposal: Hybrid network stack for Trixie)

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

Hi Sirius,

Thanks for taking ifupdown-ng for a spin.

On Mon, Sep 23, 2024 at 08:22:51AM +0200, Sirius wrote:
> > 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.

> 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

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

#113490 — Re: ifupdown-ng source stanza (Was: proposal: Hybrid network stack for Trixie)

On mån, 2024/09/23 at 10:57:22 +0200, Daniel Gröber wrote:
> 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

> On Mon, Sep 23, 2024 at 08:22:51AM +0200, Sirius wrote:
> > 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.

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

-- 
Kind regards,

/S

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

#113461

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

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.

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

#113462

* Holger Levsen <holger@layer-acht.org> [240923 10:06]:
> 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

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

#113463

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

On Mon, Sep 23, 2024 at 10:14:39AM +0200, Chris Hofstaedtler wrote:
> * Holger Levsen <holger@layer-acht.org> [240923 10:06]:
> > 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
 
> 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)

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

#113465

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

On Sep 23, Holger Levsen <holger@layer-acht.org> wrote:

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

-- 
ciao,
Marco

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

#113467

On 23.09.24 11:04, Marco d'Itri wrote:
> On Sep 23, Holger Levsen <holger@layer-acht.org> wrote:
> 
>> 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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web