Bug 514955 - Replica assigns new value from local range when replace is performed with magic value
Summary: Replica assigns new value from local range when replace is performed with mag...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - DNA Plug-in
Version: 1.2.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.1
TreeView+ depends on / blocked
 
Reported: 2009-07-31 16:17 UTC by Nathan Kinder
Modified: 2015-12-07 16:49 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:49:48 UTC
Embargoed:


Attachments (Terms of Use)
Patch (2.99 KB, patch)
2009-07-31 22:14 UTC, Nathan Kinder
no flags Details | Diff
Revised Patch (3.05 KB, patch)
2009-08-03 16:08 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2009-07-31 16:17:37 UTC
When using DNA with replication, replacing an existing managed value with the magic value causes all replicas to assign a new value from their local range.  The first server should assign the value, which should then be replicated to all other replicas.

To reproduce:

  - Setup replication with 2 masters.
  - Enable the DNA plug-in on both masters.
  - Add the following shared configuration container:

       dn: ou=ranges,dc=example,dc=com
       objectclass: top
       objectclass: organiationalUnit
       ou: ranges

  - Add the following range configuration entries to the appropriate master:

    M1:
       dn: cn=testrange,cn=Distributed Numeric Assignment
        Plugin,cn=plugins,cn=config
       objectclass: extensibleObject
       dnamaxvalue: 1010
       dnamagicregen: 0
       dnathreshold: 1
       dnatype: uidNumber
       dnafilter: (objectclass=posixAccount)
       dnascope: dc=example,dc=com
       dnasharedcfgdn: ou=ranges,dc=example,dc=com
       dnanextvalue: 1001

    M2:
       dn: cn=testrange,cn=Distributed Numeric Assignment
        Plugin,cn=plugins,cn=config
       objectclass: extensibleObject
       dnamaxvalue: 1020
       dnamagicregen: 0
       dnathreshold: 1
       dnatype: uidNumber
       dnafilter: (objectclass=posixAccount)
       dnascope: dc=example,dc=com
       dnasharedcfgdn: ou=ranges,dc=example,dc=com
       dnanextvalue: 1011

  - Perform the following operation against M1:

       dn: uid=testuser,dc=example,dc=com
       changetype: add
       objectclass: posixAccount
       objectclass: inetorgperson
       cn: testuser
       sn: testuser
       homedirectory: /home/test    
       gidnumber: 1

  - At this point, the entry should have a uidNumber value of 1001 on
    both masters.

  - Perform the following operation against M1:

       dn: uid=testuser,dc=example,dc=com
       changetype: modify
       replace: uidNumber
       uidNumber: 0

  - At this point, the uidNumber will be 1002 on M1 and 1011 on M2.  The
    value is supposed to be 1002 on both servers.

Comment 2 Nathan Kinder 2009-07-31 22:14:57 UTC
Created attachment 355867 [details]
Patch

Comment 3 Nathan Kinder 2009-08-03 16:08:30 UTC
Created attachment 356057 [details]
Revised Patch

The previous patch did not handle all cases.  This new patch takes a different approach than the previous patch.  Instead of trimming the mod that triggered generation, we leave it alone and make DNA check subsequent mods before commiting to generating a new value.  This is easily done by just unsetting the generate flag if we find a subsequent mod for the same attribute in the same operation.

Comment 4 Nathan Kinder 2009-08-03 17:04:34 UTC
Pushed patch from comment#3 to master.  Thanks to Noriko for her review!

Comment 5 Jenny Severance 2010-06-02 13:44:59 UTC
verified - All DNA acceptance tests passing at 100% - all supported platforms


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