[Date Prev][Date Next]
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
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
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
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs