Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

LDAP Administration Guide
Previous Page Home Next Page

C.2. Other Errors

C.2.1. ber_get_next on fd X failed errno=34 (Numerical result out of range)

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).

C.2.2. ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)

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.

C.2.3. daemon: socket() failed errno=97 (Address family not supported)

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.

C.2.4. GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;

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]

C.2.5. access from unknown denied

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.

C.2.6. ldap_read: want=# error=Resource temporarily unavailable

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.

C.2.7. `make test' fails

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]

C.2.8. ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed

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]

C.2.9. ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

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.

      • Le Trung Kien

________________
© Copyright 2007, OpenLDAP Foundation, [email protected]
LDAP Administration Guide
Previous Page Home Next Page

 
 
  Published under the terms of the OpenLDAP Public License Design by Interspire