[Freeipa-users] Upgrade form Centos to Fedora (3.0.0 -> 3.3.3)

[Martin Kosek]

The installation part is indeed that simple, but you will also want to 
additionally turn the new CA to be the "master CA" so that it properly 
generates the CRL and renews the CA subsystem certificates when the old "master 
CA" is decommissioned. See [1] and [2] for more information.

Martin

[1] 
http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS
[2] 
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Reconfigure_a_CA_as_the_new_master

On 02/05/2014 08:38 PM, Bret Wortman wrote:
> Rob,
>
> To add the second master-with-CA, is it as simple as doing this on one of the
> replicas?
>
> # ipa-ca-install /path/to/replica-info-hostname.foo.net.gpg
>
>
>
> Bret
>
> On 02/05/2014 04:35 AM, Rob Crittenden wrote:
>> Will Sheldon wrote:
>>>
>>> Hello IPA users :)
>>>
>>> We have implemented IPA using the packaged version in centos 6.5 (which
>>> is 3.0.0-37.el6), but have been playing with the more recent version in
>>> Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the
>>> shiny new features, so are thinking about migrating.
>>>
>>> Has anyone done this? Is there an easy way to migrate/upgrade?
>>> What would happen if I tried to setup a FC19 replica, would it get angry
>>> and break?
>>>
>>> We only have users in production so far, (no production clients or
>>> issued certs) so maybe the user migration script mentioned in previous
>>> posts would be the best bet?
>>>
>>> Any pointers would be hugely appreciated..
>>
>> This is exactly the way to migrate between versions. You'll want to set up a
>> CA on the F19 server for sure, and DNS if you're using that. The idea is that
>> you set up the new master, spend some time (days, weeks not months) verifying
>> that things are working ok, then remove the old server and things should
>> continue to just work. We also recommend having at least two masters with CAs
>> for redundancy and avoiding a single point of failure.
>>
>> We have discovered a bug in the way clients are enrolled though. We store the
>> name of the master you enroll against. Normally this isn't a big deal,
>> especially if you use SRV records. The problem is if that some tools use the
>> master from this file to connect to and not SRV records, so you may want to
>> run around to your clients and change this in /etc/ipa/default.conf once the
>> migration is complete.
>>
>> rob
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>