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

Re: Loading LDAP schema files into cn=config

Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:

Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you are trying to

Obviously the config file has to be valid; any schema that the ones
you're converting depend on must be loaded.

I understand that part; however when installing the packages for Debian
Squeeze the post-installation process preloads the following schemas
into cn=schema,cn=config:


So what I wanted to verify was that if I want to add a new
sirius-custom.schema file into the directory I would need to setup
schemaConvert.conf to look like this:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/sirius-custom.schema

The previous entries are required to ensure that the
sirius-custom.schema LDIF would be generated as {4}sirius-custom ready
for using ldapadd to load into the directory.

You only need to load those 4 schema files if your sirius-custom.schema file actually depends on all of them. The ordering prefix only needs to be {4} if you really need those others to be parsed first. Otherwise the prefix can be deleted and the config backend will generate it automatically. This is all in the documentation. You should try reading it sometime.


However when I then run:

mkdir config&&  slaptest -f slapd.conf.tmp -F config

Then I get my {4}sirius-custom.ldif but the top lines look like this:




You're not paying attention. You skipped step 3 of my reply.

And apparently you need to be flamed too.

I frankly can't believe that you just asked that question. cn=config is
an LDAP database. When you want to change its contents, you use
ldapmodify. It takes effect immediately and there is no need to restart
the server.

Oh I understand that part - my question was perhaps badly asked. What I
really want to know is what should my workflow be when designing new
LDAP schemas to be distributed as .schema files? Based upon what you are
saying, I guess it should be either:

1) Update .schema file
2) Generate .ldif using slaptest
3) Manually update the relevant attribute in cn=schema using an LDAP
browser to be the new value generated within the .ldif
4) Test


1) Update .schema file
2) Generate .ldif using slaptest
3) Hack the dn within the .ldif to add cn=schema,cn=config suffix
4) Remove the entire cn={x}sirius-custom section
5) Reload the entire cn={x}sirius-custom section using ldapadd
6) Test

Does that sound correct?


As soon as you use the word "hack" you should realize you're doing something wrong. As soon as you use the words "manually update" you should realize you're doing something wrong.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/