[Fedora-directory-users] ldapmodify to add OU failed, and led to "ldap_search: Operations error"
Rich Megginson
rmeggins at redhat.com
Wed Jun 11 18:06:45 UTC 2008
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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20080611/f61e603a/attachment.bin>
More information about the Fedora-directory-users
mailing list