The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
olcSyncrepl: {0} rid=102 provider="ldap://server2.prod:389/" type=refreshAndPersist retry="60 30 300 +" keepalive=1200:10:3 searchbase="dc=mydomain,dc=com" bindmethod=simple binddn="cn=replica,dc=mydomain,dc=com" credentials=xxxxxx starttls=critical tls_cacert="/etc/pki/CA/cacert.pem"
On the consumer side I am seeing these messages:
Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search entry without Sync State control Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 retrying (29 retries left)
and on the provider side I am seeing these:
Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 ACCEPT from IP=10.10.2.103:35671 (IP=0.0.0.0:389) Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 STARTTLS Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=0 RESULT oid= err=0 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 TLS established tls_ssf=256 ssf=256 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" method=128 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" mech=SIMPLE ssf=0 Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=1 RESULT tag=97 err=0 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SRCH base="dc=mydomain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SRCH attr=* + Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=2 SEARCH RESULT tag=101 err=0 nentries=22 text= Sep 22 18:02:36 localhost slapd[20718]: conn=1071 op=3 UNBIND Sep 22 18:02:36 localhost slapd[20718]: conn=1071 fd=21 closed Sep 22 18:02:36 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:02:36 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 ACCEPT from IP=10.10.2.103:35672 (IP=0.0.0.0:389) Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 STARTTLS Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=0 RESULT oid= err=0 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 TLS established tls_ssf=256 ssf=256 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" method=128 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 BIND dn="cn=replica,dc=mydomain,dc=com" mech=SIMPLE ssf=0 Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=1 RESULT tag=97 err=0 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SRCH base="dc=mydomain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SRCH attr=* + Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=2 SEARCH RESULT tag=101 err=0 nentries=22 text= Sep 22 18:03:37 localhost slapd[20718]: conn=1072 op=3 UNBIND Sep 22 18:03:37 localhost slapd[20718]: conn=1072 fd=21 closed Sep 22 18:03:37 localhost slapd[20718]: connection_read(21): no connection! Sep 22 18:03:37 localhost slapd[20718]: connection_read(21): no connection!
The sync connection is supposed to be persistent but it keeps closing down and reconnecting.
Anyone know what could be the reason?
Thanks, Daniel
Daniel Qian wrote:
The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
olcSyncrepl: {0} rid=102 provider="ldap://server2.prod:389/" type=refreshAndPersist retry="60 30 300 +" keepalive=1200:10:3 searchbase="dc=mydomain,dc=com" bindmethod=simple binddn="cn=replica,dc=mydomain,dc=com" credentials=xxxxxx starttls=critical tls_cacert="/etc/pki/CA/cacert.pem"
On the consumer side I am seeing these messages:
Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search entry without Sync State control Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 retrying (29 retries left)
and on the provider side I am seeing these:
The sync connection is supposed to be persistent but it keeps closing down and reconnecting.
Anyone know what could be the reason?
Obviously your "provider side" doesn't actually have the syncprov overlay configured.
On 11-09-22 7:37 PM, Howard Chu wrote:
Daniel Qian wrote:
The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
olcSyncrepl: {0} rid=102 provider="ldap://server2.prod:389/" type=refreshAndPersist retry="60 30 300 +" keepalive=1200:10:3 searchbase="dc=mydomain,dc=com" bindmethod=simple binddn="cn=replica,dc=mydomain,dc=com" credentials=xxxxxx starttls=critical tls_cacert="/etc/pki/CA/cacert.pem"
On the consumer side I am seeing these messages:
Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search entry without Sync State control Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 retrying (29 retries left)
and on the provider side I am seeing these:
The sync connection is supposed to be persistent but it keeps closing down and reconnecting.
Anyone know what could be the reason?
Obviously your "provider side" doesn't actually have the syncprov overlay configured.
I put the exact same configuration for syncprov on two servers
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov1.prod cn=module{0} Enter LDAP Password: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov2.prod cn=module{0} Enter LDAP Password: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov
[root@localhost cn=config]# ls /usr/lib64/openldap accesslog-2.4.so.2 constraint-2.4.so.2 dyngroup-2.4.so.2 pcache-2.4.so.2 retcode-2.4.so.2 smbk5pwd-2.4.so.2 translucent-2.4.so.2 accesslog-2.4.so.2.6.0 constraint-2.4.so.2.6.0 dyngroup-2.4.so.2.6.0 pcache-2.4.so.2.6.0 retcode-2.4.so.2.6.0 smbk5pwd-2.4.so.2.6.0 translucent-2.4.so.2.6.0 accesslog.la constraint.la dyngroup.la pcache.la retcode.la smbk5pwd.la translucent.la auditlog-2.4.so.2 dds-2.4.so.2 dynlist-2.4.so.2 ppolicy-2.4.so.2 rwm-2.4.so.2 sssvlv-2.4.so.2 unique-2.4.so.2 auditlog-2.4.so.2.6.0 dds-2.4.so.2.6.0 dynlist-2.4.so.2.6.0 ppolicy-2.4.so.2.6.0 rwm-2.4.so.2.6.0 sssvlv-2.4.so.2.6.0 unique-2.4.so.2.6.0 auditlog.la dds.la dynlist.la ppolicy.la rwm.la sssvlv.la unique.la collect-2.4.so.2 deref-2.4.so.2 memberof-2.4.so.2 refint-2.4.so.2 seqmod-2.4.so.2 syncprov-2.4.so.2 valsort-2.4.so.2 collect-2.4.so.2.6.0 deref-2.4.so.2.6.0 memberof-2.4.so.2.6.0 refint-2.4.so.2.6.0 seqmod-2.4.so.2.6.0 syncprov-2.4.so.2.6.0 valsort-2.4.so.2.6.0 collect.la deref.la memberof.la refint.la seqmod.la syncprov.la valsort.la
Can you tell what is missing on one of the two servers? Is there a command to tell if the module is actually loaded into the execution space?
Thanks, Daniel
you need to add the syncrepl overlay to the backend containing your replication source data, to make it syncrepl aware.
On Fri, Sep 23, 2011 at 10:30 AM, Daniel Qian daniel@up247solution.comwrote:
On 11-09-22 7:37 PM, Howard Chu wrote:
Daniel Qian wrote:
The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
On 11-09-22 9:37 PM, Brett @Google wrote:
you need to add the syncrepl overlay to the backend containing your replication source data, to make it syncrepl aware.
On Fri, Sep 23, 2011 at 10:30 AM, Daniel Qian <daniel@up247solution.com mailto:daniel@up247solution.com> wrote:
On 11-09-22 7:37 PM, Howard Chu wrote: Daniel Qian wrote: The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
I am not sure what you mean by "add the syncrepl to the backend". The two nodes have pretty much the same configuration for the backend containing the replicated data but the question is why one is working and the other one is not.
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov2.prod olcDatabase={1}bdb > /root/ldaprov2.ldif Enter LDAP Password:
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov1.prod olcDatabase={1}bdb > /root/ldaprov1.ldif Enter LDAP Password:
[root@localhost cn=config]# !diff diff /root/ldaprov1.ldif /root/ldaprov2.ldif 18c18 < olcRootPW: {SSHA}/2ht...................... ---
olcRootPW: {SSHA}lfxH.....................
20c20 < olcSyncrepl: {0}rid=102 provider="ldap://ldaprov2.prod:389/" type=refreshAndP ---
olcSyncrepl: {0}rid=202 provider="ldap://ldaprov1.prod:389/"
type=refreshAndP
above lines are the only difference of the backend configurations in the two nodes.
Thanks, Daniel
On 11-09-22 10:09 PM, Daniel Qian wrote:
On 11-09-22 9:37 PM, Brett @Google wrote:
you need to add the syncrepl overlay to the backend containing your replication source data, to make it syncrepl aware.
On Fri, Sep 23, 2011 at 10:30 AM, Daniel Qian <daniel@up247solution.com mailto:daniel@up247solution.com> wrote:
On 11-09-22 7:37 PM, Howard Chu wrote: Daniel Qian wrote: The problem direction has the same syncrepl configuration as the working one except for the rid and provider name:
I am not sure what you mean by "add the syncrepl to the backend". The two nodes have pretty much the same configuration for the backend containing the replicated data but the question is why one is working and the other one is not.
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov2.prod olcDatabase={1}bdb > /root/ldaprov2.ldif Enter LDAP Password:
[root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov1.prod olcDatabase={1}bdb > /root/ldaprov1.ldif Enter LDAP Password:
[root@localhost cn=config]# !diff diff /root/ldaprov1.ldif /root/ldaprov2.ldif 18c18
< olcRootPW: {SSHA}/2ht......................
olcRootPW: {SSHA}lfxH.....................
20c20 < olcSyncrepl: {0}rid=102 provider="ldap://ldaprov2.prod:389/" type=refreshAndP
olcSyncrepl: {0}rid=202 provider="ldap://ldaprov1.prod:389/"
type=refreshAndP
above lines are the only difference of the backend configurations in the two nodes.
Thanks, Daniel
Actually I was missing a component on the second node. This fixed the problem:
[root@localhost cn=config]# ldapadd -W -D cn=admin,cn=config <<EOF dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 EOF Enter LDAP Password: adding new entry "olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config"
Thanks for the help Daniel
openldap-technical@openldap.org