Re: Updating a private schema (cn=config)?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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"...)

-- 
Hallvard