Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian <luk@slyon.de> wrote:
>
> Am 19.06.23 um 20:01 schrieb Simon McVittie:
> > On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
> >> On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
> >>> Why does isc-dhcp-client have priority:important to begin with?
> >>> I don't think users care so much about a dhcp client but rather a
> >>> network configuration system
> >>
> >> The priority question isn't the important one. The real question is:
> >>
> >> What network configuration system should users end up with (by
> >> default)?
>
> Indeed, this is the correct question to ask!
>
> > Yes, whatever DHCP client ifupdown would prefer to use, that seems
> > like an implementation detail of ifupdown: it should pull it in via
> > an appropriate level of dependency, and that's orthogonal to whether a
> > particular class of installation has its networking managed by ifupdown,
> > NetworkManager, systemd-networkd or something else by default.
>
> ACK.
>
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that seems reasonable (although I personally
> > prefer to set up systemd-networkd on servers).
> >
> > Of our desktop tasks, all except possibly LXDE and LXQT pull in
> > NetworkManager via Recommends or stronger, which seems right. LXDE
> > and LXQT might pull in connman as a higher preference than NM, via an
> > alternative dependency that includes connman-gtk or cmst: it's not
> > immediately obvious to me what actually happens, and I don't have a
> > recent installation of either one to look at right now.
>
> As the maintainer of Netplan, I have a strong interest in this topic. I agree with bluca, going with systemd-networkd on servers and NetworkManager on desktops, the pooling & sharing of resources between Debian and Ubuntu will be a win-win situation! I'd propose to use Netplan.io on top of that, to seed the configuration for either network configuration tool in a common way, which should make life easier for the d-i team.
>
> Netplan allows to configure both of those tools and is already being used across Ubuntu and in Debian cloud-images for this purpose. All while keeping full flexibility to use the underlying tool's native config files, should Netplan's simple YAML settings not be enough for a given complex usecase. E.g. /etc/netplan/*.yaml will generate configuration in /run/systemd/network/... and/or /run/NetworkManager/system-connections/... while /etc/systemd/network/... and /etc/NetworkManager/system-connections/... are still there for native (or override) configurations!
>
> I think we shaped up the Netplan package in Debian [2] pretty nicely in the recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not least, at the Netplan project we're happy to help out with any rough edges that Debian might run into, as we might have already seen those in Ubuntu and of course we're also open for contributions!
>
> > The other possible reason to have a DHCP client is for recovery, but
> > most bootable Debian systems will have busybox (via Recommends from
> > initramfs-tools-core), and that has a small DHCP client included anyway.
> >
> >> I also think that installing both ifupdown and NetworkManager on
> >> desktop environments is worse than only NM.
> >
> > ifupdown should be fairly harmless when not configured to manage any
> > non-loopback interfaces (which is what d-i does when NM is installed),
> > but I agree that it seems better not to have it if it's not needed.
>
> ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian Reunion Hamburg [2].
> ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
> ifupdown-ng has only ever seen a single upload in Debian, but was deemed to be the best ifupdown implementation currently.
>
> IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should rather go the systemd-networkd (server) + NetworkManager (desktop) path, potentially in combination with Netplan, in order to switch to a more modern and future proof network configuration tool, that also supports advanced features such as WiFi regulatory domain settings or SR-IOV network virtualization, to cover today's usecases. We'd also get nice CLI tools to control this stack for free, such as "networkctl", "nmcli" or "netplan status".
>
> Cheers,
> Lukas
>
> [1] https://tracker.debian.org/pkg/netplan.io
> [2] https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Yeah I think it would be nice to do some experiments there, at least
starting with networkd and eventually considering netplan as an
additional step on top - thanks for volunteering :-P
Ultimately it seems to me that the defaults should be driven by
tasklets rather than priority - ie, make ifupdown and dhcpd-base
optional, have ifupdown depend on dhcpd-base so that if a user wants
to use that stack they can just pull in ifupdown and it works as
expected, and have the desktop task pull in NetworkManager. Then we
can decide what the default stack for servers should be after some
experimenting.
Kind regards,
Luca Boccassi
Reply to: