Mac OS X Web Server Tips for Designers, Part 2

We've been rolling through one of the decidedly unsexy (albeit often necessary) aspects of being a Web designer: the need to actually use an honest-to-goodness Web server to test out your sites. Mac OS X makes this process pretty easy, but there are some extra steps one can take to make the whole experience a tad more full-featured. Let's go over a few more tips for adding some extra bling to Mac OS X's indigenous Web server.

Tip #4: Embrace the symlink

When we last left off, I had just finished describing one method of changing your Document Root directory to the location of your choice by using Bare Bones' Text Wrangler (or BBEdit, if you prefer, as I do) to edit the Apache httpd.conf file. If you'd like to review this process, by all means click on this link to read Part 1. You're going to need some of the knowledge (such as it is) contained there if you want to follow along a little later. In the meantime, there's a much simpler way to change your Document Root that nicely frames our brief discussion about symbolic links.

If you remember from last time, the Apache Web server built into OS X uses the /Library/WebServer/Documents directory as the default folder to serve Web pages from. This time, we're going to use a symbolic link to change the directory rather than edit the configuration file. If you happen to be unfamiliar with symbolic links (or symlinks for short), here's the lowdown: symlinks have their roots in Mac OS X's Unix underpinnings, and are sort of like the tried-and-true "classic" Mac aliases. However, instead of being a simple pointer to folders or files on your system, a symlink is seen by the system as an actual instance of said file or folder. Such a distinction is important when it comes to Mac OS X's Web server, as Apache will respect and "follow" symlinks, while it will ignore aliases. Therefore, it's possible to create a symlink of the desired folder that you want to use as your root folder, and then move that symlink to where Apache expects to find it. The question becomes, then, how to best create symlinks, since Apple still only makes it easy by default to create aliases. You could, of course, use the Terminal to create symlinks, but as I promised last time that I wouldn't go down that road, we need a more GUI-fied solution. Enter Nick Zitzmann's Symbolic Linker, a free contextual menu item which can be downloaded from this link. Once you install Symbolic Linker and log out and log back in (or at least force restart the Finder), all you need to do to right/control-click on the file or folder you want to make a symlink to and select "Make Symbolic Link" from the contextual menu (fig. 1). You can then move and rename and do whatever else with the symlink you like, as it's just another item in the Finder to be manipulated like anything else.

Figure 1

Now that we're all up to speed with symlinks and how to easily create them, let's run through the process of using a symlink to point at a different root folder. Note that this procedure assumes that you haven't already changed the location through the httpd.conf file the way we did last time.

• In the /Library/WebServer/ folder, rename the Documents directory to DocumentsBak (or some other name—the point is not to delete the directory outright in case you ever want to change things back).
• Navigate to your desired root folder (remember, in our earlier example, the path was /Volumes/Data/DocRoot), right-click on it, and select "Make Symbolic Link."
• Drag and drop the symlink (which, in our example, will now be called DocRoot symlink) to the /Library/WebServer folder.
• Rename the symlink to Documents.
• Restart the server by going to the Sharing Preference Pane and clicking the Stop and then the Start buttons next to Personal Web Sharing service.

That's it. The server will then follow the symlink to your new document root folder. However, as Ron Popeil might say, "But wait—there's more!" Now that you have the whole symlink thing down, you'll probably also want to use symlinks to point to various other folders on your hard drive. For example, say you have a big client, which we'll call "BiggCo." You're doing some Web work for BiggCo, so naturally, you have a BiggCo directory somewhere on your hard drive. Inside that directory is likely another directory where you store your Web files, perhaps named Web Docs. You could do the following:

• Create a symlink for your BiggCo/Web Docs folder.
• Drag the symlink to your DocRoot folder.
• Rename the symlink to biggco.

Now, using one of the various URLs alluded to in the last installment, you could then point your browser at http://localhost/biggco/ and see your BiggCo Web files in all their glory. So, just to sum things up, symlinks can not only be used to "move" your Document Root directory without editing the configuration file, they can also redirect individual directories so you can keep project files in a single place.

Tip #5: Change the default document

