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.
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.coilliot@think.fr>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.
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.coilliot@think.fr <mailto:louis.coilliot@think.fr>> 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 > <mailto:puppet-users@googlegroups.com>. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com > <mailto:puppet-users%2Bunsubscribe@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.
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.
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 <louis.c...@think.fr>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.
Reasonably Related Threads
- Whats the best approach to create a repo of the installers to be used for installing and upgrading in the puppet managed nodes
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- "What Calls What" diagram. Flow Chart?
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'