Dominique VOLPE wrote:

Hi,

I try to install a meta directory.

My slapd.conf looks like that :

database meta suffix "o=mydomain,c=fr" rootdn "cn=Manager,o=mydomain,c=fr" rootpw secret lastmod off

uri "ldap://xxxxx/ou=persons,o=mydomain,c=fr" suffixmassage "ou=persons,o=mydomain,c=fr" "ou=org1,o=mydomain,c=fr"

When I search an address whith my email client, I can see in the log :

conn=5 op=1 SRCH base="o=mydomain,c=fr" scope=0 deref=0 filter="(objectClass=*)" conn=5 op=1 SRCH attr=objectClass daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL request 1 done conn=5 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=

It tries to list all objectclasses, but it uses the scope "base" (scope=0) instead of "sub" (scope=2). Thus, it produces an error.

Has anybody already met this problem and did find a solution?

I think I could do it with rewrite rules, but I didn't find how to substitute the scope.

The scope of a search is automatically handled by slapd-meta to deal with matching the request with what the targets are supposed to handle, there's no way you can explicitly modify the scope of asearch. However, your issue occurs well before any rewriting takes place.

In your slapd.conf you configure the meta database so that it can handle requests in the "o=mydomain,c=fr" naming context; then, you configure the only target in a manner that it can only deal with requests in the "ou=persons,o=mydomain,c=fr" branch of that naming context. As the client searches for "o=mydomain,c=fr" with a scope of "base", it means that the client really wants only that very entry, which your meta database can't answer. Either you configure the target so that it can return that very entry, or you configure your client to request what the database can actually return.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

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

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:

<slapd.conf> 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... </slapd.conf>

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.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

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