[Date Prev][Date Next] [Chronological] [Thread] [Top]

translucent overlay with local-only entries

I'm trying to extend an ldap directory using the translucent overlay,
like many before me:


Before version 2.4.8, this wasn't possible. Howard Chu seems to have
fixed this in rev 1.40 (before release 2.4.8) of translucent.c:

Although it seems to have been fixed, I cannot get it to work on my
setup. I use the packaged v2.4.10 in Debian testing. My config:

# Config start
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        none

modulepath      /usr/lib/ldap
moduleload      back_hdb
moduleload      back_ldap
moduleload      translucent

sizelimit 500
tool-threads 1

backend         hdb
backend         ldap

database hdb
directory /var/lib/ldap/translucent
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=mybranch,dc=example,dc=com"
rootpw "admin"

overlay translucent
uri "ldap://";
idassert-authzFrom "dn.subtree:dc=example,dc=com"
# Config end

This works perfectly fine for searches where the entry is remote.
Changing entries works fine well, with the results stored in the local
translucent db. Adding new entries works, but they are not returned on
searches. I check this by running slapcat.

So, it boils down to these questions:
* Does Howard's patch not fully implement the searching?
* Is my config wrong?
* There is probably other ways to do this, perhaps using a meta
 ldap backend. With multiple backends, what determines where writes
 go? Probably where the object is based, but what about new objects?
* Is it cleaner to keep my "branch" of the tree under a subdomain,
 such as mybranch.example.com using rwm, or should they all be on the
 main example.com domain?
* Examples for exotic overlays are very scarce. It would be very
 helpful if anyone could provide their configuration file.