Puppet users - Nov 2011 - puppetlabs-firewall: How does it work?

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <lrhazi@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <lrhazi@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 <lrhazi@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <ken@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 <lrhazi@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
<lrhazi@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> 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?
The rules are changing whenever the resource is applied after the
catalogue is downloaded from the master. If the agent is running as a
daemon on its own, the order matters only a little.

The fix is specifically for a situation where you are running the
agent in the foreground via SSH for example (and usually the first
time you run Puppet on a box). The documented solution was added
because someone in the field hit this problem - if you don''t feel you
need it - you don''t need to use it.
> 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.
Okay.

So an alternate solution would be to store the rules in a file (like
/etc/iptables/rules.v4 for debian), and apply them late. Its been
suggested in the past, however it brings with it other
implications/problems. I think if there was enough demand for it an
alternative provider could be made to do this perhaps. Persistent vs
real-time handling for providers has always will been a contentious
area for Puppet :-).

ken.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.