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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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#nodenamefact
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.mcgrath@gmail.com>wrote:
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Hey there, I''ve got fire in ma belly to get this solved, as I''m impatient to use Puppet''s CA to bootstrap Simian, but due to this same sticking point the bootstrapping process is more ungainly then it should be. My point is we customize things about each machine while naming and binding, why can''t cert distribution (preceded by generation if necessary) be part of that step in the process? Then it''s a (debatably) more secure and simple process, in my opinion. Pardon I haven''t looked in to puppet cert yet(it allows me to generate certs for clients in advance based on supplied info/UUID''s/serial numbers, etc?), and I also need to figure out how generic I can make the puppet install/config in the deployed image so only this cert needs to be a custom addition. My proposal is scripting DeployStudio to add a filedrop (or similar) workflow to seed the right cert on the imaged system. I''ll report back as soon as I have a proof-of-concept. Allister On Apr 11, 11:31 am, Sean McGrath <seanc.mcgr...@gmail.com> wrote:> 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.com>wrote: > > > > > > > > > > > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hey Guys,
Let me try to step through this one step at a time. I recommend
downloading one of our VMs that we host for testing puppet (I''m using
the
VM we use for training located here -->
http://downloads.puppetlabs.com/training/puppet-vmware.zip but there''s
also
one for VirtualBox too -->
http://downloads.puppetlabs.com/training/puppet-vbox.zip) to test this
setup. If you do that, make sure DNS and networking are working (So, setup
host entries on your laptop for each VM, setup the hostname and FQDN ON
EACH VM, and make sure each VM can ping the VM Master). I''m using
three
VMs (a master and two agents): nodemaster.puppetlabs.vm,
node1.puppetlabs.vm, and node2.puppetlabs.vm. Once DNS resolves and is
working, setup Puppet on the master FIRST, and then setup the remaining
nodes as agents. Again, I recommend using the VMs and using Puppet
Enterprise because it makes it MUCH EASIER to setup Puppet - just use the
puppet-enterprise-installer script (once you get the process of using a
single cert and multiple node_names DOWN, THEN you can start on some actual
machines).
Now we can start customizing Puppet. There are a couple of key steps that
need to be taken since we''re shipping around a single cert for all
machines:
1. When you stand up a PE Agent, it''s going to contact the master and
setup
a Certificate Signing Request. Because of this, go to the master
node''s
$ssldir (which, on Puppet Enterprise, is /etc/puppetlabs/puppet/ssl. If
you want to find the $ssldir on YOUR master, just run `puppet config print
ssldir` and it will print it out for you) and remove the CSRs that are in
the ca/requests/ directory (they should be named after your nodes).
2. Next, lets generate the single certificate that will be shopped around.
You will need to use the same ''certname'' on every node. This
is the name
of the node as SSL is aware (in my case I''m using
''macs.puppetlabs.vm'').
Do this by doing `puppet cert generate macs.puppetlabs.vm` on your MASTER
machine. The master will generate the certs and your $ssldir will look
something like this:
ssl
|-- ca
| |-- ca_crl.pem
| |-- ca_crt.pem
| |-- ca_key.pem
| |-- ca_pub.pem
| |-- inventory.txt
| |-- private
| | `-- ca.pass
| |-- requests
| |-- serial
| `-- signed
| |-- macs.puppetlabs.vm.pem
| |-- nodemaster.puppetlabs.vm.pem
| |-- pe-internal-broker.pem
| |-- pe-internal-dashboard.pem
| |-- pe-internal-mcollective-servers.pem
| |-- pe-internal-peadmin-mcollective-client.pem
| `-- pe-internal-puppet-console-mcollective-client.pem
|-- certificate_requests
|-- certs
| |-- ca.pem
| |-- macs.puppetlabs.vm.pem
| |-- nodemaster.puppetlabs.vm.pem
| |-- pe-internal-broker.pem
| |-- pe-internal-mcollective-servers.pem
| |-- pe-internal-peadmin-mcollective-client.pem
| `-- pe-internal-puppet-console-mcollective-client.pem
|-- crl.pem
|-- private
|-- private_keys
| |-- macs.puppetlabs.vm.pem
| |-- nodemaster.puppetlabs.vm.pem
| |-- pe-internal-broker.pem
| |-- pe-internal-mcollective-servers.pem
| |-- pe-internal-peadmin-mcollective-client.pem
| `-- pe-internal-puppet-console-mcollective-client.pem
`-- public_keys
|-- foo.puppetlabs.vm.pem
|-- macs.puppetlabs.vm.pem
|-- nodemaster.puppetlabs.vm.pem
|-- pe-internal-broker.pem
|-- pe-internal-mcollective-servers.pem
|-- pe-internal-peadmin-mcollective-client.pem
`-- pe-internal-puppet-console-mcollective-client.pem
3. There are three files you need to collect on your master and ship
around to all of your nodes. They are ALL in the $ssldir, so these paths
are relative to THAT directory. The three files are:
- $ssldir/private_keys/macs.puppetlabs.vm.pem on the master -> gets
copied to the agent''s $ssldir/private_keys directory
- $ssldir/public_keys/macs.puppetlabs.vm.pem on the master -> gets
copied to the agent''s $ssldir/public_keys directory
- $ssldir/ca/signed/macs.puppetlabs.vm.pem on the master -> gets
copied to the agent''s $ssldir/certs directory
4. You need to modify /etc/puppetlabs/puppet/auth.conf on the master so
every node can access the find action on the catalog REST endpoint for the
master (i.e. The Mac nodes can get their catalog). Look for this stanza in
auth.conf:
# allow nodes to retrieve their own catalog (ie their configuration)
path ~ ^/catalog/([^/]+)$
method find
allow $1
Add the following line under ''allow $1'': (Remember that
I''m using the
certname 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#nodenamefact
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.mcgrath@gmail.com>wrote:
> 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.com
> >wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Gary, thanks very much for that. I got that to work as I wanted after a bit of fighting with other issues of my own creation. So I am very grateful to you for your help. If you ever in Dublin, Ireland. Look me up, I owe you a favor so I''m willing to pay back, within reason of course. Best Sean On Apr 12, 5:21 pm, Gary Larizza <g...@puppetlabs.com> wrote:> Hey Guys, > > Let me try to step through this one step at a time. I recommend > downloading one of our VMs that we host for testing puppet (I''m using the > VM we use for training located here -->http://downloads.puppetlabs.com/training/puppet-vmware.zipbut there''s also > one for VirtualBox too -->http://downloads.puppetlabs.com/training/puppet-vbox.zip) to test this > setup. If you do that, make sure DNS and networking are working (So, setup > host entries on your laptop for each VM, setup the hostname and FQDN ON > EACH VM, and make sure each VM can ping the VM Master). I''m using three > VMs (a master and two agents): nodemaster.puppetlabs.vm, > node1.puppetlabs.vm, and node2.puppetlabs.vm. Once DNS resolves and is > working, setup Puppet on the master FIRST, and then setup the remaining > nodes as agents. Again, I recommend using the VMs and using Puppet > Enterprise because it makes it MUCH EASIER to setup Puppet - just use the > puppet-enterprise-installer script (once you get the process of using a > single cert and multiple node_names DOWN, THEN you can start on some actual > machines). > > Now we can start customizing Puppet. There are a couple of key steps that > need to be taken since we''re shipping around a single cert for all machines: > > 1. When you stand up a PE Agent, it''s going to contact the master and setup > a Certificate Signing Request. Because of this, go to the master node''s > $ssldir (which, on Puppet Enterprise, is /etc/puppetlabs/puppet/ssl. If > you want to find the $ssldir on YOUR master, just run `puppet config print > ssldir` and it will print it out for you) and remove the CSRs that are in > the ca/requests/ directory (they should be named after your nodes). > > 2. Next, lets generate the single certificate that will be shopped around. > You will need to use the same ''certname'' on every node. This is the name > of the node as SSL is aware (in my case I''m using ''macs.puppetlabs.vm''). > Do this by doing `puppet cert generate macs.puppetlabs.vm` on your MASTER > machine. The master will generate the certs and your $ssldir will look > something like this: > > ssl > > |-- ca > > | |-- ca_crl.pem > > | |-- ca_crt.pem > > | |-- ca_key.pem > > | |-- ca_pub.pem > > | |-- inventory.txt > > | |-- private > > | | `-- ca.pass > > | |-- requests > > | |-- serial > > | `-- signed > > | |-- macs.puppetlabs.vm.pem > > | |-- nodemaster.puppetlabs.vm.pem > > | |-- pe-internal-broker.pem > > | |-- pe-internal-dashboard.pem > > | |-- pe-internal-mcollective-servers.pem > > | |-- pe-internal-peadmin-mcollective-client.pem > > | `-- pe-internal-puppet-console-mcollective-client.pem > > |-- certificate_requests > > |-- certs > > | |-- ca.pem > > | |-- macs.puppetlabs.vm.pem > > | |-- nodemaster.puppetlabs.vm.pem > > | |-- pe-internal-broker.pem > > | |-- pe-internal-mcollective-servers.pem > > | |-- pe-internal-peadmin-mcollective-client.pem > > | `-- pe-internal-puppet-console-mcollective-client.pem > > |-- crl.pem > > |-- private > > |-- private_keys > > | |-- macs.puppetlabs.vm.pem > > | |-- nodemaster.puppetlabs.vm.pem > > | |-- pe-internal-broker.pem > > | |-- pe-internal-mcollective-servers.pem > > | |-- pe-internal-peadmin-mcollective-client.pem > > | `-- pe-internal-puppet-console-mcollective-client.pem > > `-- public_keys > > |-- foo.puppetlabs.vm.pem > > |-- macs.puppetlabs.vm.pem > > |-- nodemaster.puppetlabs.vm.pem > > |-- pe-internal-broker.pem > > |-- pe-internal-mcollective-servers.pem > > |-- pe-internal-peadmin-mcollective-client.pem > > `-- pe-internal-puppet-console-mcollective-client.pem > > 3. There are three files you need to collect on your master and ship > around to all of your nodes. They are ALL in the $ssldir, so these paths > are relative to THAT directory. The three files are: > > - $ssldir/private_keys/macs.puppetlabs.vm.pem on the master -> gets > copied to the agent''s $ssldir/private_keys directory > - $ssldir/public_keys/macs.puppetlabs.vm.pem on the master -> gets > copied to the agent''s $ssldir/public_keys directory > - $ssldir/ca/signed/macs.puppetlabs.vm.pem on the master -> gets > copied to the agent''s $ssldir/certs directory > > 4. You need to modify /etc/puppetlabs/puppet/auth.conf on the master so > every node can access the find action on the catalog REST endpoint for the > master (i.e. The Mac nodes can get their catalog). Look for this stanza in > auth.conf: > > # allow nodes to retrieve their own catalog (ie their configuration) > path ~ ^/catalog/([^/]+)$ > method find > allow $1 > > Add the following line under ''allow $1'': (Remember that I''m using the > certname 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.com>wrote: > > > > > > > > > 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.com > > >wrote: > > ... > > read more »-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Sorry to resurrect an old(er) thread, but: http://projects.puppetlabs.com/issues/3360#note-33 leads me to believe none of those workarounds are necessary, just allow_duplicate_cert However, https://gist.github.com/0c76fb5b28abfcb2f9d6 That''s a proof of concept that I started testing on the DeployStudio side, and will probably fire up some python (once conference extravaganza passes) to iterate over a csv of serial numbers and therefore generate a bunch of certs at once. Allister On Apr 11, 12: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.com>wrote: > > > > > > > > > > > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Apr 27, 2012 at 2:22 PM, Allister Banks <al@aru-b.com> wrote:> Sorry to resurrect an old(er) thread, but: > http://projects.puppetlabs.com/issues/3360#note-33 > leads me to believe none of those workarounds are necessary, just > allow_duplicate_cert >Have you tried this out? I''ve personally never used the allow_duplicate_cert feature, but if it''s not working properly then reporting that in the bug is totally the best way to go?> > However, > https://gist.github.com/0c76fb5b28abfcb2f9d6 > That''s a proof of concept that I started testing on the DeployStudio > side, and will probably fire up some python (once conference > extravaganza passes) to iterate over a csv of serial numbers and > therefore generate a bunch of certs at once. > >Commented on the gist - that should work as long as you generate the certs ON the puppet master and use the certname of the node you''re wanting to provision.> Allister > > > On Apr 11, 12: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.com > >wrote: > > > > > > > > > > > > > > > > > > > > > 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Gah, should not end with a question mark --> "I''ve personally never used the allow_duplicate_cert feature, but if it''s not working properly then reporting that in the bug report is totally the best way to go?" On Fri, Apr 27, 2012 at 6:35 PM, Gary Larizza <gary@puppetlabs.com> wrote:> > > On Fri, Apr 27, 2012 at 2:22 PM, Allister Banks <al@aru-b.com> wrote: > >> Sorry to resurrect an old(er) thread, but: >> http://projects.puppetlabs.com/issues/3360#note-33 >> leads me to believe none of those workarounds are necessary, just >> allow_duplicate_cert >> > > Have you tried this out? I''ve personally never used the > allow_duplicate_cert feature, but if it''s not working properly then > reporting that in the bug is totally the best way to go? > > >> >> However, >> https://gist.github.com/0c76fb5b28abfcb2f9d6 >> That''s a proof of concept that I started testing on the DeployStudio >> side, and will probably fire up some python (once conference >> extravaganza passes) to iterate over a csv of serial numbers and >> therefore generate a bunch of certs at once. >> >> > Commented on the gist - that should work as long as you generate the certs > ON the puppet master and use the certname of the node you''re wanting to > provision. > > > >> Allister >> >> >> On Apr 11, 12: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.com >> >wrote: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > 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+unsubscribe@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+unsubscribe@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 > >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.