LWN: Comments on "systemd 256 released"

tmpfiles footgun, apply directly to the forehead

pizza — Sat, 22 Jun 2024 20:27:37 +0000

> It's in $PATH. If it's not a user-facing tool it goes in /usr/libexec.

... So is 'rm', 'dd', 'fdisk', 'mkfs.*' and many other tools (including good old shell output redirection) that can be trivially used to completely trash your files.

> If you worked in a real engineering profession, your attitude would get people killed.

In a "real" profession you can (1) explicitly define who your users/target audience are, and (2) legally require them to undergo formal training before getting on your ride.

tmpfiles footgun, apply directly to the forehead

flussence — Sat, 22 Jun 2024 15:26:32 +0000

> This is not a user-facing tool

It's in $PATH. If it's not a user-facing tool it goes in /usr/libexec. Just admit you were wrong. You didn't even fix this, Lennart did.

If you worked in a real engineering profession, your attitude would get people killed.

tmpfiles footgun, apply directly to the forehead

bluca — Tue, 18 Jun 2024 21:32:53 +0000

> Of course having unclear footguns is not nice, so what we'll likely do is make this switch only act on specific input, and refuse to run 'globally', so you really have to say "please delete this and this", otherwise it does nothing. This seems like a decent compromise to me.

v256.1 has been released with this change. Much ado about nothing.

tmpfiles footgun, apply directly to the forehead

bluca — Mon, 17 Jun 2024 15:20:12 +0000

That would result in a ton of bikeshedding, so can't be bothered honestly

tmpfiles footgun, apply directly to the forehead

Wol — Mon, 17 Jun 2024 14:34:35 +0000

> None of this has anything to do with "tmpfiles" - it is just an unfortunate legacy name (that cannot be changed without breaking scripts), but sd-tmpfiles has not been about temporary files for years and years. Just check the entries in the tmpfiles.d directory, you'll see plenty of stuff under /etc/ and /var/.

Can't you rename it with a link to the previous name, and a note in the docu saying "these two are the same, but the old name is misleading and deprecated"?

I'm sure they do that elsewhere ...

Cheers,
Wol

The SSH over vsock handling could enable much better cloud security

abartlet — Mon, 17 Jun 2024 08:00:34 +0000

Imagine if 'openstack ssh' existed, and did the work to connect to this service over the broader network, but only for authenticated openstack users and with openstack providing the warrenty that the host was the right one. No more SSH noise as SSH isn't listening!

Or if SSH must be listening, the openstack service could use the service to probe for the SSH host keys, which could be securely published, for a tool to injest avoiding the 'unknown host' or 'this host key has changed' that plagues cloud use.

Very cool, I look forward to this filtering into use at all the right layers.

tmpfiles footgun, apply directly to the forehead

mjg59 — Mon, 17 Jun 2024 05:45:24 +0000

I'm the one who decided to expose efi variables via a filesystem in a way that let you rm things, and the intent was that it be mounted read-write by default. Any blame associated with rm -rf / bricking systems is on me, not systemd.

tmpfiles footgun, apply directly to the forehead

jccleaver — Mon, 17 Jun 2024 04:34:42 +0000

>None of this has anything to do with "tmpfiles" - it is just an unfortunate legacy name (that cannot be changed without breaking scripts), but sd-tmpfiles has not been about temporary files for years and years. Just check the entries in the tmpfiles.d directory, you'll see plenty of stuff under /etc/ and /var/.

What? Scope creep in systemd leading to bombs left for sysadmins years after the fact to discover the hard way? Surely not! That's impossible.

This ranks up there with the "Bricking laptops via an errant 'rm' command is a Good Thing" rationalization.

Ubuntu's defaults for btrfs root have been subvolumes for @home and @ for over a decade

Kamilion — Mon, 17 Jun 2024 01:54:25 +0000

Hm, This has always been the way ubuntu's done things whenever I've asked for btrfs root. I get two subvolumes, `@` and `@home`.
The apt-btrfs-snapshot package will add a hook that takes a snapshot of @ while excluding @home during most package management activities. I've found it to be quite helpful in the past *decade* since it's introduction somewhere around 2011-2013.

tmpfiles footgun, apply directly to the forehead

bluca — Sun, 16 Jun 2024 22:44:30 +0000

> Much appreaciated, that I have to be on LWN to get that important information about what defaults you changed on my system.

