3:37 a.m.
Hello All,
I am trying to setup Mirror Mode of replication. Using the
configuration files listed below for 2 node setup. The database comes up
and after every 2 or 3 writes, the data is not pushed onto the other
mirror node. This is happening on both the mirror nodes.
I am getting the following error:
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso_arc" ldap_sasl_bind_s failed (-1)
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso" ldap_sasl_bind_s failed (-1)
This is happening after 2 or 3 write operations to the database.
The slapd.conf on node 1 is:
=================================
database bdb
suffix "o=CSOSSO"
directory /opt/cso/ldap/db
rootdn "uid=<UID>,o=CSOSSO"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
include /opt/cso/ldap/replica/135.254.229.102-390
database bdb
suffix "o=CSOSSO_ARC"
directory /opt/cso/ldap/db_arc
rootdn "uid=<UID>,o=CSOSSO_ARC"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
include /opt/cso/ldap/replica/135.254.229.102-390-arc
=========================================
The syncrepl configuration on node 1 is:
=========================================
syncrepl rid=1
provider=ldap://135.254.229.102:389
type=refreshAndPersist
interval=00:00:01:00
retry="30 +"
searchbase="ou=people,o=csosso"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<UID>,o=CSOSSO"
credentials=<PWD>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
=======================================
Same configuration files are used on node 2 except the port numbers and
the serverID.
Thanks
Sachin
9:49 a.m.
--On February 20, 2008 7:37:17 PM +0800 "K C, Sachin (Sachin)"
<sachinkc(a)alcatel-lucent.com> wrote:
Hello All,
I am trying to setup Mirror Mode of replication. Using the
configuration files listed below for 2 node setup. The database comes up
and after every 2 or 3 writes, the data is not pushed onto the other
mirror node. This is happening on both the mirror nodes.
What openldap release?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
7:28 p.m.
OpenLDAP 2.4.7 in which MirrorMode is supported.
-Sachin
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Wednesday, February 20, 2008 11:20 PM
To: K C, Sachin (Sachin); openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
--On February 20, 2008 7:37:17 PM +0800 "K C, Sachin (Sachin)"
<sachinkc(a)alcatel-lucent.com> wrote:
Hello All,
I am trying to setup Mirror Mode of replication. Using the
configuration files listed below for 2 node setup. The database comes
up and after every 2 or 3 writes, the data is not pushed onto the
other mirror node. This is happening on both the mirror nodes.
What openldap release?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
2:30 a.m.
K C, Sachin (Sachin) wrote:
Hello All,
I am trying to setup Mirror Mode of replication. Using the
configuration files listed below for 2 node setup. The database comes up
and after every 2 or 3 writes, the data is not pushed onto the other
mirror node. This is happening on both the mirror nodes.
I am getting the following error:
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso_arc" ldap_sasl_bind_s failed (-1)
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso" ldap_sasl_bind_s failed (-1)
What is the error number if any?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
2:43 a.m.
Gevin,
I modified on node 1. The error it logged is ( log level is 8 )
Node 1 log:
=================
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 20r
daemon: read activity on 20
daemon: select: listen=7 active_threads=1 tvp=zero
null_callback : error code 0x14
syncrepl_updateCookie: rid=001 be_modify failed (20)
daemon: removing 20
do_syncrepl: rid=001 retrying
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 21r
daemon: read activity on 21
Node 2 log:
===============
daemon: added 7r listener=1f9060
slap_client_connect: URI=ldap://135.254.229.102:390
DN="uid=<UID>,o=<o>"
ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=001 retrying
Do let me know If you need more log info at higher levels.
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 4:00 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
Hello All,
I am trying to setup Mirror Mode of replication. Using the
configuration files listed below for 2 node setup. The database comes
up and after every 2 or 3 writes, the data is not pushed onto the
other mirror node. This is happening on both the mirror nodes.
I am getting the following error:
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso_arc" ldap_sasl_bind_s failed (-1)
slap_client_connect: URI=ldap://135.254.229.102:389
DN="uid=<UID>,o=csosso" ldap_sasl_bind_s failed (-1)
What is the error number if any?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
3:08 a.m.
K C, Sachin (Sachin) wrote:
Gevin,
I modified on node 1. The error it logged is ( log level is 8 )
Node 1 log:
=================
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 20r
daemon: read activity on 20
daemon: select: listen=7 active_threads=1 tvp=zero
null_callback : error code 0x14
syncrepl_updateCookie: rid=001 be_modify failed (20)
daemon: removing 20
do_syncrepl: rid=001 retrying
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 21r
daemon: read activity on 21
Node 2 log:
===============
daemon: added 7r listener=1f9060
slap_client_connect: URI=ldap://135.254.229.102:390
DN="uid=<UID>,o=<o>"
ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=001 retrying
Do let me know If you need more log info at higher levels.
Do -1 and paste the first 10 lines after "ldap_sasl_bind_s failed (-1)"
or so.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
3:35 a.m.
Here it is...
841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
842 ldap_close_socket: 18
843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
ldap_sasl_bind_s failed
(-1)
844 do_syncrepl: rid=001 retrying
845 do_syncrepl: rid=002 retrying
846 daemon: select: listen=7 active_threads=0 tvp=zero
847 daemon: activity on 1 descriptor
848 daemon: waked
849 daemon: select: listen=7 active_threads=0 tvp=zero
850 daemon: activity on 1 descriptor
851 slap_listener_activate(7):
852 daemon: select: listen=7 busy
853 >>> slap_listener(ldap://<IP>:389)
854 daemon: listen=7, new connection on 18
855 daemon: added 18r (active) listener=0
856 conn=0 fd=18 ACCEPT from IP=<IP>:51749 (IP=<IP>:389)
857 daemon: activity on 1 descriptor
858 daemon: waked
859 daemon: select: listen=7 active_threads=1 tvp=zero
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 4:38 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
Gevin,
I modified on node 1. The error it logged is ( log level is 8 )
Node 1 log:
=================
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 20r
daemon: read activity on 20
daemon: select: listen=7 active_threads=1 tvp=zero null_callback :
error code 0x14
syncrepl_updateCookie: rid=001 be_modify failed (20)
daemon: removing 20
do_syncrepl: rid=001 retrying
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 21r
daemon: read activity on 21
Node 2 log:
===============
daemon: added 7r listener=1f9060
slap_client_connect: URI=ldap://135.254.229.102:390
DN="uid=<UID>,o=<o>"
ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=001 retrying
Do let me know If you need more log info at higher levels.
Do -1 and paste the first 10 lines after "ldap_sasl_bind_s failed (-1)"
or so.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
3:40 a.m.
<quote who="K C, Sachin \(Sachin\)">
Here it is...
841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
842 ldap_close_socket: 18
843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
ldap_sasl_bind_s failed
(-1)
844 do_syncrepl: rid=001 retrying
845 do_syncrepl: rid=002 retrying
OK, so can you definitely ldapsearch these to servers from this machine?
7:42 p.m.
Yes, I can do ldapsearch from this machine.
The same thing is inconsistent from within syncrepl :(
- Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 5:11 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
<quote who="K C, Sachin \(Sachin\)">
Here it is...
841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
842 ldap_close_socket: 18
843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
ldap_sasl_bind_s failed
(-1)
844 do_syncrepl: rid=001 retrying
845 do_syncrepl: rid=002 retrying
OK, so can you definitely ldapsearch these to servers from this machine?
3:33 a.m.
Gavin,
Just wanted to update with the configuration files on both sides one
more time.
Apart from intermittent update problem, one more problem I found is that
changes to node with serverID 1 gets replicated to node with serverID 2,
but not the reverse.
Node 1: serverId 1
===================
database bdb
suffix "o=<O>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node2>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<O>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Node 2: serverId 2
====================
database bdb
suffix "o=<o>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node1>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<o>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Thanks a lot Gavin
Sachin
-----Original Message-----
From:
openldap-technical-bounces+sachinkc=alcatel-lucent.com(a)openldap.org
[mailto:openldap-technical-bounces+sachinkc=alcatel-lucent.com@openldap.
org] On Behalf Of K C, Sachin (Sachin)
Sent: Friday, February 22, 2008 9:12 AM
To: Gavin Henry
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
Yes, I can do ldapsearch from this machine.
The same thing is inconsistent from within syncrepl :(
- Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 5:11 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
<quote who="K C, Sachin \(Sachin\)">
Here it is...
841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
842 ldap_close_socket: 18
843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
ldap_sasl_bind_s failed
(-1)
844 do_syncrepl: rid=001 retrying
845 do_syncrepl: rid=002 retrying
OK, so can you definitely ldapsearch these to servers from this machine?
7:23 a.m.
Try the overlay syncprov stuff before the syncrepl directives.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
<quote who="K C, Sachin \(Sachin\)">
Gavin,
Just wanted to update with the configuration files on both sides one
more time.
Apart from intermittent update problem, one more problem I found is that
changes to node with serverID 1 gets replicated to node with serverID 2,
but not the reverse.
Node 1: serverId 1
===================
database bdb
suffix "o=<O>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node2>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<O>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Node 2: serverId 2
====================
database bdb
suffix "o=<o>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node1>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<o>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Thanks a lot Gavin
Sachin
-----Original Message-----
From:
openldap-technical-bounces+sachinkc=alcatel-lucent.com(a)openldap.org
[mailto:openldap-technical-bounces+sachinkc=alcatel-lucent.com@openldap.
org] On Behalf Of K C, Sachin (Sachin)
Sent: Friday, February 22, 2008 9:12 AM
To: Gavin Henry
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
Yes, I can do ldapsearch from this machine.
The same thing is inconsistent from within syncrepl :(
- Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 5:11 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
<quote who="K C, Sachin \(Sachin\)">
>
> Here it is...
>
>
> 841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
> 842 ldap_close_socket: 18
> 843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
> ldap_sasl_bind_s failed
> (-1)
> 844 do_syncrepl: rid=001 retrying
> 845 do_syncrepl: rid=002 retrying
OK, so can you definitely ldapsearch these to servers from this machine?
8:35 p.m.
Tried this as well. No satisfactory results :(
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Friday, February 22, 2008 8:53 PM
To: K C, Sachin (Sachin)
Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
Try the overlay syncprov stuff before the syncrepl directives.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
<quote who="K C, Sachin \(Sachin\)">
Gavin,
Just wanted to update with the configuration files on both sides one
more time.
Apart from intermittent update problem, one more problem I found is
that changes to node with serverID 1 gets replicated to node with
serverID 2, but not the reverse.
Node 1: serverId 1
===================
database bdb
suffix "o=<O>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should # be avoid.
See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node2>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<O>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Node 2: serverId 2
====================
database bdb
suffix "o=<o>"
directory <loc>
rootdn "uid=Directory Manager,o=<o>"
rootpw <PWD>
# cleartext passwords, especially for the rootdn, should # be avoid.
See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectclass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://<node1>:389/
type=refreshAndPersist
interval=00:00:00:10
retry="30 +"
searchbase="ou=people,o=<o>"
filter="(objectclass=*)"
scope=sub
attrs="*,+"
sizelimit="unlimited"
timelimit="unlimited"
schemachecking=off
bindmethod=simple
binddn="uid=<uid>,o=<o>"
credentials=<pwd>
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
Thanks a lot Gavin
Sachin
-----Original Message-----
From:
openldap-technical-bounces+sachinkc=alcatel-lucent.com(a)openldap.org
[mailto:openldap-technical-bounces+sachinkc=alcatel-lucent.com@openldap.
org] On Behalf Of K C, Sachin (Sachin)
Sent: Friday, February 22, 2008 9:12 AM
To: Gavin Henry
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
Yes, I can do ldapsearch from this machine.
The same thing is inconsistent from within syncrepl :(
- Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 21, 2008 5:11 PM
To: K C, Sachin (Sachin)
Cc: openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
<quote who="K C, Sachin \(Sachin\)">
>
> Here it is...
>
>
> 841 ldap_pvt_connect: fd: 18 tm: -1 async: 0
> 842 ldap_close_socket: 18
> 843 slap_client_connect: URI=ldap://<IP>:390
DN="uid=<UID>,o=<0>"
> ldap_sasl_bind_s failed
> (-1)
> 844 do_syncrepl: rid=001 retrying
> 845 do_syncrepl: rid=002 retrying
OK, so can you definitely ldapsearch these to servers from this
machine?
9:02 p.m.
K C, Sachin (Sachin) wrote:
Tried this as well. No satisfactory results :(
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Friday, February 22, 2008 8:53 PM
Try the overlay syncprov stuff before the syncrepl directives.
That is clearly wrong. "syncrepl" is a database-specific directive. Overlay
directives are supposed to come after all of the regular database directives.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:42 a.m.
<quote who="Howard Chu">
K C, Sachin (Sachin) wrote:
>
> Tried this as well. No satisfactory results :(
>
> -Sachin
>
>
> -----Original Message-----
> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
> Sent: Friday, February 22, 2008 8:53 PM
> Try the overlay syncprov stuff before the syncrepl directives.
That is clearly wrong. "syncrepl" is a database-specific directive.
Overlay
directives are supposed to come after all of the regular database
directives.
It can be applied globally to all databases no? That's why I said before
the syncrepl directive, meaning before the database section/s
1:46 a.m.
Tried syncprov directive before all database directives. Me getting the
following error.
@(#) $OpenLDAP: slapd 2.4.7 (Feb 22 2008 15:29:49) $
syncprov must be instantiated within a database.
slapd stopped.
connections_destroy: nothing to destroy.
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 3:12 PM
To: Howard Chu
Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
<quote who="Howard Chu">
K C, Sachin (Sachin) wrote:
>
> Tried this as well. No satisfactory results :(
>
> -Sachin
>
>
> -----Original Message-----
> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
> Sent: Friday, February 22, 2008 8:53 PM
> Try the overlay syncprov stuff before the syncrepl directives.
That is clearly wrong. "syncrepl" is a database-specific directive.
Overlay
directives are supposed to come after all of the regular database
directives.
It can be applied globally to all databases no? That's why I said before
the syncrepl directive, meaning before the database section/s
4:33 a.m.
K C, Sachin (Sachin) wrote:
Tried syncprov directive before all database directives. Me getting the
following error.
@(#) $OpenLDAP: slapd 2.4.7 (Feb 22 2008 15:29:49) $
syncprov must be instantiated within a database.
slapd stopped.
connections_destroy: nothing to destroy.
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 3:12 PM
To: Howard Chu
Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
<quote who="Howard Chu">
> K C, Sachin (Sachin) wrote:
>> Tried this as well. No satisfactory results :(
>>
>> -Sachin
>>
>>
>> -----Original Message-----
>> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
>> Sent: Friday, February 22, 2008 8:53 PM
>> Try the overlay syncprov stuff before the syncrepl directives.
> That is clearly wrong. "syncrepl" is a database-specific directive.
> Overlay
> directives are supposed to come after all of the regular database
> directives.
It can be applied globally to all databases no? That's why I said before
the syncrepl directive, meaning before the database section/s
Yeah, sorry about that.
Can you try with 2.4.8 with the same setup as before (not the one you
just tried)?
10:09 p.m.
It is not working on 2.4.8 as well, Gavin.
Configuration files look just fine. Isn't it?
Has anybody tried this on solaris 10?
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 6:04 PM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
Tried syncprov directive before all database directives. Me getting
the following error.
@(#) $OpenLDAP: slapd 2.4.7 (Feb 22 2008 15:29:49) $ syncprov must be
instantiated within a database.
slapd stopped.
connections_destroy: nothing to destroy.
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 3:12 PM
To: Howard Chu
Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
<quote who="Howard Chu">
> K C, Sachin (Sachin) wrote:
>> Tried this as well. No satisfactory results :(
>>
>> -Sachin
>>
>>
>> -----Original Message-----
>> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
>> Sent: Friday, February 22, 2008 8:53 PM Try the overlay syncprov
>> stuff before the syncrepl directives.
> That is clearly wrong. "syncrepl" is a database-specific directive.
> Overlay
> directives are supposed to come after all of the regular database
> directives.
It can be applied globally to all databases no? That's why I said
before the syncrepl directive, meaning before the database section/s
Yeah, sorry about that.
Can you try with 2.4.8 with the same setup as before (not the one you
just tried)?
12:06 p.m.
Can you send me your configs and sanitised LDIF data?
Then I can setup your exact config and test.
Thansk.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
<quote who="K C, Sachin \(Sachin\)">
It is not working on 2.4.8 as well, Gavin.
Configuration files look just fine. Isn't it?
Has anybody tried this on solaris 10?
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 6:04 PM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
>
> Tried syncprov directive before all database directives. Me getting
> the following error.
>
> @(#) $OpenLDAP: slapd 2.4.7 (Feb 22 2008 15:29:49) $ syncprov must be
> instantiated within a database.
> slapd stopped.
> connections_destroy: nothing to destroy.
>
> Thanks
> Sachin
>
>
>
>
> -----Original Message-----
> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
> Sent: Monday, February 25, 2008 3:12 PM
> To: Howard Chu
> Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
> Subject: Re: LDAP Writes are not propagated to mirror nodes.
>
> <quote who="Howard Chu">
>> K C, Sachin (Sachin) wrote:
>>> Tried this as well. No satisfactory results :(
>>>
>>> -Sachin
>>>
>>>
>>> -----Original Message-----
>>> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
>>> Sent: Friday, February 22, 2008 8:53 PM Try the overlay syncprov
>>> stuff before the syncrepl directives.
>> That is clearly wrong. "syncrepl" is a database-specific directive.
>> Overlay
>> directives are supposed to come after all of the regular database
>> directives.
>
> It can be applied globally to all databases no? That's why I said
> before the syncrepl directive, meaning before the database section/s
Yeah, sorry about that.
Can you try with 2.4.8 with the same setup as before (not the one you
just tried)?
8:44 p.m.
Gavin,
Find in the attached the config files for 2 nodes (node1.conf
and node2.conf)
initial.ldif file contains the LDIF data.
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Wednesday, February 27, 2008 1:37 AM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: RE: LDAP Writes are not propagated to mirror nodes.
Can you send me your configs and sanitised LDIF data?
Then I can setup your exact config and test.
Thansk.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
<quote who="K C, Sachin \(Sachin\)">
It is not working on 2.4.8 as well, Gavin.
Configuration files look just fine. Isn't it?
Has anybody tried this on solaris 10?
-Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Monday, February 25, 2008 6:04 PM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
>
> Tried syncprov directive before all database directives. Me getting
> the following error.
>
> @(#) $OpenLDAP: slapd 2.4.7 (Feb 22 2008 15:29:49) $ syncprov must be
> instantiated within a database.
> slapd stopped.
> connections_destroy: nothing to destroy.
>
> Thanks
> Sachin
>
>
>
>
> -----Original Message-----
> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
> Sent: Monday, February 25, 2008 3:12 PM
> To: Howard Chu
> Cc: K C, Sachin (Sachin); openldap-technical(a)openldap.org
> Subject: Re: LDAP Writes are not propagated to mirror nodes.
>
> <quote who="Howard Chu">
>> K C, Sachin (Sachin) wrote:
>>> Tried this as well. No satisfactory results :(
>>>
>>> -Sachin
>>>
>>>
>>> -----Original Message-----
>>> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
>>> Sent: Friday, February 22, 2008 8:53 PM Try the overlay syncprov
>>> stuff before the syncrepl directives.
>> That is clearly wrong. "syncrepl" is a database-specific directive.
>> Overlay
>> directives are supposed to come after all of the regular database
>> directives.
>
> It can be applied globally to all databases no? That's why I said
> before the syncrepl directive, meaning before the database section/s
Yeah, sorry about that.
Can you try with 2.4.8 with the same setup as before (not the one you
just tried)?
4:08 p.m.
K C, Sachin (Sachin) wrote:
Gavin,
Find in the attached the config files for 2 nodes (node1.conf
and node2.conf)
initial.ldif file contains the LDIF data.
Well I've spent 3 hours tonight testing various settings and operations;
adding/deleting/modifying etc.
It seems very inconsistent. For example, I'll add 5 new users on node2
and node1 will only add one of them and stop at:
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("uid=user6,ou=people,o=org")
=> bdb_dn2id("uid=user6,ou=people,o=org")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
=> bdb_dn2id_add 0x8: "uid=user6,ou=people,o=org"
<= bdb_dn2id_add 0x8: 0
=> index_entry_add( 8, "uid=user6,ou=people,o=ORG" )
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
=> key_change(ADD,8)
<= key_change 0
<= index_entry_add( 8, "uid=user6,ou=people,o=ORG" ) success
=> entry_encode(0x00000008): uid=user6,ou=people,o=ORG
bdb_add: added id=00000008 dn="uid=user6,ou=people,o=ORG"
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("o=org")
bdb_entry_get: rc=0
bdb_dn2entry("o=org")
bdb_modify_internal: 0x00000001: o=ORG
bdb_modify: modify failed (16)
send_ldap_result: conn=-1 op=0 p=0
null_callback : error code 0x10
syncrepl_updateCookie: rid=001 be_modify failed (16)
node1 is now sitting there with only that user6.
Replication seems to have stopped working also. Both nodes are still up.
If I stop and start node1 it catches up ok.
Attached are the configs I'm working with.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
#
#
#
# STANDALONE SLAPD CONFIGURATION FILE
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
#ucdata-path /opt/openldap/share/openldap/ucdata
include /opt/openldap/etc/openldap/schema/core.schema
include /opt/openldap/etc/openldap/schema/cosine.schema
include /opt/openldap/etc/openldap/schema/inetorgperson.schema
include /opt/openldap/etc/openldap/schema/nis.schema
pidfile /opt/cso/ldap/var/slapd.pid
argsfile /opt/cso/ldap/var/slapd.args
modulepath /usr/local/libexec/openldap
moduleload back_bdb.la
moduleload syncprov.la
sizelimit 1000000
timelimit 360
idletimeout 420
threads 32
# To turn logging off set loglevel to 0 then stop/start ldap server
loglevel sync stats
allow bind_v2
# If this LDAP server is to be used standalone then
# the access area should be set to the following:
access to dn.regex=".*"
by self write
by dn.exact="uid=Usr,o=ORG" write
by * write
serverID 1
#######################################################################
# bdb active database definitions
#######################################################################
database bdb
suffix "o=ORG"
rootdn "uid=Usr,o=ORG"
rootpw password1
directory /opt/cso/ldap/db
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectClass,entryCSN,entryUUID eq
syncrepl rid=1
provider=ldap://127.0.0.1:391/
type=refreshAndPersist
retry="30 +"
searchbase="o=ORG"
schemachecking=off
bindmethod=simple
binddn="uid=Usr,o=ORG"
credentials=password1
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
#
#
#
# STANDALONE SLAPD CONFIGURATION FILE
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
#ucdata-path /opt/openldap/share/openldap/ucdata
include /opt/openldap/etc/openldap/schema/core.schema
include /opt/openldap/etc/openldap/schema/cosine.schema
include /opt/openldap/etc/openldap/schema/inetorgperson.schema
include /opt/openldap/etc/openldap/schema/nis.schema
pidfile /opt/cso/ldap/var/slapd2.pid
argsfile /opt/cso/ldap/var/slapd2.args
modulepath /usr/local/libexec/openldap
moduleload back_bdb.la
moduleload syncprov.la
sizelimit 1000000
timelimit 360
idletimeout 420
threads 32
# To turn logging off set loglevel to 0 then stop/start ldap server
loglevel sync stats
allow bind_v2
# If this LDAP server is to be used standalone then
# the access area should be set to the following:
access to dn.regex=".*"
by self write
by dn.exact="uid=Usr,o=ORG" write
by * write
serverID 2
#######################################################################
# bdb active database definitions
#######################################################################
database bdb
suffix "o=ORG"
rootdn "uid=Usr,o=ORG"
rootpw password1
directory /opt/cso/ldap/db2
# cleartext passwords, especially for the rootdn, should
# be avoid. See slapd.conf(5) for details.
cachesize 10000
index cn pres,eq,sub
index sn pres,eq,sub
index givenName pres,eq,sub
index uid eq
index objectClass,entryCSN,entryUUID eq
syncrepl rid=2
provider=ldap://127.0.0.1:390/
type=refreshAndPersist
retry="30 +"
searchbase="o=ORG"
schemachecking=off
bindmethod=simple
binddn="uid=Usr,o=ORG"
credentials=password1
mirrormode on
overlay syncprov
syncprov-checkpoint 100 1
2:22 a.m.
Hello Gavin,
I was on vacation last week and could not follow up. Any updates
on this?
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 28, 2008 5:39 AM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
Gavin,
Find in the attached the config files for 2 nodes (node1.conf
and
node2.conf)
initial.ldif file contains the LDIF data.
Well I've spent 3 hours tonight testing various settings and operations;
adding/deleting/modifying etc.
It seems very inconsistent. For example, I'll add 5 new users on node2
and node1 will only add one of them and stop at:
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("uid=user6,ou=people,o=org")
=> bdb_dn2id("uid=user6,ou=people,o=org")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
=> bdb_dn2id_add 0x8: "uid=user6,ou=people,o=org"
<= bdb_dn2id_add 0x8: 0
=> index_entry_add( 8, "uid=user6,ou=people,o=ORG" ) =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 <= index_entry_add(
8, "uid=user6,ou=people,o=ORG" ) success => entry_encode(0x00000008):
uid=user6,ou=people,o=ORG
bdb_add: added id=00000008 dn="uid=user6,ou=people,o=ORG"
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("o=org")
bdb_entry_get: rc=0
bdb_dn2entry("o=org")
bdb_modify_internal: 0x00000001: o=ORG
bdb_modify: modify failed (16)
send_ldap_result: conn=-1 op=0 p=0
null_callback : error code 0x10
syncrepl_updateCookie: rid=001 be_modify failed (16)
node1 is now sitting there with only that user6.
Replication seems to have stopped working also. Both nodes are still up.
If I stop and start node1 it catches up ok.
Attached are the configs I'm working with.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
2:30 a.m.
I was hoping another member of the team could confirm my results below.
No one has had time I presume.
Cheers.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
<quote who="K C, Sachin \(Sachin\)">
Hello Gavin,
I was on vacation last week and could not follow up. Any updates
on this?
Thanks
Sachin
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Thursday, February 28, 2008 5:39 AM
To: K C, Sachin (Sachin)
Cc: Howard Chu; openldap-technical(a)openldap.org
Subject: Re: LDAP Writes are not propagated to mirror nodes.
K C, Sachin (Sachin) wrote:
> Gavin,
>
> Find in the attached the config files for 2 nodes (node1.conf
and
> node2.conf)
> initial.ldif file contains the LDIF data.
>
Well I've spent 3 hours tonight testing various settings and operations;
adding/deleting/modifying etc.
It seems very inconsistent. For example, I'll add 5 new users on node2
and node1 will only add one of them and stop at:
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("uid=user6,ou=people,o=org")
=> bdb_dn2id("uid=user6,ou=people,o=org")
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
(-30990)
=> bdb_dn2id_add 0x8: "uid=user6,ou=people,o=org"
<= bdb_dn2id_add 0x8: 0
=> index_entry_add( 8, "uid=user6,ou=people,o=ORG" ) =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 =>
key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change 0
=> key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <= key_change
0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8) <=
key_change 0 => key_change(ADD,8) <= key_change 0 => key_change(ADD,8)
<= key_change 0 => key_change(ADD,8) <= key_change 0 <= index_entry_add(
8, "uid=user6,ou=people,o=ORG" ) success => entry_encode(0x00000008):
uid=user6,ou=people,o=ORG
bdb_add: added id=00000008 dn="uid=user6,ou=people,o=ORG"
send_ldap_result: conn=-1 op=0 p=0
bdb_dn2entry("o=org")
bdb_entry_get: rc=0
bdb_dn2entry("o=org")
bdb_modify_internal: 0x00000001: o=ORG
bdb_modify: modify failed (16)
send_ldap_result: conn=-1 op=0 p=0
null_callback : error code 0x10
syncrepl_updateCookie: rid=001 be_modify failed (16)
node1 is now sitting there with only that user6.
Replication seems to have stopped working also. Both nodes are still up.
If I stop and start node1 it catches up ok.
Attached are the configs I'm working with.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
6:53 p.m.
Gavin Henry wrote:
K C, Sachin (Sachin) wrote:
> Gavin,
>
> Find in the attached the config files for 2 nodes (node1.conf
> and node2.conf)
> initial.ldif file contains the LDIF data.
>
Well I've spent 3 hours tonight testing various settings and operations;
adding/deleting/modifying etc.
It seems very inconsistent. For example, I'll add 5 new users on node2
and node1 will only add one of them and stop at:
bdb_dn2entry("o=org")
bdb_entry_get: rc=0
bdb_dn2entry("o=org")
bdb_modify_internal: 0x00000001: o=ORG
bdb_modify: modify failed (16)
send_ldap_result: conn=-1 op=0 p=0
null_callback : error code 0x10
syncrepl_updateCookie: rid=001 be_modify failed (16)
I took a look at this just now. This is a (stupid) interaction between
syncrepl and syncprov's checkpoint; syncprov has already updated the
contextCSN so when syncrepl tries to delete the old value it fails because
syncprov has already deleted it.
The simple workaround for now is to just turn off the syncprov-checkpoint.
It's unnecessary in the mirror/multimaster config since syncrepl will always
keep the contextCSN up to date itself.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:54 p.m.
On Wed, 12 Mar 2008, Howard Chu wrote:
> syncrepl_updateCookie: rid=001 be_modify failed (16)
I took a look at this just now. This is a (stupid) interaction between
syncrepl and syncprov's checkpoint; syncprov has already updated the
contextCSN so when syncrepl tries to delete the old value it fails
because syncprov has already deleted it.
Interesting; that's exactly what I'm seeing (2.4.7 + patches from 2.4.8)
in a master/slave configuration.
The simple workaround for now is to just turn off the
syncprov-checkpoint. It's unnecessary in the mirror/multimaster config
since syncrepl will always keep the contextCSN up to date itself.
What about master/slave? I can just ignore it?
--
Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
11:28 p.m.
Dave Horsfall wrote:
On Wed, 12 Mar 2008, Howard Chu wrote:
>> syncrepl_updateCookie: rid=001 be_modify failed (16)
> I took a look at this just now. This is a (stupid) interaction between
> syncrepl and syncprov's checkpoint; syncprov has already updated the
> contextCSN so when syncrepl tries to delete the old value it fails
> because syncprov has already deleted it.
Interesting; that's exactly what I'm seeing (2.4.7 + patches from 2.4.8)
in a master/slave configuration.
> The simple workaround for now is to just turn off the
> syncprov-checkpoint. It's unnecessary in the mirror/multimaster config
> since syncrepl will always keep the contextCSN up to date itself.
What about master/slave? I can just ignore it?
I would just turn off the syncprov-checkpoint in all cases.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:03 a.m.
<quote who="Howard Chu">
Gavin Henry wrote:
> K C, Sachin (Sachin) wrote:
>> Gavin,
>>
>> Find in the attached the config files for 2 nodes (node1.conf
>> and node2.conf)
>> initial.ldif file contains the LDIF data.
>>
>
> Well I've spent 3 hours tonight testing various settings and operations;
> adding/deleting/modifying etc.
>
> It seems very inconsistent. For example, I'll add 5 new users on node2
> and node1 will only add one of them and stop at:
> bdb_dn2entry("o=org")
> bdb_entry_get: rc=0
> bdb_dn2entry("o=org")
> bdb_modify_internal: 0x00000001: o=ORG
> bdb_modify: modify failed (16)
> send_ldap_result: conn=-1 op=0 p=0
> null_callback : error code 0x10
> syncrepl_updateCookie: rid=001 be_modify failed (16)
I took a look at this just now. This is a (stupid) interaction between
syncrepl and syncprov's checkpoint; syncprov has already updated the
contextCSN so when syncrepl tries to delete the old value it fails because
syncprov has already deleted it.
The simple workaround for now is to just turn off the syncprov-checkpoint.
It's unnecessary in the mirror/multimaster config since syncrepl will
always
keep the contextCSN up to date itself.
OK, thanks for this.
Gavin.
3:04 a.m.
<quote who="Howard Chu">
Dave Horsfall wrote:
> On Wed, 12 Mar 2008, Howard Chu wrote:
>
>>> syncrepl_updateCookie: rid=001 be_modify failed (16)
>> I took a look at this just now. This is a (stupid) interaction between
>> syncrepl and syncprov's checkpoint; syncprov has already updated the
>> contextCSN so when syncrepl tries to delete the old value it fails
>> because syncprov has already deleted it.
>
> Interesting; that's exactly what I'm seeing (2.4.7 + patches from 2.4.8)
> in a master/slave configuration.
>
>> The simple workaround for now is to just turn off the
>> syncprov-checkpoint. It's unnecessary in the mirror/multimaster config
>> since syncrepl will always keep the contextCSN up to date itself.
>
> What about master/slave? I can just ignore it?
I would just turn off the syncprov-checkpoint in all cases.
Just as a quick fix right?
5747
days inactive
5769
days old
openldap-technical@openldap.org
28 comments
5 participants
participants (5)
-
Dave Horsfall -
Gavin Henry -
Howard Chu -
K C, Sachin (Sachin) -
Quanah Gibson-Mount