Quanah Gibson-Mount wrote:
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.
Haven't checked, but if you don't force real database selection at
startup, it will find its way by selecting the database for each
operation (maybe not the most efficient option...)
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.
That __should__ 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.
We got to a point where schema is essential for all internal operations
-- and I wouldn't back off --; for this purposes, we rather developed
tools to munch and digest the worst schema sources ever. I rather
prefer having control on what is getting in, and especially on what's
pushed out. Note that in order to push out search results you don't
need to know matching rules for attributes; but you will to accept
filters. So a best practice consists in knowing the schema for all
items, and generate dummy schema for unknown items with something like
"octetStringMatch" as equality rule, so that it smoothly passes frontend
filter validation. Any overlay would be useless at this point, since
overlays cannot take control __before__ filter validation, or when
determining if an attribute was requested. I can share some of those
tools if you want to try them (too busy to release them "officially",
sorry).
p.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: [EMAIL PROTECTED]
------------------------------------------
