Hello,

We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the current configuration do not use a regular suffix (o=foo,c=bar nor dc=foo,dc=bar) but use an empty suffix ("").

We want to move away from empty suffix as we cannot use cn=monitor or any additional suffixes as they can not bind when a suffix ""is in use in a hdb database :

<suffix> namingContext "o=..." already served by a preceding hdb database serving namingContext ""

Of course, you can't configure a database with non-null suffix after one with null suffix:

database xxx suffix ""

database yyy suffix "cn=non-null"

this is invalid, since "" is more general than anything else. But you can always do

database yyy suffix "cn=non-null"

database xxx suffix ""

because any DN is less general than "". Does this solve your problem?

p.

We still have some old applications which are using empty search base and query implicitly the union of o=A and o=B stored within the same ldbm database.

To maintain the backward compatibility we did a meta backend to merge the two local DITs under suffit "".

The side effect of meta backend with ldap://localhost is the increase of the number opened tcp connection to slapd which are eating "thread" connections for "nothing". The number of "thread" in use is linked to the number of suffixmassage used in meta backend (2 in our case). We want to try to avoid increasing by two the number of theads in use to maintain the backward compatibility.

Do you know an alternative way to merge two local DITs without using meta backend ? Can we use relay/ldap backend with rwm overlay instead of using meta backend ?

database meta suffix "" uri "ldap://localhost/o=test1" suffixmassage "o=test1" "o=test1" uri "ldap://localhost/o=test2" suffixmassage "o=test2" "o=test2"

Thank you for your help.

Best Regards, Guy Baconniere.

CURRENT CONFIG (slapd 2.1.x) suffix "" database ldbm rootdn "cn=manager" directory "/var/lib/ldap" # o=test1, o=test2, cn=manager are stored within the same ldbm database

CURRENT LDAPSEARCH (slapd 2.1.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' dn: o=test1 dn: o=test2 dn: cn=manager

TEST CONFIG WITH BACKWARD COMPATIBILITY (slapd 2.4.x) database hdb suffix "o=test1" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/test1" database hdb suffix "o=test2" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/test2" database hdb suffix "dc=test3,dc=com" rootdn "cn=admin,dc=test3,dc=com" directory "/var/lib/ldap/dc=test3,dc=com" database relay suffix "cn=manager" overlay rwm rwm-rewriteEngine on rwm-suffixmassage "cn=manager" "cn=manager,o=admin" rwm-normalize-mapped-attrs yes database meta suffix "" uri "ldap://localhost/o=test1" suffixmassage "o=test1" "o=test1" uri "ldap://localhost/o=test2" suffixmassage "o=test2" "o=test2"

LDAPSEARCH WITHOUT META BACKEND (slapd 2.4.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' No such object (32)

LDAPSEARCH WITH META BACKEND (slapd 2.4.x) ldapsearch -LLL -h localhost -p 389 -x -b '' -s one '(objectclass=*)' '1.1' dn: o=test1 dn: o=test2

OPENLDAP LOGS SHOWING THE LOCAL CONNECTIONS OF META BACKEND slapd[29622]: conn=11 fd=37 ACCEPT from IP=127.0.0.1:33680 (IP=0.0.0.0:389) slapd[29622]: conn=11 op=0 BIND dn="" method=128 slapd[29622]: conn=11 op=0 RESULT tag=97 err=0 text= slapd[29622]: conn=11 op=1 SRCH base="" scope=1 deref=0 filter="(objectClass=*)" slapd[29622]: conn=11 op=1 SRCH attr=1.1 slapd[29622]: conn=8 op=3 SRCH base="o=test1" scope=0 deref=0 filter="(objectClass=*)" slapd[29622]: conn=8 op=3 SRCH attr=1.1 slapd[29622]: conn=8 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[29622]: conn=9 op=3 SRCH base="o=test2" scope=0 deref=0 filter="(objectClass=*)" slapd[29622]: conn=9 op=3 SRCH attr=1.1 slapd[29622]: conn=9 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[29622]: conn=11 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text= slapd[29622]: conn=11 op=2 UNBIND slapd[29622]: conn=11 fd=37 closed

Hello,

You can do this just fine. I do it in all my installs. You simply need to declare them in the right order. I.e., you must declare monitor, etc before the empty suffix.

I did not realize that the order was important.

Thank you very much !

For meta backend it can be a good add-on feature to avoid generating a tcp connection to connect to localhost as the relay backend does.

People may not realise that for one client connection to a meta DB the server is generating N parallels tcp connections (equal to the number of suffixmassage) to the target server (localhost). It will reach easily the default 32 threads on the ldap server.

Then if you increase the number of thread you will get "warning, threads=128 larger than twice the default (2*16=32); YMMV."

If found another kind of "issue" with meta with localhost that it will act as a ldap client connecting to it self and you may skip the fact that it needs to have full read credential. Even if you connect with ldapsearch as super user (cn=admin,..) on a meta DIT you will not get a full access to the tree because the "client" by default is anonymous so it has restricted ACL.

Best Regards, Guy Baconnière