On a Debian or Ubuntu Apache httpd install, what do the a2enmod and a2ensite commands actually do, and why can editing a file under sites-available leave the running server unchanged?

## Apache's config is assembled, not written Apache reads one root file — `apache2.conf` on Debian/Ubuntu, `httpd.conf` on Red Hat-family systems — and that file pulls in fragments with `Include` and `IncludeOptional`. Everything else is a fragment. Understanding which directories get pulled in is most of understanding an unfamiliar Apache installation. ## The Debian layout ``` /etc/apache2/ apache2.conf # root file, does the includes ports.conf # Listen directives mods-available/ # every packaged module: name.load + optional name.conf mods-enabled/ # symlinks to the ones actually loaded sites-available/ # every vhost file sites-enabled/ # symlinks to the ones actually served conf-available/ # other config snippets conf-enabled/ # symlinks to the active ones ``` `apache2.conf` contains lines equivalent to: ```apacheconf IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf IncludeOptional conf-enabled/*.conf IncludeOptional sites-enabled/*.conf ``` The `available` directories appear nowhere. They exist so packages can ship configuration without activating it. ## What the helper scripts do `a2enmod proxy_http` creates symlinks in `mods-enabled` pointing at `mods-available/proxy_http.load` (and `.conf` if present). The `.load` file is a one-liner: ```apacheconf LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so ``` `a2ensite`, `a2enconf` and their `dis` counterparts do the same for the other pairs. They are shell scripts — you can achieve the identical result with `ln -s`, and configuration management tools often do. They also print the reminder to reload, which is the step people skip. A useful behaviour: enabling a module that depends on another (`proxy_http` needs `proxy`) pulls the dependency in too, and disabling one that others depend on will warn. ## The three ways "my change did nothing" happens 1. **The file was never enabled.** Edited in `sites-available`, no symlink, no effect. `ls -l /etc/apache2/sites-enabled/` settles it instantly. 2. **Apache has not re-read the config.** The running process holds the configuration it parsed at startup. `systemctl reload apache2` (a graceful reload) applies the change; existing connections finish on the old configuration. 3. **The module providing the directive is not loaded.** Here you usually do get an error — an unknown directive is a fatal config error, and Apache refuses to start or reload. This is why `a2enmod` and the directive change must ship together. ## Ordering is part of the config Because the includes use a glob, files load in lexical order. That is why Debian ships `000-default.conf` — the leading digits pin it as the first vhost, which is the one Apache uses as the fallback for unmatched hostnames. Rename your files carelessly and you can change which site answers for unknown domains without touching a single directive. ## The Red Hat family is different On RHEL, CentOS Stream, Rocky and Fedora, the package is `httpd` and there is no enable/disable indirection: ``` /etc/httpd/ conf/httpd.conf # root file conf.modules.d/*.conf # LoadModule lines, included unconditionally conf.d/*.conf # site and app config, included unconditionally ``` To disable a module you comment out or remove its `LoadModule` line. Scripts and runbooks that call `a2enmod` are Debian-specific and will fail here — a common surprise when a container image switches base distributions. ## Verify, then reload, in that order - `apachectl configtest` (equivalently `apache2ctl -t`, `httpd -t`) parses the whole assembled config and reports the file and line of any error. - `apache2ctl -M` lists the modules actually loaded — the ground truth, better than reading symlinks. - `apachectl -S` shows the resulting virtual host map. - `systemctl reload apache2` applies changes gracefully. `apachectl` runs a configuration check before signalling on restart and graceful, so a syntax error fails the reload rather than taking the site down — but that safety net only exists if you go through the tooling instead of sending signals by hand.