I'm using Ubuntu server right now (for local development) and noticed that some Ubuntu packages like apache have their config files... um... scattered.

While official Apache docs primarily refer to httpd.conf for everything, Ubuntu's Apache packages cleverly divides this one file into ..um...>20 files.

For example, instead of adding virtual hosts in httpd.conf you are expected to create files in a subdirectory, then alias it to another directory...m'ok. I guess many people like this...but I'm..um...think this overcomplicates things. if I want my config separated - I can do it myself.

What Linux server distro in your opinion has their packages customized the least by distro creators?


Stay with this layout! It brings the advantage of the conf.d folders. Files in that folders never get overwritten, unlike the httpd.conf! Apache assembles all the snippets into a httpd.conf then. You don't have to care about the order of the directives, because it's a XML-like configuration file.

It is really really not practical to have all directives in one file. Sometimes I even split this configs into smaller, partly customer editable, files.

Have a look in /etc/apache2/conf.d/. If you are looking for some directives and don't know which file to look in, us grep: grep -i -r "<IfModule mod_foo*" /etc/apache2/conf.d.

It is basically a good idea to never edit the httpd.conf itself. Even if you want to override existing declarations, copy them to a *.conf file to the conf.d directory and restart apache after the modifications in the copied file.


For servers that require high degree of customization feature-wise (and given enough time, they all do), I prefer to roll my own. I know it doesn't exactly answer your question, but it's an option you should consider. After few years of trying to 'go with the flow' and modify things on top of whatever the official packages gave me, it turned out that they're hacking it as much as I do, but differently, and more importantly, unintuitively to me. So I ended up building my own scripts to build, layout, and install my own apache with mods, php, mysql, etc. Later I went another step farther and made my own packages out of these scripts for easy distribution. It ended up much easier to maintain in the long run, because while it was a strange setup, it was MY strange setup and I could fix/update things a lot faster than poking around in dozens of conf.d/*.conf scattered all over the filesystem. It's kinda time consuming at first, but it works out great in the long run.


This sort of changes is the main reason we do not use any of the Debian or Ubuntu distributions. You end up using the Ubuntu flavor of Apache, and not Apache itself.

I do not know which other distribution stays closer to the upstream sources, I'm familiar with RedHat and CentOS and those 2 make changes as well, albeit less dramatic.

You could try uninstalling the distribution-supplied packages which are giving you troubles, then compile the software you want from sources into /opt and its subdirectories. You would then manage the configuration according to your preferences (I would recommend Puppet but it may be overkill if you have only one server).

  • +1 for compiling from source and putting into /opt :) – pepoluan Apr 20 '11 at 15:35

Typically distributions break down config files to match some kind of methodology or philosophy in the distribution. Instead of apache having one config layout and exim having another, they will both be relativly similar so that if you are familier with the distribution, you will know where to look for configs for any new package that comes along.

I suggest you pick a distribution with a methodology that you generally like, then learn it well and learn to play by it's rules. It will make your life easier in the end.

The apache documentation, or any documentation for that matter, is usually generic and discusses the simplest possible scenario, but in the real world things are rarely that simple. The division of configs into several files makes typical real world scenarios easier to manage in the long run.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.