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 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...@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 view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/WYBrXIrm0RAJ.
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.

Reply via email to