OPENLDAP(slapd) starts with the wrong namingContext

[ermurachi]

Hello,

I am using Fedora12. I installed the following packages:
openldap-servers-2.4.19-1.fc12.x86_64
openldap-clients-2.4.19-1.fc12.x86_64
openldap-2.4.19-1.fc12.x86_64
db4-4.7.25-13.fc12.x86_64

My configuration file looks like this:
database bdb
suffix "dc=eurobluelife,dc=ro"
checkpoin 1024 15
rootdn "cn=Manager,dc=eurobluelife,dc=ro"
rootpw secret
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
database monitor
access to *
by * read

I started slapd with service slapd start and it gives me the message
[root@ns1 openldap]# service slapd start
Checking configuration files for slapd: [WARNING]
bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2).
Expect poor performance for suffix "dc=my-domain,dc=com".
config file testing succeeded
Starting slapd: [ OK ]

When i issue the command ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts it returns :

# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=my-domain,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

QUESTION: Why slapd does not start with the naming context from the config file (dc=eurobluelife,dc=ro) ?

In startup script /etc/init.d/slapd I found the folowing line
configfile=/etc/openldap/slapd.conf, wich means it's starting whith config from /etc/openldap/slapd.conf

The /etc/openldap/slapd.conf has the following access permissions
-rw-r-----. 1 root root 4113 2010-01-25 16:36 slapd.conf

slapd started with the folowing args:
[root@ns1 ~]# ps -aux | grep slapd
ldap 6661 0.0 0.1 224208 5532 ? Ssl 16:40 0:00 /usr/sbin/slapd -h ldap:/// -u ldap

Where should I dig, what I'm doing wrong ?

[smr54]

Is it possible that you simply commented out the defaults of my-domain,dc=com and perhaps made some error with the comment? Do a search through slapd.conf for my-domain and make sure it isn't in there, and uncommented somewhere.

Have you added a file with the basic domain information, that is something like

dn: dc=eurobeluelife,dc=ro

and the other goodies?

If that hasn't been added then there's a good chance that the dc=my-company is what's in the database.

See http://home.roadrunner.com/~computertaijutsu/ldap.html for my favorite ldap tutorial.

[ermurachi]

I looked in the /etc/openldap/slapd.conf for errors with the comments.
I'm not using other config files than the /etc/openldap/slapd.conf

I started the slapd with
[root@ns1 ~]# slapd -f /etc/openldap/slapd.conf

the following command confirms me that is working:

ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -h localhost
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=eurobluelife,dc=ro

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I wryly wanted to use a startup script, becouse it's easy.
Is the startup script wrong ?
How could I make it work ?
Maybe additional tests ?

Thanks in advance

[smr54]

Hrrm. Ok, that's a bit peculiar. I'm writing this from CentOS (back when RH still called the startup script ldap rather than slapd).

Looking at the startup script in CentOS, it seems that it should check slapd.conf. I will have to look at Fedora's, but probably won't have time for a few days.

Why don't you, just for fun, put in a really basic ldif file defining your domain. (You might have already done so), and see if that makes a difference?

The startup script is a default init script, at least in CentOS.

[ermurachi]

I solved the issue by deleting the /etc/openldap/slapd.d, it camed with the openldap-servers rpm package
[root@ns1 openldap]# rpm -ql openldap-servers | grep -i slapd.d
/etc/openldap/slapd.d
/usr/lib64/libslapd_db-4.8.so
/usr/sbin/slapd_db_archive
/usr/sbin/slapd_db_checkpoint
/usr/sbin/slapd_db_deadlock
/usr/sbin/slapd_db_dump
/usr/sbin/slapd_db_hotbackup
/usr/sbin/slapd_db_load
/usr/sbin/slapd_db_printlog
/usr/sbin/slapd_db_recover
/usr/sbin/slapd_db_sql
/usr/sbin/slapd_db_stat
/usr/sbin/slapd_db_upgrade
/usr/sbin/slapd_db_verify
/usr/share/man/man5/slapd-dnssrv.5.gz

ThankYou smr54

[smr54]

Thanks for mentioning that. I've never set it up as a server on Fedora, and I suspect that file would have thrown me.


On CentOS, there is no such subdirectory. I imagine it's there in Fedora for a reason, but I have no idea what.

[shadowen]

Thanks for mentioning that. I've never set it up as a server on Fedora, and I suspect that file would have thrown me.


On CentOS, there is no such subdirectory. I imagine it's there in Fedora for a reason, but I have no idea what.

I found out that on Fedora 12 there is a test installed in the startup of slapd, which will nuke any changes that you do in slapd.conf or the like, basically it seems to load the configuration data from /etc/openldap/slapd.d into the ldap, overwriting any changes that you have made.

From /etc/rc.d/init.d/slapd

function start() {
[ -x $slapd ] || exit 5
[ `id -u` -eq 0 ] || exit 4
configtest
# Define a couple of local variables which we'll need. Maybe.
user=ldap
prog=`basename ${slapd}`
harg="$SLAPD_URLS"


The configtest starts if it finds the

function configtest() {
local user= ldapuid= dbdir= file=
# Check for simple-but-common errors.
user=ldap
prog=`basename ${slapd}`
ldapuid=`id -u $user`
# Unaccessible database files.
slaptestflags=""
dbdirs=""
if [ -d $configdir ]; then



Just a pity that it could have saved me several hours, if this either was not the default behaviour. The really bad thing is that this is hard to diagnose, until you start digging through the startup scripts, after having followed dozens of different howto's on the net, of which none mentioned this "debug"/"test" feature.

I can understand the presence of the configtest as a command line option.

However, that it is automatically run every time that the slapd is started seems very odd to me. Especially combined with the fact that the configtest has the side effect of overruling any changes that the user has made, basically making the ldap services non-functional, and exceptionally hard to diagnose. Particularly if your experience with ldap is low - like in my case.

I suspect that this is some kind of debug that wasn't filtered out, at release time.

[smr54]

Thanks for this--adding a link to this thread on my ldap page.

Yes, LDAP documentation is generally pretty bad, and Fedora tends to make changes that break things and if it is documented, it's difficult to find. What's worse is that the CentOS/RH 5.4 to 5.5 upgrade also might have broken LDAP over port 636.

It's often, as in this case, something relatively simple that no one bothered documenting.