I’ve just added a feature to the SCM codebase: you can now specify the auditor to only use rules from a given level.
This means if you want to concentrate on just the Critical problems, you can tell SCM to use --rule-level critical, and it will only run the audit rules that are marked as being critical. If you’ve got a lot of audit issues, this can help you focus on specific problems.
Alternately, you might want to just run the Info rules to learn about the environment, and don’t want any noise about Warnings or Errors. No problem: --rule-level info
You can chain some rule levels together if you want to see just Warnings and Errors, or Info and Critical, or any combination you want.
The default is still to run all the rules you load.
Posted in Features, Reporting.
Tagged with audit, rules, scm.
I finally bit the bullet and rewrote the SCM audit logic.
Until now, the audit logic was based on the Rule condition evaluating to False. This was actually the opposite of what it should have been. It was originally written from a perspective of “check that this is true. If it isn’t, that’s a problem”, which makes a certain kind of sense if you think about it in that way.
The problem with this logic is that it’s usually the opposite of what you expect it to be. When writing an audit rule, you’re generally checking for something that’s broken. The logic in your head is “if this happens, that’s bad, so tell me”, which is the exact logical opposite of the original logic.
Several times I’ve found myself writing a new audit rule and having it fail in testing, and then doing a facepalm and thinking “oh yeah, that’s right. This thing wants it to be the other way around.” If I have trouble with this, what chance do you have?
So I changed it. And it’s much better this way.
Posted in Development, Features.
Tagged with audit, doh!, facepalm, logic, rule, scm.
