Hallvard:
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
Yup....I use the command line utilities (ldapsearch/add/modify) a lot with some routines that generate appropriate ldif files from raw XML. I also have found luma to be quite handy as a GUI-based LDAP viewer/editor. Even managed to get it set up so that I can walk and modify the cn=config entries, including schemas.
There are LDAP tools that make editing LDAP entries easier -
Yup...like XSLT and XQuery! ;-)
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.
Then the term "database" is being misused rather badly, IMO. They are just ldif-formatted flat files.
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?
Backend storage mechanism.
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.
Which can be handy at times...just not for doing iterative custom schema development. ;-)
I imagine rewriting LDAP config entries back to slapd.conf format would add an additional set of hassles.
Yup...not really interested in going that route.
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"...)
"Starting over" is always a very, very bad idea.
The dynamic cn=config stuff is a bit young and raw around the edges, but the concept is a good one.