Super, it all works great!
Since the whole fwpre class is run before everything else, is it necessary
to define each resource with dependencies with firewall {"002 testing":
...}->firewall {... as in your gist?
Anyway, works great for us now. Thanks much!
All that remains is waiting for a new release to get firewall rules at boot
on debian, and then some magic work yet to be done for not stomping on
custom chains like fail2ban.
On Wednesday, March 14, 2012 11:53:31 AM UTC-5, Ken Barber wrote:
>
> > You said:
> >>
> >> the numbers in the namevar are ultimately for how they get
> >> ordered in the file ruleset as you state - but not what order
> >> they are _inserted_.
> >
> > Which makes me still think that the order various modules kick can affect
> > the firewall rules. Thus, a stage after main is still needed to guarantee
> > that the drop happens last. I hope I'm wrong, is there any alternative?
>
> If you look at my example in the gist:
>
> Firewall {
> notify => Exec["persist-firewall"],
> before => Class["my_soe::fwpost"],
> require => Class["my_soe::fwpre"],
> }
>
> I'm setting it so that by default, every rule firewall resource runs
> 'before' Class["my_soe::fwpost"], and it requires
> Class["my_soe::fwpre"]. So in this example it doesn't need stages -
> just put your pre & post in those classes.
>
> ken.
>
>
--
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/-/zzV3pegM5bUJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
