The
House
of Ding.

Managing local development websites on your Mac

• Posted November 3rd, 2008
• by Chris
• No comments

I recently had my hard drive fail in my Mac­Book Pro I use for work, which, while a lit­tle painful, gave me the oppor­tu­nity get a fresh, clean install of everything—especially my Apache con­fig files.  Like a lot of devel­op­ers, my Apache con­fig files had been hacked to pieces.  This was a great time to re-think how I was doing things.

Apache accord­ing to Apple

My pre­vi­ous strat­egy of ignor­ing every line Apple included in httpd.conf and try­ing to write my own super genius con­fig­u­ra­tion was a night­mare.  My new strat­egy would be to fol­low the guide­lines and files that Apple includes with the 10.5 Apache.

Con­fig­u­ra­tion files

As of 10.5, Apple arranges Apache con­fig­u­ra­tion files in the fol­low­ing manner:

• /etc/apache2/httpd.conf — the über con­fig file
• /etc/apache2/extras/httpd-vhosts.conf — vir­tual hosts
• /etc/apache2/users/your_user_name.conf — options and access con­trol (IP exceptions)

We’ll use only these files to set up an indi­vid­ual site for each devel­op­ment app/website.

First things first

Before you start edit­ing files, turn on your local web server by going to Sys­tem Pref­er­ences > Shar­ing and check­ing the Web Shar­ing checkbox.

Clean up httpd.conf

Assum­ing you’ll want to do local Ruby on Rails (via Pas­sen­ger), SSL (with a self-signed cer­tifi­cate), and PHP devel­op­ment, make the fol­low­ing changes to you /etc/apache2/httpd.conf:

Listen 443
LoadModule php5_module libexec/apache2/libphp5.so
Include /private/etc/apache2/extra/httpd-vhosts.conf
# Rails via Phusion Passenger (mod_rails)
LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-1.0.5/ext/apache2/mod_passenger.so
RailsSpawnServer /Library/Ruby/Gems/1.8/gems/passenger-1.0.5/bin/passenger-spawn-server
RailsRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Add these lines to the end or your httpd.conf or just down­load this ver­sion with the changes already in place.

Add some vir­tual hosts

We’ll set up vir­tual hosts that respond to re-routed local DNS requests like acoolwebsite.local or companysite.local.  To do this, we’ll have to first add some lines to the /etc/hosts file to pick up these requests.

/etc/hosts

Add any local devel­op­ment web­sites to your /etc/hosts file and point them to the loop­back IP address, 127.0.0.1:

127.0.0.1 sslwebsite.local
127.0.0.1 companywebsite.local

/etc/apache2/extra/httpd-vhosts.conf

Now we’ll add cor­re­spond­ing vir­tual host entries in /etc/apache2/extra/httpd-vhosts.conf:

NameVirtualHost *:443
<VirtualHost *:443>
  DocumentRoot /Users/your_user_name/Sites/sslwebsite
  ServerName sslwebsite.local
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /Users/your_user_name/Sites/companywebsite
  ServerName companywebsite.local
</VirtualHost>

Access con­trol

Since you’re the only one devel­op­ing on your machine, you can safely open up all Apache options and enable over­rides in /etc/apache2/users/your_user_name.conf:

<Directory "/Users/your_user_name/Sites/">
  Options All
  AllowOverride All
  Order deny,allow
  Deny from all
  Allow from 127.0.0.1
  Allow from 72.14.207.99 # Joe's computer
  # Order allow,deny
  # Allow from all
</Directory>

This only allows requests to be made from your own machine. You can add IP excep­tions to allow access from cowork­ers’ machines or for demo­ing pur­poses. I leave the last two lines com­mented in case I need to tem­porar­ily open a site up to the world or if I don’t know the IP of a demo machine.

Restart Apache

That’s it—restart Apache with sudo apachectl restart and you should be in business.