[Puppet Users] Puppet agent certs: do they live in /etc/puppet/ssl or /var/lib/puppet/ssl?
Hi all, I have been trying to configure a number of puppet agents with certificates and keys that are pregenerated. In theory, this means putting the certs in the right place and starting puppet agent. In practise this seems to be hard. After installing the puppet v3.4.3 package on ubuntu 14.04, a directory tree is created under /var/lib/puppet/ssl as follows: /var/lib/puppet/ssl /var/lib/puppet/ssl/private_keys /var/lib/puppet/ssl/public_keys /var/lib/puppet/ssl/certs /var/lib/puppet/ssl/private /var/lib/puppet/ssl/certificate_requests I place the key and cert in this tree expecting puppet to do the right thing, but when I start puppet agent for the first time as below a new directory tree is created below /etc/puppet/ssl, new keys are created and all my pregenerated keys and certs are ignored: /etc/puppet/ssl /etc/puppet/ssl/private_keys /etc/puppet/ssl/private_keys/zonza-hogarth-dev-black-pup01.northeurope.azure.zonza.zone.pem /etc/puppet/ssl/public_keys /etc/puppet/ssl/public_keys/zonza-hogarth-dev-black-pup01.northeurope.azure.zonza.zone.pem /etc/puppet/ssl/certs /etc/puppet/ssl/private /etc/puppet/ssl/certificate_requests Is there a way to make puppet agent's behaviour predictable when it comes to certs and keys? Which directory is the one a puppet agent should be using, /etc/puppet/ssl or /var/lib/puppet/ssl? In all cases puppet is being run as root (with sudo). root@snip-brk01:~# sudo cat /etc/puppet/puppet.conf [main] certname = snip-pup01.snip server = snip-pup01.snip environment = dev runinterval = 1h Regards, Graham -- -- 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/c3da4c39-f739-4836-ae4c-b56e02b79ef4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Is puppet right for us?
On 07 Dec 2011, at 10:22 PM, Luke wrote: We are web app startup that is attempting to embrace the devops paradigm. We have a mixture of redhat and centos ESX VMs spread across dev/QA/ prod environments. We are currently using nagios for monitoring. Our servers consist of apache, tomcat and mysql. We are looking for open sourced software (we are a startup so we are broke! but commercial support could be an option once we get big). We are looking for a tool that will not only allow us to automate our complex server builds and web app deployments but will assist our devs with getting their builds ready to deploy. Monitoring, integration of Tomcat, mysql etc would be nice as well since configuring nagios is a pain. Can puppet do all of these things? Does it sound right for us? We are also considering CFengine and Chef. Would puppet be a better fit over these two? If so why? When we (a large media company facing the same problem) built our platform, we were Redhat based, and so initially chose RPM as a deployment mechanism, with RPMs rolled using maven (even the non Java ones). What that meant was that our applications and our configs were rolled into proper RPMs, deployed to yum repositories, and deployed using the same tooling that already existed on the OS. This had a number of advantages: - Developers were expected to integrate their own packages and deliver them as RPMs. This is immensely powerful - no longer do developers and integration teams play tennis with code lobbed over a wall, now it's purely the developers in control of the code. Apart from the initial resistance from developers (what? more work?), they soon realised the upsides (what? you mean it deployed somewhere else and just worked without anyone messing with my code?). If something went wrong, it was almost always the developer's fault, and the developer could just deploy the RPM to a sandbox and debug it. When something is clearly one person's fault, they just get on with fixing it, no fighting necessary. - Deployments were simple - deploy the RPM, done. This took discipline, as ops had to refuse complicated install instructions (anything beyond deploy RPM; restart service was rejected), but the advantage was that once the code was deployed to one environment, it could be deployed to the next and we'd know it would work. Because deployments were effectively all the same, they were quick to do, and didn't require any specialised training over and above that an ops person already knew about managing the system. This saved a fortune. - Rollbacks were both possible and simple - if something didn't work, you rolled back to the previous RPM, done. Suddenly deployments were far less risky, and downtime was negligible. Deployments were an office hours affair, and that saved a lot of money on staff. - Deployments were repeatable - If you deployed an RPM to a testing environment and it worked, you could deploy the RPM to a live environment and be assured that it would work without worrying that some 20 step process wasn't followed correctly. - Whatever you could do, you could undo - If you wanted to uninstall an application or website, you uninstalled the RPM, done. If you wanted to know what package owned a particular file on the machine, you asked RPM, it would tell you. - Documentation evaporated, and this is a Good Thing(TM). If everything works the same way, you don't need to document it beyond documenting the expected way to do things for the first RPM. There were some downsides though: - Configuration was deployed by RPM too, and for complex configurations (such as those of a whole class of webserver) this made sense and was a huge help, but for simple configurations this was a curse, as you had to release a new RPM for every change. - External config such as digital certificates were handled manually, and wasn't ideal. - Despite the protection provided by RPM, developers still found new and interesting ways to subvert the RPM process to break things. Fortunately this was the exception, not the rule. To solve this, we introduced puppet to complement the RPM based stuff above, and by and large it has been successful, but there have been downsides. - It is very tempting for someone who knows puppet to just do it in puppet, and we ended up with some configs done in RPM, and others in puppet. Complex configurations in puppet are big, unwieldy, slow to run, and difficult to understand, and cannot be uninstalled from the affected machines. - RPM includes the concept of versioning natively, but puppet expects you to apply your own versioning scheme outside of puppet, and in our case we just didn't. Sure, the puppet config was in source control, but there was no functionality to branch or tag, nor was there a way to deploy or roll back atomic changes. We no longer had the certainty of it worked in test so it will definitely work in live, and this was a step
[Puppet Users] Using puppet+augeas to modify multiple files
Hi all, I have a task to convince puppet and augeas to modify multiple postfix files, most specifically /etc/postfix/main.cf and /etc/postifx/ acceptdomains.cf (and other LDAP related files), and I'm struggling to find out how to do that. I have found examples on how to use augeas to modify just one file at a time, but no information seems to be available when multiple files are involved. I started with the config published here, and have no idea what to change to convince puppet+augeas to edit both /etc/postfix/main.cf and /etc/postfix/acceptdomains.cf at the same time: https://github.com/camptocamp/puppet-postfix/blob/master/manifests/config.pp Does anyone have a sample configuration on how you would modify multiple files at once, or have a clue on where to start? Regards, Graham -- -- 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.
[Puppet Users] Re: Using puppet+augeas to modify multiple files
On 27 Nov 2011, at 20:04, Graham Leggett wrote: I have a task to convince puppet and augeas to modify multiple postfix files, most specifically /etc/postfix/main.cf and /etc/postifx/ acceptdomains.cf (and other LDAP related files), and I'm struggling to find out how to do that. I have found examples on how to use augeas to modify just one file at a time, but no information seems to be available when multiple files are involved. I started with the config published here, and have no idea what to change to convince puppet+augeas to edit both /etc/postfix/main.cf and /etc/postfix/acceptdomains.cf at the same time: https://github.com/camptocamp/puppet-postfix/blob/master/manifests/config.pp Does anyone have a sample configuration on how you would modify multiple files at once, or have a clue on where to start? Answering my own question, I've discovered that augeas doesn't support multiple files at all without a custom lens being created to support it. Or to declare it more accurately, augeas only knows about specific files defined in specific locations, it has no concept of a general file in a general location that you might want to apply a lens to. I eventually worked around the issue by making a custom lens copied from the augeas postfix_main.aug lens that listed the extra ldap templates as matching a wildcard, at this point augeas started working correctly. Something else I discovered is that augeas has no error handling of any kind - if it doesn't recognise a file as matching one of the predetermined locations built into the lens, it will silently ignore the file, and not tell you why. Regards, Graham -- -- 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.
[Puppet Users] Templates + Parameterised classes
Hi all, I have found the puppet docs for parameterised classes, and I have found the docs for templates, but I cannot find it documented anywhere on how to expose a parameter from a parameterised class inside a template. I am trying to embed the parameter name using % parameter_name % inside the template, but all I get in the final file is the empty string, and no clear indication as to why. Is there a set of docs anywhere that explains how to do this? Regards, Graham -- -- 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.
