Re: [Puppet Users] Re: A working firewall module
Just did,
Thank you!
Ronen
On Mon, Jul 11, 2011 at 1:50 AM, Ken Barber k...@puppetlabs.com wrote:
Hi Ronen,
Making the rules persistent is a matter of running iptables-save
afterwards. If you drop this in your top scope it should work:
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables /etc/sysconfig/iptables,
}
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
Can you raise a bug on the other issue about not detecting existing
rules? I'd appreciate being able to see any problematic rules (after
your own scrubbing of course). We'll then be able to try and fix it
for you.
https://github.com/puppetlabs/puppetlabs-firewall/issues
Alessandro's suggestions still hold true about applying firewall rules
with related classes. I'm a big fan of this methodology instead of
having a long list of rules. This is why a firewall type that handles
individual rules is a good approach.
ken.
On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis nark...@gmail.com wrote:
Hey Ken, the main issue was that the provider wasn't detecting existing
rules but instead kept adding them in, another issue is that the rules
aren't persistent (restarting the service clears them out),
Alessandro ill check it out thanks!
Ronen
On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber
kgbbelm...@gmail.com
wrote:
I have been working on doing something similar to this. We want to
abstract for multiple OS's and deal with the joy that is Solaris zones.
Essentially, it will be a resource that defines the fw rules in XML and
then a script takes all of those definitions and creates a complete set
of
firewall rules.
I am waiting to hear back on our code release policy to see what it
takes
to release it once I am done.
-- cwebber
On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
FYI
I don't know it it may be useful , but I've done this:
https://github.com/example42/puppet-modules/tree/master/iptables
which can be used in 2 ways:
- a standard iptable-save approach (set $iptables_config = file
before
to enable it) with rules file defined in
https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
(here you have to add source or content arguments to mange it with
static
files or templates according to your need)
- an automatic way (default option when you include the module) that
dymanically builds iptables rules according to the modules you include
and
the iptables related variables you set (see the README)
This actually works if you use the Example42 modules (or at least the
firewall defines included in each one).
It's quite nice to see it working adding or removing dynamically but, I
must admin, is a bit resource intensive (a puppet resoutce for each
dymanic
rule).
Regards
Al @ Lab42
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ.
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.
--
Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig;
--
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.
Re: [Puppet Users] Re: A working firewall module
Hey Alessandro the module works well, one issue that I had is that once
rules were applied the iptables service wasn't restarted, iv dug through the
code and indeed saw the notify under rule.pp:
concat::fragment{ iptables_rule_$name:
target = ${iptables::params::configfile},
content = $command $chain $true_rule -j $target\n,
order = $true_order,
ensure = $ensure,
notify = Service[iptables],
}
My guess is that the notify should be defined deeper in the defined
resource?
The only way I was able to make it restart was to use:
File[/etc/sysconfig/iptables] ~ Service[iptables]
Ronen
On Mon, Jul 11, 2011 at 12:59 PM, Ronen Narkis nark...@gmail.com wrote:
Just did,
Thank you!
Ronen
On Mon, Jul 11, 2011 at 1:50 AM, Ken Barber k...@puppetlabs.com wrote:
Hi Ronen,
Making the rules persistent is a matter of running iptables-save
afterwards. If you drop this in your top scope it should work:
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables /etc/sysconfig/iptables,
}
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
Can you raise a bug on the other issue about not detecting existing
rules? I'd appreciate being able to see any problematic rules (after
your own scrubbing of course). We'll then be able to try and fix it
for you.
https://github.com/puppetlabs/puppetlabs-firewall/issues
Alessandro's suggestions still hold true about applying firewall rules
with related classes. I'm a big fan of this methodology instead of
having a long list of rules. This is why a firewall type that handles
individual rules is a good approach.
ken.
On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis nark...@gmail.com wrote:
Hey Ken, the main issue was that the provider wasn't detecting existing
rules but instead kept adding them in, another issue is that the rules
aren't persistent (restarting the service clears them out),
Alessandro ill check it out thanks!
Ronen
On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber
kgbbelm...@gmail.com
wrote:
I have been working on doing something similar to this. We want to
abstract for multiple OS's and deal with the joy that is Solaris zones.
Essentially, it will be a resource that defines the fw rules in XML and
then a script takes all of those definitions and creates a complete set
of
firewall rules.
I am waiting to hear back on our code release policy to see what it
takes
to release it once I am done.
-- cwebber
On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
FYI
I don't know it it may be useful , but I've done this:
https://github.com/example42/puppet-modules/tree/master/iptables
which can be used in 2 ways:
- a standard iptable-save approach (set $iptables_config = file
before
to enable it) with rules file defined in
https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
(here you have to add source or content arguments to mange it with
static
files or templates according to your need)
- an automatic way (default option when you include the module) that
dymanically builds iptables rules according to the modules you include
and
the iptables related variables you set (see the README)
This actually works if you use the Example42 modules (or at least the
firewall defines included in each one).
It's quite nice to see it working adding or removing dynamically but, I
must admin, is a bit resource intensive (a puppet resoutce for each
dymanic
rule).
Regards
Al @ Lab42
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ.
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.
--
Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig;
--
You received this message
Re: [Puppet Users] Re: A working firewall module
Thanks for the feedback and the bug report, Ronen.
I'll check it..
On Monday, July 11, 2011 3:28:27 PM UTC+2, Ronen wrote:
Hey Alessandro the module works well, one issue that I had is that once
rules were applied the iptables service wasn't restarted, iv dug through the
code and indeed saw the notify under rule.pp:
concat::fragment{ iptables_rule_$name:
target = ${iptables::params::configfile},
content = $command $chain $true_rule -j $target\n,
order = $true_order,
ensure = $ensure,
notify = Service[iptables],
}
My guess is that the notify should be defined deeper in the defined
resource?
The only way I was able to make it restart was to use:
File[/etc/sysconfig/iptables] ~ Service[iptables]
Ronen
On Mon, Jul 11, 2011 at 12:59 PM, Ronen Narkis nar...@gmail.com wrote:
Just did,
Thank you!
Ronen
On Mon, Jul 11, 2011 at 1:50 AM, Ken Barber k...@puppetlabs.com wrote:
Hi Ronen,
Making the rules persistent is a matter of running iptables-save
afterwards. If you drop this in your top scope it should work:
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables /etc/sysconfig/iptables,
}
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
Can you raise a bug on the other issue about not detecting existing
rules? I'd appreciate being able to see any problematic rules (after
your own scrubbing of course). We'll then be able to try and fix it
for you.
https://github.com/puppetlabs/puppetlabs-firewall/issues
Alessandro's suggestions still hold true about applying firewall rules
with related classes. I'm a big fan of this methodology instead of
having a long list of rules. This is why a firewall type that handles
individual rules is a good approach.
ken.
On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis nar...@gmail.com wrote:
Hey Ken, the main issue was that the provider wasn't detecting existing
rules but instead kept adding them in, another issue is that the rules
aren't persistent (restarting the service clears them out),
Alessandro ill check it out thanks!
Ronen
On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber
kgbbe...@gmail.com
wrote:
I have been working on doing something similar to this. We want to
abstract for multiple OS's and deal with the joy that is Solaris
zones.
Essentially, it will be a resource that defines the fw rules in XML
and
then a script takes all of those definitions and creates a complete
set of
firewall rules.
I am waiting to hear back on our code release policy to see what it
takes
to release it once I am done.
-- cwebber
On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
FYI
I don't know it it may be useful , but I've done this:
https://github.com/example42/puppet-modules/tree/master/iptables
which can be used in 2 ways:
- a standard iptable-save approach (set $iptables_config = file
before
to enable it) with rules file defined in
https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
(here you have to add source or content arguments to mange it with
static
files or templates according to your need)
- an automatic way (default option when you include the module) that
dymanically builds iptables rules according to the modules you include
and
the iptables related variables you set (see the README)
This actually works if you use the Example42 modules (or at least the
firewall defines included in each one).
It's quite nice to see it working adding or removing dynamically but,
I
must admin, is a bit resource intensive (a puppet resoutce for each
dymanic
rule).
Regards
Al @ Lab42
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ.
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 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.
--
Join us
Re: [Puppet Users] Re: A working firewall module
Jonathan Boyett provided a patch for this problem:
https://github.com/puppetlabs/puppetlabs-firewall/commit/a7faff6f5b0de882bc720c8eb652d37b85a6b2a8
Looks like the crux of it was a Ruby 1.8.5 compatibility issue:
https://github.com/puppetlabs/puppetlabs-firewall/issues/3
Thanks.
ken.
On Mon, Jul 11, 2011 at 10:59 AM, Ronen Narkis nark...@gmail.com wrote:
Just did,
Thank you!
Ronen
On Mon, Jul 11, 2011 at 1:50 AM, Ken Barber k...@puppetlabs.com wrote:
Hi Ronen,
Making the rules persistent is a matter of running iptables-save
afterwards. If you drop this in your top scope it should work:
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables /etc/sysconfig/iptables,
}
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
Can you raise a bug on the other issue about not detecting existing
rules? I'd appreciate being able to see any problematic rules (after
your own scrubbing of course). We'll then be able to try and fix it
for you.
https://github.com/puppetlabs/puppetlabs-firewall/issues
Alessandro's suggestions still hold true about applying firewall rules
with related classes. I'm a big fan of this methodology instead of
having a long list of rules. This is why a firewall type that handles
individual rules is a good approach.
ken.
On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis nark...@gmail.com wrote:
Hey Ken, the main issue was that the provider wasn't detecting existing
rules but instead kept adding them in, another issue is that the rules
aren't persistent (restarting the service clears them out),
Alessandro ill check it out thanks!
Ronen
On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber
kgbbelm...@gmail.com
wrote:
I have been working on doing something similar to this. We want to
abstract for multiple OS's and deal with the joy that is Solaris zones.
Essentially, it will be a resource that defines the fw rules in XML and
then a script takes all of those definitions and creates a complete set
of
firewall rules.
I am waiting to hear back on our code release policy to see what it
takes
to release it once I am done.
-- cwebber
On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
FYI
I don't know it it may be useful , but I've done this:
https://github.com/example42/puppet-modules/tree/master/iptables
which can be used in 2 ways:
- a standard iptable-save approach (set $iptables_config = file
before
to enable it) with rules file defined in
https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
(here you have to add source or content arguments to mange it with
static
files or templates according to your need)
- an automatic way (default option when you include the module) that
dymanically builds iptables rules according to the modules you include
and
the iptables related variables you set (see the README)
This actually works if you use the Example42 modules (or at least the
firewall defines included in each one).
It's quite nice to see it working adding or removing dynamically but, I
must admin, is a bit resource intensive (a puppet resoutce for each
dymanic
rule).
Regards
Al @ Lab42
--
You received this message because you are subscribed to the Google
Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ.
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.
--
Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig;
--
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
[Puppet Users] Re: A working firewall module
FYI I don't know it it may be useful , but I've done this: https://github.com/example42/puppet-modules/tree/master/iptables which can be used in 2 ways: - a standard iptable-save approach (set $iptables_config = file before to enable it) with rules file defined in https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp (here you have to add source or content arguments to mange it with static files or templates according to your need) - an automatic way (default option when you include the module) that dymanically builds iptables rules according to the modules you include and the iptables related variables you set (see the README) This actually works if you use the Example42 modules (or at least the firewall defines included in each one). It's quite nice to see it working adding or removing dynamically but, I must admin, is a bit resource intensive (a puppet resoutce for each dymanic rule). Regards Al @ Lab42 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ. 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.
Re: [Puppet Users] Re: A working firewall module
I have been working on doing something similar to this. We want to abstract for multiple OS's and deal with the joy that is Solaris zones. Essentially, it will be a resource that defines the fw rules in XML and then a script takes all of those definitions and creates a complete set of firewall rules. I am waiting to hear back on our code release policy to see what it takes to release it once I am done. -- cwebber On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote: FYI I don't know it it may be useful , but I've done this: https://github.com/example42/puppet-modules/tree/master/iptables which can be used in 2 ways: - a standard iptable-save approach (set $iptables_config = file before to enable it) with rules file defined in https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp (here you have to add source or content arguments to mange it with static files or templates according to your need) - an automatic way (default option when you include the module) that dymanically builds iptables rules according to the modules you include and the iptables related variables you set (see the README) This actually works if you use the Example42 modules (or at least the firewall defines included in each one). It's quite nice to see it working adding or removing dynamically but, I must admin, is a bit resource intensive (a puppet resoutce for each dymanic rule). Regards Al @ Lab42 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ. 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.
Re: [Puppet Users] Re: A working firewall module
Hey Ken, the main issue was that the provider wasn't detecting existing rules but instead kept adding them in, another issue is that the rules aren't persistent (restarting the service clears them out), Alessandro ill check it out thanks! Ronen On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber kgbbelm...@gmail.comwrote: I have been working on doing something similar to this. We want to abstract for multiple OS's and deal with the joy that is Solaris zones. Essentially, it will be a resource that defines the fw rules in XML and then a script takes all of those definitions and creates a complete set of firewall rules. I am waiting to hear back on our code release policy to see what it takes to release it once I am done. -- cwebber On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote: FYI I don't know it it may be useful , but I've done this: https://github.com/example42/puppet-modules/tree/master/iptables which can be used in 2 ways: - a standard iptable-save approach (set $iptables_config = file before to enable it) with rules file defined in https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp (here you have to add source or content arguments to mange it with static files or templates according to your need) - an automatic way (default option when you include the module) that dymanically builds iptables rules according to the modules you include and the iptables related variables you set (see the README) This actually works if you use the Example42 modules (or at least the firewall defines included in each one). It's quite nice to see it working adding or removing dynamically but, I must admin, is a bit resource intensive (a puppet resoutce for each dymanic rule). Regards Al @ Lab42 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ. 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.
Re: [Puppet Users] Re: A working firewall module
Hi Ronen,
Making the rules persistent is a matter of running iptables-save
afterwards. If you drop this in your top scope it should work:
exec { persist-firewall:
command = $operatingsystem ? {
debian = /sbin/iptables /etc/iptables/rules.v4,
/(RedHat|CentOS)/ = /sbin/iptables /etc/sysconfig/iptables,
}
refreshonly = true,
}
Firewall {
notify = Exec[persist-firewall]
}
Can you raise a bug on the other issue about not detecting existing
rules? I'd appreciate being able to see any problematic rules (after
your own scrubbing of course). We'll then be able to try and fix it
for you.
https://github.com/puppetlabs/puppetlabs-firewall/issues
Alessandro's suggestions still hold true about applying firewall rules
with related classes. I'm a big fan of this methodology instead of
having a long list of rules. This is why a firewall type that handles
individual rules is a good approach.
ken.
On Sun, Jul 10, 2011 at 9:54 PM, Ronen Narkis nark...@gmail.com wrote:
Hey Ken, the main issue was that the provider wasn't detecting existing
rules but instead kept adding them in, another issue is that the rules
aren't persistent (restarting the service clears them out),
Alessandro ill check it out thanks!
Ronen
On Sun, Jul 10, 2011 at 10:38 PM, Christopher Webber kgbbelm...@gmail.com
wrote:
I have been working on doing something similar to this. We want to
abstract for multiple OS's and deal with the joy that is Solaris zones.
Essentially, it will be a resource that defines the fw rules in XML and
then a script takes all of those definitions and creates a complete set of
firewall rules.
I am waiting to hear back on our code release policy to see what it takes
to release it once I am done.
-- cwebber
On Jul 10, 2011, at 12:32 PM, Alessandro Franceschi wrote:
FYI
I don't know it it may be useful , but I've done this:
https://github.com/example42/puppet-modules/tree/master/iptables
which can be used in 2 ways:
- a standard iptable-save approach (set $iptables_config = file before
to enable it) with rules file defined in
https://github.com/example42/puppet-modules/blob/master/iptables/manifests/file.pp
(here you have to add source or content arguments to mange it with static
files or templates according to your need)
- an automatic way (default option when you include the module) that
dymanically builds iptables rules according to the modules you include and
the iptables related variables you set (see the README)
This actually works if you use the Example42 modules (or at least the
firewall defines included in each one).
It's quite nice to see it working adding or removing dynamically but, I
must admin, is a bit resource intensive (a puppet resoutce for each dymanic
rule).
Regards
Al @ Lab42
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/KSn4hF687gQJ.
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.
--
Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig;
--
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.
