Speaking of sessions…if you’re using the default PStore sessions, you can set the directory you want them in:

ActionController::CgiRequest::DEFAULTSESSIONOPTIONS[:tmpdir] = “#{RAILS_ROOT}/sessions/”

This will also help you keep in mind that you’ll have to go in there from time to time and clean em out.

No tags

If you’re working away on a rails app and have made a change to an object that is held in a session, you may get an error about some mung in the session and then the whole app seems to die. You probably need to clear out the session cache. It holds a serialized version of an object that it can’t un-serialize any more since you went and changed it. On Windows that’s here:

C:\Documents and Settings\[username]\Local Settings\Temp\ruby_sess.

Delete any ruby_sess. and you should be back at it.

No tags

Here’s what I did to get typo running at DreamHost:

First, confirm from the shell:

which ruby  -> should be /usr/bin/ruby
gem list  -> should include rails 0.13.1, etc.

You’ll need to edit dispatch.fcgi and dispatch.rb to have the correct path to ruby.

I set up typo in my web root. If you don’t want that, I’d highly suggest setting up a sub domain and pointing it to the public folder of typo:

/home/cgiusername/public_html/typo/public/

Then edit the .htaccess file to point it to use .fcgi:

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

And set the permissions of at least the dispatch.fcgi and dispatch.rb to 755:

chmod 755 public/*

It’s a good idea just to do the whole public directory.

Next, if you’re on Windows run:

dos2unix public/*

Before I set up the sub domain I was having problems getting the app to handle the requests right. It is definitely easier to use a whole separate host if you have any spare ones. I’ll probably go back and set up several hosts such as:

blog.convergentarts.com
wiki. " "
forum. " "

etc. because it is both a lot easier to get your app running, but you also have some nice division of your htdocs so you don’t overwrite your wiki when you change your blog.

No tags

If you use the configure script, you may want to remove it from your production instance. (You may also want to remove all the sql scripts for the same reason.) It would be potentially disastrous to execute that script on your production app and reset your database to pristine condition. I may try to add a user confirm to the script if the environment comes back as ‘production’.

No tags