View Revisions of Serving a Website from a Home Network on Mac OS X

Compare:	Current Version: 26-Jan-09 20:21 Version 2: 21-Dec-08 21:34 Version 1: 10-Dec-08 22:34 (should be the newer of the two)
To:	Current Version: 26-Jan-09 20:21 Version 2: 21-Dec-08 21:34 Version 1: 10-Dec-08 22:34 (older)

Key: Unchanged text, New text, Deleted text

One of the perks of owning a Mac is the ability to create your own website using iWeb[1] and then to host it from your home using the built-in Apache webserver in Mac OS X. While generally straightforward, the process does include a number of decisions and tasks of which the everyday Mac user probably is not cognizant. The following guide should fill in these gaps to allow just about anyone with a home Internet connection to host and maintain their own website (or multiple sites) using nothing more than the software bundled with Mac OS X.


h2. Create Your Site


Of course, there's no point in using your Mac to host a website if there is no website. WYSIWYG[2] software packages such as iWeb are great for quickly organizing simple yet functional websites. While an avid web developer would likely find these programs constraining, they are just what the doctor ordered for someone looking to start a blog, share pictures/videos, or even start a podcast. No matter how you decide to do it, though, creating your site is probably the first step. Once you have something put together to publish online (which doesn't need to be much), you are set to use the steps outlined in this article - learn about networks, register a domain, configure your router, etc. That's right, _you_ are going to do all of those things - and it probably won't be as painful as you think.


h2. Website Basics


Before getting into the thick of things, it is important to know how networks work. While more detailed information on this subject is available elsewhere,[3] most of the definitions and explanations necessary to take full advantage of this article are included below:
* _Server_ - any computer that is willing to accept and handle a request. If you have an image in your mind of a towering rack of blinking lights, discard it. The very computer you are reading this article from could be a server with proper configuration.
* _Client_ - any computer that sends requests to a server. The computer you used to access this article is a client of the OmniNerd server.
* _Port_ - a number that helps channel the requests a server receives and usually represents a certain type of traffic. The vast majority of webservers are configured to take requests on port 80.[4]
* _Hostname_ - a computer name that is known by the computer itself and possibly other computers on its network.
* _Domain Name_ - a registered name that has global scope. OmniNerd.com is an example. There is only one OmniNerd.com.
* _IP address_ - a numeric identifier in the form of XXX.XXX.XXX.XXX where XXX represents a number from 0-255. Domain names get translated into IP addresses, which are what routers and computers use to direct information on networks.
* _Internet Service Provider (ISP)_ - the company you pay to provide access to the Internet.
* _Hyper Text Markup Language (HTML)_ - a markup language describing how plain text should be annotated with tags to provide information about the text.
* _Hyper Text Transfer Protocol (HTTP)_ - the way HTML documents are transferred on networks.
* _Routing_ - a manner of directing client requests to the proper location. This is accomplished in many ways, but for the purposes of this article we will consider the routing involved when a server is running from your home and is plugged into a router, which is plugged into a modem. This model breaks down as follows:
* #_Client to DNS_ - when the client queries a separate, authoritative server for the IP address associated with a submitted domain name.
## _Client to DNS_ - when the client queries a separate, authoritative server for the IP address associated with a submitted domain name.

* #_Client to Your Modem_ - when the client uses the IP address received to accesses your modem.
## _Client to Your Modem_ - when the client uses the IP address received to accesses your modem.

* #_Modem to Router_ - when your modem passes the traffic along to your router, which you have told to forward all port 80 traffic to your computer (the webserver).
## _Modem to Router_ - when your modem passes the traffic along to your router, which you have told to forward all port 80 traffic to your computer (the webserver).

## _Router to Webserver_ - when the router passes the traffic to your server, which fulfills the request and basically reverses this process to get the requested data to the client.

* #_Router to Webserver_ - when the router passes the traffic to your server, which fulfills the request and basically reverses this process to get the requested data to the client.


h2. Should I Host My Own Site?


Playing around in iWeb and learning about networking is all well and good, but is hosting your own website right for _you_? I mean, even though Steve Jobs[5] could use this article to serve the next version of _Apple.com_ from his home Mac, that does _not_ mean it would be a good idea. Aspiring webmasters (like you) should first consider issues like available equipment, bandwidth requirements, etc.


h3. Equipment


