[Puppet Users] Re: Puppet Certificate's
of macs.puppetlabs.vm - you would substitute the certname you will use in your infrastructure) - allow macs.puppetlabs.vm 5. Now, we need to modify /etc/puppetlabs/puppet/puppet.conf on the NODES themselves. There are two changes that need to be made: the certname and the nodename. Remember that we need to decouple the name that SSL uses to identify the node (macs.puppetlabs.vm) with the name that PUPPET uses to CLASSIFY the node (node1.puppetlabs.vm and node2.puppetlabs.vm in our case). The first line you need to change in puppet.conf is the certname configuration item, set that to the following on ALL of your nodes: 'certname = macs.puppetlabs.vm'. If you're using Puppet Enterprise, that item should already be in the [agent] stanza, so you'll need to change it. The next configuration item could either go in the [agent] or [main] stanza, and that's the node_name_fact OR the node_name_value item. NOTE: THESE ITEMS ARE MUTUALLY EXCLUSIVE - YOU CAN ONLY USE ONE OR THE OTHER. For more information, see --http://docs.puppetlabs.com/references/stable/configuration.html#noden... The node_name_fact allows you to set the nodename based on a Facter fact. In my case I'm going to set 'node_name_fact = fqdn' on all of my nodes because I want the nodename to match the FQDN on the machine. If you're managing Macs, however, you might want to use something relatively static like a serial number (if you use something like the hostname, it will change any time someone renames their machine in the sharing pane). You could also do 'node_name_value = thisnode' and Puppet would classify the node based on the name of 'thisnode', but you would need to have that item be unique for every one of your nodes. This is a change you will need to evaluate in your own environment. 6. Once you've generated the cert, put it in the appropriate directories on the client, changed auth.conf, set puppet.conf on the agents, and everything is installed, you should be able to run `puppet agent -t` and watch things work! Note that if you're using the console, you will see the node records listed based on the nodename. Let me know if you have any other questions on this process :) On Thu, Apr 12, 2012 at 7:58 AM, Sean McGrath seanc.mcgr...@gmail.comwrote: Gary, Thanks very much for getting back to me on this. While I have been researching Puppet for our Mac fleet I have used a lot of the very useful information you have published about this so thank you very much for that. In regards your response. Firstly, apologies for my lack of knowledge in this matter and any help that can be provided will be very much appreciated. I am interested in #3 and am having looking at it now but the following are some of the things that have crossed my mind The private cert to distribute to the client nodes, which one from the master is it? There are a few there and I cannot tell which one it is and where does it go on the client? Is there any other configuration that is needed on the master? In the clients /etc/puppet/puppet.conf file would the following configuration be correct for this approach. [puppetd] node_name_fact = hostname node_name_value = certname # i.e. the one from the server Is this correct? Thats it for now, I'm going to stay playing around with this and see where I can get but any help and guidance that anyone can provide will be very much appreciated. Regards Sean On Apr 11, 5:32 pm, Gary Larizza g...@puppetlabs.com wrote: Hey Sean, First - congrats on wrangling your Macs with Puppet! Next, I understand and have shared your pain regarding timely imaging of workstations and Puppet cert-wrangling. Generally, I've seen folks do one of a couple of things: 1. Autosign 2. Utilize a CGI script to sign/revoke certs on the master (which can largely be replaced through the use of the `puppet cert` face) 3. Use the same private key everywhere and change the individual node_name Numbers 1 and 2 are largely process around signing individual certs for every node. You COULD even backup the $ssldir on your clients, image the machine, install puppet, restore the $ssldir, and then run Puppet again and Puppet will work fine for your clients. Number 3 is a bit different. With #3, you would have the SAME private cert for EVERY node in your infrastructure. Because of this, the certname must be THE SAME for every node. When you do this, however, Puppet treats every node as if it were the SAME node - so you need a way to de-couple the name of the node as Puppet knows it with the name of the node as the Certificate knows it. The solution is the 'node_name_fact' and 'node_name_value' configuration item in puppet.conf -- http://docs.puppetlabs.com/references/stable/configuration.html#noden... You would essentially ship the private cert around to EVERY node, set
[Puppet Users] Re: Puppet Certificate's
Gary,
Thanks very much for getting back to me on this. While I have been
researching Puppet for our Mac fleet I have used a lot of the very
useful information you have published about this so thank you very
much for that.
In regards your response. Firstly, apologies for my lack of knowledge
in this matter and any help that can be provided will be very much
appreciated.
I am interested in #3 and am having looking at it now but the
following are some of the things that have crossed my mind
The private cert to distribute to the client nodes, which one from the
master is it? There are a few there and I cannot tell which one it is
and where does it go on the client?
Is there any other configuration that is needed on the master?
In the clients /etc/puppet/puppet.conf file would the following
configuration be correct for this approach.
[puppetd]
node_name_fact = hostname
node_name_value = certname # i.e. the one from the server
Is this correct?
Thats it for now, I'm going to stay playing around with this and see
where I can get but any help and guidance that anyone can provide will
be very much appreciated.
Regards
Sean
On Apr 11, 5:32 pm, Gary Larizza g...@puppetlabs.com wrote:
Hey Sean,
First - congrats on wrangling your Macs with Puppet! Next, I understand and
have shared your pain regarding timely imaging of workstations and Puppet
cert-wrangling. Generally, I've seen folks do one of a couple of things:
1. Autosign
2. Utilize a CGI script to sign/revoke certs on the master (which can
largely be replaced through the use of the `puppet cert` face)
3. Use the same private key everywhere and change the individual
node_name
Numbers 1 and 2 are largely process around signing individual certs for
every node. You COULD even backup the $ssldir on your clients, image the
machine, install puppet, restore the $ssldir, and then run Puppet again and
Puppet will work fine for your clients.
Number 3 is a bit different. With #3, you would have the SAME private cert
for EVERY node in your infrastructure. Because of this, the certname must
be THE SAME for every node. When you do this, however, Puppet treats every
node as if it were the SAME node - so you need a way to de-couple the name
of the node as Puppet knows it with the name of the node as the Certificate
knows it. The solution is the 'node_name_fact' and 'node_name_value'
configuration item in puppet.conf
--http://docs.puppetlabs.com/references/stable/configuration.html#noden...
You would essentially ship the private cert around to EVERY node, set
the
node_name_{fact,value} in puppet.conf, and then Puppet would treat each
machine as a separate node (even though the certificate is the same
everywhere). Obviously there are security implications for this, but some
people prefer it to Autosigning.
Hopefully, this should help you on your way.
On Wed, Apr 11, 2012 at 8:31 AM, Sean McGrath seanc.mcgr...@gmail.comwrote:
Firstly my apologies for posting this if it has been answered
elsewhere and I missed it while looking.
I'm starting to look at using Puppet to manage our fleet of Mac's
running OS X in our lab environment and I'm quite impressed with it
from my testing so far.
I have tested the functionality of the autosign.conf file with the
hostnames of the trusted clients in it.
However, if I re-image one of the Mac's as we occasionally do that
destroys the client certificate that it uses for the puppetca request.
Thus the puppet master see's a request with a different certificate
from a node with a hostname that has had its trust relationship
established with a different certificate.
This is probably a noob question but I haven't been able to figure it
out. How do I get around this in an automated manner. I don't want to
have to revoke certificates each time I re-image a Mac so they can be
re-trusted by the puppet master. Is there something like a root
certificate I could build into the image to establish the trust
relationship easily and securely each time a Mac is re-imaged?
many thanks
Sean
--
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.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
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] Puppet Certificate's
Firstly my apologies for posting this if it has been answered elsewhere and I missed it while looking. I'm starting to look at using Puppet to manage our fleet of Mac's running OS X in our lab environment and I'm quite impressed with it from my testing so far. I have tested the functionality of the autosign.conf file with the hostnames of the trusted clients in it. However, if I re-image one of the Mac's as we occasionally do that destroys the client certificate that it uses for the puppetca request. Thus the puppet master see's a request with a different certificate from a node with a hostname that has had its trust relationship established with a different certificate. This is probably a noob question but I haven't been able to figure it out. How do I get around this in an automated manner. I don't want to have to revoke certificates each time I re-image a Mac so they can be re-trusted by the puppet master. Is there something like a root certificate I could build into the image to establish the trust relationship easily and securely each time a Mac is re-imaged? many thanks Sean -- 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.
