Can you determine which Apache modules have been used and can be removed?
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.
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
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:
- Build a test server identical to the one you have running, right down to the sites configuration
- Disable a module.
- Perform regression testing on the sites.
- Repeat step 2 and 3 until something breaks or you are done with all the modules.
- Re-enable the module.
- Repeat steps 2 and 3.
- With the newly updated apache, perform a configuration flash-cut on the configuration and restart the apache service.
- 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: