Apache will not start with OpenSSL from ports

RazorX

New Member


Messages: 10

I am trying to get www/apache22 working with security/openssl. It works with the system OpenSSL, but will not start with the one from ports. I have set
Code:
# /etc/make.conf
WITH_OPENSSL_PORT=yes
and I can compile and install both Apache and OpenSSL from ports. When I try to start Apache I get

Code:
httpd: Syntax error on line 9 of /usr/local/etc/apache22/httpd.conf: Syntax error on line 35 of /usr/local/etc/apache22/conf/modules.conf: Cannot load /usr/local/libexec/apache22/mod_ssl.so into server: /usr/local/libexec/apache22/mod_ssl.so: Undefined symbol "TLSv1_2_server_method"
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
I only have two thoughts at the moment, but I do not know how to test them:

  1. Apache thinks it's using the newer OpenSSL and expects TLSv1_2_server_method, but it loads the system OpenSSL and fails to find that.
  2. Apache expects the old OpenSSL and expects TLSv1_2_server_method, but loads the OpenSSL from ports and fails to find that.
Another idea is that the mod_ssl build by apache is not compatible with the openssl in ports.

Has anyone gotten this to work? Does anyone know how I can check what libs apache is loading and if those libs contain TLSv1_2_server_method?

Thank you for any help.
 

wblock@

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 3,634
Messages: 13,850

Did you build and install the OpenSSL port before the Apache port? Did you clean the Apache port before rebuilding it?
 
OP
OP
RazorX

RazorX

New Member


Messages: 10

Yes, I set the Makefile option, build and install OpenSSL, then for Apache I do

Code:
make clean
make
/usr/local/etc/rc.d/apache22 stop
make deinstall
make install
 

xtaz

Well-Known Member

Reaction score: 104
Messages: 409

I had the same problem for the last couple of months at least. It was working fine up to a point and then some upgrade changed the behaviour. I couldn't get it to work no matter which way round you compile the ports, full make cleans, etc. Nothing worked. Like you say it kind of appears that Apache detects one version of OpenSSL during building, and then uses the other version during run time or something like that.

In the end though I got annoyed enough at the fact there wasn't an apache24 port as I've been waiting for a long time for features that I need which are only in 2.4 that I just gave up and converted to nginx instead. And yes I know it's a volunteer project, I haven't complained, and was willing to wait for a while, but it's been too long now. Nginx won over time.
 

derekschrock

Member

Reaction score: 31
Messages: 79

Is there a solution to this issue? I ended up using base OpenSSL but I would rather use ports.
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

This is just a theory of mine, but I got intrigued after looking into the situation on my servers (I simply resort to using OpenSSL from the base system because it works for me).

I'm missing the mentioning of another name in this thread: devel/apr1. APR, or Apache Portable Runtime, is a project which provides an interface which can sit between an underlying operating system and Apache itself. This allows Apache to utilize specific locations to support functionality instead of having to start digging for specific items itself.

When you investigate the way www/apache22 utilizes crypto then you'll soon come across this library:

Code:
root@smtp2:/usr/ports/www/apache22 # grep ssl Makefile
APU_CRYPTO_SSL?=        ${LOCALBASE}/lib/apr-util-1/apr_crypto_openssl.so
root@smtp2:/usr/ports/www/apache22 # pkg_info -W /usr/local/lib/apr-util-1/apr_crypto_openssl.so
/usr/local/lib/apr-util-1/apr_crypto_openssl.so was installed by package apr-1.4.6.1.4.1_3
So the first to look out for is that you also use # make clean && make deinstall && make reinstall on devel/apr1. Or maybe even better, simply use portmaster to sort it all out: # portmaster -Rr devel/apr1.

I'm pretty sure this is the key to the issues, especially when you look at the way how devel/apr1 defines OpenSSL support:

Code:
root@smtp2:/usr/ports/devel/apr1 # grep openssl Makefile
APU_CONF_ARGS+= --with-openssl=${OPENSSLBASE}
APU_CONF_ARGS+= --without-openssl
This of course leads up to the question what OPENSSLBASE stands for and where it got defined. What better place to look than bsd.openssl.mk; this file defines exactly which OpenSSL version is to be used:

