plethera of glitches

I have very mixed feelings about DH after only about 4 days.
I have had way too many glitches and too steep of a learning curve that should be either fixed or documented.

1.) with a new web ID you are assigned a PW and not told how to change it or even if it can be changed.

2.) Learned the hard way not to FTP to sciopio.dreamhost.combut rather to my domain when it comes to mapped directories.

3.) WebDAV directories don't work as advertised and are useless due to them wanting passwords when being linked to.

If you have any suggestions I am listening. I just wish DH would focus on the basics before spending time on the rocket science!!!

I agree that the setup learning curve is steep, I was quite confused for a few days, but I am more concerend about frequent MySQL outages. My site has been experiencing intermittant failures for most of this week, with connections not being made, queries failing, pages not available, and so forth. Yet when I ask support I am told the server was stable and there were no significant problems. Its quite concerning!

I am also a new user and have noticed that my ssh sessions will sometimes freeze for no apparent reason. I can reconnect immediately with no problems. This doesn't happen on other hosts.

I too have noticed the MySQL downtimes. Also, even a default installation of Ruby on Rails will sometimes report an error, which disappears if you reload. Other times, there will be a long (10s or so) delay before rendering even the simplest of Ruby pages. Ruby also seems to leave instances of dispatch.fcgi running forever (evidenced by running ps x).

I've also noticed that the number of open support requests has gone from 44 to 80 or so to 144 to 151 since I registered.

I really like the feature set and price structure, and the server appears to be very powerful, but this combination of things has made me leery of putting anything terribly important on my dreamhost account.

You know, I've been with Dreamhost for over 7 years. I've seen glitches, but what you're describing isn't a glitch.

If you would calm down and take some effort to look at the Knowledge Base system, you'll find your answers without the steep learning curve. The reason Dreamhost doesn't tell you all of this is because they already HAVE. Hence the Knowledge Base system:

1)Go to USERS in your dreamhost control panel (panel.dreamhost.com), then PASSWORD. Rocket science indeed.
2) https://panel.dreamhost.com/kbase/index.cgi?area=137&keyword=FTP
3)WebDAV is extremely unsecure. The reason is wants passwords is to help make it more secure. You're lucky dreamhost offers it at all because most secure, decent hosts, won't. I tend to think the instructions work but you're making mistakes. If you can't take the time to use the resources provided, tends to make me think you're not taking the time to do this right either.
WebDAV--
https://panel.dreamhost.com/kbase/index.cgi?area=932&keyword=WebDAV

Sorry for being blunt but you whine about steep learning curve and you haven't tried very hard to learn.
Dreamhost isn't AOL. It's not going to do it all for you because it's expected that when you work with a real host, you know what you're doing or know how to look it up.

I have noticed the MySQL blips. All I can say is that if enough people report it, something will be done.

Raven


www.ravenoak.net
www.torifest.com
www.6-58.comEdited by ravenoak on 06/30/05 08:38 AM (server time).

Two more areas of help:

The Getting Started Guide:
https://panel.dreamhost.com/kbase/index.cgi?area=7

And an explanation of the Web ID:
https://panel.dreamhost.com/kbase/index.cgi?area=2125

Raven

www.ravenoak.net
www.torifest.com
www.6-58.com

Most of your points are valid, but dreamhost should not rely on user complaints to find out about things like MySQL outages. They should monitor these core systems continuously and have automated mechanisms in place to alert sysadmins or even bring hot spares online.

For all we know, they are aware and dealing.
Or these could be blips as a result of the DOS attacks, which Dreamhost cannot control unless they shut down everyone's board.

If you have a better way to deal with the problem, I'm sure they'd love to hear about it. If your that concerned, all you have to do is email them about it.

Usually, they do surf these boards a bit. The fact that they haven't been in days tells me that they're REALLY busy with something.

Raven

www.ravenoak.net
www.torifest.com
www.6-58.com

It's not unusual to expect 99.9% uptime from a web host. The burden is not on me, the customer, to tell the provider how to run their business, or run it better. That is what I (and presumably you) pay them for. You could have told me that if I don't like it I should find another host, and that would be reasonable, but "tell us how YOU would do it" is not.

It is bizarre to hear people talk about outages in terms of "days" in this industry unless the NOC is under physical attack, or DDoS on the scale of the ones that took down eBay and Amazon in the late 90s.

The fact that nobody from dreamhost has shown up in days, not even to post a simple update tells me that something is wrong. You seem to take it as a sign that they are doing a great job, which I find rather weird. What is this "for all we know, they are aware and dealing."?? That's my point--we don't even know if they are aware! How you can come in and defend them across the board is beyond me. You pay for the service, you're entitled to complain a little.


Edit: Great, now I am getting that bad_httpd_conf error that other people were/are having on one of my new subdomains. Anyone care to spin this in dreamhost's favor? Perhaps they are editing their httpd.conf templates to ensure better service for us.Edited by bithive on 07/01/05 02:55 PM (server time).

