New systemd 248 feature 'extension images' updates immutable file systems without really updating them
- Reference: 1617274990
- News link: https://www.theregister.co.uk/2021/04/01/systemd_248/
- Source link:
As developer Lennart Poettering [1]explained : "When a system extension image is activated, its /usr/ and /opt/ hierarchies and os-release information are combined via overlayfs with the file system hierarchy of the host OS."
[2]
The primary use case for system extension images is for immutable operating systems like Red Hat's Silverblue and [3]Kinoite . In these OSes, the file system is read-only and is updated by replacing it with a new image rather than being patched, which is better both for security and stability.
Kinoite: Immutable Fedora variant with KDE Plasma desktop on the way [4]READ MORE
[5]
It does cause compatibility issues for applications that need updated system files, and is difficult for developers who need more flexibility. Typically, these problems are overcome by running virtual machines or containers, but system extension images let users and developers update or add system files without actually modifying the immutable file system. Developers could add debugging tools, or install a newly compiled build including system files.
"System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image.
"Typically, system extension images are built at the same time as the base OS image – within the same build system," [6]say the docs . System extension images may be provided as plan directories or as disk images, activated or deactivated with the systemd-sysext command.
Poettering lists other new features in his post. There is a new configuration file, /etc/veritytab, for configuring [7]dm-verity integrity protection, for cryptographic checking of the integrity of block devices, as well as a new kernel command-line option, systemd.verity.root_options.
There are also improvements to systemd-oomd, designed to take corrective action when free memory is running very low. There is "a new DefaultMemoryPressureDurationSec=setting to configure the time a unit's cgroup needs to exceed memory pressure limits before action will be taken," said Poettering, adding: "systemd-oomd is now considered fully supported (the usual backwards-compatiblity promises apply)."
Finally, the main git development branch for systemd has been renamed to "main" in accordance with the [8]trend towards [9]inclusive branch names .
[10]
New releases of systemd appear around every four months, the previous one being in November 2020. ®
Get our [11]Tech Resources
[1] https://github.com/systemd/systemd/blob/main/NEWS
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YGXuFkt1dxOQaTgJj1MnGwAAAJE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2021/02/18/kinoite_immutable_fedora/
[4] https://www.theregister.com/2021/02/18/kinoite_immutable_fedora/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YGXuFkt1dxOQaTgJj1MnGwAAAJE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
[7] https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html
[8] https://www.theregister.com/2021/03/11/gitlab_main/
[9] https://sfconservancy.org/news/2020/jun/23/gitbranchname/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YGXuFkt1dxOQaTgJj1MnGwAAAJE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
Re: why in hell?
Yeah, enough about systemd already. Where's this year's April Fool article?
Re: why in hell?
Systemd is to replace emacs, or is it the other way around ??
M-x apropos systemd
No apropos matches for ‘systemd’
I think we're safe in that direction.
Re: why in hell?
In recent years, across a number of publications, it seems more common to post implausible but actually real stories. Instead of making something up. Maybe the world is now so messed up that April fools day will be abandoned, as we can enjoy it all year long.
Errr but...
Version 248 of systemd, a widely used and almost universally hated system and service manager for Linux,
There fixed it for you...
Even if this is a joke, I could not resist the opportunity to have a go at systems. It is about the worst thing ever imposed on Linux.
Re: Errr but...
The core idea of replacing the serial init scripts with a parallel boot process is fine, it makes server booting faster and replicates SMF on Solaris in that regard.
Unfortunately, just as SMF absorbed a bunch of configuration into its clutches (e.g. DNS changes via svccfg rather than simply editting /etc/resolv.conf), systemd is doing the same. I'm not keen on so much being done by the init process in Linux - it's too critical and important to have bugs in.
Re: Errr but...
That auto-generated /etc/resolve.conf annoys the hell out of me. The other day I came across it again, couldn't remember the correct voodoo incantation, and couldn't be arsed. So I did the only sane thing - edited the file and made it immutable with "chattr +i". Yes, I'm a bad person.
Re: Errr but...
Yep, I got pissed off by the monkeying with /etc/resolve.conf too, mainly because for years I've just slapped a local customised copy over the top of it whenever a system upgrade caused name resolution to fail. This time, after a couple of reboots I finally read the version that got pasted back in place at each boot, did what it said and have decided that I actually quite like putting all resolver customisation in /etc/systemd/resolved.conf because it does at least collect a number of related settings in one file.
Still somewhat annoyed that somebody thought it would be a good idea to put these hints in the replacement /etc/resolve.conf rather than an easily found manpage, though.
Re: Errr but...
"Something must be done. This is something, therefore we must do it"
Re: Errr but...
> The core idea of replacing the serial init scripts with a parallel boot process is fine, it makes server booting faster and replicates SMF on Solaris in that regard.
Yes, and it was done before systemd. My Gentoo 2004 vintage distro had parallel init booting, and it did speed things up quite a bit.
So systemd was very much a (poor) solution in search of a problem when it came out in the first place, and not much has changed, except it is getting forced down our throats by RedHat/IBM.
Re: Errr but...
"replacing the serial init scripts with a parallel boot process is fine"
My OpenRC machine has parallel service startup now, works perfectly well enough for me!
Extension images
Yet another neat idea that absolutely should have been it's own project instead of swelling the excessively turgid belly of Systemd. Hmm, turgid, I might make that my word of the day.
Why. Just why?
It's an overlayfs. That's all it is. Just a less good one that's forced to target specific parts of the tree. If I wanted to overlayfs /usr/ I can already do that. I don't need another stupid bloody systemd specific way of doing that!
Re: Why. Just why?
My thoughts exactly. If this isn't an April Fool's joke, then yet again Poettering has reinvented the wheel.
When
I first discovered in UNIX that you could mount one filesystem on top of another, I thought it was a bug.
Haters gotta hate
I'm OK with systemd. I think it is better at keeping a system in good nick than init-scripts. It can be hard to find the right man page but at least everything is documented in detail and Google usually has a quick answer.
I have a little set-top-box pc that has a read-only root I update by rsyncing the main server root file system and then having a dozen or so symlinks to handle the unique files and files that have to be write-able. Those symlinks are created by a script in the initramfs image (very painful to debug) so the vanilla boot procedure works normally. This new feature might be usable instead given that systemd has a very powerful and customizable dependency system.
Undermining the benefits of an immutable filesystem?
Isn't the fact it's read-only security enhancing; e.g. a bad actor can't replace a critical library or executable on /usr with some backdoored version? Then what's the point?
Not sure if this is an April fools or not. It’s possible it is, but seems a bit of a reach functionality wise for systemd. That said, it seems systemd is almost becoming an os in it’s own right it had gained so many functions.
that said, it seems systemd is almost becoming an os in it’s own right it had gained so many functions.
Well the sooner it does, the sooner we can avoid it if we don't want it.
why in hell?
Apparently L.P. couldn't run pulseaudio on his Phillips Hue lights...