Code:
root@smtp2:/usr/ports/Mk # grep OPENSSLBASE bsd.openssl.mk
# OPENSSLBASE           - "/usr" or ${LOCALBASE}
OPENSSLBASE=            /usr
OPENSSLBASE=            ${LOCALBASE}
Better yet, also how us end-users can utilize all this:

Code:
# the user/port can now set this options in the makefiles.
#
# WITH_OPENSSL_BASE=yes - Use the version in the base system.
# WITH_OPENSSL_PORT=yes - Use the port, even if base is up to date
I know this build option has already been mentioned earlier in this thread, but when I start digging I like to go all the way. I don't use build options because they should work, I also want to know where they came from, how they were defined and sometimes even more important: why.

So, long story but my advice is to start by reinstalling devel/apr1, then see what happens.
 

nodnarb

New Member

Reaction score: 1
Messages: 3

I'm having the OPs problem when trying to enable mod_ssl, but recompiling apache22, openssl and apr1 has no effect regardless of the order. The "TLSv1_2_server_method" undefined symbol message still appears.

Using
Code:
WITH_OPENSSL_PORT=YES
in /etc/make.conf, /usr/local/sbin/httpd still links against /lib/libcrypt.so.5, not against /usr/local/lib/libcrypto.so.8 like everything else on this machine (except of course base packages, e.g. sshd).

Code:
root@walter:/usr/ports/www/apache22 # ldd /usr/local/sbin/httpd
/usr/local/sbin/httpd:
        libm.so.5 => /lib/libm.so.5 (0x800878000)
        libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x800a99000)
        libaprutil-1.so.5 => /usr/local/lib/libaprutil-1.so.5 (0x800cfb000)
        libdb-4.2.so.2 => /usr/local/lib/libdb-4.2.so.2 (0x800f20000)
        libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x801205000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80140c000)
        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801616000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801839000)
        libapr-1.so.4 => /usr/local/lib/libapr-1.so.4 (0x801b35000)
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x801d5f000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x801f7e000)
        libc.so.7 => /lib/libc.so.7 (0x8021a0000)
Using
Code:
WITH_OPENSSL_BASE=YES
option to at least get things up and running I get the following message:
Code:
Dependency error: this port wants the OpenSSL library from the FreeBSD
base system. You can't build against it, while a newer
version is installed by a port.
Please deinstall the port or undefine WITH_OPENSSL_BASE.
Well, I can't deinstall the openssl port currently, as this is a production system with several other apps linked against it. Makes more sense to not use Apache and SSL for the time being.

So I looked at the apache22 Makefile in hopes of pointing it to the right library by hand, but that doesn't seem to be an option.

What am I missing? Is there some other dependency I need to recompile? portupgrade -rfvn devel/apr1 gives this list, but nothing else seems relevant.

Code:
        + devel/apr1 (apr-1.4.8.1.5.2 -> apr-1.4.8.1.5.2)
        + www/apache22 (apache22-2.2.25 -> apache22-2.2.25)
        + lang/php5 (php5-5.4.19 -> php5-5.4.19)
        + archivers/php5-bz2 (php5-bz2-5.4.19 -> php5-bz2-5.4.19)
        + converters/php5-mbstring (php5-mbstring-5.4.19 -> php5-mbstring-5.4.19)
        + textproc/php5-dom (php5-dom-5.4.19 -> php5-dom-5.4.19)
        + devel/php5-json (php5-json-5.4.19 -> php5-json-5.4.19)
        + devel/php5-tokenizer (php5-tokenizer-5.4.19 -> php5-tokenizer-5.4.19)
        + textproc/php5-simplexml (php5-simplexml-5.4.19 -> php5-simplexml-5.4.19)
        + textproc/php5-xmlwriter (php5-xmlwriter-5.4.19 -> php5-xmlwriter-5.4.19)
        + www/php5-session (php5-session-5.4.19 -> php5-session-5.4.19)
        + databases/php5-sqlite3 (php5-sqlite3-5.4.19 -> php5-sqlite3-5.4.19)
        + converters/php5-iconv (php5-iconv-5.4.19 -> php5-iconv-5.4.19)
        + sysutils/php5-posix (php5-posix-5.4.19 -> php5-posix-5.4.19)
        + devel/php5-gettext (php5-gettext-5.4.19 -> php5-gettext-5.4.19)
        + databases/php5-pdo (php5-pdo-5.4.19 -> php5-pdo-5.4.19)
        + graphics/php5-gd (php5-gd-5.4.19 -> php5-gd-5.4.19)
        + databases/php5-pdo_sqlite (php5-pdo_sqlite-5.4.19 -> php5-pdo_sqlite-5.4.19)
        + security/php5-filter (php5-filter-5.4.19 -> php5-filter-5.4.19)
        + security/php5-openssl (php5-openssl-5.4.19 -> php5-openssl-5.4.19)
        + databases/php5-mysql (php5-mysql-5.4.19 -> php5-mysql-5.4.19)
        + databases/php5-odbc (php5-odbc-5.4.19 -> php5-odbc-5.4.19)
        + textproc/php5-ctype (php5-ctype-5.4.19 -> php5-ctype-5.4.19)
        + databases/php5-mysqli (php5-mysqli-5.4.19 -> php5-mysqli-5.4.19)
        + textproc/php5-xmlreader (php5-xmlreader-5.4.19 -> php5-xmlreader-5.4.19)
        + databases/php5-mssql (php5-mssql-5.4.19 -> php5-mssql-5.4.19)
        + print/pecl-pdflib (pecl-pdflib-2.1.10 -> pecl-pdflib-2.1.10)
        + textproc/php5-xml (php5-xml-5.4.19 -> php5-xml-5.4.19)
        + devel/pear (pear-1.9.4_2 -> pear-1.9.4_2)
        + security/php5-hash (php5-hash-5.4.19 -> php5-hash-5.4.19)
        + net/pear-Net_Socket (pear-Net_Socket-1.0.14 -> pear-Net_Socket-1.0.14)
        + archivers/php5-phar (php5-phar-5.4.19 -> php5-phar-5.4.19)
        + lang/php5-extensions (php5-extensions-1.7 -> php5-extensions-1.7)
        + mail/php5-imap (php5-imap-5.4.19 -> php5-imap-5.4.19)
        + www/pecl-APC (pecl-APC-3.1.14_1 -> pecl-APC-3.1.14_1)
        + security/php5-mcrypt (php5-mcrypt-5.4.19 -> php5-mcrypt-5.4.19)
        + net/pear-Net_URL (pear-Net_URL-1.0.15 -> pear-Net_URL-1.0.15)
        + archivers/php5-zip (php5-zip-5.4.19 -> php5-zip-5.4.19)
        + www/pear-HTTP_Request (pear-HTTP_Request-1.4.4 -> pear-HTTP_Request-1.4.4)
        + archivers/php5-zlib (php5-zlib-5.4.19 -> php5-zlib-5.4.19)
        + mail/phplist (phplist-2.10.18 -> phplist-2.10.19)
        + databases/phpmyadmin (phpMyAdmin-4.0.7 -> phpMyAdmin-4.0.7)
        + www/gallery3 (gallery3-3.0.4_1 -> gallery3-3.0.9)
        + devel/subversion (subversion-1.8.3 -> subversion-1.8.3)
        + textproc/docproj (docproj-1.17_13 -> docproj-1.17_13)
--->  Packages processed: 45 done, 0 ignored, 0 skipped and 0 failed
--->  Session ended at: Wed, 25 Sep 2013 15:12:18 -0500 (consumed 00:00:13)
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

nodnarb said:
I'm having the OPs problem when trying to enable mod_ssl, but recompiling apache22, openssl and apr1 has no effect regardless of the order.
Your message confuses me because it gives me the impression that you're simply rebuilding the ports without re-installing them. I concluded as much from your comment about how de-installing security/openssl isn't an option due to the machine being used for production.

But how do you expect to replace binaries if you're not willing to replace ports with newly built versions?

