Description of problem: 389-ds-base and 389-admin are using the old format of cert db. NSS recommends to switch to the sql format having the shared DB feature. There are patches for this, but they are over a year old: https://pagure.io/389-ds-base/issue/48760 Version-Release number of selected component (if applicable): F27 (rhel 7.5)
I've been using SQL db for a while, I think we are ready to go.
The bugzilla can't be verified because when we use 'sql' database for NSS, suites/sasl/plain_test.py fails. Also, as per discussion with William, the following reproduction steps were used: Reproduction steps: 1. Enable test debug mode: # export DEBUGGING=on 2. Set NSS database explicitly to 'sql' # export NSS_DEFAULT_DB_TYPE=sql 3. Run test suite for plain SASL: # py.test -s -v dirsrvtests/tests/suites/sasl/plain_test.py It should pass but it fails with the following error during conn = standalone.openConnection(saslmethod='PLAIN', sasltoken=auth_tokens, starttls=True, connOnly=True, certdir=standalone.get_cert_dir(), reqcert=ldap.OPT_X_TLS_NEVER) In open() and then in start_tls_s() part: E ldap.PROTOCOL_ERROR: {'desc': 'Protocol error', 'info': 'unsupported extended operation'} 4. While the instance is stopped, remove cert8.db, key3.db and secmod.db files from /etc/dirsrv/slapd-inst 5. Start the instance. 6. Check /var/log/dirsrv/slapd-inst/errors. Server should use cert9.db and key4.db and enable SSL. Actual results: [23/Nov/2017:10:10:58.244817243 -0500] - ERR - Security Initialization - slapd_ssl_init - Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.) [23/Nov/2017:10:10:58.245344666 -0500] - ERR - force_to_disable_security - ERROR: SSL Initialization Failed. Disabling SSL. Expected results: SSL is successfully enabled
https://pagure.io/389-ds-base/issue/48760 Is still open and assigned to me. I will investigate.
This actually works, if you add NSS_DEFAULT_DB_TYPE=sql to /etc/sysconfig/dirsrv.
(In reply to Viktor Ashirov from comment #8) > This actually works, if you add NSS_DEFAULT_DB_TYPE=sql to > /etc/sysconfig/dirsrv. Great! Turning this bug into a doc bug. So somewhere in section 9.3 of the admin guide, we need to mention that if you want to use a SQL database for NSS you must set NSS_DEFAULT_DB_TYPE=sql in /etc/sysconfig/dirsrv.