Rails does not properly read environmental variables in database.yml

Question

My database.yml is set up as such:

development:
  adapter: mysql2
  encoding: utf8
  database: devel
  username: root
  host: localhost
  port: 3306
  timeout: 5000

# ... snip ...

production:
  adapter: mysql2
  encoding: utf8
  database: prod
  username: <%= ENV["DB_USER"] %>
  password: <%= ENV["DB_PASSWORD"] %>
  host: <%= ENV["DB_HOST"] %>
  port: 3306
  timeout: 5000

The issue is, though, despite setting my environmental variables, Rails is not reading these properly. When I start up my Phusion-backed Nginx server on EC2, I get this message:

Access denied for user 'root'@'localhost' (using password: NO) (Mysql2::Error)

I confirmed that Phusion is starting Rails in the production environment; I changed the usernames and hosts in the development and test configuration to unique names, and 'root'@'localhost' always showed up as the error message. In addition, if I hard-code the username and password into the YAML file, the server starts up properly.

I suspect that I'm not setting my environmental variables correctly because MySQL keeps claiming that I'm trying to log in as 'root' without a password. I initially had them exported from the .bashrc file, but after reading this question, I realized that this was not the proper way to do it. After searching around, I happened upon this blog post, so I followed the instructions and created these three files:

/usr/local/etc/env

export RAILS_ENV=production
export DB_PASSWORD= (snip)
export DB_USER=doorbells

/usr/local/etc/ruby_wrapper

#!/bin/sh

source /usr/local/etc/env
exec /home/rooby/.rvm/wrappers/ruby-1.9.3-p362@doorbells-dev/ruby "$@"

/etc/profile.d/env.sh

#!/bin/sh

source /usr/local/etc/env

In my nginx.conf file, I use this line:

passenger_ruby /usr/local/etc/ruby_wrapper;

I've rebooted my server to no avail. Any ideas?

Loux

just a guess but you need to use database.yml.erb – Mcghee

Didn't work, unfortunately. The file needs to be named 'database.yml'. – Loux

@gorelative it possible to interpolate variables in YAML files – Delightful

This should work, or at least it does with Foreman and Webbrick, locally. – Enviable

Answer 1

I had the very same problem on Ubuntu 12.04.

In the nginx error log (/var/log/nginx/error.log/) I've seen, that

[ ... ]: [App 8509 stderr] /path/to/ruby_wrapper.sh: 2: /path/to/ruby_wrapper.sh: 
[ ... ]: [App 8509 stdout] 
[ ... ]: [App 8509 stderr] source: not found

/bin/sh seems to don't understand the source command. Thus, I've changed it to a simple ., which does the same.

The complete changed ruby_wrapper.sh would look like:

#!/bin/sh

. /usr/local/etc/env
exec /home/rooby/.rvm/wrappers/ruby-1.9.3-p362@doorbells-dev/ruby "$@"

Does this help for you?

Northwester

Hmm, I do recall deploying my Rails app onto an EC2 instance running Ubuntu 12.04 LTS. I don't really do Rails anymore, but I'll try out your solution for closure. Surprised people are still digging this question up. :) – Loux

Answer 2

The above solution did not work for me. However, I found the solution on How do I use variables in a YAML file?

My .yml file contained something like:

development:
gmail_username: <%= ENV["GMAIL_USERNAME"] %>
gmail_password: <%= ENV["GMAIL_PASSWORD"] %>

The solution looks like:

template = ERB.new File.new("path/to/config.yml.erb").read
processed = YAML.load template.result(binding)

So when you introduce a scriptlet tag in .yml file, it is more of erb template. So read it as a erb template first and then load the yml as shown above.

Nanine

Answer 3

first, use

username: ENV["DB_USER"]
password: ENV["DB_PASSWORD"]
host: ENV["DB_HOST"]

instead

username: <%= ENV["DB_USER"] %>
password: <%= ENV["DB_PASSWORD"] %>
host: <%= ENV["DB_HOST"] %>

Suffragette

That is not correct. database.yml is evaluated as an ERB template so he definitely should use the <%= %> syntax. – Tommie

@Tommie Unless you're using HAML, in which case you'll need to use string interpolation. – Examen

That is not true either. database.yml is always evaluated as an ERB template. It does not matter whether you use HAML for views or not. – Tommie