Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Deployment from Git on HTTPS fails to use credentials #384

Closed
ain opened this Issue · 23 comments

3 participants

@ain

The below deploy.rb works, but prompts for username and password twice ignoring scm_username and scm_password:

require "bundler/capistrano"

set :application, "AppName"

set :scm_username, "username"
set :scm_password, "password"
set :scm, :git
set :branch, "master"

set :repository,  "https://repo-url.de:4442/git/repo.git"

set :deploy_via, "copy"
set :copy_cache, false
set :copy_exclude, [".git*", ".DS_Store", "nbproject"]

ssh_options[:forward_agent] = true
set :use_sudo, false
set :keep_releases, 5

task :production do
  set :user, "user"
  set :password, "passwd"
  set :deploy_to, "/var/www/passenger-site.de"
  role :web, "passenger-site.de"
  role :app, "passenger-site.de"
  role :db,  "passenger-site.de", :primary => true
  ssh_options[:port] = 2222
  set :env, "production"
end

namespace :deploy do

  task :restart, :roles => :app, :except => { :no_release => true } do
    run "cd #{current_path}; bundle exec rake assets:precompile"
    run "touch #{File.join(current_path,'tmp','restart.txt')}"
  end

end

ruby 1.8.7 (2012-10-12 patchlevel 371) [i686-darwin11]
Capistrano v2.12.0

@leehambley
Owner

No output logs?

@leehambley
Owner

You should use the method user@password:your-host.de:4222 - Git doesn't like giving http credentials.

@ain

Yeah, that worked, but only for passwords that have no special characters :(

And of course the format would then have to be user:password@your-host.de:4442

@leehambley
Owner
@ain

Yup. I'm using HTTPS over the auth framework and repo management. Also many of the SVN deployments I'm about to migrate over to Git did work seamlessly over HTTPS, would be nice to use more or less the same logic also for Git.

Let me know if there's anything I could test for you, I've got quite a few test-cases that use Capistrano across Rails and Symfony projects at slightly varying configurations and additional recipes.

@leehambley
Owner
@leehambley
Owner

Feedback? I'm closing here pending a bit more discussion.

@leehambley leehambley closed this
@leehambley leehambley reopened this
@ain

I've been trying to use Cap 3 to test it, but no success. Is it ready to be used or still work in progress?

The problem is the documentation, i.e. getting the connection to the stage doesn't seem to work for me, e.g.

server 'server.de', roles: %w{web app db}, port: 2222, keys: [File.join(ENV["HOME"], ".ssh", "id_rsa")]

Trace:

** Invoke staging (first_time)
** Execute staging
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Invoke deploy:ensure_stage (first_time)
** Execute deploy:ensure_stage
** Execute deploy:starting
** Invoke deploy:started (first_time)
** Execute deploy:started
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
cap aborted!
Connection refused - connect(2)
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `open'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `block in initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:52:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:97:in `timeout'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `new'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `start'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:124:in `ssh'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:42:in `upload!'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/capistrano-3.0.0.pre3/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in '
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `instance_exec'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `run'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/runners/parallel.rb:29:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
@leehambley
Owner
@ain

Could you post a sample config for v3?

@leehambley
Owner

The simplest thing that works, for me at least is:

Desktop  cap uptime
Password:
 INFO leehambley@localhost:22 has uptime 9:18  up 1 day, 17:39, 1 user, load averages: 0.79 0.97 1.13Desktop  cat Capfile
require 'capistrano/setup'

server 'localhost'

task :uptime do
  on roles(:all) do |host|
    info "#{host} has uptime #{capture(:uptime)}"
  end
end
@leehambley
Owner

And a second log with a remote server, just to prove that it's not a localhost fluke:

Desktop  grep -A3 "Host harrow" ~/.ssh/config
Host harrow
User <not so fast!>
HostName 78.46.106.75Desktop  cat Capfile
require 'capistrano/setup'

server 'harrow'

task :uptime do
  on roles(:all) do |host|
    info "#{host} has uptime #{capture(:uptime)}"
  end
endDesktop  !cap
➜  Desktop  cap uptime --trace --verbose
** Invoke uptime (first_time)
** Execute uptime
 INFO leehambley@harrow:22 has uptime 09:21:01 up 50 days, 14:41,  0 users,  load average: 0.08, 0.05, 0.05
@ain

As you can see from the log, it fails on git:wrapper. What's happening there? Are you uploading to /tmp… on the remote?

ain$ sudo cap staging deploy --trace
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit.rb:3: warning: already initialized constant SSHKit::StandardError
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/sshkit-0.0.25/lib/sshkit.rb:3: warning: previous definition of StandardError was here
** Invoke staging (first_time)
** Execute staging
** Invoke deploy (first_time)
** Execute deploy
** Invoke deploy:starting (first_time)
** Invoke deploy:ensure_stage (first_time)
** Execute deploy:ensure_stage
** Execute deploy:starting
** Invoke deploy:started (first_time)
** Execute deploy:started
** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
cap aborted!
Connection refused - connect(2)
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `open'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `block in initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:52:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/timeout.rb:97:in `timeout'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh/transport/session.rb:67:in `initialize'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `new'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/net-ssh-2.6.7/lib/net/ssh.rb:192:in `start'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:124:in `ssh'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:42:in `upload!'
/Users/ain/.rvm/rubies/ruby-2.0.0-p195/lib/ruby/gems/2.0.0/gems/capistrano-3.0.0.pre3/lib/capistrano/tasks/git.rake:11:in `block (3 levels) in '
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `instance_exec'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/backends/netssh.rb:16:in `run'
/Users/ain/.rvm/gems/ruby-2.0.0-p195/gems/sshkit-0.0.25/lib/sshkit/runners/parallel.rb:29:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
@seenmyfate
Owner

Could this be caused by SSHKit defaulting to port 22? I think in the current implementation it will only be parsed as part of the host string - server 'server.de:2222', roles: %w{web app db}

@leehambley
Owner
@ain

I still get the above trace and Connection refused even with the port in the host string. Since it's a key-based auth, I'm afraid the problem is there. On old Cap 2 deploy I always defined the keys with [File.join(ENV["HOME"], ".ssh", "id_rsa_wtmh")].

@leehambley
Owner
@ain

Ok so it seems the failure is in making a connection on a non-standard port with a key. I set the port in server and also adjusted SSH config to point to the identity:

Host server.de
User deployer
IndentityFile ~/.ssh/id_rsa_wtmh

but it's not picking it up, the result is the same as in the above trace, Connection refused.

@leehambley
Owner
@ain

NB! v3 label also applies to this topic, the latter part of it at least :)

@seenmyfate seenmyfate referenced this issue from a commit
@seenmyfate seenmyfate Support setting of SSHKit::Host variables
Variables passed to the `server` or `role` syntax are correctly
assigned on the SSHKit::Host instance:

    server 'example1.com', roles: %w{web app}, user: 'tomc', port: 2222
    server 'example2.com', roles: %w{web app}, keys: '~/.ssh/key'

Expect this to close issue #384
5d2fb93
@seenmyfate
Owner

@ain this last commit combined with the latest version of SSHKit will now correctly set the variables passed in port and key/keys - hopefully this will resolve your issue, please let me know how you get on

@ain

Connection is fine now!

Tested with a privileged user (no keys) and deployment user (keys) of limited privileges, on a non-standard port, connection was successful on both.

I've split the further issue I'm having to #507.

@leehambley
Owner

Whoohoo great, serves me right for reading emails in chronological order, great news guys!

@leehambley leehambley closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.