-
-
Notifications
You must be signed in to change notification settings - Fork 106
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
Changed sysctl configuration to exclusively use templates. #431
Conversation
Previously these settings were applied with ansible's sysctl option, but this ran into conflicts. This code provides two templates: one for generic sysctl hardening, and an other for disabling ipv6. Forgot to remove the ipv6 tag from the generic sysctl template. Cleanup, typos
6912d7d
to
86c6fcf
Compare
Cleanup, typos, squashed into 1 commit, should be done now, from my point at this moment. |
I'm fine with removing it, since it will be added later if requried.
No worries, I'm planning to add and remove some later onanyway
I'll update the README after this has been merged.
The linter was happy 👍 |
Updated as requested. |
Thanks @KoenDG! |
Ok, I said earlier I'd take a look next week, but I found I had nothing to do this evening, so I had a look and came up with this.
This code provides two templates: one for generic sysctl hardening, and an other for disabling ipv6.
In my opinion, this separates the concerns of generic sysctl hardening versus disabling ipv6. Both can be done on their own, and this way both can have their appropriate tags, and only those, without extras that only apply in certain situations.
This also works around an other issue where systemd's sysctl binary doesn't have the option to load only a single file with sysctl settings. You're stuck restarting the service completely, even if you only want to change 1 file. By splitting this into 2 config files, one doesn't hinder the other.
On top of that, I've added code to remove the ipv6 sysctl file, if the system doesn't have ipv6 support. This can happen if a previous run of these playbooks(or whatever the user did to their device manually) disabled it, and now there's a file there that doesn't apply.
I'm not sure it's strictly necessary to remove it, though it seems logically consistent. Maybe it's more pragmatic to leave it in place?
Which brings me to 2 final question:
I don't think "what if the user wants to re-enable ipv6" is a relevant question for this project, as if focuses on hardening only, not undoing the hardening.
So maybe 3rd question: should something to that effect be added to the readme? Or maybe it's already there, it's been a while since I checked.
I'm not sure about what the linter is going to say about what I've done, so that and any other remarks are welcome.