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(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>
>