2012-02-23 16 views
5

Ricevo errori di autorizzazione durante il tentativo di distribuire l'app per le mie rails sul server di un amico. Sto correndo rails 3.1.3, ruby-1.9.2-p290, capistrano 2.11.2, Mac OS 10.6.8, e abbiamo impostato le chiavi ssh. Tuttavia, non possiamo capire da dove vengono i problemi di autorizzazione. Pensiamo che potrebbe essere che capistrano stia cercando di spingere il codice dal repository git AS THE GIT USER alla directory deploy, o qualcosa del genere. Ma questo è il nostro primo tentativo di schieramento, quindi non ne siamo sicuri. Qualsiasi aiuto sarebbe molto apprezzato!Problemi ssh durante l'implementazione con capistrano

Oh, ed ecco qualche dettaglio in più che il mio amico mi ha detto di specificare: appsrv-04.example.ca è il nome di dominio completo canonica del paese ospitante, e project.example.ca è un CNAME indicando per il record di appsrv-04.example.ca. Il file known_hosts per gli utenti git e deploy contiene tutte le apprv-04, appsrv-04.example.ca, project e project.example.ca.

Di seguito è riportato l'output della distribuzione in esecuzione: aggiornamento.

[[email protected]]~/Code/projectapi $ cap deploy:update 
* executing `deploy:update' 
    ** transaction: start 
    * executing `deploy:update_code' 
updating the cached checkout on all servers 
executing locally: "git ls-remote ssh://[email protected]/usr/local/git_root/projectapi.git master" 
Enter passphrase for key '/Users/user/.ssh/id_rsa': 
command finished in 4478ms 
* executing "if [ -d /usr/local/www/sites/project.example.ca/public/shared/cached-copy ]; then cd /usr/local/www/sites/project.example.ca/public/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard e71d220f299271522517f7b4f028a9275d53326a && git clean -q -d -x -f; else git clone -q ssh://[email protected]/usr/local/git_root/projectapi.git /usr/local/www/sites/project.example.ca/public/shared/cached-copy && cd /usr/local/www/sites/project.example.ca/public/shared/cached-copy && git checkout -q -b deploy e71d220f299271522517f7b4f028a9275d53326a; fi" 
servers: ["project.example.ca"] 
Enter passphrase for /Users/user/.ssh/id_dsa: 
[project.example.ca] executing command 
** [project.example.ca :: err] Permission denied, please try again. 
** [project.example.ca :: err] Permission denied, please try again. 
** [project.example.ca :: err] Permission denied (publickey,password). 
** [project.example.ca :: err] fatal: The remote end hung up unexpectedly 
    command finished in 650ms 
*** [deploy:update_code] rolling back 
* executing "rm -rf /usr/local/www/sites/project.example.ca/public/releases/20120222225453; true" 
servers: ["project.example.ca"] 
[project.example.ca] executing command 
command finished in 465ms 
failed: "rvm_path=/usr/local/rvm /usr/local/rvm/bin/rvm-shell '[email protected]' -c 'if [ -d /usr/local/www/sites/project.example.ca/public/shared/cached-copy ]; then cd /usr/local/www/sites/project.example.ca/public/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard e71d220f299271522517f7b4f028a9275d53326a && git clean -q -d -x -f; else git clone -q ssh://[email protected]/usr/local/git_root/projectapi.git /usr/local/www/sites/project.example.ca/public/shared/cached-copy && cd /usr/local/www/sites/project.example.ca/public/shared/cached-copy && git checkout -q -b deploy e71d220f299271522517f7b4f028a9275d53326a; fi'" on project.example.ca 

Ed ecco il mio file Deploy:

$:.unshift(File.expand_path('./lib', ENV['rvm_path'])) 
require "rvm/capistrano"   

set :application, "Project" 

set :scm, "git" 
set :repository, "ssh://[email protected]/usr/local/git_root/project.git" 
set :user, "deploy" 

#set :rvm_bin_path, "/usr/local/rvm/bin" 
set :rvm_ruby_string, "[email protected]" 

ssh_options[:forward_agent] = true 

set :branch, "master" 

set :deploy_via, :remote_cache 

set :deploy_to, "/usr/local/www/sites/project.example.ca/public/" 

set :use_sudo, false 

set :domain, 'project.example.ca' 

role :app, domain 
role :web, domain 
role :db, domain, :primary => true 

risposta

0

Problema risolto. L'host virtuale è stato creato clonando uno esistente e modificando l'IP. Ho aggiornato il file/etc/hosts per utilizzare il nuovo nome host, ma apparentemente non il nuovo IP. Quindi, quando l'utente di deploy stava provando a ssh come utente git ... stava fallendo perché non c'era nessun utente git sull'IP che stava usando.

14

Hai quasi certamente diagnosticato correttamente il problema; stai provando a controllare il repository github come utente deploy e la chiave inoltrata non viene impostata correttamente. Sembra che tu abbia forward_agent attivato in Capistrano ... stai aggiungendo la chiave al tuo agente in modo che venga inoltrata correttamente?

Provare a farlo con ssh-add ~/.ssh/id-rsa e distribuire di nuovo.

+0

Ho impostato forward_agent su false e provato, e ho ottenuto lo stesso risultato. In realtà non stiamo usando un agente ssh. Possiamo, se renderebbe la vita più facile. La mia domanda, quale utente ha bisogno di quali chiavi sono state aggiunte a quale agente? –

+1

Non si desidera impostare forward_agent su false. Il problema è probabilmente che il tuo repository github è privato, quindi è possibile accedervi solo tramite determinate chiavi SSH; il server non ha una chiave SSH consentita, quindi non può controllare il repository. L'utilizzo di forward_agent consente al tuo agente SSH di inoltrare la tua chiave privata al server, che utilizzerà la chiave SSH per controllare il repository da github. Impostare forward_agent su true e aggiungere la chiave SSH all'agente e il server remoto sarà in grado di scaricare correttamente il repository. – Veraticus

+0

Grazie per le vostre risposte. Ho provato a giocare con lo ssh-agent, ma finora senza successo. Possiamo provare la "spiegazione-come-mi-sono-cinque routine"? Il repository git e la distribuzione stanno accadendo sullo stesso server, sebbene nel deploy.rb utilizzino nomi host diversi. Il repository git viene raggiunto tramite il record A canonico, mentre l'implementazione avviene tramite un record CNAME che punta al record A. Questa è stata una decisione arbitraria e potrebbe essere facilmente modificata. –

Problemi correlati