Carr, Chris wrote:
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 22 January 2008 03:16
Still, it would probably be worth spending a few days effort to
collect the
different schema together and define a superset that contains all of
their
respective customizations. Then you can use back-relay and the rewrite
overlay
to present the client-specific views to each client. The result of
that effort
would make a fine entry in the FAQ-o-Matic.
Thanks for the replies. Is there another way of doing this? Instead of trying to create some super-schema for my server (which would be outdated every time any of the clients altered its schema), could I not simply replace each client's schema with a consistent one?
Let's say that the three clients I want to share contacts are Outlook, Evolution and Thunderbird. Would it be possible to use the AD schema for the LDAP server and for all three clients, replacing the default schemata of Evolution and Thunderbird?
Since Evolution and Thunderbird are open source, you can of course modify them to do whatever you want.
If this is not possible, how would the super-schema solution propagate changes made by one client to the data visible to another? (Presumably this is where "back-relay and the rewrite overlay" come in - will have to read up on these.)
Yes, you would create one main directory with the superset of data elements and use back-relay to present distinct virtual directories to each client so they will only see the attributes they're looking for. The rewrite overlay would translate attribute names back and forth so that there aren't multiple copies of identical data.
I found the Evolution schema, though I don't know how up-to-date it is:
http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/openldap/evolutionperso n.schema?view=co
... so I can try combining it with the Mozilla schema and see how far I get before taking on Outlook. Does anyone know where to find the AD schema? I can find dozens of pages about it, but can't actually download it from any of them.
As usual, Microsoft is not very forthcoming with docs, but there's quite a bit of analysis already done here.
http://www.openldap.org/faq/data/cache/295.html
Yet another way of looking at this is to consider that the combination of core, cosine and inetorgperson provides all the fields you need in a basic address book, and it should be possible to get all the clients (at least the non-MS ones) using that.
I'll report back if I make any progress, but Google shows that people have been struggling with this problem since the dawn of LDAP, so I'm not overly optimistic.
CC