capistrano - Remote multi-server automation tool A remote server automation and deployment tool written in Ruby.

Capistrano asks for password when deploying, despite SSH keys

My ssh keys are definitely set up correctly, as I'm never prompted for the password when using ssh. But capistrano still asks for a password when deploying with cap deploy. It doesn't ask for the password when I setup with cap deploy:setup though, strangely enough. It would make the deployment cycle so much smoother without a password prompt.

Specifics: I'm deploying a Sinatra app to a Dreamhost shared account (which uses Passenger). I had followed a tutorial for doing so long back, which worked perfectly back then. Something broke since. I'm using capistrano (2.5.9) and git version Here's my Capfile:

load 'deploy' if respond_to?(:namespace) # cap2 differentiator

set :user, 'ehsanul'
set :domain, 'jellly.com'

default_run_options[:pty] = true

# the rest should be good
set :repository,  "ehsanul@jellly.com:git/jellly.git"
set :deploy_to, "/home/ehsanul/jellly.com"
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'deploy'
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false

server domain, :app, :web

namespace :deploy do
  task :migrate do
    run "cd #{current_path}; /usr/bin/rake migrate environment=production"
  task :restart do
    run "touch #{current_path}/tmp/restart.txt"

after "deploy", "deploy:migrate"

And here's the output of what happens when I cap deploy, upto the password prompt:

$ cap deploy
  * executing `deploy'
  * executing `deploy:update'
 ** transaction: start
  * executing `deploy:update_code'
    updating the cached checkout on all servers
    executing locally: "git ls-remote ehsanul@jellly.com:git/jellly.git deploy"
  * executing "if [ -d /home/ehsanul/jellly.com/shared/cached-copy ]; then cd /home/ehsanul/jellly.com/shared/cached-copy && git fetch  origin && git reset  --hard ea744c77b0b939d5355ba2dc50ef1ec85f918d66 && git clean  -d -x -f; else git clone  --depth 1 ehsanul@jellly.com:git/jellly.git /home/ehsanul/jellly.com/shared/cached-copy && cd /home/ehsanul/jellly.com/shared/cached-copy && git checkout  -b deploy ea744c77b0b939d5355ba2dc50ef1ec85f918d66; fi"
    servers: ["jellly.com"]
    [jellly.com] executing command
 ** [jellly.com :: out] ehsanul@jellly.com's password:
 ** [jellly.com :: out]
 ** [jellly.com :: out] remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.

What could be broken?

Source: (StackOverflow)

How do I invoke one Capistrano task from another?

How do I invoke one Capistrano task from another?

For example:

task :foo do
  # stuff

task :bar do
  # INVOKE :foo

Source: (StackOverflow)

How can you check to see if a file exists (on the remote server) in Capistrano?

Like many others I've seen in the Googleverse, I fell victim to the File.exists? trap, which of course checks your local file system, not the server you are deploying to.

I found one result that used a shell hack like:

if [[ -d #{shared_path}/images ]]; then ...

but that doesn't sit well with me, unless it were wrapped nicely in a Ruby method.

Has anybody solved this elegantly?

Source: (StackOverflow)

Why won't bundler install JSON gem?

I get the following error when attempting to run cap production deploy.

DEBUG [dc362284]    Bundler::GemNotFound: Could not find json-1.8.1.gem for installation
DEBUG [dc362284]    An error occurred while installing json (1.8.1), and Bundler cannot continue.
DEBUG [dc362284]    Make sure that `gem install json -v '1.8.1'` succeeds before bundling.

It may be important to note that this deployment was working, than I upgraded to Ruby 2.1.0 to remove an encoding error. I upgraded locally which worked fine. I ran rvm install 2.1.0 and rvm use 2.1.0 then changed my .ruby-version file to reflect this Ruby upgrade.

The bundle install command works locally, but produces the same above error when I ssh onto the destination server and run this command.

If I run gem list I can see this in the list of gems.

jquery-rails (3.0.4)
json (1.8.1)
less (2.3.2)

If I try the recommended solution gem install json -v '1.8.1' Locally and on the destination server I get the following output:

Building native extensions.  This could take a while...
Successfully installed json-1.8.1
Parsing documentation for json-1.8.1
Done installing documentation for json after 0 seconds
1 gem installed

So it appears the gem is installed, right? Why is this happening? How can I solve this? Any help would be greatly appreciated.

Source: (StackOverflow)

Capistrano & Bash: ignore command exit status

I'm using Capistrano run a remote task. My task looks like this:

task :my_task do
  run "my_command"

My problem is that if my_command has an exit status != 0, then Capistrano considers it failed and exits. How can I make capistrano keep going when exit when the exit status is not 0? I've changed my_command to my_command;echo and it works but it feels like a hack.

Source: (StackOverflow)

How to Configure Capistrano to Deploy from Local Git Repository?

What changes do I need to make to the deploy.rb file below to make it deploy my app from a local git repo? If I can't deploy from a local repo, can I have capistrano use the working copying instead?

set :application, "my_app"
set :repository, "."
set :local_repository, "file:///path/to/application/.git"
set :deploy_to, "/data/www/apps/#{application}"
set :deploy_via, :copy
set :copy_cache, true
set :user, "dane"
set :use_sudo, false

set :scm, :git # Should I change this to :none
set :branch, "master"

Source: (StackOverflow)

getaddrinfo: nodename nor servname provided, or not known

I have a Ruby on Rails application that I am deploying on a computer running Mac OS X 10.6. The code where the problem arises is run by a delayed_job. The problem only occurs when it is run through delayed_job. If I run it within a console (rails console production) or call the API directly through cURL, it works without any problems. Also, the entire process works without issue in my development environment.

Basically, the code works in one place, but for some reason, fails where it has to work. I've searched and found a few resources, but none of the suggestions apply or make any difference. When I log into the server and run the commands, everything works. But for some reason when they are run/started by Capistrano, it doesn't work.

Any help is greatly appreciated.

Important notes:

  • Ruby version: 1.9.2-p0
  • Rails version: 3.0.1
  • delayed_job version: latest (from collectiveidea/delayed_job)
  • rest-client version: 1.6.1


class CallApi < Struct.new(:num)
  def perform
    log "Entering perform"
    apinum = num || 5
    log "ApiNum = #{apinum}"
    results = attempt(2,10) do
      ActiveSupport::JSON.decode(RestClient.get(API_URL, {:params => {:apinum => apinum}}))
    log "Results retrieved. (count: #{results.count})"

  def log(message)
    Delayed::Worker.logger.info "[CallApi] #{Time.now} - #{message}"

Environment Config (note: the url is fake, but of the same form as the real one):

API_URL = "http://api.example.org/api_endpoint"
# Originally, I had "http://" before the beginning, but found a
# post mentioning that Net::Http.start didn't like that.
# So I tried it both ways.
# The same error occurs regardless of if the "http://" is there.

Call where the error happens:

RestClient.get(API_URL, {:params => {:apinum => apinum}})


getaddrinfo: nodename nor servname provided, or not known
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `initialize'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `open'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `block in connect'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:44:in `timeout'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:87:in `timeout'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:644:in `connect'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:637:in `do_start'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/net/http.rb:626:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:166:in `transmit'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:60:in `execute'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient/request.rb:31:in `execute'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/rest-client-1.6.1/lib/restclient.rb:68:in `get'
/private/var/www/project-gemset/releases/20101109002137/lib/call_api.rb:7:in `block in perform'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/attempt-0.2.0/lib/attempt.rb:70:in `attempt'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/attempt-0.2.0/lib/attempt.rb:114:in `attempt'
/private/var/www/project-gemset/releases/20101109002137/lib/call_api.rb:6:in `perform'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/backend/base.rb:77:in `invoke_job'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:118:in `block (2 levels) in run'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/timeout.rb:57:in `timeout'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:118:in `block in run'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/benchmark.rb:309:in `realtime'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:117:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:176:in `reserve_and_run_one_job'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:102:in `block in work_off'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:101:in `times'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:101:in `work_off'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:76:in `block (2 levels) in start'
/Users/api/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/benchmark.rb:309:in `realtime'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:75:in `block in start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:72:in `loop'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/worker.rb:72:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:100:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:79:in `block in run_process'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:250:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:250:in `block in start_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/daemonize.rb:199:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/daemonize.rb:199:in `call_as_daemon'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:254:in `start_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application.rb:294:in `start'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:159:in `block (2 levels) in start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:158:in `fork'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:158:in `block in start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:157:in `each'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/application_group.rb:157:in `start_all'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/controller.rb:80:in `run'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons.rb:193:in `block in run_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in `call'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in `catch_exceptions'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/gems/daemons-1.1.0/lib/daemons.rb:192:in `run_proc'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:78:in `run_process'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:72:in `block in daemonize'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:70:in `times'
/Users/api/.rvm/gems/ruby-1.9.2-p0@project-gemset/bundler/gems/delayed_job-aba9905764c2/lib/delayed/command.rb:70:in `daemonize'
script/delayed_job:5:in `'

Source: (StackOverflow)

Capistrano SSH::AuthenticationFailed, not prompting for password

I've been using capistrano successfully for a while now and all of a sudden in every project I've lost the ability to deploy.


  • os X (Mavericks)
  • ruby 1.9.3p194
  • rvm (locally, not on server)
  • rails 3.2 and up
  • RubyGems 1.8.25

I'm not using rsa_keys or anything I want capistrano to prompt for user and password. Suddenly it has decided not to ask for a password, but does ask for user. Then it rolls back and gives me the following error.

[deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: sub.example.com (Net::SSH::AuthenticationFailed: Authentication failed for user user@sub.example.com)
connection failed for: sub.example.com (Net::SSH::AuthenticationFailed: Authentication failed for user user@sub.example.com)

This has occurred on my personal laptop and my iMac at work. It occurs when deploying to two different servers (both linux)

I'm completely at a loss here. Any ideas?

Source: (StackOverflow)

How to deploy to a single specific server using Capistrano

I have a system in production that has several servers in several roles. I would like to test a new app server by deploying to that specific server, without having to redeploy to every server in production. Is there a way to ask Capistrano to deploy to a specific server? Ideally I'd like to be able to run something like

cap SERVER=app2.example.com ROLE=app production deploy

if I just wanted to deploy to app2.example.com.


[update] I tried the solution suggested by wulong by executing:

cap HOSTS=app2.server.hostname ROLE=app qa deploy 

but capistrano seemed be trying to execute tasks for other roles on that server in addition to app tasks. Maybe I need to update my version of cap (I'm running v2.2.0)?

Source: (StackOverflow)

Rails 3 -- Bundler/Capistrano Errors

I have a basic Rails 3 app working locally on my development box, but want to test out deploying early on to make sure everything works. I'm using Capistrano to deploy.

When I run cap deploy (after all the other necessary setup), it breaks on this command with this error:

* executing 'bundle:install'
* executing "bundle install --gemfile /var/www/trex/releases/20100917172521/Gemfile --path /var/www/trex/shared/bundle --deployment --quiet --without development test"

servers: ["www.[my domain].com"]
[www.[my domain].com] executing command
** [out :: www.[my domain].com] sh: bundle: command not found
command finished

So it looks like it can't find the bundle command on the server.

However, when I log in to the server...

$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]
$ rails -v
Rails 3.0.0
$ bundle -v
Bundler version 1.0.0

...the bundle command works just fine.

What could be going wrong?


(Furthermore, for completeness:)

$ which ruby
$ which rails
$ which bundle

Source: (StackOverflow)

Bundler: You are trying to install in deployment mode after changing your Gemfile

I'm pretty new to bundler and capistrano, and I'm trying to use them together. When I try to deploy, I get the message:

You are trying to install in deployment mode after changing your Gemfile. Run `bundle install' elsewhere and add the updated Gemfile.lock to version control.

I don't know how to satisfy the system that's complaining, and I don't understand why the complaint is coming up because I read in the doc:

If a Gemfile.lock does exist, and you have updated your Gemfile(5), bundler will use the dependencies in the Gemfile.lock for all gems that you did not update, but will re-resolve the dependencies of gems that you did update. You can find more information about this update process below under CONSERVATIVE UPDATING.

I interpret that to mean that the Bundler can handle the fact that my Gemfile is not whatever it expected. Any help?

Specs: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, deploying to a Posix machine.

Edit: My Gemfile includes logic blocks like the following:

unless RbConfig::CONFIG['host_os'] === 'mingw32'
  # gem 'a' ...

Source: (StackOverflow)

Deploying a Git subdirectory in Capistrano

My master branch layout is like this:

/ <-- top level

/client <-- desktop client source files

/server <-- Rails app

What I'd like to do is only pull down the /server directory in my deploy.rb, but I can't seem to find any way to do that. The /client directory is huge, so setting up a hook to copy /server to / won't work very well, it needs to only pull down the Rails app.

Source: (StackOverflow)

Speed up assets:precompile with Rails 3.1/3.2 Capistrano deployment

My deployments are slow, they take at least 3 minutes. The slow Capistrano task during deploy is assets:precompile. This takes probably 99% of the total deploy time. How can I speed this up? Should I precompile my assets on my local machine and add them to my git repo?

Edit: Adding config.assets.initialize_on_precompile = false to my application.rb file dropped the precompile time with half a minute, but it is still slow.

Source: (StackOverflow)

Capistrano deploy fails after I changed the repository URL

I have a simple deployment via capistrano from a Git repository. At first I was deploying form GitHub, everything worked just fine. But then I moved my repository to BitBucket and now I'm getting

fatal: Could not parse object '9cfb...'.

The problem goes away once I change

set :deploy_via, :remote_cache


set :deploy_via, :copy

but that doesn't fix the problem, it only bypasses it. Is there any way I can tell capistrano to just drop the old cache?

Source: (StackOverflow)

Capistrano error tar: This does not look like a tar archive

 INFO [050fe961] Running mkdir -p /home/rails/rails-
capistrano/releases/20140114234157 on staging-rails
DEBUG [050fe961] Command: cd /home/rails/rails-capistrano/repo && ( PATH=/opt/ruby/bin:$PATH GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/rails/git-ssh.sh mkdir -p /home/rails/rails-capistrano/releases/20140114234157 )
 INFO [050fe961] Finished in 0.142 seconds with exit status 0 (successful).
 INFO [2dea2fe5] Running git archive feature/Capistrano | tar -x -C /home/rails/rails-capistrano/releases/20140114234157 on staging-rails
DEBUG [2dea2fe5] Command: cd /home/rails/rails-capistrano/repo && ( PATH=/opt/ruby/bin:$PATH GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/rails/git-ssh.sh git archive feature/Capistrano | tar -x -C /home/rails/rails-capistrano/releases/20140114234157 )
DEBUG [2dea2fe5]    fatal: Not a valid object name
DEBUG [2dea2fe5]    tar: This does not look like a tar archive
DEBUG [2dea2fe5]    tar: 
DEBUG [2dea2fe5]    Exiting with failure status due to previous errors      

I am confused about two things:

  1. Why is Capistrano running git archive here:
    git archive feature/Capistrano | tar -x -C /home/rails/rails-capistrano/releases/20140114234157

  2. Why is tar failing?

Source: (StackOverflow)