Thank a lot Ken... Just to be sure and clear, the "lockout" problem is
not about locking puppet agent itself out, that is :
- All the rules, part of the catalogue, are retrieved from the puppet
master in one go, then applied one after another, in unpredictable
order, but there is no chance of firewall rules changing in the middle
of agent-master transaction, right?
I did see a problem where puppet agent fails to send its report back,
after a wrong iptables config was applied, but that is not the same
thing.
I do not like/feel the solution to the feared problem... so I just
wanna understand and live with it.
Thanks a lot,
Mohamed.
On Wed, Nov 30, 2011 at 8:56 AM, Ken Barber <k...@puppetlabs.com> wrote:
> 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.
>
>
--
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.
