Hi Lee
before I make a ticket, I've been playing around with a number op
possibilities. I came up with a solution that fit my needs.
As explained above, I wanted to have 1 deployer for multiple projects.
That 1 deployer also has access to the repository. So the thing that
came to mind after my post, was the fact that sudo for the
deploy:check might work, but then again, pulling the code from
versioning would fail again. This becouse of the facts that with sudo,
the checkout/pull would happen as the admin_runner user that doesn't
have access to the repo. Not only that, If you would let the deployer
handle the checkout/pull, it wouldn't have sufficient rights to write
in the tree structure, since the tree structure would have
admin_runner permissions and the deployer would try to pull it's files
in it. So that was a no go.
So today, I started playing with the before and after filters in my
deploy.rb file. Don't ask me why I didn't do that before, I have no
clue. Maybe I was just thinking too much about the way that I deploy
now, instead of looking at everything that capistrano has to offer.
So this is the strategy that I came up with today:
Prerequisite:
* 1 deploy user (ex. deployer) with shell access . This user has
restricted sudo access to certain commands like mkdir, chmod, chown,
ln, touch, rm
* create the basic project structure where you want to deploy in.
Make sure the deployer has write permissions in that folder. eg ( /srv/
projectx/www) where the www folder belongs to the deployer.
Next up is creating your deploy receipe. Now, to shorten the
procedure, I have done the following:
* after deploy:setup I change the owner of deploy_to/* to the
deployer user using sudo (run "#{try_sudo} chown -R
deployer.deployer #{deploy_to}/*")
* after deploy I change the owner of current_path/ to the
admin_runner using sudo ( run "#{try_sudo} chown -R projectx.projectx
#{current_path}/" )
Now I can deploy as the deployer user and the projects get run as the
proper user.
Now I had to play with the permissions again when using
deploy:cleanup, deploy:rollback en deploy:rollback:code . Before those
actions I needed to restore the owner for all folders under releases/
back to the deployer, and after those actions just restore the owner
of the current_path folder back to the admin_runner .
So actually, the default deploy receipe is ok, no need for sudo. Just
create a few custom tasks that handle file / folder ownership and
permissions for you.
--
* 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
