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.