Harry G Coin via FreeIPA-users wrote: > 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/html/migrating_to_identity_management_on_rhel_9/assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers_migrating-to-idm-on-rhel-9#starting-crl-generation-on-the-new-rhel-9-idm-ca-server_assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers > > 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. >
At a glance these steps look ok. I didn't try them myself. Eventually modifying CS.cfg won't be necessary before running ipa-crlgen-manage. I recently fixed that (not in any build yet). Since you'll be in there I'd also recommend setting CS.cfg ca.listenToCloneModifications=true on the new CRL generator and false on the other(s). See https://pagure.io/freeipa/issue/9569 Messing with dnarange shouldn't strictly be necessary. I guess I'd recommend noting the values but on uninstall any range(s) should be preserved on another. Also run ipa-replica-manage dnanextrange-show to see any preserved ranges. Every IPA server does not require a range and it's perfectly acceptable for there not be one. One is only required if you add users or groups on that specific server. You just need a range on at least one server. Some users designate one server that handles all user management. YMMV. I assume you'll need to do this for every DNS-enabled server (minus the CRL designations). To find them all: # ipa server-role-find --role 'DNS server' All those are are not marked absent. rob -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
