How to Install and Configure Third-Party Apache Modules

Abdul Wahab Junaid

3 years ago

How to install and configure third-party Apache modules

One of the things I genuinely love about Apache is how extensible it is. Beyond the modules that ship with it out of the box, there’s a huge ecosystem of third-party modules that add capabilities Apache doesn’t have natively — things like advanced security filtering, custom authentication schemes, or specialized caching behavior. Over the years I’ve installed more than a few of these on production servers, and I’ve learned there’s a right way and a wrong way to do it.

What Are Third-Party Apache Modules

Apache’s core functionality (serving files, handling virtual hosts, basic logging) is deliberately minimal. Almost everything else — SSL support, URL rewriting, PHP integration, compression, security filtering — is implemented as a module. Some of these modules ship with Apache itself (like mod_rewrite or mod_ssl); others are developed independently and need to be installed separately.

Common third-party modules I’ve worked with include:

mod_security – a web application firewall
mod_evasive – DoS/brute-force mitigation
mod_pagespeed – Google’s page-optimization module (now largely deprecated, worth mentioning historically)
mod_geoip / mod_maxminddb – geolocation-based routing and blocking
mod_fcgid – FastCGI process management
libapache2-mod-passenger – for Ruby/Node app deployment

Prerequisites

A working Apache installation with root/sudo access
apache2-dev (Debian/Ubuntu) or httpd-devel (CentOS/RHEL) installed if you’ll be compiling from source
Familiarity with your distro’s package manager
A staging or test environment — I never install a new module directly on production first

Install the development headers up front since you’ll likely need them:

# Debian/Ubuntu
sudo apt update
sudo apt install apache2-dev build-essential

# CentOS/RHEL
sudo dnf install httpd-devel gcc make

Step 1: Check If a Package Already Exists

Before building anything from source, I always check whether the module is available through the package manager — it’s faster, easier to update, and generally safer.

# Debian/Ubuntu
apt search mod_security
sudo apt install libapache2-mod-security2

# CentOS/RHEL
dnf search mod_security
sudo dnf install mod_security

If it’s there, this is almost always the better route.

Step 2: Installing via apxs (Compiling from Source)

When a module isn’t packaged, or you need a specific version, you compile it using apxs (APache eXtenSion tool), which comes with the dev package.

Here’s the general workflow I follow, using a hypothetical module as an example:

# Download and extract source
wget https://example.com/mod_example-1.2.3.tar.gz
tar -xvzf mod_example-1.2.3.tar.gz
cd mod_example-1.2.3

# Build and install
sudo apxs -i -a -c mod_example.c

Breaking down those flags:

-c compiles the module
-i installs it into Apache’s module directory
-a activates it by adding a LoadModule line to the config

After this, verify it’s registered:

apachectl -M | grep example

Step 3: Manually Loading a Module

If apxs -a didn’t add the load directive (or you compiled manually), add it yourself. On Debian/Ubuntu, modules typically go in /etc/apache2/mods-available/:

# /etc/apache2/mods-available/example.load
LoadModule example_module /usr/lib/apache2/modules/mod_example.so

Then enable it:

sudo a2enmod example
sudo systemctl restart apache2

On CentOS/RHEL, you’d typically add the LoadModule line directly into /etc/httpd/conf.modules.d/ as a new .conf file:

# /etc/httpd/conf.modules.d/10-example.conf
LoadModule example_module modules/mod_example.so

Then restart:

sudo systemctl restart httpd

Step 4: Configuring the Module

Every module has its own directives, defined in its documentation. Configuration usually lives in its own file for cleanliness. For example, on Debian/Ubuntu:

# /etc/apache2/mods-available/example.conf
<IfModule mod_example.c>
    ExampleDirective On
    ExampleTimeout 30
</IfModule>

I always wrap module-specific config in <IfModule> blocks. This means if the module ever gets disabled or fails to load, Apache won’t throw a fatal error about unknown directives — it’ll just skip that block gracefully.

Step 5: Test Before Reloading

This step is non-negotiable for me, every single time:

sudo apachectl configtest

If that comes back clean:

sudo systemctl reload apache2   # Debian/Ubuntu
sudo systemctl reload httpd     # CentOS/RHEL

Verifying the Module Is Active

apachectl -M

This lists every loaded module. I grep for the one I just installed to confirm it took effect:

