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
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/