Andrzej Jan Taramina writes:
> 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
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:
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
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