What about the other issue - the connection limit? I would be delighted to use any build of 2.2.19 (it does everything I need), except that all of the builds I have seen for windows have a limit of 64 concurrent connections. The more recent builds have a limit of a few-thousand connections but without the "schemacheck off" feature so desperately need.

In addition to missing attributes required by the schema we also have extra attributes not required by core elements of the schema, and we also have malformed elements which do not have cn entries - I understand that this is not so much a violation of a schema but of the entire LDAP RFC. Unfortunately I am dealing with utterly crazy data which if I were to fix it would force me to re-test an entire application... it's a very big application which I mostly do not understand - that is why it's much simpler to make the new LDAP server work as much as possible like the old one.

While it would be inappropriate to repeat a historical flaming, my feeling is that it was a real nuisance to take a potentially useful feature which people were innocently (ab)using - it was abruptly removed without any simple migration path. I understand that disabling schema-checking would be a foolish thing to do in a conventional LDAP application (e.g. NIS), but many people use openldap for casual or experimental purposes for which it is very convenient to allow an "anything-goes" strategy.

:-)

On Wed, Jan 21, 2009 at 6:49 PM, Bill MacAllister whm@stanford.edu wrote:

--On Wednesday, January 21, 2009 01:35:25 PM +0000 Salim Fadhley < sal@stodge.org> wrote:

...

I've recently inherited responsibility for an LDAP server for a large business critical operation.

Unfortunately the previous developer simply added data with schema-checking off. They were using a very old version of OpenLDAP (which I can no longer use) which allowed them to disable all schema-checking. As a consequence the data is no longer compatible with the schema - all validation fails.

I want to disable all schema-checking on my new server, so I used the slapd.conf directive "schemacheck off" - however this seems to be ignored. I know this because when I attempt to add an un-declared attribute to an entry in the database, the change is rejected. I understand that the "schemacheck" config directive has been deprecated in recent versions of slapd: But is there any other way to achive the same thing?

I've been told that there is a class called "ExtensibleObject" - might this help? Please bear in mind that my database is big (approx 20Mb) and changing the data may break compatibility with the application.

All I really want is to re-create the same kind of "anything-goes" platform that we had with the old 2.2.19 slapd which allowed me to disable all schema-checking.

Thanks,

Sal

Years ago I wrote a flame to the list about the lost of this feature. No one actually thought that what I was concerned about was important and since then I have come around and joined that crowd. Better to just create a valid schema set that will work for you. It is not all that hard.

I am guessing that the real issue is that you have new attributes that do not appear anywhere in a loaded schema. It is possible that your unique attributes are not all that unique and are in an existing schema that is not being loaded. I would just search the files in the schema directory and see what I could find and load the schemas that will satisfy your requirements.

If the attributes are really new then the slowest part of creating the new schema entries is obtaining and OID arc. You need to go to < http://www.iana.org/cgi-bin/enterprise.pl%3E and fill out the form. An OID arc is free. And, yes, you can create one out of thin air, but if you do that there are others on this list that will slice up your liver for dinner.

This make seem like a lot of effort, but it is a one time job.

Bill

+-------------------------------------------------------- | Bill MacAllister whm@stanford.edu | Systems Software Programmer, ITS Unix Systems, Stanford University

--On Wednesday, January 21, 2009 09:06:19 PM +0000 Salim Fadhley sal@stodge.org wrote:

What about the other issue - the connection limit? I would be delighted to use any build of 2.2.19 (it does everything I need), except that all of the builds I have seen for windows have a limit of 64 concurrent connections. The more recent builds have a limit of a few-thousand connections but without the "schemacheck off" feature so desperately need.

In addition to missing attributes required by the schema we also have extra attributes not required by core elements of the schema, and we also have malformed elements which do not have cn entries - I understand that this is not so much a violation of a schema but of the entire LDAP RFC. Unfortunately I am dealing with utterly crazy data which if I were to fix it would force me to re-test an entire application... it's a very big application which I mostly do not understand - that is why it's much simpler to make the new LDAP server work as much as possible like the old one.

While it would be inappropriate to repeat a historical flaming, my feeling is that it was a real nuisance to take a potentially useful feature which people were innocently (ab)using - it was abruptly removed without any simple migration path. I understand that disabling schema-checking would be a foolish thing to do in a conventional LDAP application (e.g. NIS), but many people use openldap for casual or experimental purposes for which it is very convenient to allow an "anything-goes" strategy.

Just so we are clear, you want the developers to implement a feature that they don't agree with so that an application that is dependent on a broken data model won't have to be retested. You find someone that signs up for that make sure you let them know that I have a bridge for sale.

Having said that, really the only thing that has changed is that you have to define some schema elements. No where does the software say that they have to make sense. You will have to read the documentation enough to know how to create the new elements you require and relax syntaxes to allow your bogus data, but if you do that you will still be able to re-implement your "anything-goes" strategy.

Bill

+-------------------------------------------------------- | Bill MacAllister whm@stanford.edu | Systems Software Programmer, ITS Unix Systems, Stanford University