Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
IronPort-PHdr: =?us-ascii?q?9a23=3AB9FjghbyLkYPfwNFeAwktY7/LSx+4OfEezUN459i?=
 =?us-ascii?q?sYplN5qZpM+ybnLW6fgltlLVR4KTs6sC0LqG9f2+EjVZv96oizMrTt9lb1c9k8?=
 =?us-ascii?q?IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9?=
 =?us-ascii?q?HOnpAIma153xjLDivcCNKFwR2nKUWvBbElaflU3prM4YgI9veO4a6yDihT92Qd?=
 =?us-ascii?q?lQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGfayQqIjULYNDCg6K2xz7dXivhnO?=
 =?us-ascii?q?CwyV6SghVH4LmE9IHxTd4FfzRp76sia8sfByixWdaIfrVr0uQhyi87tzRFnhkC?=
 =?us-ascii?q?4MNzN/93vYwIQkkblWugmJpwBj24KSaZmcP/pzOKTHcoVJa3BGW5MbbytODY66?=
 =?us-ascii?q?d4wPC65JEe9eroT57RNaoRK4BASoQvvoxTBFgGfx3akS3ek7FxzA3UkgFt0Dtj?=
 =?us-ascii?q?LYoYOmZ+8pTempwfyQnn34ZPRM1GKl5Q=3D=3D?=
From: "Poggenpohl, Daniel" <daniel.poggenpohl@fernuni-hagen.de>
To: "users@httpd.apache.org" <users@httpd.apache.org>
Thread-Topic: [users@httpd] Can't activate LDAPS support in my OpenSSL
 1.0.2g/OpenLDAP 2.4.44/Apache 2.4.18/PHP 5.6.20 combination
Thread-Index: AdGWWRQCIM2pEhRzRySUSRAnrab5cgADKYuAAAWl0PsAACM+aw==
Date: Thu, 14 Apr 2016 18:39:54 +0000
Message-ID: 
 <18A3A75A149A1C4F89705973ED81137911D3DA28@Ymir.buerokommunikation.fernuni-hagen.de>
References: 
 <18A3A75A149A1C4F89705973ED81137911D3D9E6@Ymir.buerokommunikation.fernuni-hagen.de>,<570FD8FF.80503@kippdata.de>,<18A3A75A149A1C4F89705973ED81137911D3DA15@Ymir.buerokommunikation.fernuni-hagen.de>
In-Reply-To: 
 <18A3A75A149A1C4F89705973ED81137911D3DA15@Ymir.buerokommunikation.fernuni-hagen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: AW: [users@httpd] Can't activate LDAPS support in my OpenSSL
 1.0.2g/OpenLDAP 2.4.44/Apache 2.4.18/PHP 5.6.20 combination

Hello,=0A=
=0A=
I just realized that this may not be the problem, but the plugin architectu=
re is. I would have to check all modules in Apache and all extensions in PH=
P for dependencies to see all involved dependencies, wouldn't I?=0A=
=0A=
Regards,=0A=
Daniel P.=0A=
________________________________________=0A=
Von: Poggenpohl, Daniel [daniel.poggenpohl@fernuni-hagen.de]=0A=
Gesendet: Donnerstag, 14. April 2016 20:36=0A=
An: users@httpd.apache.org=0A=
Betreff: AW: [users@httpd] Can't activate LDAPS support in my OpenSSL 1.0.2=
g/OpenLDAP 2.4.44/Apache 2.4.18/PHP 5.6.20 combination=0A=
=0A=
Hello,=0A=
=0A=
that sounds reasonable and enlightening to me. Is there a ldd switch or oth=
er method so that I see the complete dependency tree starting from a binary=
/library I select? ldd -s doesn't seem to go down to the bottom.=0A=
=0A=
Regards,=0A=
Daniel P.=0A=
=0A=
________________________________________=0A=
Von: Rainer Jung [rainer.jung@kippdata.de]=0A=
Gesendet: Donnerstag, 14. April 2016 19:53=0A=
An: users@httpd.apache.org=0A=
Betreff: Re: [users@httpd] Can't activate LDAPS support in my OpenSSL 1.0.2=
g/OpenLDAP 2.4.44/Apache 2.4.18/PHP 5.6.20 combination=0A=
=0A=
Am 14.04.2016 um 17:02 schrieb Poggenpohl, Daniel:=0A=
> Hello everyone,=0A=
>=0A=
> thanks to this mailing list I have identified and solved many problems in=
 my builds regarding my current setup for a Moodle installation.=0A=
