[Date Prev][Date Next] [Chronological] [Thread] [Top]

Multiple syncrepl problems



Good day,

We've been fighting for a few months now, trying to get any version of
OpenLDAP to work on our servers (Fedora Core 2, db4-4.2.52-3.1, back-bdb).
We installed the software with a modified FC RPM.  The servers run well and
queries are fast, but getting LDAP Sync replication to work has been nothing
but a headache, unfortunately.  We're thinking it's about time to post a
message to this list...

We currently have a 2.2.19 provider with many 2.2.19 consumers, which has
been the most stable setup to date (no bdb corruption so far).  Consumer
syncrepl conf section is:

syncrepl rid=123
        provider=ldap://A.B.C.D:389
        type=refreshOnly
        interval=00:00:05:00
        searchbase="o=Shaw Cablesystems,c=CA"
        scope=sub
        schemachecking=on
        updatedn="cn=admin,o=Shaw Cablesystems,c=CA"
        bindmethod=simple
        binddn="cn=admin,o=Shaw Cablesystems,c=CA"
        credentials=xxxxxxxxxxxxxx

(interval is set low for testing)

Replication "sometimes" works.  One of the problems we noticed was that,
when bringing up a new consumer, the consumer would occasionally be trying
to add entries before their parent entries exist.  This obviously would
fail.  Some of the parent entries would eventually make it to the consumer,
but the child entries never make it.  Cleaning out the consumer's DB and
resyncing it shows that it misses exactly the same entries again.

We saw that there were numerous more syncrepl fixes in 2.2.20, so we thought
we'd give that a try.  We brought up a fresh 2.2.20 consumer against the
2.2.19 provider, but no entries get replicated at all.  The log on the
consumer shows:


slapd[23658]: bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52:
(December  3, 2003)
slapd[23658]: bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52:
(December  3, 2003)
slapd[23658]: bdb_db_init: Initializing BDB database
slapd[23663]: slapd starting
slapd[23663]: null_callback : error code 0x32
last message repeated 14086 times


Are we missing something here, or are we just running up against bugs?

Is LDAP Sync Replication considered stable on OpenLDAP, or should we instead
be using traditional slurpd replication?

Any help would be really, really appreciated.  More info can be provided if
needed.  Thanks,

============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948