Re: Loading LDAP schema files into cn=config

[Howard Chu <hyc@symas.com>]

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
> > > 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.

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.

http://www.openldap.org/doc/admin24/slapdconf2.html

> 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:

No.

No.

No.

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

And apparently you need to be flamed too.
http://www.openldap.org/lists/openldap-technical/201106/msg00085.html


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

No.

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/