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
> 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"
- 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
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.
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
Freeipa-users mailing list