[Date Prev][Date Next]
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
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
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
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 :)