On Mon, Aug 11, 2003 at 01:50:53PM -0700, Kurt D. Zeilenga wrote: > I note that the HEAD code is designed such that each entry must > have a single structural object class, per X.501, for things to > work right. Things will break without this (such as the remaining > schema checks). Keeping the remaining schema checks was my first goal (in the other case, I would just have used schemacheck off !), and I made a few successfull tests which shows that my patch "seems to work"... > The side effects of your change are more > significant than I think you realize. In fact, that's one of the reasons why I first posted here, instead of just sending a submit report on the web site ! > We currently also require the structural class of an entry not > to change. This is because changing applicable content rule, > structure rule and name forms makes little sense. However, it > seems possible that the server could work properly whilst allowing > such changes (at least in current HEAD). I currently use this patch in some test servers, and it seems to work. But I would like to have some feedback from experienced slapd developpers, and of course, it would be great if this patch could be submitted (no more patches to do with newer versions, code test/modifications when needed, etc...). VANHULLEBUS Yvan. > Kurt > > At 12:46 AM 8/11/2003, VANHULLEBUS Yvan wrote: > >Hi. > > > >I recently upgraded some servers from an OpenLDAP 2.0 to > >OpenLDAP 2.1.22, and had problems with schema structure checks. > > > > > >As modifying my schemas (then all the base entries !) was not easy to > >do (it could not really be donne by a program), and as I didn't like > >do completly desactivate schemacheck, I made a quick patch to add a > >'structuralcheck' option on slapd.conf (like the "schemacheck" > >option). > > > >With this option, slapd does not checks the schema structure anymore > >(STRUCTURAL/AUXILIARY) but stills checks other "basic things" (if the > >attribute exists, etc...). > > > > > >Here is my patch, please comment if I missed something, if something > >is wrong, etc... I'll submit it in a few days if there is no problem > >with it. > > > >Please note that this patch is probably not "optimal", I wanted to > >modify as little code as possible. > > > > > >Regards, > > > >VANHULLEBUS Yvan. > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature