Re: Deleting overlays from cn=config

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")