Hello,
We're running into almost exactly the same issue that Turbo described a few months ago and I'm not exactly sure what to try next...
Basically there are two remote directories that we only have read-only access to via fixed set of bind credentials. Both directories have the same naming contexts and same user entry DNs but a slightly different non-conflicting set of user attributes.
What we would like to do is create a combined merged view that contains the user entry attribute responses from both remote directories displayed as a single entry and allow anonymous access via the local lan. Only one of the two directories has the specific attribute being searched for but again we would like the response to include the full set of attributes from both directories and the entry DNs do match.
So, I'm attempting to use slapd-ldap for the first remote directory and slapo-translucent for the second remote directory but can't seem to make the two mechanisms cooperate with each other. The errors are the same as what Turbo described.
If I change the database from slapd-ldap to slapd-shell or slapd-hdb (empty db), the slapo-translucent portion works correctly and I can see the attributes in the searched entry retrieved from the second remote directory.
If I leave the slapd-ldap configuration in place and comment out the overlay translucent portion, the slapd-ldap portion works correctly and I can see the attributes in the searched entry retrieved from the first remote directory.
Still no luck on getting both to work at the same time though so that it combines the attributes from both entries into a single response.
Here's the pertinent portion of the config:
backend ldap database ldap suffix "dc=example,dc=com" uri "ldap://172.16.16.16/" idassert-bind mode=none bindmethod=simple binddn="uid=readonly1,cn=admins,dc=example,dc=com" credentials="secret1" flags=override,non-prescriptive
overlay translucent uri "ldap://172.17.17.17/" idassert-bind mode=none bindmethod=simple binddn="uid=readonly2,cn=admins,dc=example,dc=com" credentials="secret2" flags=override,non-prescriptive
If anyone has any ideas why the above isn't working or knows of a cleaner way to do it, please let me know. It would be much appreciated.
Thanks, Brian
----- Original Message -----
On Wed, 14 Sep 2011 20:53:03 +0200, Turbo Fredriksson wrote:
I'm trying to proxy an AD and an OpenLDAP server on a separate machine to get a 'combined' view.
Some more testing and finding a loglevel that doesn't drown me in information, I see this:
----- s n i p ----- [...] slapd starting conn=1000 fd=13 ACCEPT from IP=127.0.0.1:54815 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=company,dc=tld" scope=2 deref=0 filter="(uid=kpxb140)" conn=1000 op=1 SRCH attr=uid [...] conn=1015 fd=43 ACCEPT from IP=127.0.0.1:54830 (IP=0.0.0.0:389) conn=1015 op=0 BIND dn="" method=128 conn=1015 op=0 RESULT tag=97 err=0 text= conn=1015 op=1 SRCH base="dc=company,dc=tld" scope=2 deref=0 filter="(uid=kpxb140)" conn=1015 op=1 SRCH attr=* + daemon: shutdown requested and initiated. conn=1015 op=1 SEARCH RESULT tag=101 err=52 nentries=0 text=Proxy operation retry failed slapd shutdown: waiting for 18 operations/tasks to finish conn=1015 fd=43 closed (slapd shutdown) daemon: accept(-1) failed errno=9 (Bad file descriptor) [...] conn=1000 op=1 ldap_back_retry: retrying URI="(null)" DN="" conn=1000 fd=13 closed (slapd shutdown) RESETTING CACHED QUERY URLS slapd stopped. ----- s n i p -----
So on the last connection, I get 'Proxy operation retry failed' and on all the rest 'retrying URI="(null)" DN=""'. So I'll asume that there's a URI on conn=1000.
But why do I get these problems? Isn't slapo-translucent supposed to work with slapd-{ldap,meta}?
On Mar 17, 2012, at 10:59 PM, Brian Thompson wrote:
Still no luck on getting both to work at the same time though so that it combines the attributes from both entries into a single response.
Apparently, there's currently a problem with stacking modules like this.
The discussion get's a little more technical further down that thread, but the point was that it's supposed to be fixed somewhere at 2.5 (something needed to be rewritten).
openldap-technical@openldap.org