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.

--Quanah --On November 24, 2008 3:52:48 PM +0100 Steffen Kaiser <vm5015995887542392v(a)vmail.inf.fh-bonn-rhein-sieg.de&gt; 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