It's not important information at all, and no defaults are changed. If you manually run some tools you don't know anything about, then you should read its documentation and the configuration files that come with it beforehand, that's just common sense. Nothing happens if you don't run it, so you don't have anything to worry about. As clearly explained in the documentation, these subvolumes are only created if the directories are missing, which happens only on firstboot with a read-only rootfs subvolume.

tmpfiles footgun, apply directly to the forehead

mb — Sun, 16 Jun 2024 21:48:08 +0000

>Then mask it/override it

Yeah, thanks for letting me know on LWN.
Much appreaciated, that I have to be on LWN to get that important information about what defaults you changed on my system.

What about: Do not change defaults. Ok?

tmpfiles footgun, apply directly to the forehead

bluca — Sun, 16 Jun 2024 21:40:05 +0000

> In fact, I use btrfs and I do _not_ want these to be subvolumes.

Then mask it/override it. It's a default configuration drop-in, shipped in /usr/ exactly to allow modifying to one's liking, this is 100% supported

tmpfiles footgun, apply directly to the forehead

mb — Sun, 16 Jun 2024 21:38:10 +0000

>The reason there's a config entry for the /home and /srv top level directories is to allow seamlessly making those into subvolumes for the BTRFS use case.

That doesn't make a lot of sense to me.
If I wanted these directories to be subvolumes, I would have created them as such. No magic "help" from systemd required.

In fact, I use btrfs and I do _not_ want these to be subvolumes.

tmpfiles footgun, apply directly to the forehead

bluca — Sun, 16 Jun 2024 21:26:26 +0000

> Why does tmpfiles have *anything* to do with /home at all on a normal system?

None of this has anything to do with "tmpfiles" - it is just an unfortunate legacy name (that cannot be changed without breaking scripts), but sd-tmpfiles has not been about temporary files for years and years. Just check the entries in the tmpfiles.d directory, you'll see plenty of stuff under /etc/ and /var/.

Its purpose today, and since quite some time, is providing declarative configuration for creating/removing/purging files and directories that are not shipped directly inside packages, which translates to pretty much anything outside of the vendor tree (/usr/).
The reason there's a config entry for the /home and /srv top level directories is to allow seamlessly making those into subvolumes for the BTRFS use case.

tmpfiles footgun, apply directly to the forehead

MarcB — Sun, 16 Jun 2024 19:02:46 +0000

> What the hell? Cleanup for home? How do I switch it off? I can't find it in the manpage.

Cleanup it is switched off, as indicated by "-".

To completely disable management of /home and /srv, place an empty home.conf in /etc/tempfiles.d/
You can verify success on older Systemds via "systemd-tmpfiles --cat-config | grep home"

> Managing /home with anything that has "tmp" in its name is a *serious* design mistake.

It's a configuration mistake. Arguably /home and /srv should not be included in the upstream configuration. It's just a footgun for people who like to run commands they don't understand as root. Since such people exist, deployments that need management of those folder should explicitly enable it.

tmpfiles footgun, apply directly to the forehead

mb — Sun, 16 Jun 2024 18:07:44 +0000

Why does tmpfiles have *anything* to do with /home at all on a normal system?
/home is the most NON-temporary file that exists on a normal system.

I found this in my default Debian config:

Q /home 0755 - - -

What does that even mean? And no, tmpfiles.d(5) is not at all helpful here.
The manpage says:

Q /subvolume-or-directory/to/create mode user group cleanup-age -

What the hell? Cleanup for home? How do I switch it off? I can't find it in the manpage.

Managing /home with anything that has "tmp" in its name is a *serious* design mistake.

tmpfiles footgun, apply directly to the forehead

bluca — Sun, 16 Jun 2024 17:11:15 +0000

> As systemd users have been discovering

I remain extremely skeptical that it actually happened. This is not a user-facing tool - and I mean the entire sd-tmpfiles, not just the new option. It's ran by units on boot and on timer events, and by packaging scriptlets. I am not aware of any documentation or manpage or hint or blog or anything that suggests "this is the tool you want to run manually to do random stuff".
I cannot possibly figure out the sequence of events that could accidentally and in good faith lead from (A) "I don't know what tmpfiles is or does or how it works or even that it exists. I want to delete some files from /var/cache/" to (B) "I will run sd-tmpfiles --purge as root without any specific configuration or input". I can't really see a path from A to B that is not artificially manufactured, and seeing where it came from, how it started and how it developed (ie, the usual pile on), further enhances my skepticism.

