Errno::ENOENT: No such file or directory - /tmp/502/SSHKeychain.socket

[Nathan Youngman]

I am running into an error like this <http://groups.google.com/group/
capistrano/browse_thread/thread/de04f810873ac9e0/87d0d2223de29dab?
lnk=gst&q=SSHKeychain.socket#87d0d2223de29dab> while doing a cap
deploy:setup (using Capistrano 2.1 on Mac OS X).

servers: ["dbserver", "revelation", "james"]
connection failed for: dbserver (Errno::ENOENT: No such file or
directory - /tmp/502/SSHKeychain.socket), james (Errno::ENOENT: No
such file or directory - /tmp/502/SSHKeychain.socket), revelation
(Errno::ENOENT: No such file or directory - /tmp/502/
SSHKeychain.socket)

I can ssh to apply-deploy@james from the command line and immediately
be logged in (it took a bit to get the keys working, but now they
are). apply-deploy is my :user in deploy.rb. I'm not entirely sure why
setup is trying to access all 3 servers, since the folders only need
to be on the app server.

I'm not currently using ssh-agent or a gui equivalent, as my key has
no passphrase. I have no ssh_options[:keys] though it has the same
error with one (assuming i put it in the right place and all).

My key file has a custom name, apply_deploy_id_dsa (and .pub) and it
wasn't created here (it came from the Debian server, but it is DSA).
Among a few other things, my ~/.ssh/config specifies:

Host james
IdentityFile ~/.ssh/apply_deploy_id_dsa

Which is generally how it finds the right key, though perhaps Net:SSH
doesn't look there? Still, ssh_options[:keys] doesn't seem to work
either.
ssh_options[:keys] = "~/.ssh/apply_deploy_id_dsa"

Thanks for your assistance.
- Nathan.

[Jamis Buck]

It looks like you were using SSHKeychain at one point, which sets an
environment variable (SSH_AUTH_SOCK) indicating the socket to use
when querying it. However, SSHKeychain isn't running anymore, but the
environment variable still exists, and things are blowing up when the
agent tries to connect to the socket (which doesn't exist). You might
just try removing that environment variable and trying again.

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[Nathan Youngman]

Thanks Jamis,

It took me a bit to find where this was set. It is in ~/.macosx/
environment.plist, and since that was the only thing there, I just
removed it. I had to restart as well (or at least a log-off) to get
rid of the setting.

I'm getting a password prompt, but at least it's past that error.

~

A bit unrelated: where does cap deploy:setup create these folders? It
seems to want to put them on the web server, where as our setup is
that the web server (Apache) is just proxying to the app server
running mongrels, where the actual files should exist. Not sure if
that's the best setup, but it's the setup I need to work with. Should
I also need my deploy user on the web server in order to do some
things (restart apache?).

Thanks, Nathan.

[Jamis Buck]

By default, Capistrano's deployment recipes assume you are deploying
to your web server, your app server, and your database server. (This
is because some of the tasks, like deploy:web:disable and
deploy:web:enable) assume that your app exists on the web server. If,
however, you don't need those tasks, feel free to declare your roles
thus:

role :web, "server1", "server2", :no_release => true

The ":no_release => true" bit tells Capistrano not to deploy files to
those servers. Note, though, that because Capistrano was not designed
with that deployment scenario in mind, there may be other gotchas; be
prepared to override tasks as you discover them failing due to
assumptions changing.

- Jamis

[Nathan Youngman]

Hey Jamis,

Thanks for the tip. Btw, I very much appreciated your interview on
Godbit.

Ciao, Nathan.