On Sun, Feb 21, 2016 at 10:04:48AM -0500, Dave Beach wrote:
########### # syslog start # ###########
Feb 21 07:47:03 drbgate slapd[1242]: @(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $#012#011root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd Feb 21 07:47:03 drbgate slapd[1242]: daemon: bind(11) failed errno=2 (No such file or directory)
This looks like a Debian bug, actually.
The default pidfile location is /var/run/slapd/slapd.pid, and the init script does "mkdir $(dirname $pidfile)" during startup.
(In case you want to compare, the default template is in /usr/share/slapd/slapd.conf.)
However, your pidfile is set to /var/run/slapd.pid, so probably nothing is creating /var/run/slapd. This is a problem since on modern systems /var/run is a symlink to /run which is a tmpfs...
Would you please report this in the Debian bug tracker?
A workaround to get you going would be to change your pidfile setting to /var/run/slapd/slapd.pid.
No matter in the short term (that problem is down the priority list), I can simply start it manually with slapd -t /etc/ldap/slapd.conf; slapd starts, here's the syslog snippet:
Assuming that's the exact command you actually ran, slapd is now running as root instead of openldap, and that's only going to exacerbate any permissions problems you might have.
To restore sanity, you may want to
chown -R openldap:openldap /var/lib/ldap /etc/ldap/slapd.conf
(and /etc/ldap/slapd.d, if it exists)
and use something more like this for future manual runs of slapd:
slapd -h 'ldap:// ldapi://' -u openldap -g openldap -f /etc/ldap/slapd.conf
password-hash {SMD5}
Hmm, time to upgrade to a more secure hash... Current default is SSHA and there are even better possibilities in some contrib modules (the sha2 module is included in the Debian package).
############################ # bdb database definitions # ############################
database bdb
And time to upgrade to MDB backend as well, but obviously with lower priority, after the current fire has been put out. :)
rootpw {SMD5}jucQ+foqlF7O/VLmLllThlYH5zY=
FTR, putting the plaintext password there works as well - not recommended for production, of course, but helpful for ruling things out during testing.
I take from this response ("no such object") that it could not find the entry.
Where am I going wrong?
I don't see anything obviously wrong with the above.
I assume you've ensured that the parent entry dc=drbhome,dc=ca exists.
I have no evidence that indexing is your problem, but in an odd situation like yours, I might re-index just to rule that out:
sudo -u openldap slapindex -f /etc/ldap/slapd.conf -q