Intro
This is a tale of one thing leading to another. I’ll probably either continue this post or delete it altogether if I find I’m headed down a wrong path.
The details
I suspect that to get better marks for my server’s SSL implementation I probably need apache 2.4. There is an RPM for apache 2.4 but it is almost two years old! So I decided to bite the bullet and compile the darn thing myself. Easier said than done. My current production version is 2.2.15.
Now if you just want to compile a recent version of apache 2.4 then this guide is much, much better than mine: https://jasonpowell42.wordpress.com/2013/04/05/install-apache-2-4-4-on-centos-6-4/. My guide, where I’ve hit just about every conceivable error and powered through, is more for timid folks like me who want to keep their current apache 2.2 running while trying 2.4. In spite of what you read elsewhere this is possible to do, but you need patience and perseverance.
Getting the source is easy enough. Then you configure it:
httpd-2.4.16$ ./configure −−prefix=/usr/local/apache24
checking for chosen layout... Apache checking for working mkdir -p... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu configure: configure: Configuring Apache Portable Runtime library... configure: checking for APR... configure: WARNING: APR version 1.4.0 or later is required, found 1.3.9 configure: WARNING: skipped APR at apr-1-config, version not acceptable no configure: error: APR not found. Please read the documentation. |
What version of apr do we have?
$ sudo rpm −qa|grep apr
apr-util-devel-1.3.9-3.el6_0.1.x86_64 apr-util-1.3.9-3.el6_0.1.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 apr-1.3.9-5.el6_2.x86_64 apr-devel-1.3.9-5.el6_2.x86_64 |
Drat. No wonder we’re having trouble. Guess we could compile apr ourselves, but perhaps there’s a suitable version out there somewhere we can simply download?
Warning: this approach to apr shown below was a dead end for me. Further down I show a successful approach.
$ sudo yum search apr
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: linux.cc.lehigh.edu
* epel: mirror.us.leaseweb.net
* extras: mirror.rackspace.com
* updates: mirror.es.its.nyu.edu
========================================================== N/S Matched: apr ==========================================================
...
httpd24-apr-debuginfo.x86_64 : Debug information for package httpd24-apr
httpd24-apr-devel.x86_64 : APR library development kit
httpd24-apr-util-debuginfo.x86_64 : Debug information for package
: httpd24-apr-util
httpd24-apr-util-devel.x86_64 : APR utility library development kit
httpd24-apr-util-ldap.x86_64 : APR utility library LDAP support
httpd24-apr-util-mysql.x86_64 : APR utility library MySQL DBD driver
httpd24-apr-util-nss.x86_64 : APR utility library NSS crytpo support
httpd24-apr-util-odbc.x86_64 : APR utility library ODBC DBD driver
httpd24-apr-util-openssl.x86_64 : APR utility library OpenSSL crytpo support
httpd24-apr-util-pgsql.x86_64 : APR utility library PostgreSQL DBD driver
httpd24-apr-util-sqlite.x86_64 : APR utility library SQLite DBD driver
httpd24-apr.x86_64 : Apache Portable Runtime library
httpd24-apr-util.x86_64 : Apache Portable Runtime Utility library
... |
I singled out the promising looking ones. After all it’s apache 2.4 that’s driving the need for this version so the httpd24 versions of apr should suffice.
So I installed these:
$ sudo yum install httpd24-apr-util.x86_64
$ sudo yum install httpd24-apr-util-devel.x86_64
Now how do we tell the configurator where our new apr package is?
httpd-2.4.16$ ./configure −−help|grep −i apr
--enable-hook-probes Enable APR hook probes
--with-included-apr Use bundled copies of APR/APR-Util
--with-apr=PATH prefix for installed APR or the full path to
apr-config
--with-apr-util=PATH prefix for installed APU or the full path to |
The with-apr switch looks promising. Now we guess as to exactly what we should put for the path. Here’s what happens when we guess wrong:
httpd-2.4.16$ ./configure −−with-apr=/opt/rh/httpd24/root/usr/lib64 −−prefix=/usr/local/apache24
checking for chosen layout... Apache checking for working mkdir -p... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu configure: configure: Configuring Apache Portable Runtime library... configure: checking for APR... configure: error: the --with-apr parameter is incorrect. It must specify an install prefix, a build directory, or an apr-config file. |
I’ll spare you the guesswork. Here is the path correctly specified:
httpd-2.4.16$ ./configure −−with-apr=/opt/rh/httpd24/root/usr −−prefix=/usr/local/apache24
... configure: Configuring Apache Portable Runtime Utility library... configure: checking for APR-util... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for gcc option to accept ISO C99... -std=gnu99 checking for pcre-config... false configure: error: pcre-config for libpcre not found. PCRE is required and available from http://pcre.org/ |
So we finally got past the apr error and are onto the next one : (. I’ll try to install pcre-devel to see if that helps:
$ sudo yum install pcre-devel.x86_64
Wow! Got lucky that time. That cleared up that error and the configure went all the way through!
Oh, no. It doesn’t compile! It begins to, but it can’t compile export.c:
httpd-2.4.16$ make
... gawk -f /usr/local/src/apache24/httpd-2.4.16/build/make_exports.awk `cat export_files` > exports.c /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc -std=gnu99 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I. -I/usr/local/src/apache24/httpd-2.4.16/os/unix -I/usr/local/src/apache24/httpd-2.4.16/include -I/opt/rh/httpd24/root/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/local/src/apache24/httpd-2.4.16/modules/aaa -I/usr/local/src/apache24/httpd-2.4.16/modules/cache -I/usr/local/src/apache24/httpd-2.4.16/modules/core -I/usr/local/src/apache24/httpd-2.4.16/modules/database -I/usr/local/src/apache24/httpd-2.4.16/modules/filters -I/usr/local/src/apache24/httpd-2.4.16/modules/ldap -I/usr/local/src/apache24/httpd-2.4.16/modules/loggers -I/usr/local/src/apache24/httpd-2.4.16/modules/lua -I/usr/local/src/apache24/httpd-2.4.16/modules/proxy -I/usr/local/src/apache24/httpd-2.4.16/modules/session -I/usr/local/src/apache24/httpd-2.4.16/modules/ssl -I/usr/local/src/apache24/httpd-2.4.16/modules/test -I/usr/local/src/apache24/httpd-2.4.16/server -I/usr/local/src/apache24/httpd-2.4.16/modules/arch/unix -I/usr/local/src/apache24/httpd-2.4.16/modules/dav/main -I/usr/local/src/apache24/httpd-2.4.16/modules/generators -I/usr/local/src/apache24/httpd-2.4.16/modules/mappers -prefer-non-pic -static -c exports.c && touch exports.lo exports.c:1244: error: redefinition of ‘ap_hack_apr_allocator_create’ exports.c:198: note: previous definition of ‘ap_hack_apr_allocator_create’ was here exports.c:1245: error: redefinition of ‘ap_hack_apr_allocator_destroy’ exports.c:199: note: previous definition of ‘ap_hack_apr_allocator_destroy’ was here exports.c:1246: error: redefinition of ‘ap_hack_apr_allocator_alloc’ exports.c:200: note: previous definition of ‘ap_hack_apr_allocator_alloc’ was here exports.c:1247: error: redefinition of ‘ap_hack_apr_allocator_free’ exports.c:201: note: previous definition of ‘ap_hack_apr_allocator_free’ was here exports.c:1248: error: redefinition of ‘ap_hack_apr_allocator_owner_set’ |
This could be tough! Maybe impossible for me to get past. I’ve never encountered this kind of error. OK. Got it. Not so tough. I had two versions of apr installed – the old one needed by my apache 2.2 and the new one installed as shown above. I didn’t want to completely blow away the old one as I feared that it is dynamically linked by Apache 2.2, so I did the following:
$ cd /usr/lib64; sudo mv apr-1 drjapr-1
– then change to my apache24 root directory and run configure again; then run make
And it went through this time!
Only modules installed
make install however only installed modules, not the httpd binary.
The problem seems related to my original apr libraries. They look like this:
$ sudo rpm −qa|grep ^apr
apr-util-devel-1.3.9-3.el6_0.1.x86_64 apr-util-1.3.9-3.el6_0.1.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 apr-1.3.9-5.el6_2.x86_64 apr-devel-1.3.9-5.el6_2.x86_64 |
I tried to move them all to a temporary directory but then the compiler cannot find libtool which is normally supplied by apr-devel.
I considered removing apr-devel, but boy there are so many dependencies that my other packages have on it that I did not feel comfortable doing that. PHP, apache2.2 and a whole lot more depend on it.
End of dead end approach to apr
New approach needed
My new approach is to try to use the APR from apache itself by downloaded the Unix sources for APR and apr-util from http://apr.apache.org/download.cgi. Yes, this worked best of all. I even put back all the apr files I had moved in the previous failed effort.
It’s not very clear what they mean by unpacking apr and apr-util in srclib. I created symlinks in my srclib directory such that apr -> apr-1.5.2 and apr-util -> apr-util-1.5.4. For the inexperienced the command format is like in this example:
$ ln −s apr-1.5.2 apr
Of course you first have to download the source tarball to your srclib directory and unpack it:
$ tar zxf apr-1.5.2.tar.gz
It Compiles and Installs
So after all those misfires I finally got a version that compiled and installed in its entirety. That process starts with this configure command:
$ ./configure −−with-included-apr −−prefix=/usr/local/apache24
Then the usual make and sudo make install.
Modules problem
I inherited a configuration that had a mods-avalable and a mods-enabled directory which is how my old apache 2.2 was set up. After tweaking the modules path using the replace command, something like this
$ cd /etc; cp −pr apache2 apache24; cd mods-avalable
$ sudo replace /usr/lib/apache2 /usr/local/apache24 −− *.load
I still could not start my new server:
Starting apache24: httpd: Syntax error on line 203 of /etc/apache24/apache24.conf: Syntax error on line 1 of /etc/apache24/mods-enabled/authz_default.load: Cannot load /usr/local/apache24/modules/mod_authz_default.so into server: /usr/local/apache24/modules/mod_authz_default.so: cannot open shared object file: No such file or directory
[FAILED] |
I looked at all my configuration files and don’t see anything that relies on this module so I deleted the reference to it in mods-enabled.
Starting apache24: httpd: Syntax error on line 203 of /etc/apache24/apache24.conf: Syntax error on line 1 of /etc/apache24/mods-enabled/cgi.load: Cannot load /usr/local/apache24/modules/mod_cgi.so into server: /usr/local/apache24/modules/mod_cgi.so: cannot open shared object file: No such file or directory
[FAILED] |
Now I do like to run CGI programs on occasion so this one can’t be so easily brushed aside. It could be that we should be using mod_cgid.so instead.
Then it’s onto this error:
Starting apache24: httpd: Syntax error on line 203 of /etc/apache24/apache24.conf: Syntax error on line 1 of /etc/apache24/mods-enabled/php5.load: Cannot load /usr/local/apache24/modules/libphp5.so into server: /usr/local/apache24/modules/libphp5.so: cannot open shared object file: No such file or directory
[FAILED] |
I use php so I may have to investigate this one in some detail. simply trying to update the link to where the old libphp5.so resides under apache2.2 brings up this different kind of error:
Starting apache24: httpd: Syntax error on line 203 of /etc/apache24/apache24.conf: Syntax error on line 1 of /etc/apache24/mods-enabled/php5.load: Cannot load /usr/lib/apache2/modules/libphp5.so into server: /usr/lib/apache2/modules/libphp5.so: undefined symbol: unixd_config
[FAILED] |
Wow. I’m reading various things and it looks like I’ll now have to compile php5 as well. This is getting hairy. This site, although old, seems to explain it most clearly. And of course I’ve got php 5.3 which you can’t even find source for on the php web site, www.php.net
So I downloaded php5.4.43, which is the oldest one I could find on the php web site!
To configure it I used this long list of options, some of which are determined by my choices of location for my apache24 files:
$ ./configure ‐‐with‐apxs2=/usr/local/apache24/bin/apxs ‐‐with‐mysql ‐‐prefix=/usr/local/apache24/php5 ‐‐with‐config‐file ‐path=/usr/local/apache24/php5 ‐‐disable‐cgi ‐‐with‐zlib ‐‐with‐gettext ‐‐with‐gdbm ‐‐with‐curl ‐‐with‐openssl
2017 update for php
I finally needed to update some WordPress packages and found my only transport is ftp. I think my command-line compile options for php5 above leave something to be desired. I think I need to add curl and openssl like so:
$ ./configure ‐‐with‐apxs2=/usr/local/apache24/bin/apxs ‐‐with‐mysql ‐‐prefix=/usr/local/apache24/php5 ‐‐with‐config‐file ‐path=/usr/local/apache24/php5 ‐‐disable‐cgi ‐‐with‐zlib ‐‐with‐gettext ‐‐with‐gdbm ‐‐with‐curl ‐‐with‐openssl
but I get these errors:
ext/curl/.libs/interface.o: In function `php_curl_option_url': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:180: undefined reference to `core_globals' ext/curl/.libs/interface.o: In function `_php_curl_setopt': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1821: undefined reference to `core_globals' /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1804: undefined reference to `core_globals' ext/curl/.libs/interface.o: In function `curl_progress': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1113: undefined reference to `executor_globals' ext/curl/.libs/interface.o: In function `curl_write_header': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1264: undefined reference to `executor_globals' ext/curl/.libs/interface.o: In function `curl_write': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1038: undefined reference to `executor_globals' ext/curl/.libs/interface.o: In function `curl_read': /usr/local/src/php5/php-5.4.43/ext/curl/interface.c:1187: undefined reference to `executor_globals' ext/curl/.libs/streams.o: In function `php_curl_stream_opener': /usr/local/src/php5/php-5.4.43/ext/curl/streams.c:320: undefined reference to `file_globals' /usr/local/src/php5/php-5.4.43/ext/curl/streams.c:406: undefined reference to `core_globals' /usr/local/src/php5/php-5.4.43/ext/curl/streams.c:414: undefined reference to `core_globals' ext/curl/.libs/streams.o: In function `on_data_available': /usr/local/src/php5/php-5.4.43/ext/curl/streams.c:68: undefined reference to `executor_globals' ext/standard/.libs/info.o: In function `php_info_print_request_uri': /usr/local/src/php5/php-5.4.43/ext/standard/info.c:97: undefined reference to `sapi_globals' ext/standard/.libs/info.o: In function `php_print_gpcse_array': /usr/local/src/php5/php-5.4.43/ext/standard/info.c:213: undefined reference to `executor_globals' ext/standard/.libs/info.o: In function `php_print_info': /usr/local/src/php5/php-5.4.43/ext/standard/info.c:918: undefined reference to `executor_globals' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 |
Here the problem seems to be that since I had already compiled php5 and left it around, it was using the old parts.
You need to do a make clean first! Then it compiles.
Now I’m down to this apache error:
$ sudo service apache24 start
Starting apache24: AH00526: Syntax error on line 55 of /etc/apache24/apache24.conf:
Invalid command 'LockFile', perhaps misspelled or defined by a module not included in the server configuration
[FAILED] |
I’m going to just try to comment out that pesky Option LockFile…. I’ve found this apache page which is helpful for this upgrade: http://httpd.apache.org/docs/trunk/upgrading.html OK, next error:
Starting apache24: AH00526: Syntax error on line 145 of /etc/apache24/apache24.conf:
Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration
[FAILED] |
Here the advice is to load module mod_unixd. I don’t even have anything like that so I’m looking into it now. OK. It’s in the apache24/modules so I just need to load it in. Next error:
Starting apache24: AH00526: Syntax error on line 161 of /etc/apache24/apache24.conf: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration |
Wow. That comes from this pretty standard line:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy all
</Files> |
This is a helpful document: http://httpd.apache.org/docs/trunk/upgrading.html. So at their recommendation I replaced all that with a
Require all denied |
That leads to the next error:
Starting apache24: AH00526: Syntax error on line 166 of /etc/apache24/apache24.conf: Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration |
It means Require is not even found. I needed to load some new modules, names authz_code and unixd:
LoadModule authz_core_module /usr/local/apache24/modules/mod_authz_core.so LoadModule unixd_module /usr/local/apache24/modules/mod_unixd.so |
Next error:
AH00526: Syntax error on line 20 of /etc/apache24/mods-enabled/alias.conf: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration |
so some of my old conf files that I copied over use the old syntax. The alias.conf file looked like this:
Alias /icons/ "/var/www/icons/"
<Directory "/var/www/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory> |
Again looking at http://httpd.apache.org/docs/trunk/upgrading.html they suggest to replace the Order… and following line with:
Require all granted |
Next error:
AH00526: Syntax error on line 3 of /etc/apache24/mods-enabled/deflate.conf:
Invalid command 'AddOutputFilterByType', perhaps misspelled or defined by a module not included in the server configuration
[FAILED] |
But I was already loading the deflate module which defines AddOutputfilterByType. What I learned is that in apache 2.4 you also need to load mod_filter.
And the next error please:
AH00526: Syntax error on line 43 of /etc/apache24/mods-enabled/ssl.conf: SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?). |
That’s in complaint about this line:
SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000) |
The standard advice for this error is to uncomment this line:
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so |
But I don’t have that module!
I guess I chose the wrong options when doing the initial ./configure. See the references for a proper guide that lists some good options.
I’m now trying to configure like this:
$ ./configure −−with-included-apr −−prefix=/usr/local/apache24 −−enable-php5 −−enable-so −−enable-ssl −−with-mpm=prefork
Actually I don’t know if I needed all those options such as enable-ssl. The main thing was that my apache 2.2 mods-available directory didn’t have a mention of mod_socache_shmcb.so. My apache 2.4 built with these config options definitely does. so I just need one of these LoadModule statements like this:
LoadModule socache_shmcb_module /usr/local/apache24/modules/mod_socache_shmcb.so |
Well we’ve moved six lines down into that config file. I guess that’s progress! because now we’ve made it all the wy to line 49:
AH00526: Syntax error on line 49 of /etc/apache24/mods-enabled/ssl.conf:
Invalid command 'SSLMutex', perhaps misspelled or defined by a module not included in the server configuration
[FAILED] |
Even apache’s upgrade guide documents this error. It’s caused by a conf file line that looks something like this:
SSLMutex file:${APACHE_RUN_DIR}/ssl_mutex |
and they say – I’m paraphrasing here – just try to comment it out and hope for the best.
Next error:
AH00526: Syntax error on line 9 of /etc/apache24/mods-enabled/status.conf:
Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration
[FAILED] |
Yeah status.conf has
Order deny,allow
Deny from all
Allow from 127.0.0.1 ::1 |
We’ll try to replace that with this:
Require host 127.0.0.1 ::1 |
Now it runs through all the configuration OK but doesn’t actually start. I had set up an init.d script and I wasn’t going to go into this but I may have to:
$ sudo service apache24 start
httpd (pid 30896) already running |
Remember I am trying to run this while still running the old apache 2.2 server. Process 30896 is the old apache 2.2:
root 30896 1 0 10:05 ? 00:00:00 /usr/sbin/httpd -d /etc/apache2 -f apache2.conf |
This results from the byzantine way I set up to launch apache. There is a /etc/sysconfig/apache24 which doesn’t do much other than import environment variable definitions from /etc/apache24/envvars, except I had forgotten to update that path so it pointed to the old /etc/apache2/envvars.
Now it starts! But not without complaint:
Starting apache24: [Thu Aug 06 11:18:04.711658 2015] [core:warn] [pid 22911] AH00117: Ignoring deprecated use of DefaultType in line 178 of /etc/apache24/apache24.conf.
[ OK ] |
That stems from this line which tries to establish a default MIME type:
DefaultType text/plain |
I also notice I cannot really get the status of my new web server:
$ sudo service apache24 status
httpd dead but subsys locked |
So stopping/starting doesn’t really work either once it’s started.
What I found is that it seems happier if I have a line in /etc/sysconfig/apache24 which has an explicit PIDFILE defined – I use PIDFILE=/var/run/apache24.pid – with the same filepath as is mentioned in the apache24.conf file, where I have PidFile ${APACHE_PID_FILE} where APACHE_PID_FILE is taken from my envvars and has the value /var/run/apache24.pid. OK, my setup is very convoluted and probably unique. But the problem is common on CentOS so the main takeway is to have consistent reference to the pidfile filepath in /etc/sysconfig/httpd or whatever you are calling it as in your main config file httpd.conf or whatever you are calling it.
Home page test (I’m running on port 1443 to avoid conflict with my production server):
$ curl −i −k https://127.0.0.1:1443/
HTTP/1.1 301 Moved Permanently Date: Wed, 05 Aug 2015 18:33:19 GMT Server: Apache/2 X-Powered-By: PHP/5.4.43 Location: https://drjohnstechtalk.com/blog/ Content-Length: 2 Content-Type: text/html |
So that looks pretty good.
A simple php test:
$ curl −i −k https://127.0.0.1:1443/phpinfo.php
Long output. Basically looks right.
OK. What about the opening WordPress page?
$ curl −i −H ‘Host: drjohnstechtalk.com’ −k https://127.0.0.1:1443/blog/
Yes. Big long output. Looks good. I don’t think this proves that the mySQL/php interface is really working however as that page could be cached since I use a pagecache plugin.
Next test I’d like to run is the Qualys SSLLabs test, but it won’t run on port 1443. Maybe the DigiCERT test will. Yes, it does allow it. And I no longer have the BREACH vulnerability.
A few words about a BREACH test
This prompted me to look at why Digicert felt I was vulnerable to BREACH in the first place. I thnk it’s related to serving compressed objects. So I thought of this simple test. Against my apache 2.2 I can run a query like this:
$ curl −i −k −−compress https://127.0.0.1:1443/blog/|head −10
Date: Fri, 07 Aug 2015 14:02:48 GMT Server: Apache/2 X-Powered-By: PHP/5.3.3 Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 30414 Content-Type: text/html <!DOCTYPE html> <html lang="en-US"> |
See that Content-Encoding: gzip? Yet the actual content that begins <!DOCTYPE html… is in plain text and plainly not compressed. So I really wasn’t vulnerable to BREACH at all. The server claimed to be compressing the pages it was sendnig to the browser but in reality it wasn’t. For apache 2.4 the behaviour is basically the same except there is no response header Content-Encoding: gzip returned. This is why it passes Digicert’s BREACH test with flying colors.
Moving on
Next test. Swap apache 2.2 for apache 2.4 by changing listening ports 443 for 1443. Then do the SSLlabs test. I now get an A. well, actually I get an A both before and after the swap.
WordPress test
I’m writing this using my new shiny apache 2.4. With regards to WordPress it all seems to feel the same as before. One small thing I’ve noticed is that I don’t get WordPress news any longer:
RSS Error: WP HTTP Error: There are no HTTP transports available which can complete the requested request. |
Hopefully there’s nothing more serious.
php.ini missing
If you blindly copied my config options for compiling php then sooner or later (much later in my case) you’ll realize that you have no valid php.ini file! You will see an error like this when the date() function is called:
Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in |
So because I used the config option –with-config-fil
e-path=/usr/local/apache24/php5 I needed to put a php.ini file in that directory and only that directory. For now its contents are:
; DrJ, inspired by http://stackoverflow.com/questions/2184513/php-change-the-maximum-upload-file-size - 12/31/14 ; Maximum allowed size for uploaded files. upload_max_filesize = 10M ; Must be greater than or equal to upload_max_filesize post_max_size = 10M ; You'll need this to avoid errors with the Date function ; http://stackoverflow.com/questions/16765158/date-it-is-not-safe-to-rely-on-the-systems-timezone-settings [Date] ; Defines the default timezone used by the date functions ; http://php.net/date.timezone date.timezone = America/New_York |
Appendix A
mod_ssl error after patching
I have an apache 2.2.21 server on a SLES server. After a system patch (I guess) I realized the apache web server wouldn’t start. It shows this error:
> sudo service apache201 start
Starting httpd (/usr/local/apache2/bin/httpd) httpd: Syntax error on line 54 of /usr/local/apache201/conf/httpd.conf: Cannot load /usr/local/apache201/modules/mod_ssl.so into server: /usr/local/apache201/modules/mod_ssl.so: undefined symbol: ap_map_http_request_error |
I had been playing fast and loose and I borrowed the mod_ssl.so from some other system, I guess. I forget which. In other words, I dropped in by hand a mod_ssl.so into the directory /usr/lib64/apache2-prefork. I was using those system-supplied modules paired with my compiled apache. All fine until that patch. So I found another mod_ssl.so frm a different system and tried that one. It worked. Whew. These were both SLES 11 SP 4 systems. The older one (with the mod_ssl.so that still works) is dated April 18th, 2017. The one with the broken mod_ssl.so Dec 29thth 2017. That’s from a uname -a.
References and related articles
A proper guide to installing apache 2.4 on CentOS is https://jasonpowell42.wordpress.com/2013/04/05/install-apache-2-4-4-on-centos-6-4/
Some upgrade issues are covered by apache’s own guide: http://httpd.apache.org/docs/2.4/upgrading.html
Scaling up apache to handle more than a couple hundred simultaneous requests is described in this blog post.
The DigiCERT certificate inspector tool, which is what I was referring to in this post when it comes to scanning for BREACH vulnerabilities, is here.
