-1

Every time I've ever run a production installation of Apache, it's been deployed in the standard configuration implied by the httpd documentation:

PREFIX/bin
      /conf
      /logs
      /htdocs
      ...

Normally, that dir structure is owned by root, and I'd go off and create a similar directory structure somewhere like:

/app_partition/apache/current/bin
                             /conf
                             /logs
                             /htdocs
                             ...

The scripts in my bin dir then call through to those in PREFIX/bin, passing it the -f option to point it at the conf files on /app_partition. Thus, I can run several instances of apache on the same server (useful for e.g. having dev and UAT environments on the same box), always referring to a pristine copy of binaries that the application account can't modify. If I need to listen on port 80, a one-time configuration by root sets up iptables rules that forward port 80 to whatever port the relevant apache instance is listening on.

For bonus points, current in the above path is a symlink, as is htdocs when required, and the whole lot - start scripts, config and all - is built out of source control and deployed with scripts.

So, now I find myself with a CentOS VPS account with Apache pre-installed. It's been done through yum, and the apache files are all over the place; code in /usr/sbin/, config in /etc/httpd, the doc base in /var/www/; all owned by root, all offering (in my mind) very little flexibility.

I'm en route to getting everything up in the manner that I'm used to (without compiling from source, since I quite like the idea of being able to apply security updates with a single yum command) , but I have a couple of questions:

  1. Why do distros (all the others I've looked at seem to do the same) insist on spewing the various bits of httpd all over the place - why not just install under /opt/apache/ or similar?

  2. How do other people make this work? Are people (who aren't hosting companies) really out there running Apache out of /usr/sbin? Specifically:

    • How do you get around /var/www being owned by root? Symlinks?
    • How do you control Apache upgrades? (Clarifying a bit: There's only one copy of the httpd binary on the sytem, so when you upgrade, you're essentially saying to all users/apps on the system "Congrats, you've been upgraded!", shortly followed by "What do you mean, your config doesn't work any more?")
    • How do you roll back Apache upgrades, if it all goes wrong? In the past, I've struggled to make yum downgrade stuff. (Thankfully that netbook came with a restore disk.)
    • How do you version your Apache config?
    • What's this /etc/httpd/conf.d dir?

    -bash-3.2# cat /etc/httpd/conf.d/README

    This directory holds Apache 2.0 module-specific configuration files; any files in this directory which have the ".conf" extension will be processed as Apache configuration files.

    Files are processed in alphabetical order, so if using configuration directives which depend on, say, mod_perl being loaded, ensure that these are placed in a filename later in the sort order than "perl.conf".

    That's some sort of bad practical joke on unsuspecting noobs, right?

Andy
  • 33
  • 3

2 Answers2

2
  1. Distros put stuff "all over the place" to follow the filesystem hierarchy standard for Linux, where binaries intended to be run by root go in /usr/sbin, configuration files go in /etc, files that change go in /var, etc... This allows the system to interact better with other tools.
  2. Yes, people really run apache out of /usr/sbin.
    • I've never had a problem with /var/www being owned by root. One one system, /var/www/html is a symlink to another location. If I need one of those to have a different owner, I set the ownership with puppet, so that future upgrades of httpd won't break it.
    • "yum update". :)
    • Upgrades never go wrong, because RH doesn't make feature changes and properly marks config files so that updated versions don't overwrite your versions. It's not that hard to get the old version of the RPM and downgrade to it, however.
    • On my older systems, the apache config is tracked in revision control (CVS, SVN, whatever). On newer systems it's pushed out from puppet (which is in revision control)
    • /etc/httpd/conf.d is a directory of config files that are included in the config. It allows other software that interacts in some way with apache to drop the required configuration in place without needing to edit a config file from a script. For instance, if you install the squirrelmail RPMs, they'll drop a config file in there. Install the mod_perl RPM and it drops a config in there that loads mod_perl.so (and has examples of other things you might want to do in some comments)
freiheit
  • 14,544
  • 1
  • 47
  • 69
  • 1
    And the benefit of the FHS is that you don't have to backup a million different places to get all of your configs and data without also collecting all of your binaries. – womble Nov 17 '09 at 21:41
  • I know about the FHS but I don't buy into the back-ups argument. Ideally, there shouldn't *be* anything in those dirs that needs backing up, since that implies that you can't recreate your server build automatically out of version control. App data (vs configuration) should be on a separate partition with appropriate restrictions. Similarly, I've never been enormously thrilled with the idea of running httpd as root, either. – Andy Nov 17 '09 at 21:57
  • 1
    You *have* to run httpd as root, if you want to run it on a port < 1024. That's UNIX 101. What you can do (and CentOS does by default) is configure httpd to run the spawned processes as a non-root user. CentOS uses the user apache. You can change that user by changing this line in /etc/httpd/conf to: User apache – Aaron Brown Nov 18 '09 at 16:16
  • Somthing i want to leave here: `8080 TCP HTTP alternate (http_alt)—commonly used for Web proxy and caching server, or for running a Web server as a non-root user Official` [wikipedia](http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers) – Metalmini Jul 09 '14 at 07:06
1

You can just stick config/logs/htdocs where you want it and then run /usr/sbin/apache -f /whatever/you/want/httpd.conf. The only thing you can't easily change is the binary location, and that's well-known (and not something you want on a per-instance basis, as far as I can tell).

womble
  • 96,255
  • 29
  • 175
  • 230
  • Exactly right. If you want to have an environment that scales and plays nicely, play within the rules of the distribution you have, and don't change things for the sake of change. – Matt Simmons Nov 17 '09 at 22:17
  • I'm already using -f, and this question is exactly about *how* I play nicely within the rules of the distribution. Thinking about it more, I think my confusion is because everything comes set up for running exactly one version of Apache as root - and neither of those assumptions apply in the environment I'm used to. Said environment's not huge, but it's a couple of hundred servers, and we make everything play nicely by running as little as possible as root, and when upgrading keeping the proven-good install alongside the new one. Rollback's then stop.sh -> symlink change -> start.sh – Andy Nov 17 '09 at 23:02
  • Why are you bothering with CentOS then, since you obviously know more about how to run it than it does? – womble Nov 18 '09 at 06:21
  • If I thought that, I'd just have ripped out what's provided and done my own thing, rather than ask a question. I don't want to significantly change things, so I want to understand how I'm supposed to manage the default installation. – Andy Nov 18 '09 at 09:57