Re: still unclear on error 69

[Tony Earnshaw <tonni@billy.demon.nl>]

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.

Noted.

> 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:

top
person
organizationalPerson
inetOrgPerson
posixAccount
shadowAccount
inetLocalMailRecipient

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 :)

HTH,

Tony

--
Tony Earnshaw

http://www.billy.demon.nl
Mail: tonni@billy.demon.nl