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

Re: Problem with slapd-meta

Dominique VOLPE wrote:
I have five branches in my meta directory. I mentioned only one to simplify
the message.

The client begins every search (whatever the search criteria) with this
request :
Oct 29 19:34:22 localhost slapd[2181]: conn=14 op=1 SRCH
base="o=mydomain,c=fr" scope=0 deref=0 filter="(objectClass=*)" Oct 29 19:34:22 localhost slapd[2181]: conn=14 op=1 SRCH attr=objectClass
The problem is in the client, which wants to see the suffix entry. Nothing precludes that entry from existing in at least one of the targets, but to avoid issues you'll want it to exist, or to be looked for, in exactly one. I assume that you're using the latest 2.3 release. In that case, assuming that at least the target "main" contains an entry corresponding to the suffix, what you can do is:

database meta
suffix "o=myorg,c=fr"

# first sub-target
uri "ldap://sub1/ou=sub1,o=myorg,c=fr";
# second sub-target
uri "ldap://sub2/ou=sub2,o=myorg,c=fr";
# add more...

# main target
uri "ldap://main/o=myorg,c=fr";
subtree-exclude "ou=sub1,o=myorg,c=fr"
subtree-exclude "ou=sub2,o=myorg,c=fr"
# add more...

This will cause searches with base "o=myorg,c=fr" to be correctly handled by the "main" target no matter what the scope is, while other, more specific searches are directed to the most appropriate target, excluding the "main" whenever the search base is in the "subtree-exclude". Of course you need to ensure that the contents of the "main" target do not overlap with those of the other targets, but then this is true regardless of the presence of the subtree-exclude directive.

Another way to accomplish this is to add a fake target that handles operations for the suffix naming context, which actually points to a local instance of any database (like bdb) the only contains the entry with the suffix of the meta database. This is a bit more involved, and may add unnecessary overhead.
In a meta drirectory, this cannot works. Accordind to the "man" : The only
operation that may resolve to multiple targets is a search with scope at
least "one", which results in spawning searches to the targets.
That's correct. Your client wants a single entry, the one corresponding to the suffix of the meta database, it's your client's search that's exactly requesting that. Either your client is broken, or it has a good reason to look for that entry. In the first case, there's nothing slapd-meta (and OpenLDAP) can do to help you fixing it. In the latter case, you need to configure slapd-meta to be able to fulfil that request. That's what my above explanation is trying to do.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it