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.
Using a large number of CoS templates no longer slow down the virtual attribute processing time
Due to a bug, using a large number of Class of Service (CoS) templates in Directory Server increased the virtual attribute processing time. This update improves the structure of the CoS storage. As a result, using a large number of CoS templates no longer increases the virtual attribute processing time.
Created attachment 1364283[details]
sample ldif to reproduce the issue
Description of problem:
When using Indirect Cos like the following,
dn: cn=cosDefinition,dc=test,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: cossuperdefinition
objectClass: cosIndirectDefinition
cosAttribute: ou merge-schemes
cosAttribute: description merge-schemes
cosAttribute: postalCode merge-schemes
cn: cosDefinition
cosIndirectSpecifier: seeAlso
search takes longer than before after cosTemplate entries are added/modified.
Version-Release number of selected component (if applicable):
389-ds-base-1.3.6.1-24.el7_4.x86_64
How reproducible:
This can be reproduced with attached sample LDIF.
Steps to Reproduce:
1. create suffix dc=test,dc=com and import test.ldif
(or adjust suffix accordingly)
2. run the following search
ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1
=> this return the result immediately
3. add new cosTemplcate by the following command
ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif
stop ldapmodify after adding about 500 entries by CTRL+C
4. run the same search
ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1
=> this will take a time than step 2
5. add new cosTemplcate by the following command again
ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif
stop ldapmodify after adding around 500 entries by CTRL+C
6. run the same search
ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1
=> this will take a time than step 2 and 4
7. add additional Cos Identifier attribute
ldapmodify -D "cn=directory manager" -w password -a -f addCosIdentifier.ldif
8. run the same search
ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1
=> this will take too time than before (Cos works as expected though)
9. restart server and do the same search
=> this returns entry immediately
Actual results:
search takes longer time than before
Expected results:
search returns result soon
Additional info:
This happen after applying 389-ds-base-1.3.6.1-24.el7_4.x86_64.
But this does not happen with 389-ds-base-1.3.6.1-23.el7_4.x86_64
Comment 9wibrown@redhat.com
2017-12-11 09:32:29 UTC
patch was confirmed good, making this bz 1523183 a RHEL-7.4.z candidate for the sf customer case number 01987672
to be reviewed tomorrow with dev and qe.
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.
https://access.redhat.com/errata/RHBA-2018:0811
Created attachment 1364283 [details] sample ldif to reproduce the issue Description of problem: When using Indirect Cos like the following, dn: cn=cosDefinition,dc=test,dc=com objectClass: top objectClass: ldapsubentry objectClass: cossuperdefinition objectClass: cosIndirectDefinition cosAttribute: ou merge-schemes cosAttribute: description merge-schemes cosAttribute: postalCode merge-schemes cn: cosDefinition cosIndirectSpecifier: seeAlso search takes longer than before after cosTemplate entries are added/modified. Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-24.el7_4.x86_64 How reproducible: This can be reproduced with attached sample LDIF. Steps to Reproduce: 1. create suffix dc=test,dc=com and import test.ldif (or adjust suffix accordingly) 2. run the following search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this return the result immediately 3. add new cosTemplcate by the following command ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif stop ldapmodify after adding about 500 entries by CTRL+C 4. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take a time than step 2 5. add new cosTemplcate by the following command again ldapmodify -D "cn=directory manager" -w password -a -c -f ou10000.ldif stop ldapmodify after adding around 500 entries by CTRL+C 6. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take a time than step 2 and 4 7. add additional Cos Identifier attribute ldapmodify -D "cn=directory manager" -w password -a -f addCosIdentifier.ldif 8. run the same search ldapsearch -D "cn=directory manager" -w password -b dc=test,dc=com uid=user1 => this will take too time than before (Cos works as expected though) 9. restart server and do the same search => this returns entry immediately Actual results: search takes longer time than before Expected results: search returns result soon Additional info: This happen after applying 389-ds-base-1.3.6.1-24.el7_4.x86_64. But this does not happen with 389-ds-base-1.3.6.1-23.el7_4.x86_64