Home / server / Questions / 117459
Accepted
Chris Adams
Asked: 2010-02-28 05:56:14 +0800 CST

Why does rhel/centos store apache conf files the way it does?

  • 772

I've started administering a clutch of CentOS based webservers in a new job, and after a couple of years of using debian based linux servers, I've got fairly comfortable with the apache file structure along the lines of below:

    /etc/apache2
        apache2.conf
        conf.d/
        envvars
        mods-available
        mods-enabled
        ports.conf
        sites-available
        sites-enabled

This makes sense to me modules that are available to me but not necessarily in use are in mod-available, and ones in user are in mods-enabled, likewise with the sites directly. Granted, these are mainly symlinks, but I can understand why it's done like this; coming to the system fresh I have a rough idea of what's up on the system, by looking in the relevant *enabled directories.

By comparison CentOS's setup is like so:

    /etc/httpd
        conf
        conf.d
        logs -> ../../var/log/httpd
        modules -> ../../usr/lib64/httpd/modules
        run -> ../../var/run

I can understand that I can see which hosts are enabled by calling apachectl -S, and apachectl -M to see the modules, and renaming /conf.d/example.conf to conf.d/example.conf.disabled would allow me to disable sites fairly simply too, but I don't understand why these are different in the first place, and right now, I'm not sure of the advantages of doing it one way or another.

Are there any pages, blog posts or sites around to help explain the differences between the two, and possibly some of the thinking around why they're set up like this?

Right now I'm blindly following the convention I'm seeing in the standard CentOS file system without understanding why, which I can't help feeling will bite me when I least it expect it, like when I blunder across selinux's permissions layer, or something similar.

centos debian apache-2.2 httpd

2 Answers

  1. Every distribution has certain preferences and they follow the model they thought would be the best when it was created. This is caused by the lack of an standard and preference of the developers...

    I don't think there is much to understand, no..

    • 1
  2. Best Answer

    Just of different way of thinking about it. I don't think you have anything to worry about, nothing is going to bite as long as you leave the directory structure untouched. Obviously other packages are going to drop their own .conf files into the conf.d dir so it would be a bad idea to rename or move it. The modules-enabled/available is eliminated but don't count on the include line being in the conf.d file for all packages. Some still add it to the httpd.conf file via the RPM post install routine.

    • 1