apachectl -M | grep -i example

You can also check the server-status page (if mod_status is enabled) or simply watch the error log during startup for any complaints about the new module.

Updating and Removing Third-Party Modules

Modules installed via the package manager update the same way as everything else on your system:

sudo apt update && sudo apt upgrade libapache2-mod-security2   # Debian/Ubuntu
sudo dnf update mod_security                                    # CentOS/RHEL

For modules compiled from source, you’ll need to repeat the download-compile-install process with the new version, then restart Apache. I always keep a note (a simple text file or a comment in my config) of exactly which version I compiled and from what source, since apxs-installed modules don’t show up in your package manager’s update listings — it’s easy to forget they even exist until something breaks.

To remove a module cleanly:

sudo a2dismod example
sudo systemctl restart apache2

Then delete the .so file and any leftover config if you no longer need it. Leaving disabled-but-installed modules around isn’t a huge risk, but I still prefer to keep servers lean and remove what isn’t in active use.

Real-World Use Cases

mod_security: I install this on any public-facing site handling forms or user input — it blocks a huge percentage of automated attack traffic before it even reaches the application.
mod_evasive: Useful on servers that get hit with basic brute-force login attempts.
mod_fcgid: Needed when running certain legacy PHP or CGI-based apps that require FastCGI process management outside of PHP-FPM.
mod_geoip/mod_maxminddb: I’ve used this to block traffic from specific regions or route users to region-specific content.

Troubleshooting Tips

“Cannot load module” errors almost always mean an architecture mismatch (32-bit vs 64-bit) or the wrong Apache version (MPM prefork vs worker vs event) — recompile against the matching apxs.
Undefined symbol errors typically mean the module was built against a different Apache/APR version than what’s installed — reinstall apache2-dev/httpd-devel and rebuild.
If Apache won’t start after adding a module, check journalctl -xeu apache2 (or httpd) for the exact failure reason.
If a module loads but doesn’t seem to do anything, double check it’s not being overridden by a later <IfModule> block or virtual host-level directive.

Common Mistakes to Avoid

Installing directly on production without testing first. A bad module can take your whole site down.
Downloading modules from untrusted or unofficial sources. Only use vetted repositories, official module pages, or your distro’s package manager.
Forgetting to wrap config in <IfModule> blocks. This causes hard failures if the module isn’t loaded.
Not pinning module versions, leading to unexpected behavior changes after an unattended upgrade.
Skipping configtest before reloading.

Security Best Practices

Only install modules from official repositories or the module author’s verified source — malicious or poorly maintained modules are a real attack vector.
Keep modules updated; security-focused modules like mod_security rely on frequently updated rule sets.
Remove or disable modules you’re not actively using — every loaded module is additional attack surface.
Review a module’s changelog before upgrading in case of breaking security-relevant changes.

Performance Optimization

Only load the modules you actually need — each loaded module adds a small amount of memory overhead per Apache worker process.
For modules with significant CPU cost (like mod_security with a large rule set), benchmark before and after under realistic load.
Where possible, use the module’s own performance tuning directives (e.g., caching options) rather than relying on defaults.

Frequently Asked Questions

Q: How do I know if a module is already installed? A: Run apachectl -M to list all currently loaded modules.

Q: What’s the difference between installing via package manager and compiling from source? A: Package manager installs are easier to maintain and update automatically; compiling from source gives you more control over versions but requires manual updates.

Q: What is apxs? A: It’s Apache’s extension tool for building and installing modules against your specific Apache installation.

Q: Why did Apache fail to start after I added a module? A: Usually a version mismatch, a syntax error in the module’s config block, or a missing dependency. Check the error log for the specific reason.

Q: Should I test new modules before production? A: Always. I install and test in a staging environment first, every time, no exceptions.

Summary and Key Takeaways

Installing third-party Apache modules opens up a lot of functionality that isn’t there out of the box, but it also comes with real risk if done carelessly. To recap:

Prefer package-manager installs over compiling from source when possible.
Use apxs for building modules from source when needed.
Always wrap module configuration in <IfModule> blocks.
Test configuration with apachectl configtest before every reload.
Only load modules you actually use, and keep them updated.

Done carefully, third-party modules can massively extend what your Apache server is capable of — done carelessly, they’re one of the fastest ways to take a site down.