I recently installed Leopard on my development machine by doing a completely fresh install in order to have a clean system. One thing I found that I couldn’t get running correctly was recreating my preferred Apache web server setup including Virtual Host configuration. Leopard runs Apache 2 by default but I had been running this on Tiger anyway rather than the default Apache 1.3.
Problem #1: Access denied using custom DocumentRoot
My first problem was that I like to use a different location for the DocumentRoot configuration, I keep my site files in ‘Users/rickcurran/Documents/Client_Data’ located in my Documents folder in my user account rather than in the default ‘Library/Webserver/Documents’ location. The problem I encountered was that if I changed the DocumentRoot to point to my preferred location I got a ‘Forbidden – You don’t have permission to access / on this server’ message. I tried to get it working and just gave up for a while and used the standalone MAMP application in the mean time to get working because this had no problem pointing to my custom DocumentRoot location.
Solution to #1: Change the user that Apache webserver runs as
I eventually figured out that in Leopard Apache’s default user (www) doesn’t have permissions to access my Documents folder. I simply went and changed the User and Group settings in the httpd.conf file to use my user and group and then it worked fine. I’m sure you could probably add the default Apache user to a group or some other Users / Groups / Permissions setting but for a development machine this solution works fine!
Problem #2: An alternative to name-based virtual hosts avoiding netinfo / hosts files
I like to have all my sites both current and past projects running locally so that I can fix any bugs etc without having to work on live sites. Apache’s Virtual Host configuration is perfect for the job. At first under leopard I just couldn’t get them to work but I realised that I’d simply missed something out in the configuration, so it was more a human error really. However whilst Googling trying to figure out what I’d done wrong it reminded me that most tutorials on configuring Virtual Hosts under Apache do so by using name-based hosts which require you to edit the ‘/etc/hosts’ file (or via Netinfo Manager on Tiger).
The drawback to this technique is that the sites are only viewable on your development machine, if other users on your network want to view the development sites they need to configure their own hosts file. This is a problem when you’ve got several machines that need to access the sites.
Solution to #2: Port based virtual hosts
To get around the hassle of Netinfo / hosts configuration I use an alternative virtual hosts setting which uses a different port for each site and can be accessed on any machine on the network.
To set up port based virtual hosts you need to first uncomment a line in the main httpd.conf to enable virtual hosts in the first place. Next edit the ‘httpd-vhosts.conf’ file found in ‘/etc/apache2/extra/httpd-vhosts.conf’, comment out the example virtual hosts that are there by default and then add your virtual hosts in the following way:
<VirtualHost *:80
DocumentRoot "/Users/rickcurran/Documents/Client_Data/intranet"
</VirtualHost>Listen 8081
<VirtualHost *:8081>
DocumentRoot "/Users/rickcurran/Documents/Client_Data/myexamplesite_co_uk"
ServerName 192.168.0.2:8081
</VirtualHost>
The first sets a default virtual host on port 80, the second sets up a site on port 8081. The examples above are very basic configurations, you could add support for error logs etc but this gets them up and running.
Restart Apache by unchecking and rechecking the Web Sharing tickbox in the Sharing System Preference you should then be able to access the ‘myexamplesite_co_uk’ site by using the URL ‘http://localhost:8081’. Also anybody else on the network can access the site too without messing around with the ‘etc/hosts’ file!
Scared to edit httpd.conf etc? Try HeadDress VirtualHostX
Update: It seems as if HeadDress is no more, the website has been down for ages so I’ve updated this section to refer to another app called VirtualHostX. If you don’t like editing config files via the Terminal then there’s a nice application called HeadDress VirtualHostX that gives a nice user interface for the whole process of setting up Virtual Hosts. VirtualHostX allows you to create sites running on their own local domain name by editing your /etc/hosts/ file, you can also specify a specific port for the site too.
I still prefer using my own method #2 above as it allows multiple users on your local network to view your sites as well, whereas with VirtualHostX you’d need everyone to edit their /etc/hosts/ file. For single machine web development it’s a great application and costs only $9.00 for a licence.
I think you should change the advice given in answer #1 as it isn't a good all round solution.
First look for problems in your config files using:
httpd -S
and
httpd -t
Next, ensure that the execute bit is set on all directories in the web path.
chmod +x dir1 dir2 dir3
Now you can add
< Directory /some/other/path>
Order deny,allow
Allow from all
< /Directory>
or if you want to make the change for all your sites, all at once, add
< Location />
Order deny,allow
Allow from all
< /Location>
to httpd-vhosts.conf.
Thanks a ton for these tips. I have been trying to get virtual hosts on my leopard installation for the past 3 days. The problem was the user and group setting in httpd.conf It is now working thanks to your solution to problem #1.
Right on Neal! Terrific catch.
I realized I missed the comment above the Directory element – “This should be changed to whatever your document root is”. Doh :)
I was bashing my head against the desk wondering why my virtual sites were giving a ‘Forbidden – You don’t have permission to access / on this server’ message after upgrading to Leopard, despite the file/directory permissions on the web directories being unchanged.
This happens if your virtual sites aren’t under /Library/WebServer/Documents and there is a solution that doesn\’t need the apache user and group to be changed (which could lead to other hassles).
After actually realising Leopard had changed from using Apache1.3 to Apache2 I (eventually) looked at what differences there were in the httpd.conf files relating to directory access.
(In what follows I’ll use square brackets to delimit apache directives in case angle brackets aren’t escaped when displaying as HTML).
In Apache1.3 Apple’s httpd.conf has this:
[Directory /]
Options FollowSymLinks
AllowOverride None
[/Directory]
[Directory “/Library/WebServer/Documents”]
…
Order allow,deny
Allow from all
[/Directory]
The [Directory /] block has an implicit Order Deny, Allow directive (i.e. the default) so that anything below the root of any site is, by default, accessible. (The [Directory “/Library/WebServer/Documents”] block’s directives are explicitly saying that anything within /Library/WebServer/Documents is accessible. This doesn’t change what is already allowed).
However, in Apache2 Apple’s httpd.conf has this:
[Directory /]
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
[/Directory]
[Directory “/Library/WebServer/Documents”]
…
Order allow,deny
Allow from all
[/Directory]
The [Directory /] block now explicitly makes everything inaccessible below the root of any site by default. Now the [Directory “/Library/WebServer/Documents”] block’s directives are overriding this to grant access to everything under /Library/WebServer/Documents.
That’s fine if your virtual sites are under /Library/WebServer/Documents but if they’re not you get ‘Forbidden – You don’t have permission to access / on this server’.
The solution is simply to add an Allow from all directive for each virtual site’s DocumentRoot, e.g.
[VirtualHost *:80]
ServerName my.virtual.site
DocumentRoot /some/other/path
[/VirtualHost]
Becomes:
[VirtualHost *:80]
ServerName my.virtual.site
DocumentRoot /some/other/path
[/VirtualHost]
[Directory /some/other/path]
Allow from all
[/Directory]
The Allow from all directive overrides the [Directory /] block’s Deny from all directive because it is processed afterwards and the last one processed wins.