Hi, ipahealthcheck gives me this warning [   {     "source": "ipahealthcheck.ds.replication",     "check": "ReplicationCheck",     "result": "WARNING",     "uuid": "237f4271-6e93-4d42-a15d-accdb936e51b",     "when": "20210709182051Z",     "duration": "45.967890",     "kw": {       "key": "DSREPLLE0002",       "items": [         "Replication",         "Conflict Entries"       ],       "msg": "There were 1 conflict entries found under the replication suffix \"o=ipaca\"."     }   } ] ldapsearch does not reveal any hit, however nsconf does. [root@linge ~]# ldapsearch -H ldaps://linge.example.com -W -D 'cn=Directory Manager' -b 'o=ipaca' '(nsds5ReplConflict=*)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <o=ipaca> with scope subtree # filter: (nsds5ReplConflict=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 [root@linge ~]# dsconf slapd-EXAMPLE-COM  repl-conflict list o=ipaca dn: cn=iparep4.example.com:443+nsuniqueid=ee993401-84ef11eb-93f498e2-54354ddc,cn=CAList,ou=Security Domain,o=ipaca Clone: TRUE DomainManager: TRUE SecureAdminPort: 443 SecureAgentPort: 443 SecureEEClientAuthPort: 443 SecurePort: 443 SubsystemName: CA iparep4.example.com 8443 UnSecurePort: 80 cn: iparep4.example.com:443 host: iparep4.example.com nsds5replconflict: namingConflict (ADD) cn=iparep4.example.com:443,cn=calist,ou=security domain,o=ipaca objectClass: top objectClass: pkiSubsystem objectClass: ldapsubentry How is that possible?

On 09-07-2021 21:33, Rob Crittenden wrote: > Kees Bakker via FreeIPA-users wrote: >> Hi, >> >> ipahealthcheck gives me this warning >> >> [ >> { >> "source": "ipahealthcheck.ds.replication", >> "check": "ReplicationCheck", >> "result": "WARNING", >> "uuid": "237f4271-6e93-4d42-a15d-accdb936e51b", >> "when": "20210709182051Z", >> "duration": "45.967890", >> "kw": { >> "key": "DSREPLLE0002", >> "items": [ >> "Replication", >> "Conflict Entries" >> ], >> "msg": "There were 1 conflict entries found under the replication >> suffix \"o=ipaca\"." >> } >> } >> ] >> >> >> ldapsearch does not reveal any hit, however nsconf does. >> >> >> [root@linge ~]# ldapsearch -H ldaps://linge.example.com -W -D >> 'cn=Directory Manager' -b 'o=ipaca' '(nsds5ReplConflict=*)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base <o=ipaca> with scope subtree >> # filter: (nsds5ReplConflict=*) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> >> [root@linge ~]# dsconf slapd-EXAMPLE-COM repl-conflict list o=ipaca >> dn: >> cn=iparep4.example.com:443 +nsuniqueid=ee993401-84ef11eb-93f498e2-54354ddc,cn=CAList,ou=Security >> Domain,o=ipaca >> Clone: TRUE >> DomainManager: TRUE >> SecureAdminPort: 443 >> SecureAgentPort: 443 >> SecureEEClientAuthPort: 443 >> SecurePort: 443 >> SubsystemName: CA iparep4.example.com 8443 >> UnSecurePort: 80 >> cn: iparep4.example.com:443 >> host: iparep4.example.com >> nsds5replconflict: namingConflict (ADD) >> cn=iparep4.example.com:443,cn=calist,ou=security domain,o=ipaca >> objectClass: top >> objectClass: pkiSubsystem >> objectClass: ldapsubentry >> >> >> How is that possible? > 389 filters out conflict entries now. Add this filter and you should see > it with ldapsearch: > > (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) > That makes no difference. Both BASEDN and o=ipaca result in no hits. (( Can ldapsearch really filter out more if the filter expression is less restrictive? )) [root@linge ~]# ldapsearch -H ldaps://linge.example.com -W -D 'cn=Directory Manager' -b 'o=ipaca' '(&(!(objectclass=nstombstone))(nsds5ReplConflict=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <o=ipaca> with scope subtree # filter: (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 [root@linge ~]# ldapsearch -H ldaps://linge.example.com -W -D 'cn=Directory Manager' -b $BASEDN '(&(!(objectclass=nstombstone))(nsds5ReplConflict=*))' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -- Kees _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org 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/freeipa-users@lists.fedoraho... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Thanks Flo, Yes! That's the one. Anyway, back to ipahealthcheck. How can we improve it so that users don't have to struggle with pdb in discovering what is actually wrong? ("we" => Rob :-) Only because I came across the following I was able to see the problem using dsconf. (Pdb) print(result['fix']) While conflict entries are expected to occur in an MMR environment, they should be resolved.  In regards to conflict entries there is always the original/counterpart entry that has a normal DN, and then the conflict version of that entry.  Technically both entries are valid, you as the administrator, needs to decide which entry you want to keep. First examine/compare both entries to determine which one you want to keep or remove.  You can use the CLI tool "dsconf" to resolve the conflict.  Here is an example:       List the conflict entries:           # dsconf slapd-EXAMPLE-COM  repl-conflict list dc=example,dc=com       Examine conflict entry and its counterpart entry:           # dsconf slapd-EXAMPLE-COM  repl-conflict compare <DN of conflict entry>       Remove conflict entry and keep only the original/counterpart entry:           # dsconf slapd-EXAMPLE-COM  repl-conflict delete <DN of conflict entry>       Replace the original/counterpart entry with the conflict entry:           # dsconf slapd-EXAMPLE-COM  repl-conflict swap <DN of conflict entry>

