On 05/16/2012 07:48 PM, Brad Schuetz wrote:
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:
https://fedorahosted.org/389/ticket/376
The fact that there are two result lines for the operation is a good
clue that something is going wrong.
--
Brad
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
