Getting camping working with fcgi on a shared host (DreamHost), part 1

Posted by Tim Connor Fri, 06 Jul 2007 16:04:00 GMT

Since I’ve been splitting up an app into an rails admin section and a separate camping front-end, I need to get camping working on the host to deploy. And that host, for this app, happens to be DreamHost, which means it’s gotta be fcgi. I’m not all the way done with that, but after a late night last night, I managed to get it running on fcgi locally. I’ll skip over the basics (for one thing, if you haven’t gotten this far yet, you are going to need to struggle through it to be familiar enough with what is happening to have a chance of finishing the process) until I have it all worked out smoothly, but I have to post a couple highlights, to spare some people with the same pain.

First off, no luck running off of edge. The only way I got it working consistently with mongrel, cgi (crucial for debugging and figuring out why things aren’t working), and fcgi, was to use the gem release (1.5.180), and patch that (keep reading). Once I had that running smoothly with the built-in server and then cgi, I got it working with fcgi. If you have the same problem I did, you’ll get an “`camp_do’: undefined local variable or method `exc’” error. THis is because there is another problem, which is throwing an error, but there is a bug in the exception handling code. Manually fix that (change e on to exc in the exception catching, so that it is defined), and then you can move on to the next issue, since your exceptions will now actually get through to the log, or the screen, depending on how far you’ve made it, and you can use them for more debugging.

If you have my problem, you can track down the next error to the path variable not being populated right in the fastcgi.rb


def camp_do(req)
root, path, dir, app = “/”
if ENV[‘FORCE_ROOT’] and ENV[‘FORCE_ROOT’].to_i == 1
path = req.env[‘SCRIPT_NAME’]
else
root = req.env[‘SCRIPT_NAME’]
path = req.env[‘PATH_INFO’]
end

Wether or not I set ENV[‘FORCE_ROOT’] the wrong server variables are being set for camping to know the right path. This shows up as gsub on nil errors, or “/dispatch.fcgi not found”, or some others, depending on exactly which way you are running things. This all comes back to not being able to use ScriptAlias, as in the wiki, due to only having .htaccess level access. And using RedirectRule and other mod_rewrite stuff that workins in .htaccess (I actually just stole that right from my rails .htaccess) populates things a little bit different.

My fix was to set “ENV[”FORCE_ROOT"]=1.to_s" in my dispatch.fcgi, and then change the corresponding “path =” line to match what my set-up was populating -req.env[‘REQUEST_URI’]. I tracked this down by getting things running well enough to get the default error dump to the browser, and then checking over that.

Now I need to duplicate this without using global gems (since I can’t upgrade them on the shared host), and the do more debugging on the actual host.

Run your Dreamhost apps under separate users

Posted by Tim Connor Tue, 10 Apr 2007 17:30:00 GMT

After an email exchange with Dreamhost I have had it confirmed that their watcher processes monitor on a per user basis. This means that if you run each app under a separate user you are less likely to have problems with getting your fcgi processes killed.

Excerpt of my email exchange with Dreamhost
bq.

> Is it true that the processes are watched on a per user basis
> as in running each app under a different user name will
> mitigate problems?

Yep, that’s correct!

Dreamhost has got to go - Apache fcgi sucks. 4

Posted by Tim Connor Wed, 25 Oct 2006 07:33:00 GMT

So I thought I’d hold onto Dreamhost as my primary host a while longer, but its driving me mad. It just won’t perform wortha snot, especially anything that depends on fcgi. Hence Trac and Typo (Rails is Apache fcgi on Dreamhost) are not exactly running up to snuff. But it’s not like anything has ever been going F1 speeds for me with them.

You want to know how I knew right away there was a comment posted on one of the entries? I have been giving the new Rails monitoring service, Heartbeat, a try, and I got a notification from them that my domain had changed from “200 OK” to timing out. Great, the load of serving up a couple page-views and handling a single comment pushed my Typo install to it’s limits.

I’m going to keep Dreamhost for storage, backup, and mirroring svn, since you get a lot for your dollar, but I can’t stand it as a primary domain any longer, even just for my blog and minor personal projects.

Update on hosting

Posted by Tim Connor Thu, 19 Oct 2006 15:59:00 GMT

Dreamhost upgraded the RAM on my server yesterday. This meant it was down unexpectdly and I felt like that was teh last straw. BUT, I checked their special status page, and saw what was happening, and they did have it right back up around the time frame they said they would.

My sites perform MUCH better now. I’m still stuck with the vagaries of being on a shared host, with the (mt) gs set-up might be the solution for, but so far I haven’t had any problems. Maybe half my problem was just being stuck on an underequiped server. And after trying out the gs, I might be asking for a refund (they said they’d give me one, if I chose). I’m just too addicted to the featurefulness of DH. mt didn’t have SRV records (needed for the chat for GMail for Your Domain), email plus addressing (tim+randomstring@timocracy.com), anyway to run Trac, barring good (bad) old cgi*, or mod\dav\svn (svn over Apache).

The solution for most of these would be too keep my DH account for those and use the Grid for things like Rails sites that need better performance. Well, why not just keep my DH only then, since my sites are performing fine now. I can always go back to mt later, after they add a Python container and SRV records (two things I know they are planning to implement). Thanks mt, for making it easy to cancel and get a refund, I’ll remember that when I need a little more umph, or if DH starts sucking again.

*While Apache fcgi may suck, it’s better than that.

Dreamhost going down the tubes?

Posted by Tim Connor Wed, 18 Oct 2006 16:42:00 GMT

I’m getting really tired of Dreamhost’s non-stop problems. Hell even when something isn’t officialy broken my performance sucks. While I don’t expect to find mod_python so Trac will run nicely, for the Rails side of things (and all around, actually) a very nice looking new option sprung up: MediaTemple’s new Grid Server hosting. I’m seriously considering migrating everything over to their basic plan. Hell, I can keep my Dreamhost for random filestorage forever (well as long as one certain old client doesn’t get as tired of the performance as I am, and switch), given my referals (I might have to cut back to the basic plan).

I’m basically just waiting to hear back that Trac should run fine under .fcgi, which I expect it will, and to maybe read some reviews, since it JUST went live.

Oh, and the fact that DH just 10-foldified their disk space on plans, but are still DESPERATELY trying to get vendors to sell them a massive network storage solution doesn’t look good.