title: the deal with openldap schema-checking link: https://onemoretech.wordpress.com/2007/08/21/the-deal-with-openldap-schema-checking/ author: lembobro description: post_id: 659 created: 2007/08/21 18:13:00 created_gmt: 2007/08/21 18:13:00 comment_status: open post_name: the-deal-with-openldap-schema-checking status: publish post_type: post

the deal with openldap schema-checking

The last few days I’ve been experimenting with loading some medium sized datasets into OpenLDAP. Basically all I did was transform a dump of all the active entries in my company’s directory into a format loadable into OpenLDAP without making any schema changes.

Well, at least that was the plan.

Right off the bat I was tripped up by the fact that the ‘c’ or ‘countryName’ attribute, although defined in the core.schema file, is only included in the ‘country’ objectclass as an allowable attribute. No problem, I just added it to ‘organizationalPerson’ (hey, I am eldapo, after all).

Then I had some trouble with having a value like “9999999999” for ‘facsimiletelephonenumber’, with ldapadd screaming at me about invalid syntax (the dreaded “error 21”). When I checked the core.schema file I found ‘facsimiletelephonenumber’ or ‘fax’ had a different syntax code that ‘telephonenumber’. I fixed that too, adding the EQUALITY and SUBSTR directive from ‘telephonenumber’ to allow me to index it for eq and sub searches (any good whitepages directory should let you search on fax as well as voice numbers for someone).

There were a few other odd schema violation notices as well, some inexplicable even on careful examination. In the end I did an ldapadd -c to just load the bulk of the entries (which came to just over 15,000).

Of course schema-checking can no longer be disabled in the latest OpenLDAP code (since at least 2.2.28), which Kurt Zeilenga explains was necessary because the feature conflicted with other enhancements being rolled into the code (he adds that it was broken anyway, to which I can attest from personal experience).

When I first started working with OpenLDAP I quickly learned that hacking the schema was an essential skill I needed to develop. For the most part you can get away with adding your own custom objectlasses (usually auxilliary) and attributes to get around the limitations of what ships with the product. Oh yeah, you’ll also need to understand the difference between structural and auxilliary objectclasses. For example see this discussion thread (and what preceeded it). A succinct explaination of the matter can be found in this article in the OpenLDAP Faq-O-Matic (which I did not author, though I wish I had).

The aggravating thing is that I’ve loaded similar data, in fact data that had not had a fraction of the scrubbing, into both Netscape family (Sun, Fedora/RedHat) and Oracle directories without this much trouble — once again demonstrating that open source is not for amateurs.

Copyright 2004-2019 Phil Lembo