Closed benlangfeld closed 10 years ago
Thanks for using my cookbook!
This is not an issue, but regular design in chef. If you need to delete a obsolete rule, you need to specify it using the :delete
action.
See: https://github.com/chr4-cookbooks/iptables-ng/issues/10
I just had this same issue - I accidentally added a rule which had v4 source addresses in, without specifying 'ip_version 4' and ip6tables was failing. I realised and removed it, but it kept appearing until I cleared /etc/iptables.d.
Makes sense abotu :delete though - it works the same for packages - you can install a package, but if you remove that declaration from chef, it won't then remove that package unless you tell it to do so with :delete.
Ian
Trying to think of a possible solution to this. Why not compare what is on disk to the current rule set on each run. If they differ replace the rules on disk and reload?
@ichilton: Exactly, this is what I meant with "regular design in chef"
@gregf: While I had this though too, I never came up with a clean/decent idea. Remember that iptables rules might be created using different recipes or even cookbooks. One could store them on the chef-server using attributes, but I think this is a pretty messy. I think we'll just have to do it "the chef way", as this problem also applies to files, templates, packages and many more.
When defining rules using LWRPs, if I remove some resources from my recipe, their rules are left in iptables-persistent and can cause conflicts that cannot be applied.
For idempotency,
/etc/iptables/rules.v*
should be written from scratch on every chef run.Is this a known issue?