Can you determine which Apache modules have been used and can be removed?

Question

I, like many people, have a relatively out-of-the-box Apache installation with a lot of default "LoadModule" lines.

Since the beginning, I've installed a lot of software, and to be honest, I don't know what software is is using which modules.

I would like to reduce the memory footprint of my Apache instances, and to do that, I'd like to remove modules from being used. The only way that I know of to determine if a module is in use is to remove it from the configuration and see if anything breaks. This is bad in more ways than I have time to describe.

I would like to know if anyone is aware of a way to get Apache to report which modules have been used, or if there's another way to programmatically determine whether a module is safe to un-configure.

Solution 1

The way I did is building a test server, read the documentation, and start from a blank page.

The following modules are compulsory:

• core
• mod_authz_host
• mod_auth_basic
• mod_authn_file
• mod_dir
• mod_log_config
• mod_mime

Then I commented out all the remaining modules and restart Apache. It will sound out if something breaks, for e.g:

Starting httpd: Syntax error on line 10 of /etc/httpd/conf.d/squid.conf:
Invalid command 'order', perhaps misspelled or defined by a module not included in the server configuration

Do the same with the other modules. By using this method, here are some modules often not needed:

• mod_authn_alias
• mod_authn_anon
• mod_authn_dbm
• mod_authn_default

---

• mod_authz_user
• mod_authz_owner
• mod_authz_groupfile
• mod_authz_dbm
• mod_authz_default

---

• mod_include
• mod_logio
• mod_ext_filter
• mod_usertrack
• mod_dav
• mod_info
• mod_dav_fs
• mod_speling
• mod_suexec
• mod_cgi

If you are not using LDAP for authentication, this can be disabled:

• mod_ldap
• mod_authnz_ldap

The below modules should be considered when enabling:

• mod_proxy
• mod_proxy_balancer
• mod_proxy_ftp
• mod_proxy_http
• mod_proxy_connect

---

• mod_cache
• mod_disk_cache
• mod_file_cache
• mod_mem_cache

Solution 2

An earlier post suggest disabling the modules until something breaks. While that is definitely foolhardy in on a production system, the person is the on right path, as you will need to do regression testing anyway.

So in this case:

1. Build a test server identical to the one you have running, right down to the sites configuration
2. Disable a module.
3. Perform regression testing on the sites.
4. Repeat step 2 and 3 until something breaks or you are done with all the modules.
5. Re-enable the module.
6. Repeat steps 2 and 3.
7. With the newly updated apache, perform a configuration flash-cut on the configuration and restart the apache service.
8. If it fails, revert the configuration bath, pull the logs, analyze and start from step 2 (or step 1 if necessary).

That is probably the easiest way to streamline the Apache configuration. Otherwise, you will have to look each module, determine its functionality and search through the sites to see which one uses that functionality. That would take much longer.

Alternatively, this may give you a good opportunity to switch to something more lightweight:

Comments

[John Gardeniers]

How does that answer the question that was asked?

[Greg Petersen]

What do you mean?

[mahnsc]

Although I love your answer, the OP is looking for some tool, command line argument, or handler that will tell you which modules are safe to remove, presumably when run against or while inspecting a live server's configuration files.