ken
2008-Jun-11 14:43 UTC
[Fedora-directory-users] ldapmodify to add OU failed, and led to "ldap_search: Operations error"
ldapmodify to add OU failed, and led to "ldap_search: Operations
error"
I set up a directory and am feeling my way towards making it
live by doing one thing at a time. I successfully added quite a
large number of users using ldapmodify, and could retrieve them
with ldapsearch and db2ldif.
Then I tried to add some new OUs in order to copy a subset of
the OU hierarchy we have on Windows. But when I ran the
ldapmodify it failed.
From that moment on, every ldapsearch I tried resulted in:
ldap_search: Operations error
I stopped and restarted the ldap daemon and now every search I
try produces:
ldap_search: No such object
The database looks as if it is empty
What did I do wrong? Can a botched modify so easily wipe out
what is already there? Or are they secretly hiding somewhere? Is
there a utility that can show me what is actually in the
database even if I don''t know what its root name is? (I thought
db2ldif might do that and it shows nothing now)
I know I can wipe this database entirely (it looks like I
already have!) and re-install. BUT I want to know what I did
wrong so I don''t do it again. The LDIFs to be imported into the
directory will come from a program I wrote (it gathers
information from various sources such as an SQL database, WAD,
/etc/passwd...) and I really don''t want to risk repeating my
mistake in batch runs at 2am after we''ve gone live and coming in
to find no-one can use the directory.
Any clues?
Examples of what I did:
Command used to import LDIF to define an OU
=======================ldapmodify -a -B "dc=bbk,dc=ac,dc=uk" -D
"cn=directory manager"
-w [PWD]
=======================
the LDIF that was used:
=======================dn: ou=students,ou=people,dc=bbk,dc=ac,dc=uk
objectClass: top
objectClass: organizationalunit
ou: students
=======================
Error log from ldapmodify:
=========================================[09/Jun/2008:19:54:47 +0100] - WARNING:
Import is running with
nsslapd-db-private-import-mem on; No other process is
allowed to access the database
[09/Jun/2008:19:54:47 +0100] - Bulk import: begin import on
''dc=bbk,dc=ac,dc=uk''.
[09/Jun/2008:19:54:56 +0100] - import userRoot: WARNING:
Skipping entry "ou=students,ou=people,dc=bbk,dc=ac,dc=uk" which
has no parent, ending at line 0 of file "(bulk import)"
[09/Jun/2008:19:55:05 +0100] - import userRoot: Workers
finished; cleaning up...
[09/Jun/2008:19:55:05 +0100] - import userRoot: Workers cleaned up.
[09/Jun/2008:19:55:05 +0100] - import userRoot: Indexing
complete. Post-processing...
[09/Jun/2008:19:55:05 +0100] - Nothing to do to build ancestorid
index
[09/Jun/2008:19:55:05 +0100] - import userRoot: Flushing caches...
[09/Jun/2008:19:55:05 +0100] - import userRoot: Closing files...
[09/Jun/2008:19:55:05 +0100] - import userRoot: Import complete.
Processed 1 entries (1 were skipped) in 18 seconds. (0.06
entries/sec)
[09/Jun/2008:19:55:05 +0100] - Bulk import completed successfully.
=========================================
There was no error message on the screen, but the log says the
object "has no parent". Though as far as I can tell it has the
same parent as the user entries I added successfully, such as:
=======================# ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' -D
"cn=directory manager"
-w [PWD] ''(objectclass=person)''
version: 1
dn: cn=xlean99,ou=people,dc=bbk,dc=ac,dc=uk
cn: xlean99
description: A mythical person to test LDAP with
objectClass: person
objectClass: top
sn: Lean
=======================
Which was in there but is no longer.
But now I see things like:
=======================[ken@~]$ /usr/lib/mozldap/ldapsearch -b
''dc=bbk,dc=ac,dc=uk'' -D
"cn=uxxxxxx" ''(cn=uxxxxxx)''
ldap_search: No such object
[ken@~]$ ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' -D
"cn=directory
manager" -w [PWD] ''(objectclass=person)''
ldap_search: No such object
[ken@~]$ ldapsearch -b ''dc=bbk,dc=ac,dc=uk''
''(objectclass=*)''
ldap_search: No such object
=======================
And most worryingly of all:
=======================[ken@~]$ ldapsearch -b "" -s base -D
"cn=directory manager" -w
[PWD] ''(objectclass=*)'' namingContext
version: 1
dn:
[ken@~]$
=======================
:-(
It''s not a permissions problem because this works:
=======================ldapsearch -b o=netscaperoot "objectclass=*" cn
=======================
This also still works:
=======================[]# /usr/lib/dirsrv/slapd-ldap1/db2ldif -n NetscapeRoot
-a
/tmp/stuff2.ldif
Exported ldif file: /tmp/stuff2.ldif
ldiffile: /tmp/stuff2.ldif
[11/Jun/2008:14:03:47 +0100] - export NetscapeRoot: Processed 95
entries (100%).
[11/Jun/2008:14:03:47 +0100] - All database threads now stopped
=======================
But this produces nothing:
=======================[]# /usr/lib/dirsrv/slapd-ldap1/db2ldif -n UserRoot -a
/tmp/stuffU.ldif
Exported ldif file: /tmp/stuffU.ldif
ldiffile: /tmp/stuffU.ldif
[11/Jun/2008:14:38:23 +0100] - All database threads now stopped
[]# more /tmp/stuffU.ldif
version: 1
========================
Rich Megginson
2008-Jun-11 18:06 UTC
Re: [Fedora-directory-users] ldapmodify to add OU failed, and led to "ldap_search: Operations error"
ken wrote:> ldapmodify to add OU failed, and led to "ldap_search: Operations error" > > I set up a directory and am feeling my way towards making it live by > doing one thing at a time. I successfully added quite a large number > of users using ldapmodify, and could retrieve them with ldapsearch and > db2ldif. > > Then I tried to add some new OUs in order to copy a subset of the OU > hierarchy we have on Windows. But when I ran the ldapmodify it failed. > > From that moment on, every ldapsearch I tried resulted in: > ldap_search: Operations error > > I stopped and restarted the ldap daemon and now every search I try > produces: > ldap_search: No such object > > The database looks as if it is empty > > What did I do wrong? Can a botched modify so easily wipe out what is > already there? Or are they secretly hiding somewhere? Is there a > utility that can show me what is actually in the database even if I > don''t know what its root name is? (I thought db2ldif might do that and > it shows nothing now) > > I know I can wipe this database entirely (it looks like I already > have!) and re-install. BUT I want to know what I did wrong so I don''t > do it again. The LDIFs to be imported into the directory will come > from a program I wrote (it gathers information from various sources > such as an SQL database, WAD, /etc/passwd...) and I really don''t want > to risk repeating my mistake in batch runs at 2am after we''ve gone > live and coming in to find no-one can use the directory. > > > Any clues? > > Examples of what I did: > > Command used to import LDIF to define an OU > > =======================> ldapmodify -a -B "dc=bbk,dc=ac,dc=uk" -D "cn=directory manager" -w > [PWD]Why are you using the -B option here? In mozldap ldapmodify, -B means "bulk online import" which means 1) wipe out the database 2) use the database import code to import the given LDIF> =======================> > the LDIF that was used: > > =======================> dn: ou=students,ou=people,dc=bbk,dc=ac,dc=uk > objectClass: top > objectClass: organizationalunit > ou: students > =======================> > Error log from ldapmodify: > > =========================================> [09/Jun/2008:19:54:47 +0100] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [09/Jun/2008:19:54:47 +0100] - Bulk import: begin import on > ''dc=bbk,dc=ac,dc=uk''. > [09/Jun/2008:19:54:56 +0100] - import userRoot: WARNING: Skipping > entry "ou=students,ou=people,dc=bbk,dc=ac,dc=uk" which has no parent, > ending at line 0 of file "(bulk import)" > [09/Jun/2008:19:55:05 +0100] - import userRoot: Workers finished; > cleaning up... > [09/Jun/2008:19:55:05 +0100] - import userRoot: Workers cleaned up. > [09/Jun/2008:19:55:05 +0100] - import userRoot: Indexing complete. > Post-processing... > [09/Jun/2008:19:55:05 +0100] - Nothing to do to build ancestorid index > [09/Jun/2008:19:55:05 +0100] - import userRoot: Flushing caches... > [09/Jun/2008:19:55:05 +0100] - import userRoot: Closing files... > [09/Jun/2008:19:55:05 +0100] - import userRoot: Import complete. > Processed 1 entries (1 were skipped) in 18 seconds. (0.06 entries/sec) > [09/Jun/2008:19:55:05 +0100] - Bulk import completed successfully. > =========================================> > There was no error message on the screen, but the log says the object > "has no parent". Though as far as I can tell it has the same parent as > the user entries I added successfully, such as: > > =======================> # ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' -D "cn=directory manager" -w > [PWD] ''(objectclass=person)'' > version: 1 > dn: cn=xlean99,ou=people,dc=bbk,dc=ac,dc=uk > cn: xlean99 > description: A mythical person to test LDAP with > objectClass: person > objectClass: top > sn: Lean > =======================> > Which was in there but is no longer. > > But now I see things like: > > =======================> [ken@~]$ /usr/lib/mozldap/ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' -D > "cn=uxxxxxx" ''(cn=uxxxxxx)'' > ldap_search: No such object > > [ken@~]$ ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' -D "cn=directory manager" > -w [PWD] ''(objectclass=person)'' > ldap_search: No such object > > [ken@~]$ ldapsearch -b ''dc=bbk,dc=ac,dc=uk'' ''(objectclass=*)'' > ldap_search: No such object > =======================> > And most worryingly of all: > > =======================> [ken@~]$ ldapsearch -b "" -s base -D "cn=directory manager" -w [PWD] > ''(objectclass=*)'' namingContext > version: 1 > dn: > [ken@~]$ > =======================> > :-( > > It''s not a permissions problem because this works: > > =======================> ldapsearch -b o=netscaperoot "objectclass=*" cn > =======================> > This also still works: > > =======================> []# /usr/lib/dirsrv/slapd-ldap1/db2ldif -n NetscapeRoot -a > /tmp/stuff2.ldif > Exported ldif file: /tmp/stuff2.ldif > ldiffile: /tmp/stuff2.ldif > [11/Jun/2008:14:03:47 +0100] - export NetscapeRoot: Processed 95 > entries (100%). > [11/Jun/2008:14:03:47 +0100] - All database threads now stopped > =======================> > But this produces nothing: > > =======================> []# /usr/lib/dirsrv/slapd-ldap1/db2ldif -n UserRoot -a /tmp/stuffU.ldif > Exported ldif file: /tmp/stuffU.ldif > ldiffile: /tmp/stuffU.ldif > [11/Jun/2008:14:38:23 +0100] - All database threads now stopped > []# more /tmp/stuffU.ldif > version: 1 > =======================> > > > > > > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
ken
2008-Jun-11 18:39 UTC
Re: [Fedora-directory-users] ldapmodify to add OU failed, and led to "ldap_search: Operations error"
Rich Megginson wrote:>> =======================>> ldapmodify -a -B "dc=bbk,dc=ac,dc=uk"> Why are you using the -B option here? In mozldap ldapmodify, -B means > "bulk online import" which means > 1) wipe out the database > 2) use the database import code to import the given LDIFThat''s my error! A simple typo. Probably the result of my habit of cutting and pasting commands from one place to another. One of those things that I didn''t spot in two days of worrying about the command because when I looked at it I must have assumed it said what I intended it to say rather than what it actually said. Thanks!