Hi Doug,
In case everyone else's posts haven't solved your problem, there's a
fiddly but seamless way to migrate between Puppet Masters by keeping
the same CA. It's easier if you already have a DNS alias for your
master, like "puppet" and that's also an additional Cert DNS Name in
the master's certificate (which is added by default when a master
creates it's CA cert for the first tile I think). You can check on the
master with this:
openssl x509 -text -in /var/lib/puppet/ssl/certs/$(hostname).pem |
grep -A1 'Subject Alternative Name'
X509v3 Subject Alternative Name:
DNS:puppet, DNS:oldpuppetmaster.foo.com
Before each of these steps I'd backup /var/lib/puppet/ssl/, just so
you can get back to where you were.
Now on your old Puppet Master, generate a new certificate for your new
Puppet Master, specifying "puppet" as an additional DNS name. You
might even want to add in the DNS name of the old server:
puppetca --generate --certdnsnames oldpuppetmaster.foo.com:puppet
newpuppetmaster.foo.com
You might need to clean up any existing certs for your new server
before you do this, puppetca might complain if it already exists.
Next, copy this new cert and key to the new Puppet Master server, as
well as *all* the Puppet certs your old master has signed as well:
oldpuppetmaster$ cd /var/lib/puppet/ssl
oldpuppetmaster$ scp private_keys/newpuppetmaster.foo.com.pem
r...@newpuppetmaster.foo.com:/var/lib/puppet/ssl/private_keys/
newpuppetmaster.foo.com.pem
oldpuppetmaster$ scp ca/signed/newpuppetmaster.foo.com.pem
r...@newpuppetmaster.foo.com:/var/lib/puppet/ssl/certs/
newpuppetmaster.foo.com.pem
oldpuppetmaster$ scp ca/ca_crt.pem r...@newpuppetmaster.foo.com:/var/
lib/puppet/ssl/certs/ca.pem
oldpuppetmaster$ scp -r ca/ r...@newpuppetmaster.foo.com:/var/lib/
puppet/ssl/
Now, take one of your existing clients, poison it's DNS with /etc/
hosts to point "puppet" to your new server, and see if it can connect.
Theoretically it should be fine... I don't think I've forgotten
anything ;)
With this method you can seamlessly phase out your old Puppet Master
and all your existing certs are still valid as you haven't changed CA,
you've just moved it.
It's a probably a bad idea to run both servers simultaneously
considering the SSL serial number - you don't want to sign different
certs on different servers and reuse the same serial number. I believe
this only affects certificate revocation lists, but it's best to be
nice. Therefore do your cut over as an "all in one go" operation.
Hope that helps (and please take backups of the ssl dir!),
-Luke
On Jul 27, 10:13 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:
> On Wed, Jul 27, 2011 at 2:10 PM, Douglas Garstang
> <doug.garst...@gmail.com>wrote:
>
>
>
> > On Wed, Jul 27, 2011 at 2:01 PM, Jacob Helwig <ja...@puppetlabs.com>wrote:
>
> >> On Wed, 27 Jul 2011 13:58:25 -0700, Douglas Garstang wrote:
>
> >> > All,
>
> >> > I'm upgrading puppet clients from 0.25.5 to 2.7.1. I've rolled an RPM
> >> for
> >> > the new version, and I'm:
>
> >> > 1. Stopping puppet
> >> > 2. Upgrading RPM
> >> > 3. Change the puppet master on the client to point to a new puppet
> >> master
> >> > running 2.7.1.
> >> > 3. Starting puppet
>
> >> > I am seeing this in the log files on the client:
>
> >> > Could not evaluate: certificate verify failed Could not retrieve file
> >> > metadata for puppet://hprov01.h.xxx.com/plugins: certificate verify
> >> failed
> >> > Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not retrieve
> >> > catalog from remote server: certificate verify failed
> >> > Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Using cached
> >> catalog
> >> > Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not send
> >> report:
> >> > certificate verify failed
> >> > Jul 27 13:53:54 hsqlstor04p1-old puppet-agent[9468]: Could not run
> >> Puppet
> >> > configuration client: interning empty string
>
> >> > After stopping puppet again, removing /var/lib/puppet/ssl and restarting
> >> > puppet, all is ok. Why do I need to blow away the client side certs? I
> >> > recently upgraded 0.25.5 to 2.6.8, and I don't believe I had to do this.
> >> I
> >> > have a couple of hundred servers to upgrade, and I don't want to have to
> >> > remove all the client side ssl directories as part of the upgrade
> >> process.
>
> >> > Doug.
>
> >> It sounds like you have a new server with 2.7.1, in addition to your old
> >> server. Did you copy over the master certificates to the new 2.7.1
> >> master from the old one?
>
> >> If the new 2.7.1 master had generated a new certificate, I would expect
> >> to get the errors you're seeing.
>
> >> --
>
> > Oh, and which files under /var/lib/puppet/ssl on the server would be the
> > relevant master certs?
>
> > Doug.
>
> Hmmm..... that's not going to work, since the host names of the servers are
> different, and therefore, so are the cert names. Now I'm really confused.
> Since the client can't have knowledge of two servers, this means that if
> things go south, and I have to switch the client back to the original
> master, that I will have to remove the certs again. There's got to be an
> easier way.
>
> Doug.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
