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.

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.

So still my suggestion is to distinguish validating a new DN from validating a DN of an *existing* entry.

Ciao, Michael.

Howard Chu wrote:

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.

Well, I know how to do things right. But sometimes I have to correct the results of false procedures done by others... ;-)

Ciao, Michael.

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.