On 05/17/2012 08:30 AM, Rich Megginson wrote: > 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. > Looks like my IO issue is resolved now that the tombstone entries aren't going crazy. Thanks for the help everyone. -- Brad -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
