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

RE: slapadd, No such object (?)



Good day,

Thanks for the reply.  The detail is quite appreciated.

I followed these steps were followed verbatim (except that my DB files are
.gdbm and not *.dbb).  The problem persisted, however.

But, after more troubleshooting, I have discovered that slapd DOES log
something cryptic after this, when the search is performed.

Nov 21 10:24:18 sr2lb slapd[28978]: daemon: conn=0 fd=7 connection from
IP=127.0.0.1:33225 (IP=0.0.0.0:34049) accepted. 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=0 op=0 BIND
dn="CN=MANAGER,O=SHAWTEST,DC=SHAW,DC=CA" method=128 
Nov 21 10:24:18 sr2lb slapd[28978]: <= dn2id could not open dn2id.gdbm 
Nov 21 10:24:18 sr2lb slapd[28978]: <= dn2id could not open dn2id.gdbm 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=0 op=0 RESULT tag=97 err=0 text= 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=0 op=1 SRCH
base="o=Shawtest,dc=shaw,dc=ca" scope=2 filter="(objectClass=*)" 
Nov 21 10:24:18 sr2lb slapd[28978]: <= dn2id could not open dn2id.gdbm 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=0 op=1 RESULT tag=101 err=32 text= 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=0 op=2 UNBIND 
Nov 21 10:24:18 sr2lb slapd[28978]: conn=-1 fd=7 closed

Looking at the actual database files:

# ls /var/lib/ldap/
total 120
drwx------    2 ldap     ldap         4096 Nov 21 10:23 ./
drwxr-xr-x   13 root     root         4096 Nov 15 10:10 ../
-rw-------    1 root     root        14336 Nov 21 10:23 cn.gdbm
-rw-------    1 root     root        13675 Nov 21 10:23 dn2id.gdbm
-rw-------    1 root     root        14830 Nov 21 10:23 id2entry.gdbm
-rw-------    1 root     root        12296 Nov 21 10:23 nextid.gdbm
-rw-------    1 root     root        12628 Nov 21 10:23 objectClass.gdbm
-rw-------    1 root     root        12568 Nov 21 10:23 sn.gdbm
-rw-------    1 root     root        12316 Nov 21 10:23 uid.gdbm
# 

The file dn2id.gdbm does exist.  But, only root can read it- slapd runs as
user "ldap" as set by the RPM.  Since slapadd leaves the permissions as
root, the files are unreadable by slapd.  A quick chown, and everything runs
fine.  Another mystery solved.

I am not sure what can really be done about this to prevent other people
from tripping on this as well, as I'm sure that the LDAP server responses
are RFC-defined and can't really be changed.

Thanks again to everyone who replied.

============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948


-----Original Message-----
From: OpenLDAP Mailing List [mailto:openldap@kogz.com]
Sent: Tuesday, November 20, 2001 5:45 PM
To: Darren Gamble; Peter W; openldap-software@OpenLDAP.org
Subject: RE: slapadd, No such object (?)


I have found that the following works reliably:

1. stop ldap server

Then,

# slapindex -f /path/to/slapd.conf
# slapcat -f /path/to/slapd.conf > foo.ldif

To load back,
# rm /var/ldap/*.dbb (or where your dbm files are)
# slapadd -f /path/to/slapd.conf -c < foo.ldif
# slapindex -f /path/to/slapd.conf

start ldap server

Notice the slapindex and the -c in slapadd.

Kevin

