[Date Prev][Date Next]
Re: So I finally upgraded from slurpd...
On Fri, 9 Jul 2010, Quanah Gibson-Mount wrote:
> --On Thursday, July 08, 2010 7:04 PM +0200 Kolbjørn Barmen
> <firstname.lastname@example.org> 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.
> > When I start slapd on the slave I get on the slave:
> > ===================
> > 18:37:50 server.foo.no slapd: @(#) $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: slapd starting
> > 18:37:50 server.foo.no slapd: syncrepl_message_to_entry: rid=123
> > mods check (objectClass: value #0 provided more than once) 18:37:50
> > server.foo.no slapd: do_syncrepl: rid=123 rc 20 retrying 18:38:50
> > server.foo.no slapd: syncrepl_message_to_entry: rid=123 mods check
> > (objectClass: value #0 provided more than once) 18:38:50 server.foo.no
> > slapd: 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
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
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 :)