Howard:

What are you talking about? A schema entry under cn=config has individual attribute values per schema element.

There is one attribute per schema element, that is, each objectClass or attribute defined in a schema is expressed by a single olcAttributeTypes or olcObjectClasses attribute, which contains a long, complex string which effectively defines other "attributes" of the schema object.

Would have been nicer if the hierarchy looked like this instead:

cn=config cn=schema cn={4}myshema cn={1}myattribute1 objectClass: olcAttributeTypes oid: 1.3.6.1.4... name: myAttr1 desc: This is a sample schema attribute equality: caseIgnoreMatch syntax: 1.3.6.1.4... cn={2}myattribute2 objectClass: olcAttributeTypes oid: 1.3.6.1.4... name: myAttr2 desc: This is a sample schema attribute 2 equality: caseIgnoreMatch syntax: 1.3.6.1.4... cn={3}myclass objectClass: olcObjectClass name: myAttr2 sup: top type: auxiliary must: cn={1}myattribute1 $ cn={2}myattribute2

rather than embedding all the attributes of a schema object in a monolithic string.

Then I would have agreed with you, Howard, that it would be easier to edit individual elements.

Editing individual schema elements is far more useful than deleting the entire schema and reloading it.

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. When developing a schema iteratively, I find it's easier to have replace the whole thing when you make significant changes than to futz around trying to replace individual definitions, crafing intricate ldif modify directives.

As it turns out, cn=config is NOT stored in the database (though the documentation misleads about this)...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.

Then Ralf said:

But is very time consuming and resource intensive. E.g. checking for the presence of an AttributeType requires a full scan of the database if that AttributeType is not indexed, I think. Additionally this check would have to be done with the thread pool paused (i.e. no other operation would be processed) or at least with every database set into read only mode, to avoid races. I am not even sure if it would be possilbe with all backends types that we currently support (think of back-ldap or back-meta).

Hmmm...sounds like a classic referential integrity issue. Triggers can be your friend! ;-)

But the safest option we can currently offer, IMO.

Sounds like it...though that makes me shudder, having some dbms background.

And yes of course things can always be improved. Help with that is always welcome, BTW.

'Fraid I have limited time to devote to open source (read: unpaid) projects, and all my spare time is already committed to another open source project (eXist...XML database).

So the best I can do is to ask questions and offer suggestions at this time, wrt OpenLDAP.

Then again, I did recently write and donate an eXist extension module that lets you easily query an LDAP directory using high-level functions in an XQuery. Does that count? ;-)

Quanah:

Incorrect. It is stored in a database of type "ldif". This may not be "bdb" or "hdb" that you are used to, but it is a type of OpenLDAP database backend.

You know, I tend to call databases, databases and flat files, flat files (or sometimes text files). There does tend to be a bit of a difference between the two.

And the *.ldif files found in /etc/ldap/slapd.d/cn=config/cn=schema are pretty much simple flat files, in a slightly modified ldif format, basically with some extra attributes defined at the end of the file.

And if they are "databases" (which I find hard to believe having looked at their internal structure), then one must question the advisability of using a .ldif filename suffix, which has very specific meaning.

Either way, sorry but I'm not buying it.

--On Saturday, December 13, 2008 12:07 AM +0100 Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:

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

AKA OpenLDAP 3.0? ;)

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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.

Andrzej Jan Taramina wrote:

Howard:

...

What are you talking about? A schema entry under cn=config has individual attribute values per schema element.

There is one attribute per schema element, that is, each objectClass or attribute defined in a schema is expressed by a single olcAttributeTypes or olcObjectClasses attribute, which contains a long, complex string which effectively defines other "attributes" of the schema object.

Would have been nicer if the hierarchy looked like this instead:

cn=config cn=schema cn={4}myshema cn={1}myattribute1 objectClass: olcAttributeTypes oid: 1.3.6.1.4... name: myAttr1 desc: This is a sample schema attribute equality: caseIgnoreMatch syntax: 1.3.6.1.4... cn={2}myattribute2 objectClass: olcAttributeTypes oid: 1.3.6.1.4... name: myAttr2 desc: This is a sample schema attribute 2 equality: caseIgnoreMatch syntax: 1.3.6.1.4... cn={3}myclass objectClass: olcObjectClass name: myAttr2 sup: top type: auxiliary must: cn={1}myattribute1 $ cn={2}myattribute2

rather than embedding all the attributes of a schema object in a monolithic string.

Then I would have agreed with you, Howard, that it would be easier to edit individual elements.

What you've described is similar to the original design, 3 years ago, but it proved unworkable. You can read through the openldap-devel archives from that time period for more background on the decisions. As I recall, we ran into trouble with schema extensions and a few other elements that didn't lend themselves well to being treated as distinct attributes.

You should learn a bit more about why and how things work, before suggesting they be changed.

Russell Jackson wrote:

Andrzej Jan Taramina wrote:

...

Then the term "database" is being misused rather badly, IMO. They are just ldif-formatted flat files.

At the risk of sparking a semantic war, a database is simply a collection of records. How they are formatted or stored is an implementation detail.

Exactly. "database" != "RDBMS", no matter how much the RDBMS folks like to claim otherwise.

Andrzej Jan Taramina wrote:

Hallvard:

...

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.

This does not say much. In the way I understand your wording this definition is plain wrong since it lacks the functional model of a database. And that's exactly what's missing in your understanding.

...

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 usually do schema development in a dedicated test slapd instance by simply editing schema text files included with slapd.conf. I'd use cn=config only if there's a real need for dynamic re-configuration of a long-running slapd instance for minimizing downtime.

Ciao, Michael.