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