2:50 p.m.
If you've decided freeipa's DNS and/or DNSsec isn't part of your future,
here's a way to migrate to another solution without disrupting the rest
of freeipa's capabilities. I couldn't find any documentation about how
to do this in an automated way, this worked for me. (Watch someone
answer this post with 'oh, you just run X and it's all automated!)
This same instruction set can help whenever it's necessary to reinstall
a freeipa-master on a fresh/new system.
Corrections welcome! This is based on experience and with hints posted
at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
It requires a currently running master and at the ability to install (or
re-install) one replica.
1. Review the logs on the master to make sure operations are normal
(you can ignore dns/dnssec related errors). Before making changes: in
case it all goes horribly wrong make a complete snapshot of the master
and save it (usually best done as a low-level disk operation when the
master host is powered off).
2. On the master: Make sure whatever is replacing freeipa's DNS/DNSsec
is operational and has satisfactory content. (We chose Technitium,
after adding failover capability to it). To gain confidence that is
complete, point /etc/resolv.conf on the master at the new DNS server,
then run ipa-healthcheck until there are no complaints. Zone transfer
can be your friend.
3. Create a new system/vm and on it install a replica
(ipa-replica-install) but do not include --setup-dns or related options
like --no-forwarders. Comprehend the details of 'ipa-replica-manage
dnarange-set' which may be necessary on your master and different on
your replica. This replica can be temporary, in that case do not
specify a large dnarange.
4. On the replica, point /etc/resolv.conf to the new dns server, then
run ipa-healthcheck to make sure there are no complaints.
5. On the replica, kinit admin then: ipa config-mod
--ca-renewal-master-server <replica fqdn> . From
/etc/pki/pki-tomcat/ca/CS.cfg remove 'ca.certStatusUpdateInterval=0'
Then ipactl restart on the replica.
6. Add 'ca.certStatusUpdateInterval=0' to
/etc/pki/pki-tomcat/ca/CS.cfg on the soon-to-be-retired master. ipactl
restart on the master.
7. On the master, ipa-crlgen-manage disable and on the replica
ipa-crlgen-manage enable.
8. check that ipa-crlgen-manage status on the master shows disabled,
and on the replica shows enabled.
9. Power down the master. Check that the replica is operating
normally and new DNS operations are normal.
10. On the replica, do 'ipa-replica-manage del <master fqdn> --force
(you will be warned about dns, but you've got that covered, right?)
11. Install a new OS or reformat what was the master. Make sure DNS
is correct on the new setup. Install ipa-server as if on a replica,
pointing at the temporary replica you've created above as the source.
Remember NOT to include --setup-dns or dns related installation options.
12. Reverse steps 7, 6 and 5.
13. On the master, you may need to run step 3 with the prior dna-range.
14. When 'ipa-healthcheck' on the now-new master reports no errors, if
you wish you can delete the replica from the ipa topology and retire
that system.
That's it! The good news is adding freeipa's DNS back into the mix if
that becomes best in your setup is well documented. Some of the
alternative DNS servers can act as secondary servers then 'promote'
themselves to 'primary' using the transferred database, which makes
migration easier. If you use DNSSec, be sure to add DS records for the
new nameserver in your registrar's dns before retiring
bind9-named-pkcs11/softhsm/opendnssec/bind-dynldap and related freeipa
DNS suite subsystems.
We found a way to keep the tight relationship between freeipa and DNS
(host DNS records and the like). To make that a 'native' freeipa
option, you might imagine a freeipa plugin that issued host zone record
related commands to third-party DNS solutions.
Harry