> - Removed unnecessary switches from Apache build=0A=
> - Placement of switches inside commands=0A=
> - new switches for selective runtime search path changing (even if I don'=
t use them yet...)=0A=
> - found new (to me) tools for checking info about binaries and libraries=
=0A=
> - Facts about the order of checking in runtime linking paths (-R, crle, L=
D_LIBRARY_PATH)=0A=
>=0A=
> So thanks for this so far, you've been very helpful.=0A=
>=0A=
> Yet two problems remain, which may or may be the same problem.=0A=
> - I have to set LD_LIBRARY_PATH to my own OpenSSL. Only then does PHPInfo=
 tell me that the correct OpenSSL is in use.=0A=
> - Using the system OpenLDAP, I can't connect using LDAPS. Using my own Op=
enLDAP 2.4.44, I can use LDAPS on the prompt and I can process a php file c=
ontaining commands to connect via LDAPS. I just can't request the same file=
 via the browser (PHP then reports that it can't bind to the LDAP server. I=
 also can't login via LDAP to Moodle, but get a an error that the secured c=
onnection can't be established. (I will send the exact error message if I r=
ecompile again to test).=0A=
>=0A=
> Checking in with ldd, all runtime search paths are set. I checked the pat=
hs for=0A=
> OpenSSL: openssl, libssl, libcrypto=0A=
> OpenLDAP: ldapsearch, libldap, liblber=0A=
> Apache: httpd, the apr and apr-util libraries, mod_ssl=0A=
> PHP: php, libphp5.so (in Apache)=0A=
>=0A=
> The only things that's looked strange are:=0A=
> - PHP uses Postgres libraries, which in turn depend on libssl and libcryp=
to. When I ldd, I have dependencies to both /my/own/openssl/install/lib and=
 to /usr/lib (libssl and libcrypto). But I think that's okay....?=0A=
> - PHP uses libcurl, it finds it in /usr/local/lib . This in turn depends =
on libssl and libcrypto and when I ldd libcurl, it finds them in /usr/lib. =
Again, I don't know? How deep do I have to go here?=0A=
>=0A=
> My configure commands for each of the four tools:=0A=
> # OpenSSL=0A=
> OPENSSLDIR=3D/moodle/openssl/1.0.2g \=0A=
> ; \=0A=
> export CFLAGS=3D"-I$OPENSSLDIR/include" \=0A=
> CFLAG=3D \=0A=
> CPPFLAGS=3D \=0A=
> LDFLAGS=3D \=0A=
> ; \=0A=
> ./Configure shared --openssldir=3D$OPENSSLDIR enable-ssl2 solaris-x86-gcc=
 \=0A=
