Hi,
I have a syncrepl provider v2.4.22 working fine (the only provider in our organization).
I upgraded with the same configuration to v2.4.26 and provider is not working (neither over ldaps: nor over ldap:). Otherwise connectivity is fine (with any ldap client) both with ldap and with ldaps.
I get (in all consumers):
Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrepl: rid=111 rc -2 retrying
How can I troubleshoot the issue further?
Current config on the provider is:
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
and on consumers:
syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="cn=someuser,dc=example,dc=com" credentials="password"
Thanks, Nick
On 17/10/2011 9:52 μμ, Nick Milas wrote:
I upgraded with the same configuration to v2.4.26 and provider is not working
Hmm, actually I changed a couple of things:
1. I am now using a different openldap RPM package (with different paths etc.); This should not be important, because I have updated configuration accordingly and everything (except syncrepl provider) works fine. 2. I have chosen to use hdb rather than bdb in the new setup. All entries were migrated by using slapcat on the initial instance and then slapadd on the new openldap instance. (They were migrated successfully.
Could the use of hdb on the provider cause such a problem ("server is unwilling to perform")? (According to documentation hdb supports syncrepl).
I read that this error means that "lapd will return an unwilling to perform error if the backend holding the target entry does not support the given operation". Why wouldn't the backend support sync operations in this case?
Note that I tried (in consumers) all sorts of configurations (plain ldap without starttls or with starttls, ldaps) but nothing worked.
In any case, below is my whole slapd.conf (Note: In this Openldap RPM, provided by the LTB project, all modules are included and not dynamically loaded):
Thanks, Nick
----------------------------------------------------------------------------------- slapd.conf: ----------------------------------------------------------------------------------- include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema
# Allow LDAPv2 client connections. This is NOT the default. allow bind_v2
pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args
# Load dynamic backend modules: modulepath /usr/local/openldap/lib64
loglevel sync
sizelimit unlimited timelimit unlimited
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/openldap/certs/chain.pem TLSCertificateFile /usr/local/openldap/etc/openldap/certs/cert.pem TLSCertificateKeyFile /usr/local/openldap/etc/openldap/certs/priv.pem TLSVerifyClient never
database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret
######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf
directory /usr/local/openldap/var/openldap-data
overlay auditlog auditlog /usr/local/openldap/var/openldap-data/ldapaudit.log
index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index aRecord,pTRRecord pres,eq,sub index aliasInactive eq index krbPrincipalName eq,pres,sub index schacUserStatus eq,pres
# Allow dynamic lists
overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member
# Setup Provider - Allow Consumer Sync
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
database monitor
access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none
-----------------------------------------------------------------------------------
On 18/10/2011 10:47 πμ, Marc Patermann wrote:
# Load dynamic backend modules: modulepath /usr/local/openldap/lib64
could it be that you have to load some modules here? Look at the directory for what is in there.
Thanks Marc,
This RPM does not use dynamically loaded modules. Here is the feedback from the LTB project (see thread: http://tools.lsc-project.org/issues/349):
"LTB packaging do not ship overlays as modules, they are built in slapd. ... this seems to be more an OpenLDAP question..."
So, any other ideas would be appreciated.
For your reference, here is the listing of the mentioned directory:
drwxr-xr-x 2 ldap ldap 4096 Oct 17 15:38 . drwxr-xr-x 10 ldap ldap 4096 Oct 17 15:38 .. lrwxrwxrwx 1 ldap ldap 20 Oct 17 15:38 liblber-2.4.so.2 -> liblber-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 171110 Jul 18 13:36 liblber-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 98766 Jul 18 11:41 liblber.a -rw-r--r-- 1 ldap ldap 863 Jul 18 13:36 liblber.la lrwxrwxrwx 1 ldap ldap 20 Oct 17 15:38 liblber.so -> liblber-2.4.so.2.7.1 lrwxrwxrwx 1 ldap ldap 20 Oct 17 15:38 libldap-2.4.so.2 -> libldap-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 1085276 Jul 18 13:37 libldap-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 528402 Jul 18 11:41 libldap.a -rw-r--r-- 1 ldap ldap 923 Jul 18 13:37 libldap.la lrwxrwxrwx 1 ldap ldap 22 Oct 17 15:38 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 1189584 Jul 18 13:37 libldap_r-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 584034 Jul 18 11:41 libldap_r.a -rw-r--r-- 1 ldap ldap 946 Jul 18 13:37 libldap_r.la lrwxrwxrwx 1 ldap ldap 22 Oct 17 15:38 libldap_r.so -> libldap_r-2.4.so.2.7.1 lrwxrwxrwx 1 ldap ldap 20 Oct 17 15:38 libldap.so -> libldap-2.4.so.2.7.1 lrwxrwxrwx 1 ldap ldap 21 Oct 17 15:38 libslapi-2.4.so.2 -> libslapi-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 442540 Jul 18 11:37 libslapi-2.4.so.2.7.1 -rw-r--r-- 1 ldap ldap 208364 Jul 18 11:41 libslapi.a -rw-r--r-- 1 ldap ldap 861 Jul 18 11:37 libslapi.la lrwxrwxrwx 1 ldap ldap 21 Oct 17 15:38 libslapi.so -> libslapi-2.4.so.2.7.1
Nick
2011/10/19 Nick Milas nick@eurobjects.com:
On 18/10/2011 10:47 πμ, Marc Patermann wrote:
# Load dynamic backend modules: modulepath /usr/local/openldap/lib64
could it be that you have to load some modules here? Look at the directory for what is in there.
Thanks Marc,
This RPM does not use dynamically loaded modules. Here is the feedback from the LTB project (see thread: http://tools.lsc-project.org/issues/349):
"LTB packaging do not ship overlays as modules, they are built in slapd. ... this seems to be more an OpenLDAP question..."
So, any other ideas would be appreciated.
You should try to run your provider and your consumer in full debug mode (loglevel -1), this will maybe allow to see the source of the error.
Clément.
On 19/10/2011 10:57 πμ, Clément OUDOT wrote:
You should try to run your provider and your consumer in full debug mode (loglevel -1), this will maybe allow to see the source of the error. Clément.
Thank you Clement,
Today I did a fresh slapcat (from version 2.4.22 which was in use as a provider) - slapadd (to new LTB 2.4.26 CentOS RPM) of all DIT and when I restarted, surprise!, everything worked like a breeze... I switched to olcLogLevel: -1 but it was not needed after all, since everything works fine now.
(Pitty I didn't manage to log in detail the issue; yet, it's better that there is no issue any more.)
I don't know what could have been the cause of this malfunction... If someone can imagine something, it would be enlightening...
So, issue closed. Now we have almost completely switched to LTB Openldap RPMs (one provider and two - up to now - out of three consumers) and everything is running smoothly.
Good job guys: LTB Project rocks! Keep up the good work.
Of course, a big thanks to OpenLDAP Project (developers, community) too!
Nick
Am Wed, 19 Oct 2011 10:40:09 +0300 schrieb Nick Milas nick@eurobjects.com:
On 18/10/2011 10:47 πμ, Marc Patermann wrote:
# Load dynamic backend modules: modulepath /usr/local/openldap/lib64
could it be that you have to load some modules here? Look at the directory for what is in there.
Thanks Marc,
This RPM does not use dynamically loaded modules. Here is the feedback from the LTB project (see thread: http://tools.lsc-project.org/issues/349):
"LTB packaging do not ship overlays as modules, they are built inslapd. ... this seems to be more an OpenLDAP question..."
So, any other ideas would be appreciated.
[...]
Run slapd -VVV in order to get information on all build-in modules.
-Dieter
openldap-technical@openldap.org
-
Clément OUDOT -
Dieter Klünter -
Marc Patermann -
Nick Milas