If you are running Mac OS X and are connected to the Internet, you likely have all the equipment necessary to host your own website. The only potential issue comes when certain ISPs block port 80. The easiest way to determine if this will be an issue for you _should_ be to call your ISP, but we do not recommend this as you are likely to get bad information (depending on the quality of your ISP, of course). The section entitled "Hosting the Site" below will give you further details on checking the availability of port 80.


h3. Inherent Limitations


While Mac OS X provides a lot of out-of-the-box functionality, like a webserver, internal and external factors will likely keep it from performing anywhere close to commercial-grade servers on all levels.


h4. Bandwidth


Unless you paid extra for it, your Internet connection is likely slow. This means that your website will lag and may even result in 503 errors[6] when it is subjected to traffic beyond the abilities of your Internet connection or processing capacity. Additionally, the same issue may result if you intend to serve high volumes of content to even a few users. The vast majority of personal websites (e.g., blogs, photo sharing, etc.), however, will not fall victim to these limitations. If you have tons of video and images in mind, you may want to reconsider or call your ISP to see what increased bandwidth options are available.


h4. Uptime


Uptime is another factor to consider. Your computer, network, and ISP must all be in simultaneous working order for your site to function. If your site cannot afford to have temporary downtime while any of these components are either turned off, out of order or mis-configured, you may need to check out other options. With that being said, many computers and networks are able to run almost continuously and ISPs are gaining credibility; it could be that power outages are the only time your service experiences any interruption.


h4. Server Maintenance


Another potential issue is that _you will be responsible for all maintenance_. While the basics of such maintenance will be covered in this article, it is possible that a combination of circumstances, predatory software, or other foul luck could land your server in a complicated mess - with no officially provided tech support to turn to for guidance.


h4. UNIX-like System Knowledge


One key in being able to address server issues is knowledge of UNIX-like systems. Much in Mac OS X, including the Apache server, can be efficiently addressed via the Terminal application (and shell of your choice, though _bash_ is the default), and thus proficiency in Terminal navigation will be beneficial. If you've heard of UNIX and are fairly computer literate but aren't UNIX-adept, fear not; this article will explain what you need to know. If, on the other hand, UNIX is Greek to you and you have difficulty working anything more than email and a web browser, you will likely struggle with website administration.[7]


h3. Other Options


If all of these factors have you convinced serving your own website is for the dogs, you will have to open your pocketbook and turn to a commercial sector for a third-party server. These come in two varieties: shared and dedicated.


h4. Shared Third-party Servers


Shared servers, as the name implies, are servers shared with other sites. They range from very affordable at under $15/month, to rather costly at over $100/month.[8] Most shared servers will meet the needs of the run-of-the-mill website; it is only when your site starts to attract relatively heavy traffic that a dedicated server becomes necessary. Additionally, if your site will be nothing more than some HTML generated by an application such as iWeb and will have traffic on the order of a typical blog or family site, you might be able to secure a shared server environment for less than $10/month.

It is also of note that many shared servers are "managed," meaning most site administration activities are taken care of by the server host - to include available technical support.


h4. Dedicated Third-party Servers


Dedicated servers are reserved for your site (or sites) alone. They are considerably more expensive, ranging from just under $100/month to over $250/month.[9] If your site is going to be developed using iWeb or a similar application, a dedicated server is probably overkill and not worth the extra cost.

The more expensive dedicated servers are also usually _not_ managed in terms of software, meaning _all server administration will be in your hands_ - which may be manageable for a beginner when using your Mac as a server, but is a whole different story when dealing with a dedicated server from a remote location.


h2. Register a Domain


After deciding if serving your own website is in your best interest, the next step is to register a domain. Your site domain, or hostname, is what the user will enter into a browser as part of a website, other URL, or email address to access your site and its features. The domain name of _OmniNerd_, for example, is _omninerd.com_. When a domain is "registered" in behalf of a person, group or organization, it is reserved for their use. In this way someone could register _iamthecoolestpersoninthewholewideworld.com_ for the homepage of their new blog and not have to worry about someone else stealing the name for their startup social networking site.

Additionally, keep in mind when determining your domain that certain extensions are designated for different purposes. These guidelines are not strictly enforced in some instances (e.g., _.org_ and _.info_), but are more stringent in others (e.g., _.gov_ and _.edu_).[10]


h3. Determine Domain Availability


