Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 986131
Description of problem: After enabling the USN plugin, entries that are added have large entryusn values and when in global USN mode the lastusn value is negative. Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-14.el6_4.x86_64 How reproducible: The customer said that the entryusn values were large for entries added after the plugin was enabled. I was able to produce a negative lastusn value of -1 when testing in my environment (same 389 version), after my first update it was 0 and then my second update was 1. Steps to Reproduce: I am working on getting more info from customer, I did the following to get the negative lastusn value: 1. setup-ds-admin.pl 2. I have single-master replication to one consumer 3. Enabled the USN plugin on the master in the redhat-idm-console 4. Enabled the global nsslapd-entryusn-global parameter via ldapmodify 5. The lastusn value is negative ldapsearch [...] -b "" -s base "(objectclass=*)" lastusn -D cn="directory manager" -W Actual results: For the customer: The initial entryusn values of entries that are added are very large and when in global usn mode the lastusn value is negative. Expected results: For the customer: The entryusn values shouldn't be extremely large and the lastusn shouldn't be negative after enabling the USN plugin and adding entries.
I built from 389-ds-base-1.2.11.15-14 tag, but I could not reproduce the problem. {{{ 1. Enabled entryusn plugin 1-1. nsslapd-entryusn-global: off lastusn;userroot: -1 1-2. nsslapd-entryusn-global: on lastusn: -1 2. Imported entries with negative entryusn dn: o=my.com entryusn: -100000000
dn: cn=Directory Administrators,o=my.com entryusn: -10000000 [...] dn: cn=QA Managers,ou=Groups,o=my.com entryusn: -10
dn: cn=PD Managers,ou=Groups,o=my.com entryusn: -1 2-1. Attempt to update entryusn value, which fails as expected. dn: cn=Accounting Managers,ou=Groups,o=my.com changetype: modify replace: entryusn entryusn: -2000
modifying entry cn=Accounting Managers,ou=Groups,o=my.com ldap_modify: DSA is unwilling to perform
2-2. Update an entry which has entryusn value -10000, which successfully sets the first entryusn value 0. dn: ou=Special Users,o=my.com entryusn: 0 2-3. Update an entry which has entryusn value -100000, which successfully sets the second entryusn value 1. dn: ou=People,o=my.com entryusn: 1 3. Check the values in the database. # dbscan -f id2entry.db | egrep entryusn entryusn: -100000000 entryusn: -10000000 entryusn: -1000000 entryusn: 1 entryusn: 0 entryusn: -1000 entryusn: -100 entryusn: -10 entryusn: -1 }}}
It looks my test data was not enough. If I import ldif with no "entryusn: -1": 2'. Imported entries with negative entryusn {{{ dn: o=my.com entryusn: -100000000
dn: cn=Directory Administrators,o=my.com entryusn: -10000000 [...] dn: cn=QA Managers,ou=Groups,o=my.com entryusn: -10 }}} And did a modify on, e.g., QA Managers, then got this large value: {{{ dn: cn=QA Managers,ou=Groups,o=my.com entryusn: 18446744073709551607
lastusn: 18446744073709551607 }}}
{{{ 1. Bug description: The initial value of lastusn is -1, but since the entryusn has the unsigned long long integer type, the server returns 18446744073709551615 == 0XFFFFFFFFFFFFFFFF.
Fix description: The initial value "-1" is returned as it is.
Fix description: When an entryusn value is retrieved from the database, it's checked as a singed integer once and if it is negative, it's replaced with the initial value "-1". }}}
git patch file (master) 0001-Ticket-47435-Very-large-entryusn-values-after-enabli.patch
Reviewed by Mark and Rich (Thank you!!)
Pushed to master. 7330597..c94da99 master -> master commit c94da99
Pushed to 389-ds-base-1.3.1. ea333f2..185d4f8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 185d4f8
Pushed to 389-ds-base-1.3.0. 90f170c..a94a75e 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 commit a94a75e
Pushed to 389-ds-base-1.2.11. bf53a29..f54e44c 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit f54e44c
We could not narrow down the origin of the negative values -- how the negative values ( < -1 ) were introduced to the server at first. The user did not do anything unusual such as importing entries having entryusn.
Closing this ticket for now.
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.22
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/772
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.