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.

Bug 918694

Summary:	[RFE] Create a normalized dn cache
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Sankar Ramalingam <sramling>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	amsharma, jgalipea, mreynolds, nhosoi, rmeggins
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.1.6-15.el7	Doc Type:	Enhancement
Doc Text:	Cause: A potential for a performance gain by implementing a normalized DN cache. Consequence: Boost in performance by plugins such as roles, & memberof, or operations what update entries with many DN syntax attributes. Change: A configurable normalized DN cache was created. Result: Improved performance of DN handling by the server.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-13 11:50:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nathan Kinder 2013-03-06 18:13:58 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/408

DN normalization is very expensive, it would be much more efficient to implement a  cache of normalized DNs.  This would definitely give an overall performance boost,  especially around static groups.

Comment 1 Rich Megginson 2013-10-01 23:26:51 UTC

moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.

Comment 7 Amita Sharma 2014-01-10 07:47:55 UTC

[root@dhcp201-149 /]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=config
changetype: modify
replace: nsslapd-ndn-cache-enabled
nsslapd-ndn-cache-enabled: on
> EOF
modifying entry "cn=config"

[root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
ldap_result: Can't contact LDAP server (-1)

[root@dhcp201-149 /]# systemctl start dirsrv@dhcp201-149

[root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: on

[root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config"
# extended LDIF
#
# LDAPv3
# base <cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# monitor, userRoot, ldbm database, plugins, config
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: monitor
database: ldbm database
readonly: 0
entrycachehits: 6
entrycachetries: 9
entrycachehitratio: 66
currententrycachesize: 7198
maxentrycachesize: 10485760
currententrycachecount: 2
maxentrycachecount: -1
dncachehits: 0
dncachetries: 2
dncachehitratio: 0
currentdncachesize: 124
maxdncachesize: 10485760
currentdncachecount: 2
maxdncachecount: -1
normalizeddncachetries: 450
normalizeddncachehits: 355
normalizeddncachemisses: 95
normalizeddncachehitratio: 78

Hence marking bug as VERIFIED.

Comment 8 Rich Megginson 2014-01-10 14:24:11 UTC

(In reply to Amita Sharma from comment #7)
> [root@dhcp201-149 /]# ldapmodify -h localhost -p 389 -D "cn=directory
> manager" -w Secret123 <<EOF
> dn: cn=config
> changetype: modify
> replace: nsslapd-ndn-cache-enabled
> nsslapd-ndn-cache-enabled: on
> > EOF
> modifying entry "cn=config"
> 
> [root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory
> Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
> ldap_result: Can't contact LDAP server (-1)

???  What happened here?  Did the server crash?

> 
> [root@dhcp201-149 /]# systemctl start dirsrv@dhcp201-149
> 
> [root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory
> Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
> nsslapd-ndn-cache-enabled: on
> 
> [root@dhcp201-149 /]# ldapsearch -x -h localhost -p 389 -D "cn=Directory
> Manager" -w Secret123 -b "cn=monitor,cn=userRoot,cn=ldbm
> database,cn=plugins,cn=config"
> # extended LDIF
> #
> # LDAPv3
> # base <cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config> with
> scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> 
> # monitor, userRoot, ldbm database, plugins, config
> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: monitor
> database: ldbm database
> readonly: 0
> entrycachehits: 6
> entrycachetries: 9
> entrycachehitratio: 66
> currententrycachesize: 7198
> maxentrycachesize: 10485760
> currententrycachecount: 2
> maxentrycachecount: -1
> dncachehits: 0
> dncachetries: 2
> dncachehitratio: 0
> currentdncachesize: 124
> maxdncachesize: 10485760
> currentdncachecount: 2
> maxdncachecount: -1
> normalizeddncachetries: 450
> normalizeddncachehits: 355
> normalizeddncachemisses: 95
> normalizeddncachehitratio: 78
> 
> Hence marking bug as VERIFIED.

Comment 9 Amita Sharma 2014-01-10 18:01:52 UTC

Hi Rich,

I thought it takes server to restart after modifying the attribute but when I tried it modifying again n again, it did not give me any such error ::
ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"

ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=config
changetype: modify
replace: nsslapd-ndn-cache-enabled
nsslapd-ndn-cache-enabled: on
EOF


[root@dhcp201-149 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: on
[root@dhcp201-149 ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=config
> changetype: modify
> replace: nsslapd-ndn-cache-enabled
> nsslapd-ndn-cache-enabled: on
> EOF
modifying entry "cn=config"


[root@dhcp201-149 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: on
[root@dhcp201-149 ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=config
changetype: modify
replace: nsslapd-ndn-cache-enabled
nsslapd-ndn-cache-enabled: off
> EOF
modifying entry "cn=config"

[root@dhcp201-149 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: off

Then, I removed the Instance, created the fresh one..again for the first time when I modified the attribute ..

Your new DS instance 'dhcp201-149' was successfully created.
Exiting . . .
Log file is '/tmp/setup253M6G.log'

[root@dhcp201-149 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: off
[root@dhcp201-149 ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=config
> changetype: modify
> replace: nsslapd-ndn-cache-enabled
> nsslapd-ndn-cache-enabled: on
> EOF
modifying entry "cn=config"

[root@dhcp201-149 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
ldap_result: Can't contact LDAP server (-1)

[root@dhcp201-149 ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=config
changetype: modify
replace: nsslapd-ndn-cache-enabled
nsslapd-ndn-cache-enabled: on
EOF
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

[root@dhcp201-149 ~]# ps -aef | grep slapd
root     22391 22008  0 23:00 pts/1    00:00:00 tail -f /var/log/dirsrv/slapd-dhcp201-149/access
root     22413 21982  0 23:04 pts/0    00:00:00 grep --color=auto slapd

Moving back the bug to ON_QA...

Comment 10 Rich Megginson 2014-01-10 18:03:55 UTC

Please provide the errors log

Comment 11 Amita Sharma 2014-01-10 18:08:36 UTC

[root@dhcp201-149 /]# tail -f /var/log/dirsrv/slapd-dhcp201-149/errors
[10/Jan/2014:22:57:48 +051800] - import userRoot: Indexing complete.  Post-processing...
[10/Jan/2014:22:57:48 +051800] - import userRoot: Generating numSubordinates complete.
[10/Jan/2014:22:57:48 +051800] - import userRoot: Flushing caches...
[10/Jan/2014:22:57:48 +051800] - import userRoot: Closing files...
[10/Jan/2014:22:57:49 +051800] - All database threads now stopped
[10/Jan/2014:22:57:49 +051800] - import userRoot: Import complete.  Processed 9 entries in 2 seconds. (4.50 entries/sec)
[10/Jan/2014:22:57:49 +051800] - 389-Directory/1.3.1.6 B2014.08.2017 starting up
[10/Jan/2014:22:57:49 +051800] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file.
[10/Jan/2014:22:57:49 +051800] - I'm resizing my cache now...cache was 785776640 and is now 8000000
[10/Jan/2014:22:57:50 +051800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
^C
[root@dhcp201-149 /]# tail -f /var/log/dirsrv/slapd-dhcp201-149/access
[10/Jan/2014:22:58:33 +051800] conn=1 fd=64 slot=64 connection from ::1 to ::1
[10/Jan/2014:22:58:33 +051800] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[10/Jan/2014:22:58:33 +051800] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[10/Jan/2014:22:58:33 +051800] conn=1 op=1 SRCH base="cn=config" scope=2 filter="(objectClass=*)" attrs=ALL
[10/Jan/2014:22:58:34 +051800] conn=1 op=1 RESULT err=0 tag=101 nentries=164 etime=1
[10/Jan/2014:22:58:34 +051800] conn=1 op=2 UNBIND
[10/Jan/2014:22:58:34 +051800] conn=1 op=2 fd=64 closed - U1

Comment 12 Rich Megginson 2014-01-10 18:19:30 UTC

Specifically, I'm looking for the errors log from around the time of the

ldap_result: Can't contact LDAP server (-1)

and after the restart following this.

Comment 17 Amita Sharma 2014-01-10 18:57:36 UTC

Crash was reproduced and system info given to dev with core file generated.

Comment 18 Noriko Hosoi 2014-01-10 19:04:08 UTC

ndn_cache_init is called from main once, in which ndn_cache is allocated and initialized.

I wonder it is not designed to enable/disable dynamically???

Comment 19 mreynolds 2014-01-16 13:44:03 UTC

(In reply to Noriko Hosoi from comment #18)
> ndn_cache_init is called from main once, in which ndn_cache is allocated and
> initialized.
> 
> I wonder it is not designed to enable/disable dynamically???

It was not.

Comment 20 mreynolds 2014-01-16 21:20:38 UTC

A potential fix for the crash is currently going through some automated testing.  If all goes well, it should be pushed to the latest branches tomorrow.

Comment 21 Amita Sharma 2014-02-27 10:56:31 UTC

[root@dhcp201-149 perlLDAP]# rpm -qa | grep 389
389-adminutil-1.1.15-3.fc19.1.x86_64
389-ds-base-libs-1.3.1.6-21.el7.x86_64
389-ds-base-1.3.1.6-21.el7.x86_64
389-console-1.1.7-4.fc19.noarch
[root@dhcp201-149 perlLDAP]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: off
[root@dhcp201-149 perlLDAP]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=config
> changetype: modify
> replace: nsslapd-ndn-cache-enabled
> nsslapd-ndn-cache-enabled: on
> EOF
modifying entry "cn=config"

[root@dhcp201-149 perlLDAP]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: on
[root@dhcp201-149 perlLDAP]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=config
changetype: modify
replace: nsslapd-ndn-cache-enabled
nsslapd-ndn-cache-enabled: off
> EOF
modifying entry "cn=config"

[root@dhcp201-149 perlLDAP]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep -i "nsslapd-ndn-cache-enabled"
nsslapd-ndn-cache-enabled: off

[root@dhcp201-149 ~]# tail -f /var/log/dirsrv/slapd-dhcp201-149/errors
[27/Feb/2014:15:44:52 +051800] - import userRoot: Indexing complete.  Post-processing...
[27/Feb/2014:15:44:52 +051800] - import userRoot: Generating numSubordinates complete.
[27/Feb/2014:15:44:52 +051800] - import userRoot: Flushing caches...
[27/Feb/2014:15:44:52 +051800] - import userRoot: Closing files...
[27/Feb/2014:15:44:52 +051800] - All database threads now stopped
[27/Feb/2014:15:44:52 +051800] - import userRoot: Import complete.  Processed 9 entries in 1 seconds. (9.00 entries/sec)
[27/Feb/2014:15:44:55 +051800] - 389-Directory/1.3.1.6 B2014.057.165 starting up
[27/Feb/2014:15:44:55 +051800] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file.
[27/Feb/2014:15:44:55 +051800] - I'm resizing my cache now...cache was 785776640 and is now 8000000
[27/Feb/2014:15:44:56 +051800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
^C
[root@dhcp201-149 ~]# tail -f /var/log/dirsrv/slapd-dhcp201-149/access
[27/Feb/2014:16:00:00 +051800] conn=6 op=1 RESULT err=0 tag=103 nentries=0 etime=0
[27/Feb/2014:16:00:00 +051800] conn=6 op=2 UNBIND
[27/Feb/2014:16:00:00 +051800] conn=6 op=2 fd=65 closed - U1
[27/Feb/2014:16:00:05 +051800] conn=7 fd=65 slot=65 connection from ::1 to ::1
[27/Feb/2014:16:00:05 +051800] conn=7 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[27/Feb/2014:16:00:05 +051800] conn=7 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[27/Feb/2014:16:00:05 +051800] conn=7 op=1 SRCH base="cn=config" scope=2 filter="(objectClass=*)" attrs=ALL
[27/Feb/2014:16:00:05 +051800] conn=7 op=1 RESULT err=0 tag=101 nentries=164 etime=0
[27/Feb/2014:16:00:05 +051800] conn=7 op=2 UNBIND
[27/Feb/2014:16:00:05 +051800] conn=7 op=2 fd=65 closed - U1
^C
[root@dhcp201-149 ~]# systemctl status dirsrv@dhcp201-149
dirsrv - 389 Directory Server dhcp201-149.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled)
   Active: active (running) since Thu 2014-02-27 15:44:55 IST; 18min ago
  Process: 17160 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
 Main PID: 17161 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv
           └─17161 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-dhcp201-149 -i /var/run/dirsrv/slapd-dhcp201-149.pid -w /var/run/dirsrv/slapd-dhcp201-149.startpid

Feb 27 15:44:55 dhcp201-149.englab.pnq.redhat.com systemd[1]: Started 389 Directory Server dhcp201-149..

Hence VERIFIED

Comment 22 Amita Sharma 2014-05-05 11:51:16 UTC

Test cases are in acceptance/basic/config.sh

Comment 23 Ludek Smid 2014-06-13 11:50:58 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.