> -I$OPENSSLDIR/include -L$OPENSSLDIR/lib -R$OPENSSLDIR/lib \=0A=
>> openssl-102g-configure.out=0A=
>=0A=
> # OpenLDAP=0A=
> OPENLDAPDIR=3D/moodle/openldap/2.4.44 \=0A=
> OPENSSLDIR=3D/moodle/openssl/1.0.2g \=0A=
> ; \=0A=
> export CPPFLAGS=3D"-I$OPENSSLDIR/include" \=0A=
> CFLAGS=3D \=0A=
> LDFLAGS=3D"-L$OPENSSLDIR/lib -R$OPENSSLDIR/lib" \=0A=
> ; \=0A=
> ./configure --prefix=3D$OPENLDAPDIR --disable-slapd --with-cyrus-sasl --w=
ith-tls=3Dopenssl \=0A=
>> openldap-2444-configure.out 2>&1=0A=
>=0A=
> # Apache=0A=
> APACHEDIR=3D/moodle/apache2/2.4.18 \=0A=
> OPENSSLDIR=3D/moodle/openssl/1.0.2g \=0A=
> ; \=0A=
> export PKG_CONFIG_PATH=3D$OPENSSLDIR/lib/pkgconfig \=0A=
> CFLAGS=3D \=0A=
> CPPFLAGS=3D"-I$OPENSSLDIR/include" \=0A=
> LDFLAGS=3D"-L$OPENSSLDIR/lib -R$OPENSSLDIR/lib" \=0A=
> ; \=0A=
> ./configure --prefix=3D$APACHEDIR \=0A=
> --enable-rewrite --enable-deflate \=0A=
> --enable-ssl --with-ssl=3D$OPENSSLDIR \=0A=
> --disable-version \=0A=
> --with-included-apr \=0A=
> --with-mpm=3Dprefork \=0A=
>> apache-2418-configure.out 2>&1=0A=
>=0A=
> # PHP=0A=
> APACHEDIR=3D/moodle/apache2/2.4.18 \=0A=
> POSTGRESDIR=3D /usr/postgres/9.3-pgdg \=0A=
> PHPDIR=3D/moodle/php/5.6.20 \=0A=
> OPENSSLDIR=3D/moodle/openssl/1.0.2g \=0A=
> ; \=0A=
> export PKG_CONFIG_PATH=3D$OPENSSLDIR/lib/pkgconfig \=0A=
> CFLAGS=3D"-std=3Dgnu99" \=0A=
> CPPFLAGS=3D"-I$OPENLDAPDIR/include -I$OPENSSLDIR/include" \=0A=
> LDFLAGS=3D"-L$OPENLDAPDIR/lib -L$OPENSSLDIR/lib -R$OPENLDAPDIR/lib -R$OPE=
NSSLDIR/lib" \=0A=
> ; \=0A=
> ./configure --prefix=3D$PHPDIR --with-config-file-path=3D$PHPDIR \=0A=
> --enable-mbstring --enable-soap --enable-zip --enable-opcache \=0A=
> --without-sqlite3 --without-pdo-sqlite \=0A=
> --with-pgsql=3D$POSTGRESDIR --with-pdo-pgsql=3D$POSTGRESDIR \=0A=
> --with-apxs2=3D$APACHEDIR/bin/apxs \=0A=
> --with-gd --with-curl --with-xmlrpc --with-zlib --with-mcrypt \=0A=
> --with-ldap=3D$OPENLDAPDIR \=0A=
> --with-openssl=3D$OPENSSLDIR --with-jpeg-dir=3D$PHPDIR/jpeg \=0A=
> --with-iconv=3D/usr/local \=0A=
>> php-5620-configure.out 2>&1=0A=
>=0A=
> I also have output for the different stages of the build if that would he=
lp.=0A=
=0A=
I don't have a complete answer, only some hints. The problem with PHP=0A=
is, that is uses lots of libraries. Once you start updating some of the=0A=
more complex ones, it can happen, that a non-updated lib uses the same=0A=
other lib as a dependency that your updated lib also uses. OpenSSL is a=0A=
common example for such a dependency. Than you run into trouble, because=0A=
it starts to become harder to decide, which version of that dependency=0A=
lib (OpenSSL in your case) is actually used when.=0A=
=0A=
Here symbol resolution comes into play. Say OpenSSl is linked into all=0A=
places it is needed as a shared object (dynamic linking, .so file), not=0A=
statically. Say you use PHp as mod_php, not via FPM. You start httpd,=0A=
which loads some modules and PHp as pone of the modules loads=0A=
extensions. Assume we have the following load order:=0A=
=0A=
- httpd=0A=
   - apr libs=0A=
   - ...=0A=
   - mod_php=0A=
     - php curl extension=0A=
       - libcurl=0A=
         - OpenSSL-old=0A=
     - php ldap extension=0A=
       - libldap=0A=
         - OpenSSL-new=0A=
   - ...=0A=
   - mod_ssl=0A=
     - OpenSSL-new=0A=
   - ...=0A=
