Hi Rob, On a different topic, we started migration from Centos 7 to Red Hat 8.6 over the weekend, after adding the first Red Hat master and moved CA renewal and CRL generation roles to it, then we tried to add the second Red Hat master via the first Red Hat master, after many tries without success. The keytabs on the first master seem messed up. We wonder if it is possible or safe to back out.
The current domain is all Centos 7 masters and one Red Hat 8 master with CA renewal and CRL generation role. By backing out, I mean to move the CA renewal and CRL generation role back to a Centos 7 master, then remove the Red Hat 8 master. So we will be back to the way before the migration. Then we have a freshly installed red hat server and try the migration process again. Is this safe to do? Thanks. Kathy. On Tue, Jul 12, 2022 at 2:18 PM Kathy Zhu wrote: > Hi Rob, > > Thank you! > > We are migrating to Red Hat 8.6, that master will be replaced. So far, we > do not see any issue yet. > > The outputs from "dsconf slapd-EXAMPLE-COM repl-conflict list o=ipaca" > are binaries. Have no clue what that means :-). > > Many thanks for your help! It made our domain cleaner. Appreciate it. > > Kathy. > > On Tue, Jul 12, 2022 at 2:03 PM Rob Crittenden <[email protected]> > wrote: > >> Kathy Zhu via FreeIPA-users wrote: > > > Hi Rob, >> > >> > Thank you! >> > >> > It worked! There were 4 bad entries! However, I made a mistake by >> > deleting a valid one :-(. Could you please share how to add it back? Or >> > should I reinstall it? >> >> I don't know how to re-add one or what repercussions there are (the CA >> is still treated very much like a black box). Re-installing is the >> safest bet. >> >> > >> > ipa-healthcheck is no longer complain about the same. However, I still >> > see the warning: >> > >> > # ipa-healthcheck --failures-only --output-type=human >> > >> > Unhandler rdtype 256 >> > >> > Unhandler rdtype 256 >> > >> > Unhandler rdtype 256 >> > ... >> > >> > Unhandler rdtype 256 >> > >> > WARNING: ipahealthcheck.ds.replication.ReplicationCheck.DSREPLLE0002: >> > There were 118 conflict entries found under the replication suffix >> > "dc=corp,dc=nuro,dc=team". >> > >> > WARNING: ipahealthcheck.ds.replication.ReplicationCheck.DSREPLLE0002: >> > There were 15 conflict entries found under the replication suffix >> "o=ipaca". >> > # >> > >> > Note the last line : >> > >> > There were 15 conflict entries found under the replication suffix >> "o=ipaca". >> > >> > We have 11 valid ones plus 4 old removed ones, that is total 15. >> > Somewhere in IPA still shows 15. >> >> They must be there somewhere. It is a 389-ds check that returns these >> results. I'd try: dsconf slapd-YOUR_INSTANCE repl-conflict list o=ipaca >> >> rob >> >> > >> > Many thanks. >> > >> > Kathy. >> > >> > On Mon, Jul 11, 2022 at 7:24 PM Rob Crittenden <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Kathy Zhu via FreeIPA-users wrote: >> > > Hi Team, >> > > >> > > >> > > We are migrating from Centos 7 IPA to Red Hat 8.6. After adding >> the >> > > first Red Hat master, it reported error: >> > > >> > > >> > > # ipa-healthcheck >> > > --source=pki.server.healthcheck.clones.connectivity_and_data >> > > >> > > Internal server error HTTPSConnectionPool(host='ipa4.example.com >> > <http://ipa4.example.com> >> > > <http://ipa4.example.com>', port=443): Max retries exceeded with >> url: >> > > /ca/rest/certs/search?size=3 (Caused by >> > > NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection >> object >> > > at 0x7f0611b6d5c0>: Failed to establish a new connection: [Errno >> -2] >> > > Name or service not known',)) >> > > >> > > [ >> > > >> > > { >> > > >> > > "source": >> "pki.server.healthcheck.clones.connectivity_and_data", >> > > >> > > "check": "ClonesConnectivyAndDataCheck", >> > > >> > > "result": "ERROR", >> > > >> > > "uuid": "bfb9aeac-2e86-4d1d-ac2a-3cb62300527e", >> > > >> > > "when": "20220711221016Z", >> > > >> > > "duration": "0.768881", >> > > >> > > "kw": { >> > > >> > > "status": "ERROR: pki-tomcat : Internal error testing CA >> clone. >> > > Host: ipa4.example.com <http://ipa4.example.com> >> > <http://ipa4.example.com> Port: 443" >> > > >> > > } >> > > >> > > } >> > > >> > > ] >> > > >> > > # >> > > >> > > >> > > ipa4 was a master we had years ago. it did not show up as a >> dangling >> > > master in the domain. However, it remains in pki DB. How to safely >> > clean >> > > it out from pki DB? >> > >> > IPA wasn't cleaning up the security domain on server removal until >> > relatively recently. >> > >> > You can find the list of servers with: >> > >> > # pki securitydomain-host-find >> > >> > You can remove one with with: >> > >> > # pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' >> -C >> > /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA >> > ipa.example.test 443' >> > >> > Be very careful as you can remove valid ones just as easily. >> > >> > > Another interesting fact I like to point out - Centos 7 >> > ipa-healthcheck >> > > does not report this. >> > >> > The epel-7 build of ipa-healthcheck I did was a one-off. The >> differences >> > were just too great to keep it in sync. It's an incentive to >> upgrade to >> > RHEL 8 (or 9). >> > >> > 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 on the list, report it: https://pagure.io/fedora-infrastructure
