DIY Webserver (Part 1 of 2) // VOID-STAR.NET

So on the weekend I got the brilliant idea (thanks to Lifehacker) to set up a publicly accessible webserver on Tavehd-Kyn. While I’ve installed Apache on pretty much every computer I’ve had since something like circa 2000, I’ve never had anything accessible publicly, mostly because I didn’t know how to get past issues like the router and the fact that — like pretty much everyone nowadays — I don’t have a static IP address. Little did I know that these things really aren’t the huge hurdles that they seem! And that setting up and serving a website from home is really, really piss easy!ⁱ

Here’s how you do it.

(Before we start, a caveat: Opening up your computer to the internet in this fashion is highly likely to be dangerous at least on some level. This isn’t a tutorial on how to set up a hardened webserver; if some noobs hack your box because you’ve done this, don’t say I didn’t warn you. I’d also totally not recommend you do this on Windows. Just so you know.)

Setting Up Your Local Environment

The first thing we’re going to do, even before we open ourselves up to the public, is get our own house in order. And we’re going to do this by learning how to set up virtual hosts in Apache. The reason we’re going to do this is because it allows us to have some separation between our ‘overall’ internal Apache install and the production site we’re ultimately going to be serving to the public.

1. Do a basic Apache install. I’m just going to assume you can manage this step on your own. OS X and Linux/Unix users are in luck; your OS probably comes with Apache already installed, if not necessarily configured. Sucked in, Windows users.
2. We’re going to set up one vhost to start with — the one that will be our public site — but know that you can use pretty much the same process to set up any number of vhosts. I have about six on TKyn, most of which are local development mirrors; otw.dev, void-star.dev and so forth. http://localhost on my system just goes to the default Apache install page; all my actual sites use vhosts.
3. Set up a location for your soon-to-be-public site. Mine is ~/Sites/!prod/public. The !prod folder lets me know this is a ‘production’ site as opposed to my local, development sites (which are all located in ~/Sites/!dev), but this is just an internal convention. Ultimately, you can pretty much put the root of your site anywhere you like (just make sure the permissions are correct).
4. Find your vhosts config file. If you’re running Apache2, this is likely to be a separate file called something like vhosts.conf; there’ll probably be a commented-out link to it in httpd.conf which will tell you where to find it (do a search for ‘vhost’ or ‘virtual hosts’). Uncomment the link while you’re here, then open the file it points to. If there doesn’t seem to be a separate file (probably because you’re running version 1-point-something Apache), you can enter the information in the next step straight into httpd.conf.
5. In your vhosts config file of choice, type (you can omit the first line if it’s already in the file somewhere):

   NameVirtualHost *:80
   <VirtualHost *:80>
     ServerAdmin you@your.com
     DocumentRoot "/path/to/your/site/www"
     ServerName public.prod
     #ServerAlias us.somewhere.com
   </VirtualHost>

6. And that’s all there is to it. Just make sure you’ve got the DocumentRoot directive pointing to the right location. Leave ServerAlias commented out for now; we’ll be using this when we’re finally ready to launch our site publicly. Finally, you can theoretically change the *:80 to lock down access to your vhost to certain IP addresses; the Apache manual has more info.
7. Restart Apache.
8. Now, check out http://public.prod in your browser. Don’t worry if it doesn’t work; actually I’d be shocked if it did. At the moment, Apache ‘knows’ where to find your site but your computer doesn’t. Like it always does when it encounters a domain name it doesn’t understand, it asks The Internet for the IP. But The Internet doesn’t know either, because public.prod is a local site. You’re going to have to tell your computer where your site is yourself.
9. Using your text editor of choice, locate and open your Hosts file. It’s likely you’ve never touched this before, ever; on Windows it’s probably in C:\Windows\system32\drivers\etchosts while on *NIX-style machines it’s /etc/hosts (remember to sudo).
10. At the end of this file (there’s probably only a couple of entries already here; if there are more, it may mean you have a spyware problem), add:

    127.0.0.1    public.prod

11. This tells your computer that the ‘domain name’ public.prod resolves to what’s known as the loopback address, which in network-speak means ‘this computer’.
12. Save your file. On some systems you may need to do something like flush the DNS cache to get these changes to take hold. Luckily, I do not have such a system (Vista and OS X 10.5).
13. Try http://public.prod again. If all is well, it should work! If it’s not resolving and your browser seems to be looking externally for resolution (usually it will try and dump you at http://www.public.prod.com), then there’s something wrong with your hosts file. If the name looks okay, but the site just isn’t displaying, it’s probably an Apache thing; check the syntax of your conf files using the command apachectl configtest.
14. What happens if you want to access your site from other machines on your local network? Well, unless you have DNS set up (you probably don’t), it’s editing host files again. You’ll need the local IP address of your webserver, and the host file of the machine you want to access it from. Then it’s just a matter of adding a entry similar to the one above, but with your server’s IP rather than the loopback address. Note that this will work precisely up until your networked machine changes IP address. Such is life.

And that’s it for the first part of this tutorial. While you wait for the second part — where we get into the actual meat of serving stuff to to the public — you can practice setting yourself up some more vhosts. Because they’re fun.

Until next time…

1. So long as you’re not a complete tard and manage to do something, like oh I dunno, type in sudo mv /var /usr/var. Just as, yanno, an example. ↩