Issue #10711 has been updated by Alex Cline. File iptables-140-mask-patch.diff added
This behavior appears to be caused by a change in iptables-save 1.4.0 where masks are always printed by iptables-save[1]. Iptables 1.3.5 is in CentOS 5 and 1.4.7 is available in CentOS 6. There aren't any options for enabling mask printing in earlier versions of iptables-save. To work around it, I wrote a patch for the iptables code which will append a /32 mask to a source address that doesn't have one on a system that has an older version of iptables (<1.4.0). [1] http://www.netfilter.org/projects/iptables/files/changes-iptables-1.4.0.txt ---------------------------------------- Bug #10711: In 0.0.2 of puppetlabs-firewall, source property doesn't grok what '/32' means https://projects.puppetlabs.com/issues/10711#change-57448 Author: Justin Ellison Status: Re-opened Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: I'm about 80% sure this didn't happen with 0.0.1, but certainly could be wrong. Given the following resource: firewall { "test rule": action => 'accept', source => 127.0.0.1, state => "NEW", dport => '25', proto => "tcp", } Upon each puppet run after the initial insertion of the rule the first time, it tries to update the rule, because iptables reports that the source is '127.0.0.1/32' instead of just '127.0.0.1'. Obviously, those two values are functional equivalents. A quick workaround is to simply set source to '127.0.0.1/32' in the resource. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
