FAQ
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

--
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.

Search Discussions

  • Shawn Foley at Dec 7, 2012 at 7:41 pm
    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

    On Tue, Dec 4, 2012 at 12:36 PM, Louis Coilliot wrote:

    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

    --
    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.
  • Louis Coilliot at Dec 8, 2012 at 8:23 pm
    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


    Le 07/12/2012 20:34, Shawn Foley a écrit :
    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


    On Tue, Dec 4, 2012 at 12:36 PM, Louis Coilliot
    wrote:

    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

    --
    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.
  • Jgmchan at Nov 30, 2013 at 9:47 am
    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
    On Sunday, December 9, 2012 7:22:58 AM UTC+11, Lofic wrote:

    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


    Le 07/12/2012 20:34, Shawn Foley a écrit :

    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


    On Tue, Dec 4, 2012 at 12:36 PM, Louis Coilliot <louis.c...@think.fr<javascript:>
    wrote:
    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

    --
    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<javascript:>
    .
    To unsubscribe from this group, send email to
    puppet-users...@googlegroups.com <javascript:>.
    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...@googlegroups.com<javascript:>
    .
    To unsubscribe from this group, send email to
    puppet-users...@googlegroups.com <javascript:>.
    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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@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.
  • Louis Coilliot at Dec 2, 2013 at 9:27 am
    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 <jgmchan@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

    On Sunday, December 9, 2012 7:22:58 AM UTC+11, Lofic wrote:

    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


    Le 07/12/2012 20:34, Shawn Foley a écrit :

    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

    On Tue, Dec 4, 2012 at 12:36 PM, Louis Coilliot wrote:

    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

    --
    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.
    --
    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.


    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@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.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE9jN31v0%2BfRS3_OSSpNn9yVK3WDWPdHQmrCwbQ-zxzR8H-o4Q%40mail.gmail.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 4, '12 at 8:42p
activeDec 2, '13 at 9:27a
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase