Error Connecting to GitoLite from Staging Server - ECONNREFUSED Deploy Error

Question

I'm having a little trouble trying to deploy a previously working project to the development server. I did not set-up the system however I do have all the credentials I need (I think).

After trying cap staging deploy I get so far and then it produces an error. Please see below:

triggering load callbacks
  * 2012-11-20 14:52:20 executing `staging'
    triggering start callbacks for `deploy'
  * 2012-11-20 14:52:20 executing `multistage:ensure'
Identity added: /Users/XXX/.ssh/id_rsa (/Users/XXX/.ssh/id_rsa)
  * 2012-11-20 14:52:20 executing `deploy'
  * 2012-11-20 14:52:20 executing `deploy:update'
 ** transaction: start
  * 2012-11-20 14:52:20 executing `deploy:update_code'
    executing locally: "git ls-remote ssh://gitolite@repo1:2011/proto_projectname_rails HEAD"
    command finished in 2864ms
  * executing "git clone -q ssh://gitolite@repo1:2011/proto_projectname_rails /var/www/projectname/releases/20121120145223 && cd /var/www/projectname/releases/20121120145223 && git checkout -q -b deploy 0598169ed07015279bd78efa91f25ed3e5edcad8 && (echo 0598169ed07015279bd78efa91f25ed3e5edcad8 > /var/www/projectname/releases/20121120145223/REVISION)"
    servers: ["repo2"]
*** [deploy:update_code] rolling back
  * executing "rm -rf /var/www/projectname/releases/20121120145223; true"
    servers: ["repo2"]
 ** [deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))
connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))

deploy.rb

set :stages, %w(staging production)
set :default_stage, "production"
require 'capistrano/ext/multistage'

set :application, "projectname"

set :scm, :git
set :repository,  "ssh://gitolite@repo1:2011/proto_projectname_rails"

I am honestly confused as to why a previously working version no longer functions.

Any help, advice or guidance or this matter is more than welcome.

Thank you

As a side note, yes it has always been the non-standard port of 2011 and is in my .ssh/config

Edit:

There are 2 servers involved in this process.

After running the following locally and on 2nd server I do get a response.

git ls-remote ssh://gitolite@repo1:2011/proto_projectname_rails

It returns;

0598169ed07015279bd78efa91f25ed3e5edcad8    HEAD
0598169ed07015279bd78efa91f25ed3e5edcad8    refs/heads/master

Edit: Runs on 2 servers. Repo1 and Repo2

cap deploy:check

Returns

   triggering load callbacks
 * 2012-11-27 21:02:36 executing `production'
 triggering start callbacks for `deploy:check'
 * 2012-11-27 21:02:36 executing `multistage:ensure'
  Identity added: /Users/x/.ssh/id_rsa (/Users/x/.ssh/id_rsa)
 * 2012-11-27 21:02:36 executing `deploy:check'
 * executing "test -d /var/www/projectname/releases"
   servers: ["repo2"]
   connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))

Solved

It turns out that it was being rejected due to the 2nd servers port number. Adding

set :port, 1893

The bounty is still open to anyone that can explain this.

Why could always SSH into the server, without editing my ssh/config at anytime, and were other machines able to deploy, with the exact same deploy and staging files, but I could not until I explicitly added the port number?

Answer 1

See update 2 below for the final answer to this question

OK, so first thing to test is whether, from your local computer, you can run git ls-remote ssh://gitolite@XXX:2011 -- it should return the list of references from the repo. If this doesn't work, it should probably give you a similar error (connection refused or similar), and then you probably need to figure out why from whoever is hosting the git repo.

If it does work locally, then you might need to set some or all of these options, depending on how you want to access git while you're deploying. I think the forward_agent option is needed unless your deploy server/user can log into the repository directly.

set :deploy_via, :remote_cache
default_run_options[:pty] = true
ssh_options[:forward_agent] = true

and I described how to set that up in this other stack overflow answer.

The key thing to remember about capistrano is that most commands are really just standard shell commands, but are passed to the remote server using ssh, as in ssh user@server.example.com <command>, so that would be another thing to test if you can't get this working.

Update based on information added to original question:

When you make a TCP connection to a server using a URL, you specify protocol, host address, and port number. Port number is implied for many protocols. E.g. ssh://1.2.3.4 specifies the protocol SSH whose standard port is 22, thus would be the same as ssh://1.2.3.4:22. I am guessing your git provider assigns different ports to different repositories (perhaps on the same IP address) in order to route requests, so for each of your repos you may have a different port number. Because it is not the default port for the ssh protocol being used, it must be specified as part of the URL (and it seems you can override this in capistrano using set :port).

It does not make sense to me that you would have multiple git repositories (repo1 and repo2) for the same project so perhaps I need to understand in what cases this happens, but in any case, the reason for the error was that your server could not make an TCP connection to the git host given the supplied URL.

Update 2 OK, so it turns out that repo1 is a git repository. It is hosted at a non-standard SSH port (2011) so this needs to embedded in the URL whenever referring to the ssh URL of the git server.

However, repo2 is actually just the application server that runs the Rails app (hosted by the same source as the git repo), and it is also available on a non-standard ssh port (1893). In order to ssh into this server, you will need to specify the port using ssh -p 1893 ... -- and since this is how capistrano connects, so will it. This is why adding the set :port, 1893 is required.