Fastest way of deleting a DIT

Hi,

We have a chained suffix which is connected to 4 back end suffixes. Each of these 4 suffixes have their counterparts in another node, and they have a replication agreement.

And the whole system is duplicated on another geographical redundancy center.

4 + 4 in the main data center

4 + 4 in the geographical data center

A total of 16 slapd instances are running, and they are all suppliers (writable) with 4 way multi-master configuration in place :).

My question is, i want to delete all the entries under a suffix, and i want it to be very fast. And also, i don't want any trouble regarding these replication agreements during the delete operation. Version is 5.2.

What is the fastest, trouble free way to do it?

Thanks for your time and best regards,

Ogun

[823 byte] By [oghepera] at [2007-11-27 8:18:52]
# 1

If you mean fast in terms of the human effort, then I've done the following at the Unix shell (or cygwin's bash for Windows users). This will not be the most efficient for system resources, but often the human effort and time far exceeds the system effort.

*** USE AT YOUR OWN RISK, IT'S EASY TO MAKE A BIG MISTAKE. ***

TRY LOOKING AT THE RESULTS OF EACH STEP TO MAKE SURE IT'S WHAT YOU WANT BEFORE GOING ON TO THE NEXT STEP.

With multi-master replication make sure all your work for this session will hit exactly one server (and always the same one). Let replication do its job.

It's probably much safer to make sure that ALL referrals, aliases, and the like within your target area are deleted before proceeding.

(1) Run ldapsearch to get the DN (and only the DN) to list all the entries you want to delete. Be sure to use the ldapsearch from the DSRK with the "-T" option so that it doesn't wrap the lines (which makes things very unpleasant).

If you have any entries which are hidden from anonymous searches then make sure to bind your ldapsearch with an appropriate identity.

(2) Pipe the results through egrep so that only the dn: lines are matched (the regexp '^dn:

' will do this.

(3) Pipe the output through sed to strip off the leading "dn: " (the command "sed -e 's/^dn: //'

" should do this).

(3a) Directory Server 5.2 (and probably others) will happily delete the entry at the top of the suffix. If you don't like this then run the results through egrep -v to exclude the suffix's DN. Make sure that your regular expression will actually match the suffix's DN as returned by ldapsearch.

If you do accidentally clobber the entry and wish to retain it, the 5.2 Directory Server Console has an option to recreate that entry.

Now you've got the DN's to delete.

(4) Optionally find a way to sort these according to their hierarchy. This is relatively easy to do in perl or other high powered scripting languages, but it's moderately annoying to do in the shell (I would actually use perl -e from a shell script here).

If I'm feeling lazy I often won't bother sorting it. Instead I'll give the "-c" flag to ldapdelete (in step 5) so that it will continue beyond the errors for the non-leaf containers. Then I'll just hit up arrow and repeat the process (the ldapsearch results should get smaller on every pass). Keep repeating until you've cleaned up the tree.

(5) Take that (possibly sorted) list of DN's and feed it to ldapdelete.

If you're like me and build complex shell commands at the command line you can do this all in a single pipeline for a one-time action. Make sure to test the output of each stage of the pipeline before proceeding. I've omitted options which aren't important for understanding.

THIS NEEDS TO BE TAILORED TO YOUR NEEDS BEFORE USING IT. DON'T USE THIS IF YOU DON'T UNDERSTAND IT. USE AT YOUR OWN RISK.

THERE IS NO ERROR HANDLING OR CHECKING IN THIS EXAMPLE, IT IS DEPENDENT ON THE USER DOING ALL ERROR HANDLING. BECAUSE OF THIS IT SHOULD NOT BE PLACED INTO A SCRIPT WITHOUT APPROPRIATE ERROR HANDLING.

(Make sure to use the ldapsearch & ldapdelete from the DSRK, these should be in $serverroot/shared/bin). This doesn't bother sorting hierarchically and uses -c for ldapdelete instead (which has its own downsides).

$ ldapsearch -T -h 'server1' -D 'admindn' -w - -b 'basedn-for-deletion' -s sub '(objectClass=*)' dn \

| egrep '^dn: ' \

| sed -e 's/^dn: //' \

| egrep -v '^basedn-for-deletion$'

| ldapdelete -T -h 'server1' -D 'admindn' -w - -c

You'll have to enter the password for admindn twice, and it's possible you might not see a password prompt.

-Scott-

Scott.R.Corzinea at 2007-7-12 20:07:10 > top of Java-index,Web & Directory Servers,Directory Servers...
# 2

Amazing work Scott!

I am not sure of how expensive a move would be. You could move the DIT top node that you want deleted to some other place in the tree (like a temp DC / OU ,etc). Once that is done, you can keep deleting it at your leisure. For your apps etc, the DIT has effectively been deleted.

Why I am not sure if this is efficient enough or not is because i am assuming that relative DNs are calculated on the fly, so a move would constitute just a pointer shift.

Appreciate anyone correcting me on this.

Thanks!

Ankush

ankushkapoora at 2007-7-12 20:07:10 > top of Java-index,Web & Directory Servers,Directory Servers...
# 3

This might be another option.

1. Take a replica backup of the suffix you want to be cleaned up

2. Copy the suffix entry from the above file to another file (say tmp.ldif)

3. ldif2db this file (tmp.ldif) to the suffix and you should have nothing in the suffix after this except for the base entry.

4. Now push this thru to other replica's of the suffix and you should be done

As always test it on a non-prod system to start with.

HTH

LostLada at 2007-7-12 20:07:10 > top of Java-index,Web & Directory Servers,Directory Servers...