Kathy Zhu via FreeIPA-users wrote: > 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.
Glad you figured it out. I'd have never guessed that from the logs :-) rob > > 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] > <mailto:[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]> > > <mailto:[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]> > <mailto:[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]>> > > > <mailto:[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> > > > > <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> > > > <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]> > > <mailto:[email protected] > <mailto:[email protected]>> > > To unsubscribe send an email to > > [email protected] > <mailto:[email protected]> > > <mailto:[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 > _______________________________________________ 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
