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

Re: Loading LDAP schema files into cn=config

Chan Wilson wrote:
On Wed, Jun 29, 2011 at 5:26 AM, Mark Cave-Ayland
<mark.cave-ayland@siriusit.co.uk <mailto:mark.cave-ayland@siriusit.co.uk>> wrote:

    Hi all,

    Having started to look at the changes required to migrate from a
    slapd.conf setup to a cn=config setup, one of things I'm struggling with
    is how to load new LDAP schemas into cn=config.

There's a certain mindset to be achieved in understanding cn=config / RTC, for

I'm happening to be building up an updated config for an N-way multi-master
setup, and having the occasion to revisit the OpenLDAP manual, the Zytrax LDAP
book/site, and the ever-useful test suites in the source, I can say there's
lots of good documentation out there... but it could always be better.

One item I can highly recommend is that once you convert to RTC format, don't
ever touch the files on disk.  Oh, you can, for sure, but if you ever think
about replication, there's so many lovely ways to shoot your servers it's
crazy.  Been there, learnt that.

Which is one (of many) reasons why I continue to flame people for ever suggesting it.

Let me be clear - I've been administering Unix installations for over 25 years. I am the last person anyone needs to convince about the value of human-readable and editable config files. In fact this was one of my principle requirements for cn=config when it was being developed, and I stated it many times during the early days: http://www.openldap.org/lists/openldap-devel/200503/msg00038.html

Those of you who pipe up about this topic today without having done your homework and read the background of this design are, to be blunt, both ignorant and simply preaching to the choir; neither of which is ever appreciated.

The ability to do manual disaster-recovery/emergency config changes is crucial. But you also have to understand that going this route is for *emergencies* - it is not the way to go for routine administrative tasks.

Regarding bootstrap -- the test suites show nicely how minimal it can be --
one slapadd to create the base cn=config and olcDatabase{0}config,cn=config,
and then start up the server and do the remaining configuration, including
adding the schemas (presuming you've got them in .ldif format already.)

rough edge not so obviously logged is the server (as of 2.4.25) needs a
restart after adding an (hdb) database object/branch.

That is certainly not true, as test050 does this and much more.

Replication has its own
pointy edges as well along with TLS; I've spent hours chasing obscure TLS
issues due to O/S dependent behaviors.

Regarding schemas -- it's a straightforward perl 1-liner to translate from
.schema to .ldif format.  Then import and edit via ldapmodify as needed.

Hope this helps,


    I've seen the guides similar to this one here:
    which suggest hacking together a temporary slapd.conf file containing just
    the include directives, run slaptest, and then hack the output so that it
    can be loaded into cn=config using ldapadd.

    Given that this is a quite a common task, is there no way of generating
    the LDIF directly to be loaded into the directory, e.g.

    slaptest -s /etc/ldap/schema/myschema.__schema [ -n <schemanum> ] -l

    Or then again, is this functionality already there but I just haven't
    managed to find it yet? I'd be grateful if someone could point me in the
    right direction and/or give me some hints as to the best way to manage
    schemas in the new regime.

    Many thanks,


    Mark Cave-Ayland - Senior Technical Architect
    PostgreSQL - PostGIS
    Sirius Corporation plc - control through freedom
    t: +44 870 608 0063 <tel:%2B44%20870%20608%200063>

    Sirius Labs: http://www.siriusit.co.uk/labs

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