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.
