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/