BTW. LDAP (and ldapsearch) remains a mystery to me. How can a less restrictive filter show less results?

-- Kees On 12-07-2021 09:41, Florence Renaud wrote: > The correct search filter must include (objectClass=ldapSubEntry): > > ldapsearch -H ldaps://linge.example.com <http://linge.example.com> -W > -D 'cn=Directory Manager' -b 'o=ipaca' > '(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))' nsds5ReplConflict > > HTH, > flo > > On Sat, Jul 10, 2021 at 3:20 PM Kees Bakker via FreeIPA-users > <freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> wrote: > > On 09-07-2021 21:33, Rob Crittenden wrote: > > Kees Bakker via FreeIPA-users wrote: > >> Hi, > >> > >> ipahealthcheck gives me this warning > >> > >> [ > >>    { > >>      "source": "ipahealthcheck.ds.replication", > >>      "check": "ReplicationCheck", > >>      "result": "WARNING", > >>      "uuid": "237f4271-6e93-4d42-a15d-accdb936e51b", > >>      "when": "20210709182051Z", > >>      "duration": "45.967890", > >>      "kw": { > >>        "key": "DSREPLLE0002", > >>        "items": [ > >>          "Replication", > >>          "Conflict Entries" > >>        ], > >>        "msg": "There were 1 conflict entries found under the > replication > >> suffix \"o=ipaca\"." > >>      } > >>    } > >> ] > >> > >> > >> ldapsearch does not reveal any hit, however nsconf does. > >> > >> > >> [root@linge ~]# ldapsearch -H ldaps://linge.example.com > <http://linge.example.com> -W -D > >> 'cn=Directory Manager' -b 'o=ipaca' '(nsds5ReplConflict=*)' > >> Enter LDAP Password: > >> # extended LDIF > >> # > >> # LDAPv3 > >> # base <o=ipaca> with scope subtree > >> # filter: (nsds5ReplConflict=*) > >> # requesting: ALL > >> # > >> > >> # search result > >> search: 2 > >> result: 0 Success > >> > >> # numResponses: 1 > >> > >> > >> [root@linge ~]# dsconf slapd-EXAMPLE-COM  repl-conflict list > o=ipaca > >> dn: > >> > cn=iparep4.example.com:443+nsuniqueid=ee993401-84ef11eb-93f498e2-54354ddc,cn=CAList,ou=Security > >> Domain,o=ipaca > >> Clone: TRUE > >> DomainManager: TRUE > >> SecureAdminPort: 443 > >> SecureAgentPort: 443 > >> SecureEEClientAuthPort: 443 > >> SecurePort: 443 > >> SubsystemName: CA iparep4.example.com > <http://iparep4.example.com> 8443 > >> UnSecurePort: 80 > >> cn: iparep4.example.com:443 <http://iparep4.example.com:443> > >> host: iparep4.example.com <http://iparep4.example.com> > >> nsds5replconflict: namingConflict (ADD) > >> cn=iparep4.example.com:443 > <http://iparep4.example.com:443>,cn=calist,ou=security domain,o=ipaca > >> objectClass: top > >> objectClass: pkiSubsystem > >> objectClass: ldapsubentry > >> > >> > >> How is that possible? > > 389 filters out conflict entries now. Add this filter and you > should see > > it with ldapsearch: > > > > (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) > > > > That makes no difference. Both BASEDN and o=ipaca result in no hits. > (( Can ldapsearch really filter out more if the filter expression > is less restrictive? )) > > [root@linge ~]# ldapsearch -H ldaps://linge.example.com > <http://linge.example.com> -W -D 'cn=Directory Manager' -b > 'o=ipaca' '(&(!(objectclass=nstombstone))(nsds5ReplConflict=*))' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base <o=ipaca> with scope subtree > # filter: (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > [root@linge ~]# ldapsearch -H ldaps://linge.example.com > <http://linge.example.com> -W -D 'cn=Directory Manager' -b $BASEDN > '(&(!(objectclass=nstombstone))(nsds5ReplConflict=*))' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base <dc=example,dc=com> with scope subtree > # filter: (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > -- > Kees > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://fedoraproject.org/wiki/Mailing_list_guidelines> > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > <https://pagure.io/fedora-infrastructure> >