rubber / rubber

A capistrano/rails plugin that makes it easy to deploy/manage/scale to various service providers, including EC2, DigitalOcean, vSphere, and bare metal servers.
http://rubber.io/
Other
1.47k stars 246 forks source link

Connection Error whilst deploying via rubber to AWS #141

Closed richlewis14 closed 11 years ago

richlewis14 commented 12 years ago

I think i am now one step away from successfully deploying my rails 3 website to AWS using your gem'. I seem to be getting this error message and am unsure on what it means or what to do next

connection failed for: production.foo.com (Errno::EISDIR: Is a directory - /home/richard14/bafo2)

Any help would be appreciated on what i need to do to resolve this

akremer commented 12 years ago

Are you on a Mac by chance? If so you're probably using the default Ruby that came with MacOS. Recommend you install Ruby using RVM http://beginrescueend.com/ -- after installing it that error should go away.

wr0ngway commented 12 years ago

Hard to say without more context around the failure - try copy/paste a few screens back from terminal when you see the failure

richlewis14 commented 12 years ago

Hi Guys

I use Ubuntu 11.04, already using RVM, Im on 1.9.2.... Screenshots below

richard14@richard14-Satellite-L450:~/bafo2$ cap rubber:create_staging triggering load callbacks

Hope this enough info, if you need anything else let me know, I really appreciate the help, thanks guys

richlewis14 commented 12 years ago

HI Guys

Just wondering if you have any more ideas on the above issue. Really stuck and cannot find an answer online

wr0ngway commented 12 years ago

try using a basic capistrano task to see if you can at least connect: cap invoke COMMAND=hostname

Does the directory " /home/richard14/bafo2" exist? Is bafo2 your src tree? Is that the CWD when you run the cap commands?

you could also try running cap through rdebug and stepping till you find the problem - its allo pure ruby code.

richlewis14 commented 12 years ago

This may be a obvious question but do i need to put anything next to Hostname to use for staging instance [production] ?

wr0ngway commented 12 years ago

no, cap should load the hosts using rubber, so it will execute the hostname command on all hosts in the current env

jasonmanners commented 12 years ago

Hello,

I am getting a similar error. When i run the command

cap rubber:create_staging

It will create the instance but will fail to connect on the command

  • executing `rubber:_allow_root_ssh'
  • executing "sudo -p 'sudo password: ' bash -l -c 'cp /home/ubuntu/.ssh/authorized_keys /root/.ssh/'"

This will continue to retry and so I have to kill it. When I do that and run any other commands such as:

  • cap rubber:create_staging
  • cap invoke COMMAND=hostname

I get the same error as richlewis14:

connection failed for: production.foo.com (Errno::EISDIR: Is a directory -

I am currently on Mac OSX Lion running with: RVM version: 1.10.2 Ruby version: 1.9.3p125

I am trying to create and connect to a micro instance in the us-west-1 region

timezone: US/Western region: us-west-1 image_type: t1.micro image_id: ami-ef1d38aa

Still learning how to use a lot of this so it may be a setup issue. Any help is greatly appreciated

davidweisz commented 12 years ago

I am having the same issue, too.

* Auto role: graylog_web => production.foo.com, {:platform=>"linux"} * Auto role: haproxy => production.foo.com, {:platform=>"linux"} * Auto role: web => production.foo.com, {:platform=>"linux"} * Auto role: web_tools => production.foo.com, {:platform=>"linux"}

jasonmanners commented 12 years ago

Still don't have full success but I have completed server setup by following this:

ALIAS=web01 cap rubber:refresh FILTER=host cap rubber:bootstrap cap deploy → Replace web01 with the instance alias you gave your app.

Located in the FAQ. Got me past the connection failed part and onto other issues, but those issues may be related to my setup.

If it still doesn't work check your /etc/hosts and make sure there are not duplicate entries for production.foo.com, that was also causing issues.

stestaub commented 12 years ago

Has anyone a soloution for this problem? I also get a

connection failed for: production.foo.com (Errno::EISDIR: Is a directory -

on my Mac OSX Lion

also using Ruby: 1.9.3p125 and rbenv.

same project is working on my Linux Mint computer using same ruby version and rbenv version.

My /private/etc/hosts file is set correctly and I can access my project using the webbrowser with production.foo.com

Any Ideas?

davidweisz commented 12 years ago

After trying to fix then issue without luck for one day, I moved to Ubuntu and it worked without any issue. Apparently something in OSX is causing the issue.

David

On 27 בספט 2012, at 16:40, Stefan Staub notifications@github.com wrote:

Has anyone a soloution for this problem? I also get a

connection failed for: production.foo.com (Errno::EISDIR: Is a directory - on my Mac OSX Lion

also using Ruby: 1.9.3p125 and rbenv.

same project is working on my Linux Mint computer using same ruby version and rbenv version.

My /private/etc/hosts file is set correctly and I can access my project using the webbrowser with production.foo.com

Any Ideas

— Reply to this email directly or view it on GitHubhttps://github.com/wr0ngway/rubber/issues/141#issuecomment-8938234.

stestaub commented 12 years ago

hmmm ok. Thank you for your reply. So I will work locally on my Mac and use my Linux machine at home to Deploy :D

nirvdrum commented 12 years ago

What version of Mac are you guys using? I haven't tested with Mountain Lion, but thing should be working okay with Lion.

cipater commented 12 years ago

I was having this issue, but it turned out to be the key_file key in rubber.yml.

    key_file: "#{Dir[(File.expand_path('~') rescue '/root') + '/.ec2/*' + cloud_providers.aws.key_name].first}"

The directory .ec2 didn't exist. Changing it to the correct directory (for my setup) fixed the issue.

crizCraig commented 11 years ago

It looks like conflicts in /etc/hosts and ~/.ssh/known_hosts can arise. I solved my problems by cleaning those up manually, setting up a new keypair, and making up a new domain in rubber.yml.

Also, make sure to change my-key-name.pem to the key_name in rubber.yml. This is probably the same thing without the .pem at the end, i.e. name the file my-key-name).

Side note: I am on OSX Mountain Lion.

andreteves commented 11 years ago

The only way I found to solve this problem: http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/

crizCraig, I followed your advices but It didn't work for me on a OSX 10.8.2.

crizCraig commented 11 years ago

@andreteves Looks good! The /etc/hosts file can def get messed up. Using a new instance name seemed to work for me to avoid conflicts. I also ran bundle exec cap rubber:destroy on the old instance name which seems to clean up the old entries in the /etc/hosts file and ~/.ssh/known_hosts

gmcnaughton commented 11 years ago

I had the same problem: (Timeout::Error: execution expired) trying to run rubber cap tasks (rubber 2.2.2, Mac OS 10.8.4).

My /etc/hosts and ~/.ssh/known_hosts were correct, and I could ssh into the server from the command line (ssh -i my-key.pem ...) However, attempts to run cap rubber:refresh or cap rubber:bootstrap failed with timeout errors.

The only thing that fixed the timeout errors for me was adding Google's DNS Servers (8.8.8.8 and 8.8.4.4) to my Network settings. After that, the same commands that used to error had no problems.

stestaub commented 11 years ago

Some update on this. I had this problem fixed on my OSX but forgot about this for some time now. Now I had this issue again on my Linux machine. Turns out that this error is raised when the given key file is not found as @cipater wrote. The error is somewhat confusing...

nirvdrum commented 11 years ago

Capistrano seems to go to great lengths to hide the underlying error from us. I was just recently bit by a similar issue and didn't see a way readily available to get a more informative message.

adamthedeveloper commented 11 years ago

None of the suggestions above have worked for me on my mac at all. If I wait a while, maybe a minute or so, and run cap rubber:bootstrap, it starts working and then it fails again with timeout issues (Timeout::Error: execution expired) when it reaches

executing `rubber:install_gems'

Immediately following that error, when I run cap rubber:bootstrap again, it fails much quicker at

rubber:base:update_sudoers

Then if I wait a little while, the above cycle occurs again. I'm not sure why waiting a few moments between these two commands makes a difference, but that is a pattern I am seeing.

As of now, I am completely unable to add roles to any of my machines. Installing ubuntu in a virtual machine on my mac to get around this doesn't feel happy at all. Anyone else out there have some ideas?

nirvdrum commented 11 years ago

It seems every new addition to this issue is a different problem masked by the same cap message. I'm going to close this in favor of discussion on the mailing list. If any of you are still having problems, I think we can have a more fruitful discussion there without spamming everyone else on the ticket:

http://groups.google.com/group/rubber-ec2

adamthedeveloper commented 11 years ago

Let's not be too hasty to run away from this thing =). I definitely found my issue. Looks like the Rubber Gem is forcing a connection timeout of 5 seconds if you don't set

set :ssh_timeout, <something greater than 5 seconds>

in deploy.rb

the net-ssh gem happily looks for a ConnectTimeout setting in ~/.ssh/config - I set it to something bigger there (60 is what I played with) but the rubber gem forces 5 seconds to get passed through to net-ssh. Here's the line:

# lib/rubber/recipes/rubber.rb line 86 as of 10/25/2013
ssh_options[:timeout] = fetch(:ssh_timeout, 5)

So - not sure what we all want to do with this. My humble opinion is we don't hard code the 5 there - but we do what net-ssh does and see if there's a value in ~/.ssh/config or /etc/ssh_config for ConnectTimeout and if not, then we throw a value in there. Preferably one that is higher than 5. I can make that change if it makes sense to everyone.

I'm on a mac and setting ssh_timeout to something bigger than 5 definitely fixed it for me. Now to figure out why my connections take so long - but - that's a different problem.

nirvdrum commented 11 years ago

Well, it appears one group of people is having problems with their key file, another with timeouts. I suspect the initial reporter had problems with the key file. In any event, with all the ping ponging on the issue, it's incredibly difficult to sort through this issue.

The timeout was added 3.5 years ago. My guess is net-ssh probably didn't read other timeout values, since traditionally net-ssh ignored all of your local SSH configuration. It may be the case that the timeout is no longer necessary. But I also concur that if it's taking longer than 5 seconds to establish an SSH connection, something deeper is likely wrong.

If you have a robust way of checking for configured values, I'd be happy to look at a pull request. Otherwise, I'd add this as an FAQ to the wiki and maybe bump the default from 5 to 10 seconds.

mconigliaro commented 8 years ago

Thanks @cipater, creating the ~/.ec2 directory fixed this for us too.