It is unlikely your installation uses slapd.conf at all. Modern OpenLDAP installations have long since abandoned that deprecated method of configuration.

Understood. I'm using slapd.conf until I get things working again, at which point I can decide if I want to convert to cn=config. Slapd is starting with -f /etc/ldap/slapf.conf.

I did exactly the same until I had my head wrapped around all the details of openldap. I then converted everything to the cn=config method quite easily after that.

Anyway, if you provide the details mentioned before, we should be able to figure out where the problem is coming in.

What I'm *really* trying to do is get Samba working again. There's a long-ish story, involving me backing up an old server and trying to get services running again on a new server, without having backed up Samba and its backend password database the "proper" way. The Samba passdb is ldap.

Samba is throwing ldap-related errors, so the focus at the moment is to satisfy myself that ldap is working before I turn my attention again to Samba.

It is significant to note that both Samba and ldap are running on the same box; there is no reference to any service running on any other computer.

For some reason, slapd will not start properly from init.d; I suspect a permissions problem on /var/lib/ldap or something.

Here's the syslog snippet for that failed start:

########### # 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) Feb 21 07:47:03 drbgate slapd[1242]: slapd stopped. Feb 21 07:47:03 drbgate slapd[1242]: connections_destroy: nothing to destroy. Feb 21 07:47:03 drbgate slapd[1158]: Starting OpenLDAP: slapd failed! Feb 21 07:47:03 drbgate systemd[1]: slapd.service: control process exited, code=exited status=1 Feb 21 07:47:03 drbgate systemd[1]: Unit slapd.service entered failed state.

########### # syslog end # ###########

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:

########### # syslog start # ###########

Feb 21 07:51:27 drbgate slapd[2146]: @(#) $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:51:28 drbgate slapd[2147]: slapd starting

########### # syslog end # ###########

Here's /etc/ldap/slapd.conf

####################### # OpenLDAP slapd.conf # ####################### # include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema

pidfile /var/run/slapd.pid loglevel 256 password-hash {SMD5}

# Load dynamic backend modules: modulepath /usr/lib/ldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_passwd.la moduleload back_shell.la

############################ # bdb database definitions # ############################

database bdb suffix dc=drbhome,dc=ca

rootdn "cn=admin,dc=drbhome,dc=ca" rootpw {SMD5}jucQ+foqlF7O/VLmLllThlYH5zY=

directory /var/lib/ldap

index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq

############## # end slapd.conf # ##############

So, now to use ldapsearch to see if I can successfully query the database. Running slapcat shows me my Samba backend passdb info; here's one entry from the slapcat output that Samba is looking for:

#################### # slapcat output snippet # ####################

dn: sambaDomainName=DRBHOME,dc=drbhome,dc=ca structuralObjectClass: sambaDomain entryUUID: b55dd658-8373-102b-926b-934392865679 creatorsName: cn=Manager,dc=drbhome,dc=ca createTimestamp: 20070420101446Z gidNumber: 1000 sambaDomainName: DRBHOME sambaSID: S-1-5-21-379225270-2612589903-3976116126 objectClass: top objectClass: sambaDomain objectClass: sambaUnixIdPool sambaMaxPwdAge: -1 sambaRefuseMachinePwdChange: 0 sambaMinPwdAge: 0 sambaLockoutThreshold: 0 sambaMinPwdLength: 5 sambaLogonToChgPwd: 0 sambaForceLogoff: -1 sambaNextRid: 1010 uidNumber: 1017 sambaPwdHistoryLength: 0 entryCSN: 20160210051916Z#000000#00#000000 modifiersName: cn=Manager,dc=drbhome,dc=ca modifyTimestamp: 20160210051916Z

####################### # end slapcat output snippet # #######################

One obvious observation from this output is that it refers to cn=Manager and not cn=admin. Manager was the rootdn of the previous installation, whereas admin is the rootdn of the current installation. I don't know if that means anything in terms of my current problems, but I tend to doubt it. I don't get authentication errors now using cn=admin, so I'm presuming the references to Manager in the snippet above are informational only and not significant.

So, I believe this demonstrates that the entry is there to be found. I'm trying to check that ldap is working by using ldapsearch to search for the information in that slapcat snippet above. Here's the command line I'm using:

ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -b "dc=drbhome,dc=ca" -s sub "(&(objectClass=sambaDomain)(sambaDomainName=DRBHOME))" sambaDomainName

I get prompted for the password, for which I enter the cleartext password that generated the hash found in my slapd.conf as shown above.

The result is:

################ # ldapsearch result # ################

# extended LDIF # # LDAPv3 # base <dc=drbhome,dc=ca> with scope subtree # filter: (&(objectClass=sambaDomain)(sambaDomainName=DRBHOME)) # requesting: sambaDomainName #

# search result search: 2 result: 32 No such object

# numResponses: 1

################### # end ldapsearch result # ###################

I take from this response ("no such object") that it could not find the entry.

Where am I going wrong?

You have to find the cause for the errno=2 (No such file or directory) to make slapd even start.

Yes, thanks. I think my original message acknowledged that. Regardless, I can start it manually with no error, as the rest of my original message stated. I do not believe the startup problem is related to the problem I'm currently trying to solve, but I acknowledged in my original message that at some point I have to go back and solve the startup problem.

The default pidfile location is /var/run/slapd/slapd.pid, and the init

script does "mkdir $(dirname $pidfile)" during startup.

There is no /var/run/slapd...

However, your pidfile is set to /var/run/slapd.pid, so probably nothing is

creating /var/run/slapd.

Aha.

A workaround to get you going would be to change your pidfile setting to

/var/run/slapd/slapd.pid.

Done.

To restore sanity, you may want to

chown -R openldap:openldap /var/lib/ldap /etc/ldap/slapd.conf

Done.

(and /etc/ldap/slapd.d, if it exists)

It does not (I've renamed it for the moment as a means of forcing the init script to use slapd.conf, as it won't if /etc/ldap/slapd.d exists)

Ok. A quick test to see if that solves some of the problem.

Good news, slapd is now starting properly without manual intervention, and var/run/slapd/slapd.pid exists. Much rejoicing throughout the kingdom.

...

database bdb

And time to upgrade to MDB backend as well, but obviously with lower

priority, after the current fire has been put out. :)

