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

Reply via email to