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

Re: v2.2.24 structural object class modification not allowed



Michael Ströder wrote:

Curt Blank wrote:


Kurt D. Zeilenga wrote:



At 12:58 PM 4/28/2005, Curt Blank wrote:



Now my question is, is this modification not allowed because I have
not allowed the Calendar application write access to the
structuralObjectClass attribute, or is it not allowed period?

The LDAP/X.500 information model does not allow changes to the
structural object class of an object. slapd(8) enforces this
aspect of the model.


Yeah well that's all fine and dandy but 2.0.27 didn't have this problem
and now because slapd(8) enforces that this problem exists.



2.0.27 was not strict enough in this regard and did not properly
validate non-compliant input data. But still the problem is your
directory data and not newer versions of OpenLDAP.


What is wrong with my directory data? That is what I am trying to determine and fix.

You have to sanitize your data. Period. Otherwise you could have
interoperability problems with other schema-aware LDAP applications as well.


"sanitize your data" what does not mean? The data that is in there was put in there by v2.2.24 slapadd and I would think that if 2.2.24 did not like the data it would not have let me put it in in the first place. Yes no?

The current problem is I can't add a Calendar user because the Calendar server need to give the dn the ctCalUser objectClass and for that to occur slapd needs to change structualObjectclasss for that dn to ctCalUser and it can't do that. It decides it has to do that itself but then it itself does not allow itself to do that. That just seems really stupid to me regardless of the technical need to do that.

So am I to add new users with every possible objectClass I may ever want to give them including the ones I don't know about yet and don't have defined in my schema yet??


Ciao, Michael.