the situation is only seemingly about ordering. The execution goes this way:
1) whole profile scan, create list of rules that 'fail'
2) run again, iterate over failed rules, remediate, and immediately scan
for the rule again (if pass -> result is 'fixed', otherwise 'error')
No matter the order, applicability of the remediation is evaluated based
purely on the first scan-only run.
So to solve this, every rule would have to be independent - your C
shouldn't check for package installed or service running. Just report if
configuration is or isn't there. (But then we are opening the can of
worms that is "rule C does not make sense, if profile does not contain B
Other option, if rules are dependent on each other, is to run
remediation N-times where N is depth of dependency.
On 4/17/19 7:48 PM, Alexander Bergmann wrote:
I have a question about the rules execution order. From my testing the
execution order is simply the rule order inside a group of a benchmark.
It looks like the order simply depends on the directory structure of
Is there a way to specify the execution order?
The reason I'm asking is the following. I have 3 rules A, B and C. Rules
B and C can only be executed successfully if rule A was executed before.
Sure, this is not a problem during normal evaluation, but the
remediation scripts will need the dependency. Otherwise the package is
not installed and the script will try to fix something.
An ugly workaround would be to run the remediation twice or three times,
but this should be avoided.
Any idea anyone? :)
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines