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.
