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?