pid_eins

pid_eins, 12 days ago

…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.

pid_eins, 12 days ago

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.

pid_eins, 12 days ago

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.

pid_eins, 13 days ago

In particular systemd-sysext has become quite popular on immutable OSes (by which I mean the ones that provide cryptographic immutability via dm-verity, not things like ostree where the immutability is mere convention) to provide a certain level of modularity to an otherwise rigid file hierarchy.

With these tools, the /usr/ and /etc/ hierarchies become stacks (by means of overlayfs) of read-only, cryptographically protected, individually signed file system layers.

pid_eins, 13 days ago

Any inode in these trees can be traced back to a cryptographically signed layer, and thus the source and vendor they come from. If you ask me it's the way how to develop modern operating systems with strongest security but retaining modularity to some degree.

Developing in a purely immutable world is sometimes a bit harder than in a traditional world: you cannot just go and modify some file and see if that works, …

pid_eins, 13 days ago

…because that is after all comprehensively forbidden on multiple layers of the software stack. That of course makes it harder to tinker with the system, and that sucks to some degree.

With v256 we are thus opening up things a bit: even though the primary focus of these tools (and of our general idea of what an OS should look like) is true immutability, there's now a new --mutable= switch to systemd-sysext/systemd-confext.

pid_eins, 13 days ago

it allows opting into a writable layer to the top of the stack, to allow local modifications in /usr/ or /etc/. This writable layer can either be on a tmpfs (i.e. ephemeral), or backed by a writable fs – so that the resulting layer when finished can become a proper sysext layer of its own right later on, if desired.

Note that this writable layer is truly atomic in its behaviour: if the layer is on, its files are added into the tree, and if its off, they are gone again.

pid_eins, 13 days ago

This makes it really nice to try out new things: you can just overwrite files in /usr/ and /etc/, play around with them, and afterwards you just atomically flush out your modifications, and are back in the original immutable state.

This functionality has been added by the Flatcar OS folks, who'll probably be the first to showcase this in their distribution.

And that's all for now. Stay tuned for installment #11, hopefully in the next days.

pid_eins, 13 days ago

@gd2 gnome OS for example. And there are more that aren't that public I guess.

pid_eins, 13 days ago

@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?

pid_eins, 13 days ago

@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.

pid_eins, 13 days ago

@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.

pid_eins, 13 days ago

@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)

pid_eins, 16 days ago

… maybe not quite as popular as docker, but it conquered many other areas, for example build systems and more.

There's one facet nspwan is particularly good at: we use it to showcase new integration features between the host systemd and containers. nspawn for example natively supports propagating credentials down to its payload, or supports sd_notify() ready notfications for the service manager in the payload. It allows binding a host user into the container via --bind-user=, or…

pid_eins, 16 days ago

… authenticated OS images via dm-verity/DDI and there's so much more.

Now, I personally use nspawn daily, for developing systemd, testing integration and many other aspects and a lot more. But sometimes it's not enough for my work. For example, because nspawn directly transitions into the service manager it doesn't go through an initrd, so it cannot be used for test an initrd, even though that's a crucial part of developing an OS.

pid_eins, 16 days ago

It also doesn't bother with a boot loader, since containers after all share the same kernel, there's no boot loader involved anymore. But in systemd we have sd-boot after all, which is a modern boot loader with many security features we need to work with. Per-container TPMs are also not really a thing.

Hence, in a recent systemd version we added systemd-vmspawn. It's a small wrapper around qemu, which has the point of making it as nice and simple to use qemu as it is to use nspawn.

pid_eins, 16 days ago

The idea is that we provide a roughly command line equivalent interface to VMs as for containers, so that it really is as easy to invoke a VM as it already is to invoke a container, supporting both boot from DDIs and boot from directories.

And one thing in particular we have a focus on here: that the integration points that make it so nice to use nspawn are also available in vmspawn, wherever we can possibly do that. i.e. credentials, sd_notify, and all that other stuff.

pid_eins, 16 days ago

With v256 vmspawn is relatively complete now. For example it now registers with machinectl, also supports credentials, sd_notify, and so much more.

At this point, for my daily work it's now as trivial to boot a relatively fully featured VM (with TPM, SecureBoot, and all that fancy new-fangled stuff) as it is to to run a full OS container, and all I have to do is replace "n" by "vm" in the command line I use.

We also started to switch over much of systemd's test suite to use vmspawn.

pid_eins, 16 days ago

And life has gotten so much better with it.

(Much of the work to get vmspawn up to speed for use in the integration test suite was implemented by Codethink btw, supported by the STF).

And that's all for now. Let's see if I'll manage to do a 10th installment soon.

pid_eins, 16 days ago

@mxk we kinda have that now with mountfsd/nsresourced, see earlier installment of this series. Not entirely polished yet.

pid_eins, 13 days ago

@smlx No.

pid_eins, 17 days ago

@getajobmike i pinned some of them now. But it refuses to let me pin more, hence I figure this is where it ends. Sorry.