The Saga of the New Web Hosting Provider

As I mentioned a while back, I recently switched to a new web hosting provider, Media Temple. I wanted to provide a bit more detail as to why.

About a month-and-a-half ago I was uploading some new content to my personal site, which hosts a fair amount of video and audio for download, on my old web hosting provider, Web Hosting Buzz, when suddenly I was unable to connect to my site, either via FTP or the web. This had happened before, and I was starting to get concerned, so I decided to start a Live Chat session with tech support. After some poking around, the technician was able to determine that my site was available to everyone but me, the owner, and that my uploads had resulted in the blocking of my IP address. Seems they only allow a certain number of connections, and my FTP client (the venerable Yummy FTP) was set beyond their threshold. The tech person I was chatting with helpfully advised me to set the number of concurrent sessions to two or less. I set mine to one. He unblocked my IP address and all was again well with the universe.

Cut to the next day: Wash, rinse, repeat. Same problem, only this time the tech online told me that I was in violation of their acceptable usage policy, and directed me to the Disk Usage Provision section of that policy:

"90% or more of your content on your website must be linked from an HTML or similarly coded web page where all content is freely available to the public. Your website consists of web pages of a standard design, essentially HTML based text and graphics. Downloadable files, media, streaming content or any file which consumes more than 500kb of space must not exceed 10% of your total used disk quota." [Emphasis added]

Yikes!

This time the technician informed me that I had too many files that exceeded 500kb, and that I would need to remove all media that was in violation of this policy. Funny thing was, I'd been in violation for months. Why had no one informed me? Why was this suddenly a problem? I asked the tech. He said it had been their mistake, but that it was my fault for not having read the policy.

Ah, customer service! Ya gotta love it!

In fact, I had read the policy, but I'd kinda glossed over the whole, "You can't actually, feasibly use the total amount of disk space we claim to give you," part. I mean, really. Who would think that a company would offer you 1250GB of storage and then make it practically impossible to use said storage?

Call me naive.

So, after explaining to the technician that their "mistake" had cost me a great deal of time and effort, I asked him how I was to remove the content if my IP was still blocked. He told me he would unblock the IP for 24 hours if I promised to remove the files that violated the policy. During this conversation there was very much a sense that my site was being held hostage, so I didn't want to say anything, but it was at that point that I had decided to switch to a new web hosting provider as soon as I had a backup of my site in hand.

And by gum, that's just what I did.

I'm currently hosting this site, as well as a few others, on a Media Temple (gs) Grid-Service account. Media Temple is famed for their customer service, which is a big deal considering how rudely I was treated over at WHB. But I've yet to even need MT's customer service. This is mostly due to their phenomenal online KnowledgeBase, which has managed to answer my every question, and believe me, I've had some doozies. Uptime and speed have been acceptable; I've had decent speed — faster than WHB by a smidge perhaps — and only the occasional, short-lived drop-outs, which seems to be about par for the course with consumer-level services. But perhaps best of all, I can't even find MT's acceptable usage policy. They don't seem to place any restrictions on what you can do with your disk space. Sure, there are bandwidth and capacity limits, and the capacity limit is smaller than I had with WHB. But at least now I have a chance of actually hitting it.

It's only been a month. A little early, I realize, to fully endorse Media Temple. But so far, so good.

Today I canceled my Web Hosting Buzz account. Nothing like the taste of sweet, sweet consumer revenge. I just have to wonder, when will companies realize that consumers can and do exercise their freedom of choice? It just doesn't ever pay to treat customers — or, hell, let's call them what they are, people — like shit. There's little I take greater pleasure in than dumping a company that does so.

UPDATE:

Lots of great comments on this post so far. In particular, one reader points out that Media Temple does have a usage policy (I figured!) on their legal page (not in their support pages or KnowledgeBase, which is where I was looking). Of particular interest, said reader points to the following passage:

"75% of customer’s content files stored on Provider’s server must have associated HTML, or PHP files inside the account linking to the content stored on that account."

