Repairing an Apache 2.2 Modules Installation.

note: This article is intended for a technical audience -- you should use caution when modifying a production system -- caveat emptor.

Sometimes, Ubuntu (and before it, Debian) drives me up the wall.

Recently, an apache2.2-common upgrade saw fit to blow away my /etc/apache2/mods-enabled directory, but not recreate the defaults, so I was left with an empty directory and a server that wouldn't restart due to various errors that looked similar to:

"Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration"?"

Looking around on the web, this doesn't appear to be a new issue, but it doesn't appear to be terribly well answered either -- all I knew, was that I had a box that needed SSL, PHP, Expiry Headers and well, that's it -- aside from the basic functionality.

My first test was to purge the package and re-install it, which did give me back the functionality I wanted, together with a bunch of other modules I didn't need -- I proceeded to leave it and go to bed, only to be greeted with a message from the hosting provider telling me i'd overblown my shared-hosting's RAM quota for the day and that my account was temporarily suspended.

So, I removed the directory and started working piece by piece to put things back together until both Wordpress and OSCommerce booted up and ran correctly.

note: You can also do this with Apache's handy a2enmod program, but i'm a purist -- so i'm going to do it here via 'ln -s'.

First, to obtain basic functionality, you'll need to log in as root (or sudo to root) and issue the following commands, depending on which error your Apache 2.2 installation gives you.

If you see: "Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration?", run:

ln -s /etc/apache2/mods-available/authz_default.load /etc/apache2/mods-enabled/authz_default.load
ln -s /etc/apache2/mods-available/authz_host.load /etc/apache2/mods-enabled/authz_host.load

If you see: "Invalid command 'DirectoryIndex', perhaps misspelled or defined by a module not included in the server configuration?", run:

ln -s /etc/apache2/mods-available/dir.load /etc/apache2/mods-enabled/dir.load

If you see: "Invalid command 'Alias', perhaps misspelled or defined by a module not included in the server configuration?", run:

ln -s /etc/apache2/mods-available/alias.conf /etc/apache2/mods-enabled/alias.conf
ln -s /etc/apache2/mods-available/alias.load /etc/apache2/mods-enabled/alias.load

If you see: "Invalid command 'AddType', perhaps misspelled or defined by a module not included in the server configuration?", run:

ln -s /etc/apache2/mods-available/mime.conf /etc/apache2/mods-enabled/mime.conf
ln -s /etc/apache2/mods-available/mime.load /etc/apache2/mods-enabled/mime.load

If you don't see any of those, but Wordpress 2.6.x (or 2.7.x) will not let you login (ie. you can install it, and you see the admin screen, but you get 'permission denied', 'forbidden' or a directory index -- rather than your admin dashboard) then try running:

ln -s /etc/apache2/mods-available/asis.load /etc/apache2/mods-enabled/asis.load

and restart Apache.

update [12-12-2008]: Wordpress 2.7 will fail to install unless you have the 'env' module installed, so you may also need to run:

ln -s /etc/apache2/mods-available/env.load /etc/apache2/mods-enabled/env.load

Once you've restarted, your Apache installation should basically work -- to add advanced functionality, you should visit the Apache 2.2 Modules Documentation pages and adapt the lines above to suit the function you need.

Using mod_security 2.5.x with Apache 2.x

note: This article is intended for a technical audience -- you should use extreme caution when modifying a production system, as your data will be nearly impossible to recover if you use this command incorrectly -- caveat emptor.

There's a lot of posts about how to setup the mod_security module for Apache, but few on how to configure it -- hopefully people find this post useful in doing just that.

Before we start, i'm assuming you've actually installed mod_security 2.1.3 or 2.5.x here already (Red Hat/CentOS packages are here, Ubuntu / Debian ones are here, an OpenSuSE howto is here).

I'm also assuming you've made a copy of the core rules that come supplied with the package and put them in the /etc/modsecurity directory.

note: If your distribution of choice doesn't ship the core rules with the packages, you can download those from here.

Now, to make a decent configuration.

First, move (don't copy, or the default configuration may override any environment-specific changes you make) the /etc/modsecurity/modsecurity_crs_10_config.conf file to /etc/apache2/conf.d/mod_security.

Open the newly copied /etc/apache/conf.d/mod_securityfile and edit the following parameters:

• SecResponseBodyLimit
-- Because the default configuration doesn't check binary files, you may wish to reduce this to 256K, so change this value to 262144.

• SecAuditLog
-- The default configuration saves the logfiles relative to the configuration file directory, under most modern Linux/BSD distributions, the apache or www-user account already has rights to the /var/log/apache2 directory, so you can safely change this to /var/log/apache2/modsec_audit.log

• SecDebugLog
-- Using the same rationale, you can change this to /var/log/apache2/modsec_debug.log

At this point, you should save your file and restart your Apache 2.x server in order to ensure your configuration works. If you run:

cat /var/log/apache2/error.log | grep “ModSecurity”

You should see the string:

“[Fri Jun 13 23:23:23 2008] [notice] ModSecurity for Apache/2.5.5 (http://www.modsecurity.org/) configured.”

Which means we can proceed to add our rules to the configuration. To do this, open your configuration file again and add the following line to the bottom:

Include /etc/modsecurity/rules/*_crs_*.conf

This will add the core rules to your configuration. Once again, you can restart your server and the changes will take effect.

Apache2, SSL and Ubuntu 6.06

Recently, I had to configure a dedicated SSL certificate with Apache2 on a Virtual Host -- and proceeded to use a combination of information from Verisign & the Ubuntu Documentation Project.

After tweaking the install, I ran foul of the infamous "error -12263" in my browser.

My configuration consisted of:

* cp'ing the original vhost configuration to 'secure' in /etc/apache2/sites-available/ and symlinking them to /etc/apache2/sites-enabled/

* adding "Listen 443" followed by a newline to /etc/apache2/ports.conf

* Changing /etc/apache2/sites-available/secure to read:

--- <virtualhost>*:80</virtualhost>
+++ <virtualhost>*:443</virtualhost>

* and beneath the 'ServerAdmin' line -- Adding:

+++ SSLCertificateFile /etc/ssl/certs/server.crt
+++ SSLCertificateKeyFile /etc/ssl/private/server.key
+++ SSLCACertificateFile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem

At this point, Apache starts normally & listens on both the HTTP and HTTPS ports, as referenced by the change in /var/log/apache2/error_log

from:

[notice] Apache/2.0.55 (Ubuntu) PHP/5.1.2 configured -- resuming normal operations

to:

[notice] Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a configured -- resuming normal operations

However, when you try and https:// address, browsers error out.

Worse still, Apache doesn't actually log anything about this request by default -- but we know the site works because using a standard http:// request works fine.

Actually, that's not quite true -- it does log a cryptic error message that looks similar to:

127.0.0.1 - - [04/Aug/2007:23:38:58 +1000] "\x80\x8c\x01\x03\x01" 200 16564 "-" "-"

Some googling later, this seems to indicate that port 443 is serving non-SSL requests to clients.

Luckily, you can use OpenSSL to confirm this behaviour:

Running:

openssl s_client -connect localhost:443

Returns:

CONNECTED(00000003)
7431:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:567:

Instead of your key.

The trick, of course -- turns out to be remarkably simple, open /etc/apache2/sites-available/secure -- and add:

+++ SSLEngine on

So your configuration becomes:

---
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem
---

Save the file and restart Apache, then run the OpenSSL command line again:

openssl s_client -connect localhost:443

It should now return your key information properly -- now fire up your browser and use https:// to your hearts content.