Hallvard B Furuseth wrote:
You also need to walk through the database and delete any attributes object classes defined by the overlay. That'll be at least any operational attributes since they must be hardcoded into the C source.
I wouldn't bother with that, since the schema definitions are still present. Those attributes would simply stop being updated/generated...
On the other hand, if the overlay is a dynamically loaded module, and you want to unload it (by deleting the moduleLoad) then all of its schema needs to be unregistered, etc. I already mentioned this at some point in the past, that we need to write fini() entry points for all of our dynamically loadable modules...
Only the overlay can know how to do this, so the overlay needs undo_me() code. Then that code must figure out how to interact with backends and other overlays - like translucent. Or how to figure out whether it is able to figure it out, and return LDAP_UNWILLING_TO_PERFORM if not.
I don't quite remember how ppolicy works but I assume it can "deactivate" an existing userPassword attribute. If so it also needs a policy about what to do with deactivated userPasswords which will be reactivated when ppolicy is deleted. I.e. should these userPasswords be deleted? And if an overlay does that - deletes data which might not be managed by itself - then things could get _really_ hairy to get right...
I think that's wrong. When you remove an overlay, you should expect to lose all the functionality that the overlay provided. If the overlay had locked an account, the lock will simply disappear when the overlay is removed.