So, yes, there are some restrictions on the sorts of files that can be stored in your Media Temple account. But I understand this rule. It's there to prevent you from simply using the allotted disk space as storage. Media Temple wants you to use the space to serve websites, not as an online storage repository. Web Hosting Buzz has a similar clause in their policy. But, to be clear, the Web Hosting Buzz policy goes an additional step in limiting the size of the files I can put in my account to a measly 500kb, regardless of whether or not they are linked via HTML, PHP or the like. (For the record, 10% of your files can exceed this limit.) The way I read this is that you can only use your WHB account for serving basic HTML/PHP sites that use mainly text and/or image files, and not particularly large image files at that. And that'd be fine if it were clear from the start, in which case I never would have used them. But, while this policy is buried in an otherwise seemingly reasonable usage policy, WHB boastfully offers 1250GBs of storage on their main page. This is what you see most prominently when you sign up for their service. It's plastered all over their site. But when taking the usage policy into account, it becomes clear that that 1250GBs is pretty impossible to actually use; it would require hundreds of thousands of HTML and image files, more than even the largest websites use. A 1250GB quota suggests, to me anyway, that you can use this space to host decent sized media files like audio and video. But this is clearly not the case. So, yes, I find the offer of a virtually unreachable 1250GB quota misleading. Is WHB intentionally tricking people into purchasing their service in order to make a fast buck? I don't know. And it's very possible that I am misunderstanding something. But my experience certainly made me feel cheated. The second technician I dealt with was neither apologetic about the situation (which was referred to by said technician as a "mistake" on their part for not having caught the overage) nor helpful about a resolution to the problem. I was simply told to remove the problematic files (which would render my website essentially useless) or have my account suspended.

Emotions aside, ultimately the 500kb file size limit is, quite simply, a deal breaker for me. There's no way I can run my other sites with such a restriction in place. So, whether or not WHB is misleading folks, I have no choice but to make changes to my service. Had the WHB tech been a bit more helpful about the situation, a bit more symapthetic, I might have considered upgrading my WHB service to one that could accomodate my needs. Unfortunatley, that's not how things played out.