Another thing which comes to mind; you don't need to specify WITH_OPENSSL_BASE in your /etc/make.conf file because this is the default behaviour. It'll help, but it's not required.

As such my advice is to actually take the services down for a short moment and actually rebuild and re-install all ports involved.
 

nodnarb

New Member

Reaction score: 1
Messages: 3

I'm definitely reinstalling, not merely recompiling, when it comes to apache22, openssl and apr1. My point is simply that switching everything to BASE openssl would not be practical as a workaround. It's not that it isn't an option; I'd just rather avoid it, and fix the other part instead. Every other app can use the port, why not apache22?

In short,
take the services down for a short moment and actually rebuild and re-install all ports involved
... has been done already, in every conceivable order, to no avail. apache22 still links to the wrong library.
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

nodnarb said:
In short, ... has been done already, in every conceivable order, to no avail. apache22 still links to the wrong library.
You're drawing the wrong conclusions here.

Don't forget that Apache doesn't only utilizes encryption for communication (https) but it has to deal with local encryption too. For example the password library which you can utilize to password protect a file or directory. That is what you're seeing above.

But when it comes to https support it relies on devel/apr1 instead and that's where you should look. All it takes is adding the right option to /etc/make.conf as I mentioned in my earlier message:

Code:
root@smtp2:/usr/ports/devel/apr1 # make run-depends-list
/usr/ports/converters/libiconv
/usr/ports/databases/db42
/usr/ports/databases/gdbm
/usr/ports/databases/mysql51-client
/usr/ports/textproc/expat2
root@smtp2:/usr/ports/devel/apr1 # echo "WITH_OPENSSL_PORT=yes" >> /etc/make.conf
root@smtp2:/usr/ports/devel/apr1 # make run-depends-list
/usr/ports/converters/libiconv
/usr/ports/databases/db42
/usr/ports/databases/gdbm
/usr/ports/databases/mysql51-client
[B]/usr/ports/security/openssl[/B]
/usr/ports/textproc/expat2
 

kpa

Beastie's Twin

Reaction score: 1,801
Messages: 6,318

You have to track down dependencies of www/apache22 and also the dependencies of the dependencies to make sure all dynamically loaded shared libraries use the correct OpenSSL library. Use of an automated package builder solves the problem nicely because the builder can trace the dependencies down the lowest level automatically.

Shameless plug:

http://forums.freebsd.org/showthread.php?t=38859
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

Well, when looking at this issue a second time I now think @nodnarb has spotted something out of place here.

So I followed my own advice above and added WITH_OPENSSL_PORT=yes to /etc/make.conf and checked the build dependencies for www/apache22; it now relies on security/openssl:

Code:
root@smtp2:/usr/ports/www/apache22 # make build-depends-list
/usr/ports/converters/libiconv
/usr/ports/devel/apr1
/usr/ports/devel/autoconf
/usr/ports/devel/libtool
/usr/ports/devel/pcre
/usr/ports/lang/perl5.14
[B]/usr/ports/security/openssl[/B]
/usr/ports/textproc/expat2
The reason I'm looking at build dependencies and not run dependencies should be obvious; I have no intention to actually (re)install Apache on this system.

So now I've issued a # make build and checked the results:

Code:
root@smtp2:/usr/ports/www/apache22 # ldd work/httpd-2.2.25/httpd
work/httpd-2.2.25/httpd:
        libm.so.5 => /lib/libm.so.5 (0x800876000)
        libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x800a97000)
        libaprutil-1.so.5 => /usr/local/lib/libaprutil-1.so.5 (0x800cfa000)
        libdb-4.2.so.2 => /usr/local/lib/libdb-4.2.so.2 (0x800f1e000)
        libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x801204000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80140b000)
        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801615000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801839000)
        libapr-1.so.4 => /usr/local/lib/libapr-1.so.4 (0x801b35000)
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x801d61000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x801f80000)
        libc.so.7 => /lib/libc.so.7 (0x8021a2000)
Although my previous comment holds some truth about the difference between 'local encryption' and the dependency for using https it doesn't apply here. What I overlooked earlier is that OpenSSL should have provided support for encryption here as well.

