On Fri, 9 Jul 2010, Quanah Gibson-Mount wrote:

--On Thursday, July 08, 2010 7:04 PM +0200 Kolbjørn Barmen kolbjorn.barmen@uninett.no wrote:

...

I have at last upgraded a system from using slurpd (debian etch, slapd 2.3.30) to using replsync, at least that was the intention.

I believe you mean SyncRepl (Sync Replication).

Yes - ofcourse :)

What version of OpenLDAP is on the master? 2.3.30?

It is running 2.4.23.

...

syncrepl rid=123 provider=ldaps://masterserver.uninett.no:636/ type=refreshOnly interval=00:00:00:10 retry="60 +" searchbase="dc=foo,dc=no" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=foo,dc=no" credentials="f00bAr123"

I highly advise using refreshAndPersist rather than refreshOnly.

Right! :)

...

When I start slapd on the slave I get on the slave:

18:37:50 server.foo.no slapd[7971]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 5 2010 18:35:50) $ ^Iroot@localhost:/home/kolla/openldap/openldap-2.4.23/debian/build/server s/slapd 18:37:50 server.foo.no slapd[7972]: slapd starting 18:37:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) 18:37:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying 18:38:50 server.foo.no slapd[7972]: syncrepl_message_to_entry: rid=123 mods check (objectClass: value #0 provided more than once) 18:38:50 server.foo.no slapd[7972]: do_syncrepl: rid=123 rc 20 retrying ===================

I would advise you start the slave with the "-d -1" options passed to the slapd binary, so you can see exactly what the master is sending to the replica. It sounds like it is sending invalid data. This could be a bug in the version that the master is running. You might want to try running a separate master for testing, that uses OpenLDAP 2.4.23 as well. There have been a multitude of fixes to the syncrepl code in OpenLDAP since the 2.3 series.

Both slave and master are running 2.4.23.

After som debugging I found the culprit, turned out the error message "(objectClass: value #0 provided more than once)" was a nice hint. (allthought I don't quite see what "value ¤0" is supposed to tell me)

Just by coincident I tried to change the object "cn=admin,dc=foo,dc=no" on the master with an ldap editor (gq), and got the same error message in return.

It turned out that the object cn=admin,dc=foo,dc=no had multiple occurances of "objectClass: organizationalRole" (!), and this also prevented syncrepl from working. I suspect it was a result of "manual" editing of ldif files followed by an import using slapadd. I get no warnings from slapadd when I import import objects with multiple occurances of the same objectClass.

Perhaps slapadd/slapd should be able to deal with such duplicate entries better, to make it more obivous what's wrong? I'm just saying :)

Thanks!