how to extend a remote database with local entries ?

[Oren Laadan <orenl@cs.columbia.edu>]

Hi,

I want to setup a local ldap server for my team that will extend a remote
ldap server (whose database is inaccessible to me and I cannot simply
replicate) with a small number (less than 100) of new (local) entries.
For example, the local server may add entries for new users only in my
team, but also support authentication of all users in the remote server.

I tried to use back-meta, which seems most suitable for merging data
from multiple targets. Assume the DN base is "dc=EXAMPLE,dc=COM",
which is what the clients use.

To set it up, I used the following config snippets:

...
moduleload      back_ldap
moduleload      back_meta
moduleload      back_bdb
...
backend         bdb
backend         meta
...
# bdb backend, with a "local" DN base different than the main one\
# not intended to serve clients, but to serve the meta backend only
database        bdb
suffix          "dc=TMP,dc=EXAMPLE,dc=COM"
readonly        on
...
# meta backend, with the right DN base, serving the clients
database        meta
lastmod         off
suffix          "dc=EXAMPLE,dc=COM"
uri             "ldaps://REMOTE_SERVER/dc=EXAMPLE,dc=COM"
uri             "ldaps:///dc=TMP,dc=EXAMPLE,dc=COM"
suffixmassage   "dc=EXAMPLE,dc=COM" "dc=TMP,dc=EXAMPLE,dc=COM"
...

There is a local database for subtree dc=TMP,dc=EXAMPLE,dc=COM (which
isn't used by the clients). This database holds the additional entries.
(Clearly, I cannot have used the same DN base).

The main database (used by the clients), dc=EXAMPLE,dc=COM is a meta-
backend, which forwards queries to both the remote server and the local
database. With the latter, is uses suffixmassage to convert from the
real DN to the local database DN and back.

There are two problems with this configuration: first it is suboptimal
because it requires multiple threads to handle the self-referral to the
local database. More importantly, due to a problem in the server this
leads to random lockup of the server.

The discussion in the -bugs lists (read the full thread here:
http://www.openldap.org/lists/openldap-bugs/200802/msg00034.html)
suggested alternatives:
(1) use overlay translucent
(2) use back-relay
(3) use back-ldap to the remote server and subordinate glue for local db

However ....

(1) I tried the overlay translucent (see config below), and the local
database entries didn't show up. When the overlay was turned if, they
did show up (but without the remove entries ...). Indeed the man page
says it should be used to override and/or modify attributes of entries
coming from the remote server; it doesn't say anything about being able
to add new entries.

...
# bdb backend, local database, same DN base
database        bdb
suffix          "dc=EXAMPLE,dc=COM"
readonly        on
overlay         translucent
translucent_no_glue
uri             "ldaps://REMOTE_SERVER/"
lastmod         off
...

(2) back-relay does not merge two database, but instead makes the job
of relaying to the same server internal and therefore much more efficient.

(3) Tried the config below, but it wouldn't run... so I'm not sure what
the right config should be. Again, I think the issue here is that a
subordinate database is to be a subtree of the remote server, unlike
the simple merge that I require (both remote and local at the same level)

...
database   ldap
lastmod    off
suffix     "dc=EXAMPLE,dc=COM"
uri        "ldaps://REMOTE_SERVER"
...
database        bdb
suffix          "dc=EXAMPLE,dc=COM"
subordinate
readonly        on
...

The only other solution I can think of is run two (!) separate ldap
instances on the local server machine to avoid the lockup problem I've
been experiencing. Ugly ...
(Note: I tried both 2.3.39 and 2.4.7)
Hopefully *someone* would know how to successfully get my setup to work.

Thanks,

Oren.