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


Thanks Quanah;

I was actually wondering if that would be the next step.  As stated in an
earlier email, it (syncrepl) worked once following the initial setup.  The
Consumer was a blank slate (as far as the automount maps, and rest of the
legacy NIS stuff was concernced); set up syncrepl and they all showed up on
the Consumer.  Then nothing from then on.  The replica/consumer is another
VM on another ESX machine.  No, one uses it (i.e. no clients are binding to
it, etc)...it was set up as a backup to the primary only.

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 2:53 PM
To: Borresen, John - 0442 - MITLL
Cc: openldap-technical@openldap.org

--On Wednesday, March 14, 2012 2:44 PM -0400 "Borresen, John - 0442 - 
MITLL" <john.borresen@ll.mit.edu> wrote:

> Quanah;

Pesonally, I use a specific replicator ID for replication that has full 
read to all data on the master, and make that the first ACL.  Then I don't 
have to worry whether or not the other ACLs interfere.  At this point, if 
you haven't, I'd wipe out the replicas DB and make it do a fresh sync, so 
you can confirm it is working properly, OR slapcat the master, and use the 
appropriate flags to slapadd to reload it, and then ensure the replica 
keeps up to date.  If you're using the replica as-is, where you've had an 
invalid configuration for days, I fully expect the data on the replica to 
be in an odd state.  Make sure nothing is using the replica if you choose 
to reload it in either method.



Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra ::  the leader in open source messaging and collaboration

Attachment: smime.p7s
Description: S/MIME cryptographic signature