This file is used to define some fixed uids / gids for some application. A comment even specify
IMPORTANT!
We only add static uids and gids for services where it is not feasible
to change uids/gids on service start, in example a service with a lot of
files.
So my questions would be:
if which case one would add predefined uids/gids ?
some services like sonarr are mentioned in those files, but I don’t think they are really needed here. For example, if someone is just declaring users.users.sonarr.isSystemUser = true;, it’s enough to have a local system user dedicated to the service, without having to specify the uid, no ?
the ids.nix file mentioned that we mustn’t use “ids above 399”. Why is that so ?
When to simply create users with isSystemUser = true; as needed
When to not use any local users
The items above obviously only apply to non-interactive users.
Working backwards from the list - any service that can run using DynamicUser = true; should as the best kind of the user is the one we simply don’t have to care about. If no data needs to be used/accessed by local users or other services, that’s the ideal solution. The combination of DynamicUser = true;`````` and StateDirectory “foo”;``` gives you persistent storage and if that’s all you need, that’s great.
You can of course also just create users as needed, but the problem is determinism (or rather the lack of it). Your user foo could have id 123 on one system and 456 on another which isn’t ideal. So I would say that the 2nd option above should be the least frequently used.
A lot of services are defined with persistent uid/gid but simply because DynamicUser didn’t exist at the time. Many of them could easily be migrated to DynamicUser. But take something like a web server such as nginx. You probably need to have ways of writing in the files that nginx is serving so for that you will need to set permissions on directories and/or use users with certain group memberships - you cannot do this without persistent uid/gids.
Owning a bunch of files does not rule out DynamicUser. You would also need to be sharing those files with multiple services, or copying them across servers where some servers cannot use DynamicUser.
This article introducing DynamicUser is helpful for understanding what’s going on. The section named “What does this mean for you as a packager?” at the end talks about other cases where DynamicUser is not valid.
At the very beginning, I was working on this PR, and we asked ourselves if we should use DynamicUser or not (turns out the application prevent us to do so).
Sickbeard / Sickrage are writing a bunch of files to a folder specified by the user inside the application. So in theory, creating a single user (without predefined id) using user nixos option is working.
The only problem I see by doing this is, if you reinstall your server and re-execute your configuration, it’ll most likely not work, as nixos will create a new user without the same uid, and thus will not have access to the old files.
So the user solution (solution #2 from @peterhoeg’s list) is a valid solution, but not totally idempotent. However, I found this use case very restrictive, as the “reinstall the whole server” is not a common use case.
