Configuring Apache for local development on Lion I've managed to clue out this much:

  • /private/etc/apache2/ and /etc/apache2/ are symlinked
  • /etc/apache2/httpd.conf is authoritative
  • httpd.conf draws on the confs in extra
  • original is a red herring of unknown origin - presumably Apache

Coming from Debian, I've become accustomed to handling apache virtual hosts by adding files to /etc/apache2/sites-available/ and symlinking them to /etc/apache2/sites-enabled/. But that looks to be the special reserve of 'Lion Server' peoples. It's probably relatively trivial to set up that way but I'd like to know what other people have done;

  1. How do you configure your vhosts?
  2. Where do you put the code and docroot for your vhosts?
  3. Where do you put the log files?
  4. Where do you put the local application configuration?
  5. How do you resolve the name service?

1. How do you configure your vhosts?

The "Lion way" to do so would be uncommenting the following line in your httpd.conf.

#Include /private/etc/apache2/extra/httpd-vhosts.conf

Now you can edit /private/etc/apache2/extra/httpd-vhosts.conf and put your vhosts in there. It's a good idea to start with a default one that will match all unqualified hosts, for example:

<VirtualHost *:80>
  DocumentRoot /Library/WebServer/Documents

Next, you can either add every vhost to the same file, or you can set up a similar system like Debian by including all files in a specific directory next, like so:

Include /etc/apache2/sites-enabled/*

Now whether you symlink files here that exist somewhere else (sites-available) or put actual files doesn't really matter. Personally, I think sites-available is overkill for a dev box (and I don't ever really want to "disable" a vhost), so I just create a file for every vhost directly in sites-enabled or equivalent (in fact I named the directory /etc/apache/sites to avoid confusion).

2. Where do you put the code and docroot for your vhosts?

My actual sites I put in /Users/username/Sites. I prefer to put them under my home directory for easier access in Finder etc. That said, it is good to notice that this directory is exposed by default by the userdir module. Since I don't need userdir hosting, and I am going to configure webroots below, I disabled it by commenting the following line:

Include /private/etc/apache2/extra/httpd-userdir.conf

3. Where do you put the log files?

Log files I keep the same (eg. /var/log/apache/*). Again, for a local development box, I believe individual log files for every vhost are overkill. There's only so much that I can multitask :) If you do want separate log files, you can of course configure it that way inside the VirtualHost directive (for example /var/log/apache/my.project.dev-error.log).

4. Where do you put the local application configuration?

Which applications are you referring to? If web application, I keep those together with all other project files. Depending on your architecture, your config files do not need to be under your webroot if that's an issue, in fact typically my webroot for any given project will be /Users/username/Sites/someproject/web, so config files could be at /Users/username/Sites/someproject/config without exposing them through Apache.

5. How do you resolve the name service?

The most straight-forward would be adding each hostname to /etc/hosts. Unfortunately, this doesn't do wildcards. If you feel comfortable with setting up a DNS server like bind, you could configure one locally or on your network to resolve *.dev to, for example. Disadvantage of doing that on your network is of course that it will stop working at a different location. Personally, I use /etc/hosts.

  • Thx. For (4), yep webapp configs, one BOFH insisted i put them into /etc/ which seemed really odd at first but have since come to like it for the total separation from code; yet I've never seen anyone else ever suggest it so I was fishing to see if it popped up. – John2095 Jan 17 '12 at 20:03
  • Regarding the configs, I think this depends on the specific architecture. My config files usually contain configurations for multiple environments, and they get deployed as well. In that context it's certainly not logical to not keep them together. – Gerry Jan 18 '12 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .