Hi,
We where hitting the same issue also. We solved it like this:
- we have a fact that makes sure the iptables service is up on the machine.
Otherwise if the service is down, there will be no purge and we still get
the previous rules.
- we put the purge resource in a special class (something like
So puppetlabs-firewall is an active provider, whenever it 'runs' in
the catalog it applies the rule straight away. You are probably seeing
this because you're applying a blocking rule (like a DROP or default
DROP for the table) before the SSH allowance rule gets applied.
Take a close look at the p
To clarify; we have to use SSH to connect to the servers in this
environment, they are all VMs & the hosting provider does not give any
means of accessing a console (not ideal but sadly beyond our control).
Our standard process is after building a new server to have manually run
Puppet once to
On Tuesday, July 1, 2014 9:30:57 AM UTC-5, Danny Roberts wrote:
>
> I am using the Puppetlabs firewall module to manage our firewall. All
> servers get our core ruleset:
>
> *[...]*This worked perfectly when I spun up a server with no role (and
> therefore no extra rules. However when I spun up
Cory Thank you very much!!! that was the issue...
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/00.0.0.0/0 /* 000 accept
all icmp */
ACCEPT all -- 0.0.0.0/00.0.0.0/0 /* 001 accept
all to lo interface *
Hmm...
Do you have plugin sync turned on in the agent config? Should see
something like pluginsync = true in your puppet.conf. The error
specified seems to be having an issue fining the type which is sync'ed
from the master to the agents through plugin sync.
On Tue, Jul 1, 2014 at 1:50 PM, Pabl
Just a slight update this seems to happen on any server now, not just those
with the extra rules.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+u
If it helps this is what I see when running in debug mode:
debug: /Stage[main]/My_fw::Post/Firewall[999 drop all]/require: requires
Class[My_fw::Pre]
debug: /Stage[main]/My_fw::Pre/Firewall[001 accept all to lo
interface]/before: requires Firewall[002 accept related established rules]
debug: /St
I have been wondering this myself, I think the best way to find out is to
try it! So that's exactly what I'm going to do and I will report back what
happens.
On Thursday, January 23, 2014 2:49:58 PM UTC-6, Ygor wrote:
>
> In the documentation, it says:
>
> With the latest version, we now have in
On Wednesday, March 27, 2013 12:32:27 PM UTC-7, David Warden wrote:
>
> I'm also running in to this. Has anyone managed to get the puppet firewall
> module to manage both iptables and ip6tables?
>
>>
You can add rules to ip6tables by specifying provider => 'ip6tables' on
each firewall {} statem
I'm also running in to this. Has anyone managed to get the puppet firewall
module to manage both iptables and ip6tables?
On Monday, December 3, 2012 6:38:17 PM UTC-5, David Mesler wrote:
>
> Julia, did you ever figure this out? I'm running into this issue as well.
>
> --david
>
> On Tuesday, May
On 12/04/2012 03:56 PM, Terry Z. wrote:
I believe you have stumbled into the same issue I ran into when
attempting to workaround this with defined resources and unfortunately I
had to continue using the legacy bobsh-iptables module as a result
(which has its own inherent issues but at least prope
On Tuesday, December 4, 2012 10:02:42 AM UTC-5, jcbollinger wrote:
>
>
> On Monday, December 3, 2012 5:25:58 PM UTC-6, Dusty Doris wrote:
>>
>> [...] I'm trying to figure out how I can re-write this to make it work,
>> but it appears the puppet dsl only acts on arrays when they are the name
>>
On Monday, December 3, 2012 5:25:58 PM UTC-6, Dusty Doris wrote:
>
> [...] I'm trying to figure out how I can re-write this to make it work,
> but it appears the puppet dsl only acts on arrays when they are the name
> variable and then calls the resource once for each item in the array,
> pas
I believe you have stumbled into the same issue I ran into when attempting
to workaround this with defined resources and unfortunately I had to
continue using the legacy bobsh-iptables module as a result (which has its
own inherent issues but at least properly accepts an array in source.)
It is
Julia, did you ever figure this out? I'm running into this issue as well.
--david
On Tuesday, May 22, 2012 5:28:05 AM UTC-4, Julia Smith wrote:
>
> I'm trying to use the firewall resource and it works fine for me for
> iptables.
>
> However, I'm not sure how I purge ip6tables?
>
> doing...
>
Thanks for the reply. I will take a look at that patch.
I have been trying to accomplish this with defined resources, unfortunately
my particular case isn't working well for that.
Here is my attempt, perhaps anyone has some suggestions?
define myfirewall::accept($proto='tcp', $ports) {
fir
Dusty,
I actually had the same issue and brought this up with Ken Barber at
PuppetConf. I believe he and several others have looked into this briefly
but nothing much has come from it. There was a puppet bug report where
another user had managed to have it take arrays without too much
issue:
Thanks a lot for the example. I managed to make it work. Turns out
that in fw::post my firewall rules need to have the parameter before
=> undef in order to work.
On Tue, Jun 19, 2012 at 4:18 PM, Christian McHugh
wrote:
> I have this working in our environment as a module, which I will attempt to
I have this working in our environment as a module, which I will attempt to
describe.
module: casfirewall
init.pp
class casfirewall {
include casfirewall::default, casfirewall::fwpre, casfirewall::fwpost
file {"/etc/iptables":
ensure => "directory",
owner => "root",
group => "ro
Hello,
Thanks for the reply. I hope this is really not something related to
an incompatibility with puppet 2.7. Did anyone get this working using
puppet 2.7?
I have tried this with stages and I get the cyclic dependency problem.
Then I tried this solution using require => Class["fw::pre"] and
bef
On Tuesday, June 19, 2012 4:30:38 AM UTC-5, Ioannis wrote:
[...]
Stages generate cycles.
>
Yes, stages are prone to that.
Your solution tells me it cannot find the pre class:
>
No, *your application* of Ken's example tells you that.
Tue Jun 19 05:20:23 -0400 2012 Puppet (err): Failed to appl
Not working for me.
Stages generate cycles.
Your solution tells me it cannot find the pre class:
Tue Jun 19 05:20:23 -0400 2012 Puppet (err): Failed to apply catalog: Could
not find dependency Class[Fw::Pre] for Firewall[100 accept http
connections] at
It definitely does not like:
Firewall {
I also need to figure out how to code this rule:
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
--checksum-fill is not supported, in puppet-iptables, right? or can
arbitrary iptables parameters be passed along somehow?
I am using the purge option How would you
If negation is not possible, then maybe I can just use two rules?
firewall { '100 snat for network foo2':
chain => 'POSTROUTING',
action => 'accept',
proto => 'all',
source => ['192.168.122.0/24'],
destination => ['192.168.122.0/24'],
table => 'nat',
}
firewall { '101 snat for netwo
> 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?
No its not.
> Anyway, works great for us now. Thanks much!
Good to hear - I'll get the documentation fixed
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
> 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
Great! ... almost?
The Firewall notify dependency check almost covers everything. I really
like its elegance.
The one problem I can still think of is that the firewall module is not the
only one setting firewall rules. In the puppetlabs/apache module, for
example, it attempts to open up port 8
On Mar 13, 4:24 pm, Christian McHugh
wrote:
> I appreciate the interest but I don't understand how you can tell me you
> don't have any experience with the module but yet know that I'm doing it
> wrong.
I didn't say you were doing it wrong. I said you were incorrect that
run stages are the on
This ordering behaviour is as you state, and 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_. Ideally it would
be great to have insertion order and order in the firewall list to be
the same - but this doesn
In the pre main stage I have defined rules to allow outbound and allow
related and established. In the post main stage, it does a drop all. Before
this was organized into stages, occasionally the drop all would get applied
before keep established and allow outbound, and thus the client could los
I appreciate the interest but I don't understand how you can tell me you
don't have any experience with the module but yet know that I'm doing it
wrong. The puppetlabs firewall module does not have classes or anything
else to base a dependency on. I agree, I would rather not use stages, which
i
The numbering in the firewall resource names is not meant for ordering
their executing, but for guaranteeing their uniqueness.
I too found that using stages is the only usable way out of this.
Just out of curiosity, what do you mean by:
> We ended
> up in situations where the drop rules would ki
On Feb 15, 1:00 pm, Christian McHugh
wrote:
> Hi all,
>
> I'm attempting to use the puppetlabs-firewall module. In testing,
> rules are enabled in a random order, so it seems necessary to utilize
> puppet stages to guarantee proper ordering.
It is incorrect that you must use run stages to achi
Sounds interesting. As far as I've seen, the puppetlabs-firewall resource
activates instantly. I've not tried to have them all write out to a file
and trigger an exec iptables-restore.
If the firewall resource kicks the only way I think it can, then we had an
issue of firewall ordering. While
Looks like you are applying the rules in Pre, Main and Post stage using
firewall, i wonder what could be the requirement to apply the rules in
different stages instead of creating a File resource, Service notify
trigger using Exec iptables-restore, if you don't mind giving a little
elaboration.
>
> Thus far I've only been able to get puppet to run without making the
> firewall persistent.
>
In the case of running the exec save-rules in the post: it's no good if
your hosts are at all dynamic since it only runs after the main stage. So
if you have an existing host, add another normal f
I just tried something which seems to workaround the cyclic dependency issue:
- put the exec definition in the class that runs in the post stage.
- in site.pp put the default:
Firewall {
notify => Exec["persist-firewall"],
}
Thanks,
Mohamed.
On Fri, Mar 9, 2012 at 9:47 AM, Mohamed Lrhazi wr
Hi Christian,
I am running into this same issue... Did you resolve it?
Thanks a lot,
Mohamed.
On Wed, Feb 15, 2012 at 3:36 PM, Christian McHugh
wrote:
> I've got slightly more info. In trying to figure this out I ran across
> http://projects.puppetlabs.com/issues/10665 where it was suggested
>
I've got slightly more info. In trying to figure this out I ran across
http://projects.puppetlabs.com/issues/10665 where it was suggested
that the persist-firewall bits (already shown in the previous message)
get placed into site.pp. This almost worked perfectly.
I've placed the following inside a
On 4 January 2012 07:33, bel wrote:
> I'd reverse my stages if I were you. Seems like that will fix it.
>
> On Dec 27 2011, 11:02 am, Jure Pečar wrote:
> > On Tue, 27 Dec 2011 04:32:03 -0800 (PST)
> >
> > bel wrote:
> > > You could use stages as described in documentation:
> >
> > >http://forge
I'd reverse my stages if I were you. Seems like that will fix it.
On Dec 27 2011, 11:02 am, Jure Pečar wrote:
> On Tue, 27 Dec 2011 04:32:03 -0800 (PST)
>
> bel wrote:
> > You could use stages as described in documentation:
>
> >http://forge.puppetlabs.com/puppetlabs/firewall
>
> Now I've implem
Your iptables rules are wrong, that is why you lose SSH connection. I'd
look into those before worrying about Puppet.
On Wed, Dec 28, 2011 at 3:02 AM, Jure Pečar wrote:
> On Tue, 27 Dec 2011 04:32:03 -0800 (PST)
> bel wrote:
>
> > You could use stages as described in documentation:
> >
> > http
On Tue, 27 Dec 2011 04:32:03 -0800 (PST)
bel wrote:
> You could use stages as described in documentation:
>
> http://forge.puppetlabs.com/puppetlabs/firewall
Now I've implemented stages and indeed output of puppet agent makes me think
they are in place:
notice: /Firewall[002 allow icmp on et
You could use stages as described in documentation:
http://forge.puppetlabs.com/puppetlabs/firewall
On Dec 27, 1:48 am, Mark Walkom wrote:
> It's because puppet doesn't read sequentially but randomly accesses the
> module/class.
> You might be able to get around this by using a template.
>
> O
I run into a problem when I tried applying my new firewall module
based config on RedHat version 5 systems... the problem is that th
iptables-save behaves differently than the one on RedHat 6:
# /sbin/iptables --version
iptables v1.3.5
# /sbin/iptables-save | grep SSH
-A INPUT -s 10.128.0.0/255.12
Agreed.
On Wed, Nov 30, 2011 at 5:31 PM, Mohamed Lrhazi wrote:
> Right. hostnames are attractive ideal use case:
>
> - Allow all from nagios.my.dom.ain
>
> If someone changes the IP address of the monitor server, puppet would
> find out and fix the rule on all the monitored nodes!
>
> Maybe s
Right. hostnames are attractive ideal use case:
- Allow all from nagios.my.dom.ain
If someone changes the IP address of the monitor server, puppet would
find out and fix the rule on all the monitored nodes!
Maybe such a simplistic and ideal case is rare in the real world, but
it is attractiv
Yeah - I'm glad you spotted that I was just about to point it out.
Its a hairy problem - Jonathan has submitted a patch for it but its
stil in review. Generally the feeling is that having iptables use
hostnames can be flakey at times - especially if you try to add a rule
for a host where DNS is mi
> 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 cha
Just saw this bug report: http://projects.puppetlabs.com/issues/10723
Sorry. Thanks.
On Tue, Nov 29, 2011 at 8:50 PM, Mohamed Lrhazi wrote:
> Hello,
>
> The source and destination parameters accept both IP address or a
> hostname. If using a hostname, the firewall module thinks the rule
> change
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 fire
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
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 L
55 matches
Mail list logo
