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.