> -----Original Message-----
> From: Darren Gamble [mailto:Darren.Gamble@sjrb.ca]
> Sent: Tuesday, November 20, 2001 3:52 PM
> To: 'Peter W'; openldap-software@OpenLDAP.org
> Subject: RE: slapadd, No such object (?)
> 
> 
> Good day,
> 
> Thanks for your reply.
> 
> I've noticed (and fixed) that, but that was just an attempt 
> to troubleshoot
> the problem.  It doesn't explain the initial problem with 
> importing the data
> exported by slapcat.  I should have included this in the 
> original message;
> sorry.  I'll do this now.
> 
> Is slapadd supposed to be compatible with the files slapcat 
> outputs?  The
> output that slapcat gives me has the higher level objects 
> later in the ldif-
> is this OK?  Do I have to massage the data outputted by slapcat before
> slapadd can use it?  Regardless, if I import this data, I 
> can't query it (it
> imports without errors, though).
> 
> BTW the plain password is just for testing; the "real" 
> programs using it
> will be PHP and will use a CRYPT'ed password.  This just makes testing
> easier.
> 
> Here's the whole ldif.
> 
> 
> 
> dn: uid=dgamble,ou=Users,o=Shawtest,dc=shaw,dc=ca
> objectClass: inetOrgPerson
> objectClass: person
> objectClass: top
> uid: dgamble
> cn: Darren Gamble
> sn: Gamble
> ou: All Users
> ou: Administrators
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116213120Z
> userPassword:: dGVzdHBhc3M=
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116213355Z
> 
> dn: ou=All Users,ou=Users,o=Shawtest,dc=shaw,dc=ca
> objectClass: organizationalUnit
> ou: All Users
> description: All Users
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116205421Z
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116205421Z
> 
> dn: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> objectClass: organizationalRole
> cn: Manager
> description: Directory Manager
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116205421Z
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116205421Z
> 
> dn: ou=Administrators,ou=Users,o=Shawtest,dc=shaw,dc=ca
> objectClass: organizationalUnit
> ou: All Users
> description: All Users
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116205422Z
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116205422Z
> 
> dn: ou=Users,o=Shawtest,dc=shaw,dc=ca
> objectClass: organizationalUnit
> ou: Users
> description: LDAP Users and Groups
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116205421Z
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116205421Z
> 
> dn: o=Shawtest,dc=shaw,dc=ca
> objectClass: organization
> o: Shawtest
> description: Encompassing group for test server
> creatorsName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> createTimestamp: 20011116205421Z
> modifiersName: cn=Manager,o=Shawtest,dc=shaw,dc=ca
> modifyTimestamp: 20011116205421Z
> 
> 
> ============================
> Darren Gamble
> Planner, Regional Services
> Shaw Cablesystems GP
> 630 - 3rd Avenue SW
> Calgary, Alberta, Canada
> T2P 4L4
> (403) 781-4948
> 
> 
> -----Original Message-----
> From: Peter W [mailto:peterw@usa.net]
> Sent: Tuesday, November 20, 2001 2:48 PM
> To: Darren Gamble
> Cc: openldap-software@OpenLDAP.org
> Subject: Re: slapadd, No such object (?)
> 
> 
> On Tue, Nov 20, 2001 at 10:56:46AM -0700, Darren Gamble wrote:
> 
> > suffix          "o=Shawtest,dc=shaw,dc=ca"
> > rootdn          "cn=Manager,o=Shawtest,dc=shaw,dc=ca"
> 
> > === Sample input ldif (shawtest1.ldif)
> > 
> > dn: uid=dgamble,ou=Users,o=Shawtest,dc=shaw,dc=ca
> 
> > === Sample command and output
> > 
> > $ ldapadd -h localhost -f shawtest1.ldif -x -D
> > "cn=Manager,o=Shawtest,dc=shaw,dc=ca" -w "d8bxl3"
> > adding new entry "uid=dgamble,ou=Users,o=Shawtest,dc=shaw,dc=ca"
> > ldap_add: No such object
> 
> Trying to add "uid=dgamble" before adding "ou=Users" is like trying
> to put passengers on a train when all you've done is lay the track.
> All the "higher" obects must exist before an LDAP add operation can
> work. Add your "Users" org unit & try again.
> 
> -Peter
> 
> P.S. I've always preferred "-W" to "-w secret" but that's your call.
> The -w stuff ends up in history files, and also is generally (on most
> platforms) visible to any other user/process running on the 
> same system.
>