On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian <l...@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
