[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
sure.
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.)
One
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,
--Chan
I've seen the guides similar to this one here:
http://blogger.ziesemer.com/__2011/01/ldap-authentication-__for-samba.html
<http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html>
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
myschema.ldif
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.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
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/