I moved off of hostgator.com last week on Labor Day. I chose dreamhost.com as the next hosting facility. I’m really going to try and stay for at least a year in one facility, even though moving only takes a couple of hours now, plus time for DNS to point to the new nameservers.

Dreamhost has a single plan, to which you can add. So we start with the basic plan for one year ($9.95/month, plus a wordpress discount, roughly $110), add two single IPs (not guaranteed to stay the SAME ip, but configured as unique to the site, $3.95/month for a year, roughly $44 each per year), configure SSL (no charge). And I have exactly what I would hope to have. At a cost of $198/year. $16.50/month. That’s a bit more than I would have hoped, but workable.

hostgator would have charged either $28.95/month (one reseller hosting plan, plus two ip addresses at $2/month each, and that doesn’t count the two SSL certs at $10/each install fee…), or $23.90/month (two separate accounts, $9.95/each, plus IP for each, $2/month…), to achieve this.

hostgator technical support was much more formal, and with the Live Chat feature, very responsive. At least they were up until I refused to solve a problem by upgrading my plan. They were constrained by marketing and administrative limits, but technically not bad.

dreamhost’s support ticketing system really doesn’t ticket. It assigns a number to each individual communication to support rather than gathering them into a single issue. I don’t like it. For me as a user, it is too informal, too easy to fail to get a quick communication response back. It may do some grouping that users can’t see internally, not sure.

The first night in the facility the (new) server I was on ran out of root filesystem space and needed to be rebooted to reconfigure space and resolve. This caused issues with WordPress from the admin point of view, but except for downtime during the reboot was likely invisible to traffic to the site.

When dougmunsinger.com was moved to an individual IP address, the apache config was missed and I got the “It works!” default apache testing page – five minutes after sending in a support request it was corrected. But there was no communication back from support on this issue, they just fixed it.

My overall impression is the support guys are linux-oriented, they run Debian Etch as the current version, and if the site stays accessible, reasonably fast and accumulates uptime, I can live with this situation. I am currently having an argument with support over some settings in apache that I believe are non-optimum. Discussion might be more accurate. Not critical, I have at least a temporary workaround in place, but, the server is tuned incorrectly at a default setting… IMHO.

I am watching my domain registrar in France, though – they have been Beta-testing a xen hosting solution, which if it pans out and remains reasonable in cost, would give me full control over the (virtual)s server, and that, frankly, would be ideal.

In the support form for submission to dreamhost.com, there is a drop down to indicate your expertise level as a user:

• “Please explain everything to me very carefully”
• “I do know some stuff but please don’t assume too much”
• “Overall I know my stuff, but I’m a little shaky in this area”
• “I have a good understanding of this stuff”
• “Not to be rude, but I probably know more about this than you”

That last is most likely to be true at the first level and even second level support people reading the support message from me. I don’t necessarily think it would be true at third level support – there should be testing data, network data, tcpdump, etc., traffic monitoring, OS configuration data, behavior on the hardware they run on, knowledge of the network design – all of that argues that at third level I do not know more than they do about their OS and system behaviors.

Having root on the server, even a virtual server, and better control of the whole setup would be more comfortable for me than blind user land. We’ll see where the beta testing at Gandi goes…

— dsm

I moved my websites off my home servers several weeks ago. I have Verizon FIOS and for some reason they finally got around to adding port 443 to their blocked ports, outgoing. They had always blocked port 80.

I chose hostgator.com to host the sites. I did some research, most of the reviews of the company were laudable. One reviewer indicated that after three months hostgator had insisted he needed to move to a dedicated server because of the “load he was generating”. He complained in the review that that was not the case, that hostgator was upselling. I didn’t understand the term…

I think I do now. But I’m still shocked at how fast the service went downhill. Three days ago I was still reasonably ok with hosting with hostgator. Now, late Tuesday evening, DNS for my domains points to a new hosting facility’s nameservers. And I’m writing this.

I did two things correctly. I kept current backups of everything hosted. And I did not transfer any domains to the hosting facility. My domain registrar is in Europe – I’ve been using them for almost 8 years, they’ve been outstanding to work with.

If your domain is registered outside of your hosting facility, redirecting traffic is just change the DNS nameserver delegation. You don’t even have to tell the old hosting company there is a change until after the DNS has propagated.

Here’s the thing – hostgator monitors the whois record. At one point in this whole saga I determined I might have part of a solution if I re-pointed DNS to everydns.net, and then used a web redirect to fix hostgator’s bogus https redirect – it didn’t work, but almost immediately this became a subject in the support tickets I had opened with hostgator. It would make sense – issues would definitely stem from nameserver re-pointing. But it also is a damn good warning of which customers are leaving the fold.

I purchased one year’s hosting at $9.95 per month. I added $2/month for a dedicated IP address, a requirement for private SSL. I checked the shared SSL – it only served directories from within ~/public_html. I wanted the websites isolated from each other, outside of each other’s document root, so that didn’t seem to be the right solution. Initially (this is important) addressing any query to a domain at https resulted in a timeout and that SSL connection being unavailable. Proper behavior – I wasn’t yet set up for that, so it should not be present.

Once nameservers had propagated and I could access the site, I asked that they enable private SSL using my existing SSL cert. They would – at a $10 charge to install the cert. OK, so be it. I authorized that. (Cha-ching…). They enabled the SSL. It worked… Sort of.

What it did was allow private SSL access to the primary domain. And no SSL access anywhere else on the hosted site – subdomains, add-on domains, nothing was accessible by either the private SSL or the shared SSL. Any SSL query would redirect to the primary domain home page at https:. I figured OK, they put in a blanket redirect, I’ll open a ticket in a bit and work that out.

Three days ago I opened the ticket. And over the Labor Day weekend, I pursued a solution. Sigh.

I described the situation. I had SSL access to the primary domain, but could no longer access subdomains or add-on domains via SSL – all I wanted was for the primary domain to be full securable, and to be able to access the WordPress administrative functions for two add-on domains via SSL, and to access password-protected subdomains with SSL. Neither of these is public, shared SSL would have been acceptable.

I was initially told that this could be done by moving the subdomain out from the dedicated IP address and back to the shared IP.

Good morning,

This issue is being caused because the certificate is setup to use primarydomain.com so when you access port 443(https) via that IP you are sent to that website. What you will need to do is have the other domain https://dougmunsinger.com taken off of the dedicated IP and then you can use the shared SSL. Would you like us to do this?

Thanks,

I asked if that would solve the subdomain access as well…

Would that also solve access to subdomains within primarydomain.com? Or would those subdomains need to go off the primary domain and onto dougmunsinger.com as the domain (which is possible, I think, but not a perfect solution)

– doug

And I got a reasonable response. I don’t think sales was on the line yet at this point.

Hi Doug,

All the domains you wish to use the shared ssl will need to be moved off of that dedicated ip. Let us know how you would like to proceed.

Thanks!

I was then told I couldn’t do that – hell, let me quote the reply:

Good afternoon,

This cannot be done as it would conflict with the VHost, as the shared IP is different than your dedicated IP and your IP is hard set in the zone file.

Thanks,

Interesting response. True, too. But it is a limitation of their setup and procedure, not impossible. They do a funky

add-on-domain.primarydomain.com

redirected in apache to

add-on-domain.com

or maybe that’s reversed. At hostgator you have to guess what the DNS records actually in place are. And you can’t see server-level redirects or address re-writes at all…
– so once the dedicated IP is assigned you are screwed. However – that’s process. Not a true limitation.

By this time the system had opened two tickets – not sure how. Both on the same issue, and until the very end of the thread they couldn’t seem to combine them… Eventually I got:

“Hi Doug,

The issue here is that you only have one account as a shared client. In order for these domains to be moved off of the dedicated IP they will have to have their own account. Were you thinking about moving up to a reseller package? You could then create separate accounts for each of these. Please let us know if you have any questions or if I a not understanding what you want to do correctly.”

So actually, I could have the solution if I paid more money. After several clarifying emails, where I insisted that a reseller account was out of the question, and that this functionality was simple and should just be fixed to work, back and forth, we have this response:

“Doug,

I do see what you are trying to do, and the only way this will work properly now that i see that you have a shared account is that you upgrade to a reseller. Let me try and explain why.

On a shared account, you can only have the primary domain with an SSL. What you would need to do is get a reseller account, and then setup you non SSL subdomains as accounts of their own.

If you have any questions we’ll be glad to answer them.

Thank you,k”

So – I’m paying more at this point, for a dedicated IP address and private SSL to the primary domain – for less functionality?

