Closed richlewis14 closed 11 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.
Hard to say without more context around the failure - try copy/paste a few screens back from terminal when you see the failure
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
deploy:stop' triggering before callbacks for
deploy:stop'rubber:pre_stop' triggering before callbacks for
rubber:pre_stop'Hope this enough info, if you need anything else let me know, I really appreciate the help, thanks guys
HI Guys
Just wondering if you have any more ideas on the above issue. Really stuck and cannot find an answer online
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.
This may be a obvious question but do i need to put anything next to Hostname to use for staging instance [production] ?
no, cap should load the hosts using rubber, so it will execute the hostname command on all hosts in the current env
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
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"}
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.
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?
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.
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
What version of Mac are you guys using? I haven't tested with Mountain Lion, but thing should be working okay with Lion.
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.
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.
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.
@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
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.
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...
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.
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?
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:
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.
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.
Thanks @cipater, creating the ~/.ec2
directory fixed this for us too.
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
Any help would be appreciated on what i need to do to resolve this