[Date Prev][Date Next]
Re: slapd-relay and slapo-rwm questions
Quanah Gibson-Mount wrote:
So, I've been playing with slapo-relay and slapd-rwm to try and make it
so that I can meet the expectations of different email clients that
query my directory. This has led to a few questions:
(1) If your root is "dc=example,dc=com", and the entries you are
interested in rewriting are in "cn=people,dc=example,dc=com" and the
suffix you want to use virtually is "cn=outlook,dc=example,dc=com", how
do you configure this? My attempts at doing this gave me the following
<suffix> namingContext "cn=outlook,dc=example,dc=com" already served by
a preceding hdb database serving namingContext "dc=example,dc=com"
The same rules for slapd.conf ordering still apply - the most specific
DN's must appear before the less specific DN. So you must define
(2) How do you get it to map the entry DN results to the new base? With
"cn=people,dc=stanford,dc=edu" being mapped to
"cn=outlook,dc=example,dc=com", the entries DNs returned all show
"cn=people,dc=stanford,dc=edu" instead of "cn=outlook,dc=example,dc=com":
ldapsearch -LLL -x -h ldap-dev1 -b "cn=outlook,dc=example,dc=com"
You still need to configure the suffixmassage.
(3) How do you map attributes to attribute names that don't exist in
your schema? Since this is really about what gets displayed back to the
client, I don't see why there is a requirement that the mapped-to
attribute name must exist in your schema.
Everything that the local slapd returns directly to a client must exist
in the local slapd's schema. You can only get away with using undefined
schema elements when forwarding queries to a remote server, and even
then you shouldn't - you should import the remote schema into the local
Remember, we don't support "schemachecking off" any more - we expect
everything that we touch to have valid schema definitions.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/