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?
Regards,
Daniel P.
________________________________________
Von: Poggenpohl, Daniel [daniel.poggenpohl@xxxxxxxxxxxxxxxx]
Gesendet: Donnerstag, 14. April 2016 20:36
An: users@xxxxxxxxxxxxxxxx
Betreff: AW: 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 [rainer.jung@xxxxxxxxxxx]
Gesendet: Donnerstag, 14. April 2016 19:53
An: users@xxxxxxxxxxxxxxxx
Betreff: Re: 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 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, libphp5.so (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= \
> CPPFLAGS= \
> LDFLAGS= \
> ; \
> ./Configure shared --openssldir=$OPENSSLDIR enable-ssl2 solaris-x86-gcc \
> -I$OPENSSLDIR/include -L$OPENSSLDIR/lib -R$OPENSSLDIR/lib \
>> openssl-102g-configure.out
>
> # OpenLDAP
> OPENLDAPDIR=/moodle/openldap/2.4.44 \
> OPENSSLDIR=/moodle/openssl/1.0.2g \
> ; \
> export CPPFLAGS="-I$OPENSSLDIR/include" \
> CFLAGS= \
> LDFLAGS="-L$OPENSSLDIR/lib -R$OPENSSLDIR/lib" \
> ; \
> ./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= \
> CPPFLAGS="-I$OPENSSLDIR/include" \
> LDFLAGS="-L$OPENSSLDIR/lib -R$OPENSSLDIR/lib" \
> ; \
> ./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" \
> CPPFLAGS="-I$OPENLDAPDIR/include -I$OPENSSLDIR/include" \
> LDFLAGS="-L$OPENLDAPDIR/lib -L$OPENSSLDIR/lib -R$OPENLDAPDIR/lib -R$OPENSSLDIR/lib" \
> ; \
> ./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
ldap.so 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 ldap.so 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 libssl.so and libcrypto.so 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 ldap.so 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: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|