Howard Chu writes:
Michael Ströder wrote: Then you should have been more careful and removed the offending entries before removing the schema element.
First you may need to tweak access controls so someone can't insert a new offending attribute after you've cleaned up. That'a a step more "dangerous" (more serious mistakes are possible) than fiddling schema. And stop any processes that can write them as rootdn. All in all, dynamic schema changes can grow to be a rather big affair.
OTOH, with some schema changes you must slapcat/slapadd anyway. E.g. if the syntax of an indexed attribute is changed. Supposedly that should not happen, but in real life it does. And not only with private schema, so the LDAP admin might not have any blame for that.
This is somewhat analogous to an upgrade - you must slapcat using the old software before deleting it and replacing it with the new software. If you saw off the branch you're sitting on, you have no one else to blame when you fall off the tree.
That does depend on how easy it is to saw off the branch without sitting on it. OpenLDAP can take some credit/blame for that one.
In any case, from user perspective I'd favor a control which relaxes schema requirements when parsing entries, but it should not be on by default. From an OpenLDAP-internals perspective, such bogus DNs may be less thrilling. Haven't looked too closely, but OpenLDAP code does sometimes assume that internal operations like parsing an entry's DN will succeed.