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

Re: MirrorMode sync only happening in one direction



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