This folder structure is all about manageability. While it would be perfectly fine to add all module and virtual host configuration into a single httpd.conf
, it would make it long and tricky to modify. Therefore, for example in Debian, wildcard includes have been used to separate the configuration into multiple files:
# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf
# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf
This makes everything matching path sites-enabled/*.conf
to be added to the configuration, and for the Apache HTTPd it doesn't matter whether it's a text file or a symlink to one. From this perspective, it doesn't even matter whether the file has <VirtualHost>
blocks in it or is just some other Apache configuration. It's also perfectly possible to have file example.com.conf
with configuration for example.net
etc.
The problems you will face with unconventional configuration are related to the lack of manageability:
You won't be able to enable or disable virtual hosts with a2ensite
/ a2dissite
.
# a2dissite example.com
ERROR: Site example.com does not exist!
The official documentation (man pages) becomes useless.
You can't easily temporarily disable the site. E.g. a catch-all virtual host makes it easy to create an under maintenance page to show while the site is disabled for updates.
Someone else administering the same server may have used to use ln -s
and rm
instead of these official commands. While trying to temporarily disable the site, they might accidentally delete it.
No-one else knows you haven't been following the normal practices. In a few months you will forget it, too. At that point you will ask a new question on Serverfault regarding why following the documentation or a tutorial doesn't apply for your setup anymore.