Of course having unclear footguns is not nice, so what we'll likely do is make this switch only act on specific input, and refuse to run 'globally', so you really have to say "please delete this and this", otherwise it does nothing. This seems like a decent compromise to me.

tmpfiles footgun, apply directly to the forehead

bluca — Sun, 16 Jun 2024 17:02:52 +0000

I didn't really add that for factory reset, although it could be useful for that too - I added that for packaging scriptlets so they can purge remains of data touched by a package. It's not run globally, but only using as input the tmpfiles.d provided by said package.

tmpfiles footgun, apply directly to the forehead

edgewood — Sun, 16 Jun 2024 16:03:09 +0000

Yes, a factory reset option should be named --factory-reset or something similar.

tmpfiles footgun, apply directly to the forehead

jak90 — Sun, 16 Jun 2024 15:08:19 +0000

At least the documentation has been appended [1] to somewhat convoy the intention that the --purge switch is ”useful for purge/factory reset patterns” and not just to unconditionally empty temporary directories, but this is not yet part of a release.
I think it's still better to at least rename this nuke switch long-term, if not only leverage the fact you don't need to immediately destroy the contents of a directory marked for subvolume creation.

[1] https://github.com/systemd/systemd/commit/9ebcac3b5125a8b...

tmpfiles footgun, apply directly to the forehead

flussence — Sat, 15 Jun 2024 12:49:11 +0000

> * 'systemd-tmpfiles --purge' will purge (remove) all files and
> directories created via tmpfiles.d configuration.

As systemd users have been discovering[1], this command will also remove all files and directories that *weren't* created by it which just happen to be listed in a default tmpfiles.d config. This includes all user data. There's a reason why we insist that different things should look different.

[1]: https://mathstodon.xyz/@bremner/112615591101488528

capsules?

jcpunk — Fri, 14 Jun 2024 21:09:17 +0000

This was extremely helpful thanks!

capsules?

intelfx — Fri, 14 Jun 2024 14:23:57 +0000

On the upside, you have 55 releases worth of time to invent another feature for that name ;)

capsules?

bluca — Fri, 14 Jun 2024 09:46:11 +0000

> The capsules feature (originally named projects or a range of other similarly hard to google terms)

I will never, ever get over the fact that my naming proposal, "workgroups", was rejected. I was ready to bump the version straight to 311 instead of 256, and call it the "systemd for workgroups" edition. I even made a logo. The shitposting would have gone on and on for months on end. Shame.

https://github.com/systemd/systemd/pull/29721#issuecommen...

capsules?

fishface60 — Fri, 14 Jun 2024 09:09:37 +0000

I did some digging when I heard about them so I think I might be able to answer that.

Generally it's that people were already using systemd --user instances to run applications under a different UID and had grown to depend on being able to start multiple services in a separate unit namespace.

It isn't ideal to misuse user sessions this way though because it requires a fixed UID allocation and has implications for logind and pam.

The capsules feature (originally named projects or a range of other similarly hard to google terms) exists to provide an alternative that strips out some of the parts of user sessions that aren't needed while still providing the benefits.

So if you wanted to provide a service that is implemented as a cluster of related units and they should share a dynamic UID for security reasons, you can do it as a capsule with a dynamically allocated UID instead of giving all your unit names a custom prefix and sharing a predefined user.

capsules?

jamesh — Fri, 14 Jun 2024 02:41:38 +0000

One that stands out to me is building a digital sign out of desktop tech that expects to run within a user session. Put a Wayland compositor, display app and any supporting services (maybe using a D-Bus session bus for communication).

Rather than creating a user and auto-starting a session for that user, it could just be started as a capsule.

capsules?

jcpunk — Thu, 13 Jun 2024 17:54:03 +0000

I'm still trying to find a workflow for this feature. Any ideas?

Finding the latest in a .v if you're not systemd

farnz — Thu, 13 Jun 2024 09:44:07 +0000

systemd provides systemd-vpick for that purpose.

What are .v/ directories used for?

epa — Thu, 13 Jun 2024 09:40:40 +0000

That sounds cool, but systemd could also create and update a 'latest' symlink within the .v directory once it has decided what version to run, so that other less smart programs can easily find the version currently in use.

What are .v/ directories used for?

farnz — Thu, 13 Jun 2024 09:26:28 +0000

They replace symlinks/hardlinks used to point you at "the latest" version of something like a container image or a discoverable disk image.

