Forum: Rails deployment can't do cap setup

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ea2273b4310db9ac0109dfaefd489a06?d=identicon&s=25 Ivan Storck (ivanoats)
on 2007-06-06 20:51
This is the first time I'm trying out capistrano, so I'm sure there's
something I simple I'm missng.

I can ssh to the server using a public rsa key just fine. The username
is the same on my laptop as on the server.

ivan:10:40 AM:writr> cap setup
  * executing task setup
  * executing "umask 02 &&\n    mkdir -p /var/www/writr.com
/var/www/writr.com/releases /var/www/writr.com/shared
/var/www/writr.com/shared/system &&\n    mkdir -p
/var/www/writr.com/shared/log &&\n    mkdir -p
/var/www/writr.com/shared/pids"
    servers: ["www.writr.com"]
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/agent.rb:70:in
`initialize': No such file or directory - /tmp/501/SSHKeychain.socket
(Errno::ENOENT)
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/agent.rb:70:in
`connect!'
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/services.rb:56:in
`register_services'
        from
/usr/local/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/service-point.rb:122:in
`instance'
        from
/usr/local/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/container.rb:308:in
`[]'
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/services.rb:70:in
`open'
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/userkeys.rb:232:in
`ensure_agent'
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/userkeys.rb:127:in
`identities'
        from
/usr/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.1/lib/net/ssh/userauth/methods/publickey.rb:50:in
`authenticate'
         ... 13 levels...
        from
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/cli.rb:239:in
`execute!'
        from
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/capistrano/cli.rb:12:in
`execute!'
        from
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/bin/cap:11
        from /usr/local/bin/cap:18

Thanks for any help!
Ea2273b4310db9ac0109dfaefd489a06?d=identicon&s=25 Ivan Storck (ivanoats)
on 2007-06-06 23:00
I also tried deleting my keys, on the laptop and the server, and then
running cap setup. It seems to be re-adding a ssh-dss key from somewhere
into my local known_hosts. Not sure why
Ea2273b4310db9ac0109dfaefd489a06?d=identicon&s=25 Ivan Storck (ivanoats)
on 2007-06-07 18:39
Well, I found the solution and hopefully others will find this thread if
they are stuck too.

thanks to http://www.deheus.net/petrik/blog/post/124/

"You can temporarily fix this in the console by typing: unset
SSH_AUTH_SOCK "

so it works, but I don't understand why.
13ee02bb9012e843dbe7d0a23a6656f7?d=identicon&s=25 digitalronin (Guest)
on 2007-06-08 11:45
(Received via mailing list)
> "You can temporarily fix this in the console by typing: unset
> SSH_AUTH_SOCK "
>
> so it works, but I don't understand why.

I'm sure someone will correct me if I'm wrong, but my guess would be
that at some point, you had an ssh-agent running. ssh-agent is a
process which holds your private keys in memory, so that you
authenticate them once and then you don't have to type your ssh
passphrase again (until the next time you reboot, or close down the
ssh-agent). See 'man ssh-agent' for details.

ssh-agent creates an SSH_AUTH_SOCK environment variable, which holds
the socket number that any ssh processes can use to communicate with
the ssh-agent. It sounds as if you had an ssh-agent running at some
point, but that it shut down for some reason. So, there was a left-
over SSH_AUTH_SOCK environment variable, but no agent listening on
that socket.

So, when cap tries to use ssh to connect to your server, ssh tries to
talk to an ssh-agent that isn't there, and it fails. By unsetting
SSH_AUTH_SOCK, ssh processes will not try to connect to the missing
agent, and will fall back to negotiating the connection themselves,
which works fine.

Of course, I could be talking utter rubbish!

Cheers

David
This topic is locked and can not be replied to.