(Note: this article might be better named “the most complicated database.yml file possible”)

Have you ever accidentally added your database.yml file to subversion or moved a database.yml file to a computer where it doesn’t belong? How about moving your dev server from your laptop to your desktop to your school’s web host to some new install of Suse you’re playing with?

Most of the time this is a big headache. You get errors like the one in the title where the socket was not found. Different flavors of *nix will put the default mysql socket in different places on the machine and it can be a pain to try to keep up with things.

Well, here’s a a database.yml file that can relieve you of ever having to remember which machine you’re on. Many thanks to LazyAtom go gave me the idea for this (who, in turn, got the idea from James Duncan Davidson

Behold – The Code:

login: &login
  adapter:  mysql
  username: user
  password: 
  socket:  <%=
    ['/opt/local/var/run/mysql5/mysqld.sock', # darwinports
     '/opt/local/var/run/mysqld/mysqld.sock', # darwinports, again
     '/var/run/mysqld/mysqld.sock',           # ubuntu/debian
     '/tmp/mysql.sock'].select { |f| File.exist? f }.first %>

development:
  <<: *login
  database: rails_development

test:
  <<: *login
  database: rails_test

production:
  <<: *login
  database: rails

Ta-Da. I just installed this on my dev box and things are working great already.

For those of you who run a staging server to test your app in production, you might want to check out the following setup (I’m seriously considering a staging server setup for my apps. Also, this is good if you’re absolutely dead-set on using the same database.yml file for multiple hosts and multiple configurations (just as long as you know the hostname).

<% host = `uname -n`.strip %>
user: &user
  <% if host.eql? 'staging' %>
  username: staging_user
  password: staging_pass
  <% else %>
  username: user
  password: pass
  <% end %>

login: &login
  <<: *user
  adapter:  mysql
  socket:  <%=
    ['/opt/local/var/run/mysql5/mysqld.sock', # darwinports
     '/opt/local/var/run/mysqld/mysqld.sock', # darwinports, again
     '/var/run/mysqld/mysqld.sock',           # ubuntu/debian
     '/tmp/mysql.sock']
     .select { |f| File.exist? f }.first %>

development:
  <<: *login
  database: rails_development

test:
  <<: *login
  database: rails_test

production:
  <<: *login
  database: rails

If you want to partition the login info for several different users on a large collaborative project you may want to have a special file (ignored by SVN) that holds just the login info for a given user:

login: &login
  adapter:  mysql
  username: user
  password: 
  socket:  <%=
    ['/opt/local/var/run/mysql5/mysqld.sock', # darwinports
     '/opt/local/var/run/mysqld/mysqld.sock', # darwinports, again
     '/var/run/mysqld/mysqld.sock',           # ubuntu/debian
     '/tmp/mysql.sock'].select { |f| File.exist? f }.first %>

# replace the above login details with information from ./config/dblogin.yml
<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
    IO.read(file) if File.exist?(file) %>

development:
  <<: *login
  database: rails_development

test:
  <<: *login
  database: rails_test

production:
  <<: *login
  database: rails

In case you haven’t run across this yet, Kevin has posted an awesome reference for configuring your rails behavior.

The main problem I have with the rails default ./config/database.yml format is that it’s not DRY. Here’s an example of a default database config:

development:
  adapter: mysql
  database: development_db
  username: username
  password: password
  sochost:  localhost
test:
  adapter: mysql
  database: testing_db
  username: username
  password: password
  sochost:  localhost
production:
  adapter: mysql
  database: production_db
  username: username
  password: password
  sochost:  localhost

Now, thanks to the Typo team (who have also made this blog possible), we have an alternative format that you can use to keep the redundancies out of your file:

login: &login
  username: username
  password: password
  adapter:  mysql
  host:     localhost

development:
  database: development_db
  <<: *login

test:
  database: testing_db
  <<: *login

production:
  database: production_db
  <<: *login

If this isn’t slick enough for you, Doug Alcorn has improved upon this by letting you change the login details for each host that you might run this application on. His code:

login: &login
  username: username
  password: password
  adapter:  mysql
  host:     localhost

# replace the above login details with information from ./config/dblogin.yml
<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
    IO.read(file) if File.exist?(file) %>

development:
  database: development_db
  <<: *login

test:
  database: testing_db
  <<: *login

production:
  database: production_db
  <<: *login

And then you can have a separate file next to database.yml called dblogin.yml – and it can be different for each host. Here’s an example of what dblogin.yml could look like:

login: &login
  username: danger
  password: jesus_was_probably_good_at_juggling
  adapter:  mysql
  host:     localhost

After seeing Dreamhost killoff my fastcgi processes I’ve modified my dispatch.fcgi file in accordance with the suggestion on the dreamhost wiki. This is fully functional and you can (probably) just copy and past straight into your dispatch.fcgi file. The contents of the file are mostly just comments anyway, so this significantly simplified my dispatch file. Enough ado, here’s the code:

require File.dirname(__FILE__) + "/../config/environment" 
require 'fcgi_handler'

class RailsFCGIHandler
  private
  def fix_handler(signal)
    dispatcher_log :info, "asked to terminate immediately" 
    dispatcher_log :info, "fix handler working its magic!" 
    restart_handler(signal)
  end
  alias_method :exit_now_handler, :fix_handler
end

RailsFCGIHandler.process! nil, 10

If you use Subversion and develop Rails on either Linux, Mac OS X, or through a shell into a shared server you could use this.

A while ago I realized that many of the commands I was using on a regular basis were cumbersome. With Subversion especially I found the commands lengthy. With Rails I kept wanting a ‘remigrate’ command so I could test my migrations to see if they were valid all the way down to 0 and back up. To edit your .bashrc or .bash_profile entries simply type:

nano ~/.bash_profile

(you can replace ‘nano’ with whatever editor you like). You can add as many other aliases as you want to help with whatever commands you use most – just make sure there are no spaces on either side of the equals sign!

The following is the text from my .bash_profile file in my home directory:

alias migrate='rake migrate'
alias clone='rake clone_structure_to_test'
alias remigrate='rake migrate VERSION=0 && rake migrate'
alias remigrate_prod='rake migrate VERSION=0 RAILS_ENV=production && rake migrate RAILS_ENV=production'
alias remigrate_dev='rake migrate VERSION=0 RAILS_ENV=development && rake migrate RAILS_ENV=development'
alias l='ls -l'
alias st='svn st'
alias update='svn update'
alias delete='svn delete'
alias add='svn add'
alias copy='svn copy'
alias move='svn move'
alias commit='svn commit'
alias commitm='svn commit -m ""'
alias upcom='svn update && svn commit -m ""'
alias upco='svn update && svn commit'

The following allows me to type just ‘update’ to do an svn update or ‘commitm’ if I want to commit without bothering to enter a log message (useful for one-person projects). ‘upcom’ and ‘remigrate’ are my two favorites because they allow for quick access to multiple commands.

Let me know if you have any others I should add to speed up my work!

Okay, I wish I could write this now and then go back in time two days, read it, and save myself a lot of hassle. I spent a lot of time trying to debug a rails installation on a shared host and it could have been so much easier.

1. Get your Rails app working

1. step one

Set file permissions. Do it like so: ./public needs to be set to 755

$ chmod 755 public

./public/dispatch.fcgi (or dispatch.cgi – but don’t use that!) also to 755

$ chmod 755 public/dispatch.fcgi

make sure ./public/.htaccess exists (my copy can be found at the bottom of this post) ./log and everything under it needs to be set to 766

$ chmod -R 766 log

do the same for the ./tmp directory (Rails writes session data here)

$ chmod -R 0666 tmp

#### step two Make sure you’re running in ‘development’ mode. Code errors will be displayed to the screen in this mode – but ‘production’ will just barf out on you (it’s intended to work this way). Set RAILS_ENV=’development’ in config/environment.rb if you have no other way to do this.

$ nano config/environment.rb

#### step three If the above didn’t work, look at the bottom of any of your log files. Depending what environment you’re in you may need development.log or production.log. If it gives you a handy error like ‘could not find environment.rb’ or something like that it’ll really help you figure out the problem.

$ tail -n 100 log/development.log

#### step four Get into the ruby console. Try to run a command like you would in your app like User.find_all or something similar. This will show you errors that wouln’t come up elsewhere.

$ ./script/console 

1. step five If you’re running an app that requires a specific version of Rails but didn’t include it along with the app you’ll need to ‘freeze’ Rails into your app. This is actually quite simple – if you put the whole Rails source code into ./vendor/rails then your application will use that code instead of the stuff on your server at /usr/lib/ruby/ The way to do this is to run any of the following:

rake freeze_gems

(get the latest stable version)

rake freeze_edge

(get the cutting-edge version)

svn co -r 997 http://dev.rubyonrails.org/svn/rails/trunk

(insert revision number you want instead of 997)

1. good luck!

### Resources: My working .htaccess file:

AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

ErrorDocument 500 /500.html

#ErrorDocument 500 "
Application error
Rails application failed to start properly"

If these steps didn’t work for you leave a comment and I’ll try to help you out. I’m a GNU guy so I don’t know much about Rails on Windows, but I’d be happy to help you avaoid the hideous, hideous Rails errors.

Also, if you’re looking at random 500 errors while working on your Dreamhost account, you’ll want to use a modified dispatch.fcgi file.