httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: [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
Date Thu, 14 Apr 2016 17:53:03 GMT
Am 14.04.2016 um 17:02 schrieb Poggenpohl, Daniel:
> Hello everyone,
> thanks to this mailing list I have identified and solved many problems in my builds regarding
my current setup for a Moodle installation.
> - Removed unnecessary switches from Apache build
> - Placement of switches inside commands
> - new switches for selective runtime search path changing (even if I don't use them yet...)
> - found new (to me) tools for checking info about binaries and libraries
> - Facts about the order of checking in runtime linking paths (-R, crle, LD_LIBRARY_PATH)
> So thanks for this so far, you've been very helpful.
> Yet two problems remain, which may or may be the same problem.
> - I have to set LD_LIBRARY_PATH to my own OpenSSL. Only then does PHPInfo tell me that
the correct OpenSSL is in use.
> - Using the system OpenLDAP, I can't connect using LDAPS. Using my own OpenLDAP 2.4.44,
I can use LDAPS on the prompt and I can process a php file containing 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 connection can't be established. (I will send the exact error message if I recompile
again to test).
> Checking in with ldd, all runtime search paths are set. I checked the paths for
> OpenSSL: openssl, libssl, libcrypto
> OpenLDAP: ldapsearch, libldap, liblber
> Apache: httpd, the apr and apr-util libraries, mod_ssl
> PHP: php, (in Apache)
> The only things that's looked strange are:
> - PHP uses Postgres libraries, which in turn depend on libssl and libcrypto. 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....?
> - 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?
> My configure commands for each of the four tools:
> # OpenSSL
> OPENSSLDIR=/moodle/openssl/1.0.2g \
> ; \
> export CFLAGS="-I$OPENSSLDIR/include" \
> CFLAG= \
> ; \
> ./Configure shared --openssldir=$OPENSSLDIR enable-ssl2 solaris-x86-gcc \
>> openssl-102g-configure.out
> # OpenLDAP
> OPENLDAPDIR=/moodle/openldap/2.4.44 \
> OPENSSLDIR=/moodle/openssl/1.0.2g \
> ; \
> export CPPFLAGS="-I$OPENSSLDIR/include" \
> ; \
> ./configure --prefix=$OPENLDAPDIR --disable-slapd --with-cyrus-sasl --with-tls=openssl
>> openldap-2444-configure.out 2>&1
> # Apache
> APACHEDIR=/moodle/apache2/2.4.18 \
> OPENSSLDIR=/moodle/openssl/1.0.2g \
> ; \
> export PKG_CONFIG_PATH=$OPENSSLDIR/lib/pkgconfig \
> ; \
> ./configure --prefix=$APACHEDIR \
> --enable-rewrite --enable-deflate \
> --enable-ssl --with-ssl=$OPENSSLDIR \
> --disable-version \
> --with-included-apr \
> --with-mpm=prefork \
>> apache-2418-configure.out 2>&1
> # PHP
> APACHEDIR=/moodle/apache2/2.4.18 \
> POSTGRESDIR= /usr/postgres/9.3-pgdg \
> PHPDIR=/moodle/php/5.6.20 \
> OPENSSLDIR=/moodle/openssl/1.0.2g \
> ; \
> export PKG_CONFIG_PATH=$OPENSSLDIR/lib/pkgconfig \
> CFLAGS="-std=gnu99" \
> ; \
> ./configure --prefix=$PHPDIR --with-config-file-path=$PHPDIR \
> --enable-mbstring --enable-soap --enable-zip --enable-opcache \
> --without-sqlite3 --without-pdo-sqlite \
> --with-pgsql=$POSTGRESDIR --with-pdo-pgsql=$POSTGRESDIR \
> --with-apxs2=$APACHEDIR/bin/apxs \
> --with-gd --with-curl --with-xmlrpc --with-zlib --with-mcrypt \
> --with-ldap=$OPENLDAPDIR \
> --with-openssl=$OPENSSLDIR --with-jpeg-dir=$PHPDIR/jpeg \
> --with-iconv=/usr/local \
>> php-5620-configure.out 2>&1
> I also have output for the different stages of the build if that would help.

I don't have a complete answer, only some hints. The problem with PHP 
is, that is uses lots of libraries. Once you start updating some of the 
more complex ones, it can happen, that a non-updated lib uses the same 
other lib as a dependency that your updated lib also uses. OpenSSL is a 
common example for such a dependency. Than you run into trouble, because 
it starts to become harder to decide, which version of that dependency 
lib (OpenSSL in your case) is actually used when.

Here symbol resolution comes into play. Say OpenSSl is linked into all 
places it is needed as a shared object (dynamic linking, .so file), not 
statically. Say you use PHp as mod_php, not via FPM. You start httpd, 
which loads some modules and PHp as pone of the modules loads 
extensions. Assume we have the following load order:

- httpd
   - apr libs
   - ...
   - mod_php
     - php curl extension
       - libcurl
         - OpenSSL-old
     - php ldap extension
       - libldap
         - OpenSSL-new
   - ...
   - mod_ssl
     - OpenSSL-new
   - ...

Now assume the PHP ldap extension starts to use OpenSSL symbols, e.g. 
function calls. Since those are not statically compiled into the PHP file, it needs to look them up in the running process. By 
default it starts looking inside httpd (not found), then the libs loaded 
directly by httpd (not found), then through all of the shared objects in 
the order they were loaded. In the above scenario it will find the 
symbols in OpenSSL-old, since it was the first version loaded. Not what 
you expect, because you compiled against a new OpenLDAP which 
was meant to use the new OpenSSL.

As a result depending on the load order and the compatibility of the old 
and new OpenSSL versions you either get the old version being used in 
everything, or the new version, or a crash.

That might explain your LD_LIBRARY_PATH observation, because then all of 
the loaded parts will load the new OpenSSL (if they need OpenSSL, and 
the SONAME hasn't changed betweeen the old and new version; the SONAME 
for OpenSSL hasn't changed between 1.0.0 and 1.0.2 inclusive).

What you can try to change if you don't like this:

- if you only replace few parts by your own builds, you can try to link 
OpenSSL statically into the parts you compile. That is not a great 
solution, but it might be the simplest you get for your problem. 
Depending on the build procedures, sometimes it can be enough to rename 
the installed and files during building the 
components that want to use them. If the build process is clean, they 
should then automatically link in the .a (static) ones instead.

- Since (I think) you are on Solaris, you can link with "-Bdirect" as a 
linker flag, e.g. -Wl,-Bdirect for gcc. This changes the search path for 
symbols searched by the created shared object to first search the 
dependencies that were loaded for this object before starting to search 
at the beginning of the tree. That way each modules/lib should use its 
version of OpenSSL. But I can't guarantee, that there are no clashes. We 
can't e sure, that those versions running in parallel do not influence 
each other in any way."-Bdirect" doesn't exist in Linux. There was a 
discussion about adding it a few years ago, but it wasn't agreed upon.

I expect you LDAP problem is similar. Typically httpd or the apr-util 
library loaded by httpd already has a dependency on libldap. httpd 
indirectly, apr-util directly. So starting httpd, the system ldap libs 
are loaded early. Later comes your PHP ldap extension which loads the 
newer ldap you compiled yourself. But when it actually tries to use it, 
the symbol resolution first hits the old ldap. Unfortunately there I 
found no way how in PHP could be asked about which version of 
library it uses. Since you compiled OpenLDAp yourself, you could add a 
debug output line to the impl of the ldap commect and check whether the 
line appears on commandline use (expected) but not during browser use, 
which would show that the other version is being used.

Again: as long as the SONAME of the system ldap and you self-compiled 
ldap shows they are compatible, you can try to add the path to your 
newer OpenLDAP to LD_LIBRARY_PATH to try forcing every component to use it.

I hope this was understandable.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message