[Date Prev][Date Next]
Re: So I finally upgraded from slurpd...
--On Thursday, July 08, 2010 7:04 PM +0200 Kolbjørn Barmen
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).
What version of OpenLDAP is on the master? 2.3.30?
And on slave:
# updateref ldap://masterserver.uninett.no/
I'd still set updateref, so clients know where they should send updates.
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) $
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
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration