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
<[email protected]> wrote:
--On Tuesday, September 10, 2019 5:19 PM +0000 Paul Pathiakis
<[email protected]> 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>
