chr4-cookbooks / iptables-ng

Cookbook to maintain iptables rules and policies on different platforms, respecting the way the os handles these settings.
GNU General Public License v3.0
38 stars 33 forks source link

Old rules left around #24

Closed benlangfeld closed 10 years ago

benlangfeld commented 10 years ago

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?

chr4 commented 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

ichilton commented 10 years ago

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

ghost commented 10 years ago

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?

chr4 commented 10 years ago

@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.