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