The first step in registration is to determine if your desired name is available. This is most easily and accurately determined by using a "whois" command to find more information on the owner of a site. To do this, simply type "whois exampledomain.com" at a Terminal prompt and scour the output for any leads.[11] The quickest visual cue in the output of a whois command is domain registrant information. For example @whois omninerd.com@ will dump a lot of stuff, but the section with the following makes it fairly obvious that this domain is registered:

bc..
Domain Name: omninerd.com
Registrar: AAAQ.COM
... much more registrant info would follow ...

p.

Conversely, non-existent domains are even easier. Consider @whois probablydoesntexistdomain.com@. Simply look for a line like:

bc..

No match for "PROBABLYDOESNTEXISTDOMAIN.
COM".
No match for &"PROBABLYDOESNTEXISTDOMAIN.
COM".


p.

Alternatively, you could type your desired domain into a web browser, but that would only check if anything was listed for the domain on port 80. (There are roughly 65,000 other ports.) Lastly, another means of checking for domain availability is to run a search on a domain registration site. This is usually integrated into the registration process, and is unnecessarily slow to obtain the same results.

[[Image:server_not_found.PNG]]
png]]

[[Image:domain_search.PNG]]
png]]


h3. Register


There are many online sites that offer domain registration services. Some of the more popular ones include _GoDaddy.com_,[12] _register.com_,[13] _networksolutions.com_[14] and _aplus.net_.[15] Each will likely be running myriad sales and promotions, so a quick survey of these and others may save you a couple of dollars (and hopefully make you as happy as the people pictured on those sites).

If you are less particular on your domain name, you should also consider various free domain providers. If you are willing to append _.dyndns.org_ (or any of a long list of other extensions) to the end of your domain, for example, you can register a _free_ domain at Dynamic Networking Services.[16]


h3. Post-Registration Setup through the Registrar


After registering, you will notice your selected domain now points to a default page or place holder posted by your domain registrar. In order to display your site, you will need to tell the registrar where to look. This is done using "DNS Control," which can usually be found on the domain management page after logging into your account with your domain registrar. One line of the included information will indicate the IP address to which the domain is presently pointing. Edit this to be your site's location, or WAN IP address, which will be the IP address of either your Mac or your home network router. (If you are unsure of how to determine the appropriate IP address, do not fear; it is covered later in the article.)

[[Image:dns_control.png]]

[[Image:dns_control_2.png]]

[[Image:dns_control_3.png]]

Your domain registrar could take up to 24 hours to properly implement your IP address changes on their system, but it is usually accomplished in no longer than 15-20 minutes. If your domain is still not properly forwarded to your computer after 24 hours, and you have properly cleared your cache, contact your domain registrar's customer service department.


h3. What to Expect Post-Registration


Other than an occasional promotional email and a reminder to renew your registration, you will likely not hear from your domain registrar. You may need to return to the site to update your IP address, however, so user-friendliness and customer service are factors you should consider in your selection.


h2. Host the Site


Hosting websites in Mac OS X is probably best described in two ways: the easy, inflexible way, and the less easy, flexible way. The former is ideal for those wishing to zip through the process with as little hassle as possible and with no "I'd like to expand to do X in the future" ideas floating around in their heads. The latter is ideal for those _with_ the floating ideas.


h3. Extremely Easy, Less Flexible Way


The easy, flexible method essentially consists of four simple steps:
* Turning on your Mac's webserver.
* Ensure access on port 80.
* Move your files.
* Do a quick internal test.


h4. Turn on Websharing


In order to turn on your webserver, first ensure you have a working network connection and then open _System Preferences_ and select the _Sharing_ preference pane. Locate the _Web Sharing_ option and turn it on by clicking the start button. Once running, your computer's IP address will be listed under "Network Identity" in the preference pane.[17] Make note of this for future reference and feel free to return to this preference pane if you forget your computer's IP address in the future. Alternatively, you can always run "ifconfig" in a Terminal window and locating the IP address in the output.

[[Image:websharing.png]]

Before going further, it is important to understand what kind of IP address it is you have just obtained. There are two kinds of IP addresses: those on Local Area Networks (LAN) and those on the Wide Area Network (WAN). The LAN addresses are used for communication within a local (or home) network, while the WAN addresses are used for communication over the Internet. Depending on what hardware you have at home to connect to the Internet, your computer's IP address (the number you looked up in the previous paragraph) can be either of these. If you are using a router, then it (the router) holds a _WAN_ address and assigns your computer a _LAN_ address. If there is no router, then your modem assigns your computer a _WAN_ address and there is no _LAN_ address. Perhaps the easiest way to determine the type of IP address your computer has, however, is to know that nearly all LAN addresses start with 192.168.[18] Thus, in Figure 6 above, it is obvious the shown IP address (192.168.1.100) is on a local network and thus would not allow access to someone outside of that network. (If a user outside of that network entered that IP address into a browser, it would attempt to access the computer with that same IP address on its own local network.)

