Red Hat Bugzilla – Bug 1255557
db2index creates index entry from deleted records
Last modified: 2016-11-03 16:35:41 EDT
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/48252 1) Create the entry # ldapadd -cvvvv -D "cn=Directory Manager" -W -f /root/ldif/create-posix-user2.ldif ldap_initialize( <DEFAULT> ) add objectClass: top account posixAccount shadowAccount add cn: Non Secure User add uid: user80 add uidNumber: 80 add gidNumber: 80 add homeDirectory: /home/insecure add loginShell: /bin/bash add userpassword: {CLEAR}redhat adding new entry "uid=user80,ou=People,dc=coe,dc=muc,dc=redhat,dc=com" modify complete 2) Check the index file # dbscan -f /var/lib/dirsrv/slapd-tscherf54/db/userRoot/gidNumber.db4 |grep "=80" =80 3) Delete the entry # ldapdelete -vx -D "cn=Directory Manager" -W "uid=user80,ou=People,dc=coe,dc=muc,dc=redhat,dc=com" ldap_initialize( <DEFAULT> ) deleting entry "uid=user80,ou=People,dc=coe,dc=muc,dc=redhat,dc=com" 4) Verify the value from deleted entry has been removed from index # dbscan -f /var/lib/dirsrv/slapd-tscherf54/db/userRoot/gidNumber.db4 |grep "=80" # 5) Run db2index again # /usr/lib64/dirsrv/slapd-tscherf54/db2index.pl -n userRoot -D "cn=Directory Manager" -W -t gidNumber adding new entry "cn=db2index_2015_8_19_10_34_41, cn=index, cn=tasks, cn=config" 6) Value from removed entry shows up in index file again # dbscan -f /var/lib/dirsrv/slapd-tscherf54/db/userRoot/gidNumber.db4 |grep "=80" =80 7) ldapsearch fails to find the removed entry and there is also nothing related in the error log: # ldapsearch -x gidNumber=80 # extended LDIF # # LDAPv3 # base <dc=coe,dc=muc,dc=redhat,dc=com> (default) with scope subtree # filter: gidNumber=80 # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Bug Verified 1) Create the entry [root@test dirsrv]# ldapadd -D "cn=Directory Manager" -w test1234 -p 389 -h localhost -f /tmp/user2.ldif adding new entry "uid=user80,ou=People,dc=example,dc=com" 2) Check the index file [root@test dirsrv]# dbscan -f /var/lib/dirsrv/slapd-test/db/userRoot/cn.db | grep =user80 =user80 3) Delete the entry [root@test dirsrv]# ldapdelete -vx -D "cn=Directory Manager" -w test1234 -p 389 -h localhost "uid=user80,ou=People,dc=example,dc=com" ldap_initialize( ldap://localhost:389 ) deleting entry "uid=user80,ou=People,dc=example,dc=com" 4) Verify the value from deleted entry has been removed from index [root@test dirsrv]# dbscan -f /var/lib/dirsrv/slapd-test/db/userRoot/cn.db | grep =user80 5) Run db2index again [root@test dirsrv]# /usr/lib64/dirsrv/slapd-test/db2index.pl -n userRoot -D "cn=Directory Manager" -w test1234 -t cn.db Successfully added task entry "cn=db2index_2016_7_7_15_29_50, cn=index, cn=tasks, cn=config" 6) Value from removed entry shows up in index file again [root@test dirsrv]# dbscan -f /var/lib/dirsrv/slapd-test/db/userRoot/cn.db | grep =user80 7) ldapsearch fails to find the removed entry and there is also nothing related in the error log: [root@test dirsrv]# ldapsearch -D "cn=Directory Manager" -b "dc=example,dc=com" -h localhost -p 389 -w test1234 "(cn=user80)" # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (cn=user80) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html