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

Re: v2.2.24 structural object class modification not allowed

Thank you! You made some very good points here, especially the idea *to* do a reload to insure conformity, I never thought of it that way.

But I never realized until now, and all these issues I've encountered in going to 2.2.24 that this was the case, i.e. the rules not being enforced in the first place and now that's all catching up to me. This has been a very eye opening experience. I *assumed* that in some cases getting vendor supplied schema for *their* application they knew what they were doing. How foolish of me. ;)

Kurt D. Zeilenga wrote:

At 11:49 AM 4/29/2005, Curt Blank wrote:

More then willing to do that, been trying to to that on a lot of this stuff, but where? I'm not an expert on this stuff by any means, I wish I could find someplace that explains all this in layman terms, as of yet I have not found that place...

Well, if you cannot find a good reference in the OpenLDAP FAQ <http://www.openldap.org/faq/>, I suggest you ask assistance on a general list about LDAP. See <http://www.openldap.org/lists/> and its references for suggestions here.

Or will I have to dump and reload LDAP.

First, I'm not advocating any schema design, or even any schema design approach, here. How to design schema in general, or in face of a particular clients needs, is not terribly specific to OpenLDAP Software (and a topic for more general forums). One just needs to adhere to the LDAP/X.500 models regardless of what server one uses. Assuming your server enforces all aspects of the LDAP/X.500 models is, generally, a poor assumption.

That said, I do believe it generally appropriate when using
slapd(8) to dump and reload data after making significant
schema changes.  This not only ensures the data is conformant
(to the degree the server checks conformance) to the current
schema, but ensures that any details within the server dependent
on old data and/or old schema are flushed out.