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: 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.
His step 1 and 2 were fine. Everything after that is garbage.
1: schemaConvert.conf #### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include samba.schema ####
2: slaptest mkdir config && slaptest -f schemaConvert.conf -F config
3: slapcat
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.
Hi Howard,
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... :(
ATB,
Mark.