Quanah Gibson-Mount wrote:
Upgrade to a current supported release, or file a bug with the
Debian
maintainers. The current OpenLDAP release tree is 2.4, and IIRC this is a
known issue fixed in the 2.4 series.
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.
--Quanah
--On November 24, 2008 3:52:48 PM +0100 Steffen Kaiser
<vm5015995887542392v(a)vmail.inf.fh-bonn-rhein-sieg.de> wrote:
> 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.
>
> ====
>
> Because I trust the sync provider I changed
>
> schemachecking=off
>
> of the syncrepl rid=123 entry
>
> Now I get this in the log:
>
> : syncrepl_entry: c=testww,ou=basedn : syncrepl_entry: be_modrdn (0) :
> syncrepl_entry: be_modify (0)
>
> For me it looks like that because of the sequence of the two operations,
> schema checking is not compatible with moddn and this should be noted
> in the man page.
>
> Bye,
>
> --
> Steffen Kaiser
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/