[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problems migrating to 2.1
Looks like a bug dealing with the newSuperior == oldSuperior.
Fixed in HEAD. (BTW, I wouldn't rely on all servers be
liberal in allowing newSuperior == oldSuperior. This could
be viewed as a protocol error.)
Kurt
At 10:21 AM 2002-10-23, John Morrissey wrote:
>I'm (attempting) to migrate to 2.1. I'm currently running 2.1.8, but
>I'm seeing a couple problems.
>
>First, modrdn requests don't seem to be working. Here's my ldif:
>
>dn: uid=jwmtest104,ou=branch1,dc=example,dc=com
>changetype: modrdn
>newrdn: uid=jwmtest105
>deleteoldrdn: 1
>newsuperior: ou=branch1,dc=example,dc=com
>
>When I pipe it through ldapmodify, I get:
>
>ldapmodify: rename failed: uid=jwmtest104,ou=branch1,dc=example,dc=com
>ldap_modrdn: No such object (32)
>
>uid=jwmtest104,ou=branch1,dc=example,dc=com exists and I can search for it
>just fine. Here's relevant debug output:
>
>Oct 23 12:51:06 ldap01 slapd[6670]: do_modrdn
>Oct 23 12:51:06 ldap01 slapd[6670]: do_modrdn: dn (uid=jwmtest104,ou=branch1,dc=example,dc=com) newrdn (uid=jwmtest105) newsuperior (ou=branch1,dc=example,dc=com)
>Oct 23 12:51:06 ldap01 slapd[6670]: >>> dnPrettyNormal: <uid=jwmtest104,ou=branch1,dc=example,dc=com>
>Oct 23 12:51:06 ldap01 slapd[6670]: <<< dnPrettyNormal: <uid=jwmtest104,ou=branch1,dc=example,dc=com>, <uid=jwmtest104,ou=branch1,dc=example,dc=com>
>Oct 23 12:51:06 ldap01 slapd[6670]: >>> dnPrettyNormal: <uid=jwmtest105>
>Oct 23 12:51:06 ldap01 slapd[6670]: <<< dnPrettyNormal: <uid=jwmtest105>, <uid=jwmtest105>
>Oct 23 12:51:06 ldap01 slapd[6670]: >>> dnPrettyNormal: <ou=branch1,dc=example,dc=com>
>Oct 23 12:51:06 ldap01 slapd[6670]: <<< dnPrettyNormal: <ou=branch1,dc=example,dc=com>, <ou=branch1,dc=example,dc=com>
>Oct 23 12:51:06 ldap01 slapd[6670]: conn=1 op=1 MODRDN dn="uid=jwmtest104,ou=branch1,dc=example,dc=com"
>Oct 23 12:51:06 ldap01 slapd[6670]: bdb_dn2entry_rw("uid=jwmtest104,ou=branch1,dc=example,dc=com")
>Oct 23 12:51:06 ldap01 slapd[6670]: => bdb_dn2id_matched( "uid=jwmtest104,ou=branch1,dc=example,dc=com" )
>Oct 23 12:51:06 ldap01 slapd[6670]: ====> bdb_cache_find_entry_dn2id("uid=jwmtest104,ou=branch1,dc=example,dc=com"): 100336 (1 tries)
>Oct 23 12:51:06 ldap01 slapd[6670]: ====> bdb_cache_find_entry_id( 100336 ) "uid=jwmtest104,ou=branch1,dc=example,dc=com" (found) (1 tries)
>Oct 23 12:51:06 ldap01 slapd[6670]: ====> bdb_cache_return_entry_r( 100336 ): returned (0)
>Oct 23 12:51:06 ldap01 slapd[6670]: send_ldap_result: conn=1 op=1 p=3
>Oct 23 12:51:06 ldap01 slapd[6670]: send_ldap_result: err=10 matched="" text=""
>Oct 23 12:51:06 ldap01 slapd[6670]: send_ldap_response: msgid=2 tag=109 err=32
>Oct 23 12:51:06 ldap01 slapd[6670]: conn=1 op=1 RESULT tag=109 err=32 text=
>
>This same ldif works fine when fed to a 2.0.25 slapd.
>
>Another (related?) problem I'm seeing involves a modrdn on a different
>entry. At first, this was causing a slapd thread to go into an infinite
>loop, emitting this in its debug output:
>
>Oct 23 12:54:48 ldap01 slapd[6670]: ====> bdb_cache_find_entry_dn2id("ou=branch2,dc=example,dc=com"): 8 (not ready) 4
>
>I db_recovered the database, but now whenever I try to do a modrdn on this
>user, the slapd thread that handles the request starts chewing an entire CPU
>until slapd is restarted. Debug output:
>
>Oct 23 13:15:02 ldap01 slapd[8287]: do_modrdn
>Oct 23 13:15:02 ldap01 slapd[8287]: do_modrdn: dn (uid=mlbauserman,ou=branch2,dc=example,dc=com) newrdn (uid=mbauserman) newsuperior (ou=branch2,dc=example,dc=com)
>Oct 23 13:15:02 ldap01 slapd[8287]: >>> dnPrettyNormal: <uid=mlbauserman,ou=branch2,dc=example,dc=com>
>Oct 23 13:15:02 ldap01 slapd[8287]: <<< dnPrettyNormal: <uid=mlbauserman,ou=branch2,dc=example,dc=com>, <uid=mlbauserman,ou=branch2,dc=example,dc=com>
>Oct 23 13:15:02 ldap01 slapd[8287]: >>> dnPrettyNormal: <uid=mbauserman>
>Oct 23 13:15:02 ldap01 slapd[8287]: <<< dnPrettyNormal: <uid=mbauserman>, <uid=mbauserman>
>Oct 23 13:15:02 ldap01 slapd[8287]: >>> dnPrettyNormal: <ou=branch2,dc=example,dc=com>
>Oct 23 13:15:02 ldap01 slapd[8287]: <<< dnPrettyNormal: <ou=branch2,dc=example,dc=com>, <ou=branch2,dc=example,dc=com>
>Oct 23 13:15:02 ldap01 slapd[8287]: conn=0 op=1 MODRDN dn="uid=mlbauserman,ou=branch2,dc=example,dc=com"
>Oct 23 13:15:02 ldap01 slapd[8287]: bdb_dn2entry_rw("uid=mlbauserman,ou=branch2,dc=example,dc=com")
>Oct 23 13:15:02 ldap01 slapd[8287]: => bdb_dn2id_matched( "uid=mlbauserman,ou=branch2,dc=example,dc=com" )
>
>There is no more debug output after the dn2id match.
>
>Searching for this entry by uid (which is indexed; other uid searches work
>just fine) also sends a slapd thread to 100% cpu utilization.
>
>Any thoughts on this?
>
>thanks,
>john
>--
>John Morrissey _o /\ ---- __o
>jwm@horde.net _-< \_ / \ ---- < \,
>www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__