Running your own local Apache server for development is a great idea, and even better if you’ve enabled local virtual hosts.
As demand for open source software increases, so do the options. Popular packages are frequently ported to different platforms, so it’s fully possible to run a local install of Apache regardless of which operating system you use on your workstation.
The stumbling block is mainly know-how, which is fortunately an easy gap to fill. I am decidedly not a system administrator, but I’ve run various Apache installs over the past year — without much conviction I should note, so learning has been slow.
After this past weekend’s rebuild, I got around to re-configuring a fresh copy of Apache Complete last night. Here are two tips from that experience.
Virtual hosts enable you to intelligently run multiple sites on a single server. The useful side effect is that with proper setup, you can point your browser to www.whatever.whatever and load a local copy. My development site is now www.mezzoblue.dev, which works exactly the same as the .com, just faster. I don’t even need a connection to work on it, because it’s all local; all my PHP scripts and Movable Type templates work, and the local filesystem access is so much nicer than using FTP.
I’ve long been aware of their use, but never committed to learning how to set up virtual hosts in Apache. A conversation with Narayan of Etherfarm on his recent trip through Vancouver enlightened, and it’s really ridiculously easy, to the point where I wish I’d done this last year.
httpd.conf file, and then add this line somewhere near the bottom (there’s a spot with example virtual server code, I stuck mine below that):
You might want to run a search for ‘NameVirtualHost’ within the file before-hand to make sure it’s not already set, or at least commented out with a preceding octothorpe (#).
Next add an entry for localhost pointing to the root of your web server, so that typing localhost in your browser’s address bar continues pulling up the default site:
<VirtualHost 127.0.0.1> ServerName localhost DocumentRoot /Path/To/WebRoot </VirtualHost>
And finally, for each individual virtual site you wish to run, add a new entry pointing to the proper directory. This is especially useful because, at least on Unix-based systems, this means it can sit anywhere in your filesystem. I’m used to dumping all sites in a special ‘www’ folder and pointing the web server to that; this way I can simply direct Apache to, in my case,
/Volumes/Shine/mezzoblue/www and keep all articles, .psd files, and web files in one folder.
<VirtualHost 127.0.0.1> ServerName www.mezzoblue.dev DocumentRoot /Volumes/Shine/www/delhi </VirtualHost>
But here’s the part I didn’t read, which I should have — you’re only halfway there once you’ve set up Apache. In a bout of doing one thing while having a hunch I should be doing another, I wasted far too much time configuring and re-configuring
httpd.conf before realizing I also had to tell my computer where to look for this host I’d just invented. It’s in the articles I linked above, but I missed this step. May you not make the same mistake.
Simply, all that’s required is editing your local computer’s hosts file so that your browser is able to resolve the fake names for your development sites. For each entry created in
httpd.conf, a corresponding entry needs to exist in your hosts file. Instructions on how to do this vary between operating systems, but it’s not hard to find tutorials. (The step-by-step instructions on this evolt article work perfectly in Panther.)
And That’s It?
As long as the directories you’ve pointed your virtual hosts to exist, and have files in them, you now have customized local hosts for your sites, on your own computer. Make sure to restart Apache before checking, which may require command line access, depending on your install. Other than that, you’re done.
Getting 403 errors?
If you’ve done everything above and can’t access your new site, due to a ‘403 Forbidden’ error, you have a permissions problem. If the directory/files you wish to load haven’t been given read permission for all users, the web server won’t be able to access them. As a general rule, public-facing directories and files should be at the very least something like 644 or (- r w - r - - r - -), and ideally 755 (or - r w x r - x r - x). If you don’t know what this means, a quick introduction to Unix permissions in general,
chmod in particular is in order.
Now, assuming everything looks alright, you may still get a Forbidden error. Turns out this is due to the execute permissions on all folders above the root of your virtual host on the server; namely, it must be set. For all of them.
If you have a directory serving as your root like so:
…then every directory above
Sites must have execute permissions set for all users. If you’re feeling brave, a quick and easy way to do this on the command line is as follows:
cd / sudo chmod -R 755 /Users
You will be prompted for your local computer administrator password. This will change permissions of everything in
/Users on down the hierarchy to 755. Fine if you’re in a fairly low-risk situation, like having a firewall in between you and the public internet (and trusting the local network your machine is attached to). Problematic if not. Otherwise, you’d simply do it on a per-directory basis:
cd / chmod 755 /Users cd Users chmod 755 dave cd dave chmod 755 Sites
If necessary, add the
sudo command before each
chmod line and authenticate as necessary.