(ITS#5901) modrdn syncing busted

[quanah@zimbra.com]

Full_Name: Quanah Gibson-Mount
Version: 2.4.13
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.29.239)


As noted in a post to the bugs list:

Hello,


I have configured a central OpenLDAP, using Debian Etch, version: slapd
2.3.30-5+etch1, which is also a sync provider.

Another Debian Etch box uses the sync:
syncrepl rid=123
        provider=ldap://example.com
        type=refreshAndPersist
        retry="5,2,30,2,60,+"
        interval=00:01:00:00
        searchbase="basedn"
        filter="(objectClass=*)"
        scope=sub
        attrs="*,+"
        sizelimit=0
        timelimit=0
        schemachecking=on
        bindmethod=simple
        binddn="someDN"
        credentials="somePwd"
        starttls=critical


This works fine, but moddn fails:


for testing purpose I ldapadd :


dn: c=testtt,ou=basedn
c: testtt
objectClass: country


then:


ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww'


It works on the sync provider (schemacheck on)


and the result is:


dn: c=testww,ou=basedn
objectClass: country
c: testww


But on the sync consumer:


: syncrepl_entry: c=testww,ou=basedn : Entry (c=testww,ou=basedn attribute 'c'
cannot have multiple values : entry failed schema check: attribute 'c' cannot
have multiple values : null_callback : error code 0x13 : syncrepl_entry:
be_modrdn (19)

The testtt entry is still present on the secondary box.


If I delete "testww" on the sync provider, the "testt" entry in the consumere is
deleted.



As noted by Howard in follow up:

Actually... this would have worked correctly in 2.4.11 and 2.4.12. In 2.4.13 I
reverted back to the 2.3 behavior due to other concerns, so this will probably
fail again. And the test script does a rename on an entry whose distinguished
attribute is multivalued, so it doesn't catch this case. I think we'll have to
revisit this patch for 2.4.14 and add an additional rename test to test017 and
test018.