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 18:51:16 GMT
Am 14.04.2016 um 20:39 schrieb Poggenpohl, Daniel:
> Hello,
> I just realized that this may not be the problem, but the plugin architecture is. I would
have to check all modules in Apache and all extensions in PHP for dependencies to see all
involved dependencies, wouldn't I?

On Solaris "pldd" is your friend. It works on a running process, so also 
shows shared objects loaded programattically via dlopen() etc. like 
Apache modules or PHP extensions.



> ________________________________________
> Von: Poggenpohl, Daniel []
> Gesendet: Donnerstag, 14. April 2016 20:36
> An:
> Betreff: 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,
> that sounds reasonable and enlightening to me. Is there a ldd switch or other 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.
> Regards,
> Daniel P.
> ________________________________________
> Von: Rainer Jung []
> Gesendet: Donnerstag, 14. April 2016 19:53
> An:
> Betreff: 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
> 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
>> - 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" \
>> CFLAGS= \
>> ; \
>> ./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 \
>> CFLAGS= \
>> ; \
>> ./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.
> Regards,
> Rainer

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

View raw message