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