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
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
- 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?
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.
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?
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.
Freeipa-users mailing list