[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Loading LDAP schema files into cn=config

On 29/06/11 18:05, Quanah Gibson-Mount wrote:


Although I'm not sure exactly how this is going to work since elements of
slapd.conf are still required to bootstrap the directory from LDAP
.schema files. Hmmm.


Zimbra puts cn=config in the same location as any other LDAP database we
use (/opt/zimbra/data/ldap/, which has cn=config, hdb, and accesslog
databases).


Right - so the Debian guys have definitely got this wrong then :(


As for the *.ldif schema, OpenLDAP ships both .ldif and .schema files
for the schemas it has always shipped. If a project is not shipping a
.ldif version, file a bug with the project (I did this for Amavis, for
example).

If you have your own schema, change your schema generation process to
generate an LDIF formatted schema instead of the old .schema format.
That's also what we did at Zimbra (In fact, we generate both .schema and
.ldif versions of the ZCS schema).
Whoa - wait second. Now I get it - so not only is slapd.conf deprecated, but also the distribution of .schema files. If we're supposed to be distributing schemas in .ldif format from now on, then the conversion problem just goes away. So I was missing something obvious after all...
As a long-term follower of this project, can I just summarise what I believe the results of this thread are:
1) Distribution of .schema files is deprecated. Projects should be distributing .ldif files containing schema changes instead.
2) If a project is distributing a .schema file, ask them politely to move to .ldif format instead. If they refuse, you need to convert from .schema to .ldif yourself using slaptest.
Finally, just as a general observation it's obvious that this message is NOT getting through to distributions and developers. I would advise that you add an explicit deprecation warning related to the distribution of .schema files with applications (as it's not clear that the .schema files are directly considered part of the configuration) to the main documentation and point people towards that when (like me) they start to ask questions. 


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs