Note: upstream and packages on other distros now use the "knot-resolver" name on more places, e.g. /var/cache/knot-resolver/ instead of /var/cache/kresd/, user/group name and /etc/knot-resolver/. The cost/benefit ratio of doing such changes didn't seem very favorable to me, so I didn't touch those – at least for now. Well, moving /etc/ stuff is easy on NixOS, but users can't edit it anyway and they might not have motivation to even read from there, so it's perhaps unimportant.

I would migrate to upstream defaults soonish as it makes it easier to follow upstream documentation. And the stuff you mentioned here should not require user intervention in the most cases (different users, service names, cache directory)

• user+group: drop the current IDs? And either assign now ones or migrate to that "dynamic" scheme of systemd? (I'm not aware of a good way of renaming them, but I haven't looked much.)
• cache directory: the old one will just be left rotting, I guess? I consider instead adding tmpfiles spec that removes the old one.

I wonder whether to put all the changes into this single PR, but it probably doesn't really matter, given the (expected) number of reviewers.

* user+group: drop the current IDs?  And either assign now ones or migrate to that "dynamic" scheme of systemd?  (I'm not aware of a good way of renaming them, but I haven't looked much.)

knot-resolver looks like a good candidate for DynamicUser except that users might need a user/group in case certificates are generated via the acme module for chowning them (or any other secret managed by nixops/krops). It is not possible right now to rename uid/gids, however old ids just get recycled eventually.

* cache directory: the old one will just be left rotting, I guess?  I consider instead adding tmpfiles spec that removes the old one.

I fear that deleting user data causes more harm than it helps. I would just leave it as it is.

Right, if it would make it more difficult to give kresd read access to ACME certs, I don't think we want to go that way. So I'll get new fixed IDs, I suppose.

There should be no "user data" in the cache directory. I know we don't precisely follow FHS or similar, but still.

/var/cache/ Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches.

Still, if there are any doubts, not touching the old cache is the easiest approach.

Right, if it would make it more difficult to give kresd read access to ACME certs, I don't think we want to go that way. So I'll get new fixed IDs, I suppose.

The IDs don't need to be fixed. They can also be allocated at activation time, however a user/group name should be allocated for chown() to work.

There should be no "user data" in the cache directory. I know we don't precisely follow FHS or similar, but still.

/var/cache/ Flushing this directory should have no effect on operation of programs, except for increased runtimes necessary to rebuild these caches.

Still, if there are any doubts, not touching the old cache is the easiest approach.

Looks fine, I would just add a comment when to remove these tmpfile rules. For example NixOS 21.09.

The IDs don't need to be fixed. [...]

Whenever the IDs change, the file ownership won't match anymore. I think ownership can be force-changed by switching to "e" rule in tmpfiles, but overall I wonder about cost/benefit ratio.

The IDs don't need to be fixed. [...]

Whenever the IDs change, the file ownership won't match anymore. I think ownership can be force-changed by switching to "e" rule in tmpfiles, but overall I wonder about cost/benefit ratio.

If CacheDirectory is used than systemd should take care of fixing the ownership.

Right, that's a possible approach, if we remove the possibility to configure cacheDir location (or restrict it being within /var/cache/).

I don't think this option is often used anyway. Deprecating it makes things easier and it is always possible to put a different filesystem using a bind mount. Also see: 5c18c08

OK, let me remove that option.

By the way, larger deployments want to have cache in tmpfs to reduce the I/O load (and persistence across reboots isn't a big deal), and we/upstream recommend to mount a separate tmpfs on the cache directory instead of relocating it. Perhaps I'll add a simple NixOS option for this later, though I haven't yet looked into whether to do this via systemd features or plain filesystems."/var/cache/knot-resolver".

I incorporated all that's been discussed now, I think. Also minor fixes/improvements were added, and the git history was cleaned up. I'm using the service already, as usual.

All the namings (users, paths) should be the same now as in other distributions and (upstream) docs. I kept the services.kresd name, as I'm not aware of any equivalent elsewhere anyway – but it would be cheap to change (compatible).