This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 616618

Summary: 389 v1.2.5 accepts 2 identical entries with different DN formats
Product: [Community] 389 Reporter: Noriko Hosoi <nhosoi>
Component: MigrationAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: high    
Version: 1.2.6CC: amsharma, jgalipea, rmeggins
Target Milestone: ---Keywords: VerifiedUpstream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 12:05:37 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 543590, 639035    
Attachments:
Description Flags
git patch file (389-ds-base-1.2.6)
none
git patch file (389-ds-base-1.2.6) nkinder: review+

Description Noriko Hosoi 2010-07-20 21:10:15 EDT
Description of problem:
Duplicating bug 612771 for v1.2.6:
https://bugzilla.redhat.com/show_bug.cgi?id=612771
Bug 612771 - RHDS 8.1 accepts 2 identical entries with different DN formats
Comment 1 Noriko Hosoi 2010-07-21 21:13:17 EDT
Created attachment 433565 [details]
git patch file (389-ds-base-1.2.6)

Change Description:
. renamed 91upgradednformat.pl to 80upgradednformat.pl to run
  upgradednformat before 90subtreerename.pl.
. ported following patches applied to Directory_Server_8_2_Branch
  to master and 389-ds-base-1.2.6.
  612771 - RHDS 8.1/389 v1.2.5 accepts 2 identical entries with
           different DN formats
  * commit 50bb2ee6676e10cdda704982dfa831efa4011037
    Fix Description:
    This patch fixes the upgradednformat utility to eliminate the
    duplicated DNs found in the upgrading period.  Assuming DN:
    attr0=value0,attr1=value1,...,attrn=valuen exists in the DB
    and another identical DN is found, the second DN is renamed to
      nsuniqueid=<uuid>+attr0=value0,attr1=value1,...,attrn=valuen
    , where the <uuid> is the unique id assigned to the entry when
    the entry is added to the server.  The modification is logged
    in the error log.

    In addition, there was a bug to handle multi-valued RDNs in
    slapi_dn_normalize_ext.  In case multi-valued RDN appears with
    DN value (e.g., nsuniqueid=<uuid>+cn=uid\=<uid>\,o\=<org>,dc=<dc>),
    it was not normalized properly.  Introduced second rdn_av_stack
    (subinitial_rdn_av_stack) for the nested DN value.

    See also:
    http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format#Another_Upgrade_Scenario

  * commit ebaa18adaf201f75c709e078abd8e32605eddb81
    Fix Description:
    1) In the previous commit 50bb2ee6676e10cdda704982dfa831efa4011037,
    there were 3 places to miss replacing rdn_av_count with subrdn_av_count.
    2) A variable subtypestart is used to keep the head of nested
    multivalued RDNs.  For instance,
       seeAlso=cn\=<CN>\+l\=<L>\,o\=<O>,dc=examle,dc=com
               ^   or    ^   or  ^
    There was a bug to set the first position ("cn" in the above example).

    In addition, fixed a warning assigning "const char *" to "char *" in
    import_foreman (import-threads.c).

  * commit 472a2c0f2f21205390ba87c31c498b4419a932ba
    Fix Description:
    When newly creating an ancestorid index file, instead of
    opening the index file with DB_TRUNCATE option, delete
    the file then create it.

  616135 - Upgrade failure on Solaris :
           tar: db/NetscapeRoot/{DBVERSION,*.db4}:
           No such file or directory

  * commit e6723421e6dc69408edb2a396eb22da361cff206
    Fix Description:
    .../'{'DBVERSION,*.db4'}' is not a shell syntax. Process DBVERSION
    and *.db4 individually.
Comment 2 Noriko Hosoi 2010-07-22 12:26:11 EDT
Created attachment 433752 [details]
git patch file (389-ds-base-1.2.6)

Reran autogen.sh on RHEL5, which suppressed the unnecessary changes made on the auto-generated files. (Thanks for the comments, Nathan!)
Comment 4 Noriko Hosoi 2010-07-22 15:12:19 EDT
Reviewed by Nathan (Thank you!!!)

Pushed to 389-ds-base-1.2.6:

$ git push origin ds126-local:389-ds-base-1.2.6
Counting objects: 53, done.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (27/27), 37.38 KiB, done.
Total 27 (delta 24), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   9d638b3..700d7c1  ds126-local -> 389-ds-base-1.2.6

commit 700d7c1a199db4a690740636b8bd3e612304ce1e
commit 0b6ddc9b06845bdf385e749f2c5a99497df20d98

Pushed to master:

$ git push
Counting objects: 54, done.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (28/28), 177.61 KiB, done.
Total 28 (delta 16), reused 9 (delta 1)
To ssh://git.fedorahosted.org/git/389/ds.git
   2a03eed..2f9943f  master -> master

commit 2f9943f02911e6ee7de2d28860a929345fae629c
Comment 5 Jenny Galipeau 2011-06-06 13:03:02 EDT
Not sure why this bug was duplicated ... but the original bug was already verified on DS 8.2 https://bugzilla.redhat.com/show_bug.cgi?id=612771 - do we need to re-verify?
Comment 6 Noriko Hosoi 2011-06-06 13:33:35 EDT
(In reply to comment #5)
> Not sure why this bug was duplicated ... but the original bug was already
> verified on DS 8.2 https://bugzilla.redhat.com/show_bug.cgi?id=612771 - do we
> need to re-verify?

At that time, we are working on 2 separated branches, and I wanted to make sure the fix is put into the both trees, I guess.  I think the verify on 8.2 covers 9.0, as well.
Comment 7 Jenny Galipeau 2011-06-06 13:55:53 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Not sure why this bug was duplicated ... but the original bug was already
> > verified on DS 8.2 https://bugzilla.redhat.com/show_bug.cgi?id=612771 - do we
> > need to re-verify?
> 
> At that time, we are working on 2 separated branches, and I wanted to make sure
> the fix is put into the both trees, I guess.  I think the verify on 8.2 covers
> 9.0, as well.

Okay, since they were separate branches, it doesn't hurt to verify it again.
Comment 8 Noriko Hosoi 2011-07-26 20:14:21 EDT
We could say this bug was verified upstream.

Otherwise, the verify steps are found here:
https://bugzilla.redhat.com/show_bug.cgi?id=612771#c14