`gitlab` >= 19.0 requires at least `postgresql` >= 17. GitLab users
are advised to follow the mentioned steps in the manual to upgrade their
PostgreSQL installation.
This changes how policy parameters are defined to allow user overrides.
Before, policy options were locked in `extraOpts` and users could not
change them. This commit splits them:
- `extraOpts` remains for fixed, locked values.
- `extraOptsRecommended` is added to provide sensible default values
that users can easily change later in the browser if they want to.
There is not reason to build an extra variant of OVMF only to get Secure
Boot support. We can just use the already built OVMFFull. Since
useSecureBoot is now no-op, it is also removed.
ids that were allocated and later freed only live in
/var/lib/nixos/{uid,gid}-map. userborn allocates from /etc/passwd
alone, so without this a new user could get a previously-used uid and
inherit file ownership.
Service has a ConditionPathExists on the uid-map and a sentinel under
/var/lib/userborn, so it runs at most once and is a no-op on fresh
installs.
Boots with the perl impl, removes a user, switches to userborn with a
new user, and asserts no uid collision and that the removed user is
revived with its original uid.
Fails until the migration service lands in the next commits.
If `cfg.user` is not default, there is no guarantee that `cfg.user` is a
member of `config.services.redis.servers.paperless.group`. In this case,
calls such as `paperless-manage document_renamer` would fail with
```
redis.exceptions.ConnectionError: Error 13 connecting to /run/redis-paperless/redis.sock. Permission denied.
```
The call to `sudo` in `paperless-manage` now explicitly sets group
membership to include both `cfg.group` and `config.services.redis.servers.paperless.group`.
With a redis instance enabled, `redisServer.user` was added to `defaultServiceConfig.SupplementaryGroup`.
While this technically works (since the group is derived from `redisServer.user` by default), `redisServer.group` exists and could be changed by an end user.
Using `redisServer.group` should preempt future issues.
Add a `group` option to simplify the module and stop relying on `users.users.${cfg.user}.group`,
which may not be present if `cfg.user` is created imperatively. See #547947
