Re: (ITS#4417) DELETE does not propagate in syncrepl'ed subordinate

[hyc@symas.com]

Thanks for the report. This bug affected refreshAndPersist mode (which 
is used in test033) but not refreshOnly. It is now fixed in HEAD and an 
ldapdelete check has been added to test033.

alderoth@free.fr wrote:
> Full_Name: 
> Version: 2.3.19
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.67.227.127)
>
>
>
> When an entry located in a subordinate (glued) syncrepl'ed database is deleted,
> the delete operations are not propagated to the replicated directory.
>
> This can be easily reproducted using test033:
> - run test033 with 'preserve' and 'don't stop' options : ./run -p -k test033
> - delete an entry from "ou=Information Technology Division, ou=People,
> dc=example, dc=com" on localhost:9011. This subtree is replicated to
> localhost:9012 :
>
> $ cat ld.ldif
> dn: cn=Barbara Jensen,ou=Information Technology
> Division,ou=People,dc=example,dc=com
> changetype: delete
>
> $ ldapmodify -x -H ldap://localhost:9011 -D "cn=Manager 1,dc=example,dc=com" -w
> secret < ld.ldif
> deleting entry "cn=Barbara Jensen,ou=Information Technology
> Division,ou=People,dc=example,dc=com"
>
> <wait a few seconds>
>
> $ ldapsearch -LLL -H ldap://localhost:9012 -b "cn=Barbara Jensen,ou=Information
> Technology Division,ou=People,dc=example,dc=com" "" "objectclass"
> dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,
>  dc=com
> objectClass: OpenLDAPperson
>
> The entrie is still there.
>
> Restarting both the master and the slave does not solve the problem.
> If deleting while slave is down, the entry is not deleted when the slave is
> back.
>
> Other operations seem to be correctly propagated.
>
>
>   


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/