The important thing to remember out of all of this is the _WAN address_, whether held by your computer or your router, is what a user will need to access your website.


h4. Move Web Files


Once your webserver is turned on, drag or paste the HTML documents that makeup your site into the _Sites_ folder in your _Home_ directory. At the least, these documents should include an HTML file entitled "index.html" or "Home.html." You can test to see if everything is properly configured by typing your computer's IP address you identified earlier into a browser: http://yourHomeNetworkIPAddress/~yourShortUserName/. (You can locate your short user name by navigating to _System Preferences_ -> _Users Preferences_, clicking on your name and then selecting _Edit User_.) Accessing this location is also possible by following the link on the _System Preferences_ -> _Sharing_ -> _Web Sharing_ page, "http://198.162.1.100/~Brandon" in Figure 6 above. If your site displays properly, everything the files are in the correct location.


h4. Configure Your Router to Allow Accessibility on Port 80


As previously mentioned, if your computer is on a home network (and thus has a LAN IP address), you must ensure incoming requests for your site are directed to your computer (rather than a network printer, for example) by your router. This is done by telling the router to send all requests on port 80 where to go. In order to do this, access your router by inserting http://192.168.1.1 (or your router's LAN IP address if different) into a browser. (If, on the other hand, your computer has a WAN IP address, you can skip this section.)

After logging on with your user name and password, check your router's _Application/Gaming_ page (or something similar) to see if it allows access on port 80, as shown in Figure 7. If there is no line for port 80 access, add one. If there is an existing line, then confirm the IP address listed matches your Mac's LAN IP address and that the "Enable" box is checked (if necessary).

[[Image:port80.png]]

If you do not know the LAN IP address of your Mac (forgot already?), you can find it using the "ifconfig" Terminal command or the _System Preferences_ check mentioned earlier. Remember, since you obviously have a router if you are attempting to configure it, your computer has a LAN IP address that will usually be of the form 192.168.1.xxx, with xxx commonly being 100, 101, 102, etc.


h4. Test and Go Global


Once websharing is on, your files are in place and the router is configured to allow port 80 access (if necessary), everything should be set to introduce your website to the world. Before going public, however, test your site by inserting your router's WAN IP address into your browser. If you do not know your router's WAN IP address, you can find it by accessing your router's _Status_ page (probably http://192.168.1.1, again). On the other hand, if your computer has the WAN IP address (i.e., you don't have a router), use that instead.

[[Image:router.png]]

If you insert the WAN IP address into a browser and see your website, then everything is properly configured; the router (if it exists) is properly directing traffic on port 80 to your Mac, and your Mac is successfully serving your website. If your domain registrar has successfully connected your domain to your WAN IP address, you (and anyone else) should now be able to access your website using the domain name.

Once successful, feel free to step outside briefly and shout "Hello world!"
Once successful, feel free to step outside briefly and shout, "Hello world!"


h3. A Little More Complex, More Flexible Way


The slightly more complex but much more flexible way adds the ability to serve more than one website from your computer and also to access the webfiles from more than one administrative account. If you are not interested in those features, feel free to use the simpler, less flexible method above.


h4. Host More than One Site


Hosting more than one site in Mac OS X involves editing the main Apache main configuration file. Apache, which is the webserver Mac OS X uses to do all of this magic, is configured by placing directives, or sections of code, in plain text configuration files.[19] The main configuration file is called httpd.conf and you can locate it by running the command @httpd -V@ from the Terminal. Within the output is contained the Apache server version (e.g., @Server version: Apache/1.3.20 (Darwin)@), the main configuration file location (e.g., @-D SERVER_CONFIG_FILE="/etc/httpd/httpd.
conf"@), as well as the Apache log files (e.
, @-D SERVER_CONFIG_FILE="/etc/httpd/httpd.
conf"@), as well as the Apache log files (e.
g., @-D DEFAULT_XFERLOG="/var/log/httpd/access_log" / -D DEFAULT_ERRORLOG="/var/log/httpd/error_log"@).
, @-D DEFAULT_XFERLOG="/var/log/httpd/access_log" / -D DEFAULT_ERRORLOG="/var/log/httpd/error_log"@).


