--On Wednesday, October 11, 2006 4:23 PM -0700 Howard Chu hyc@symas.com wrote:
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 error:
<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
database relay suffix cn=outlook,dc=example,dc=com ...
database hdb suffix dc=example,dc=com ...
If you put it before the database hdb definition, then it cannot find the dc=stanford,dc=edu database, and slapd fails to start.
/usr/local/etc/openldap/slapd.conf: line 72: cannot find database of relay dn "cn=people,dc=stanford,dc=edu" in "relay <dn> [massage]" line
so that's a non-starter.
(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" "cn=quanah*" dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
You still need to configure the suffixmassage.
My understand is that is the point of this bit of configuration?
database relay suffix cn=outlook,dc=stanford,dc=edu relay cn=people,dc=stanford,dc=edu massage
but that doesn't do it.
(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 slapd.
Remember, we don't support "schemachecking off" any more - we expect everything that we touch to have valid schema definitions.
I don't see why it is necessary for whatever the attribute gets mapped *to* to exist in the local schema. I don't see why I should be forced to load mozilla's schema, for example, to rewrite attributes I have in my server to what mozilla wants, or why I should create some bogus "display-name" attribute just so I can rewrite "displayName" to "display-name" for outlook. To me, the whole idea here, is I want to present to the client attributes that are syntax correct in the underlying DB, since they are forced to be there, as whatever I want the end client to see them as. As is, this whole overlay becomes worthless to me without that ability.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html