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"
I understand quite well that "cn=outlook,dc=example,dc=com" is served by dc=stanford,dc=edu, and so what? It doesn't actually exist in that database, and I want to make it appear to exist.
(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
(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.
For example:
map attribute displayName mail
works but
map attribute displayName display-name
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
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 ...
(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.
(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.
--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
Quanah Gibson-Mount wrote:
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.
The rwm overlay is probably not usable regardless, there are a lot of ITS's outstanding against it.
As for your schema complaint - I already gave you a clear explanation, there's nothing further to say.
database relay suffix cn=outlook,dc=stanford,dc=edu relay cn=people,dc=stanford,dc=edu massage
Try using rwm- directives explicitly instead of the implicit suffixmassage/map/rewrite/relay etc. directives; I think the process of deprecation there might be getting in your way. Perhaps:
# "cn=outlook" input, "cn=outlook" output, data hosted in "cn=people" below database relay suffix cn=outlook,dc=stanford,dc=edu overlay rwm rwm-suffixmassage cn=people,dc=stanford,dc=edu
# define cn=people here ("dc=stanford,dc=edu" should do)
--On Wednesday, October 11, 2006 8:43 PM -0400 Aaron Richton richton@nbcs.rutgers.edu wrote:
database relay suffix cn=outlook,dc=stanford,dc=edu relay cn=people,dc=stanford,dc=edu massage
Try using rwm- directives explicitly instead of the implicit suffixmassage/map/rewrite/relay etc. directives; I think the process of deprecation there might be getting in your way. Perhaps:
# "cn=outlook" input, "cn=outlook" output, data hosted in "cn=people" below database relay suffix cn=outlook,dc=stanford,dc=edu overlay rwm rwm-suffixmassage cn=people,dc=stanford,dc=edu
# define cn=people here ("dc=stanford,dc=edu" should do)
Yep, that made it so slapd would load with it listed first, thanks!
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
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: pierangelo.masarati@sys-net.it ------------------------------------------
--On Thursday, October 12, 2006 6:33 AM +0200 Pierangelo Masarati ando@sys-net.it wrote:
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.
Well, I think I've tracked this down to this line:
rwm-rewriteRule "(.+,)?cn=outlook,dc=stanford,dc=edu$" "$1cn=people,dc=stanford,dc=edu" ":"
If I take that line out, the rewriting occurs -- But I get no data from the entries, just the DN's.
If I keep the line, then the DN's are rewritten, but I get to see the entry data. I'm guessing that's an ITS if there isn't one on it already...
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).
Hm, I guess in my case, the issue is, I don't care about the filters, because the filters are using normal attributes. What I care about is what is on the return, and I honestly care less whether or not they even exist in a schema. But, I could always load in some schemas if necessary, it shouldn't hurt anything.
Overall though, it seems the functionality just isn't stable enough at this point to deploy onto my production servers. :/
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Thursday, October 12, 2006 3:48 PM -0700 Quanah Gibson-Mount quanah@stanford.edu wrote:
Well, I think I've tracked this down to this line:
rwm-rewriteRule "(.+,)?cn=outlook,dc=stanford,dc=edu$" "$1cn=people,dc=stanford,dc=edu" ":"
If I take that line out, the rewriting occurs -- But I get no data from the entries, just the DN's.
If I keep the line, then the DN's are rewritten, but I get to see the entry data. I'm guessing that's an ITS if there isn't one on it already...
As an example, without the line, I see:
tribes:~> ldapsearch -x -h ldap-dev1 -b "cn=outlook,dc=stanford,dc=edu" "cn=quanah*" # extended LDIF # # LDAPv3 # base <cn=outlook,dc=stanford,dc=edu> with scope subtree # filter: cn=quanah* # requesting: ALL #
# 85e49978f61311d2ae662436000baa77, outlook, stanford.edu dn: suRegID=85e49978f61311d2ae662436000baa77,cn=outlook,dc=stanford,dc=edu
# 8696e59cf61311d2ae662436000baa77, outlook, stanford.edu dn: suRegID=8696e59cf61311d2ae662436000baa77,cn=outlook,dc=stanford,dc=edu
With the line, I see:
tribes:~> ldapsearch -x -h ldap-dev1 -b "cn=outlook,dc=stanford,dc=edu" "cn=quanah*" # extended LDIF # # LDAPv3 # base <cn=outlook,dc=stanford,dc=edu> with scope subtree # filter: cn=quanah* # requesting: ALL #
# 85e49978f61311d2ae662436000baa77, people, stanford.edu dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu cn: quanah gibson cn: quanah gibson mount cn: quanah mount displayName: Quanah Gibson-Mount givenName: quanah mail: quanah@stanford.edu o: University objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: suPerson ou: IT Services sn: gibson sn: gibson mount sn: mount suAffiliation: stanford:staff suDisplayAffiliation: Staff suDisplayNameFirst: Quanah suDisplayNameLast: Gibson-Mount suDisplayNameLF: Gibson-Mount, Quanah suRegID: 85e49978f61311d2ae662436000baa77 title: Principal Sys Admin, QA, Programmer, Webmaster
....
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
It might be worth noting that you can combine this with glue if you want everything to show up as One Happy Database.
database relay subordinate suffix "ou=Peeps,dc=eden,dc=rutgers,dc=edu" overlay rwm rwm-suffixmassage "ou=People,dc=eden,dc=rutgers,dc=edu"
database ldap suffix "dc=eden,dc=rutgers,dc=edu" uri [...real data like ou=People...]
(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 ...
openldap-software@openldap.org
-
Aaron Richton -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount