This slapd error generally indicates that the client sent a message that exceeded an administrative limit. See sockbuf_max_incoming and sockbuf_max_incoming_auth configuration directives in slapd.conf(5).
This message is not indicative of abnormal behavior or error. It simply means that expected data is not yet available from the resource, in this context, a network socket. slapd(8) will process the data once it does becomes available.
This message indicates that the operating system does not support one of the (protocol) address families which slapd(8) was configured to support. Most commonly, this occurs when slapd(8) was configured to support IPv6 yet the operating system kernel wasn't. In such cases, the message can be ignored.
This message means that slapd is not running as root and, thus, it cannot get its Kerberos 5 key from the keytab, usually file /etc/krb5.keytab.
A keytab file is used to store keys that are to be used by services or daemons that are started at boot time. It is very important that these secrets are kept beyond reach of intruders.
That's why the default keytab file is owned by root and protected from being read by others. Do not mess with these permissions, build a different keytab file for slapd instead.
To do this, start kadmin, and enter the following commands:
Then, on the shell, do:
- chown ldap.ldap /etc/openldap/ldap.keytab
- chmod 600 /etc/openldap/ldap.keytab
Now you have to tell slapd (well, actually tell the gssapi library in Kerberos 5 that is invoked by Cyrus SASL) where to find the new keytab. You do this by setting the environment variable KRB5_KTNAME like this:
export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
Set that environment variable on the slapd start script (Red Hat users might find /etc/sysconfig/ldap a perfect place). [email protected], [email protected] This only works if you are using MIT kerberos. It doesn't work with Heimdal, for instance. [email protected] In Heimdal there is a function gsskrb5_register_acceptor_identity() that sets the path of the keytab file you want to use. In Cyrus SASL 2 you can add
keytab: /path/to/file
to your application's SASL config file to use this feature. This only works with Heimdal. [email protected]
This related to TCP wrappers. See hosts_access(5) for more information. in the log file: "access from unknown denied" This related to TCP wrappers. See hosts_access(5) for more information. for example: add the line "slapd: .hosts.you.want.to.allow" in /etc/hosts.allow to get rid of the error.
This message occurs normally. It means that pending data is not yet available from the resource, a network socket. slapd(8) will process the data once it becomes available.
Some times, `make test' fails at the very first test with an obscure message like
make test make[1]: Entering directory `/ldap_files/openldap-2.2.13/tests' make[2]: Entering directory `/ldap_files/openldap-2.2.13/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all...
>>>> Executing all LDAP tests for bdb
>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start...
/scripts/test000-rootdse: line 40: 10607 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start...
/scripts/test000-rootdse: kill: (10607) - No such pid ldap_bind: Can't contact LDAP server (-1)
>>>> Test failed
>>>> ./scripts/test000-rootdse failed (exit 1) make[2]: *** [bdb-yes] Error 1 make[2]: Leaving directory `/ldap_files/openldap-2.2.13/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/ldap_files/openldap-2.2.13/tests' make: *** [test] Error 2
or so. Usually, the five lines
Waiting 5 seconds for slapd to start...
indicate that slapd didn't start at all.
For OpenLDAP 2.2 and later, in tests/testrun/slapd.1.log there is a full log of what slapd wrote while trying to start. The log level can be increased by setting the environment variable SLAPD_DEBUG to the corresponding value; see loglevel in slapd.conf(5) for the meaning of log levels.
A typical reason for this behavior is a runtime link problem, i.e. slapd cannot find some dynamic libraries it was linked against. Try running ldd(1) on slapd (for those architectures that support runtime linking).
There might well be other reasons; the contents of the log file should help clarifying them.
Tests that fire up multiple instances of slapd typically log to tests/testrun/slapd.<n>.log, with a distinct <n> for each instance of slapd; list tests/testrun/ for possible values of <n>. [email protected]
This seems to be related with wrong ownership of the BDB's dir (/var/lib/ldap) and files. chmod -r openldap:openldap /var/lib/ldap fixes it in Debian Etch. I don't really know how the wrong permission went into place, but I suspect it has something to do with slapd's starting, no database existing (I had deleted it to get a new, fresh one), and slapd creating one before chroot. After a bug report, some insightful feedback, and some amount of testing, i found out that the 'wrong ownership of new files' problem is not with slapd but with slapadd. This happens when one initially populates the Directory. Oh, and the right switch of chown is '-R', not '-r'. My God! What a mess! The right command to correct this problem is: chown -R /var/lib/ldap
[email protected]
Using SASL, when a client contacts LDAP server, the slapd service dies immediately and client gets an error : SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Then check the slapd service, it stopped. This may come from incompatible of using different versions of BerkeleyDB for installing of SASL and installing of OpenLDAP. The problem arises in case of using multiple version of BerkeleyDB. Solution: - Check which version of BerkeleyDB when install Cyrus SASL. - Reinstall OpenLDAP with the version of BerkeleyDB above. It was my case and that was the solution I did and it worked :) Hope this gives you some information.
