Re: still unclear on error 69

[Jon Roberts <jon@mentata.com>]

Tony Earnshaw wrote:
> Logical thinking: If what you had worked before and does not work any
> longer, what could possibly have changed in your setup to have altered
> this?

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.

>> Using OpenLDAP 2.1 and I'm running into an issue trying to extend an
>> entry to include participation in new objectclasses (e.g. extending a
>> person entry with objectclasses organizationalperson and
>> inetorgperson). This used to work fine, but now I get an LDAP 69 error
>> (object class mods prohibited).

When I say "extending" what I mean in this case is that I'm modifying 
the values for the "objectclass" attribute for an entry to add new 
values "organizationalperson" and "inetorgperson". I've never 
encountered this error code before, but one definition I googled reads

69: Indicates that the modify operation attempted to modify the 
structure rules of an object class

I found another clue in RFC 2251:

Servers may restrict the modifications of [the objectclass] attribute to 
prevent the basic structural class of the entry from being changed

I'm using a REPLACE, so maybe that's the only thing that's not allowed, 
but I'm curious about the specifics. I guess my questions are:

What condition could be throwing this error code?
How can you augment the objectclass attribute for a person entry if such 
a mod is prohibited?

I couldn't find anything about this in the OpenLDAP documentation, but 
if somebody can give me a definitive answer, I'll try to add it to the 
FAQ-o-matic myself.

<snip>
> - have you changed your Openldap 2.1 version?
> - have you had to reset your machine?
> - have you had to reboot your machine?
> - have you over strained/overloaded your installation?
> - have you re indexed?
> etc.
> What database (bdb, ldbm) are you using? Version?
</snip>

My installations are getting better and more up to date, but the machine 
in question is a bang box with OpenLDAP 2.1.13 using ldbm/gdbm. I've 
made many, many changes since last testing objectclass extension, so 
this sort of troubleshooting is moot. I don't get the impression this is 
a state-dependent behavior, though.

> Could you have exceeded file size boundaries?
> Could you have exceeded environment boundaries?

I'm sure this is not it.

> > Does this mean there is no way to modify the objectclass attribute of 
> > an entry through the protocol without turning schema checking off?
>
> You wouldn't want to do this, would you? 

I absolutely do *not* want to have to turn schema checking off. I want 
to presume it's always on. I like schema checking :)

> Why have you never had to before?

My question (and Geert's).

Jon Roberts
www.mentata.com