PS: I know this proposal doesn't please everybody, but I think it's the mostActually I cannot thing of your proposal having much support from
actionable option that we have on the table and strikes a good compromise. As aThis is not a "compromise". There is no other "more Netplan" option
On Sep 20, Lukas Märdian <slyon@debian.org> wrote:
PS: I know this proposal doesn't please everybody, but I think it'sActually I cannot thing of your proposal having much support from
the most
anybody else.
At this point I am starting to find annoying how hard you alone are
trying to push Netplan on 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].
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.
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.
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.
d-i could make (or offer) a choice between networkd and
NetworkManager.
Given d-i then will have to make a choice, *none* of the networking
stack packages should have a "Priority:" higher than optional.
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?
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.
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
TBH the "interfaces nicely with the clickable frontends" part is
what I meant here. I don't know if anyone likes nm-cli.
# 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].
# Compatibility
We do not want to break existing systems or people that want to keep using the
classic way of /etc/network/interfaces.
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
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.
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.
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.
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>.
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.
* 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?
I miss ifupdown2 in this discussion.
ifupdown2 is like ifupdown, just rewritten in python.Yes, that's the problem: there was a consensus that it is not an
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/.
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.
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.
# 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.
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.
ifupdown2 will still be around for anybody who wants to install it.
sure.
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)?
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.
* 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.
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
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?
As described in the "Proposal" section and first answer of the FAQ, it's all about consistency.The problem with this argument is that neither systemd-networkd, nor NetworkManager, nor ifupdown users are asking for a unified
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.
It's sad to see that fellow DDs do not seem to care about consistencyI think it's good that fellow DDs are wary of adding an indirection
and usability in this regard.
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 thatSo on desktop installations including NetworkManager, netplan will
debian-installer
installs a /etc/netplan/01-network-manager-all.yaml config file, reading: >>>
network:
  version: 2
  renderer: NetworkManager
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
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.
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,
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's sad to see that fellow DDs do not seem to care
about consistency and usability in this regard.
* Pierre-Elliott Bécue <peb@debian.org> [240923 11:34]:
Lukas Märdian <slyon@debian.org> wrote on 20/09/2024 at 13:12:36+0200:
# 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 :-)
Hi Sirius,
Thanks for taking ifupdown-ng for a spin.
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.
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?
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?
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 thatSo on desktop installations including NetworkManager, netplan will
debian-installer
installs a /etc/netplan/01-network-manager-all.yaml config file, reading: >>>>
network:
  version: 2
  renderer: NetworkManager
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.
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.
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...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:56:48 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,737 |