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@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

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Howard Chu wrote:

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.

I this case, I'd recommend the initial poster files an ITS http://www.openldap.org/its/.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------