Here's the 16th installment of posts highlighting key new features of the upcoming v256 release of systemd.
(Sorry for dropping the ball on posting these for a while!)
The last feature I want to discuss in this series of postings is the new "capsule" concept of systemd v256.
systemd can be invoked in two contexts: as a system manager, i.e. PID 1, where it manages, well, the system. And as a user manager where it runs services for a specific user.
At any time on a single systemd machine you'll have 1 system manager and 0…n user managers running. This model is built around the traditional UNIX security model: UIDs are the primary security concept of the system, and thus we give each relevant UID a service scope of its own.
While the original purpose of the per-user service manager is to provide functionality for actual human users logging in interactively people have been using the concept for other purposes as well:
If one gives each "project" a user ID, then each project can define their own services, and one can "start" the project as a whole and terminate it by starting/stopping the user's (i.e. projects's) service manager.
This approach works fine, but it has various limits. For example, on UNIX it's not easy to get rid of users after creating them once. Because files are owned by UIDs, and there's not nice way to get from an UID to all files it owns (including on removable media, and such), …
… you cannot just delete a user and expect it's data to be gone too.
Except, that of course you can, because in systemd we have this nice little DynamicUser= concept: if you turn that on for a service it will allocate a user transiently while the service is running, and make it go away once it terminates. By running the service inside a tight mount namespace with very minimal write access only the functionality makes sure that the file removal problem becomes manageable:
if your service/dynamic user can only write to some very specific private directories, you can just delete those and be sure nothing of that dynamic user will persist.
So, what are those "capsules" then, that this story was all about? Well, it combines the concept of the per-user service manager and the concept of DynamicUser= into one thing: there's now a new template service capsule@.service which is very similar to user@.service. The latter wraps the per-user service manager…
… for regular users. The former is very similar: capsule@.service can be instantiated many times, and each will spawn a per-user service manager too – but has DynamicUser=1 set, i.e. it's a service manager for a dynamic, short-lived user.
So, what is this good for? The idea is that you place some service definition files in the .config/systemd/user/ subdir of /var/lib/capsules/<somename>/. The latter becomes the $HOME of the dynamic user created for capsule@.service.
With that in place, …
… you can then do "systemctl start capsule@<somename>.service" to start the capsule. This spawns a per-user service manager, with a shortlived dynamic user. Once you do "systemctl stop capsule@<somename>.service" it goes away again. And inside that service manager all services defined and enabled in the aforementioned directory will be invoked.
You don't really have to place service files in that dir btw. You can also just start the capsule as-is, and then invoke stuff dynamically inside…
… it via the `system-run --capsule=…` switch. And you can issue commands on and introspect the capsule's service manager via `systemctl --capsule=…` and so on.
You can stop a capsule and start it again later if you want, the capsules home directory will survive. Once you are done completely with the capsule's data, use `systemctl clean --all capsule@<somename>.service` to get rid of the home dir and everything else.
If you want to know more about the capsule concept, please see https://www.freedesktop.org/software/systemd/man/devel/capsule@.service.html
This is the last episode of this post series for v256 I guess. We have now gone through 16 major features of the upcoming release, and the final v256 final release is imminent.
Please have a look at the full NEWS file for more features, in particular all the smaller ones, which are also super interesting:
https://github.com/systemd/systemd/blob/main/NEWS
And thank you very much for your time! I intend to do a similar series for v257 once it comes closer.
@pid_eins Oh, yes, this is the missing piece to my currently quite hacky server setup! Thank you!
@ljrk Could you describe that setup? It sounds interesting 
@gd2 I still haven't finished the blog post as I'm not yet satisfied. Essentially I want to replicate the "old school" setup of per-service users (www for web, ftp for files, etc.) with their own "homes" (/var/srv/www or similar) but with unprivileged podman containers.
The containers are started by systemd user units which are generated by systemd itself. Currently it's a bit tricky though to have a systemd user unit for the www service generated from administrative configurations, effectively allowing the systemd user unit to "self-manage". Which is usually wanted but in case of web services you don't want to give your apache2/www user control over its own container configuration (and thus, restrictions).
@pid_eins thank you for taking your time to write those. While the technical explanation was really nice, I think it would help to include an example of how distros or end users can use the feature.
Also, thank you for systemd in general. As a sysadmin, it really helps to isolate services and keep them running inside defined boundaries.
@pid_eins thanks for the writing! Looking forward to using 256 on my machine.
@pid_eins Love reading those! Hope you can keep posting these from time to time where exciting things are happening.
@pid_eins Can you stop? Please? Just make your own OS instead of turning Linux into not-Linux. Enough is enough. I get that you have a lot of ideas that you like but please, just find a place to implement them that isn't Linux.
@me Nah, I'm happy with @pid_eins fixing many of the design choices that aged badly (UNIX is old and Linux inherited a lot of its crap!). And it's optional too! Nobody forces you to use systemd.
I know, many applications by now depend on systemd but that's out of the devs free will too. Just as if it's actually nice to build onto of systemd :)
@pid_eins that sounds cool! What are some example use cases for this capsule feature?
@pid_eins A bit late to the party, but can you elaborate on some example use-cases for this? Either way, cool stuff!