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
>> <[email protected]
>> <mailto:[email protected]>> 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 -- [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
>> <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
>> <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
