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@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@openldap.org Subject: RE: OPENLDAP SYNCREPL
--On Wednesday, March 14, 2012 4:25 PM -0400 "Borresen, John - 0442 - MITLL" john.borresen@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