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 [email protected] - Jabber: [email protected] PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
