FAQ
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 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 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.

Search Discussions

  • Gary Larizza at Apr 28, 2012 at 1:35 am

    On Fri, Apr 27, 2012 at 2:22 PM, Allister Banks 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 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 Larizza at Apr 28, 2012 at 1:36 am
    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 wrote:


    On Fri, Apr 27, 2012 at 2:22 PM, Allister Banks 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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 27, '12 at 9:22p
activeApr 28, '12 at 1:36a
posts3
users2
websitepuppetlabs.com

2 users in discussion

Gary Larizza: 2 posts Allister Banks: 1 post

People

Translate

site design / logo © 2022 Grokbase