-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
replace deprecated usage of PermissionsStartOnly (part 2) #56265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
55b381c
to
8aea801
Compare
7569018
to
dddbff7
Compare
@aanderse something's looking weird here - did you push some on the branch than this PR? |
dddbff7
to
862c38a
Compare
No worries! Looks better now :-) How do you want to proceed with this? Gathering feedback from module maintainers? Running VM tests? |
I'm guessing quite a few of these modules don't have tests. In rare situations there could be implications in changing from a mkdir+chmod in the preStart script (which runs every time the service starts) to tmpfiles (which doesn't run every time the service starts, from what I read). Given that I don't know or use many of these modules I'd say run a test when it exists as a first pass, but also ping maintainers, then we can cherry pick individual module commits one by one. Given the timeline I think that should work out. For now I plan to hammer away at the brainless modules which are low hanging fruit, and then progressively work my way up to modules which require more thought and understanding of the program/service. That being said, if anyone wants to start pinging maintainers so individual commits can be cherry picked feel free. |
Update as of 2019-04-13: Thanks to everyone for their review and feedback. The first batch of changes which have either been reviewed or have a passing NixOS test are now going to be merged into master and then removed from this PR. Quick Summary: PermissionsStartOnly is deprecated and a module that you are listed as a maintainer for uses it. I have patched the module you maintain to not use PermissionsStartOnly anymore, but I would like a module maintainer (ie. you) to review the changes and sign off on it. More details: #53852 Please review the list below for your name and review the changes to your module(s). I haven't ran tests yet, so if you want to run a test and confirm everything is working, that all the changes makes sense, and there won't be any problems from my changes, that would be appreciated. If you have the ability to merge please go ahead and cherry pick the commit relevant to your module(s) if everything checks out and you're happy with the changes and then check off your module. If you do not have commit access please leave a comment stating that you accept the changes and are OK for them to be merged as is. If there are problems with the changes it would be great if you could provide a fix, or at least explain what the issue(s) are. Thank you for your time and effort. Note: If a module is checked that means no further action is required (because the module has already been merged, deprecated, taken care of by someone else, etc...) reviewed
not reviewed, but covered by tests
not reviewed, not covered
module to be deprecated
modules which I haven't written code for (yet?)
|
For |
@aanderse looks good! |
For |
Looks good. The tests for |
@@ -70,25 +70,25 @@ in { | |||
|
|||
config = mkIf cfg.enable { | |||
|
|||
systemd.tmpfiles.rules = [ | |||
"d '${cfg.dataDir}' - mopidy mopidy - -" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the ownership applied recursive by the way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. I only added the set recursive "Z" option when someone explicitly requested/thought was required.
To move this forward, I would suggest to split this pr into smaller ones. |
@Mic92 This is split into smaller. Normally I agree that too many changes are hard to digest, but in this case I thought everything is similar so I would keep in fewer PRs with 1 commit per change unless explicitly asked. Does anyone else request more PRs to split this up? |
@aanderse gollum looks fine. I tried to modify a few pages and didn't see any issues. |
Looks good, and looks ilke a ton of great work. Thank you a lot! Let's let this bake on unstable a bit. |
The supported way to create new directories in NixOS's systemd is using systemd.tmpfiles.rules (see NixOS/nixpkgs#56265). This commit hands off the initial data directory creation to systemd.tmpfiles.rules. All other preStart scripts are left intact to limit this changes scope. Further on we might have to do everything with systemd.tmpfiles.rules because PermissionsStartOnly is being deprecated. (see NixOS/nixpkgs#53852)
The supported way to create new directories in NixOS's systemd is using systemd.tmpfiles.rules (see NixOS/nixpkgs#56265). This commit hands off the initial data directory creation to systemd.tmpfiles.rules. All other preStart scripts are left intact to limit this changes scope. Further on we might have to do everything with systemd.tmpfiles.rules because PermissionsStartOnly is being deprecated. (see NixOS/nixpkgs#53852)
This is NixOS' recommended way to setup service dirs NixOS/nixpkgs#56265. This commit hands off the initial data directory creation to systemd.tmpfiles.rules. All other preStart scripts are left intact to limit this changes' scope.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/how-to-use-home-manager-module-inside-a-declarative-container/12427/5 |
Motivation for this change
#53852
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)