Re: Removing cn=config elements (Not at runtime)

[Ralf Haferkamp <rhafer@suse.de>]

On Dienstag 11 Oktober 2011 21:18:18 Jeffrey Crawford wrote:
> I have seen in the list archives that using ldapmodify to remove
> cn=config elements while openldap is running is not supported.
> 
> However I do need to be able to disable overlays in certain cases
> sometimes (Even if it's for testing). I tried shutting down the server
> and then modifying the cn=config directory area, by renaming the .ldif
> file to ldif.disable. That seems to work but I'm wondering if there
> are other caveats I should be considering when performing actions
> like that.
Making changes to the files in the slapd.d directory manually is a really 
bad idea. Seems you already found out one reason for that by yourself 
already :).

As slapd doesn't support deleting entries from cn=config during runtime 
yet your best bet currently is probably to "slapcat -n0" the config 
database to a file, remove the entries with you favorite editor (and 
renumber the remaining entries accordingly), then cleanup the slapd.d 
directory and re-add the configuration using:
slapdadd -n0 -l <your-config.ldif>
 
Note that the master branch in git contains delete support for cn=config, 
it will eventually endup in a release as well at some point. The SUSE 
rpms you can get from download.opensuse.org are also patched with 
backports of the delete code from git-master. In case you are using 
openSUSE or SLES you might want to try those.

> One thing I did notice is that it seems like the openldap server goes
> ahead and re-numbers the overlays so there are no gaps. however the
> cn=config filesystem area did NOT renumber the files and the server
> behaved strangely when I tried to ldapmodify the "disabled" config
> back into the running system. (I got a err=32 no such object using
> openldap 2.4.26) Stopping the server again and then renaming the
> extension .disable to .ldif brought everything back to where it was.
> As a side note the ldif I used to create the overlay is the same I
> tried to use in this last step.

Ralf
<