Home / server / Questions / 325781
In Process
Matt Simmons
Asked: 2011-10-29 09:16:33 +0800 CST

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

  • 772

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.

apache-2.2 low-memory httpd

5 Answers

  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
    • 7

  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:

    • 5

  3. I dont have a direct answer to your question, but there are many 'tiny' AMP packages on the internet which as far as I know, doesn't include most of the pre-installed modules. So, I would start with looking at them as an example reference.

    These 2 links might get you started:

    1. http://en.wikipedia.org/wiki/List_of_Apache%E2%80%93MySQL%E2%80%93PHP_packages
    2. http://en.wikipedia.org/wiki/Comparison_of_WAMPs
    • 0

  4. I know you are asking about Apache, but given the memory constraints on your system, you might be much better served by swapping Apache for Nginx, Lighthttpd, or other low-footprint web servers. Apache is great for module support but very memory-hungry compared to younger web servers like Nginx, Lighthttpd, Cherokee, G-WAN, etc.

    • 0

  5. Testing for something to break has its caveats - often some directives are used only if a module is loaded (<IfModule>), which means deactivating the module may not directly break something but will cause things to not work as expected.

    For some modules you could check if their directives are being used in the configuration. Though this is tedious but may be a little more foolproof than just testing for something to break. Also, you can do your checks before making changes.

    Example:

    • mod_version, supplies the <IfVersion> directive, search for that in your configuration directories and .htaccess files (if used)

    Example script:

    #!/bin/bash

for i in "<IfVersion>" SuexecUserGroup Substitute;do
        echo "Check for $i"
        # look in configuration directories (this depends on your distribution)
        grep -r -E "$i" /etc/apache2/conf-enabled/ /etc/apache2/mods-enabled/ /etc/apache2/sites-available
        # look for .htaccess in webroot, this path depends on your setup
        # not necessary if you do not use .htaccess
        find /var/www/html -name .htaccess -exec grep "$i" {} \;
done

    Note: this script can be optimized.

    • 0