On Fri, 9 Jul 2010, Quanah Gibson-Mount wrote: > --On Thursday, July 08, 2010 7:04 PM +0200 Kolbjørn Barmen > <kolbjorn.bar...@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) $ > > ^ir...@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! -- Kolbjørn Barmen UNINETT Driftsenter