On 05/16/2012 06:24 PM, Rich Megginson wrote:
> On 05/16/2012 06:48 PM, Brad Schuetz wrote:
>> Is there any way that I can remove the nsTombstone entries from the
>> master server so I can get this under control? I think I found out why
>> I have so many nsTombstone entries in the first place so I'd like to get
>> the current ones deleted and see how much delete activity I'll have
>> moving forward.
>>
>> I saw this bug report,
>> <
https://bugzilla.redhat.com/show_bug.cgi?id=617862>, that seems to
>> indicate that I should be able to ldapdelete the nsTombstone entries
>> using their full dn, however it always says object not found.
> Can you provide
> 1) the exact ldapdelete command line
> 2) the excerpts from the access and errors log from around the time of
> the deletion
Here's the command with only the username part of the DN redacted and
the access log for the command, I confirmed that after the delete failed
that the entry was in fact still there by running the ldap search again
for nstombstone entries to be sure that it wasn't just a timing issue.
Also attempted the same command with quotes around the DN to delete.
The error log produced no entries around the time of the command being run.
ldapdelete -x -D 'cn=Directory Manager' -W
nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=aeria005,ou=Users,ou=System,dc=cust,dc=omnis,dc=com
This was the output from the above command:
ldap_delete: No such object (32)
matched DN:
uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com
access log:
17/May/2012:01:41:35 +0000] conn=947 fd=80 slot=80 SSL connection from
::1 to ::1
[17/May/2012:01:41:35 +0000] conn=947 SSL 256-bit AES
[17/May/2012:01:41:35 +0000] conn=947 op=0 BIND dn="cn=Directory
Manager" method=128 version=3
[17/May/2012:01:41:35 +0000] conn=947 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[17/May/2012:01:41:35 +0000] conn=947 op=1 DEL
dn="nsuniqueid=14403301-1dd211b2-9635fc8a-5f520000,uid=[redacted],ou=Users,ou=System,dc=cust,dc=omnis,dc=com"
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=1 RESULT err=32 tag=107
nentries=0 etime=0
[17/May/2012:01:41:35 +0000] conn=947 op=2 UNBIND
[17/May/2012:01:41:35 +0000] conn=947 op=2 fd=80 closed - U1
However I can report that the internal process seems to have finally
cleaned up the bulk of the entries, I had over 20k entries on the master
and it's finally down to less than 100. I temporarily changed the
values for when it should reap the entries to try and get it to clear
them out internally after I fixed the issue that I believe was
responsible for the extraneous deletes.
Good. I filed a ticket about the tombstone
deletion issue:
The fact that there are two result lines for the operation is a good
clue that something is going wrong.