=0A=
Now assume the PHP ldap extension starts to use OpenSSL symbols, e.g.=0A=
function calls. Since those are not statically compiled into the PHP=0A=
ldap.so file, it needs to look them up in the running process. By=0A=
default it starts looking inside httpd (not found), then the libs loaded=0A=
directly by httpd (not found), then through all of the shared objects in=0A=
the order they were loaded. In the above scenario it will find the=0A=
symbols in OpenSSL-old, since it was the first version loaded. Not what=0A=
you expect, because you compiled ldap.so against a new OpenLDAP which=0A=
was meant to use the new OpenSSL.=0A=
=0A=
As a result depending on the load order and the compatibility of the old=0A=
and new OpenSSL versions you either get the old version being used in=0A=
everything, or the new version, or a crash.=0A=
=0A=
That might explain your LD_LIBRARY_PATH observation, because then all of=0A=
the loaded parts will load the new OpenSSL (if they need OpenSSL, and=0A=
the SONAME hasn't changed betweeen the old and new version; the SONAME=0A=
for OpenSSL hasn't changed between 1.0.0 and 1.0.2 inclusive).=0A=
=0A=
What you can try to change if you don't like this:=0A=
=0A=
- if you only replace few parts by your own builds, you can try to link=0A=
OpenSSL statically into the parts you compile. That is not a great=0A=
solution, but it might be the simplest you get for your problem.=0A=
Depending on the build procedures, sometimes it can be enough to rename=0A=
the installed libssl.so and libcrypto.so files during building the=0A=
components that want to use them. If the build process is clean, they=0A=
should then automatically link in the .a (static) ones instead.=0A=
=0A=
- Since (I think) you are on Solaris, you can link with "-Bdirect" as a=0A=
linker flag, e.g. -Wl,-Bdirect for gcc. This changes the search path for=0A=
symbols searched by the created shared object to first search the=0A=
dependencies that were loaded for this object before starting to search=0A=
at the beginning of the tree. That way each modules/lib should use its=0A=
version of OpenSSL. But I can't guarantee, that there are no clashes. We=0A=
can't e sure, that those versions running in parallel do not influence=0A=
each other in any way."-Bdirect" doesn't exist in Linux. There was a=0A=
discussion about adding it a few years ago, but it wasn't agreed upon.=0A=
=0A=
I expect you LDAP problem is similar. Typically httpd or the apr-util=0A=
library loaded by httpd already has a dependency on libldap. httpd=0A=
indirectly, apr-util directly. So starting httpd, the system ldap libs=0A=
are loaded early. Later comes your PHP ldap extension which loads the=0A=
newer ldap you compiled yourself. But when it actually tries to use it,=0A=
the symbol resolution first hits the old ldap. Unfortunately there I=0A=
found no way how ldap.so in PHP could be asked about which version of=0A=
library it uses. Since you compiled OpenLDAp yourself, you could add a=0A=
debug output line to the impl of the ldap commect and check whether the=0A=
line appears on commandline use (expected) but not during browser use,=0A=
which would show that the other version is being used.=0A=
=0A=
Again: as long as the SONAME of the system ldap and you self-compiled=0A=
ldap shows they are compatible, you can try to add the path to your=0A=
newer OpenLDAP to LD_LIBRARY_PATH to try forcing every component to use it.=
=0A=
=0A=
I hope this was understandable.=0A=
=0A=
Regards,=0A=
=0A=
Rainer=0A=
=0A=
---------------------------------------------------------------------=0A=
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org=0A=
For additional commands, e-mail: users-help@httpd.apache.org=0A=
=0A=
=0A=
---------------------------------------------------------------------=0A=
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org=0A=
For additional commands, e-mail: users-help@httpd.apache.org=0A=
=0A=

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org