[Puppet Users] Re: Puppermaster certificate expired
nobody really ever had to deal with this ? Dne pondělí, 6. května 2013 10:03:15 UTC+2 Tomáš Brandýský napsal(a): Hello, We've been running puppet for 5 years until the last week when the certificate on the puppet server is expired. We were looking for a procedure describing how to create a new server certificate without a need to reconfigure certificates on puppet clients (about 100 servers) but we couldn't find anything regarding this issue within puppet's documentation. Is there any best practice guidance to easily fix the problem when puppet master certificate is expired ? Thank you Tomas -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppermaster certificate expired
On Monday, May 6, 2013 10:03:15 AM UTC+2, Tomáš Brandýský wrote: Hello, We've been running puppet for 5 years until the last week when the certificate on the puppet server is expired. We were looking for a procedure describing how to create a new server certificate without a need to reconfigure certificates on puppet clients (about 100 servers) but we couldn't find anything regarding this issue within puppet's documentation. Is there any best practice guidance to easily fix the problem when puppet master certificate is expired ? I just discovered that our CA expires next year because of this post, thanks for that :) Anyway I think the easy way is to setup some autosigning of clients after creating a new CA. Think you will have to clean the ssl-dir on clients for this to work, though. Since we are going to make a brand new puppetmaster here sometime before our CA expires that will be my approach to make the transition smoother. /Nicolai -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
2013/5/9 Nicolai Mollerup nicolai.molle...@gmail.com Anyway I think the easy way is to setup some autosigning of clients after creating a new CA. Think you will have to clean the ssl-dir on clients for this to work, though. Since we are going to make a brand new puppetmaster here sometime before our CA expires that will be my approach to make the transition smoother. we are exactly at the same point: currently moving our puppetmaster on another host, struggling against CA hostname in SSL Certificates and thinking how to approach the refresh of all certificates on agents. Autosigning for some day could be a good approach for us too, since we have our racks with predefined networks IPs and master on amazon, so amazon agents can contact master via internal network. We already manage agents configuration with a puppet module, do you think we can do the SSL substitution with a recipe in puppet itself? -- *sede di PRATO* Via Mino da Fiesole, 5 - 59100*PHONE* +39 0574.5877 *FAX* +39 0574.5877.99 Azienda certificata-Sistema Qualità ISO 9001:2008 e quotata su AIM Italia di Borsa Italiana Le informazioni contenute in questa comunicazione e gli eventuali documenti allegati hanno carattere confidenziale e sono ad uso esclusivo del destinatario. Nel caso questa comunicazione Vi sia pervenuta per errore, Vi informiamo che la sua diffusione e riproduzione è contraria alla legge e preghiamo di darci prontamente avviso e di cancellare quanto ricevuto. This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use or distribution of this e-mail is strictly prohibited, please notify the sender and delete the original message. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
On Thu, 9 May 2013 17:10:51 +0200
Lorenzo Salvadorini lorenzo.salvador...@softecspa.it wrote:
2013/5/9 Nicolai Mollerup nicolai.molle...@gmail.com
Anyway I think the easy way is to setup some autosigning of clients
after creating a new CA.
Think you will have to clean the ssl-dir on clients for this to
work, though.
Since we are going to make a brand new puppetmaster here sometime
before our CA expires that will be my approach to make the
transition smoother.
we are exactly at the same point: currently moving our puppetmaster on
another host, struggling against CA hostname in SSL Certificates and
thinking how to approach the refresh of all certificates on agents.
Autosigning for some day could be a good approach for us too, since
we have our racks with predefined networks IPs and master on amazon,
so amazon agents can contact master via internal network.
We already manage agents configuration with a puppet module, do you
think we can do the SSL substitution with a recipe in puppet itself?
I'd not try to remove ssl certificates during a puppetrun because I
expect that every file resource with a `source` parameter will fail
after that point and the agent would not be able to send the last report
to the old master.
We had a slightly different approach when migrating our agents to a new
master. We run puppet out of cron and the cronentry is also managed by
puppet. Now we have the following simplified puppet::agent class:
# need_migration is mostly calculated by checking the agent's
# version and the current puppetmaster
if $need_migration {
$cron_command = '/var/lib/puppet/migrate.sh'
}
else {
$cron_command = '/usr/bin/puppet agent'
}
cron { 'puppet_clientrun':
command = $cron_command
}
If an agent contacts the old puppetmaster and need_migration evaluates
to false, the agent will replace its cronjob with the migration script,
so in the next interval we run the migration script instead of the
puppet agent.
The migration script updates the puppet software, updates the server
setting in puppet.conf and erases the ssl directory (this is only done
once in case the migrate.sh is executed more than once). The migrate.sh
script will also trigger a normal puppetrun as the last step, so
the puppet agent will create new certificates. The `migrate.sh` keeps
running every hour until someones signes the new certificate request
on the new master. Once the request is signed and the agent is able to
contact the new mater, the $need_migration will evaluate to false and
the migrate.sh in cron is replaced with the normal puppet agent
invocation.
This way we keet the removal of the ssl directory completly outside of
puppet. We can also be sure that hosts that had puppet temporarily
disabled will be instructed to migrate after they contact the (old)
master again.
-Stefan
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppermaster certificate expired
On Thu, May 9, 2013 at 3:57 PM, Stefan Schulte
stefan.schu...@taunusstein.net wrote:
On Thu, 9 May 2013 17:10:51 +0200
Lorenzo Salvadorini lorenzo.salvador...@softecspa.it wrote:
2013/5/9 Nicolai Mollerup nicolai.molle...@gmail.com
Anyway I think the easy way is to setup some autosigning of clients
after creating a new CA.
Think you will have to clean the ssl-dir on clients for this to
work, though.
Since we are going to make a brand new puppetmaster here sometime
before our CA expires that will be my approach to make the
transition smoother.
we are exactly at the same point: currently moving our puppetmaster on
another host, struggling against CA hostname in SSL Certificates and
thinking how to approach the refresh of all certificates on agents.
There's some older thread when Puppet first hit this 5 year anniversary. I
recall trying a few things, and one that only required updating the CA cert
in the environment, but there's no avoiding touching every client once the
CA cert expired.
Autosigning for some day could be a good approach for us too, since
we have our racks with predefined networks IPs and master on amazon,
so amazon agents can contact master via internal network.
We already manage agents configuration with a puppet module, do you
think we can do the SSL substitution with a recipe in puppet itself?
I'd not try to remove ssl certificates during a puppetrun because I
expect that every file resource with a `source` parameter will fail
after that point and the agent would not be able to send the last report
to the old master.
We had a slightly different approach when migrating our agents to a new
master. We run puppet out of cron and the cronentry is also managed by
puppet. Now we have the following simplified puppet::agent class:
# need_migration is mostly calculated by checking the agent's
# version and the current puppetmaster
if $need_migration {
$cron_command = '/var/lib/puppet/migrate.sh'
}
else {
$cron_command = '/usr/bin/puppet agent'
}
cron { 'puppet_clientrun':
command = $cron_command
}
If an agent contacts the old puppetmaster and need_migration evaluates
to false, the agent will replace its cronjob with the migration script,
so in the next interval we run the migration script instead of the
puppet agent.
The migration script updates the puppet software, updates the server
setting in puppet.conf and erases the ssl directory (this is only done
once in case the migrate.sh is executed more than once). The migrate.sh
script will also trigger a normal puppetrun as the last step, so
the puppet agent will create new certificates. The `migrate.sh` keeps
running every hour until someones signes the new certificate request
on the new master. Once the request is signed and the agent is able to
contact the new mater, the $need_migration will evaluate to false and
the migrate.sh in cron is replaced with the normal puppet agent
invocation.
This way we keet the removal of the ssl directory completly outside of
puppet. We can also be sure that hosts that had puppet temporarily
disabled will be instructed to migrate after they contact the (old)
master again.
Off the top of my head, the ssldir option + server option should allow
migration to new server while keeping two different set of ssl keys as you
move the system to another master with a different CA. A mcollective puppet
plugin that supports both option might be useful for this kind of migration.
Nan
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