After all; if Apache (better put: www/apache22) depends on OpenSSL (security/openssl) but then doesn't use it it doesn't add up:

Code:
root@smtp2:/usr/ports/www/apache22 # pkg_info -Lx openssl | grep libcrypto
/usr/local/lib/libcrypto.a
/usr/local/lib/libcrypto.so
[B]/usr/local/lib/libcrypto.so.8[/B]
/usr/local/libdata/pkgconfig/libcrypto.pc
So the expected behaviour here is an httpd executable linked against libcrypto.so.8.

I then continued my investigation and started looking at devel/apr1 and what do you know:

Code:
root@smtp2:/usr/ports/devel/apr1 # make build-depends-list
/usr/ports/converters/libiconv
/usr/ports/databases/db42
/usr/ports/databases/gdbm
/usr/ports/databases/mysql51-client
[B]/usr/ports/security/openssl[/B]
/usr/ports/textproc/expat2
root@smtp2:/usr/ports/devel/apr1 # ldd work/apr-1.4.8/.libs/libapr-1.so.4
work/apr-1.4.8/.libs/libapr-1.so.4:
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x80122c000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x80144b000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)
Simple conclusion: both ports claim to honour the build flag in make.conf but actually don't.

I'm going to look deeper into this later this evening to make sure that I'm not overlooking something obvious here.
 
Last edited by a moderator:
A

Anonymous

Guest


ShelLuser said:
...
Code:
root@smtp2:/usr/ports/devel/apr1 # make build-depends-list
/usr/ports/converters/libiconv
/usr/ports/databases/db42
/usr/ports/databases/gdbm
/usr/ports/databases/mysql51-client
[B]/usr/ports/security/openssl[/B]
/usr/ports/textproc/expat2
root@smtp2:/usr/ports/devel/apr1 # ldd work/apr-1.4.8/.libs/libapr-1.so.4
work/apr-1.4.8/.libs/libapr-1.so.4:
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x80122c000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x80144b000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)
...
Be careful, libcrypt (s. crypt(3)()) is a different animal than libcrypto (s. crypto(3)()). The latter one is part of OpenSSL of either flavour, while the first one is simply a library providing some password hashing algorithms present in unix compliant systems.

Some month ago, I switched my system to OpenSSL from the ports. Initially, I ran also in a lot of dependency problems, and I solved this by rebuilding all ports that are somehow dependent on OpenSSL.

In order to obtain the dependency list, I executed the following 2 shell pipelines that I derived from the example in ldd(1)():
# find /usr/local/bin /usr/local/sbin /usr/local/libexec /usr/local/lib -type f | xargs -n1 file -F ' ' | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libssl.so.6
# find /usr/local/bin /usr/local/sbin /usr/local/libexec /usr/local/lib -type f | xargs -n1 file -F ' ' | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libcrypto.so.6

Be prepared that the execution of this find pipelines may take some minutes each. It took me some additional time to figure out for some of the listed binaries to which port they belong. It's some time ago, and I remember vaguely that pkg_info(1)() was useful for this task.

Again, after rebuilding everything that was linked to the base OpenSSL libraries, all my ports are set now to operate flawlessly with security/openssl. Ahh..., and the best of all, there was no need to add any openssl voodoo to /etc/make.conf. As a matter of fact my /etc/make.conf is empty, i.e. does not exist.
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

In the mean time I took a closer look at this issue (learning some new things about the ports collection in the process, very cool) and I can only conclude that my first comment was correct, but still based on false assumptions. It's also where @nodnarb went wrong in his reasoning.

You see; what we all overlooked is that it's not httpd nor libapr-1.so.4 which provides support for https when looking at Apache. That job is reserved for mod_ssl.so. (I think it was pretty stupid of me to overlook this, but talking after the facts is always very easy).

Looking at my system we can obviously see this situation:

Code:
$ ldd /usr/local/libexec/apache22/mod_ssl.so
/usr/local/libexec/apache22/mod_ssl.so:
        [B]libssl.so.6 => /usr/lib/libssl.so.6 (0x801231000)[/B]
        [B]libcrypto.so.6 => /lib/libcrypto.so.6 (0x801486000)[/B]
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x801827000)
        libthr.so.3 => /lib/libthr.so.3 (0x801a46000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)
