ldapsearch always coming up empty [solved]

[MankyD]

Been trying to follow a few guides to get openldap up and running. Even bought an o'reilly book to try to understand a bit better but nothing seems to work. Can someone smarter than myself help me out?

phpldapadmin is able to login both anonymously and as cn=Manager,dc=office. However, it reports, in the left column:

Code: Select all

dc=office
his base entry does not exist

Here's the command I run right after starting up slapd. According to everything I've read, I should get results.

Code: Select all

#ldapsearch -x -b "dc=office"
# extended LDIF
#
# LDAPv3
# base <dc=dave> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

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

# numResponses: 1

I tried adding this ldif file using slappadd (/tmp/base.lidf):

Code: Select all

dn: dc=office
dc: office
objectClass: dcObject
objectClass: organizationalUnit
ou: the office

Here's what's returned when I enter slapadd -v -l /tmp/base.ldif:

Code: Select all

# slapadd -v -l /tmp/base.ldif
ldbm_back_db_open: database already in use
backend_startup_one: bi_db_open failed! (-1)
slap_startup failed

/etc/ldap.conf (some comments removed)

Code: Select all

 @(#)$Id: ldap.conf,v 2.45 2006/01/13 16:15:34 lukeh Exp $

host 127.0.0.1

base dc=office

# uri ldap://127.0.0.1/
# uri ldaps://127.0.0.1/
# uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator


ldap_version 3

rootbinddn cn=Manager,dc=office

#port 389

# The search scope.
scope sub

/etc/openldap/slapd.conf

Code: Select all

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema

password-hash   {SSHA}

loglevel        296
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

TLSCertificateFile      /etc/ssl/private/ldap.pem
TLSCertificateKeyFile   /etc/openldap/ssl/ldap.pem
TLSCACertificateFile    /etc/ssl/private/ldap.pem

# database      bdb
database        ldbm
suffix          "dc=dave"
rootdn          "cn=Manager,dc=dave"
# checkpoint    32      30 # <kbyte> <min>
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          {SSHA}xxx
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /var/lib/openldap-data
# mode 0600
# Indices to maintain
index   objectClass     eq
index   cn,uid              eq
index   uidNumber       eq
index   gidNumber       eq

access to *
        by users read
        by anonymous read

access to attrs=userPassword,gecos,description,loginShell
        by self write

[ter_roshak]

I would recommend you verify that slapd is shut down before trying the slapadd. What I suspect is happening is that you start slapd, then try to slapadd -- at this point slapadd is trying to access the data files which are currently in use by slapd -- so you get an error.

Beyond that, I would recommend using bdb for your database backend, it has far better recovery and performance when compared to ldbm. ldbm will no longer be supported in version 2.4+ from what I have been hearing on the OpenLDAP lists.

- Josh

[MankyD]

Interesting, I would've sworn slapadd worked online, but that fixed that problem. Thanks.

On the other hand, when I switch to bdb, I get the following error in /var/log/messages:

Code: Select all

Jul 11 21:30:51 myserver slapd[26164]: @(#) $OpenLDAP: slapd 2.3.24 (Jul 11 2006 19:00:13) $   root@myserver:/var/tmp/portage/openldap-2.3.24-r1/work/openldap-2.3.24/servers/slapd
Jul 11 21:30:51 myserver slapd[26165]: bdb_db_open: alock package is unstable
Jul 11 21:30:51 myserver slapd[26165]: backend_startup_one: bi_db_open failed! (-1)
Jul 11 21:30:51 myserver slapd[26165]: slapd stopped.
Jul 11 21:30:51 myserver slapd[26165]: connections_destroy: nothing to destroy.

Any idea? The db directory does appear to populate with a whole bunch of files.

[ter_roshak]

I would verify that the permissions and ownership are set to be owned by ldap:ldap. Then try restart.

- Josh

[MankyD]

You, sir/madame, are my hero.