Directives placed in this main configuration file will apply to everything served from your computer. If you want to serve more than one website from your Mac (i.e., have certain directives only apply to certain requests), however, you will need to implement what is called a _Virtual Host_.[20][^,^][21][^,^][22] Basically, this directive in the configuration file serves as a filter to point incoming requests to different websites. The filter can be "IP-based," meaning that you have a different IP address for every website, or "name-based," meaning you have multiple domain names on a single IP address. Either way, the end user will not be able to tell the sites are running on the same physical server.

Although both name-based and IP-based virtual hosts can be used within Mac OS X, this article will concentrate on the name-based method.[23] This method is recommended as it is more flexible and conserves scarce IP addresses.[24]


h4. Name-based Virtual Host


As previously mentioned, in order to use name-based virtual hosting, you must edit your Apache configuration file (httpd.conf) to include @<VirtualHost>@ blocks. The first step of this block is to use the @NameVirtualHost@ directive, after which you can create a @<VirtualHost>@ block for each different host you want to serve. Both the @NameVirtualHost@ and @<VirtualHost>@ directives should have the same argument: @*:80@, representing all IP addresses coming through port 80. Inside each @<VirtualHost>@ block, a @ServerName@ and @DocumentRoot@ directive is required to designate which host is served and where that host's content is stored in the filesystem.

As an example, if you wish to serve both _www.omninerdrules.com_ and _www.omninerdcantbebeat.com_ from your Mac, you would add the following to httpd.conf:[25]

bc..
NameVirtualHost *:80

<VirtualHost *:80>
ServerName www.omninerdrules.com
ServerAlias omninerdrules.com *.omninerdrules.com
DocumentRoot /www/omninerdrules
</VirtualHost>

<VirtualHost *:80>
ServerName www.omninerdcantbebeat.com
ServerAlias omninerdcantbebeat.com *.omninerdcantbebeat.com
DocumentRoot /www/omninerdcantbebeat.com
</VirtualHost>

p.

Notice the utility of the @ServerAlias@ directive, which allows access from more than one name, such as both _www.omninerdrules.com_ and _omninerdrules.com_. Of course, if you wish to direct multiple domains in this fashion, you must properly configure your DNS server to map _all_ of them to your IP address.

Additionally, you should note that order matters. When a request arrives, the server will first look for a matching @ServerName@/@ServerAlias@. If it finds one, it will use it, but if it does not, the first loaded virtual host will be used. Thus, how you actually store your virtual hosts matters. For example, if you store them all in your httpd.conf file, they will be loaded in the order you list them and the first one will become the default. However, if you have some lines like this in your httpd.conf:

bc..
NameVirtualHost *:80
# This line and folder exists as of Mac OS X 10.4
Include /private/etc/httpd/users/*.conf

p.

... then that's a location Apache will look for virtual hosts (and any other things that you want to store in individual files). All files that end in .conf in that directory will be appended to httpd.conf, as if their contents were at the end of http.conf's. The key to note is that these files will be loaded lexically according to the system environment, i.e., filenames starting with symbols first, numbers second, then alphabetically. So if you have a slew of files, an easy way to change the default is simply to change filennames, e.g., given mysite.conf and sweetsite.conf, mysite.conf loads first unless you rename them mysite.conf and !sweetsite.conf. Now !sweetsite.conf loads first and is the default.

You should note too that both the inline and include methods can coexist. Just think of the include as pasting the .conf contents wherever it occurs in the httpd.conf file. If it occurs after virtual hosts you list, then the first host will be the default. If it occurs before the virtual hosts you list, then the first file lexically will be loaded and thus the default.

In practice, storing virtual hosts in separate files is preferred. This allows you to create a stable httpd.conf file that you do not have to edit (and potentially corrupt). Should you have a site that you decide to stop serving or move to another server, all you need to do is delete or move one conf file and restart your server, i.e., no edits necessary. This greatly removes the chance for human error.


h4. Serve Files from a Non-Account Location


In addition to serving more than one site, you may also wish to allow access to your web files from more than one user account. By storing your website files in _Home_ -> _Sites_, as instructed in the simple, less flexible method, this will be impossible. Instead, place the files in any location not subordinate to a user's home folder. For example, I use _Macintosh HD_ -> _Library_ -> _Webserver_ -> _Documents_.[26]

Once you move your files, plug http://127.0.0.1 (every computer's IP address for itself) into a browser and see if it brings up your site. If it does, then your computer is correctly serving your site - at least in its own world. If the test is unsuccessful, you have one of two problems; either your files are in the incorrect location or your webserver is not properly turned on (both of which have been covered previously in the article, so it may be good to go back and review those steps).


h2. Maintain the Site


As mentioned previously, hosting your own website means _you and only you are responsible for server administration_. Usually, the bulk of your potential problems in this capacity will come from power and ISP outages.

Obviously, your Mac cannot serve your site if it does not have power, but a less obvious complication following a power outage to your residence is your router may re-assign LAN IP addresses. This means once your power comes back on, your router could assign your computer's previous LAN IP address to another entity on your home network and then will proceed to forward incoming traffic on port 80 there, instead of your computer.

Additionally, when your ISP service is out for any reason, the site will not be served. Not only can your ISP service block traffic on port 80, it may occasionally (and without notice) change your assigned WAN IP address. This means your domain would no longer be forwarded properly to your computer, and might even point to someone else's house!

Although dealing with these issues may seem like a potential nightmare, following a few simple steps in the event of an outage can usually resolve things fairly quickly and painlessly:
* _Check Your Webserver_ - As described earlier, insert http://127.0.0.1 into a browser and see if your computer is at least working in its own world. If not, pursue the potential issues previously indicated: your files in the incorrect location or your webserver not properly turned on.
* _Check Mac Service through Router 1_ - If you have a router, determine your Mac's LAN IP address and plug this into a browser on a computer on the same local network. If it successfully displays your site, then you know your computer is properly serving your site and this can be found through your router. (As described previously, your Mac's LAN IP address can be found using "ifconfig" from Terminal, or checking the _Sharing_ page in _System Preferences_.)
* _Check Mac Service through Router 2_ - If you have a router, confirm its WAN IP address and insert it into a browser from any computer. If it brings up your site, then your router _and_ computer are both correctly serving your site and you can skip to the _Check Registration Address_ step.
* _Check the Router Port 80 Forwarding_ - If the router's WAN IP address or your computer's LAN IP address does not work and yet your computer is good to go in its own world, then the issue is somewhere between the two. Check your router's _Application/Gaming_ page (likely http://192.168.1.1 again) to ensure it allows access on port 80 through to your Mac's LAN IP address, as previously described.
* _Check Registration Address_ - Access DNS control on your domain registrar's site and check if the IP address listed matches your WAN IP address (whether held by your router or your computer). If it does, then the domain is correctly forwarding to your router. If not, modify it to match your WAN IP address and allow the registrar at most 24 hours to update their system, after which you should contact their customer service department.

If all of these steps check out, then your problem may be outside the scope of this article. Consider reviewing the steps herein (just to be sure you did not miss anything) or contacting your ISP or domain registrar customer service department for further assistance.


h2.
Notes

fn1. "iWeb." _Apple.com_. Accessed January 2007 from "http://www.apple.com/ilife/iweb/":http://www.apple.com/ilife/iweb/. More information on the abilities of iWeb.

fn2. Pronounced "wizzy-wig," this acronym stands for "what you see is what you get." A WYSIWYG editor editor allows you to edit a site and see exactly how it will look, as opposed to just writing source code in a text file.

fn3. McBride, Mark. "Getting from A to B on the Internet: An Introduction to Routing". _OmniNerd_. 19 December 2004. Accessed January 2007 from "http://www.omninerd.com/2004/12/19/articles/25":http://www.omninerd.com/2004/12/19/articles/25.

fn4. "Internet Assigned Numbers Authority." _PORT NUMBERS_. 15 February 2007. Accessed February 2007 from "http://www.iana.org/assignments/port-numbers":http://www.iana.org/assignments/port-numbers.

fn5. "Steve Jobs: CEO: Apple." _Apple.com_. Accessed January 2007 from "http://www.apple.com/pr/bios/jobs.html":http://www.apple.com/pr/bios/jobs.html. Steve Jobs is the CEO of Apple as of the publication of this article.

fn6. "503 Service Unavailable". _Hypertext Transfer Protocol -- HTTP/1.1_, Section 10.5.4. _W3.org_. Accessed January 2007 from "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html":http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

fn7. "BASH Reference Manual." _GNU.org_. Accessed February 2007 from "http://www.gnu.org/software/bash/manual/bashref.html":http://www.gnu.org/software/bash/manual/bashref.html. The Born-Again SHell is what is behind the Terminal workings. Details on most everything can be found in this reference.

fn8. "Hostway Web Hosting Solutions." Hostway Corporation, 2007. Accessed February 2007 from "http://www.hostway.com/web-hosting/index.html":http://www.hostway.com/web-hosting/index.html. Hostway's prices for shared servers, for example, range from $13.95/month to $117.95/month.

fn9. "Dedicated Servers and Managed Dedicated Servers by Hostway Corporation." Hostway Corporation, 2007. Accessed February 2007 from "http://www.hostway.com/dedicated-servers/index.html":http://www.hostway.com/dedicated-servers/index.html. Hostway is one example, with their cheapest dedicated server set at $99/month and their most expensive listed dedicated server at $269/month. The option for multiple servers, of course, has the potential to increase this significantly.

fn10. "Domain Name Services." _IANA_. Accessed February 2007 from "http://www.iana.org/domain-names.htm":http://www.iana.org/domain-names.htm. Information on top-level domains and documentation.

fn11. "Whois." _Ugenie PCS & The Consumer Education Zone_, 2005. Accessed February 2007 from "http://www.cezwright.com/theWeb/whois.htm":http://www.cezwright.com/theWeb/whois.htm. More information on the "whois" command.

fn12. "Star your domain name search here." _GoDaddy.com_. Accessed January 2007 from "https://www.godaddy.com/gdshop/registrar/search.asp?ci=235":https://www.godaddy.com/gdshop/registrar/search.asp?ci=235.

fn13. "Register Your Domain." _Register.com_.

fn14. "Domain Names." _NetworkSolutions.com_. Accessed January 2007 from "http://www.networksolutions.com/domain-name-registration/index.jsp":http://www.networksolutions.com/domain-name-registration/index.jsp.

fn15. "Domain Name Registration." _aplus.net_. Accessed January 2007 from "http://domains.aplus.net/":http://domains.aplus.net/

fn16. Dynamic Netorking Service, _DynDns.com_, Accessed January 2007 from "http://www.dyndns.com/?gclid=CKy5nqjl_okCFQlQWAodukvqQw":http://www.dyndns.com/?gclid=CKy5nqjl_okCFQlQWAodukvqQw.

fn17. If there are two IP addresses listed, either one may be used.

fn18. While LAN IP addresses starting with 192.168 are the most common for home routers, there are other reserved networks. For example, if you use an Apple Airport router, the LAN IP address of your computer will be 10.0.0.x.

fn19. "Apache HTTP Server: Configuration Files." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/configuring.html":http://httpd.apache.org/docs/2.2/configuring.html. Documentation of configuration files for Apache Server 2.2.

fn20. Ibid., _Scope of Directives_. Speaking more generally, if you want to change configurations for only parts of the server (i.e., for only one website and not the other), you can place your directives within the @<Directory>@,@<DirectoryMatch>@, @<Files>@, @<FilesMatch>@, @<Location>@, and @<LocationMatch>@ sections. These sections limit the application of their enclosed directives to particular filesystem locations or URLs, and they can also be nested.

fn21. "Apache Virtual Host documentation." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/vhosts/":http://httpd.apache.org/docs/2.2/vhosts/. Documentation of Virtual Servers on Apache Server 2.2.

fn22. "Apache Core Features: <VirtualHost> Directive." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost":http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost. Details of the VirtualServer directive.

fn23. "Apache IP-based Virtual Host Support." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/vhosts/ip-based.html":http://httpd.apache.org/docs/2.2/vhosts/ip-based.html. Details on the IP-based method not covered in this article.

fn24. "Name-based Virtual Host Support." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/vhosts/name-based.html":http://httpd.apache.org/docs/2.2/vhosts/name-based.html. Apache lists a couple of reasons why you might consider using IP-based virtual hosting, including some incompatible ancient clients, SSL secure servers, and the bandwidth management techniques used by some operating systems and network equipment.

fn25. "VirtualHost Examples." _Apache.org_. Accessed February 2007 from "http://httpd.apache.org/docs/2.2/vhosts/examples.html":http://httpd.apache.org/docs/2.2/vhosts/examples.html. More virtual host examples.

fn26. Ibid.