Andrew,

Thanks for that! That really helped me make some progress. Im still
stuck though, and Im not able to figure out why.
After setting up the permissions like you suggested, I ran cap
deploy:setup, it worked fine and cap deploy:check which asked me for
my server pwd once and declared that I seem to have my dependencies in
place.
But when I run cap deploy, this is the sequence of events
***************************************
DEBUG -- net.ssh.authentication.methods.publickey[]: trying publickey
(<rsa_signature>)
...
DEBUG -- net.ssh.authentication.session[]: allowed methods:
publickey,password
ERROR -- net.ssh.authentication.session[]: all authorization methods
failed (tried publickey)
Then asks for my server pwd
...
DEBUG -- net.ssh.transport.session[]: connection established
...
DEBUG -- net.ssh.transport.algorithms[]: exchanging keys
...
... beginning authentication of '<user in set_user line>'
...
...trying password
...password succeeded
...
[ahref.in] executing command
...
[ahref.in :: out] Initialized empty Git repository in <deploy_to_path>/
shared/cached-copy/.git/
...
INFO -- net.ssh.connection.session[]: channel_data: 0 33b
[ahref.in :: out] Permission denied (publickey).
...
[ahref.in :: out] fatal: The remote end hung up unexpectedly
...
command finished
*** [deploy:update_code] rolling back
***************************************
I have removed the public key in the server and the matching key my
local machine so that it defaults to password authentication everytime
I connect to it (I would prefer reverting back to keys though, just
not using them now to figure out what I need for successful Cap
deployment).
And yet, it seems to try to authenticate using public key and fails,
fatally.
Can you read more into this debug trace than I can? really appreciate
the guidance so far. Just hoping you can see me through! :)

@Jamis, thanks for putting that in perspective. Guess thats something
I have to keep in mind for such similar requirements in the future, IF
I can get this to work of course! :)

On 14 Feb, 01:52, Andrew Fiedler <[email protected]> wrote:
> Ram,
>
> Yeah, the problem is that /home/<username>/public_html/ahref.in is
> probably not writable by the user you have on the set user line in
> deploy.rb. When you do a "sudo mkdir /home/..." you are switching to
> root so there are no permissions errors. I'd change the ownership of
> everything in /home/<username>/public_html to the username that you
> are deploying as (on the set user line). You can do this by running
> "sudo chown <user on set user line>:<user on set user line>
> public_html/ -R" in your home directory. Note that the user name is
> specified twice with a colon in between. The second one is actually
> the user's group, but on ubuntu users are in their own groups. That
> should make cap deploy work without errors.
>
> -Andrew
>
> On 13 Feb, 10:00, Jamis Buck <[email protected]> wrote:
>
> > :use_sudo does not cause all commands to use sudo, only commands like
> > deploy:setup and deploy:restart. The primary deploy methods (which copy
> > the code to the server and update the symlink, etc.) are never run as sudo.
>
> > I've mentioned this before on the list, but deploy:setup is kind of
> > broken: if you use sudo for deploy:setup, then you need to manually fix
> > the permissions so the directories are writable. If you don't use sudo,
> > you need to fix the permissions on the parent directory first, or the
> > setup fails. It's a catch 22, and I don't know of a good, flexible way
> > to make it work.
>
> > - Jamis
>
> > On 2/13/09 4:35 AM, Ram wrote:
>
> > > Andrew,
>
> > > Thanks for you reply. I followed your instructions.
> > > The ** [out :: delugeventures.com] <the_user_you_are_logged_in_as from
> > > whoami> part shows the user on the set_user line correctly.
> > > I then ssh connected to my server and did "mkdir
> > > <folder_that_cap_is_trying_to_create>" and permissions failed.
> > > I did "sudo mkdir <folder_that_cap_is_trying_to_create>" and entered
> > > my passwrd and the folder got created.
>
> > > Now how do I effect this in my deploy.rb? This is my deploy.rb now.
> > > ******************************************
> > > set :application, "ahref.in"
> > > set :user, "<server_username>"
> > > set :repository,  "[email protected]:<gitusername>/ahref.in.git"
> > > set :branch, "master"
> > > set :port, <port_number>
> > > default_run_options[:pty] = true
> > > set :scm_verbose, true
>
> > > ssh_options[:username] = user
> > > ssh_options[:verbose] = :debug
>
> > > set :use_sudo, true
> > > set :deploy_to, "/home/#{user}/public_html/#{application}"
>
> > > set :scm, :git
> > > set :deploy_via, :remote_cache
> > > set :runner, user
>
> > > role :app, application
> > > role :web, application
> > > role :db,  application, :primary => true
>
> > > task :before_update_code, :roles => :app do
> > >     run "whoami"
> > > end
> > > ******************************************
>
> > > I assumed "set :use_sudo, true" will use sudo on all commands on the
> > > server and ask me for the server password. But it still fails.
>
> > > FYI
> > > **************
> > > cap deploy o/p
>
> > > ** [ahref.in :: out] fatal: could not create work tree dir '/home/
> > > <username>/public_html/ahref.in/shared/cached-copy'.
> > > **************
> > > cap deploy:check o/p
>
> > > The following dependencies failed. Please check them and try again:
> > > --> You do not have permissions to write to `/home/<username>/
> > > public_html/ahref.in'. (<server_name>)
> > > --> You do not have permissions to write to `/home/<username>/
> > > public_html/ahref.in/releases'. (<server_name>)
> > > --> `/home/<username>/public_html/ahref.in/shared' is not writable
> > > (<server_name>)
> > > **************
>
> > > On 12 Feb, 20:35, Andrew Fiedler <[email protected]> wrote:
> > >> Ram,
>
> > >> Are you trying to set up SSH with public/private keys so you don't
> > >> need to type a password? I'm not really sure how to get that working
> > >> but I have capistrano working fine with basic password authentication.
> > >> To help you debug, try adding to your deploy.rb in the
> > >> "namespace :deploy do" section this:
>
> > >> task :before_update_code, :roles => :app do
> > >>     run "whoami"
> > >> end
>
> > >> When you run cap deploy, you should get something like:
> > >> * executing "whoami"
> > >>     servers: ["yourserver.com"]
> > >> Password: <you type password here>
> > >>     [yourserver.com] executing command
> > >>  ** [out :: delugeventures.com] <the_user_you_are_logged_in_as from
> > >> whoami>
>
> > >> which should be the user on your "set :user" line. Then I'd manually
> > >> ssh to your server as that user and try to create the directories
> > >> manually that are failing on your mkdir lines below to debug the
> > >> permissions issues.
>
> > >> Hope that helps,
> > >> Andrew
>
> > >> On Feb 12, 5:27 am, Ram <[email protected]> wrote:
>
> > >>> OK, ive been making progress with diagnosing this. Posting my updates.
> > >>> Hope someone knows the fix.
> > >>> First off, im using 2 DIFFERENT ssh public keys for my Slicehost
> > >>> server and for the github server.
> > >>> And on the Slicehost server, although it does not ask for my password
> > >>> when I ssh connect, it DOES require my password for creating
> > >>> directories/files.
> > >>> My deploy.rb looks like this right now.
> > >>> set :application, "ahref.in"
> > >>> set :user, "<slicehost_server_username_with_write_permissions>"
> > >>> set :repository,  "[email protected]:<gitusername>/ahref.in.git"
> > >>> set :branch, "master"
> > >>> set :port, <port_number>
> > >>> default_run_options[:pty] = true
> > >>> set :scm_verbose, true
> > >>> ssh_options[:username] = user
> > >>> ssh_options[:verbose] = :debug
> > >>> #set :run_method, :run
> > >>> #set :ssh_options, { :forward_agent => true }
> > >>> set :use_sudo, false
> > >>> set :deploy_to, "/home/#{user}/public_html/#{application}"
> > >>> set :scm, :git
> > >>> set :deploy_via, :remote_cache
> > >>> #The user that starts the Mongrel(?) instances
> > >>> set :runner, user
> > >>> role :app, application
> > >>> role :web, application
> > >>> role :db,  application, :primary => true
> > >>> This thread too discusses this problemhttp://ahref.in/33870andI
> > >>> realised I had set :use_sudo true when I did cap deploy:setup. I thus
> > >>> deleted the files/dirs created by Cap on the server, set :use_sudo
> > >>> false and ran cap deploy:setup again but I still get permission denied
> > >>> errors.
> > >>>  ** [out :: ahref.in] mkdir: cannot create directory `/home/<user>/
> > >>> public_html/ahref.in/releases': Permission denied
> > >>>  ** [out :: ahref.in] mkdir: cannot create directory `/home/<user>/
> > >>> public_html/ahref.in/shared': Permission denied
> > >>>  ** [out :: ahref.in] mkdir: cannot create directory `/home/<user>/
> > >>> public_html/ahref.in/shared': Permission denied
> > >>>  ** [out :: ahref.in] mkdir: cannot create directory `/home/<user>/
> > >>> public_html/ahref.in/shared': Permission denied
> > >>>  ** [out :: ahref.in] mkdir: cannot create directory `/home/<user>/
> > >>> public_html/ahref.in/shared': Permission denied
> > >>> Now if I set use_sudo to true for deploy:setup, the setup goes fine
> > >>> but cap deploy does not work. Permission denied errors. The final
> > >>> dependency o/p for cap deploy:check is this
> > >>> The following dependencies failed. Please check them and try again:
> > >>> --> You do not have permissions to write to `/home/<user>/public_html/
> > >>> ahref.in'. (<server_name>)
> > >>> --> You do not have permissions to write to `/home/<user>/public_html/
> > >>> ahref.in/releases'. (<server_name>)
> > >>> --> `/home/<user>/public_html/ahref.in/shared' is not writable
> > >>> (<server_name>)
> > >>> In the SSH Debug o/p, I can see that Cap is using the public key for
> > >>> authentication and the authentication goes through but mkdir seems to
> > >>> fail. Like I mentioned at first, the slicehost server still requirs me
> > >>> to provide the pwd to create dirs/files and I think thats where this
> > >>> is failing. Thats my best guess at this problem. Although I dont have
> > >>> a solution.
> > >>> I even tried SSH Agents and set :ssh_options, { :forward_agent =>
> > >>> true } according to this posthttp://ahref.in/1f632butthatdintwork
> > >>> either.
> > >>> This too is a thread that discusses almost the same 
> > >>> problemhttp://ahref.in/3b4af.
> > >>> The Original poster talks about how Cap seems to try to connect to the
> > >>> server using the first HostName specified in the ~/.ssh/config file.
> > >>> Thats something to note I guess. But I even gave that a wild shot and
> > >>> that dint work.
> > >>> How can I make Cap ssh to my server using the username i provide
> > >>> instead of the public key? ssh_options[:username] = user doesnt seem
> > >>> to work.
> > >>> Is there at least a quick fix for this problem right now that any of
> > >>> you can suggest?
> > >>> Thanks a bunch for reading this through even if you cant help! :)
> > >>> Cheers!
> > >>> On Feb 12, 11:17 am, Ram <[email protected]> wrote:
> > >>>> @ MAthias Meyer,
> > >>>> Oh and yes, I DID do deploy:setup first and I can see the shared and
> > >>>> releases directories on my server
> > >>>> On Feb 12, 11:11 am, Ram <[email protected]> wrote:
> > >>>>> @Mathias Meyer,
> > >>>>> Regarding the other question, I realised i had not installed Git on
> > >>>>> the server and I did that. This post shows the error I got AFTER
> > >>>>> installing Git on the server.
> > >>>>> About write permissions, well im really not sure how the deploy.rb
> > >>>>> works but her it is if it helps,
> > >>>>> set :application, "ahref.in"
> > >>>>> set :user, "<username>" #this is the username for my slicehost server
> > >>>>> that has write permissions on the server
> > >>>>> set :repository,  "[email protected]:vinaysesh/ahref.in.git"
> > >>>>> set :port, 4001
> > >>>>> default_run_options[:pty] = true
> > >>>>> #set :use_sudo, true # Not sure what this should be set to. TRUE and
> > >>>>> FALSE dont work anyway. I get the same error.
> > >>>>> set :deploy_to, "/home/<username>/public_html/#{application}"
> > >>>>> # If you
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---

Reply via email to