Apache recompile does not find new OpenSSL

Question

I'm trying to upgrade both Apache and OpenSSL at the same time. I've gotten Apache compiled with all the modules I need, and it pops up and runs, but still shows an old version of OpenSSL.

Here is my config command:

./configure --prefix=/usr/local/apache2.2.24/ --with-ssl=/usr/local/openssl-1.0.1e/ --enable-mods-shared="all [sic] ssl rewrite"

The OpenSSL in that directory is correct:

$ /usr/local/openssl-1.0.1e/bin/openssl version
OpenSSL 1.0.1e 11 Feb 2013

Yet, when I query the server I still get an old version of OpenSSL in the header:

$ curl -I http://www.mydomain.com/
HTTP/1.1 200 OK
Date: Thu, 09 May 2013 14:51:59 GMT
Server: Apache/2.2.24 (Unix) DAV/2 mod_ssl/2.2.24 OpenSSL/1.0.0g

I've recompiled a few hundred times over the last few days, and cannot figure out what I'm missing. Each of the directories has been deleted and made from scratch (including the source directories I'm compiling in).

The system is an older version of FreeBSD with a broken ports install, so I cannot use ports for the compile.

Solution 1

First, FIX YOUR PORTS - rm -rf /usr/ports if that's what it takes. This will not harm installed software. Use portsnap for an easy way to grab a new copy of the ports tree. Advanced users can use svn.

Second, DO NOT compile Apache from downloaded source. You're begging for trouble, and should NOT be surprised that you've found it. Use the ports tree. Even if you want to use a different version of software from the Ports tree, learn how to modify your local tree for the version you want.

Run ldd against the mod_ssl.so file, since you're compiling downloaded source the installation direction is probably non-standard (meaning future admins of your system will be unable to find the directory easily).

See what libssl.so it's using, and where it'll be loaded from. Make sure you have the latest OpenSSL libraries in that location.

When you build Apache from ports it should always build against the ports installed version of OpenSSL (libssl.so in /usr/local/lib). Since that's not the case it's anyone's guess as to what it's loading.

Solution 2

You may want to consider fixing your ports collection instead. If you're running an unsupported version, you may not be able to get the latest versions of the ports you want. Otherwise, you can follow the Handbook instructions on how to use portsnap to get yourself the latest ports collection.

Solution 3

One workaround is to use rpath when configuring apache, ie:

$ LDFLAGS=-Wl,-rpath=/opt/openssl/lib ./configure ...

Verify after installing apache:

$ ldd /opt/apache-httpd/modules/mod_ssl.so
...
    libssl.so.1.0.0 => /opt/openssl/lib/libssl.so.1.0.0 (0x00007fdd56278000)
    libcrypto.so.1.0.0 => /opt/openssl/lib/libcrypto.so.1.0.0 (0x00007fdd55e9c000)
...

Comments

[dawud]

Does the openssl in /usr/local include the development headers? if not, you are always linking against the older version.

[Jack M.]

It does have the include/openssl/ directory with all of the *.h files in it.

[Michael Hampton]

Read the config.log to see what it actually auto-detected.

[Jack M.]

Not sure exactly what to look for in config.log, but it looks like it found the one I specified: configure:13500: result: /usr/local/openssl-1.0.1e

[dawud]

Add a pointer to the directory containing the development headers using -L, check the output of ./configure --help=recursive for more info.

[Jack M.]

Just got done trying that: LDFLAGS="-s -L/usr/local/openssl-1.0.1e/ -Wl,-rpath=/usr/local/openssl-1.0.1e/" CFLAGS="-O2 -fPIC -I/usr/local/openssl-1.0.1e/" SSL_BASE=/usr/local/openssl-1.0.1e/lib/ ./configure [sic] No love.

[dawud]

If building a separate DSO with apxs is an option, you could try that approach

[Jack M.]

Unfortunately, my system is far enough out of date (and planned to be replaced in a few months) that I cannot compile from ports. Variable ALL_OPTIONS is recursive. is the biggest issue. As a result, compiling from source is somewhat required.

[Philip]

Is the error you're getting Unknown modifier ‘u’?

[Jack M.]

Yes. That's the other half of it. Unfortunately recompiling make is causing problems for some of our custom software that builds weekly.

[Philip]

I have to chime in with the token "you shouldn't running a system that old", but I'm sure you know already. You can download an older copy of the Mk scripts and the ports system will work again. See the 4 commands at the bottom of this post: cinto.in/?p=185