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.
Hi,
Oren Laadan orenl@cs.columbia.edu writes:
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" ...
Declare back-bdb as subbordinate to back-meta. Something like
database bdb suffix dc=tmp,dc=example,dc=com ... subordinate
database meta suffix dc=example,dc=com uri ... uri ...
-Dieter
--On Saturday, February 09, 2008 9:19 AM +0100 Dieter Kluenter dieter@dkluenter.de wrote:
Declare back-bdb as subbordinate to back-meta. Something like
Dieter,
I suggest you go read ITS#5354.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com writes:
--On Saturday, February 09, 2008 9:19 AM +0100 Dieter Kluenter dieter@dkluenter.de wrote:
Declare back-bdb as subbordinate to back-meta. Something like
Dieter,
I suggest you go read ITS#5354.
Quanah,
As far as I understand ITS#5354 has nothing in common with my suggestion.
-Dieter
Hi,
Your suggestion indeed seems to work ! I'll be monitoring the system for lockups, but since there are no self-references from the server to itself involved, I don't expect problems. Below is the layout of the working configuration, for future references.
... moduleload back_ldap moduleload back_bdb ... backend bdb backend ldap ... # bdb backend, configured as a subordinate of the main server database bdb suffix "dc=SUB,dc=EXAMPLE,dc=COM" readonly on subordinate ... # ldap backend, with the right DN base database ldap lastmod off suffix "dc=EXAMPLE,dc=COM" uri "ldaps://REMOTE_SERVER/" ...
Works like charm :) Many thanks to all those that tried to help me sort out the problem.
Oren.
Dieter Kluenter wrote:
Hi,
Oren Laadan orenl@cs.columbia.edu writes:
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" ...
Declare back-bdb as subbordinate to back-meta. Something like
database bdb suffix dc=tmp,dc=example,dc=com ... subordinate
database meta suffix dc=example,dc=com uri ... uri ...
hehehe .. one of these uri's used to point to the server itself, and this is not well supported by openldap, hence the original problem.
-Dieter
openldap-software@openldap.org