VMware ESXi and vSphere Cluster Management

Apache mods-available Directory: Module Configuration and Enablement

Learn how Debian and Ubuntu organize Apache modules in mods-available and mods-enabled, and how to safely enable, disable, test, and troubleshoot modules.

On Debian-based systems such as Debian and Ubuntu, Apache HTTP Server modules are managed through a distribution-specific directory layout. The most important directories are /etc/apache2/mods-available and /etc/apache2/mods-enabled.

This arrangement separates modules that are installed and available from modules that Apache currently loads. It lets an administrator keep a module installed without enabling every feature in the running server.

This lesson assumes basic Linux paths and permissions, sudo, symbolic links, Apache configuration files, and systemctl.

What Is /etc/apache2/mods-available?

/etc/apache2/mods-available is the Debian-family Apache directory containing available module definitions and optional module-specific configuration files.

An Apache module is an extension that adds functionality to the server. Modules can provide URL rewriting, TLS support, proxying, authentication, request handlers, response headers, or other behavior.

The directory layout is not a universal Apache requirement. It is administration tooling supplied by Debian-family packaging around Apache's normal configuration system. Other operating systems and distributions may organize Apache modules differently.

Directory — Contents — Role — Typical file state

/etc/apache2/mods-available — Module .load files and optional .conf files — Stores installed module definitions that can be enabled — Regular packaged files

/etc/apache2/mods-enabled — Links to selected files in mods-available — Represents the module configuration Apache should use — Symbolic links for enabled modules

Files in mods-available

.load files

A .load file is a module loader configuration file. It normally contains Apache's LoadModule directive, which tells Apache to load a dynamic module binary.

LoadModule module_identifier module_binary_path

The exact module identifier and binary path depend on the module and the distribution package. For example, a loader file might identify a rewrite module and point to its installed shared object. Do not assume that identifiers or paths are interchangeable between modules.

.conf files

A .conf file is an optional module-specific configuration file. It contains Apache directives related to that module, such as defaults, compatibility settings, or supporting configuration.

A module does not necessarily need both file types. A module can have a .load file without a matching .conf file when loading the binary is all the packaged configuration required.

File basenames usually identify the module. For example, rewrite.load and rewrite.conf are associated with the rewrite module.

File suffix — Primary purpose — Typical contents — Whether every module needs it

.load — Loads the module binary — A LoadModule directive — Normally used for a dynamically loaded module

.conf — Configures module behavior — Module-specific Apache directives — Optional; some modules have no packaged file

How .load and .conf Work Together

Loading a module and configuring its behavior are separate concepts:

  • The .load file loads the module into Apache.
  • The optional .conf file supplies configuration for that module.
  • Other Apache configuration files can use directives supplied by the module after it has been loaded.

Apache must load a module before it can interpret directives provided by that module. If a configuration file contains a module-specific directive while the module is disabled, Apache may report an “Invalid command” or “directive not found” error during configuration testing or startup.

Enabling a module with Debian's helper normally activates its loader file and, when present, its matching configuration file. Administrator-created settings may be placed in a virtual-host file, a directory configuration, or another suitable Apache configuration location. The packaged module definition and defaults are conventionally represented in mods-available.

What Is /etc/apache2/mods-enabled?

/etc/apache2/mods-enabled is the active module configuration directory. Its entries are symbolic links pointing to selected .load and .conf files in mods-available.

A symbolic link is a filesystem reference that points to another file or directory. In this layout, the link indicates that a module is selected for use without copying or modifying the packaged source file.

Debian's main Apache configuration includes the enabled module directory. As a result, files linked there become part of Apache's effective configuration when Apache reads its configuration.

This split has two useful effects:

  • Installed modules can remain available without being loaded.
  • Enabling or disabling a module changes links rather than deleting packaged definitions.

If a module appears in mods-available but has no corresponding link in mods-enabled, it is generally installed and available but not active.

Enable a Module with a2enmod

a2enmod is the Debian-family helper utility for enabling Apache modules. It normally takes a module name, not a complete path to a source file.

sudo a2enmod rewrite

