Stop firewalld reload re-creating rules for deleted networks #49728
Conversation
23232f5 to
0927988
Compare
5490f9c to
9d482e0
Compare
akerouanton
left a comment
There was a problem hiding this comment.
Two small nits, otherwise LGTM.
9d482e0 to
ea7aca7
Compare
ea7aca7 to
13707b5
Compare
83cef04 to
0b0108c
Compare
| } | ||
|
|
||
| if err := nw.iptablesNetwork.reapplyNetworkLevelRules(); err != nil { | ||
| log.G(context.Background()).WithFields(log.Fields{ |
There was a problem hiding this comment.
Curious; are the locations where we'd ultimately would want the context to be passed? (which could be a context.WithoutCancel).
Probably fine for later, as these are not exported, just curious if passing context could help with tracing etc.
There was a problem hiding this comment.
Yes, potentially ... this function's called when a dbus message is received to say firewalld did-something, or on a signal. So, the context should be created a few calls up the stack from here, but Background seems appropriate in the meantime. (It will be an exported function in a couple of PR's time, but only from an internal package.)
| if !reloadedAt.IsZero() { | ||
| info.Info = append(info.Info, [2]string{"ReloadedAt", reloadedAt.Format(time.RFC3339)}) |
There was a problem hiding this comment.
So, we're mostly using this information to know whether a reload happened (and if so, when it happened), right? Would there be value in knowing when it was first applied, or is that not relevant for debugging purposes? (thinking; "first loaded at X", and a reload "2 seconds later").
There was a problem hiding this comment.
Yes - it's useful for debug. If we can see at-least one firewalld reload has happened, maybe it did something surprising. Or, if no reload has happened, perhaps it should have. And, it's a way for the daemon to signal to tests that they can continue after triggering a reload - a change in the timestamp means rules deleted by firewalld have been re-created by the daemon.
A few iptables rules are created on daemon init, and more at network creation or gateway update time. So, there's no single "load" time.
At some point, we could add a reload duration or triggered-at time, to report how long it takes to re-create the rules.
| return poll.Success() | ||
| } | ||
| return poll.Continue("firewalld reload not complete") | ||
| }, poll.WithDelay(100*time.Millisecond), poll.WithTimeout(20*time.Second)) |
There was a problem hiding this comment.
FWIW; default is 100 miliseconds interval (so we don't need to set it), and 10 seconds timeout. If 10 seconds would still be enough for this one, we could remove this config.
(not a blocker for sure; mostly that I removed a bunch of these at some point where the custom options were the same as the default)
There was a problem hiding this comment.
Ok, I can remove them ... ten seconds should be enough, we can always increase if it does lead to flaky tests, but that seems unlikely.
(Not sure removing it is good for at-a-glance readability though. I'm unlikely to remember the defaults, so will have to go and look them up if a test's misbehaving.)
Using iptables.OnReloaded to restore individual per-network rules on firewalld reload means rules for deleted networks pop back in to existence (because there was no way to delete the callbacks on network-delete). So, on firewalld reload, walk over current networks and ask them to restore their iptables rules. Signed-off-by: Rob Murray <[email protected]>
Signed-off-by: Rob Murray <[email protected]>
Signed-off-by: Rob Murray <[email protected]>
0b0108c to
c3fa7c1
Compare
- What I did
Improved restoration of iptables rules following a firewalld-reload ... only restore rules for current networks, and make sure networks aren't being updated while that happens.
- How I did it
- Restore iptables for current networks on firewalld reload
Using iptables.OnReloaded to restore individual per-network rules on firewalld reload means rules for deleted networks pop back in to existence (because there was no way to delete the callbacks on network-delete).
So, on firewalld reload, walk over current networks and ask them to restore their iptables rules.
- Report firewalld reload time in Info.FirewallBackend
To make it possible to write tests that wait for the reload to complete.
- Test that firewalld reload doesn't re-create deleted iptables rules
- How to verify it
Existing and new tests.
Checked that, without the fix, the new reload test fails.
Before the fix ...
- Human readable description for the release notes
- Fix an issue that could lead to unwanted iptables rules being restored and never deleted following a firewalld reload.