-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add remediation for RHEL-08-040090 #427
Conversation
It _appears_ that the OSCAP content already takes care of this, but this will still show up on _some_ hardening-scans. Adding this state to make it easier to point to code that, "yes, watchmaker _is_ setting this, appropriately" Closes plus3it#422
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.
Curious about the choice of onchanges
...? Seems the states ought to be safe to use just requires
, due to unless
for module.run
and firewalld.present
already being stateful?
Modifications to firewalld can happen to either the running (in memory) or on-disk changes. The two conditionals are meant to account for both:
Basically, tried to implement a "update the running configuration |
Probably don't strictly *need* a dependency-path for this one, but going to leave it here until it proves problematic
Yeah. I saw the failure:
But was tied up with other task to figure out why it didn't like that. I mean, firewalld.present looks to be a valid module? I'll get to it next week. |
Ah. Ok. Not so much:
As:
Guessing the VM-setup for the testing-container is missing the setup tasks that were in the EL7-based testing-containers. |
Also: dependency-assertion is 'require' not 'requires'
Looks like |
It appears that the OSCAP content already takes care of this, but this will still show up on some hardening-scans. Adding this state to make it easier to point auditors to a block of code that easily tells them, "yes, watchmaker is setting this, appropriately"
Closes #422