[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#4133) Database with more than 1 subordination level doesn't work



Full_Name: Dmitriy Stepanenko
Version: 2.2.x, 2.3.11
OS: Fedora Core 3, Windows XP
URL: ftp://ftp.openldap.org/incoming/Dmitriy-Stepanenko-051101.zip
Submission from: (NULL) (193.110.112.210)


When trying to create and use a distributed OpenLDAP database with more than one
subordination level I've encountered a problem that looks very mauch like an
OpenLDAP bug. Here is a description.

I try to create an OpenLDAP database with more than one level of subordination.
It should look like this (the picture is somewhat simplified by not showing some
unrelated details like other branches):

dc=kt-privat,dc=donetsk,dc=ua    - the topmost level
dc=druzh,dc=kt-privat,dc=donetsk,dc=ua    - the next level, stored in
its own database
dc=7micro,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua    - one more level,
also with its own database

I want to have an OpenLDAP server on each level. Or, to be more precise, I want
to have 3 servers, each holding databases for all three levels, but the first
server should be responsible for the topmost level master replica, the second
one - for the master replica of the second level and so on. Each server should
replicate the hanges in its corresponding master replica to all other ones.

All this worked as long as there where only two levels. Two-level configuration
now works without any problems in my "real-life" environment. Moreover, nothing
bad happened when I've tried to add the third level (dc=7micro,...) to OpenLDAP
2.1.xxx server (I don't remember the minor release number). But when I've tried
the same thing on the OpenLDAP 2.2.13 server, I've got a problem.

No matter, have I simply copied the DB hierarchy from OpenLDAP 2.1.x machine to
2.2.13 or dumped it with "slapcat" and then recreated in the new location with
slapadd, the picture was the same. Slapd starts successfully, but when I try to
browse the second level of the tree (druzh) with any LDAP browser I receive
search errors. For examle, JXplorer (a free Java-based LDAP browser) says the
following: "javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such
Object]; remaining name 'dc=druzh,dc=kt-privat,dc=donetsk,dc=ua'".

At the same time the following messages can be seen in the server debug log:

Nov  1 15:48:33 trojanda slapd[6908]: conn=3 op=9 SRCH
base="dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" scope=1 deref=2
filter="(objectClass=*)" 
Nov  1 15:48:33 trojanda slapd[6908]: slap_global_control: unavailable control:
2.16.840.1.113730.3.4.2 
Nov  1 15:48:33 trojanda slapd[6908]: ==> limits_get: conn=3 op=9
dn="cn=manager,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" 
Nov  1 15:48:33 trojanda slapd[6908]: => bdb_search 
Nov  1 15:48:33 trojanda slapd[6908]:
bdb_dn2entry("dc=7micro,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua") 
Nov  1 15:48:33 trojanda slapd[6908]: =>
bdb_dn2id("dc=7micro,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua") 
Nov  1 15:48:33 trojanda slapd[6908]: <= bdb_dn2id: get failed: DB_NOTFOUND: No
matching key/data pair found (-30990) 
Nov  1 15:48:33 trojanda slapd[6908]: send_ldap_result: conn=3 op=9 p=3 
Nov  1 15:48:33 trojanda slapd[6908]: send_ldap_result: err=10 matched=""
text="" 
Nov  1 15:48:33 trojanda slapd[6908]: send_ldap_result: conn=3 op=9 p=3 
Nov  1 15:48:33 trojanda slapd[6908]: send_ldap_result: err=32 matched=""
text="" 
Nov  1 15:48:33 trojanda slapd[6908]: send_ldap_response: msgid=10 tag=101
err=32 
Nov  1 15:48:33 trojanda slapd[6908]: conn=3 op=9 SEARCH RESULT tag=101 err=32
nentries=0 text= 

The same problem can be reproduced both with LDBM and BDB backends (I was
advised to migrate from LDBM, which I originally used to BDB, as more native for
modern OpenLDAP alternative). It also reproduces with various 2.2.x versions and
2.3.11; under Fedora Core 3 and Windows XP (with Symas CDS distribution). But it
does not exist in OpenLDAP 2.1.x.

I have uploaded a zip-archive with the above excerpt from syslog, my
(experimental) slapd.conf and a full ldif-snapshot of the database that exposes
this problem (in the file Dmitriy-Stepanenko-051101.zip)