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