On 29/06/11 11:59, Howard Chu wrote:
> 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.
> 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.
His step 1 and 2 were fine. Everything after that is garbage.
mkdir config && slaptest -f schemaConvert.conf -F config
slapcat -F config -n0 -s cn=schema,cn=config
and all of your converted schema will pop out, ready to be slapadd'd or
ldapadd'd anywhere else.
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?
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.
With cn=config, I'm guessing I can't just delete the relevant schema
entry from LDAP and re-add it since there would be a small window
whereby the schema would be missing/invisible to slapd. This could cause
all sorts of issues, such as pushing the incremental deletion out to any
slaves, as well as breaking any concurrent lookups... :(
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