Hi Quanah/all, Well, once I used the suggestions below, everything loaded and went fine. As part of my documentation and verification process: systemctl stop slapd rm -rf /etc/openldap/slapd.d/* /var/lib/ldap/* and redo the whole process...... I gives me an invalid credentials issue now when I try to load the memberof.ldif file. However, trying to re-load all the information via below and the correct cn=root works just fine. I went through my history, I haven't changed anything yet I'm getting invalid credentials. Now... here's some relevant information about this... and YES I KNOW IT SHOULD NOT MAKE A DIFFERENCE It's a VM. I'm logged in via SSH and I'm also on the console. I think this has something to do with the effective versus real UID, GID. I ssh via an unprivilege'd user and su to root with: su - (I'm old pre-sudo) I get invalid credentials.... I got thoroughly flustered. Without changing anything except the slapd running: slapd -d -1 (in the SSH window) I go to the root window on the VM console. I run the same command and it loads fine! Same password etc. Just wow... everything is running fine. *shrug* Just an fyi. P.
On Tuesday, September 10, 2019, 2:29:36 PM EDT, Quanah Gibson-Mount quanah@symas.com wrote:
--On Tuesday, September 10, 2019 5:19 PM +0000 Paul Pathiakis pathiaki2@yahoo.com wrote:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth"
"cn=root,dc=hq,dc=example,dc=com"
rootdn "cn=root,dc=hq,dc=example,dc=com" rootpw {SSHA}7gMfpdvYlzgd4EmH3VbBCUsMHugjozU+
So you have two methods of accessing the rootdn for this database. Either using SASL/EXTERNAL as root, or via -D/-W combination, with whatever password you hashed to create the above SSHA hash. Only you would know what that password is.
loglevel -1
-1 is a debug level, not a log level. See the slapd.conf(5) man page for valid log levels.
I copied /usr/share/doc/openldap/DB_CONFIG.EXAMPLE /var/lib/ldap/DB_CONFIG
DB_CONFIG only applies to back-bdb and back-hdb databases. You are using back-mdb, so it does nothing.
ldapadd -f /etc/openldap/20160826-163635.ldif -v -D "cn=config" -H ldap://newldap.hq.example.com -W -c
cn=config doesn't have access to the binary database, so this is expected. Use the correct rootdn (cn=root,dc=hq,dc=example,dc=com).
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com