Kees Bakker wrote:
> 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>

Only the DS checks provide this field. There are no plans to include it
ipa-healthcheck at this time.

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

Because it is the *server* which filters the results.

Returning the conflict entries routinely confused LDAP clients which
only expected a single return, for say, a query for a user.

rob

> -- 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@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@lists.fedorahosted.org
>>     <mailto:freeipa-users@lists.fedorahosted.org>
>>     To unsubscribe send an email to
>>     freeipa-users-le...@lists.fedorahosted.org
>>     <mailto:freeipa-users-le...@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.fedorahosted.org
>>     Do not reply to spam on the list, report it:
>>     https://pagure.io/fedora-infrastructure
>>     <https://pagure.io/fedora-infrastructure>
>>
> 
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to