Hi folks,
After applying some changes to a consumer server used for testing purposes, my attempts to run slapcat result in the following error:
#################################### slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! #################################### (Debian squeeze, slapd v2.4.23-6)
After having configure syncrepl on the same host, I used slapcat to compare its newly replicated database to the one on the provider. At that point it still worked and the databases proved to be identical.
I then proceeded to configure chaining and a referral. The above slapcat error appeared after I made the following changes (which applied successfully):
########################################################################### # 1. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com
# 2. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap
# 3. dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE
# 4. dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self ###########################################################################
Afterwards, slapd could no longer be restarted either, with the same error showing up in the syslog.
I am aware that this is a known bug:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6540;selectid=6540
According to the report, a patch was made available on April the 29th, but I'm not sure if it actually fixed anything. At any rate, my Debian slapd version is dated from the 23rd of September and still has this problem.
However, Followup 17 (31 July) in the bug report refers to a "simple fix". Unfortunately, I haven't yet been able to find what that's supposed to be.
This seems to me to be a serious bug, but for the time being I'd be happy with simple workaround. Can anyone help?
Thanks,
Jaap
Jaap Winius wrote:
Hi folks,
After applying some changes to a consumer server used for testing purposes, my attempts to run slapcat result in the following error:
#################################### slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! #################################### (Debian squeeze, slapd v2.4.23-6)
After having configure syncrepl on the same host, I used slapcat to compare its newly replicated database to the one on the provider. At that point it still worked and the databases proved to be identical.
I then proceeded to configure chaining and a referral. The above slapcat error appeared after I made the following changes (which applied successfully):
########################################################################### # 1. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com
# 2. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap
# 3. dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE
# 4. dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self ###########################################################################
Afterwards, slapd could no longer be restarted either, with the same error showing up in the syslog.
I am aware that this is a known bug:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6540;selectid=6540
According to the report, a patch was made available on April the 29th, but I'm not sure if it actually fixed anything. At any rate, my Debian slapd version is dated from the 23rd of September and still has this problem.
A link to the patch is in followup #7, here reported for clarity: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch.
That patch was never committed because the reporter of ITS#6540 said his initial report was not actually relevant for the real issue he was suffering from. Please try that patch and report about its effect; I'll be glad to commit it if it is useful.
p.
However, Followup 17 (31 July) in the bug report refers to a "simple fix". Unfortunately, I haven't yet been able to find what that's supposed to be.
This seems to me to be a serious bug, but for the time being I'd be happy with simple workaround. Can anyone help?
Quoting Pierangelo Masarati masarati@aero.polimi.it:
That patch was never committed because the reporter of ITS#6540 said his initial report was not actually relevant for the real issue he was suffering from. Please try that patch and report about its effect; I'll be glad to commit it if it is useful.
I'd be happy to do that, but regardless of whether your patch is applied or not, the compile process errors out like this:
######################################### ... Entering subdirectory liblber make[3]: Entering directory `/root/openldap-2.4.23/debian/build/libraries/liblber' rm -f version.c /root/openldap-2.4.23/build/mkversion -v "2.4.23" liblber.la > version.c /bin/sh ../../libtool --mode=compile cc -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -O2 -I../../include -I/root/openldap-2.4.23/include -DLBER_LIBRARY -c /root/openldap-2.4.23/libraries/liblber/assert.c ../../libtool: line 460: CDPATH: command not found ../../libtool: line 1138: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b Debian-2.2.6b-2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2 libtool: and run autoconf again. make[3]: *** [assert.lo] Error 63 make[3]: Leaving directory `/root/openldap-2.4.23/debian/build/libraries/liblber' make[2]: *** [all-common] Error 1 make[2]: Leaving directory `/root/openldap-2.4.23/debian/build/libraries' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/openldap-2.4.23/debian/build' make: *** [build-stamp] Error 2 root@ldaps2:~/openldap-2.4.23# _ #########################################
A bit of searching gives me the impression that this compile error is not unique to OpenLDAP. I thought of downgrading libtool, but the current version for squeeze hasn't been updated since December 2009.
Does anyone have a fix, patch or workaround for this problem?
Cheers,
Jaap
Quoting Jaap Winius jwinius@umrk.nl:
Quoting Pierangelo Masarati masarati@aero.polimi.it:
That patch was never committed because the reporter of ITS#6540 said his initial report was not actually relevant for the real issue he was suffering from. Please try that patch and report about its effect; I'll be glad to commit it if it is useful.
I'd be happy to do that, but regardless of whether your patch is applied or not, the compile process errors out like this:
Oops, my mistake. It has now compiled successfully, with your patch.
Result: the error is gone. I suggest you commit your patch ASAP.
Thanks,
Jaap
openldap-technical@openldap.org