Mohamed Lrhazi
2011-Nov-30 01:50 UTC
[Puppet Users] puppetlabs-firewall: hostnames Vs IP addresses
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Mohamed Lrhazi
2011-Nov-30 15:34 UTC
[Puppet Users] Re: puppetlabs-firewall: hostnames Vs IP addresses
Just saw this bug report: http://projects.puppetlabs.com/issues/10723 Sorry. Thanks. On Tue, Nov 29, 2011 at 8:50 PM, Mohamed Lrhazi <lrhazi@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ken Barber
2011-Nov-30 16:30 UTC
Re: [Puppet Users] Re: puppetlabs-firewall: hostnames Vs IP addresses
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 <lrhazi@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 <lrhazi@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Mohamed Lrhazi
2011-Nov-30 17:31 UTC
Re: [Puppet Users] Re: puppetlabs-firewall: hostnames Vs IP addresses
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 <ken@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 <lrhazi@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 <lrhazi@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ken Barber
2011-Nov-30 18:10 UTC
Re: [Puppet Users] Re: puppetlabs-firewall: hostnames Vs IP addresses
Agreed. On Wed, Nov 30, 2011 at 5:31 PM, Mohamed Lrhazi <lrhazi@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 <ken@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 <lrhazi@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 <lrhazi@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Mohamed Lrhazi
2011-Dec-07 23:41 UTC
Re: [Puppet Users] Re: puppetlabs-firewall: hostnames Vs IP addresses
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 <ken@puppetlabs.com> wrote:> Agreed. > > On Wed, Nov 30, 2011 at 5:31 PM, Mohamed Lrhazi <lrhazi@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 <ken@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 <lrhazi@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 <lrhazi@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.