-
Notifications
You must be signed in to change notification settings - Fork 13
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
FIREWALL: Use rich rules instead of direct rules #69
Conversation
e417fb2
to
58ba70d
Compare
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.
Some inline comments, apart from that it looks good.
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.
LGTM. Thanks for all the explanations!
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.
I didn't review the code, but it looks ok conceptually.
As a rule of thumb - don't call any commands in init, use setup for that. This way, it is possible to call setup only when something from the utils is actually used (see mh_postpone_setup). And every change done must be reverted in teardown so we do not polute other tests.
Bump @thalman |
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.
Sorry, I did the review earlier and forgot to ACK it. Approving now...
@aplopez Please, resolve conflict and we can merge. |
Direct rules have been deprecated for some time now, so we switch to using rich rules. However, we need a specific policy to which the rule will be applied. This policy is permanent (a requirement) and is created at start up, deleted at teardown, and remains active during the whole test. Only the rules are dynamic.
Direct rules have been deprecated for some time now, so we switch to using rich rules.
However, we need a specific policy to which the rule will be applied. This policy is permanent (a requirement) and is created at setup, deleted at teardown, and remains active during the whole test. Only the rules are dynamic.
This works on RHEL 8 thourgh 10.