8

The code in question

Net::SSH.start('server name', 'user')

This returns "non-absolute home". The 'user' in fact does have a home directory. One suggested approach was to modify ~/.ssh/config with full paths to the IdentityFile. This did not solve the issue.

The crazy part of this is that the code works fine if called through irb or console. The moment we try calling it from within a class method (with the same code) it returns the "non-absolute home" error.

The 'user' can also ssh into the server via command line without issue. The server is running Ubuntu.

UPDATE

Thanks to @Phrogz - The fix for this was setting ENV['HOME'] to '/home/deploy'. However, I have not figured out why $HOME is getting set to "." on the server. So, I will leave this question up without an "Answer" until I, or someone else, figures that out. Having to manually set HOME feels more like a "hack" than a proper solution, but it does work.

Jadon
  • 155
  • 1
  • 5
  • 1
    Do you have a `HOME` environment variable set? `echo $HOME` – Phrogz May 01 '12 at 00:25
  • 1
    @Phrogz - if I output it via irb, console, command line it shows a path. However, if I set it a variable in the class (home = %x[echo $HOME]) itself (Rails_Root/lib/class_obj) then it hits me back with a "."? – Jadon May 01 '12 at 00:37
  • 1
    Looks like your interpreter is running under a shell with a different path. If you either set it to an absolute path in your script, or unset it completely, does that fix it? – Phrogz May 01 '12 at 01:00
  • @Phrogz I had to set for it to work? ENV['HOME'] = 'home/deployer' I'm not really sure what killed it in the first place. It works though. Thanks so much man. – Jadon May 01 '12 at 02:19
  • 1
    I'm also having this problem, could you tell me the steps you carried out to set the home env so the net-ssh used it – user891380 Jul 16 '12 at 09:43
  • What is the execution context of the code i.e. Delayed job, web server, script etc? – Paul Odeon Jul 24 '13 at 07:02

3 Answers3

3

We just ran into the same problem, and found the root cause. We're running our script as a service, and if you check the manpage for service, it strips most env variables before running the script, including HOME. I don't know if your scenario is the same, but HOME is not set.

net-ssh wants to look up ssh config from the users home folder, so it used to force ENV['HOME'] to "." if it was not set. But when File.expand_path tries to expand "~/.ssh" the ArgumentError is raised.

This was fixed two months ago ( https://github.com/net-ssh/net-ssh/pull/98 ), so updating your net-ssh gem should resolve this.

Stylpe
  • 612
  • 1
  • 7
  • 16
1

It definitely works by setting the HOME env var if it's not set.

Antonio Terreno
  • 2,835
  • 1
  • 14
  • 9
0

Linux sets this information based on the /etc/passwd file.

Check what exists in /etc/passwd for the deployer user. It should be near the bottom of the list.

The items are colon separated. The value for ENV['HOME'] should be the second to last entry in that line.

Is it blank, ie have two colons together?

I suspect that your HOME variable isn't present in the /etc/passwd and is being set in one of the default dotfiles, ie something like .bashrc. Then, .bashrc is short circuited if your app is running via an init.d script that doesn't source your dotfiles. (Many .bashrc files stop loading remainder of commands if it is executed via a non-interactive shell).

Hope this helps and please post back with your findings.

ZPH
  • 151
  • 3