Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
If one plays around with schema and an attribute type used in the RDN of an entry is no longer present then this entry is no longer readable because whenever a request is sent to slapd invalidDNSyntax is returned. This leads to the situation that a client can't even explicitly delete this offending entry anymore.
I'd vote for relaxing the schema-based DN checking in case of search, rename (only old DN), modify and delete requests a bit so that after a schema change the data can be corrected with normal client tools without server down-time.
Any thoughts on this?
"Don't do that."
I expected you to say this but IMO it's not that simple. It's sometimes required to remove schema elements in case of bad schema design. I consider it one of the advantages of OpenLDAP that this is possible. And in fact slapd starts without checking whether *existing* entries all are compliant to the current schema. But then non-compliant entries are not accessible anymore at all. So you can't clean up the data via LDAP without down-time.
Then you should have been more careful and removed the offending entries before removing the schema element.
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.
It's not much effort for you to ldapsearch (badattr=*) and delete/modify those entries before you modify the schema.
Cleaning up now requires stopping slapd, slapcat, tweak LDIF, slapadd, start slapd
This can be a huge pain if the number of non-compliant entries are rather small compared to the overall number of entries.
Yes, and the fact that it is such a pain should discourage you from making this mistake more than once.