Capistrano 2 update_code task not using sudo

capistranodeploymentruby-on-rails-3sudo

I'm using Capistrano 2(.15.4) to deploy rails applications (i know, trying to get to 3 but not quite there yet). We have a new server environment being set up, with IT preferring access through our own user and sudo'ing to the user to deploy as.

I've been testing using:

set :use_sudo, true
set :sudo, "sudo -u <user>"

It looks to me like sudo is working for manually-defined tasks that use the sudo command:

cap deploy:restart

...
triggering load callbacks
  * 2014-09-01 11:34:28 executing `deploy:restart'
  * executing "sudo -u <user> touch /path/to/deploy/current/tmp/restart.txt"
servers: ["hostname.com"]
...

Note that the deploy:restart functionality is manually defined as:

cmd = "touch #{current_path}/tmp/restart.txt"
sudo cmd

but it does NOT look like sudo kicks in for the automatic update_code task when deploying:

cap deploy

...
triggering load callbacks
  * 2014-09-01 10:14:32 executing `deploy'
  * 2014-09-01 10:14:32 executing `deploy:update'
 ** transaction: start
  * 2014-09-01 10:14:32 executing `deploy:update_code'
    updating the cached checkout on all servers
...
copying the cached version to /path/to/deploy/20140901171450
  * executing "cp -RPp /path/to/deploy/shared/cached-copy /path/to/deploy/releases/20140901171450 && (echo 690 > /path/to/deploy/releases/20140901171450/REVISION)"
servers: ["hostname.com"]
[hostname.com] executing command
 ** [out :: hostname] cp: cannot create directory `/path/to/deploy/releases/20140901171450': Permission denied
command finished in 918ms
*** [deploy:update_code] rolling back
  * executing "rm -rf /path/to/deploy/releases/20140901171450; true"
servers: ["hostname.com"]
[hostname.com] executing command
command finished in 922ms
...

Any guidance on why sudo isn't applied to the update_code task would be much appreciated, thanks!

Best Answer

Capistrano is not implemented to support the use case you describe. You can try setting the git variable to include sudo (set :git, 'sudo git'), however you will then likely run into the issue of your forwarded authentication key not being available to the sudo'ed git command.

Perhaps a more fruitful strategy involves adding your user to the group of the owner of the folder that cap is trying to check out into, and then setting the group writable permission on that folder.

Related Topic