Okay, you're totally missing my point.

First off, they do have 99.9% uptime. Go check your machine status. I haven't had more than maybe 30 seconds TOTAL of outtage on my mySQL. If you do, something's wrong and it could be on your end. If any of your data, etc. is corrupted, it can cause a lot of problems.

Second, if you bothered to read the "AGREEMENT" terms for this board, you'd know that this isn't an OFFICIAL board and Dreamhost support team doesn't HAVE to read it. The fact that some of them do is a perk. They don't have time to read through all of this. That's what the support contact is for.

I don't know why you're getting bad_httpd_conf errors.
I don't work for Dreamhost. And I could go on for days with the reasons people have errors, most of which result from their own lack of knowledge. Email support. Simple solution.

I'm not trying to twist anything into Dreamhost's favor. Hell, there've been a time or two that I'm bitched them out and torn them a new one for REAL outtages, way back when they were just getting started (over 7 years ago). I'm the first to admit when something's not going well. But you seem to expect them to be superman when you haven't really come up with a problem yet (beyond the one you just mentioned).
mySQL outtages doesn't necessarily mean a Dreamhost problem. If it's bad coding or corrupt stuff on your end, they can't do crap about it.

Raven


www.ravenoak.net
www.torifest.com
www.6-58.com

MySQL is conspicuously absent from their uptime metrics. In fact, the status page only says this right now:

"System uptime stats currently offline (how ironic!)."

Indeed.

Before you assume the problem is on my end (it wasn't, and MySQL works fine now, but as long as we're having this discussion, I'll bite.....) I should point out that the host was completely dead. Couldn't ping it from my machine, couldn't ping it from my dreamhost shell. That's pretty conclusive. It couldn't have been a data corruption problem, because I hadn't had the opportunity to PUT any data in it in the first place!

I know this isn't an official board, I don't expect them to read or reply to anything here. My comment was directly in response to your statement that their absence was indicative of anything. It isn't. They could be hard at work fixing the problem, they could be drinking martinis in Aruba, or they could be trying to find their way out of David Bowie's Labyrinth. But to say that their absence and the sizable support queue is evidence that they're hard at work (and not incompetent) is indeed twisting things to make them look better (or at least, less bad) despite what you say.

I stand by my dismissal of the support contact page. The number of open support requests has only gotten LARGER since I've registered. It's at 200 now. Assuming 5 minutes to deal with each issue and send a response (that's being generous, I feel), working nonstop, that's a sixteen hour best-case response time if I file my request RIGHT NOW.

It's pretty presumptuous to insinuate that the errors I'm seeing are from my own lack of knowledge. Instead of trying to convince you otherwise, however, I'll just state that the errors (both MySQL inaccessibility and bad_httpd_conf) I've seen have BOTH happened simply by adding the service to my account using the control panel. Both services immediately failed to work. I never even had a chance to break them with my lack of knowledge.

At this point I'm not complaining about a specific problem. I know that's not going to do any good here. I am defending my overall impression of Dreamhost from your criticisms. Despite what you say, you are obviously not the "first one to admit when something's not going well" and you really are covering for Dreamhost.

I'm expecting them to be superman? No, I'm expecting that things work more than 50% of the time when I use their control panel. I'm expecting that when I add a MySQL service, it doesn't tell me to connect to an IP that doesn't respond to pings for 24 hours. I'm expecting that when I add a new subdomain, the damn thing doesn't come up with a fatal error in the browser right off the bat.

That SSH connection freezing is strange. Have you tried watching the network with ping when it happens to see if there are any clues? I'm ssh'd into our machines just about all day every day and haven't been seeing that problem so it's not a system-wide thing.

If you are seeing MySQL problems like that, you should contact us. There aren't any known ongoing MySQL issues at the moment so if you're seeing sporadic dropped connections we will look into it.

The Ruby dispatch.fcgi running forever appears to be a bug in Rails itself and from what I have heard has been fixed in the soon to be released newer version of Rails.

Our number of open support cases will vary quite a bit from day to day depending on the load of incoming messages and the number of technicians we have working. We don't generally answer the questions strictly in the order they are received so a larger queue does not necessarily mean a particular support question will take longer to be answered. You have to decide for yourself what is acceptable for your needs, of course!


- Dallas
- DreamHost Head Honcho/Founder

The SSH freezing has been better lately. I'm not blaming dreamhost for that since it could be a network problem anywhere between me and the datacenter.

I did not submit a support request for the MySQL problem because other people already had, and I didn't want to clog up the support queue.

Thanks for the clarification on dispatch.fcgi, and your support queue. You'll forgive my gut reaction to seeing the number go from 44 to 151 to 200 over a period of days.

Really, my only complaint right now is the bad_httpd_conf, which I will submit a support ticket for shortly.

In reply to:

---

The SSH freezing has been better lately. I'm not blaming dreamhost for that since it could be a network problem anywhere between me and the datacenter.

---

Ok. If there is a network problem that is something we can resolve we will attempt to do so. Let us know if you figure out anything more about it.

In reply to:

---

I did not submit a support request for the MySQL problem because other people already had, and I didn't want to clog up the support queue.

---

I have talked to our main MySQL administrator and he told me he has been working on the problems with some of the people reporting problems so it should get resolved soon.

In reply to:

---

Thanks for the clarification on dispatch.fcgi, and your support queue. You'll forgive my gut reaction to seeing the number go from 44 to 151 to 200 over a period of days.

---

We obviously prefer to have our support queue small as much as possible! We have added about 40% of additional support staff in the last 4 months or so. As the new recruits continue to learn more about our system they should be able to handle even more of the load. We are fairly confident our current team will be able to handle things well now, but if not we will continue adding staff.

In reply to:

---

Really, my only complaint right now is the bad_httpd_conf, which I will submit a support ticket for shortly.

---

I took care of it for you so you're good to go. It was looking for a directory that didn't exist on the server. I created it and the site setup went ahead as normal.





- Dallas
- DreamHost Head Honcho/Founder

> Thanks for the clarification on dispatch.fcgi, and your support
> queue. You'll forgive my gut reaction to seeing the number go
> from 44 to 151 to 200 over a period of days.

It's understandable. We, too, have a gut reaction when we see the queue jump up quickly (as it has today, for a variety of reasons). It's especially annoying lately as we've been doing a pretty good job keeping the queue down lately.

In our experience, a 'bad day' is always going to happen once in a while. We've been doing a good job keeping them few and far in between, but they still occur.

> Really, my only complaint right now is the bad_httpd_conf, which I
> will submit a support ticket for shortly.

I was going to check on this, but I didn't see where you posted the site in question. While this forum should never be considered a replacement for submitting a formal support request, you may want to consider posting your domain if you run into this sort of thing. If one of us happens to bump into your post, we might be able to fix it on the spot.

Also, bad_httpd_conf errors in general mean that something interfered with the generation of your site's entry in our Apache web server configuration file. You can sometimes work around this yourself by editing your domain from the web panel, 'submitting' it (even with no changes), and waiting a bit. This forces it to be re-generated, which may work. Obviously the error shouldn't happen in the first place, but if you want to get the site up ASAP this can sometimes help.

- Jeff @ DreamHost
- DH Discussion Forum Admin

Between this post and the ones from dallas, I'm all smiles now.

@ravenoak > First off, they do have 99.9% uptime.

Sorry to jump on this (again), but where can I get that info? Please don't tell me to go to the System Status page on my Web Admin Panel, as even if the stats are not offline (like right now), they are not useful at all. Thanks.

How are they not useful?

www.ravenoak.net
www.torifest.com
www.6-58.com

@ravenoak > How are they not useful?

http://discussion.dreamhost.com/showflat.pl?Cat=&Board=forum_troubleshooting&Number=21064

Ya know, that was an interesting read. Guess they're not. Hmm... They did discuss in that thread it being outdated and needing fixing so maybe that's something they're working on too?

Thanks for the link!
Raven

www.ravenoak.net
www.torifest.com
www.6-58.com

> you whine about steep learning curve and you haven't tried very hard to learn

If one has to "try very hard to learn", then surely it is because the learning curve is indeed steep.

I didn't know who to hit 'reply' to, you or Dallas or Jeff :) but since I'm going to quote you...

In reply to:

---

...I'll just state that the errors (both MySQL inaccessibility and bad_httpd_conf) I've seen have BOTH happened simply by adding the service to my account using the control panel. Both services immediately failed to work. I never even had a chance to break them with my lack of knowledge.

---

There is a notorious *wait* for things such as you've described. Creating a MySQL database and expecting it to be immediately available is not realistic right now. Creating a subdomain and expecting it to be immediately available is not realistic right now (and the bad http_conf seems to be fairly common of late, normally fixes itself eventually) nor can you expect to immediately have access to a new user space, mailbox etc...

These should be in the knowledgebase, maybe a section called *you_will_wait* ?

Oh by the way, in the web panel, once you do soemthing that will require a wait the cinfirmation page will tell you so in green.

I've heard these quicker automation things are on the shortlist which is encouraging. Once you're aware of the *waits* you can at least plan around them or at least be aware before hand...

jason

speaking of green wait text it might be worth many a support ticket to replace

<font color=green></font>

with

<span class="wait"></span>
...
.wait {
    color : red;
    background-color : yellow;
    border : 1px solid green;
}

or somesuch! The uglier the better :)

jason

> Oh by the way, in the web panel, once you do soemthing that will
> require a wait the cinfirmation page will tell you so in green.

And it will often tell you incorrectly e.g.

Successfully added mailbox@domain.co.uk!
IMPORTANT! Mailbox Login: m####### Password: *******
Note: It will take up to an hour for this new address to become active.

whereas it can take up to two hours.

Which is disappointing to see still the case, given I reported this fault nearly a year ago.