Hide Forgot
Description of problem: If you attempt to run dbmon.sh on a DS server with nsslapd-require-secure-binds: on, dbmon.sh fails to connect. There probably should be an option to use TLS. Version-Release number of selected component (if applicable): 389-ds-base-1.3.5.10-11.el7.x86_64 How reproducible: always Steps to Reproduce: Set cn=config attribute nsslapd-require-secure-binds=on and run dbmon.sh Actual results: VERBOSE=2 /usr/sbin/dbmon.sh Thu Nov 10 19:29:13 UTC 2016 ldap_bind: Confidentiality required (13) additional info: Operation requires a secure connection awk: cmd. line:84: fatal: division by zero attempted
Thanks for the report, Brian. Indeed the ldapsearch called in dbmon.sh does not support the SSL/startTLS connection. > ldapsearch -xLLL -h $HOST -p $PORT -D "$BINDDN" -w "$BINDPW" -b "$ldbmdn" '(|(cn=config)(cn=database)(cn=monitor))' Could it be possible for you to try adding "-Z" to the ldapsearch command line? I'm assuming you set the cert db path to TLS_CACERTDIR ldap.conf and/or .ldaprc. Also, I'd like to double check this problem is not a regression. It's been there since nsslapd-require-secure-binds was introduced... Note: Switching the product to RHEL-7 since the component 389-ds-base belongs to the product.
Upstream ticket: https://fedorahosted.org/389/ticket/49065
Fixed upstream
With nsslapd-require-secure-binds: on [0 root@qeos-242 ds]# cat /etc/dirsrv/slapd-qeos-242/dse.ldif |grep secure-binds nsslapd-require-secure-binds: on [0 root@qeos-242 ds]# INCR=1 HOST="`hostname`" BINDDN="cn=directory manager" BINDPW="Secret123" VERBOSE=2 dbmon.sh Mon May 15 12:18:39 EDT 2017 ldap_bind: Confidentiality required (13) additional info: Operation requires a secure connection awk: cmd. line:84: fatal: division by zero attempted Mon May 15 12:18:40 EDT 2017 ldap_bind: Confidentiality required (13) additional info: Operation requires a secure connection awk: cmd. line:84: fatal: division by zero attempted With nsslapd-require-secure-binds: off [0 root@qeos-242 ds]# cat /etc/dirsrv/slapd-qeos-242/dse.ldif |grep secure-binds nsslapd-require-secure-binds: off [0 root@qeos-242 ds]# INCR=1 HOST="`hostname`" BINDDN="cn=directory manager" BINDPW="Secret123" VERBOSE=2 dbmon.sh Mon May 15 12:20:44 EDT 2017 # dbcachefree - free bytes in dbcache # free% - percent free in dbcache # roevicts - number of read-only pages dropped from cache to make room for other pages # if this is non-zero, it means the dbcache is maxed out and there is page churn # hit% - percent of requests that are served by cache When I set "nsslapd-require-secure-binds: on", dbmon.sh fails. I am not sure, if I am missing something!
The usage changed, you need SERVID --> This is what picks up the security directory, port, host, etc: SERVID=slapd-localhost INCR=1 BINDDN="cn=directory manager" BINDPW="Secret123" VERBOSE=2 dbmon.sh I just opened a doc bug to track the usage changes: https://bugzilla.redhat.com/show_bug.cgi?id=1451067
Thanks Mark!. It works fine on SSL enabled instance with SERVID. Hence, marking the bug as Verified [root@ibm-x3650m4-01-vm-01 ~]# cat /etc/dirsrv/slapd-ibm-x3650m4-01-vm-01/dse.ldif |grep secure-binds nsslapd-require-secure-binds: on [root@ibm-x3650m4-01-vm-01 ~]# cat /etc/dirsrv/slapd-ibm-x3650m4-01-vm-01/dse.ldif |grep security: nsslapd-security: on [root@ibm-x3650m4-01-vm-01 ~]# INCR=1 SERVID=slapd-ibm-x3650m4-01-vm-01 BINDDN="cn=directory manager" BINDPW="Secret123" VERBOSE=2 dbmon.sh Mon May 15 20:09:40 EDT 2017 # dbcachefree - free bytes in dbcache # free% - percent free in dbcache # roevicts - number of read-only pages dropped from cache to make room for other pages # if this is non-zero, it means the dbcache is maxed out and there is page churn # hit% - percent of requests that are served by cache # pagein - number of pages read into the cache # pageout - number of pages dropped from the cache dbcachefree 158613504 free% 99.753 roevicts 0 hit% 100 pagein 0 pageout 0 # dbname - name of database instance - the row shows the entry cache stats # count - number of entries in cache # free - number of free bytes in cache # free% - percent free in cache # size - average size of date in cache in bytes (current size/count) # DNcache - the line below the entry cache stats are the DN cache stats # count - number of dns in dn cache # free - number of free bytes in dn cache # free% - percent free in dn cache # size - average size of dn in dn cache in bytes (currentdncachesize/currentdncachecount) # under each db are the list of selected indexes specified with INDEXLIST dbname count free free% size netscaperoot:ent 15 134147113 99.9 4707.7 netscaperoot:dn 15 16774672 100.0 169.6 userroot:ent 2 134209285 100.0 4221.5 userroot:dn 2 16777090 100.0 63.0 Mon May 15 20:09:41 EDT 2017 # dbcachefree - free bytes in dbcache # free% - percent free in dbcache # roevicts - number of read-only pages dropped from cache to make room for other pages # if this is non-zero, it means the dbcache is maxed out and there is page churn # hit% - percent of requests that are served by cache # pagein - number of pages read into the cache # pageout - number of pages dropped from the cache dbcachefree 158613504 free% 99.753 roevicts 0 hit% 100 pagein 0 pageout 0 # dbname - name of database instance - the row shows the entry cache stats # count - number of entries in cache # free - number of free bytes in cache # free% - percent free in cache # size - average size of date in cache in bytes (current size/count) # DNcache - the line below the entry cache stats are the DN cache stats # count - number of dns in dn cache # free - number of free bytes in dn cache # free% - percent free in dn cache # size - average size of dn in dn cache in bytes (currentdncachesize/currentdncachecount) # under each db are the list of selected indexes specified with INDEXLIST dbname count free free% size netscaperoot:ent 15 134147113 99.9 4707.7 netscaperoot:dn 15 16774672 100.0 169.6 userroot:ent 2 134209285 100.0 4221.5 userroot:dn 2 16777090 100.0 63.0
[root@ibm-x3650m4-01-vm-01 ~]# rpm -qa |grep -i 389-ds-base 389-ds-base-devel-1.3.6.1-13.el7.x86_64 389-ds-base-libs-1.3.6.1-13.el7.x86_64 389-ds-base-1.3.6.1-13.el7.x86_64
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-2017:2086