Perhaps - I kept bdb because I'm working with older bdb databases; at some point I'll have to figure out how to convert.

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

Hmm. The result of which is:

56c9ff8f bdb_db_open: database "dc=drbhome,dc=ca": database already in use. 56c9ff8f backend_startup_one (type=bdb, suffix="dc=drbhome,dc=ca"): bi_db_open failed! (-1) slap_startup failed

Stop slapd before running slapindex.

Sigh. Early morning. Ok, done.

Now, re-running the ldapsearch command-line:

ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -b "dc=drbhome,dc=ca" -s sub "(&(objectClass=sambaDomain)(sambaDomainName=DRBHOME))" sambaDomainName

Same result as before:

# extended LDIF # # LDAPv3 # base <dc=drbhome,dc=ca> with scope subtree # filter: (&(objectClass=sambaDomain)(sambaDomainName=DRBHOME)) # requesting: sambaDomainName #

# search result search: 2 result: 32 No such object

# numResponses: 1

OK, some sanity checks: ensure the parent entry exists and has expected contents: ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -s base -b 'dc=drbhome,dc=ca'

'*' +

("'*' +" is asking for all attributes including operational ones; then the

output will be closer to what you see from slapcat)

Result: 34 Invalid DN syntax Text: invalid DN

ensure the samba domain entry exists and has expected contents: ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -s base -b

'sambaDomainName=DRBHOME,dc=drbhome,dc=ca' '*' +

Same result.

try each part of the filter separately: ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -s sub -b 'dc=drbhome,dc=ca'

'(objectClass=sambaDomain)'

Result: 32 No such object

ldapsearch -D cn=admin,dc=drbhome,dc=ca -W -s sub -b 'dc=drbhome,dc=ca'

'(sambaDomainName=DRBHOME)'

Result: 32 No such object

All of which is reminding me of something I was thinking of earlier: is it somehow possible that slapcat is able to read the entries (which it does), but ldapsearch is not because it's reading something OTHER THAN the same database slapcat is querying?

slapd -f /etc/ldap/slapd.conf [other args ...] and slapcat -f /etc/ldap/slapd.conf [other args e.g. -b 'dc=drbhome,dc=ca'] should be operating on the same data.

I have been executing slapcat all by its lonesome on the command line, and it gives me lovely, lovely output. No arguments at all. That was the basis for my presumption that all the database info is where it's supposed to be.

When you moved the LDAP database from the old machine to this one, you did

that via slapcat/slapadd, right? Did you empty out /var/lib/ldap (except for DB_CONFIG) before slapadd?

Uh, er (stares at his shoes), no. And, no.

I *do* have all the files from the previous server (cp'd from the root recursively to an external USB HD), and I figured I'd just need to copy them to the appropriate directories and fiddle with a few config files. I figured since I could successfully see what looked like the right data when I executed slapcat that all was reasonably well with the world and I'd just need to solve an ldap problem or two.

I do still have the original system drive from that old server (it's the same computer, old and new, just new hard disks and a much newer Linux distro installed). I could, in a pinch I suppose, open it back up, put the old system drive in, boot to the old server, and do the ldap/Samba migration the "proper" way, but is there no alternative?