I run into a problem when I tried applying my new firewall module based config on RedHat version 5 systems... the problem is that th iptables-save behaves differently than the one on RedHat 6:
# /sbin/iptables --version iptables v1.3.5 # /sbin/iptables-save | grep SSH -A INPUT -s 10.128.0.0/255.128.0.0 -p tcp -m multiport --dports 22 -m comment --comment "010 allow SSH traffic from subnet 10.128.0.0/9" -m state --state NEW -j ACCEPT I added this issue to : https://projects.puppetlabs.com/issues/10723 , but am not sure it is their bug to post to. Basically iptables-save does not report the IP addresses in the format expected by Puppet. On newer RedHat 6, it works: # iptables --version iptables v1.4.7 # iptables-save |grep SSH -A INPUT -s 10.128.0.0/9 -p tcp -m multiport --dports 22 -m comment --comment "010 allow SSH traffic from subnet 10.128.0.0/9" -m state --state NEW -j ACCEPT Am wondering if there is a workaround to this issue? Thanks a lot, Mohamed. On Wed, Nov 30, 2011 at 1:10 PM, Ken Barber <k...@puppetlabs.com> wrote: > Agreed. > > On Wed, Nov 30, 2011 at 5:31 PM, Mohamed Lrhazi <lrh...@gmail.com> wrote: >> Right. hostnames are attractive.... ideal use case: >> >> - Allow all from nagios.my.dom.ain >> >> If someone changes the IP address of the monitor server, puppet would >> find out and fix the rule on all the monitored nodes! >> >> Maybe such a simplistic and ideal case is rare in the real world, but >> it is attractive. >> >> Regarding DNS being reconfigured, I think that as long as we >> understand exactly how puppet would be impacted, it should be OK. DNS >> is not supposed to be misconfigured and puppet failure could be seen >> as a healthy event. >> >> Thanks, >> Mohamed. >> >> On Wed, Nov 30, 2011 at 11:30 AM, Ken Barber <k...@puppetlabs.com> wrote: >>> Yeah - I'm glad you spotted that I was just about to point it out. >>> >>> Its a hairy problem - Jonathan has submitted a patch for it but its >>> stil in review. Generally the feeling is that having iptables use >>> hostnames can be flakey at times - especially if you try to add a rule >>> for a host where DNS is misconfigured or broken for some reason. Maybe >>> the hostname doesn't exist yet for example. However - I realise some >>> people want to do this regardless of the risks so we are looking to >>> fix it. >>> >>> Anyway - the solution Jonathan has provided is looking reasonably good >>> and should be merged in soon. >>> >>> ken. >>> >>> On Wed, Nov 30, 2011 at 3:34 PM, Mohamed Lrhazi <lrh...@gmail.com> wrote: >>>> Just saw this bug report: http://projects.puppetlabs.com/issues/10723 >>>> >>>> Sorry. Thanks. >>>> >>>> On Tue, Nov 29, 2011 at 8:50 PM, Mohamed Lrhazi <lrh...@gmail.com> wrote: >>>>> Hello, >>>>> >>>>> The source and destination parameters accept both IP address or a >>>>> hostname. If using a hostname, the firewall module thinks the rule >>>>> changed each time it runs reporting: >>>>> >>>>> >>>>> notice: /Firewall[300 allow netbackup traffic from >>>>> nbmaster2-63.example.com]/source: current_value 192.168.63.42/32, >>>>> should be nbmaster2-63.example.com (noop) >>>>> >>>>> >>>>> Is there an easy workaround to this? other than not using hostnames? >>>>> >>>>> A similar issue is also seen with the value of debug-level. From some >>>>> reason it always thinks it needs to be reset: >>>>> >>>>> notice: /Firewall[998 drop noisy local traffic]/log_level: >>>>> current_value , should be warning (noop) >>>>> >>>>> >>>>> # Log everything else, then reject it with the default deny rule >>>>> firewall { '998 drop noisy local traffic': >>>>> state => 'NEW', >>>>> log_level => warning, >>>>> jump => 'LOG', >>>>> } >>>>> >>>>> iptables -nL shows this rule as: >>>>> >>>>> LOG tcp -- 0.0.0.0/0 0.0.0.0/0 /* 998 >>>>> drop noisy local traffic */ state NEW LOG flags 0 level 4 >>>>> >>>>> I tried setting "log_level" to 4, instead of "warning" and got : >>>>> >>>>> notice: /Firewall[998 drop noisy local traffic]/log_level: >>>>> current_value , should be 4 (noop) >>>>> >>>>> >>>>> Thanks a lot. >>>>> Mohamed. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Puppet Users" group. >>>> To post to this group, send email to puppet-users@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> puppet-users+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/puppet-users?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
