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. 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...

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.

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...

Howard Chu wrote: > 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... Hmm, I'd consider this to be seriously flawed. It strikes me that there might still exist operational attributes in some entries which are no longer maintained by the DSA and there's no schema information available anymore. Think of backup/restore situations where slapadd checks the schema...

On 6/5/08 11:50 AM, Michael Ströder wrote: > Howard Chu wrote: >> 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... > > Hmm, I'd consider this to be seriously flawed. It strikes me that > there might still exist operational attributes in some entries which > are no longer maintained by the DSA and there's no schema information > available anymore. > > Think of backup/restore situations where slapadd checks the schema... How is that different from pre-cn=config setups where the administrator shut down slapd and removed the schema from the slapd.conf and restarted slapd? It's the same administrative responsibility to remove the use of the schema (and the attributes in the database) before removing the schema definition.

On Friday 06 June 2008 18:58:11 Michael Ströder wrote: > Francis Swasey wrote: >> On 6/5/08 11:50 AM, Michael Ströder wrote: >>> Howard Chu wrote: >>>> Hallvard B Furuseth wrote: >>>>> You also need to walk through the database and delete any attributes >>>>> object classes defined by the overlay. IMHO, configuration changes should not result in changes to data.

IMHO, the cleanest would be for any configuration change which would remove schema definitions should do a search for the use of those schema definitions, and fail with a suitable message if any of the schema definitions are in use.

The problem though is that at present some data (whose attribute definitions are marked as "NO-USER-MODIFICATION") cannot presently be removed. ppolicy attributes (pwdAccountLockedTime etc.) come to mind.

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...

> (...) I.e. should these userPasswords be deleted? (...) 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.

Ralf Haferkamp wrote: > Hi, > > as back-config does currently not have support for the delete > operation (config_back_delete() just returns > LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out what > is needed to get at least delete support for simple overlays (e.g. > ppolicy or memberof) running. Very brave of you. ;)

> I am a bit unsure about the db_destroy() part. Is that enough or is > it needed to call the db_close() hooks (when provided by the > overlay) before calling db_destroy()? Did I miss something else? Is > anybody else currently working on this? You should call the db_close() hook first. > Up to now I am testing this only with some simpler overlays > (memberof, pcache), I assume that deleting overlays that > instantiate their own databases (like pcache, translucent(?)) might > get a little more hairy. Right. We need to distinguish between tearing down due to a normal shutdown, which should leave underlying data intact, and tearing down due to removal...

On Donnerstag, 5. Juni 2008, Howard Chu wrote: > Ralf Haferkamp wrote: > > Hi, > > > > as back-config does currently not have support for the delete > > operation (config_back_delete() just returns > > LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out > > what is needed to get at least delete support for simple overlays > > (e.g. ppolicy or memberof) running. > > Very brave of you. ;) > > > What I am currently doing is: > > - renumber the indexes of the siblings of the overlay that's > > going to be deleted > > - remove the CfEntryInfo of the overlay from the internal config > > tree - remove the Entry from the underlying LDIF database > > > > Additionally I need to remove the overlay's slap_overinst > > structure from the overlay list of the backend and in case it was > > the last overlay, restore the original BackendInfo structure and > > delete the SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB > > structure of the underlying database (for global overlays). > > Currently I use the overlay_destroy_one() function for this task. > > This also calls the db_destroy() hook of the overlay which should > > take are of free resources held by the overlay. > > > > I am a bit unsure about the db_destroy() part. Is that enough or > > is it needed to call the db_close() hooks (when provided by the > > overlay) before calling db_destroy()? Did I miss something else? > > Is anybody else currently working on this? > > You should call the db_close() hook first. Ok. I implemented that in a separate function (overlay_remove()) now. Basically that calls the db_close and db_destroy hooks, removes the overlay from the oi_list and cleans up the BackendDB structure when the last overlay is being removed. I have some preliminary code for back-config delete support ready I think. It currently only supports overlays which do not instantiate child objects (pcache, translucent) and does not touch any data the overlay might have created in the underlying database. I hope to be able commit that code during the next days. Should it be hidden behind #ifdefs for now? (Probably be enabled with "LDAP_DEVEL")