After two very frustrating days, I have finally been able to perform what used to be a fairly routine thing for me, which is creating a FAMP server using FreeBSD, Apache 2.2.x, MySQL 5.x.x and PHP 5.5.x.
Several issues arose out of my attempts.
My first attempt was installing Apache 2.4.9, MySQL 5.6.17 and PHP 5.5.12 on FreeBSD 10.0-RELEASE-p3 (AMD64). This was my first time installing anything greater than MySQL 5.1.x. ‘./configure’ has been replaced with ‘cmake .’; other than that, all things ordinary. This was also my first time installing Apache 2.4.x and there are several new steps involved. The first is that you now have to manually install Apache’s portable runtime library and associated utilities. Piece of cake. Grabbed those from the APR website and installed without issue. Apache installed. But now the trouble. I was able to ‘./configure’ and ‘make’ PHP without issue, but during the ‘make install’ I ran into an issue.
# make install Installing PHP SAPI module: apache2handler /usr/local/httpd/build/instdso.sh SH_LIBTOOL='/usr/local/apr/build-1/libtool' libphp5.la /usr/local/httpd/modules /usr/local/apr/build-1/libtool --mode=install cp libphp5.la /usr/local/httpd/modules/ libtool: install: cp .libs/libphp5.lai /usr/local/httpd/modules/libphp5.la libtool: install: cp .libs/libphp5.a /usr/local/httpd/modules/libphp5.a libtool: install: chmod 644 /usr/local/httpd/modules/libphp5.a libtool: install: ranlib /usr/local/httpd/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.5.5/libs' Warning! dlname not found in /usr/local/httpd/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/httpd/modules/libphp5.so chmod: /usr/local/httpd/modules/libphp5.so: No such file or directory apxs:Error: Command failed with rc=65536
Keep in mind, this was a brand new, entirely fresh FreeBSD 10.0-RELEASE install with ‘freebsd-update’ run bringing it to -p3. Nothing else had been done on this box except the MySQL and Apache installs.
I found it very strange that in that small bunch of code, two separate libtools were referenced. Foolishly, I didn’t check my working server to compare. In any case, ‘/usr/local/apr/build-1/libtool’ and the libtool included with the PHP source were both referenced. For good measure, I even installed libtool using ‘pkg install’. Nothing worked and libphp5.so failed to be created. Not being a software developer, I went to Google looking for the answer but came up short. A few suggestions were to use the .bz2 version instead of the .tgz version, use ports and one person even pointed the finger at the AMD64 build of FreeBSD. I briefly attempted to install a known working version of libphp5.so from another one of my servers but that just created more issues. I moved on.
I reloaded the OS from scratch and tried again. Same result. I’m a sucker for punishment.
I then reinstalled the OS using FreeBSD 9.2-RELEASE. As before, I ran ‘freebsd-update’ first thing and brought it up to -6p. I compiled MySQL using the new steps I had learned earlier. Same with Apache, except I used 2.2.27 this time to simplify things; go with what you know. Then the true test, PHP 5.5.12, which also installed no problem. Added a few times to httpd.conf and started the server. Problem. I telneted to port 80 to see what version or OpenSSL I was using and it came back as 0.9.8y. This version isn’t vulnerable to the heartbleed vulnerability, but it does lack TLSv1.1 and TLSv1.2 support, which I need, if only to give my clients a greater sense of security. So I search Google for “freebsd upgrade openssl” and a few articles come up, including one I had recently visited. I went back, performed the needful using ports and OpenSSL was upgraded. Sort of. The base OpenSSL install has its binaries in /usr/bin, libraries in /usr/lib and config file in /etc. The port install puts the binaries in /usr/local/bin, the libraries in /usr/local/lib and the config file in /usr/local/etc/ssl. So I have two completely autonomous OpenSSL installs at this point. Typing ‘which openssl’ shows /usr/bin/openssl which is version 0.9.8y. ‘/usr/local/bin/openssl version’ shows 1.0.1g. Again, 0.9.8y is not vulnerable to heartbleed, but it is insufficient for my needs. After further reading, a few people suggested to remove the old binary and symlink /usr/local/bin/openssl to /usr/bin/openssl and also symlink the configuration files. This seemed to work, so I rebuilt Apache again thinking that version 1.0.1g would show up. But it didn’t. Knowing that this was a new install and that I would probably blow it away once I found a working formula, I started deleting things, symlinking things, moving things, etc. I reminded myself of my father-in-law who while looking to free up space on his internal HDD, he deleted his windows system files with the rational of “I’ve never used those, I can delete them.” A mess I made. Server trashed. Blank slate.
Again, I started with FreeBSD 9.2-RELEASE. I immediately updated using freebsd-update to -p6. I then downloaded and installed OpenSSL 1.0.1g from the OpenSSL website. I then confirmed that my base and secondary install were as expected:
# /usr/bin/openssl version OpenSSL 0.9.8y 5 Feb 2013
Good.
# /usr/local/ssl/bin/openssl version OpenSSL 1.0.1g 7 Apr 2014
Great.
When it came to compiling Apache, I had to compile mod_ssl as a static module. In the process, a few of the core modules were also made static, so I had a mishmash of static and dynamic. I had to comment out a few of the LoadModule statements in the httpd.conf, but in the end, everything works as it should.
[root@server01 ~]# telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HTTP/1.1 / GET HTTP/1.1 501 Method Not Implemented Date: Wed, 28 May 2014 23:07:36 GMT Server: Apache/2.2.27 (Unix) DAV/2 PHP/5.5.12 mod_ssl/2.2.27 OpenSSL/1.0.1g Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 220 Connection: close Content-Type: text/html; charset=iso-8859-1
Success! I now have a server running exactly the way I want and I have no compromised any of the base OpenSSL files, or anything that was built against them. While I think this was a fairly good way to accomplish this task, there are probably even better ways to do it. However, my Googling efforts did not lead me to those.
Another other method, which some will say is more elegant, would have been to install from pkg or ports. However, I disagree. Since I compiled my first web server twenty years ago to present day, I have always been an advocate of compiling critical services from source. If all you ever do is type ‘pkg install apache22’ how do you learn to troubleshoot when something goes wrong? How do you know how to fine tune your installation when you need to compile in sockets, or curl, or other libraries and modules? I prefer infinite control.