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.
