[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: still unclear on error 69

Jon Roberts wrote:

Thanks for replying. I should've qualified "used to work fine" better. Extending entries by modifying the objectclass attribute was something I did regularly with iPlanet directory servers and something I tested once or twice with OpenLDAP 2.0.


It's admittedly been some time since I've tried, and much of my configuration has changed.

The thread I referenced from last month

 >> http://www.openldap.org/lists/openldap-software/200307/msg00646.html

led me to believe that this error is the result of schema checking, was a natural product of upgrading to 2.1, and that there was no way to modify the objectclass attribute for an object with schema checking turned on. Perhaps it's misinformed, but it was stated so matter-of-factly that I assumed there was a straightforward, if perhaps unwelcome, answer.

Ah. I don't recall ever having seen this. It's true that Openldap v2.1.x has schema checking. It's also true that for Error 69, the PHP4 ldap error reads: "Cannot modify object class."

However, running v2.1.22 - and with every Openldap version I've ever run since 2.1.4 - I have the following objectclasses for each posixAccount user:


I even have others, non-Openldap standard - such as evolutionPerson and calEntry

So, your problem has nothing to do with schema conflicts as such.

schema conflicts occur only when you have a superior objectclass which does not allow a structural inferior objectclass. For example, there is a an obligatory hierarchy: top -> person -> organizationalPerson -> inetOrgPerson which has to be obeyed if you wish to use inetOrgPerson.

Similarly, if you together with inetOrgPerson try to add another /structural/ objectclass for which organizationalPerson is the superior, this will be denied you. There has to be a unique hierarchy. There are both /structural/ and /auxiliary/ objectclasses. You may add as many /auxiliary/ objectclasses as you wish, without invoking errors.

If this were not so, then you'd end up with a schema structure which "would not resemble the pig," to use a Norwegian expression. So, don't set schema checking off ;)

Error 69 is not telling you anything other than that ldapmodify (ldapmod()) can not do what you want at the moment - it just doesn't tell you why.

A tremendous tool to check all this with, is GQ (gtk).

Quite another thing is, that if you're making the jump to 2.1.x, this should be 2.1.22 and your database should be BDB 4.1.25. But that's another story :)



Tony Earnshaw

Mail: tonni@billy.demon.nl