The helper creates the appropriate symbolic links under /etc/apache2/mods-enabled, pointing back to applicable files in /etc/apache2/mods-available.

Changing the links does not necessarily change the configuration of an already running Apache process immediately. Validate the configuration and then reload or restart Apache.

sudo apache2ctl configtest
sudo systemctl reload apache2

A reload applies the new configuration without a full stop where supported. If a reload is unsuitable or unavailable, a controlled restart may be required.

Disable a Module with a2dismod

a2dismod disables an Apache module by removing its enabled symbolic links. It ordinarily does not delete the source files in mods-available.

sudo a2dismod rewrite
sudo apache2ctl configtest
sudo systemctl reload apache2

Before disabling a module, check whether an enabled site, global configuration file, or another module configuration depends on it. If active configuration still contains directives supplied by the disabled module, the configuration test or reload can fail.

If the application still requires the module, restore it with:

sudo a2enmod rewrite

Inspection and Verification Workflow

1. List available module definitions

ls -l /etc/apache2/mods-available/
ls -l /etc/apache2/mods-available/rewrite.*

The first command lists all available module files. The second focuses on files whose basename begins with rewrite, such as rewrite.load and, if supplied by the package, rewrite.conf.

2. List active module links

ls -l /etc/apache2/mods-enabled/

Look for symbolic-link indicators in the listing. An enabled entry should point into mods-available.

readlink -f /etc/apache2/mods-enabled/rewrite.load

This resolves the link and displays the available-file path to which it ultimately points.

3. Inspect the loader and optional configuration

cat /etc/apache2/mods-available/rewrite.load
cat /etc/apache2/mods-available/rewrite.conf

The second command is useful only when the optional file exists. Inspecting these files helps you understand what enabling the module will load and configure. Packaged files should generally be treated as distribution-managed files rather than places for routine custom edits.

4. Test before applying changes

sudo apache2ctl configtest

A successful result indicates that Apache accepted the current configuration syntax. It does not prove that every application-level feature is configured correctly, but it should be part of every module change workflow.

5. Confirm the module is loaded

sudo apache2ctl -M

This lists modules loaded by Apache. Compare the output with the module you enabled. A link in mods-enabled is evidence of selected configuration; apache2ctl -M verifies that Apache actually loaded the module in its running configuration context.

6. Check service status and errors

sudo systemctl status apache2

When a test or reload fails, read the reported error and inspect Apache's error output. The service status commonly points to the relevant failure, such as an invalid directive, a missing module, or an incompatible configuration.

Practical Example: Enable URL Rewriting

URL rewriting support is commonly provided by the rewrite module. Enabling the module is only the first part of using rewrite rules.

  1. Inspect the available files:
ls -l /etc/apache2/mods-available/rewrite.*
  1. Enable the module by name:
sudo a2enmod rewrite
  1. Validate the complete Apache configuration:
sudo apache2ctl configtest
  1. Reload Apache if the test succeeds:
sudo systemctl reload apache2
  1. Confirm the loaded module:
sudo apache2ctl -M

After this process, Apache has rewrite support loaded. The application still needs appropriate rewrite directives in its virtual-host, directory, or other active configuration.

Practical Example: Compare Available and Active State

ls -l /etc/apache2/mods-available/rewrite.*
ls -l /etc/apache2/mods-enabled/ | grep rewrite
readlink -f /etc/apache2/mods-enabled/rewrite.load

The first command shows what is installed and available. The second checks whether rewrite-related links are active. The third demonstrates that the enabled loader entry points back to the corresponding available file.

If the module has files in mods-available but no matching entry in mods-enabled, the module is not selected for Apache's active configuration. This does not necessarily mean the module is broken or absent; it may simply be disabled.

Practical Example: Disable an Unneeded Module

  1. Identify the enabled module and inspect its links:
ls -l /etc/apache2/mods-enabled/
  1. Search active Apache configuration for directives associated with the module:
grep -R "DIRECTIVE_NAME" /etc/apache2

Replace DIRECTIVE_NAME with a directive supplied by the module. Check site configuration, global configuration, and module-specific configuration.

  1. Disable the module:
sudo a2dismod module_name
  1. Test before reloading:
sudo apache2ctl configtest
  1. Reload only when validation succeeds:
sudo systemctl reload apache2

If the test reports an unrecognized directive, either re-enable the dependency or remove or replace the configuration that requires it.

Common Module Administration Commands

Task — Command — Result — Follow-up action

Enable a module — sudo a2enmod module_name — Creates enabled links — Run apache2ctl configtest, then reload

Disable a module — sudo a2dismod module_name — Removes enabled links — Check dependencies, test, then reload

Test configuration — sudo apache2ctl configtest — Checks Apache configuration syntax — Fix reported errors before applying changes

Reload Apache — sudo systemctl reload apache2 — Applies accepted configuration changes — Check service status and logs if it fails

List loaded modules — sudo apache2ctl -M — Displays modules Apache loaded — Confirm the expected module is present

Troubleshooting

Apache fails after a module is disabled

The most likely cause is that active configuration still contains a directive supplied by the disabled module.

  • Read the configuration-test error.
  • Identify the unrecognized directive or missing module.
  • Search /etc/apache2 for that directive.
  • Re-enable the dependency or remove or replace the dependent configuration as appropriate.
sudo apache2ctl configtest
grep -R "DIRECTIVE_NAME" /etc/apache2

A module appears in mods-available but does not function

  • Check for its corresponding link in mods-enabled.
  • Run sudo apache2ctl -M to verify that Apache loaded it.
  • Run the configuration test.
  • Check service status and Apache error output.
  • Confirm that the feature itself has the required virtual-host or directory configuration.

a2enmod says the requested module does not exist

Possible causes include a missing module package, a module name that does not match an available-file basename, or a system that does not use the Debian/Ubuntu Apache layout.

ls -l /etc/apache2/mods-available/

Check the available basenames, verify that the relevant Apache module package is installed, and confirm the operating system's Apache packaging conventions.

Apache reload fails after enabling a module

The module's optional configuration may contain an invalid or incompatible directive, or it may conflict with another enabled module.

  • Run sudo apache2ctl configtest before retrying the reload.
  • Review the module's linked .conf file.
  • Read the Apache error output and service status.
  • If necessary, disable the newly enabled module to restore the previous state, then investigate the conflict.

Manual edits in mods-enabled behave inconsistently

The enabled directory is intended to be managed through symbolic links and helper commands. A link may point to a missing source file, or manual changes may not match the package's expected state.

ls -l /etc/apache2/mods-enabled/
readlink -f /etc/apache2/mods-enabled/module_name.load

Use a2enmod or a2dismod to restore normal state management. Do not delete source files from mods-available as a way to disable modules.

Operational and Security Considerations

  • Use administrative privileges for module state changes.
  • Distinguish package installation from module enablement. A module can be installed and available while remaining inactive.
  • Prefer the helper commands instead of manually managing symbolic links during normal administration.
  • Do not edit or delete packaged loader files unless there is a clear administrative requirement and you understand the package-management consequences.
  • Enable only modules required by the deployment. Fewer active modules reduce configuration complexity and can reduce the server's attack surface.
  • Always run a configuration test before reloading or restarting Apache after module changes.
  • Keep a way to restore the prior state, especially when changing a production server.

Exam-Relevant Summary

  • /etc/apache2/mods-available contains available module loader files and optional module configuration files.
  • A .load file normally contains a LoadModule directive.
  • A .conf file supplies optional module-specific settings; not every module has one.
  • /etc/apache2/mods-enabled contains symbolic links to selected files in mods-available.
  • a2enmod module_name enables a module by creating the appropriate links.
  • a2dismod module_name disables a module by removing those links, not by normally deleting available files.
  • A module must be loaded before Apache can interpret directives that it provides.
  • Use sudo apache2ctl configtest before sudo systemctl reload apache2.
  • Use sudo apache2ctl -M to confirm that Apache has loaded a module.

For a broader view of this Debian-style configuration layout, see the Apache mods-available directory guide.