Debian shows how to do Apache configuration right (and Fedora fumbles it)
For reasons involving upgrading my office workstation to Fedora 18, I've had to deal with the stock Fedora Apache configuration setup for the first time in a long time. And oh boy, is it bad. It's a beautiful example of how not to do configuration files in a modern package manager world and is all the more shocking because I'm used to the Ubuntu Apache setup (which is the Debian Apache setup), which basically gets everything right.
Here is how Debian splits Apache configuration up:
- Apache modules put their configuration files in
/etc/apache2/mods-available
, but this doesn't enable them; there's a separate directory for that,/etc/apache2/mods-enabled
. To enable a module you put appropriate symlinks inmods-enabled
or, more likely, usea2enmod
anda2dismod
to do it for you. - the configuration files for your websites are in
/etc/apache2/sites-available
;default
is the default stock one (anddefault-ssl
if applicable). However, once again, this doesn't enable them; that's/etc/apache2/sites-enabled
, which has appropriate symlinks (managed by hand or witha2ensite
anda2dissite
as you prefer). - configuration file snippets that don't otherwise fit go in
/etc/apache2/conf.d
. In a default configuration there is almost nothing in this directory that is active and most of it you don't want to touch. - configuring the ports that Apache listens on has been split off into
/etc/apache2/ports.conf
(and this automatically handles SSL).
The remaining Apache configuration file is very short and consists mostly of comments; the Ubuntu 12.04 version has exactly 54 lines of configuration directives, most of them to set MPM parameters.
This is not perfectly modular, but in practice we can run a number of
web servers, ranging from relatively simple to fairly complex, without
needing to change any of the stock, package-provided files. The two
most common changes (what your website setup actually is and controlling
what Apache modules the server has enabled) both explicitly separate
something simply being installed from it being enabled. Changing
listening ports has been deliberately split off into its own file that
has nothing else, so if you have to change it you still have a pristine
main configuration file (that will keep being updated with package
updates). You can remove or completely replace the default site just
by removing and changing symlinks, while keeping the actual default
around untouched for package updates (and to mine for ideas and so on).
Fedora, well, Fedora is not like this. It has no distinction between
installed Apache modules and active Apache modules; if you have a module
installed it drops a file in /etc/httpd/conf.modules.d
and you can
guess what happens next. It has no equivalent of even sites-enabled
;
your site is hardcoded in the main Apache configuration file along with
a pile of other things (I'd call it 'your main site' except that Fedora
doesn't even imagine that you might use virtual hosts). There is a
directory for 'random configuration snippets', /etc/httpd/conf.d
, but
it's a complete mixed bag of actual general configuration directives
and various packages adding Aliases and ScriptAliases to your site.
It doesn't have any separation between installed and enabled either,
and random Fedora packages feel free to drop bits in here (and in the
process steal URLs out from underneath you).
All of this is catastrophically bad in the face of modern package management. In order to do anything with a Fedora Apache configuration you must change and delete files that are owned by various packages, leaving you to find and merge any future changes by hand (and you'd better also re-remove any files you removed when they're put back by package updates). This goes directly against years of experience of how to make things work well with package managers, and as Debian shows it's not as if Apache lacks the tools to create a genuinely modular and package manager friendly configuration. Nor is it as if Fedora is without experience at designing systems that work very well with modern package management.
(In practice the only thing you can really do with the Fedora Apache configuration is to burn it to the ground and start from scratch. Before I discovered the Debian way I had an approach for this, which I guess I get to repeat.)
There is a larger scale lesson for package management here that I encapsulated in a tweet, but explaining it properly is going to take another entry (this one is already long enough).
|
|