|
Top-level
 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: 5 comments
… 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… |
Gregory's Server
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), …