1️⃣1️⃣ Here's the 11th installment of posts highlighting key new features of the upcoming v256 release of systemd.
There are multiple network management services in popular use on Linux. In systemd we ship systemd-networkd, and of course think it's the best choice. Weirdly, some people disagree though, and that creates problems of ownership: you either have to use one or the other network management service (i.e. either systemd-networkd OR NetworkManager), or you have to carefully make…
…sure that there's exactly one service that manages each interface, so that they don't fight for ownership of the network device, trample on each other's feet and undo each other's settings.
To improve the situation in systemd v255 we introduced a udev property ID_NET_MANAGED_BY= which can be set on a network interface device. The value is expected to be a some string identifying the intended owning network management service, by convention in reverse domain name syntax.
This allows running multiple services side-by-side, and clearly tell each one which interfaces they shall manage. Of course they might still fight for the devices that are not tagged like this, but at least in the networkd case we should be safe, since by default it will not try to manage an devices it has no configuration for.
In systemd v256 we now made it possible to configure this udev property (or any other in fact) via the Property= field in .link files.
Recap: .link files configure various settings on network devices that are more property of the device itself – as opposed to .network files which configure settings that belong to the network you then attach to it. .link files are a udev concept (they are also interpreted if you use NM hence!), while .network files are a networkd concept. At any time there are zero or one .link files and zero or one .network file applied to a network interface.
Hence, with this new Property= field you can nicely define via .link files which network service shall manage the matching devices.
This is particularly useful as systemd out-of-the-box ships with a bunch of .link files that match devices created by systemd-nspawn, systemd-vmspawn and systemd-nsresourced. These .link files have been updated to clearly indicate that these interfaces are supposed to be managed by networkd, and nothing else.
Or in other words: it's now entirely safe out of the box to run NM and systemd-networkd side-by-side and be sure that networkd will manage the interfaces of systemd's other components, and NM can do its own thing, without any ownership issues.
At this point at least NetworkManager also respects the NET_MANAGED_BY= property. And we recommend that packages that allocate their own network interfaces (bridges, veth tunnels, dummys, tap, tun, …) start shipping .link files that match them, …
@greatquux most of our releases if similar numbers of big features, it's just that previously I didn't post mastodon stories about them, and you had to read the NEWS file instead.
@pid_eins so in fedora, NM is the default. Does that mean they generate a link file if no one claims the interface and if i want to move the interface under systemd-networkd i would change the autogenerated link file? Or how would that work?
Thanks for the awesome updates. Really love systemd!
@breiti well, the scheme leaves unanswered what happens to network devices that are not tagged for any network management service. My assumption is that based on user config one of them takes possession of all untagged devices. networkd by default doesn't, NM by default does. Thus in this combination at least we should be good, you can just leave networkd running together with NM and in the default config everything should be fine.
Add comment