I asked that they revert the dedicated IP back to a shared IP and re-enable shared SSL. They did, as of Sunday evening late.

They also redirected https traffic obnoxiously. As soon as this was reverted, instead of https:// URL’s either redirected to http:// (appropriate) or simply unreachable (appropriate) – they were redirected to some search site.

As soon as I refused the upsell to a reseller account (Cha-ching – that literally is double – $25/month ($24.95, but who’s actually counting 5 cents at this point?)), responsiveness dropped to pretty much zero. Instead of a one hour response, which had been usual, I got overnight. Maybe. And the responses stopped actually addressing the issues.

I complained bitterly about this redirect on Monday, and got no response. I did get:

Hello,

It appears that the domain has just had its nameservers changed. The WHOIS information shows that it was changed today and was pointing previously to dns.gandi.net. It is now pointed to

NS1065.HOSTGATOR.COM

NS1066.HOSTGATOR.COM

It normally takes 48 – 72 hour for the nameservers to completely propagate, allowing you to view your site using the domain name around the world. You might not be able to use the domain name to view your site until after that time.

If there is anything else we can help you with do not hesitate to ask.

Thank you,

Hmmm. I wasn’t aware that whois actually gave a history of nameservers. Actually, checking the command, it does not. That suggests they monitor the command at hostgator for changes. And since he had the history, they save the data for at least their tech support guys, if not their salespeople. At the point in time I changed the DNS nameservers, it was with an eye to finding a workaround for the hostgator https redirect, while trying to get tech support to address it.

A reasonably courteous response, actually. But it completely avoided addressing the https redirect (that redirect really pissed me off – can you tell?). Which has nothing at all to do with nameservice at this point – I verified this behavior on remote access servers where the DNS change (brief – like 20 minutes) was never even seen. I just now edited /etc/hosts and re-pointed to the hostgator address for the server instead of the current one and as soon as I do, https brings back the same page. Just intentionally coercive.

Because Verizon used to allow port 443 (SSL) a lot of the search results for the sites I administer are https. A bogus redirect was unquestionably not acceptable. I sent sales queries to bluehost.com and to dreamhost.com, both are listed by WordPress as acceptable hosting companies.

I made up a list of questions which outlined exact requirements, hopefully to avoid this same situation. Both companies gave good answers. This was starting Sunday evening through Labor day, Monday. I chose dreamhost.com, moved the site, re-pointed the nameservers. In a day or so (well within the 45 day trial period at hostgator) I’ll ask hostgator for my account to be closed and the money refunded, after I delete everything off of the server. Once that’s done I’ll click “publish” on this article.

un-Cha-ching.

You know, just out of curiosity (and since I’m already off the hosting anyway), I’m going to submit another ticket to see how much it takes to remove the redirect… It may not be a true test, but let’s see how flexible they are in the face of adversity. Here’s the email to open the ticket:

I recently asked that private SSL be dismantled for this account. It was. Once it was dismantled a redirect went into effect for https://myprimarydomain.com to http://searchportal.information.com/index.mas?epl=00680014UV_a_verylongstring.

Please remove this redirect. Acceptable behavior for this kind of thing is for https:// urls to redirect back to http:// OR for https:// to time out since the connection is not available.

To redirect to a bogus URL for https is unacceptable. I have re-pointed the domain away from hostgator to resolve this issue to a host I use for other domains. I can re-point back on my local DNS for testing purposes – please let me know when you have removed this behavior.

Thank you,

— doug

My guess is the response won’t be satisfactory, but should be interesting to see what happens.

…12:19 AM 20080903, no response at all.

On the other hand – the host dreamhost placed me on had root filesystem space issues tonight – they responded, and I could watch through the (full) bash shell on the server as they fixed it, up until

Broadcast message from root@server (pts/8) (Tue Sep 2 19:22:38 2008):

 

The system is going down for reboot NOW!

Connection to server closed by remote host.

The website was also down after they assigned a dedicated IP address – this was resolved within 5 minutes of reporting it. Just an apache misconfig.

This kind of sysadmin stuff I can tolerate, within reason.

At this point I have two dedicated IP addresses and SSL enabled successfully on both of my primary sites. I’m paying slightly more than for the single account at hostgator, but certainly less than two or more shared accounts on hostgator would have cost.

— dsm