Re: So I finally upgraded from slurpd...

[Kolbjørn Barmen <kolbjorn.barmen@uninett.no>]

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!

-- 
Kolbjørn Barmen
UNINETT Driftsenter