Thankfully, Media Temple does not seem to have the same sort of restrictions in their usage policy (and, in what is probably a good sign, they do not offer nearly as much disk space, though it's certainly more than enough). But, as I said, the jury's still out. And I'll take, as always, a wait-and-see approach. If I encounter problems, I will take my business elsewhere. But I'm hopeful that, at least for a while, I've found a new home in Media Temple.

UPDATE 2:

I've edited the post for clarity.

Google Calendar Sync Now Official

Just this past week, Google made their CalDAV support — and, specifically, their support for iCal and other desktop calendar clients — official. A while back I reported on the beta version of this feature, and I was pleasantly surprised to find that the beta had actually ended.

Along with offical support, Google is now supplying a configuration utility, which simplifies the setup of iCal, thus addressing my major beef with the service.

Great news.

Taking My Own Medicine

I've long extolled the virtues of network-based home accounts, at least in some situations. And, of course, I've written copiously on how to implement such a thing in a lab setting. What I've never really done in any meaningful way, or for any length of time, is to use network home accounts myself. Until now. There are certainly situations in which local home accounts are preferable. Generally speaking, they tend to be the way to go if you can swing it. They're usually a bit more responsive, and of course they don't rely on a functioning network, proper network settings, authentication servers and home account servers to work. They are the de facto, the default, and they're what most people are used to. And if your users ever only use their one computer, local home accounts are likely to be all you'll ever need.

But in environments that involve numerous shared (network) resources, or in which people are moving from computer to computer on a regular basis and need some semblance of consistency among machines, a centrally-located, accessible-from-everywhere home account can be a real blessing. In order to sell this system at my new job (on the Mac side — Linux was already using network homes), I needed to prove its reliability, so I threw myself on the grenade, as it were: I started using a networked home account. And you know what? I really like it.

There are, as alluded, certain inconveniences with such a scheme. For one, login tends to be a bit slower as the system needs additional time to locate and coordinate with the necessary network resources. Also, there is no Trash folder for a network home, and deleting files is immediate on a Mac when done over the network. So every time I try to throw something away I get this alert:

And the file is deleted for good. This is probably the worst part of the networked home. No Trash. But the advantages are so great that I plan to stick with my networked home, despite the minor annoyances.

At some point not too long ago I decided that the reliability test had been a success, and that I could finally revert back to my local home account. So I synced everything back to the local drive, and changed my home account location on the server (I use server-based authentication either way), and logged in. I worked locally for a while, and then I needed to do something on a Linux machine. I logged into that machine — which uses networked home accounts — and got my old, outdated, network home. And that's when I realized: you can't have it both ways. You either need to go local-only, in which case you need to really only use one machine, or you need to go networked. Otherwise your data's all out of sync. And that's way worse than any network dependencies or minor performance hits. So I immediately switched back to my networked home. And I plan to stay there.

And speaking of having it both ways, I suppose it is possible. At my old job I had a local account on my office computer and a networked account everywhere else. This was okay, but created all sorts of problems — particularly permissions problems — any time I wanted to share data with, uh, myself. Long story short, it was a real pain in the ass. Doable, but kinda sucky. Avoid if possible.

I have to say, since committing to my network home account, I've been pretty darned happy with it. Most times I'm completely unaware that I'm even on the network. And it's great to have the same environment across every machine in the lab. It's also great to finally be able to say definitively that this approach is not only valid, but actually pretty great in instances in which it's appropriate.

Go me!

Abandonment Issues

Because of the recent departure of Apple's Senior VP of Enterprise Sales, John C. Welch claims that "the Mac IT crowd" is wondering if Apple is abandoning the Enterprise. He then goes on to say that this depends on whether or not you thought "Apple was, or wanted to be, an 'enterprise' company." Um... No it doesn't...

Mr. Welch raises some good points in his article, the main premise of which is that Apple is, indeed, not an enterprise company, an idea I fully agree with. But the fact is that it's certainly possible to worry that Apple will abandon the enterprise without thinking of them as an enterprise company. And that's because Apple makes enterprise products that some of us have come to rely on.

I don't think many IT folk — Mac or otherwise — think of Apple as an enterprise company. In fact, I'd venture to say that we worry that Apple will abandon us because we know know full well that Apple is not such a company at heart, and that their connections to enterprise are tenuous at best. But some of us do actually appreciate the design and ease-of-use of their server products. In my case, I've come to rely fairly heavily on Mac OS X Server for cross-platform authentication, among other things. I get flack for this sometimes, but the plain fact is that no one has integrated authentication for Mac, Windows and Linux in one spot in such an easy-to-build package as Mac OS X Server. Could I do this with a Windows server? Sure. Could I do it on Linux? Yes, of course I could. But I'll spend twice as long building it, and twice as much time maintaining it, when Mac OS X Server does it out of the box with ease and grace. I suppose I could punch myself in the face over and over again as well. Do I want to? Not particularly.

I often worry that Apple will someday leave the server market altogether. I sometimes even worry that Apple will stop building high-end workstations. Hell, who knows? Maybe Apple will stop selling computers one day. But I don't worry about these things because I think Apple is one kind of company or another. I worry about them because these are products that I enjoy using on a daily basis, and I would like to keep using them for as long as they're the best tool for the job.

Secondary DNS in Leopard

I covered secondary DNS configuration in Tiger (10.4) Server a while back. And while the buttons have moved around a bit, most of those instructions apply to Leopard as well. Leopard does have one fairly cool new addition worth mentioning, though: forwarders. Generally I'm setting up secondary DNS for internal networks, and generally those internal DNS servers  serve DNS only for the internal networks. Everything outside the internal network is handled by external DNS servers (or by DNS servers that sit on a network of which we are a subdomain), and our internal DNS servers need to know who those server are. These external servers are called forwarders, in DNS parlance. They are the first stop for all DNS outside your local network. And you can now set them on your secondary DNS server in the Leopard Server Admin application.

To get to the settings, navigate to the "Settings" tab under the DNS service. In the bottom-most pane of the window you will see a box labeled "Forwarder IP Addresses:" Click the plus sign to add a server to the list, then type in an IP address. Typically you will add two addresses, one for the primary external DNS server and one for the secondary. These will often be your ISP's DNS servers, though if you're on a subdomain of a larger network you'll use the DNS servers for that network's domain (i.e. the subdomain systemsboy.com.mail will use the DNS servers for the domain systemsboy.com). Once you've entered and saved the settings, restart your DNS service and you're off to the races.

Requests for internal network resources will still be handled by your internal DNS server, but now external requests for things like "google.com" will be passed to the appropriate external DNS server. Even if your secondary has to take over DNS duties for a long period of time, you'll still be able to properly reach the Big Bad Internet without having to use cached or stale settings.

This is a very handy addition to the DNS configuration GUI in Server Admin.