Remote SDK and environment variables.

I'm having an issue with my development configuration where it seems to be unable to read environment variables on the remote SDK's server, which I use to store the database password. The error I get is this:

/home/vagrant/.rbenv/versions/2.2.2/bin/ruby -e '$stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift)' /home/vagrant/railsproject/bin/rails server -b 127.0.0.1 -p 3000 -e development

=> Booting Puma

=> Rails 4.2.3 application starting in development on http://127.0.0.1:3000

=> Run `rails server -h` for more startup options

=> Ctrl-C to shutdown server

Puma 2.12.2 starting...

* Min threads: 0, max threads: 16

* Environment: development

* Listening on tcp://127.0.0.1:3000



Started GET "/" for 127.0.0.1 at 2015-08-01 20:39:12 +0200


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

  mysql2 (0.3.19) lib/mysql2/client.rb:70:in `connect'

  mysql2 (0.3.19) lib/mysql2/client.rb:70:in `initialize'

  activerecord (4.2.3) lib/active_record/connection_adapters/mysql2_adapter.rb:18:in `new'

  activerecord (4.2.3) lib/active_record/connection_adapters/mysql2_adapter.rb:18:in `mysql2_connection'

  activerecord (4.2.3) lib/active_record/connection_adapters/abstract/connection_pool.rb:438:in `new_connection'

  activerecord (4.2.3) lib/active_record/connection_adapters/abstract/connection_pool.rb:448:in `checkout_new_connection'

  activerecord (4.2.3) lib/active_record/connection_adapters/abstract/connection_pool.rb:422:in `acquire_connection'

  activerecord (4.2.3) lib/active_record/connection_adapters/abstract/connection_pool.rb:349:in `block in checkout'

  /home/vagrant/.rbenv/versions/2.2.2/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'

Which is basically telling me that my password is empty. Here is my database.yml:

default: &default
  adapter: mysql2
  database: invdb
  username: invuser
  password: <%= ENV['INVUSR_PASSWORD'] %>
  host: localhost

development:
  <<: *default


This works fine if I launch the console or the server directly from an ssh terminal, but if I run this from Rubymine it simply won't pick up the variables. I'm assuming this is cause it's not reading .profile nor .bashrc. For reference, this is what I get on an ssh terminal:

vagrant@debian:~/railsproject$ env | grep INV

INVUSER_PASSWORD=XXXXXXXXXX

What could I be missing? Is there a way to know if Rubymine is reading either .bashrc or .profile when it connects over ssh? This is a new project, as I wanted to test rails 4.2.3. As a workaround I hardcoded the database password directly on database.yml (which is fine, since this is simply for testing).

These are some of my computer specs:

Host OS: Windows 10 Home x64.
Guest OS: Debian 8.1 (jessie)
Rubymine: 7.1.4
Ruby: 2.2.2 (rbenv)
Rails: 4.2.3

2 comments
Comment actions Permalink

Hi,

most likely the problem is that you do set the vars for interactive shell only.
Any remote execution is something similar to "ssh <command>"
So I'd suggest to verify that "ssh env | grep INV" will show the varibale.

Hope this helps, Oleg.

0
Comment actions Permalink

Ahh, that did it. Thank you!

Just to be thorough, here's what I did to solve it (in case someone else stumbles on to this):

I'm using Debian, so I had to change a line in my .bashrc (the one in my home directory) so that it loaded the variables before it notices that it's not in interactive mode. The lines are:

# If not running interactively, don't do anything

case $- in

    *i*) ;;

      *) return;;

esac

Either all of these are commented, or you load the variables before these lines. I decided to load the variables before, but by using a file with the variables, just so I wouldn't have to keep screwing around with .bashrc. Here's how my .bashrc ended up like

source ~/.railsenv


# If not running interactively, don't do anything

case $- in

    *i*) ;;

      *) return;;

esac

Then my .railsenv file:

export RAILS_ENV=development

export INVUSER_PASSWORD="XXXXXXXXXXX"

And here's how ssh replies after the change:

$ ssh vagrant env | grep INV

INVUSER_PASSWORD=XXXXXXXXXXX

And it works!

0

Please sign in to leave a comment.