[Freeipa-users] Upgrade/Migration steps

[Rob Crittenden]

Joshua J. Kugler wrote:
> Thank you so much!  A few questions below.
>
> On Wednesday, June 19, 2013 08:46:06 Martin Kosek wrote:
>> This is the migration plan that should work:
>>
>> 0) We have IPA server(s) of aging version (2.0 in your case)
>>
>> 1) On one of your servers, create a replica (ipa-replica-prepare) and copy
>> the replica file to the new server/VM which will host the updated IPA
>> version
>>
>> 2) You install the up-to-date FreeIPA server (ipa-replica-install). It
>> should have all the services as the original server had, i.e.
>> - if original server had CA installed (it probably did), you will also add
>> "--setup-ca" option
>> - if original server had DNS installed , you will also add "--setup-dns"
>> option
>
>   - Am I correct in understanding that the replica file won't inform the replica
> which services to create?

By default it configures Apache, 389-ds and Kerberos and some things 
used by IPA. DNS, NTP and a CA are optional.

>   - We do have DNS running on our IPA nodes, but it is not controlled by IPA. I
> assume I don't setup DNS in that case.

Right.

>
>> The new server should now have all the capability of the aging servers + it
>> will have features introduced in the new version.
>>
>> 4) (Optional but recommended) If the installation went well and you are
>> satisfied with the new server and plan to migrate, you may also spin off
>> some replicas from it just to keep the redundancy in case this server break
>> in any way.
>>
>> 5) If the new server was properly installed, you stop all the old IPA
>> servers: # ipactl stop
>> - this step is important, this will prevent loosing data in case the new
>> server misses something and let you test the new server
>>
>> 6) On your client(s), you verify that they continue to function as before.
>> If you use DNS with IPA, this should be easy as they should fallback to the
>> new IPA servers automatically simply by reading new server address from DNS
>> SRV records. If you do not use automatic DNS discovery and you use a fixed
>> list of servers, you would have to update these lists in
>> /etc/sssd/sssd.conf and /etc/krb5.conf and other configuration files you
>> used.
>
> IPA doesn't control DNS, but I think we may use DNS auto discovery. We have
> this in our DNS records:
>
> ; DNS-discovery service entries
> _kerberos               IN      TXT     LAB.WHAMCLOUD.COM
> ; name                                  prio    weight  port    target
> _kerberos._udp          IN      SRV     10      0       88      ipa0
> _kerberos-master._udp   IN      SRV     0       0       88      ipa0
> _kerberos-adm._tcp      IN      SRV     0       0       749     ipa0
> _kpasswd._udp           IN      SRV     0       0       464     ipa0
> _ldap._tcp              IN      SRV     10      0       389     ipa0
>
> If I add another set of records, but using ipa_new (for example), will the
> sssd clients be able to see both servers?

Yes. It is just an extra task to remember to update the SRV records 
whenever you add or remove IPA servers.

>
>> 7) When you verify that clients keep functioning properly, you remove the
>> old IPA servers, i.e:
>> - log in to the new ipa server and delete the old servers
>> $ ipa-replica-manage list
>> $ ipa-replica-manage del old.ipa.server.fqdn
>>
>> 8) You can now uninstall old IPA servers (ipa-server-install --uninstall) or
>> discard their VMs/machines
>>
>> 9) You successfully migrated!
>
> What are some good tests to run against the replica? The basic ones like ipa
> user-find, listing groups, listing automounts, etc?  How do I make sure my test
> queries are going against the new IPA server instead of the old one?  For the
> ipa commands is there a way (similar to dig's @) to direct a query against a
> specific IPA server?

ipa -e xmlrpc_uri=https://otherserver.example.com/ipa/xml user-show admin

A server configures the client on itself to talk to itself, so if you do 
the tests on the replica itself you can be assured it is local data.

I'd exercise both the IPA framework (user-show, etc) and nss in general, 
getent passwd admin, id somebody, test logins, etc.

Testing sudo, automount, Kerberos, etc is probably wise too. Password 
changes as well.

>> Please note that this procedure works only if your FreeIPA basic settings
>> (like REALM) stays intact.
>
> Nope, everything is staying the same.
>
>> Any comments? Does this procedure make sense to you?
>
> It does make sense. Thank you so much for walking me through this. I'll let
> you know if I hit any glitches.
>
> j
>