Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

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?
share|improve this question
add comment

1 Answer

up vote 7 down vote accepted

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
</VirtualHost>

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 wether 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 seperate log files, you can ofcourse 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 wild-carts. 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 127.0.0.1 for example. Disadvantage of doing that on your network is ofcourse that it will stop working at a different location. Personally, I use /etc/hosts.

share|improve this answer
    
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. –  John Mee 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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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