Lee/Peter: Here's what I ended up doing to get cap deploy to work again. I'm not especially pleased with this solution, but it'll do for now.
I settled on this in my deploy.rb file: > set :repository, "https://[email protected]/hikari17/molex_acq.git"; I then set the same thing in my [remote "origin"] entry in /.git/config: > url = https://[email protected]/hikari17/molex_acq.git On my production server, in the .git directory for my rails_root/current, there's an independent .git/config file, which manages to stay intact from deploy to deploy, and in it I've set: [remote "origin"] url = https://hikari17:[email protected]/hikari17/molex_acq.git So now when I cap deploy from my development box command line, I'm only prompted for my github password once, after that, the deploy process proceeds without any authorization problems. I don't completely understand why I can't leave the password out and be prompted for it like I was before, but it works, and I can finally deploy again. Thanks for all your help, Dean Richardson On Wednesday, August 14, 2013 12:40:27 AM UTC-5, Lee Hambley wrote: > > Peter, > > deploy_via => :copy will probably be one of the first things we try - if > we stay with cap2. Having taken a look at Dean's code already it appears > that as he's on Cap2, and locally, and the servers will access the > repository differently, he'll need to switch to deploy_via => :copy, or > specify both :repository and :local_repository, (with different > combinations of https auth with the username and password in the URL, and > scm_username and scm_password to go over the git protocol). > > With Cap3 the local machine doesn't require github access, and has more > robust handling of authentication (and better error handling) on the server > side, so we might just skip cap2 debugging, and jump right into Cap3, it > should be mainline by the end of the month, anyway. > > Lee Hambley > -- > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On 14 August 2013 02:25, Peter Booth <[email protected] <javascript:>>wrote: > >> I'm neither a capistrano or a git expert, but I have used the combination >> on at least a dozen projects, some of which involved deploys into DMZs or >> through proxies. >> I did a quick search through my deploy.rb files and noticed the following: >> >> 1. Some used scm :git with deploy_via :copy to deploy into a DMZ >> 2. Some used scm :none with :copy >> 3. Some used scm_passphrase with git URLs >> >> From memory, a git: URL uses the git socket protocol not ssh, which means >> that it should be proxy-able. >> >> Capistrano supports local git repositories. Perhaps there's value in >> separating the repo you deploy from and github? >> >> I hope that you get to the bottom of this and we can all learn something >> from it. >> >> Peter >> (Big fan of capistrano and github) >> >> Sent from my iPhone >> >> On Aug 13, 2013, at 10:52 AM, Dean Richardson >> <[email protected]<javascript:>> >> wrote: >> >> Lee: >> >> I seem to recall that github steered me away from that approach because >> my production deploy server is behind a corporate firewall and needs to use >> a proxy login/password to access github. >> >> Basically, though, you're saying I should use >> >> [email protected]:username/molex_acq.git >> >> as my repository in deploy.rb, correct? >> >> The line that's currently commented out in the deploy.rb I posted? >> >> Thanks, >> >> Dean >> >> On Tuesday, August 13, 2013 9:40:30 AM UTC-5, Lee Hambley wrote: >>> >>> You must use ssh:// clone url with deploy keys, as the https clone >>> endpoint doesn't accept any config paramaters. >>> >>> If you have deploy keys, they'll only work with ssh://, annoyingly if >>> you have git username and password, that'll also only work with ssh://. (so >>> I recommend using deploy keys) >>> >>> Lee Hambley >>> -- >>> http://lee.hambley.name/ >>> +49 (0) 170 298 5667 >>> >>> >>> On 12 August 2013 22:44, Dean Richardson <[email protected]> wrote: >>> >>>> Hi again: >>>> >>>> I'm still looking for help debugging an authorization problem accessing >>>> github from my deploy server as part of the cap deploy process. Github >>>> support tells me it's a Capistrano problem and that I need to seek the >>>> solution here. :) >>>> >>>> To review, I'm running ruby 1.9.3p392 [i386-mingw32] on windows 7; I'm >>>> also running Capistrano v2.15.5. I've made some progress since my previous >>>> post, but the result is unfortunately still the same. >>>> >>>> I've had success deploying an earlier rails app to my production >>>> (Ubuntu 12.04) server using cap deploy for many months now. >>>> >>>> But my attempt to deploy a new rails app to the same server using cap >>>> deploy has raised a number of errors. They all seem to arise when >>>> capistrano tries to access my git repository from the production server. >>>> >>>> Deploy.rb: http://pastie.org/**8**200290 <http://pastie.org/8200290> >>>> Capfile: http://pastie.org/**820**0301 <http://pastie.org/8200301> >>>> >>>> Here's what I'm getting in response to "cap deploy" at the git bash >>>> command line on my Windows development machine: >>>> >>>> c:\Sites\rails_projects\molex_**acq>cap deploy >>>>>> >>>>> * ←[32m2013-08-12 15:39:24 executing `deploy'←[0m >>>>> >>>>> * ←[32m2013-08-12 15:39:24 executing `deploy:update'←[0m >>>>> >>>>> ** transaction: start >>>>> >>>>> * ←[32m2013-08-12 15:39:24 executing `deploy:update_code'←[0m >>>>> >>>>> updating the cached checkout on all servers >>>>> >>>>> ←[33mexecuting locally: "git ls-remote http://[email protected]/ >>>>>> **username/m <http://[email protected]/username/m> >>>>> >>>>> olex_acq.git master"←[0m >>>>> >>>>> Password for 'http://[email protected]': >>>>> >>>>> ←[2;37mcommand finished in 12259ms←[0m >>>>> >>>>> * ←[33mexecuting "if [ -d /home/dean/rails_projects/** >>>>>> molex_acq/shared/cached-co >>>>> >>>>> py ]; then cd /home/dean/rails_projects/**molex_acq/shared/cached-copy >>>>>> && git fetc >>>>> >>>>> h -q origin && git fetch --tags -q origin && git reset -q --hard >>>>>> efc8ed513b24026 >>>>> >>>>> 640d395151d03b3fdb755cfb6 && git clean -q -d -x -f; else git clone -q >>>>>> -b master >>>>> >>>>> http://[email protected]/**username/molex_acq.git<http://[email protected]/username/molex_acq.git>/home/dean/rails_projects/mole >>>>> >>>>> x_acq/shared/cached-copy && cd /home/dean/rails_projects/** >>>>>> molex_acq/shared/cached >>>>> >>>>> -copy && git checkout -q -b deploy >>>>> efc8ed513b24026640d395151d03b3**fdb755cfb6; >>>>>> fi" >>>>> >>>>> ←[0m >>>>> >>>>> servers: ["10.24.5.50"] >>>>> >>>>> [10.24.5.50] executing command >>>>> >>>>> ** [10.24.5.50 :: out] Password for 'http://[email protected]': >>>>> >>>>> Password: >>>>> >>>>> ** [10.24.5.50 :: out] >>>>> >>>>> ** ←[31m[10.24.5.50 :: out] fatal: Authentication failed←[0m >>>>> >>>>> ←[2;37mcommand finished in 6130ms←[0m >>>>> >>>>> *** [←[34mdeploy:update_code←[0m] ←[34mrolling back←[0m >>>>> >>>>> * ←[33mexecuting "rm -rf /home/dean/rails_projects/** >>>>>> molex_acq/releases/20130812 >>>>> >>>>> 203944; true"←[0m >>>>> >>>>> servers: ["10.24.5.50"] >>>>> >>>>> [10.24.5.50] executing command >>>>> >>>>> ←[2;37mcommand finished in 44ms←[0m >>>>> >>>>> failed: "sh -c 'if [ -d >>>>> /home/dean/rails_projects/**molex_acq/shared/cached-copy >>>>>> ] >>>>> >>>>> ; then cd /home/dean/rails_projects/**molex_acq/shared/cached-copy && >>>>>> git fetch -q >>>>> >>>>> origin && git fetch --tags -q origin && git reset -q --hard >>>>>> efc8ed513b24026640d >>>>> >>>>> 395151d03b3fdb755cfb6 && git clean -q -d -x -f; else git clone -q -b >>>>>> master http >>>>> >>>>> ://[email protected]/**username/molex_acq.git<http://[email protected]/username/molex_acq.git>/home/dean/rails_projects/ >>>>>> **molex_ac >>>>> >>>>> q/shared/cached-copy && cd /home/dean/rails_projects/** >>>>>> molex_acq/shared/cached-cop >>>>> >>>>> y && git checkout -q -b deploy >>>>> efc8ed513b24026640d395151d03b3**fdb755cfb6; >>>>>> fi'" on >>>>> >>>>> 10.24.5.50 >>>>> >>>>> >>>>>> c:\Sites\rails_projects\molex_**acq> >>>>> >>>>> >>>> I'm trying to figure out why my response to the password prompt works >>>> the first time (when the deploy script is running git ls-remote) but not >>>> the second time (when the deploy script is trying to check for the cached >>>> copy of my app on the deploy server.) My deploy.rb contains my correct >>>> github password, and capistrano prompts me for that password at several >>>> locations, and I'm entering that password correctly. I did fiddle with my >>>> ssh keys recently in attempting to deploy my new app to heroku, so that >>>> might be where things are going wrong. Any suggestions on how to debug >>>> this >>>> process? >>>> >>>> I'm particularly interested in understanding what exactly capistrano is >>>> trying to do at each step so I can attempt to reproduce the process step >>>> by >>>> step. >>>> >>>> Thanks very much, >>>> >>>> Dean Richardson >>>> Molex.com >>>> >>>> -- >>>> -- >>>> * You received this message because you are subscribed to the Google >>>> Groups "Capistrano" group. >>>> * To post to this group, send email to [email protected] >>>> * To unsubscribe from this group, send email to capistrano+...@** >>>> googlegroups.com For more options, visit this group at >>>> http://groups.google.com/**group/capistrano?hl=en<http://groups.google.com/group/capistrano?hl=en> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Capistrano" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to capistrano+...@**googlegroups.com. >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> >>> -- >> -- >> * You received this message because you are subscribed to the Google >> Groups "Capistrano" group. >> * To post to this group, send email to [email protected]<javascript:> >> * To unsubscribe from this group, send email to >> [email protected] <javascript:> For more options, visit >> this group at http://groups.google.com/group/capistrano?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- >> -- >> * You received this message because you are subscribed to the Google >> Groups "Capistrano" group. >> * To post to this group, send email to [email protected]<javascript:> >> * To unsubscribe from this group, send email to >> [email protected] <javascript:> For more options, visit >> this group at http://groups.google.com/group/capistrano?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
