[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapadd and initial loading of ldap



Wow! That did it! You have no idea how long I tried and re-tried that slapadd command! And it turned out to be an ownership issue. Thank you!

--Steve


Rigler, Steve wrote:

Stephen,

It sounds like a simple gotcha.

If you run slapadd as root, then the files it creates will be owned
by root (and if slapd runs as "ldap" then it won't be able to access
the database).

Check your ownership on the files in /var/lib/ldap.  Chown ldap:ldap
if they are owned by root.

-Steve

-----Original Message-----
From: Stephen Lorenz [mailto:slorenz@mco.mass.edu]
Sent: Tuesday, July 08, 2003 9:28 AM
To: openldap-software@OpenLDAP.org
Subject: slapadd and initial loading of ldap


I am running into a problem loading the LDAP using the slapadd command. I'm sure it's something that I am doing wrong but I am pulling out my hair try to fiugre out what it is. I have looked in the list archives and there is some mention of similar issues but none of the threads list a solution to the problem.


I am planning on using OpenLDAP on a Redhat 9.0 box for PAM authentication. I trying to load the following base.ldif file:

dn: dc=mco,dc=mass,dc=edu
dc: mco
objectClass: top
objectClass: domain

dn: ou=People,dc=mco,dc=mass,dc=edu
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=mco,dc=mass,dc=edu
ou: Group
objectClass: top
objectClass: organizationalUnit

Using the "/usr/sbin/slapadd -l base.ldif -f /etc/openldap/slapd.conf -v -b 'dc=mco,dc=mass,dc=edu'" command. The command runs with the following results:

added: "dc=mco,dc=mass,dc=edu" (00000001)
added: "ou=People,dc=mco,dc=mass,dc=edu" (00000002)
added: "ou=Group,dc=mco,dc=mass,dc=edu" (00000003)

Then I start the ldap server and proceed to do a simple test search, "ldapsearch -b 'dc=mco,dc=mass,dc=edu' 'objectclass=*' -vxw <passwd>" and I receive the following results:

ldap_initialize( <DEFAULT> )
filter: objectclass=*
requesting: ALL
version: 2

#
# filter: objectclass=*
# requesting: ALL
#

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

# numResponses: 1

What am I doing wrong? It's got to be something simple that I'm just missing!

I am tacking the slapd.conf file to tail end of this message with the hope that this message is more readable.

Thanks,
Steve

===================================================================
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27 20:00:31 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/redhat/rfc822-MailMember.schema
include /etc/openldap/schema/redhat/autofs.schema
include /etc/openldap/schema/redhat/kerberosobject.schema


# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

#pidfile        //var/run/slapd.pid
#argsfile       //var/run/slapd.args

# Create a replication log in /var/lib/ldap for use by slurpd.
#replogfile     /var/lib/ldap/master-slapd.replog

# Load dynamic backend modules:
# modulepath    /usr/sbin/openldap
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la
# moduleload    back_shell.la

#
# The next three lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
# TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
#
# Sample Access Control
#       Allow read access of root DSE
#       Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
#
#access to dn="" by * read
#access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default is:
#       Allow read by all
#
# rootdn can always write!

#######################################################################
# ldbm database definitions
#######################################################################

database        ldbm
suffix          "dc=mco,dc=mass,dc=edu"
rootdn          "cn=Directory Manager,dc=mco,dc=mass,dc=edu"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          <passwd>
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory       /var/lib/ldap
# Indices to maintain
index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
index   cn,mail,surname,givenname                       eq,subinitial
# Replicas to which we should propagate changes
#replica host=ldap-1.example.com:389 tls=yes
#       bindmethod=sasl saslmech=GSSAPI
#       authcId=host/ldap-master.example.com@EXAMPLE.COM