On Fri, Dec 5, 2014 at 1:23 PM, Howard Chu <[email protected]> wrote: > Richard LEGER wrote: > >> >> On Thu, Jul 10, 2014 at 10:00 PM, Quanah Gibson-Mount <[email protected] >> <mailto:[email protected]>> wrote: >> >> --On Thursday, July 10, 2014 2:58 PM +0100 Richard LEGER >> <[email protected] <mailto:[email protected]>> wrote: >> >> Is there other way(s) via a local schema or else to modify/extend >> definition of OpenLDAP core attributes without modifying source >> code and >> recompiling? >> >> >> No. You shouldn't be using the garbage OpenLDAP build shipped with >> Ubuntu anyway. >> >> --Quanah >> >> >> For information to those that may interested (and for the record)... >> >> Here is a simple description of the openldap <-> Outlook ldap >> addressbook issue: >> Source: http://victor-sudakov.livejournal.com/124269.html >> Translation: >> http://translate.google.co.uk/translate?hl=en&sl=ru&u=http:/ >> /victor-sudakov.livejournal.com/124269.html&prev=search >> >> In addition, for the address list organization to be displayed in >> Outlook, it seems necessary to patch the file >> /etc/openldap/schema/core.schema in order to add 'company' attribute as >> alias to 'o', something like: >> >> attributetype ( 2.5.4.10 NAME ( 'company' 'o' 'organizationName' ) DESC >> 'RFC2256: organization this object belongs to' SUP name ) >> > > Nonsense. This is why we have the rewrite module and attribute mapping > functions. > > Modifying IETF published schema is prohibited. >
Thanks for the info. That make sense. I wasn't aware of this functionality. > Just thought that may be helpful to know and record on the forum... >> > > No. Breaking the server is not the way to adapt schema for broken clients. > I understand this policy and I agree with it in theory but in practice once sometime has to be pragmatic when it needs to implement local exceptional work around for the sake of functionality and end-users life :) They are situations where you have no control over the broken client nor you can have it changed. Therefore you can only try to apply solution via what is in your control, the server side in a given environment. Those minor changes in core.schema discussed here won't really break the server, only remove full compliance with RFC while adding interoperability with some broken clients. In a closed private managed environment without external interaction that can be viewed as an acceptable temporary solution until broken clients are fixed. Thanks for your support.
