Tinsology

This guide will show you how to create a domain on your local machine and configure apache to route traffic to that domain to a particular directory. I’ll describe how to do this using Windows, but the process should be very similar in a linux environment.

The first step is to choose a domain name. When choosing a domain you should remember two things: It will only exist on your local machine and it will override an already existing domain. The latter is probably the most important; choosing google.com as the domain will prevent you from accessing google.com. The simplest way to avoid overriding a domain is to leave off the TLD. Personally I use subdomains of localhost. For example, if I had a project Foo that I wanted to create a domain for I’d choose foo.localhost.

The next step is to associate the domain with your loopback address (almost always 127.0.0.1 the IPv6 version is ::1). To do this you need to locate and edit your hosts file. In Windows it should be located in the directory C:\Windows\System32\drivers\etc If you are using Vista or 7 you won’t be able to edit it with Administrative Privileges. You’ll need to run whatever application you are using to edit it (notepad will do) as an administrator. To do so in notepad follow these steps:

• In your Start menu navigate to All Programs > Accessories
• Locate and right-click Notepad
• Click Run as administrator
• Once in Notepad select File > Open...
• Navigate to C:\Windows\System32\drivers\etc and select the file hosts

Your hosts file should look something like this:

127.0.0.1 localhost
::1 localhost


If the domain you chose if foo.localhost then just add the entry:

127.0.0.1 foo.localhost


After you save the file the domain foo.localhost should route to 127.0.01. For now it is effectively identical to just using localhost.

It is up to apache to route traffic to foo.localhost to the right location. This process may vary depending on your configuration, but at this point it is identical to configuring a virtual domain on your server. The first step is to create a virtual host. Locate your httpd.conf file, it should be in the conf directory wherever apache is installed. If you haven’t already set up a virtual host you’ll need to add the line:

NameVirtualHost *

You’ll then need to setup a virtual host for each domain, here is an example:

NameVirtualHost *

<VirtualHost *>
    ServerAdmin webmaster@foo.localhost
    DocumentRoot "C:\srv\foo\public-html"
    ServerName foo.localhost
</VirtualHost>
<VirtualHost *>
    ServerAdmin webmaster@localhost
    DocumentRoot "C:\srv\public-html"
    ServerName localhost
</VirtualHost>

If you entered your new domain into your browser now you may get a 503 error (forbidden). To fix this problem you’ll need to tell apache to allow access to directory you specified in the DocumentRoot entry in your virtual host:

<Directory "C:/srv">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Thats it! Your domain should be setup and ready to use.

I have been using various shared hosting providers for several years now. In that time I have never renewed a hosting plan with any single provider; instead moving from one to another for various reasons. Before I go any further let me describe my needs with regard to hosting:

1. Obviously one of my needs is to host this blog. I don’t get a huge amount of visitors (150 on an average day) so this isn’t much to ask for.
2. I have a few other sites that are in development, most of them will never see the light of day. Their impact on server load is pretty much negligible.
3. I develop PHP scripts on my local windows machine, but I often upload and run them on my host to make sure they’ll work in a linux production server.
4. If I develop something for a client I usually demo it on my host.

That’s it. Nothing is mission critical and I don’t get a lot of traffic. This being the case you may be wondering why I move from host to host. After all, my needs aren’t very demanding. To be honest one of the reasons is that a renewal is almost always more expensive than switching to a new provider. You don’t have to look hard to find a discount, the catch is you have to pay full price when it is time to renew.  I wouldn’t mind paying a bit more though, if it weren’t for one thing: there is almost always something that I find dissatisfying: poor customer service, lack of features, lack of freedom, etc.

One thing that up until my last host was never an issue was server performance. As I mentioned my needs are fairly small, and I don’t mind a little downtime. The fact that I can pay a company money and not have them meet my relatively small amount of demand has scared me away from shared hosting forever. This is where the horror story portion of this article begins:

Up until my recent host switch I had been hosting with a company called MochaHost. The reason I chose them in the first place was related to one of my complaints about a previous host: lack of features. On paper MochaHost had everything I needed, and like virtually every shared hosting provider they had an uptime guarantee. In general these guarantees have a ton of loopholes and are not to be trusted, but in this particular case the guarantee was an outright lie. The quality of server I experienced was beyond terrible. I experienced frequent downtime usually lasting only for a short period (but long enough to be extremely annoying when you are trying to get something done). Half the time when my service wasn’t down it was very slow, often to the point where you might as well consider it to be downtime. This graph illustrates my point:

The graph is from Google Webmaster Tools and shows the amount of time spent download a page. It should be fairly easy to tell at which point I switched hosts. The site performance tool in Webmaster Tools also consistently rated this site as being slower than 90+ percent of other sites prior to the switch.

