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

Re: Loading LDAP schema files into cn=config

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.

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:

dn: cn={4}sirius-custom
cn: {4}sirius-custom

...which then means I still can't add it directly using ldapadd without further processing.

Also that begs another question: what happens if you want to modify an
existing schema, e.g. if I need to hack a schema by hand and reload it
into openldap so that it takes effect? Normally I would change the
schema file on disk, restart slapd and it would just work.

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?



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