I can’t get past the setup step in Capistrano. I know the paths are
correct and I’m using zsh locally (bash on remote), so the shell
shouldn’t be a problem. It never asks for the SSH password, even. Any
help you could give would be greatly appreciated. Thanks.
I can’t get past the setup step in Capistrano. I know the paths are
correct and I’m using zsh locally (bash on remote), so the shell
shouldn’t be a problem. It never asks for the SSH password, even. Any
help you could give would be greatly appreciated. Thanks.
Kenneth,
What error are you getting? What is the command-line you are using to
run the setup?
I’m not getting any explicit error. It just hangs at the " * executing
“mkdir -p -m 775” line. This is with “rake remote:exec ACTION=setup”
and “cap setup”.
I’m not getting any explicit error. It just hangs at the " * executing
“mkdir -p -m 775” line. This is with “rake remote:exec ACTION=setup”
and “cap setup”.
Strange… Could you try adding the following to your deploy.rb:
ssh_options[:verbose] = :debug
Then run it and capture the output to a file. Search and replace any
instances of your password (if any), and then email the result to me
directly.
Thanks! Sorry for the snafu… Hopefully this dump will enlighten me
a bit about what is going on.
I’m not getting any explicit error. It just hangs at the " * executing
“mkdir -p -m 775” line. This is with “rake remote:exec ACTION=setup”
and “cap setup”.
Strange… Could you try adding the following to your deploy.rb:
ssh_options[:verbose] = :debug
Then run it and capture the output to a file. Search and replace any
instances of your password (if any), and then email the result to me
directly.
Thanks! Sorry for the snafu… Hopefully this dump will enlighten me
a bit about what is going on.
Jamis
One more data point: I just upgraded to Cap 1.1. Everything worked
great until running “cap -A .”
[root@zvents dev_instance]# cap -A .
exists config
Then it just sat there for a couple minutes. It turns out that it never
displayed the “overwrite config/deploy.rb? [Ynaq]” prompt, but it was
waiting for a keystroke. I hit enter and then it displayed the prompt
after the fact. Odd. In case it matters, this is with termios 0.9.4
gem on CentOS 4.0.
I can’t get rake remote:exec ACTION=setup to complete successfully. I
suspect there is a problem in authentication.
I connect to my development server using RSA authentication and I am
using keychain, (v2.02) an ssh-agent front-end so I only have to
enter a passphrase for my key once.
Keychain is an OpenSSH key manager, typically run from
~/.bash_profile. When
run, it will make sure ssh-agent is running; if not, it will start
ssh-agent.
It will redirect ssh-agent’s output to ~/.keychain/[hostname]-sh, so
that cron
jobs that need to use ssh-agent keys can simply source this file and
make the
necessary passwordless ssh connections. In addition, when keychain
runs, it
will check with ssh-agent and make sure that the ssh RSA/DSA keys that
you
specified on the keychain command line have actually been added to
ssh-agent.
If not, you are prompted for the appropriate passphrases so that they
can be
added by keychain.
I have not used capistrano before and have installed the most recent
gem on my development machine and the single machine handling :web
and :app (the database is on a separate machine altogether).
executing “mkdir -p -m 775
/web/rails.dev.concord.org/teemss2/releases
/web/rails.dev.concord.org/teemss2/shared/system &&\n mkdir -p -m
777 /web/rails.dev.concord.org/teemss2/shared/log”
servers: [“maggie.concord.org”, “database.concord.org”]
rake aborted!
No such file or directory - /tmp/ssh-G0tW2k3sTa/agent.333
If I turn on verbose SSH debugging I see this before the process bombs:
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: got packet
of type 33
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: sending
message >>“\025”<<
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: waiting
for packet from server…
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: reading 8 bytes from socket…
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: packet length(12) remaining(8)
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: received: “\025”
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: got packet
of type 21
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: sending
message >>“\005\000\000\000\fssh-userauth”<<
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: waiting
for packet from server…
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: reading 8 bytes from socket…
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: packet length(28) remaining(24)
[DEBUG] Tue Mar 28 13:37:08 EST 2006 –
transport.incoming_packet_stream: received:
“\006\000\000\000\fssh-userauth”
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – transport.session: got packet of
type 6
[DEBUG] Tue Mar 28 13:37:08 EST 2006 – userauth.driver: trying
“publickey”
rake aborted!
No such file or directory - /tmp/ssh-G0tW2k3sTa/agent.333
ssh_options[:verbose] = :debug
One more data point: I just upgraded to Cap 1.1. Everything worked
after the fact. Odd. In case it matters, this is with termios 0.9.4
gem on CentOS 4.0.
No such file or directory - /tmp/ssh-G0tW2k3sTa/agent.333
If your ssh-agent is configured properly, it will create a socket and
then set an environment variable called SSH_AUTH_SOCK that gives the
path to the socket.
However, things do go wrong. It sounds like you’ve got the
SSH_AUTH_SOCK environment variable set, but it is pointing to a
socket that doesn’t exist. Try unsetting the SSH_AUTH_SOCK
environment variable before running capistrano and see if that helps.
No such file or directory - /tmp/ssh-G0tW2k3sTa/agent.333
If your ssh-agent is configured properly, it will create a socket and then set an environment variable called SSH_AUTH_SOCK that gives the path to the socket.
However, things do go wrong. It sounds like you’ve got the SSH_AUTH_SOCK environment variable set, but it is pointing to a socket that doesn’t exist. Try unsetting the SSH_AUTH_SOCK environment variable before running capistrano and see if that helps.
Thanks for responding Jamis,
I unset SSH_AUTH_SOCK and no longer have the “No such file …” error.
After killing ssh-agent and running kechain again I now have an
SSH_AUTH_SOCK that points to something valid.
I had turned off rsa authentication (by renaming the server folder
.ssh), had the same problem and have turned it back on. However
everytime I run my task I get asked for the password (I’m not sure why
it isn’t using the host keys).
Here’s what I see if I try the task with --trace, basically the process
ends by raising AuthenticationFailed.
Does Net::SSH work with SSH protocol version 1 RSA keys? That is what
I have been using.
I’ve generated both DSA and RSA SSH protocol level 2 keys but haven’t
yet got them to work with the remote server using ssh shell login.
I’ve copied the id_rsa.pub key identity.pub on the remote host and
copied id.rsa into identity on the local host.
The Net::SSH connection method works fine using a password but not
with the original RSA1 keys.
So originally, I had the same problem - when running ‘cap deploy’ I got
a
No such file or directory - /tmp/ssh-XEpLf2881/agent.2881
Then I followed the helpful advice in this forum and unset my
SSH_AUTH_SOCK, which successfully got rid of the initial error.
Unfortunately, another one replaced it. I now get “exception while
rolling back: Errno::ECONNREFUSED, Connection refused”. Any help with
this would be much appreciated, as I really don’t know how to go about
debugging issues with SSH. Below is the full output.
executing “rm -rf /var/www/apps/collegelist/releases/20070209002231”
servers: [“scribd.com”]
** [update_code] exception while rolling back: Errno::ECONNREFUSED,
Connection refused -
/usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/agent.rb:70:in initialize': Connection refused - (Errno::ECONNREFUSED) from /usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/agent.rb:70:in connect!’
from
/usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/services.rb:56:in register_services' from /usr/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/service-point.rb:122:in instance’
from
/usr/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/container.rb:308:in []' from /usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/services.rb:70:in open’
from
/usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/userkeys.rb:232:in ensure_agent' from /usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/userkeys.rb:127:in identities’
from
/usr/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/methods/publickey.rb:50:in authenticate' ... 21 levels... from /usr/lib/ruby/gems/1.8/gems/capistrano-1.4.0/lib/capistrano/cli.rb:239:in execute!’
from
/usr/lib/ruby/gems/1.8/gems/capistrano-1.4.0/lib/capistrano/cli.rb:12:in
`execute!’
from /usr/lib/ruby/gems/1.8/gems/capistrano-1.4.0/bin/cap:11
from /usr/bin/cap:18
Stephen B. wrote:
Stephan,
The telling error here is this:
No such file or directory - /tmp/ssh-G0tW2k3sTa/agent.333
If your ssh-agent is configured properly, it will create a socket and then set an environment variable called SSH_AUTH_SOCK that gives the path to the socket.
However, things do go wrong. It sounds like you’ve got the SSH_AUTH_SOCK environment variable set, but it is pointing to a socket that doesn’t exist. Try unsetting the SSH_AUTH_SOCK environment variable before running capistrano and see if that helps.
Thanks for responding Jamis,
I unset SSH_AUTH_SOCK and no longer have the “No such file …” error.
After killing ssh-agent and running kechain again I now have an
SSH_AUTH_SOCK that points to something valid.
I had turned off rsa authentication (by renaming the server folder
.ssh), had the same problem and have turned it back on. However
everytime I run my task I get asked for the password (I’m not sure why
it isn’t using the host keys).
Here’s what I see if I try the task with --trace, basically the process
ends by raising AuthenticationFailed.