The rule order is lexical based on comment, however the order which
they get applied to the running ruleset during a puppet run, without
proper puppet ordering can be effectively random. This follows the
same rules as any puppet resource without explicit/implicit ordering.
Because of this, you may find reject rules getting applied before
allowed rules - which is undesirable at times - especially when your
SSH'd into a box and trying to run puppet for the first time ... and
you find yourself locked out of the box because of the rule apply
order.
One of the work-arounds for this is to put your accept rules in an
early order, and reject rules late. Stages are one way to do this, or
you can just use defaults and 'require', 'before' params this way.
I actually avoid stages by doing something like this:
Firewall {
before => Class["my_soe::fwpost"],
require => Class["my_soe::fwpre"],
}
Which is effectively the same thing.
We have feature requests raised that may actually make the resource
order part of the final ordering, but this is still pending design and
discussion (and code obviously :-).
ken.
On Tue, Nov 29, 2011 at 7:52 PM, Mohamed Lrhazi <lrh...@gmail.com> wrote:
> To clarify why I am asking how does this work...The doc has this
> intriguing advise: "If you wish to ensure any reject rules are
> executed last, try using stages..." Isn't the "rule order" integer in
> the resource name solving that problem?
>
> Thanks,
> Mohamed.
>
> On Tue, Nov 29, 2011 at 2:30 PM, Mohamed Lrhazi <lrh...@gmail.com> wrote:
>> Hello,
>>
>> Could someone clarify the philosiphy of this module... I need a way to
>> manage iptables on all my systmes, and trying to imagine how this
>> module would fit in,
>>
>> How does this module work? Does it check each supplied rule, for a
>> node, against its current rules, then insert rule if missing? or does
>> it just inserts the rules each time it is run?
>>
>> How are you using this module? Do you have all "standard" rules listed
>> in one class/module, then various modules inserting their own specific
>> rules elsewhere (in their own manifests)?
>>
>> Thanks a lot,
>> Mohamed.
>>
>
> --
> 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.