When I reported this downtime usually the response completely ignored the underlying issue. Generally some person would reply that it seems to be working now, without addressing the problem that IT WAS down and that this wasn’t the first time. The only thing good I can say about MochaHost was that their customer service was very responsive and helpful, provided they weren’t dodging questions about uptime and performance.

MochaHost was only the worst part of what was ultimately a bad trip through shared hosting land. In spite of not needing much in terms of performance, I was constantly disappointed with the features and level of flexibility of shared hosting. This led me to switch to VPS (Virtual Private Server). In case you are unaware, a VPS is somewhere between a shared host and a dedicated server. A server is divided between multiple user, but this is transparent to the user; the environment is effectively the same as that of a dedicated server.

This comes at a cost however, I’m paying twice as much as I did for shared hosting. What I get in exchange, however, is well worth it. In addition to getting better performance than you could hope for in a shared host, I have absolute freedom: I have root access and I can configure my server anyway I please, and I can install which ever software I choose. I was even given the choice of server location (I chose one in California). Of course the downside to absolute freedom is absolute freedom: I’m free to screw up anything I can and when I do there is no one to hold my hand. Having had plenty of experience screwing up my own machine I think I’m up to the challenge.

Another benefit of VPS is the dramatic decline in bullshit. Some shared hosts give you unlimited everything, which is bullshit for ‘we’ll decide when you’ve used too much bandwidth or storage’. Still others promise you more than they would ever let you use. The caps on my bandwidth and storage are both real and reasonable. In case you’re interested (Warning: Imminent blatant affiliate link drop) I’m using Linode. I paid about $220 for a year of service and so far I couldn’t be happier. A word of caution though: If you don’t know how to configure and manage a server, or don’t want to take the time and effort to learn, it may not be for you.

Update: A perfect example of what I mean by being free to screw up anything I can: When I was configuring this site in apache I forgot to set the server alias www.tinsology.net for the domain tinsology.net. For whatever reason all of the traffic from www.tinsology.net was getting redirected to a completely different domain: errordatabase.info, which is another site of mine hosted on the same server.

I have an old single core laptop that doesn’t get a whole lot of use anymore, partially because it is dated (purchased in 2006) and partially I’ve never really adapted to using a laptop as a general purpose computer. Increasingly, however, I find myself in need of a laptop either when I want to get some work done when I’m away from home, or when I need to take my work with me. This being the case I decided to re-purpose my old laptop as a dedicated development machine.

I could have just put a fresh copy of Windows XP on it and gone from there, but given the circumstances that might not have been the best route. All I needed to run was apache, MySQL, PHP, subversion, and something to write code in. Clearly something more lightweight than Windows could accomplish this. In addition to this I wanted something that would mirror my production server, which is running ubuntu. I ended up installing lubuntu, a lightweight distribution based on ubuntu (if you plan on trying lubuntu bear in mind that it is still in beta). Other than some very minor bugs, lubuntu seems to be perfect for my needs: I could configure it to be almost identical to my production server, it is easy on resources (even on my ancient laptop), and I immediately noticed a big improvement with regard to battery life.

During my recent host switch I ran into a bit of a problem. After I had moved my database and content to the new server and changed the name servers, requests were still be directed toward my old server. The reason for this is that my ISP had not yet updated their DNS record cache thereby causing requests to be directed to the old server. It typically takes several days for a domain to fully propagate; the amount of time it takes for changes to take effect for an individual depends on how often their ISP updates the DNS records. There is, however, a simple way to avoid having to wait for DNS propagation.

(Note that it may be sufficient just to clear your local DNS cache using the command ipconfig /flushdns)

When resolving a domain a host will usually check for an IP address in its local DNS record first. If it cannot find an address it will pass the request on to the DNS server. The problem occurs when neither the local dns record nor the DNS servers’ records are up-to-date. In most cases the DNS servers’ records are out of our hands so the solution is to manually tell the local machine the IP address for a given domain. You can do this by editing the hosts file located in C:\Windows\System32\drivers\etc (the location should be the same for Windows XP/Vista/7). You should edit the file using notepad with administrative privileges. You can do so by selecting your Start Menu -> Accessories and then right clicking Notepad and selecting Run as administrator (This is how I did it using Windows 7).

You can now add the entries for your domain. Each entry should be on its own line and specify an IP address followed by a domain name:

123.45.67.89 mydomain.com
123.45.67.89 www.mydomain.com

You domain should now resolve to the correct host. Note that this does not in any way effect DNS propagation; users who’s DNS servers have not updated their records will still be directed to the old server. You should also note that this method assumes a static IP address; if at some point the IP address of your web server changes the domain will not resolve correctly and the entries will have to be updated or changed. This shouldn’t be much of a problem considering that the entries can (and probably should) be removed once your ISP has updated their DNS records.