Andrzej Jan Taramina writes:
Howard: (...)
Editing individual schema elements is far more useful than deleting the entire schema and reloading it.
Depends on the schema, if I understand the distinction correctly. Once in a while I've needed to upgrade to a new version of a published schema. And to retire a schema. But that's rare enough that it'd be OK to stop slapd and update some cn=config files tree by hand.
Still, I do find it easier to edit slapd.conf than to modify cn=config. Among other things because there are fewer cases which don't work... We are moving to cn=config here anyway so we can update it dynamically, but we'll likely keep a slapd.conf around as "documentation" and maybe to regenerate the config from if we want to do something cn=config doesn't want to do.
I find it a PITfA, since you have to respecify the whole schema object definition string each time...you can't just change the SUP or the description alone with the current structure, and searches are a pain too. But that is just IMO.
If nobody has mentioned it yet - I hope you are aware of various LDAP browser/editors which can make this a bit easier. phpLDAPadmin, ldapvi, etc. Some ar listed here: http://www.openldap.org/faq/data/cache/271.html
Regarding searching - why does olcAttributeTypes have syntax Directory String instead of using attributeTypes' syntax Attribute Type Description? That would enable a search for (olcAttributeTypes=title), as well as ldapsearch -E'!mv=(olcAttributeTypes=title)' to extract just the definition of 'title'.
It needs to be a string type, a SUBSTR matching rule would help. Then we could search for "(olcAttributeTypes=*'title'*)".
There are LDAP tools that make editing LDAP entries easier -
As it turns out, cn=config is NOT stored in the database (though the documentation misleads about this)...
It's what slapd considers a "database" and which you configure as a "database" in slapd.conf. A slapd "database" is an instance of a backend, and a backend is a module which can store/provide LDAP data for slapd.
Only a few backends in slapd use what you'd normally call a "database". Do you have a suggestion for where it could have made clearer, and a brief wording for it?
it is stored in a special subdirectory (/etc/ldap/slapd.d/cn=config on my Ubuntu boxes). Maybe it's loaded into the db at startup...I don't know. Not sure this is much better than the old slapd.conf approach.
The point of cn=config is that you can update it over the LDAP protocol without stopping slapd. Therefore the configuration must be LDAP entries. I imagine rewriting LDAP config entries back to slapd.conf format would add an additional set of hassles.
[About checking if a schema element to be deleted is in use]
Hmmm...sounds like a classic referential integrity issue. Triggers can be your friend! ;-)
Sure it can be done. It's just that the code was not written with dynamic configuration in mind, and it's quite a job to update it all to support it. (I don't know how much, but I wouldn't be surprised if it's yet another issue which in the end leads to "maybe we should just start over"...)