Reputation: 18250
What is the proper way to deploy:setup
and to do a cold deploy with Capistrano?
Using
deploy.rb
this is my scenario:
when running deploy:setup
, Capistrano makes use of root privileges to prepare the directory structure for deployment:
$ cap deploy:setup
* 2013-02-28 14:50:21 executing `deploy:setup'
* executing "sudo -p 'sudo password: ' mkdir -p /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids"
servers: ["example.com"]
[example.com] executing command
command finished in 29ms
* executing "sudo -p 'sudo password: ' chmod g+w /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids"
servers: ["example.com"]
[example.com] executing command
command finished in 11ms
yet upon deploy:cold
Capistrano attempts to checkout (from git in this case) and write as the vagrant
user – the user specified in deploy.rb
:
$ cap deploy:cold
* 2013-02-28 14:50:47 executing `deploy:cold'
* 2013-02-28 14:50:47 executing `deploy:update'
** transaction: start
* 2013-02-28 14:50:47 executing `deploy:update_code'
updating the cached checkout on all servers
executing locally: "git ls-remote [email protected]:mariusbutuc/realtime-faye.git master"
command finished in 2360ms
* executing "if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q [email protected]:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi"
servers: ["example.com"]
[example.com] executing command
** [example.com :: out] fatal: could not create work tree dir '/home/vagrant/example/shared/cached-copy'.: Permission denied
command finished in 26ms
*** [deploy:update_code] rolling back
* executing "rm -rf /home/vagrant/example/releases/20130228195049; true"
servers: ["example.com"]
[example.com] executing command
command finished in 7ms
failed: "sh -c 'if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q [email protected]:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi'" on example.com
Of course, the deploy:check
report bares no surprises: the vagrant
user cannot write in the directories created during deploy:setup
since the two users belong to different groups – root:root
versus vagrant:vagrant
:
$ cap deploy:check
[...]
The following dependencies failed. Please check them and try again:
--> You do not have permissions to write to `/home/vagrant/example'. (example.com)
--> You do not have permissions to write to `/home/vagrant/example/releases'. (example.com)
--> `/home/vagrant/example/shared' is not writable (example.com)
What is the reasoning behind this, and what prerequisite is not satisfied yet so the deployment passes this issue?
Upvotes: 3
Views: 1388
Reputation: 18250
Since there are no group setting in Capistrano my workaround is to extend such a setting, for example:
set :user, 'vagrant'
set :group, 'vagrant'
and then create a task to "fix" the ownership after running deploy:setup
:
after "deploy:setup", :setup_ownership
task :setup_ownership do
run "#{sudo} chown -R #{user}:#{group} #{deploy_to} && chmod -R g+s #{deploy_to}"
end
But the only thing better than fixing an issue is not having it in the first place, so Stuart's answer is both wiser and more elegant.
Upvotes: 0
Reputation: 11588
The deploy:setup
task probably should not be using sudo
to create the app directory, since that is likely causing it to be owned by root
.
You can turn that off in your deploy.rb
file with:
set :use_sudo, false
Upvotes: 1