Chris Card wrote:
Michael Ströder wrote:
Chris Card wrote:
Howard Chu wrote:
Michael Ströder wrote:
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the
Howard Chu wrote:
Michael Ströder wrote:
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the contextCSN to check that replication is in sync, but I've
noticed
Michael Ströder wrote:
Chris Card wrote:
Howard Chu wrote:
Michael Ströder wrote:
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the contextCSN to check
Hi All,
I am running openldap 2.4.36 with BDB for my main backend db, and multi-master
replication setup using delta-syncrepl with MDB for the cn=accesslog db.
I monitor the contextCSN to check that replication is in sync, but I've noticed
what looks like a bug:
If I try to delete a
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the contextCSN to check that replication is in sync, but I've
noticed what looks like a bug:
If I try to
Michael Ströder wrote
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the contextCSN to check that replication is in sync, but I've
noticed what looks like
Michael Ströder wrote:
Chris Card wrote:
I am running openldap 2.4.36 with BDB for my main backend db, and
multi-master replication setup using delta-syncrepl with MDB for the
cn=accesslog db.
I monitor the contextCSN to check that replication is in sync, but I've
noticed what looks like a
On 07/31/2013 12:36 PM, Tony Davis wrote:
Hi,
I wonder if anyone can help me with a question I have regarding an
openldap setup on Redhat / Centos 5.8 using openldap-2.3.43.
I am trying to setup replication, I have set this up using the simple
bind method, which stores a password for the
Hi!
I'm trying to implement a Kerberos server using an OpenLdap backend on a
server called *ldap1.vm* and replicate those on an other called *ldap2.vm*.
My first server is working fine. Each kerberos principal is stored in
his own ldap entry (with the krbPrincipalName attribut).
For exemple
I solved this issue. It was in fact a mistake in my ACL directives.
For those who try to build a master-master replication between LDAP
servers, for both cn=config DIT and dc=exemple,dc=com, my config DIT
look like this :
On ldap1.vm :
=
dn:
Hi,
Hi,
I've been having issues with syncrepl in openldap. This is plain
syncrepl. I'm not using delta-syncrepl as I run with mirror mode on.
I've noticed that when there are a large number of writes on the
writemaster (Typically around 10 per second) the data on the readslave
goes
ph: 781-981-2954
email: john.d.borre...@ll.mit.edu
-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@zimbra.com]
Sent: Tuesday, March 13, 2012 6:40 PM
To: Borresen, John - 0442 - MITLL
Cc: openldap-technical@openldap.org
Subject: RE: OPENLDAP SYNCREPL
--On Tuesday, March 13
- 0442 - MITLL
Cc: openldap-technical@openldap.org
Subject: RE: OPENLDAP SYNCREPL
--On Tuesday, March 13, 2012 4:10 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
My apologies for sounding stupid...but, I really don't see it. Out of
utter frustration, I have tried to run
- MITLL
Cc: openldap-technical@openldap.org
Subject: RE: OPENLDAP SYNCREPL
--On Wednesday, March 14, 2012 2:44 PM -0400 Borresen, John - 0442 -
MITLL john.borre...@ll.mit.edu wrote:
Quanah;
Pesonally, I use a specific replicator ID for replication that has full
read to all data on the master
--On Wednesday, March 14, 2012 4:25 PM -0400 Borresen, John - 0442 -
MITLL john.borre...@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
All,
I've read and re-read (not to mentioned googled) configuring SyncRepl in
OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something
somewhere. Current logging is set to 256 on both Provider and Consumer.
On my Master/Provider LDAP server seeing the following:
slapd
--On Tuesday, March 13, 2012 12:01 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
All,
I've read and re-read (not to mentioned googled) configuring SyncRepl in
OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something
somewhere. Current logging is
: Quanah Gibson-Mount [mailto:qua...@zimbra.com]
Sent: Tuesday, March 13, 2012 1:08 PM
To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org
Subject: Re: OPENLDAP SYNCREPL
--On Tuesday, March 13, 2012 12:01 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
All
--On Tuesday, March 13, 2012 1:12 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
Thanks, Quanah;
As requested:
cn=config]# ll
total 140
-rw--- 1 ldap ldap 398 Jan 24 11:28 cn=module{0}.ldif
-rw--- 1 ldap ldap 398 Feb 8 14:02 cn=module{1}.ldif
-rw--- 1
Borresen, John - 0442 - MITLL wrote:
Thanks, Quanah;
As requested:
That was clearly not the problem; if the syncprov module was missing your
config would have caused slapd to fail to start. Also it was clearly present
since you had it updating the contextCSN in your shutdown log. Quanah,
-Original Message-
From: Howard Chu [mailto:h...@symas.com]
Sent: Tuesday, March 13, 2012 2:01 PM
To: Borresen, John - 0442 - MITLL
Cc: Quanah Gibson-Mount; openldap-technical@openldap.org
Subject: Re: OPENLDAP SYNCREPL
Borresen, John - 0442 - MITLL wrote:
Thanks, Quanah;
As requested
, John - 0442 - MITLL
Cc: Quanah Gibson-Mount; openldap-technical@openldap.org
Subject: Re: OPENLDAP SYNCREPL
Borresen, John - 0442 - MITLL wrote:
Thanks, Howard;
In hindsight, if my config looks jumbled, it is...that's what I get for
doing little things in a quasi-blind attempt at solving issues
--On Tuesday, March 13, 2012 3:38 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
Maybe it's just that it is near the end of the day...but, first here is my
ldif to add the provider to my cn=accesslog:
Look at the example LDIF I provided you. Clearly your base DN of
, John - 0442 - MITLL
Cc: openldap-technical@openldap.org
Subject: RE: OPENLDAP SYNCREPL
--On Tuesday, March 13, 2012 3:38 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
Maybe it's just that it is near the end of the day...but, first here is my
ldif to add the provider to my
--On Tuesday, March 13, 2012 4:10 PM -0400 Borresen, John - 0442 - MITLL
john.borre...@ll.mit.edu wrote:
My apologies for sounding stupid...but, I really don't see it. Out of
utter frustration, I have tried to run it on nearly all the dn's that I
can find all with the same objectClass: value
On Wed, Nov 23, 2011 at 10:51 AM, Jeffrey Crawford jeffr...@ucsc.edu wrote:
On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount qua...@zimbra.com
wrote:
--On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
read that already:
my original question was
--On Thursday, December 01, 2011 9:38 AM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
Humm that didn't seem to work. I'm rebuilding so I'll give that another
try.
Finally got to do another test. I tested by changing the permissions
of the replication account permissions and tried
read that already:
my original question was the following:
Granted the above issues might be explained away in that we don't yet
have enough ram on the machines yet, however it does seem to present
us with a problem when we notice the discrepancy, how do we during run
time re-sync the data from
--On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
read that already:
my original question was the following:
Granted the above issues might be explained away in that we don't yet
have enough ram on the machines yet, however it does seem to present
us
On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount qua...@zimbra.com wrote:
--On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
read that already:
my original question was the following:
Granted the above issues might be explained away in that we
On Thu, Nov 17, 2011 at 11:47 PM, Howard Chu h...@symas.com wrote:
Jeffrey Crawford wrote:
On Thu, Nov 17, 2011 at 9:21 PM, Howard Chuh...@symas.com wrote:
Jeffrey Crawford wrote:
On Thu, Nov 17, 2011 at 5:50 PM, Howard Chuh...@symas.com wrote:
There ought to be other error messages
--On Tuesday, November 22, 2011 5:50 PM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
Starting slapd with the -c option isn't working or I'm using the wrong
combination.
man slapadd.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--On Wednesday, November 16, 2011 3:49 PM -0800 Jeffrey Crawford
jeffr...@ucsc.edu wrote:
Oh and we are using bdb 4.6 right now (forgot to answer that)
With all the patches? Oracle lists 4.
4.6.21
Requires log file format upgrade. change log - patches ( 4)
--
Quanah Gibson-Mount
Okay using bdb 4.8 seems to be working better, I ran through several
mass adds and deletes. I stil get periodic failures of:
Nov 21 10:32:27 idm-prod-ldap-2 slapd[41275]: conn=-1 op=0: attribute
reqEnd index delete failure
which is obviously part of the acceslog overlay. I am replicating that
DB
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 1:27 PM, Howard Chu h...@symas.com
mailto:h...@symas.com wrote:
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 7:40 AM, Jeffrey Crawfordjeffr...@ucsc.edu
mailto:jeffr...@ucsc.edu wrote:
On Wed, Nov 16, 2011 at
On Thu, Nov 17, 2011 at 5:50 PM, Howard Chu h...@symas.com wrote:
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 1:27 PM, Howard Chu h...@symas.com
mailto:h...@symas.com wrote:
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 7:40 AM, Jeffrey Crawfordjeffr...@ucsc.edu
Jeffrey Crawford wrote:
On Thu, Nov 17, 2011 at 5:50 PM, Howard Chuh...@symas.com wrote:
There ought to be other error messages in your log, immediately preceding
the one you quoted. Post those too.
There really isn't much there but here is an example really not much
around it: (I've
Jeffrey Crawford wrote:
I'm trying to stabilize our openldap server farm before going live and
am finding that despite the contextCSN matching between providers and
replicas, the actual content of the server is getting out of sync.
This is most prominent when we are testing our population
On Wed, Nov 16, 2011 at 12:09 AM, Howard Chu h...@symas.com wrote:
Jeffrey Crawford wrote:
I'm trying to stabilize our openldap server farm before going live and
am finding that despite the contextCSN matching between providers and
replicas, the actual content of the server is getting out of
On Wed, Nov 16, 2011 at 7:40 AM, Jeffrey Crawford jeffr...@ucsc.edu wrote:
On Wed, Nov 16, 2011 at 12:09 AM, Howard Chu h...@symas.com wrote:
Jeffrey Crawford wrote:
I'm trying to stabilize our openldap server farm before going live and
am finding that despite the contextCSN matching between
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 12:09 AM, Howard Chuh...@symas.com wrote:
There are known bugs in syncrepl delete handling. ITS#7052 is probably
relevant here. The fix will be in 2.4.27.
Any idea when it will be released?
The release branch has been ready to go for a few
On Wed, Nov 16, 2011 at 1:27 PM, Howard Chu h...@symas.com wrote:
Jeffrey Crawford wrote:
On Wed, Nov 16, 2011 at 7:40 AM, Jeffrey Crawfordjeffr...@ucsc.edu
wrote:
On Wed, Nov 16, 2011 at 12:09 AM, Howard Chuh...@symas.com wrote:
Jeffrey Crawford wrote:
I'm trying to stabilize our
I'm trying to stabilize our openldap server farm before going live and
am finding that despite the contextCSN matching between providers and
replicas, the actual content of the server is getting out of sync.
This is most prominent when we are testing our population routine and
we need to remove
I was giving incorrect URI in proxy.conf(Consumer proxy configuration).
It should point to slave database(10.52.35.204:9015).Correcting URI as below
resolved replication issue.
uri ldap://10.52.35.204:9015/
Regards
Rupesh
I missed to include /usr/share/openldap-servers/slapd.acl in
proxy.conf(Consumer proxy configuration).I included this, still getting same
error in consumer proxy log.
*syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)*
*syncrepl_entry: rid=001 be_search (49)*
*syncrepl_entry:
setting(overlay pcache) ?
Thanks
Rupesh
-Original Message-
From: Marc Patermann [mailto:hans.mo...@ofd-z.niedersachsen.de]
Sent: Friday, August 19, 2011 4:43 PM
To: Rupesh Thakkar; openldap-technical openldap org
Subject: Re: openldap syncrepl Provider with Slave(older version)
Rupesh,
Rupesh
Rupesh,
Rupesh Thakkar schrieb:
#syncrepl Provider for primary db
overlay syncprov
syncprov-checkpoint 1000 60
# Let the replica DN have limitless searches
limits
dn.exact=umObjectGUID=218afb42cb5e11e09542001a64e587d4,ou=People,dc=Avaya
time.soft=unlimited
Hi ,
My application was using replication using Slurpd .
Now, we want to move to openldap version 2.4 (RHEL 6.x)from 2.2, so I should
use syncrepl instead slurpd. Replication clients(slaves) can still be of older
version(2.2)
I am tried to replication setup using sincerely using doc
48 matches
Mail list logo
