[Freeipa-users] Upgrade/Migration steps

[Joshua J. Kugler]

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?
 - 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.

> 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?


> 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?

> 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

-- 
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
joshua at azariah.com - Jabber: pedahzur at gmail.com
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A