1️⃣0️⃣ Here's the 10th installment of posts highlighting key new features of the upcoming v256 release of systemd.
-
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/.
-
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.
-
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, …
-
…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.
-
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.
-
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.
-
-
Nitpicking: I like the series a lot, but here is a tip from a former writer/editor:
I'm pretty sure you would reach a (much?) bigger audience if the first toot in the thread has the most interesting bit, e.g. something to make people want to read that thread – and not somewhat boring sentence they might have read a few times before plus a sentence + some also somewhat boring toots that just set the stage.
E.g. make it look more like this: [see reply to self]
-
@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 Keep it up. We need more alternatives to legacy tools, designed around the patterns of userdbd, homed, and run0.
I find it "funny" how people fail to see systemd as an umbrella for basic system management tools. I mean, they don't pick at, say, KDE for making hundreds of apps for all sorts of things, but when the systemd project releases optional alternatives to system tools, they cry out in rage. I don't get it.
-
@nik KDE got (and still gets) a lot of flak for, which is the reason they cut the project up in smaller packages that can individually be depended on, with KDE5.
"optional" in systemd land means very little, when the wide availability of the (singular) package causes people to be comfortable hard-depending on even its most lesser used components, and when you do so, you pull in the rest of the ecosystem. There's maybe a handful of tools that work without the PID1.
-
@mid_kid I don't consider systemd itself as PID 1 optional. Mostly because there isn't any reasonable alternative that is fit for modern IT requirements (I will not discuss this in this thread).
I meant that all the non-PID1 parts are optional.