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 mycompany::firewall::puppet_purge) and enforce it to run in the last stage (we use stages)
Best regards, Cristian Falcas On Fri, Jul 4, 2014 at 5:47 PM, Ken Barber <k...@puppetlabs.com> wrote: > 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 pre/post suggestion here: > https://forge.puppetlabs.com/puppetlabs/firewall#beginning-with-firewall > > Notice how it suggests creating a course-grained ordering to setup the > "DROP" rule as the very last thing that runs. Now to be clear this > concept is about puppet resource execution order, not the order which > the rules are setup in iptables (ie. with the number in the title). > > ken. > > On Fri, Jul 4, 2014 at 1:19 PM, Danny Roberts > <dannyroberts.perso...@googlemail.com> wrote: > > 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 bring it up to our standard ASAP. Normally Puppet runs > > daemonized beyond this point. > > > > This is our first production environmnet that uses the Puppetlabs > Firewall > > module so our first time encountering this in anger. Oddly the server > > remains unreachable via SSH after this for at least 2 hours which is > enough > > for 3/4 Puppet runs to sort out any issues. This still seems a bit long. > > > > I'm about to try another test by stopped the firewall before doing > another > > Puppet run on a fresh server to see how that behaves. > > > > > > On Wednesday, 2 July 2014 14:27:05 UTC+1, jcbollinger wrote: > >> > >> > >> > >> 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 servers with the 'puppet' & > >>> 'database' roles (and therefore the extra rules) it hung at: > >>> > >>> Notice: /Stage[main]/Mycompany/Firewall[9001 > >>> fe701ab7ca74bd49f13b9f0ab39f3254]/ensure: removed > >>> > >>> My SSH session eventually disconnects with a broken pipe. The puppet > >>> server I spun up yesterday was available when I got into the office > this > >>> morning so it seems they do eventually come back but it takes some > time. Is > >>> there any reason I am getting cut of like that and is there any way to > avoid > >>> it? > >> > >> > >> > >> I'm a little confused. What does your SSH session have to do with it? > I > >> don't find it especially surprising that an existing SSH connection gets > >> severed when the destination machine's firewall is manipulated by > Puppet, if > >> that's what you're describing. I would not necessarily have predicted > it, > >> but in retrospect it seems reasonable. > >> > >> I'm supposing that you were connected remotely via SSH to the machine on > >> which the agent was running, following the progress of the run in real > time. > >> In that case, are you certain that the run was in fact interrupted at > all? > >> Maybe the output from the remote side was curtailed when your SSH > connection > >> was disrupted, but the run continued. Or if you were running > un-daemonized, > >> then perhaps the run was interrupted when severing the SSH connection > >> produced a forced logout from the controlling terminal. > >> > >> Any way around, the fact that the subject systems eventually recover on > >> their own makes me suspect that the problem lies in how you were > monitoring > >> the run, rather than in your manifests. You could try running puppet in > >> daemon mode, or otherwise disconnected from a terminal, and checking > the log > >> after the fact to make sure everything went as it should. > >> > >> > >> John > >> > > -- > > 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+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/puppet-users/5eb83bdd-c8a5-4e36-956d-ff87eafd7acb%40googlegroups.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAE4bNTm94EFtp5ZsB9NzgYY0R4CRoEfkE84T1HX2ue4J3%2B8M3g%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMo7R_d2x-NE%3Dj8YZHuP0P2bEdcYrQRu0Kn9BUVYf53OTyN%2BVg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
