On 17/10/2011 9:52 μμ, Nick Milas wrote: 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: 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

On 19/10/2011 10:57 πμ, Clément OUDOT wrote: 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