Quanah;
A question about the "entryCSN" attributes, the three zeros (entryCSN:=
20120308173545.066786Z#000000#000#000000) between the #-marks correspond to
the Server ID, correct? If they do, why are some "000" and others
"001"
when I only have one server?
Thank you for your assistance on getting me over the syncrepl wall.
I noticed in the 2.4 Admin Guide that configuring the monitor database for
cn=config has not been published yet; and, there isn't a lot online, period,
about it. The manpages are not overly helpful either from cn=config is
concerned.
I am seeing this: "bdb_monitor_db_open: monitoring disabled; configure
monitor database to enable"
on both the Provider and Consumer.
Can you recommend something, relevant to cn=config monitor setup?
Thanks again for your help.
David Borresen
ph: 781-981-2954
email: john.d.borresen(a)ll.mit.edu
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Wednesday, March 14, 2012 4:53 PM
To: Borresen, John - 0442 - MITLL
Cc: openldap-technical(a)openldap.org
Subject: RE: OPENLDAP SYNCREPL
--On Wednesday, March 14, 2012 4:25 PM -0400 "Borresen, John - 0442 -
MITLL" <john.borresen(a)ll.mit.edu> wrote:
Saw a post of yours from a while back, so I backed up the
consumer's dbase
and moved the directory out of the way, then ran slapadd and brought slapd
up on the consumer.
Yes, when you go to reload a server, you must delete the existing DB.
Things look more in-sync with each other than they did.
Question: I noticed that there are seven "reqStart" entries in the
cn=accesslog on the Provider machine. They were there when I was testing
and beating my head against the wall. Should they be deleted manually
since I used slapcat/slapadd? Or does it matter?
It doesn't matter. The point of syncrepl is it is intelligent enough to
ignore data it's already replicated.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration