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. -- Brad -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
