comment and log prefix NOT enclosed in " - makes iptables fail about puppetlabs-firewall HOT 12 CLOSED

Using quotes instead of ' had no effect on our systems. The problem persisted as long as log_level is used.

from puppetlabs-firewall.

@KlavsKlavsen I believe you have a rule that the firewall provider is unable to purge. The failed iptables -D command indicates this. What does your exist iptables-save look like today? If you purge the rule in question manually does the bug go away?

from puppetlabs-firewall.

The rule it's trying to purge was added, because the above manifest succeeds in adding the rule to iptables saved config - but fails to add it using iptables.
I then reloaded iptables service to see if the saved worked, and it did.

After removing the rule manually from iptables running config - it still fails, if I enable the manifest - exactly the same way.

It's trying to run:
/sbin/iptables -t filter -A INPUT -m comment --comment 998 Log all -j LOG --log-prefix default drop

If I enclose it like this:
/sbin/iptables -t filter -A INPUT -m comment --comment "998 Log all" -j LOG --log-prefix "default drop"

It works, when I run it manually.

from puppetlabs-firewall.

The rule it's trying to purge was added, because the above manifest succeeds in adding the rule to iptables saved config - but fails to add it using iptables.

That doesn't make sense. We add the rule first using iptables then we just run iptables-save usually to persist it. If we can't add the rule to the running configuration, we therefore can't persist it.

Anyway, I'm getting somewhat confused by your explanation and otherwise can't replicate it ... here is a gist of how I tried to replicate it ... can you do something similar for me ... showing steps so I can reproduce it here? https://gist.github.com/kbarber/5636235

from puppetlabs-firewall.

Here's the situation that's occurring for us.

If we start out with

firewall {'003 Log all INVALID packets':
  chain      => 'INPUT',
  proto      => 'all',
  state      => 'INVALID',
  jump       => 'LOG',
  log_level  => '3',
  log_prefix => 'IPTABLES Dropped Invalid: ',
}

and do a Puppet run, everything will work fine and iptables will be constructed as desired (although the bug in 184 will start occurring on subsequent runs).

If we then change the rule to be something like:

firewall {'003 Log all INVALID packets because racecar':
  chain      => 'INPUT',
  proto      => 'all',
  state      => 'INVALID',
  jump       => 'LOG',
  log_level  => '3',
  log_prefix => 'IPTABLES Dropped Invalid: ',
}

When we do a puppet run, puppet will not be able to remove the old rule, will return the error stated by the OP and as a result, iptables will now have duplicate rules with the comment from the rule in puppet being the only difference.

from puppetlabs-firewall.

@ITBlogger like this? https://gist.github.com/kbarber/5636445

from puppetlabs-firewall.

Yep, that's exactly what happens.

from puppetlabs-firewall.

I appearently got confused as to what was the cause - my issue is the exact same as you demonstrated, and as ITBlogger also has.

from puppetlabs-firewall.

Pull request #189 addresses this

from puppetlabs-firewall.

Should be fixed by #189, recently merged. @ITBlogger @KlavsKlavsen can you confirm?

from puppetlabs-firewall.

Yep, it looks like this bug is now fixed. Thought it might fix the other bug where puppet keeps regenerating iptables with every puppet run, but that bug is still there.

from puppetlabs-firewall.

@ITBlogger thanks for confirming. The other bug is still open.

from puppetlabs-firewall.