If you've done any sort of Web design, you're no doubt highly aware that each server you post files to has a default document that it will serve up. Whether it's default.htm, index.html, or something else, any file named for the server's default will be automatically displayed when the root URL or subfolder is accessed (e.g., http://www.site.com/ or http://www.site.com/directory/). Of course, if you're not happy with index.html, which is the Mac OS X server default, you can easily change this as well. Now, for this hint, you'll need to be up to speed with the whole TextWrangler/BBEdit setup that was outlined last time for editing the httpd.conf file, so you may want to review that process if you skipped the previous installment.

As per the instructions from last time, open up the httpd.conf file, hit Command+F in either TextWrangler or BBEdit, and look for the text "index.html" (without quotes, of course). In BBEdit, this should appear at or around line 445. The full text in question should look like this:

# DirectoryIndex: Name of the file or files to use as a pre-written HTML
# directory index. Separate multiple entries with spaces.
#
<IfModule mod_dir.c>
    DirectoryIndex index.html
</IfModule>

All you need to do is add a space after index.html and then type whatever you want to serve as a default file. Put as many as you like here; I usually am just fine with index.html, but I tend to add the following list just to have options:

• index.htm
• index.shtml
• index.shtm
• default.html
• default.htm

My new line would then look like this:

<IfModule mod_dir.c>
    DirectoryIndex index.html index.htm index.shtml index.shtm default.html default.htm
</IfModule>

As for the .shtml and .shtm entries, those will be useful for our next installment, so consider that a tease to get you to tune in next time when we enable PHP and SSI. In any event, once you add your entries and restart the server, you'll be able to have any of your entries serve as the default page for any directory. Keep in mind, though, that any directory that contains more than one of the files named as a default document will have the first entry in the httpd.conf file serve as the default. So in our example, if a directory contains both index.htm and default.htm, index.htm will be used since it comes first. First come, first served, if you'll pardon the hideous pun.

Tip #6: Futz with the hosts file

The last thing we'll go over today is a brief introduction to the hosts file. This file certainly isn't unique to OS X, nor is it even really associated with OS X's Web server that we've been dealing with up to this point. However, it is a tool we can use to aid in Web development, so it deserves a mention. Now, for those who may not be familiar with the hosts file, in a nutshell, it's a document that your browser checks to pair IP addresses with an associated URL. By modifying this file, you can map specific URLs to your local machine, which may come in handy during the design and development process. To expand upon the earlier example, let's say that you're still working on BiggCo's site. While you are, it might be nice to have http://www.biggco.com/ resolve directly to your local server, and editing the hosts file will help do just that.

We're going to use the same process to edit the hosts file as we did to mess with the httpd.conf file, so this should be a relatively simple process to walk through. That said, edit this file at your own risk, and don't blame me if you do it wrong:

• In the Finder, select Go:Go to Folder (Command+Shift+G) and type in /etc/ (fig. 2).
• Scroll down to the hosts file.
• Option-drag the hosts file to the same directory to make a copy, entering in your password when prompted (fig. 3).
• As with the httpd.conf file, drag the hosts file to the TextWrangler/BBEdit icon in the Dock to open it.

Figure 2

Figure 3

As you'll notice, the hosts file doesn't have a whole lot to it. There's an introduction and two entries, the first of which:

127.0.0.1    localhost

will seriously foul up your machine if it is removed, so be careful not to mess with it. Anyway, the syntax for adding entries is very straightforward. If you read Part 1, you'll know that 127.0.0.1 is the local IP address for your own machine, and you'll also know that if you type localhost into your Web browser, you'll also be accessing your local machine. It would then appear that the first entry in the hosts file makes this happen, as localhost is mapped to 127.0.0.1. Therefore, the syntax to add a new entry would be (using our BiggCo example):

127.0.0.1    www.biggco.com

Makes sense, right? Now, once you save the file you'll need to reboot your machine for changes to take effect (there is a Terminal command do force this without a reboot, but I promised no Terminal), but once you're back up, typing http://www.biggco.com/ into your browser will route to your own local server.

Of course, you can probably figure out how changing entries in the hosts file would be useful beyond what we've done today, so if you want to explore further, please use caution. Messing up the httpd.conf file is one thing, but the hosts file is vital to your system working properly, so take the appropriate amount of care when playing with it.

Next time...

Now, I know I promised that we'd go over enabling PHP and SSI in this installment, but the more I thought about it, the more I realized that those steps are better addressed separately in their very own piece. So with apologies for the "bait and switch," as it were, I hope to see you all next time!

Filed under: Tutorial on May 31st, 2006

^ Top of Page

Got Feedback? to send an email. I'll do my best to answer. Really.