Bug 694927 - Full replica push loses some entries with multi-valued RDNs
Full replica push loses some entries with multi-valued RDNs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.1
Unspecified Linux
high Severity high
: rc
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
: screened
Depends On: 693962
Blocks: 639035 389_1.2.8
  Show dependency treegraph
 
Reported: 2011-04-08 18:57 EDT by Rich Megginson
Modified: 2015-01-04 18:47 EST (History)
8 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.8.1-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 693962
Environment:
Last Closed: 2011-05-19 08:43:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Megginson 2011-04-08 18:57:07 EDT
+++ This bug was initially created as a clone of Bug #693962 +++

Description of problem:

In 1.2.8 the components of multi-valued RDNs seem to be sorted, whereas in 1.2.5 the server kept them in the order they were in when the entry was created. When doing a full replica push from my 1.2.5 instance to 1.2.8 only those entries with multi-valued RDNs make it into 1.2.8 where the RDN components happen to be in the correct order.

Version-Release number of selected component (if applicable):

1.2.8.rc2, replicating from 1.2.5

How reproducible:

I have these two entries (amongst others) in the 1.2.5 instance:

dn: cn=Karsten+sn=Sperling,ou=People,dc=sky,dc=co,dc=nz
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: Karsten
sn: Sperling

dn: sn=Doe+cn=John,ou=People,dc=sky,dc=co,dc=nz
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: John
sn: Doe

After doing a full replica push to the 1.2.8 instance, only the first one of those is present in the 1.2.8 instance, the John Doe entry is missing.

If the John Doe entry is imported directly into the 1.2.8 instance, the DN is normalized to cn=John+sn=Doe,ou=People,dc=sky,dc=co,dc=nz. It seems the absence of this normalization step during the full replica initialization is what's causing this issue.

--- Additional comment from rmeggins@redhat.com on 2011-04-08 14:02:01 EDT ---

Created attachment 490848 [details]
0001-Bug-693962-Full-replica-push-loses-some-entries-with.patch

--- Additional comment from rmeggins@redhat.com on 2011-04-08 14:05:37 EDT ---

Created attachment 490849 [details]
0001-Bug-693962-Full-replica-push-loses-some-entries-with.patch

--- Additional comment from rmeggins@redhat.com on 2011-04-08 18:56:42 EDT ---

To ssh://git.fedorahosted.org/git/389/ds.git
   f9237d6..a82b8f0  389-ds-base-1.2.8 -> 389-ds-base-1.2.8
commit 54b95201cfc274c72e2364f49fc21b8a8e8fa688
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Fri Apr 8 11:55:27 2011 -0600
   47e725d..2472169  master -> master
commit 2472169b3e077ff379812f9e91f439ce1e4edffb
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Fri Apr 8 11:55:27 2011 -0600
    Reviewed by: nhosoi (Thanks!)
    Branch: master
    Fix Description: The code in _entryrdn_insert_key was assuming the srdn
    passed in was already normalized.  This is not true in some cases where
    the data is coming from a source of old data such as replication with an
    older server.  The solution is to make sure the rdn code always
    normalizes the code using slapi_dn_normalize_case_ext() instead of
    slapi_dn_normalize_case() which now doesn't do any normalization, it just
    converts the given string to lower case.  I added a function
    normalize_case_helper() to return a normalized dn as a copy or in place
    depending on the arguments.
    Tested with gdb - stepped through and verified the char arrays are correctly
    replaced, and copy values are correctly assigned.
    Used valgrind with online import to verify no leaks or errors.
    Exported a netscaperoot ldif from an older 1.2.8 server and imported with
    the new code.  Verified that the dbscan -f entryrdn.db4 output was
    identical between the two.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no
Comment 5 Rich Megginson 2011-05-02 11:31:16 EDT
To reproduce:
1) set up replication - master -> consumer
2) add the following entry to the master:
dn: sn=Doe+cn=John,<your suffix here>
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: John
sn: Doe

3) wait for replication to occur
4) verify that the entry is on the consumer
Comment 6 Amita Sharma 2011-05-02 13:29:40 EDT
Master - 20100
Slave - 20102

[root@rhel61-ds90-amita ~]# ldapmodify -x -h localhost -p 20100 -D "cn=Directory Manager" -w Secret123 << EOF
> dn: sn=Doe+cn=John,ou=people,dc=replsuffix,dc=com
> changetype: add
> objectClass: inetOrgPerson
> objectClass: top
> objectClass: organizationalPerson
> objectClass: person
> cn: John
> sn: Doe
> EOF
adding new entry "sn=Doe+cn=John,ou=people,dc=replsuffix,dc=com"

[root@rhel61-ds90-amita ~]# ldapsearch -h localhost -p 20100 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=replsuffix,dc=com"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=replsuffix,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# People, replsuffix.com
dn: ou=People,dc=replsuffix,dc=com
objectClass: top
objectClass: organizationalunit
ou: People

# John + Doe, People, replsuffix.com
dn: cn=John+sn=Doe,ou=People,dc=replsuffix,dc=com
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: John
sn: Doe

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

ldapsearch -h localhost -p 20102 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=replsuffix,dc=com"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=replsuffix,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# People, replsuffix.com
dn: ou=People,dc=replsuffix,dc=com
ou: People
objectClass: top
objectClass: organizationalunit

# John + Doe, People, replsuffix.com
dn: cn=John+sn=Doe,ou=People,dc=replsuffix,dc=com
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: John
sn: Doe

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2
 
Entry got replicated without crash. Bug is VERIFIED.
Comment 7 errata-xmlrpc 2011-05-19 08:43:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0533.html

Note You need to log in before you can comment on or make changes to this bug.