puppetlabs-firewall scope

[Louis Coilliot]

Hello,

I can't figure out how I can use the module puppetlabs-firewall only
for some targeted nodes.

If I put :

resources { "firewall": purge => true }

in top scope (i.e. site.pp),

then all the firewall rules on all my nodes are purged. Even for nodes
for which I don't apply any module containing specific firewall { ...
} resources.

If I put it in a module (i.e. myfw ), then for all nodes where I
apply a module containing firewall resources, I got a mix of the
previous rules (defined locally with the OS) and the new ones provided
with puppet.

Did I miss something or is it the expected behaviour ?

If this is expected, is there a workaround to apply the purge of the
rules only for some nodes where I want to apply specific firewall
rules through modules and puppet-firewall ?

Thanks in advance.

Louis Coilliot

[Shawn Foley]

I created a firewall module. In firewall/manifests/init.pp i have the following.

class firewall {

  ## Always persist firewall rules

  exec { 'persist-firewall':

    command  => '/sbin/iptables-save > /etc/sysconfig/iptables',

    refreshonly => true,

  }

  ## These defaults ensure that the persistence command is executed after

  ## every change to the firewall, and that pre & post classes are run in the

  ## right order to avoid potentially locking you out of your box during the

  ## first puppet run.

  Firewall {

    notify  => Exec['persist-firewall'],

    before  => Class['firewall::post'],

    require => Class['firewall::pre'],

  }

  Firewallchain {

    notify  => Exec['persist-firewall'],

  }

  ## Purge unmanaged firewall resources

  ##

  ## This will clear any existing rules, and make sure that only rules

  ## defined in puppet exist on the machine

  resources { 'firewall': purge => true }

  ## include the pre and post modules

  include firewall::pre

  include firewall::post

}

Then you just "include firewall"  

Shawn Foley
425.281.0182

Louis Coilliot

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Louis Coilliot]

Thanks a lot. Indeed, in that way it leaves my untargeted nodes alone. And I feel it's cleaner than putting things in the site.pp.

However I still have one little problem : at first application on some fw rules on a node with puppet, the purge of preexisting rules is slow, blocking the network temporarily.

Hopefully it comes back after a while.

I don't have this annoyance if I 'iptables -F' first.

See an example below.

I can work with that but if you have a workaround you're welcome.

Louis Coilliot

Info: Applying configuration version '1354997226'
/Firewall[9999 fe701ab7ca74bd49f13b9f0ab39f3254]/ensure: removed
/Firewall[9999 a627067f779aaa7406fa9062efa4550e]/ensure: removed
/Firewall[9999 49bcd611c61bdd18b235cea46ef04fae]/ensure: removed
Error: /File[nagios.vim]: Could not evaluate: Connection timed out - connect(2) Could not retrieve file metadata for puppet:///modules/nagios/nagios.vim: Connection timed out - connect(2)
Error: /File[nagiosvim-install.sh]: Could not evaluate: Connection timed out - connect(2) Could not retrieve file metadata for puppet:///modules/nagios/nagiosvim-install.sh: Connection timed out - connect(2)
Error: /File[/etc/vimrc]: Could not evaluate: Connection timed out - connect(2) Could not retrieve file metadata for puppet:///modules/vim/vimrc: Connection timed out - connect(2)
/Firewall[9999 b205c9394b2980936dac53f8b62e38e7]/ensure: removed
/Firewall[000 accept all icmp]/ensure: created
Info: /Firewall[000 accept all icmp]: Scheduling refresh of Exec[persist-firewall]
/Firewall[9999 d53829245128968bfa101d5214694702]/ensure: removed
/Firewall[001 accept all to lo interface]/ensure: created
Info: /Firewall[001 accept all to lo interface]: Scheduling refresh of Exec[persist-firewall]
/Firewall[002 accept related established rules]/ensure: created
Info: /Firewall[002 accept related established rules]: Scheduling refresh of Exec[persist-firewall]
/Firewall[003 accept SSH]/ensure: created
Info: /Firewall[003 accept SSH]: Scheduling refresh of Exec[persist-firewall]
/Firewall[999 drop all on INPUT eventually]/ensure: created
Info: /Firewall[999 drop all on INPUT eventually]: Scheduling refresh of Exec[persist-firewall]
/Firewall[999 drop all on FORWARD eventually]/ensure: created
Info: /Firewall[999 drop all on FORWARD eventually]: Scheduling refresh of Exec[persist-firewall]
/Stage[main]/Firewall/Exec[persist-firewall]: Triggered 'refresh' from 6 events
Finished catalog run in 196.45 seconds

[jgm...@gmail.com]

Hi Louis, 

Did you ever find a workaround for this problem? I'm experiencing the same thing, where the existing rules are not all purged at once so it causes the other resources to time out. This can last for up to 10 minutes so it can cause some problems.

Jeff

[Louis Coilliot]

Hello,

sorry I'm not sure because I'm now used to do a iptables -F just in case before applying puppet on a new node for the first time.

This is now in my standard provisioning procedure.

After that my fw rules are handled with puppet and I don't have any more problems.

I think I use some very basic settings :

https://github.com/lofic/puppet-myfirewall/blob/master/manifests/init.pp

And I've simplified it :

https://github.com/lofic/puppet-myfirewall/commit/a291413745fc73ac2d7a1c7e824ed9cb6fecbfa7

But may be you can give another try to the above conf with the exec on iptables -F

Let me know if it works for you.

Louis Coilliot

2013/11/30 <jgm...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4daeb960-1e85-4e80-ba48-bb101a7a70a8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.