--On Thursday, June 30, 2011 9:59 AM +0100 Mark Cave-Ayland
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.
Correct. Or ship both until 2.5 is out. ;)
2) If a project is distributing a .schema file, ask them politely to
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
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
Unfortunately, the people who maintain various distributions don't
necessarily participate (by joining the OpenLDAP mailing lists) in the
project. Others (RedHat, Mandriva, possibly others) do. The OpenLDAP
project obviously cannot force them to do things in any particular way.
Again, I urge people to file bug reports etc with distributions when they
find issues like these. I do this fairly often with Debian/Ubuntu.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration