[Date Prev][Date Next]
Re: still unclear on error 69
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
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
>> 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
- 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?
What database (bdb, ldbm) are you using? Version?
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).