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.
1️⃣0️⃣ Here's the 10th installment of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd-sysext: a component of systemd that can overlay immutable disk images (DDIs) on top of /usr/, to extend it in a secure, and again, immutable fashion. It has a companion tool systemd-confext that does the same over /etc/.
@kernellogger might sound weird, but i am kinda afraid of a bigger audience tbh. The run0 story with all the problematic folks suddenly showing up from hn, reddit, heise forums, and so on and feeling the urge to be assholes on the internet which I then have to block makes me prefer posting things in a way that doesnt find the really big audience. Thankfully those folks aren't capable of reading more than one sentence anyway, hence by hiding the good stuff a bit further down keeps things civil?
@kernellogger its a difficult balance to find, but let's just say that of the 9 stories I posted until today only the one that reached the big audience was a mess to keep control of.
Yeah, it's in a way elitist as fuck, and I am usually against that, but the Internet is what the Internet is.
@javierm yeah, not convinced though. Doesn't protect the bits that need protection the most: the fs data structures. It's simply on the wrong layer. It's like you try to build a skyscraper on quicksand.
@gnomealex@javierm nope. DDIs come with dm-verity. Hence regardless what they are stored on integrity is ensured on block layer before the fs data structures are processed.
And if they themselves are stored on a backing fs then sure you need to ensure some basic validity of that, but its relatively limited, i.e. even vfat suffices (which is probably where data structures are simple enough for security, because kinda mandated by uefi model around esp)
9️⃣ Here's the 9th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
I am sure you are aware of systemd-nspawn, systemd's minimal container manager focussed on full OS containers, that can boot up a Linux image from an OS in a disk image or from a directory. systemd-nspawn was originally a development tool, to make it easy for us to develop the service manager without constantly having to reboot.