That's because I prefer to rely on the base system.

Now, there is some truth in my previous comment in that Apache relies on devel/apr1.

An important detail here is that devel/apr1 is also part of the build depends list of Apache. My system relies on the OpenSSL version supplied by the base system, and this is also what devel/apr1 has been compiled against. Long story cut short: Just using # make -C /usr/ports/www/apache22 build won't cut it for test casing this because the installed version of devel/apr1 on my system does not use the OpenSSL port (and I'm obviously not going to replace it on a production system ;)).

This is a job for central dogma
(or; my dogma jail).

So basically I compiled Apache (and it's devel/apr1 dependency) on a clean system where it automatically installed security/openssl in the process.

And now we can see for ourselves that Apache really is using the OpenSSL version supplied by the ports collection:

Code:
# pwd
/usr/ports/www/apache22/work/httpd-2.2.25/modules/ssl/.libs
# ldd ./mod_ssl.so
./mod_ssl.so:
        [B]libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801231000)[/B]
        [B]libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801497000)[/B]
        libc.so.7 => /lib/libc.so.7 (0x80081a000)
        libthr.so.3 => /lib/libthr.so.3 (0x80186a000)
Now, to complete my story lets also check out what httpd and libapr-1.so.4 are using in this environment:

Code:
# pwd
/usr/ports/www/apache22/work/httpd-2.2.25
# ldd ./httpd
./httpd:
        libm.so.5 => /lib/libm.so.5 (0x800876000)
        libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x800a97000)
        libaprutil-1.so.5 => /usr/local/lib/libaprutil-1.so.5 (0x800cfa000)
        libdb-4.2.so.2 => /usr/local/lib/libdb-4.2.so.2 (0x800f1e000)
        libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x801204000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80140b000)
        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801615000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801839000)
        libapr-1.so.4 => /usr/local/lib/libapr-1.so.4 (0x801b35000)
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x801d61000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x801f80000)
        libc.so.7 => /lib/libc.so.7 (0x8021a2000)
# cd /usr/ports/devel/apr1/work/apr-1.4.8/.libs
# ldd ./libapr-1.so.4
./libapr-1.so.4:
        [B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x80122c000)[/B]
        libthr.so.3 => /lib/libthr.so.3 (0x80144b000)
        libc.so.7 => /lib/libc.so.7 (0x80081a000)
As such, my previous simple conclusion was indeed too simplistic (as I somewhat expected, thus my comment that I'd be diving deeper into this).

There was nothing going wrong, we were just looking in the wrong places.

Man, I love stuff like this. Honestly guys; it may look tedious or such, but never underestimate the stuff you can learn from going over all this. It's just awesome in my opinion.
 
Last edited by a moderator:

nodnarb

New Member

Reaction score: 1
Messages: 3

And now we can see for ourselves that Apache really is using the OpenSSL version supplied by the ports collection:
Yes, but how do you get that to happen on an existing installation? You're right that we were looking in the wrong place initially, but even with this new information I still cannot figure out how to get /usr/local/libexec/apache22/mod_ssl.so to link against the PORT versions of openssl libraries that reside in /usr/local/lib/, and am obviously reluctant to start completely from scratch.

Your continued assistance is greatly appreciated!
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

nodnarb said:
Yes, but how do you get that to happen on an existing installation?
The best way I can come up with, though it might take a little while to complete, is basically this:

  • Add the following to /etc/make.conf:
    Code:
    WITH_OPENSSL_PORT=yes
  • Recompile Apache and all its dependencies using # portmaster -f www/apache22.
Keep in mind that this action will include re-installing stuff such as devel/apr1 which could interfere with your current setup (though I doubt that). Even so, it's probably a good idea to make sure that you can take the website(s) down for a short moment.

Another thing to keep in mind is that this reinstalls all of Apaches dependencies, which most likely will also include packages such as Perl. As such it can take a while to rebuild, depending on your system.
 
Top