Fedora directory users - Jun 2008 - 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
========================

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

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 LDIF
That''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!