In a traditional setup, you have a file such as foo_container_v1.img, containing v1 of foo_container. You then have a symlink or hardlink pointing foo_container_current.img to foo_container_v1.img, and configure everything to point to foo_container_current.img. To update to foo_container_v2.img, you download foo_container_latest.img, rename it to foo_container_v2.img, then change the link to point to it.

.v directories solve this differently; you put files in foo_container.img.v, and when you give them the right names, systemd-vpick and other systemd tools like systemd-nspawn will pick up the latest version.

That's the basic mechanism, but systemd adds a couple of extras that aren't easily possible with the link-based version; firstly, systemd is architecture-aware, so you can use the same .vdirectory with the same contents across multiple systems (e.g. just copying it down as part of your fleet management). More usefully, systemd knows how to keep a retry counter in the filename, so you can download a new image, but if it fails to run, systemd will track this and do the "normal" automatic fallback to the old version. And you can look at ls in that directory to see the retry count.

So, using this with foo_container version 2, you'd download foo_container_latest.x86-64.img into the .v directory, then rename it to foo_container_2_x86-64+5-0.img. This is now a newer version than the existing v1, so the next time a systemd tool on x86-64 looks for foo_container.img in foo_container.img.v, it'll find this v2 image. Before it attempts to start it, it'll rename it to foo_container_2_x86-64+4-1.img, showing you that it's used up one retry. If it succeeds, it'll rename the file again to foo_container_2_x86-64.img, which will cause this to be used unconditionally if v2 is the latest. If it fails, it's kept under the new name; if it keeps failing, it'll eventually be renamed to foo_container_2_x86-64+0-5.img, which causes it to be ignored in favour of foo_container_1.img. And this is all ignored by an aarch64 host, which will stick to v1 until you bring in a new aarch64 container.

What are .v/ directories used for?

fishface60 — Thu, 13 Jun 2024 08:53:42 +0000

The idea is that .d directories which specify a bunch of config that all gets merged together are really convenient for just being able to drop an extra file in there and have less trouble resolving file conflicts when something updates,
but not everything can be merged like that so .v directories let you drop stuff in and pick the best option.

Suppose you had an application that was packaged as a container, in a disk image called /var/lib/machines/myapp.raw.
You could boot the container with systemd-nspawn or use the RootDirectory/RootImage options in a service file.

When an updated image is released you'd want to download it and try it out, but also keep the old version around so that you can roll back.

Instead of managing the container image by hand you can let the .v directory logic pick the most appropriate version, so in the directory named /var/lib/machines/myapp.raw.v/ you could have myapp_1.0.raw and myapp_2.0.raw. It will do a version sort of the version component of the file names and pick the latest.

If myapp_2.0.raw is broken though you don't want it to just keep attempting to boot the same image that failed forever, so it also supports a counter for the number of attempts in the file name,
so instead of saving the image as myapp_2.0.raw it could be saved as myapp_2.0+2.raw, which means try running it twice.
The first time it starts to boot it renames it to myapp_2.0+1-1.raw, then if that fails it starts again, renames it to myapp_2.0+0-2.raw, but because the tries counter after the + is 0, if it fails and is restarted, myapp_2.0+0-2.raw won't be tried again and myapp_1.0.raw will be booted instead.
If myapp_2.0+M-N.raw does successfully boot though it gets renamed to myapp_2.0.raw and bypasses the counter logic in future because it's known to be good.

It can also select by CPU architecture so you could have myapp_2.0_arm64.raw and myapp_2.0_x86-64.raw on some network share used by a heterogeneous server farm and it pick the correct version.

Round numbers

python — Thu, 13 Jun 2024 01:18:10 +0000

Finally a round number release 2^8. Will we ever make it to 2^9?

What are .v/ directories used for?

python — Thu, 13 Jun 2024 01:16:52 +0000

What are .v/ directories useful for for? (I am a new to this)

blog story

bluca — Wed, 12 Jun 2024 18:50:01 +0000

But then you miss all the sh*tposting

blog story

dskoll — Wed, 12 Jun 2024 18:40:20 +0000

The .v/ directories are a great idea. I hope other packages adopt this.

blog story

bof — Wed, 12 Jun 2024 18:09:30 +0000

Just my opinion - from a readability point of view, your blog posts are 10x nicer than these Mastodon chatty-segmented-looking-things-with-sidebars.

blog story

mezcalero — Wed, 12 Jun 2024 15:44:43 +0000

BTW, I posted a blog story here that links all 16 mastodon posts i did about key features of v256, for anyone interested:

https://0pointer.net/blog/announcing-systemd-v256.html