Hi Rob and Florence, I found out why.
It was the combination of two - 1, the new replica was built with a DNS server (forwarder) which does not forward the reverse zones , which could resolve reverse DNS of master's IP, which is used for installation. 2, I manually corrected it in /etc/resolv.conf file before ipa-replica-install, however, in the middle of the installation, /etc/resolv.conf got override by the setting in /etc/sysconfig/network-scripts/ifcfg-ens192 (the interface configuration file created when built). I meant that the file was changed when the installation failed. To fix, I made correction in ifcfg-ens192 file. I also updated sssd.conf to use red hat master only, that helps too. I was able to install a few RHEL new replicas from RHEL masters. Thank you for all your help! Really appreciate it. Kathy. On Wed, Jul 13, 2022 at 12:23 PM Kathy Zhu wrote: > Thanks, Rob. > > ipa-replica-install does not take --server switch. I used --server in > ipa-client-install, which puts the server in /etc/ipa/default.conf, when > promoting this client to replica with ipa-replica-install, it picks up the > server there. At least, this is my understanding. Below are the command > lines I used: > > # password is the one time code generated with --random switch when adding > the host > ipa-client-install --mkhomedir --hostname=`hostname` > --domain=corp.nuro.team --server=$server --password=$password --unattended > > ipa-replica-install --setup-dns --forwarder=$forwarder-IP1 --forwarder= > $forwarder-IP2 --setup-ca --principal admin > > I tried with "-w" to give the admin password in the command line, but that > did not help. > > Thanks. > > Kathy. > > On Wed, Jul 13, 2022 at 12:02 PM Rob Crittenden <[email protected]> > wrote: > >> Florence Blanc-Renaud wrote: >> > >> > >> > On Wed, Jul 13, 2022 at 12:46 AM Kathy Zhu via FreeIPA-users >> > <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > 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? >> > >> > Hi, >> > I don't see any issue with moving back CA renewal and CRL generation >> > roles back to the Centos 7 server. But maybe you can share the failed >> > installation logs for us to help you troubleshoot the replica >> > installation issue? >> >> The connection log inside the ipareplica-install log you shared doesn't >> include the cn error you shared later. >> >> It's a strange failure. The no session_cookie failure is expected since >> this principal hasn't authenticated yet, but the No valid Negotiate >> header isn't. I don't know why the RPC client wouldn't send that. >> >> Were you using the --server option to ipa-replica-install to control >> which server to connect with? >> >> rob >> >> > >> > flo >> > >> > 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] <mailto:[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]> >> > > <mailto:[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> >> > > > <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> >> > > <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] >> > <mailto:[email protected]> >> > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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 >> > >> >>
_______________________________________________ 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
