Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionNikolai Kondrashov
2013-10-21 09:07:35 UTC
Description of problem:
After performing major addition/deletion of directory entries, subsequent minor additions/deletions result in an entry containing an attribute with the value being the bind DN, whereas that attribute was never set to that value in any of the operations.
Version-Release number of selected component (if applicable):
Server:
openldap-2.4.23-31.el6.x86_64
openldap-clients-2.4.23-31.el6.x86_64
openldap-servers-2.4.23-31.el6.x86_64
Client:
openldap-2.4.23-32.el6_4.1.x86_64
openldap-clients-2.4.23-32.el6_4.1.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Extract the attached "attribute_gets_bind_dn_value.tar.gz".
2. Go to the resulting "attribute_gets_bind_dn_value" directory.
3. Use "config.ldif" and "base.ldif" as the reference
for the directory server setup.
4. Modify the "stress.sh" file to match local setup.
5. Make sure lua is installed.
6. Add the extracted directory to PATH, for example with
"export PATH=`pwd`:$PATH" command.
7. Run "stress_make" - it will take 10-15 minutes.
8. Run "stress_check"
9. If need to repeat "stress_check", run "stress_cleanup" then go to step 8.
Actual results:
Output of "stress_check":
# Iteration 1
# Iteration 2
# Corrupted attribute encountered in an entry:
dn: cn=group10000,ou=Groups,dc=example,dc=com
objectClass: extensibleObject
objectClass: groupOfNames
gidNumber: 10000
cn: group10000
member: cn=Manager,dc=example,dc=com
Expected results:
Output of "stress_check":
# Iteration 1
# Iteration 2
# Iteration 3
# Iteration 4
# Iteration 5
# Iteration 6
# Iteration 7
# Iteration 8
# Iteration 9
# Iteration 10
Additional info:
See the attached ldap.pcap for a traffic capture of a ldapsearch followed by a "stress_check" execution.
The problem didn't reproduce when slapd was executed under Valgrind.
The problem didn't reproduce with openldap-servers-2.4.35-1.el6.x86_64.
Comment 1Nikolai Kondrashov
2013-10-21 09:08:28 UTC
Comment 4Nikolai Kondrashov
2013-10-21 09:13:38 UTC
Clarification to the Valgrind note: after "stress_make" was run, a subsequent "stress_check" run failed, slapd was stopped and started under Valgrind, another "stress_check" run didn't fail.
Moreover, after the slapd started under Valgrind was stopped and started again with the regular "service" command, "stress_check" runs stopped failing.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2014-1426.html
Description of problem: After performing major addition/deletion of directory entries, subsequent minor additions/deletions result in an entry containing an attribute with the value being the bind DN, whereas that attribute was never set to that value in any of the operations. Version-Release number of selected component (if applicable): Server: openldap-2.4.23-31.el6.x86_64 openldap-clients-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 Client: openldap-2.4.23-32.el6_4.1.x86_64 openldap-clients-2.4.23-32.el6_4.1.x86_64 How reproducible: Always Steps to Reproduce: 1. Extract the attached "attribute_gets_bind_dn_value.tar.gz". 2. Go to the resulting "attribute_gets_bind_dn_value" directory. 3. Use "config.ldif" and "base.ldif" as the reference for the directory server setup. 4. Modify the "stress.sh" file to match local setup. 5. Make sure lua is installed. 6. Add the extracted directory to PATH, for example with "export PATH=`pwd`:$PATH" command. 7. Run "stress_make" - it will take 10-15 minutes. 8. Run "stress_check" 9. If need to repeat "stress_check", run "stress_cleanup" then go to step 8. Actual results: Output of "stress_check": # Iteration 1 # Iteration 2 # Corrupted attribute encountered in an entry: dn: cn=group10000,ou=Groups,dc=example,dc=com objectClass: extensibleObject objectClass: groupOfNames gidNumber: 10000 cn: group10000 member: cn=Manager,dc=example,dc=com Expected results: Output of "stress_check": # Iteration 1 # Iteration 2 # Iteration 3 # Iteration 4 # Iteration 5 # Iteration 6 # Iteration 7 # Iteration 8 # Iteration 9 # Iteration 10 Additional info: See the attached ldap.pcap for a traffic capture of a ldapsearch followed by a "stress_check" execution. The problem didn't reproduce when slapd was executed under Valgrind. The problem didn't reproduce with openldap-servers-2.4.35-1.el6.x86_64.