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 1394000 - dbmon.sh fails if you have nsslapd-require-secure-binds enabled
Summary: dbmon.sh fails if you have nsslapd-require-secure-binds enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-10 19:36 UTC by Brian J. Atkisson
Modified: 2020-09-13 21:54 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-4.el7
Doc Type: Release Note
Doc Text:
The "dbmon.sh" script now uses instance names to connect to Directory Server instances The "dbmon.sh" shell script enables you to monitor the Directory Server database and entry cache usage. With this update, the script no longer uses the "HOST" and "PORT" environment variables. To support secure binds, the script now reads the Directory Server instance name from the "SERVID" environment variable and uses it to retrieve the host name, port, and the information if the server requires a secure connection. For example, to monitor the "slapd-localhost" instance, enter: SERVID=slapd-localhost INCR=1 BINDDN="cn=Directory Manager" BINDPW="password" dbmon.sh
Clone Of:
Environment:
Last Closed: 2017-08-01 21:12:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2124 0 None None None 2020-09-13 21:54:04 UTC
Red Hat Product Errata RHBA-2017:2086 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Brian J. Atkisson 2016-11-10 19:36:31 UTC 
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
Comment 1 Noriko Hosoi 2016-11-10 20:43:38 UTC 
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.
Comment 3 mreynolds 2016-12-07 18:25:52 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/49065
Comment 4 mreynolds 2017-03-21 19:43:58 UTC 
Fixed upstream
Comment 6 Sankar Ramalingam 2017-05-15 16:28:09 UTC 
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!
Comment 7 mreynolds 2017-05-15 17:04:09 UTC 
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
Comment 8 Sankar Ramalingam 2017-05-16 00:10:54 UTC 
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
Comment 9 Sankar Ramalingam 2017-05-16 00:11:57 UTC 
[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
Comment 12 errata-xmlrpc 2017-08-01 21:12:24 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.