389-ds-base

#50363 ds-replcheck reports data inconsistency if attribute has matching entries but in different order
Closed: wontfix by mreynolds. Opened by mreynolds.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1708094

Description of problem:
/usr/bin/ds-replcheck reports "Entry Inconsistencies" in attribute data between
IPA master and replica, even though entries for the attribute match. This
happens when the entries of an attribute appear in a different order in the
LDAP database on the master and the replica.
========
Version-Release number of selected component (if applicable):
389-ds-base-1.3.8.4-22
========
How reproducible:
TBD
Steps to Reproduce:
1.
2.
3.
========
Actual results:
ds-replcheck reports "Entry Inconsistencies" when IPA master and replica have
correctly matching data for an attribute, however only the ordering is
different for those entries within the LDAP database.
For example:
==> If IPA master has:
....
memberUid: u1000xx@test.domain.com
memberUid: u1000yy@test.domain.com
....
==> and IPA replica has:
....
memberUid: u1000yy@test.domain.com
memberUid: u1000xx@test.domain.com
....
==> Both have identical entries but differing in order.
==> ds-replcheck reports the below error:
Entry Inconsistencies
=====================================================
cn=test_group,cn=groups,cn=compat,dc=linux,dc=test,dc=domain,dc=com
-------------------------------------------------------------------
 - Attribute 'memberuid' is different:
      Master:
        ....
        - Origin value: u1000xx@test.domain.com
        - Origin value: u1000yy@test.domain.com
        ....
      Replica:
        ....
        - Origin value: u1000yy@test.domain.com
        - Origin value: u1000xx@test.domain.com
        ....
========
Expected results:
Ideally, as long as all the entries in an attribute match on the IPA master and
replica, it should be considered as a successful comparison. Difference in
ordering doesn't cause any functional issues in LDAP and therefore shouldn't be
generating errors. This causes fall positives for customers using the script to
check replication data sync.
Additional info:

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1708094

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

https://pagure.io/389-ds-base/pull-request/50364

Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

commit 974c802fceb429315bf799805917a208b44c4917

4950a3e37..f31920392 389-ds-base-1.4.0 -> 389-ds-base-1.4.0

d116dd899..25c704a4a 389-ds-base-1.3.9 -> 389-ds-base-1.3.9

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3422

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.