Capistrano and Certificates

All,

I’m setting up a deployment script with Capistrano at the moment, and
am running into some trouble when it attempts to pull the code down
from the SVN server when I run the deploy task.

The SVN server runs over https, and the problem seems to be when I get
asked whether I want to accept or reject the certificate. I hit ‘p’ to
accept the certificate permanently, but then the whole process stalls.
Nothing is changed on the server, and it never recovers. I’ve pasted
below the stack trace that is printed out when I terminate.

Has anyone else run into this before? Are there any workarounds? I’m
running on OS X with Ruby 1.8.4. The setup task ran perfectly.

Thanks,
David

/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/command.rb:39:in
sleep' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/command.rb:39:inprocess!’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/command.rb:26:in
process!' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:176:inrun’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:425:in
execute_on_servers' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:173:inrun’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/scm/base.rb:41:in
run_checkout' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/scm/subversion.rb:73:incheckout’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/recipes/standard.rb:70:in
load' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:125:inupdate_code’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/recipes/standard.rb:141:in
load' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:329:intransaction’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/recipes/standard.rb:140:in
load' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/actor.rb:125:indeploy’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/cli.rb:246:in
execute_recipes!' /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/cli.rb:246:inexecute_recipes!’
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/capistrano/cli.rb:221:in
execute!' ./lib/tasks/capistrano.rake:15:incap’
./lib/tasks/capistrano.rake:26
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in
execute' /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:inexecute’
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in invoke' /usr/local/lib/ruby/1.8/thread.rb:135:insynchronize’
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in invoke' /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:inrun’
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run’
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7
/usr/local/bin/rake:18

David,

Please submit this as a Capistrano bug at http://dev.rubyonrails.org.
Capistrano is, by default, not aware of the certificate prompt. It
needs to be made aware of this. (A patch would be wonderful, if
anyone has the time.)

Thanks,

Jamis

David T. wrote:

Has anyone else run into this before? Are there any workarounds? I’m
running on OS X with Ruby 1.8.4. The setup task ran perfectly.

I’ve faced this problem in other contexts. A workaround is to save the
certificate by manually logging into your server and performing a svn
checkout. During this preliminary checkout, you will save your
certificate permanently on the server.

After having done this you will no longer be asked when you do the
checkout remotely through capistrano.

Ray

Jamis: I’ve submitted this as a ticket as requested:
http://dev.rubyonrails.org/ticket/4792

I’ve faced this problem in other contexts. A workaround is to save the
certificate by manually logging into your server and performing a svn
checkout. During this preliminary checkout, you will save your
certificate permanently on the server.

Ray: Thanks - I was focusing so hard on what was going wrong that I
couldn’t see the obvious solution!

Best,
David