Installing Insoshi on a Dreamhost Account

May 17, 2008

With the Insoshi social networking platform rapidly gaining in popularity, I thought it might be useful to folks to know how to install it on the ever-popular Dreamhost shared account. If you need a Dreamhost account, please consider using the promo code “LRDESIGN” when you sign up. It will save you $50 on your first year of membership, and will help me with my site hosting expenses so I can keep this blog going.

So, there are still some possible drawbacks to this approach, but I was able to get a running install of Insoshi on my Dreamhost account with this sequence. You might want to read to the bottom of this post to learn about the difficulties with acts_as_ferret and Dreamhost before you commit to running your insoshi site on DH. Hopefully these problems will have a solution soon, and I’ll update this post if/when they do.

If you use this method and it works (or doesn’t!) please let me know in comments.

1) Set up a domain

Use the DH control panel to create a new fully hosted domain for your Insoshi site, for example yourdomain.com or insoshi.yourdomain.com. I will use “insoshi.yourdomain.com” through the rest of this post to indicate the domain that you want to use to run insoshi. I set up http://insoshi.lrdesign.com/ in the process of writing this post, but I can’t guarantee that it will stay up.

When you set up the domain:

• Make sure that fastcgi support is selected.
• Set “specify your web directory” to point to /home/username/insoshi.yourdomain.com/public/

2) Set up mysql databases

1. In the dreamhost panel, select “Goodies -> Manage MySQL”
2. Scroll down to “create a new mysql database”

I used these example settings:

• database name: insoshi
• use hostname: mysql.yourdomain.com (use “new hostname” to create this if you do not already have it)
• New user: insoshi
• New password:

If you want to run tests, you should create a second database called insoshi_test; you can leave the other settings the same.

3) Download the tarball of the current insoshi distribution:

cd
wget http://insoshi.com/home/tarball

You’ll get a tarball with a name like “insoshi-insoshi-e1fd8b8e440c9f3ab34161d4e87de78e956c1012.tar.gz”. Unzip the tarball and copy the contents to the directory you want the website to appear in:

tar xzf insoshi-insoshi-e1fd8b8e440c9f3ab34161d4e87de78e956c1012.tar.gz
cp -r insoshi-insoshi-e1fd8b8e440c9f3ab34161d4e87de78e956c1012/* insoshi.yourdomain.com/

4) Set up your database.yml file

cd ~/insoshi.yourdomain.com/config
cp database.example database.yml

Edit ~/insoshi.yourdomain.com/database.yml and make it look like the following, where <password> is the password you chose in the previous step:

development:
  adapter: mysql
  database: insoshi
  username: insoshi
  password: <password>
  host: mysql.lrdesign.com
  port: 3306

# Warning: The database defined as 'test' will be erased and
# re-generated from your development database when you run 'rake'.
# Do not set this db to the same as development or production.
test:
  adapter: mysql
  database: insoshi_test
  username: insoshi
  password: <password>
  host: mysql.lrdesign.com
  port: 3306

production:
  adapter: mysql
  database: insoshi
  username: insoshi
  password: <password>
  host: mysql.lrdesign.com
  port: 3306

5) Run the insoshi install script.

This will migrate the database and do some insoshi-specific setup. It’s also an excellent way to check that you’ve configured your database.yml correctly.

cd ~/insoshi.yourdomain.com
rake install

If it works, you should see a bunch of migrations (22 as of the current version of insoshi). If not, go back and figure out what’s wrong with your database.yml file.

6) Get rails working

These instructions are an adaptation of the instructions at the Dreamhost Wiki page about Rails.

Generate a dummy rails app and copy the dispatch scripts to your insoshi install:

cd ~
rails dummy
cp dummy/public/dispatch.* insoshi.yourdomain.com/public/

Edit ~/insoshi.yourdomain.com/public/.htaccess file to enable fastCGI. Change the line with dispatch.cgi to look like this:

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

change your permissions on the public and dispatch files:

cd ~/insoshi.yourdomai.com
chmod 755 public
chmod 755 public/dispatch.*  

I also had to make my log files writeable:

chmod a+w log/
chmod a+w log/*

7) Start the ferret server

I was not able to get insoshi to run in production mode on Dreamhost at first
because in production mode it needs the ferret server (text search) to be
running or it will refuse to load some of the models. (In test and development
mode, acts_as_ferret will access the ferret databases directly, so this problem only appears in production). Based on this post, I found I could get it working by running:

script/ferret_server start -e production

At this point, I was able to load Insoshi in my browser.

Unfortunately, there are still some problems

I am pretty confident that the approach to running ferret_server above will not be a long term solution, because Dreamhost kills any processes that you leave running for more than a few hours. So ferret_server will go down after a while, and with it your site, so this will probably only get your insoshi site up for a few hours before you have to restart ferret_server. This basically means there’s no good way to use the rails plugin acts_as_ferret on a DH shared account, and unfortunately Insoshi depends on AAF.

Possible Workarounds

You could try putting the startup command in a cron script, to restart ferret_server when Dreamhost kills it, for example:

0,15,30,45 * * * * cd ~/insoshi.yourdomain.com; script/ferret_server start -e production

would attempt to start the ferret server every fifteen minutes. But that might run afoul of Dreamhost server policies (does anyone know for sure?), and in any case your site would still be down in between the time DH killed the ferret_server process and your cron job started again.

You can also alter config/ferret_server.yml to have ferret treat production mode the same as development, directly accessing the ferret database and bypassing ferret_server entirely. However, if you get concurrent access with multiple users, you are very likely to get a corrupted ferret database with that approach.

Hopefully, some permanent solutions?

The Insoshi guys are working on replacing ferret with Sphinx, and that may be a permanent solution to this problem.

You also may want to consider lobbying Dreamhost to allow users run persistent processes like ferret_server. If you are a Dreamhost subscriber you can vote for this feature by following this link to Dreamhost’s Policies Suggestions and voting for “Be able to run simple, persistent scripts!”.