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

Re: proposal: Hybrid network stack for Trixie



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: http://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


Reply to: