[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
add?

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:

{0}core
{1}cosine
{2}nis
{3}inetorgperson

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

or:

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?


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