Disabled mod_passenger on a number of domains
Posted (June 27th, 2008 at 7:01 am PST) by kitchenWhile dealing with some issues with mod_passenger over the last few days, we’ve observed that quite a number of people are enabling mod_passenger on their domains and not actually using it for anything. Because of this we’ve made a restriction for mod_passenger where the path to the web directory must actually have /public at the end, to (hopefully) prevent people from enabling it without any need to do so.
To take care of the existing domains which have been set up in this fashion, we disabled mod_passenger on any currently hosted domain which wasn’t pointing at a /public directory. There are a few of you who might have a symlink to a rails application’s /public directory, you simply need to re-enable mod_passenger through the web panel to get it working again.
If you have any questions, please feel free to contact support, and we can assist you!
20 Responses to “Disabled mod_passenger on a number of domains”
I like the service you offer, but it’s frustrating working with you. So many of your premeditated outages, which you know will break functionality until someone notices, are a complete surprise to your customers.
Please make an effort to notify affected customers _before_ yanking the rug from under our feet.
@ Jesse
You only need it if you’re running a Rails sites. You wouldn’t want to have it running unless you had a rails site.
@Nyhm
Dreamhost does an amazing job when it comes to keeping clients notified about what is going on with their systems. Yes, it does take effort on our part to check dreamhoststatus, but I actually enjoy reading about what it going on across the board, even if it does not affect me. It shows that dreamhost is not afraid to be honest or hide anything from us happy-dreamhost-customers.
This time around they must have had trouble determining who was ACTUALLY using their enabled passenger and who was accidentally running it. I would do the same thing… disable it unless pubic. Just like they did.
But when will you upgrade Rails to 2.1?
@Brad
I entirely agree with you regarding DreamHost’s status updates (this blog). I also give commendations for doing the Right Thing when it comes to administering their systems. I truly believe DreamHost wants its infrastructure configured as clean as possible.
However, emergencies notwithstanding, DreamHost should plan ahead and provide preemptive announcements, like:
“If you have X configured like Y, please be aware that on DATE_IN_FUTURE, your hosting may break unless you do INSTRUCTIONS.”
true… true….
I agree with Nyhm. Hopefully DH takes your comment into consideration.
I am now looking for a new service and a refund this service goes down every day for something new….
““If you have X configured like Y, please be aware that on DATE_IN_FUTURE, your hosting may break unless you do INSTRUCTIONS.””
The problem with this, is that the domains that didn’t have this configured properly were causing apache web servers to crash unexpectedly. That basically means 30-40 sites were down, per apache, instead of a handful that were misconfigured!
We had to make the change immediately, in order to keep as many sites up as we could. While it’s always our intention to let everyone know of every change we make as far in advance as possible, sometimes, that’s just not feasible, as the issue may be effecting many more users, if left unfixed.
@Brian -
“domains that didn’t have this configured properly were causing apache web servers to crash unexpectedly”
If you had stated that in the announcement, you would have less complaints. The announcement reads like you’re just trying to do a little cleanup, not fix an actual issue that may be affecting others who aren’t even using Rails.
Thanks for taking quick action to prevent more of us from having downtime due to some people who aren’t aware how to properly configure their domains.
@Brian - Thank you for the clarification. I see now that this was indeed an emergency procedure, and thank you for taking quick action.
@brasscrest - Very good point. DreamHost’s open, detailed, technical feedback is a primary reason I’m a customer. Don’t be shy about explaining the hosting side of the problem.
Overall, this situation is just a gap in communications, which could be improved on both sides. I shouldn’t be so quick to frustration, and should assume DreamHost did what they had to do. DreamHost can be sure to give us tech-savvy geek-types the details we need to understand the situation.
@Nyhm - but with some situations, giving technical details may scare non-technical users. While it will help us tech-savvy people, the non-techs will be lost, and sometimes scared at the big words. The way they ‘dumb it down’ and keep it simple, allows both non-technical and technical users to understand it more easily, even if a few details are kept out.
If the issue does not affect you, theres no need to ask questions; however, when it does, that’s when you ask. DreamHost is one of the very few companies to be so open about their status, most hosting companies would not tell you about any of this.
@Jay - Yes, I totally agree with what you’ve said. DreamHost’s openness and technical competence is probably 75% of why I’m here.
@Brian,
I am about to deploy mod_passenger to a number of VPS machines. Could you clarify “While dealing with some issues with mod_passenger over the last few days”? (Offline if necessary.) Was it just that the misconfiguration was causing problems or are there issues with mod_passenger in production? I appreciate your feedback.
Thanks!
+1 for Rails 2.1 (asap please). Also will you be enabling Ruby Enterprise for Passenger?
Thanks. 
+1 for Rails 2.1
+1 for Rails 2.1 too…
MOST WANTED!
Note two things:
1. This also breaks symbolic links if you are using them in the filesystem.
2. The note does not clearly state where to turn this back on. This article labels the issue as “mod_passenger” where the checkbox option in panel is labeled as “mod_rails.”
Even if you are not using rails but you are using symbolic links, you will need to enable the “Ruby On Rails” option in hosting setup.
Documentation has got to be clean…
Yeah, I’m looking for a Rails Hosting… But I’m in a rush… My App is too Rails 2.1 intensive 
Leave a Reply
Comments posted here may not be viewed by DreamHost staff at all. Please note that this is not a way to contact DreamHost.
I’m sorry, but what is mod_passenger? Is this enabled on all domains? Or just for Rails?
If it’s for all domains, how can this impact PHP?
Thanks