RFE: ship a catch-all .network file with systemd-networkd

[poettering]

We should really consider shipping a default, catch-all-Ethernet .network file along with systemd. Something containing a rule as simple as:

[Match]
Type=ether

[Network]
DHCP=yes

We'd then suggest downstream distros do ship this in a separate downstream RPM/DEB/..., then when installed makes automatic networking work. Distros not interested in this could simply not package this at all.

See systemd/mkosi@2663475#r75502267 for some background on this.

[keszybz]

Yeah, this makes a lot of sense and I thought about something like this myself. Unfortunately this would break the previous condition that without any explicit configuration, systemd-networkd was safe to enable because it wouldn't do anything.

For Fedora, I don't think we'd bother with a separate package: systemd-networkd is disabled in presets, so we can assume that if somebody enabled networkd it is because they want to use it.

[poettering]

@keszybz well, i use networkd on my laptop, and I actually wouldn't want that .network file here. That's because I let NM manage my wlan and stuff. I use networkd to deal with containers however, hence I really like the current default of only taking possession of container devices...

The fact that networkd can run safely in the bg without taking possession of everything popping up is pretty nice I think, and we should not depart from that in Fedora either, unless explicit configured...

[martinpitt]

If we ever actually ship something like that, this would change behaviour on existing installs, as all of a sudden networkd would now start to manage all ethernet devices. This is kinda okay for NetworkManager as people have a nice GUI/indicator for it, but makes it much harder/less obvious to tell networkd to not touch ethernets.

IMHO configuring network interfaces should be a function of the OS installer.

[poettering]

@martinpitt again, the idea would be not to ship this in the main package, but add an extra package for that, that pretty much only contains that one file, and that people can install if they want networkd to take possesion of everything, or leave out if not.

I am pretty sure OS images should be put together ideally just by dropping in files, and not by running "install scripts" or so, which patch around in the OS.

This would also make sure we can update the default .network file along with systemd itself.

[keszybz]

True. It seems bad to add this file to existing packages, even if systemd-networkd was disabled by default. OTOH, I don't like the idea of adding a systemd-networkd-enable-on-ethernet-by-default.rpm, and then systemd-networkd-enable-on-all-interfaces-by-default.rpm.

Maybe instead we should provide a set of disabled .network files, to allow admins to enable certain standard configurations by simply adding a single symlink.
E.g. /usr/lib/systemd/network/all-ethernet.network.example, and this could be enabled by ln -s ....

[martinpitt]

the idea would be not to ship this in the main package.

Ah sorry, missed that bit, so retracting my objection.

Maybe instead we should provide a set of disabled .network files, to allow admins to enable certain standard configurations by simply adding a single symlink.

That sounds nice indeed.

[poettering]

@keszybz well, that opens another door: should there be "networkctl enable" and "networkctl disable", which enable network files á la "systemctl enable" and "systemctl disable"...

I am inclined to say, that we really shouldn't have something like that though.

An alternative idea would be to introduce a "noop.network" concept, i.e. a network file that tells networkd to explicitly not take possession of a specific interface. i.e. something like this:

90-noop.network:
[Network]
Manage=no

If Manage=no is set (which defaults to =yes), then networkd would not manage the iface at all. Then, we could add another network file:

95-ethernet-dhcp.network:
[Match]
Type=ether
[Network]
DHCP=yes

Since 95 is after 90, this would mean that the noop network would always win, and no interfaces be managed (unless they have a prio below 90). However, if people mask noop.network then it would lose its negative effect and 95-ethernet-dhcp.network would take effect. Creating a /dev/null symlink would hence be enough to make make networkd possession of all devices. We could even install 90-noop.network only if --enable-noop-network is passed during configure, so that by default networkd takes possesion of everything.

The Manage=no switch might also be useful for .network files that simply want to attach metadata to ifaces without making networkd manage them. Think: a network file that attaches NTP or DNS info to an iface actually managed by something else.

[keszybz]

That's even more convoluted than my idea ;)
Also, negative enables like this are problematic, because you enable stuff by removing a file, and then package upgrade will likely re-add the file. So you configure networking on your server, run upgrade, and reboot and voilà, you have a free trip to the server room to reenable networking.

Manage=no sounds like a useful idea, but not a solution to this particular problem.

[poettering]

while typing this i also assumed it was quite convoluted and inda "inverted". But actually, the way I'd think about this is is that networkd should of course manage everything by default, and that should be the normal case, and if people don't want that, they should use the noop network file. But in the systemd setup of our dreams of course networkd should manage evertyhing and should take possession of everything.

hence, one could argue: yeah, if you don't want networkd to manage everything, then that's deviating from the best possible state, and the noop thingy might be the right approach, if you follow what i mean.

a package upgrade that removes unmask symlinks would be a pretty broken package upgrade I'd say...

[keszybz]

Oh, OK, I got the masking thing backwards. You're right, upgrades would not cause issues.

But still, this does not seem like the interface that we want to support. It's very ad-hoc and specific to this one issue. I'd prefer to wait until systemd-networkd is more mature and has at least the dbus interface, before we start enabling it by default like this.

After all, it's not a big issue to drop a four line file in the installer. It's much clearer at least.

[sjoerd-ccu]

Just playing with this example on a VM, it seems that ethernet device don't actually set DEVTYPE=ether in their uevent meaning the snippet doesn't actually seem to work..

Digging a bit in the kernel, devtype is set in the wireless core to wlan but there is no central place that ever sets devtype to ether. So unless networkd starts doing the same heuristics for matching as networkctl does i don't see how this can work.

[poettering]

@sjoerd-ccu there were some attempts to fix the kernel to always pass useful data about the iface to userspace, but that wen't nowhere.

networkctl already "fixes up" the device type in userspace if the kernel doesn't let us know enough info. I figure we should really add the same logic to the matching code too, and fix up the rubbish the kernel passes to us, if we can.

[q2dg]

Ubuntu Server 17.10 implements "netplan", who reads /etc/netplan/01-netcfg.yaml file, which has this default content:

network:
version 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: yes

The result of reading this is the creation on boot of the /run/systemd/network/10-netplan-enp0s3.network file, which has this content:

[Match]
Name=enp0s3
[Network]
DHCP=ipv4
[DHCP]
UseMTU=true
RouteMetric=100

The result of all of this is having the systemd-networkd service running in a "enabled-runtime" state although it was disabled explicitely with systemctl disable systemd-networkd.{service,socket}

So...my (maybe erroneous) onclusion is Netplan is already doing this "default configuration for-all", at least in Ubuntu Server. More information here: http://manpages.ubuntu.com/manpages/zesty/man5/netplan.5.html

[motimati08]

ether