#47435 Very large entryusn values after enabling the USN plugin and the lastusn value is negative.
Closed: wontfix None Opened 8 years ago by nhosoi.

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):

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- 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.

  1. Bug description: Entryusn syntax is defined as an integer in
    the schema. If negative values are accidentally stored in the
    entryusn value in the database, it was casted to the unsigned
    integer in the entryusn initialization code (usn_get_last_usn).

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".

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:

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.