Change:
certificates and keys, etc.) must now be readable by this less privileged user/group. </para> <ins> <para> To continue to use the old approach, you can configure: <programlisting> services.nginx.appendConfig = let cfg = config.services.nginx; in ''user ${cfg.user} ${cfg.group};''; systemd.services.nginx.serviceConfig.User = lib.mkForce "root"; </programlisting> </para> </ins> </listitem> <listitem> <para>

Discussion:
PR broke -- first discovered in Before that PR, the systemd service ran as , so the nginx master process ran as root, and then the worker processes ran as an unprivileged user ( , or by default if thta line is not given). Now the systemd service runs as , including the master process. When you change the default back to root (e.g. because your setup needs the master process to be root, or for replicate the setup as it was in 19.09) using , it does not work out of the box. That is because the module now assumes that nginx will run only as 1 user, and it sets file system permissions that way. But nginx running as root makes nginx drop privileges to or the configured , and the file system permissions are not set up correctly for that as shown in
FYI this is how I'm handling the situation with : The sysadmin should override and to set the master process user and group, while the and options set the effective user and group.
The way the tmpfile rules are currently written is that the group doesn't have write, only read access to . So it doesn't really work well with running the nginx master process as root, and then drop permissions to a regular user. I assume you also don't want to run worker processes as root either :laughing:… I'm not sure how to properly approach this problem. Can you elaborate a bit on what's your usecase as running the master process as root?
are you able to test this configuration out and report back: Please take special consideration to look over your directory (under ) and the permissions there. I'm not familiar on what user/group permissions the process assigns to log files when it runs with as the master process... possibly a minor tweak to the will be required, but let me know what happens with your test. If this works we need to simply add documentation on how to run with as the master process, as I have explained above.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Just from the go/no-go meeting, I approved of changes being backported to 20.03
I've gone ahead and tested the above configuration snippet.

I had to make a few tweaks and ended up with this as the required configuration to get to run with as the master process but as the child processes: can you please describe your requirement to run the master process as ? I'm not familiar with so I have a hard time judging whether your case is an edge case or not. depending on the answer from we need to make a decision about whether we need to simply improve documentation, or improve documentation and modify the module code to make this use case better supported. I'm currently leaning toward this being a documentation only thing, but let's wait to hear what has to say.
I think your suggestion is good, I will try it today for our setup and report back. If it works, then I agree that it is sufficient to document your approach in the release notes (and perhaps as a description in one of the config options (probably the one for is best). On my use case, it is: being able to configure nginx the same way it was running on 19.09 for smoother migration, also so that one can upgrade to 20.03 already before fixing all the other things one's nginx uses that may rely on the master running as root
NixOS does not complain when options on non-existent systemd services are set (should it?) -- that took a while to figure out :grin:
I have checked your approach now on my staging deployment; it works (with the typo removed). What we should add to the changelog:
glad to hear. Thanks! :tada:
PR: We should cherry-pick it on after merge.
Thanks for finding the best solution!