#49300 Duplicate entryUSN numbers for different LDAP entries in the same backend
Opened 2 years ago by pj101. Modified 4 months ago

Issue Description

According to the description of entryUSN plugin and attribute functioning (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/tracking_modifications_to_directory_entries) it should be unique for each backend (excluding entryusn=0 for imported and never changed entries). In our production environment (389ds v1.3.6.6) there are multiple entries having 2 exactly same entryUSN. Generally it's a group and a user entry that was added/deleted from that group.

Steps to reproduce

  1. Probably heavy large group modifications with memberOf and entryUSN plugins enabled
  2. Check dbscan -r -f entryusn.db
  3. To find all duplicate entries:
    dbscan -r -f entryusn.db | tail -n +3 | grep -B 1 '[0-9]+ [0-9]'

Actual results

for some entryUSN numbers there are two entries:
=174757
9955 40108
It is always a group and a user, so it is very probable the duplicate entryUSN is generated during memberOf plugin functioning:
cn=Groupe Example,ou=Par entite,ou=Groupes Globaux,ou=Groupes,dc=id,dc=polytechnique,dc=edu
...
uniqueMember: uid=user1,ou=Personnel,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu
...
modifyTimeStamp: 20170620133023Z
modifiersName: cn=X LDAP Root
entryUSN: 174757

uid=user1,ou=Personnel,ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu
...
memberOf: cn=Groupe Example,ou=Par entite,ou=Groupes Globaux,ou=Groupes,dc=id,dc=polytechnique,dc=edu
...
modifyTimeStamp: 20170620133023Z
modifiersName: cn=X LDAP Root
entryUSN: 174757

Expected results

entryUSN is supposed to be unique per backend according to documentation. These duplicates are not very critical since anyway the two changed entries will be found by the filter entryUSN>=n.


Frequency of occurence: we have 60 duplicate entryUSN for 10650 distinct values of entryUSN contained in entryusn.db

@pj101 Through another ticket, I may have an idea about why this occurs. I will update shortly on my findings

Metadata Update from @firstyear:
- Custom field type adjusted to defect

2 years ago

Some additional information: lastusn;userroot at the "" is sometimes larger than the real maximum entryUSN in the index entryusn.db. It probably happens because of the duplicates in index:

ldapsearch -x -h ldap-model.polytechnique.fr -b "" -s base '(objectClass=*)' 'lastusn;userroot'
dn:
lastusn;userroot: 176

dbscan -r -f entryusn.db | tail
=171
8681
=172
8726
=173
8960
=174
9020
=175
6597 24283

After server restart the the value of lastusn;userroot returns to the real maximum value in index:
ldapsearch -x -h ldap-model.polytechnique.fr -b "" -s base '(objectClass=*)' 'lastusn;userroot'
dn:
lastusn;userroot: 175

I reproduced the issue quite easily, a log of my actions is attached, it shows the duplicate entryusn problem and the problem of lastusn beeing ahead

Also, the issue (I think it is the same issue) possible to reproduce with TET - subtreeRenamesRunIt - subtree_31 test case.

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.3.7.0

2 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.2 (was: 1.3.7.0)

4 months ago

Login to comment on this ticket.

Metadata
Attachments 2
Attached 2 years ago View Comment
Attached 2 years ago View Comment