jgiam.com

After getting burnt by my previous webhost, SolidInternet (previously Myacen), I am more cautious when it comes to webhosts. I was with VirtuallyDedicated since November last year, and several things led me to switch to another webhost recently. These are how not to run a webhosting company.

1. Promise first, don’t deliver.
   VirtuallyDedicated promised me a few times a control panel for my VPS. I didn’t really need a control panel. I just wanted it to be able to tell if my VPS was down by my own fault, or if the node was down, and to reboot my VPS if needed. Yet, I was promised again and again, and no control panel was delivered.
2. Don’t communicate with your customers. Don’t inform them of downtimes or system failures.
   Throughout the time I was with VirtuallyDedicated, my VPS experienced a few occasions of extended downtime. Extended being in the range of hours. The webhost didn’t bother to inform me nor offer any explanation. Unless I e-mailed them to ask about it. Over time, I just gave up and let the downtimes be, since they were rare.
3. Let your servers go down for really long, and not only not inform customers, but don’t reply to their e-mails.
   This last one took the cake. My VPS went down for over 24 hours. No word from the webhost. I submitted a support ticket, but did not receive a reply. I directly e-mailed the webhost, and over a day later, received a reply that the downtime was due to a hardware issue and that I didn’t receive a reply because “for some reason tickets were not reaching the support system”. No further explanation, not even why a hardware issue resulted in downtime of over a day.
   

After that, I simply had enough of VirtuallyDedicated. I decided that for my next webhost, I would go for an established company, one that actually had a real team of technical and support staff. Although there were some negative reviews, I am now on BurstNET. So far, so good. There was an incident where my VPS was performing very slow due to (I suspect) high disk I/O by some other user on the node. But since then, everything is working well and I’m happy with BurstNET.

I’m on Singtel, and my HTC HD2 gets preconfigured with four data networks: SingTel Streaming, SingTel MMS, SingTel WAP and SingTel Internet. If you go to “Settings” > “All Settings” > “Connections” > “Connections” > “Advanced” > “Select Networks”, you can see the list under the heading “Programs that automatically connect to the Internet should connect using:”.

One of the neat features of HTC Sense is the integration with Facebook, YouTube and Flickr. From the HTC Albums, you can easily upload photos to Facebook. If it works. Unfortunately for me, I couldn’t get that feature to work. Instead, I was prompted to login. After typing in my e-mail and password, I got the following “Login error”: “There has been a connection error while attempting to login”. I never figured this problem out until recently. Apparently this is an obscure problem. I came across a forum posting that mentioned trying to change the default data network, so I tried that. To my surprise, I hit the jackpot with “SingTel Streaming”. Once I selected that and tried to login, it worked! I changed the setting back to “SingTel Internet” (the default network), and was able to upload photos from HTC Albums!

I don’t really know the difference between the different Singtel data network settings, and it is quite strange that even though “SingTel Internet” (aka “IDEAS Internet”) is the default connection, HTC Sense is not able to login. This issue was also encountered on a HTC HD mini.

By the way, to manage your accounts in HTC Sense, go to “Settings” > “All Settings” > “Connections” > “Account Manager”, and you will see the login status of Facebook, YouTube and Twitter. Not particularly intuitive.

A side effect of changing the data network was that all of a sudden, my Opera browser could not surf the Internet. Internet Explorer and other applications were fine. Just Opera. Loading any page would immediately display the network error page.

Thanks to a thread from Mobinauts, I found that the solution is to change the following registry key from ’0′ to ’1′:

HKEY_LOCAL_MACHINE\Software\Opera\Prefs\Network
Conn Mgr Auto Detect Network = 1

Apparently Opera is configured to connect only through “SingTel WAP”. Unfortunately, something I did caused the connection to fail. By changing the registry, Opera will use an available data network setting, in this case, “SingTel Internet”.

Perhaps these are more accurately telco (Singtel) quirks, rather than HTC Sense?

Recently, I was using a laptop with Ubuntu installed. Anticipating that I might not have Wi-fi and needed to tether my Windows Mobile phone for Internet, I installed SynCE. I was in a rush and didn’t have time to really test it other than loading Google (isn’t that the “standard” test for Internet connectivity now? ) As it turned out, the place I went to did have Wi-fi access, but I hadn’t installed the Wi-fi drivers for the laptop. To install the Wi-fi drivers, I would need to tether my phone.

Unfortunately I was facing a very strange situation. When I tethered my phone, the laptop did have Internet. But I couldn’t load anything other than the Google home page. I could ping, and I could do nslookup. I could wget the Google homepage consistently. But I couldn’t search or load any other pages. apt-get refused to work as well. I tried to FTP, and discovered that the connection would choke if I tried to do a directory listing of a large directory.

After much trying and Googling, I wondered if it had anything to do with the MTU. I Googled, and came across a forum post that suggested changing the MTU to 1000. I tried it, and… it worked!

I’m now happily tethering my Windows Mobile 6.1 phone with Ubuntu 9.10, using just SynCE + MTU 1000.

128MB wasn’t enough for me. My VPS struggled to serve my sites, and too many simultaneous connections caused the server to swap wildly, bringing up CPU and disk usage. My VPS got suspended once for over usage of resources. Despite more tweaking, the server was still too slow for my liking.

I wanted to upgrade to a plan with more RAM, but the plans on RapidXen were beyond my budget. I looked around and found VirtuallyDedicated. Their 640MB (with 1.25GB swap) was still reasonably affordable for me, and I decided to take that plan. I did not regret my decision. The extra RAM really does help, and my sites load faster, and handle more connections. Even compiling PHP for LiteSpeed took a fraction of the time. Network connectivity is much better, especially in terms of bandwidth. A tip if you’re buying hosting in another country: make sure you do latency and bandwidth tests. Not all datacentres are made equal. 10-20KB/s is really bad.

So far, so good with this VPS. My only issue right now is the lack of a control panel (for Xen VPSes), which means things like reboots have to be requested and done by staff. They keep telling me a control panel is launching soon, but I have not received any word.

I’ve seen the painful lessons many times: lazy website owners thinking their webhost would last forever, and neglecting to save their own backups. But really, you learn a lesson the best when you actually feel the pain. And I sure did.

To prevent this, I decided to automatically, and regularly backup my VPS and store them on my computer. I searched Google a bit, and found two typical approaches: a simple shell script, or a full-fledged backup solution. I decided that I didn’t need something like Amanda or Bacula. I didn’t feel too inclined to messing with scripts though. However, I found this nifty tutorial to backup web server files and MySQL databases. The tutorial came complete with a script generator, which was really handy.

I made some changes to the generated script though:

1. I prefer the yyyy-mm-dd date format for easier (and natural) file name sorting. I also changed the timestamp of the MySQL dumps to match the file dump timestamp format. 
2. Because I’m not running large websites, I decided to change the script so that the full backup  is only run once a month instead of once a week, to save on resources.

With this script running, I should not have to encounter another situation where I lose months of data. Well, unless the backups stop running without me realising.