capistrano deploy user vs rackbox app_user

[agentdave]

I got to this via the tutorial at http://teohm.github.io/blog/2013/04/17/chef-cookbooks-for-busy-ruby-developers/ and am wondering what I missed. I followed the examples pretty closely, but while I got a deployable application, it didn't actually run. The nginx logs indicate the following error:

connect() failed (111: Connection refused) while connecting to upstream

I managed to get it working by setting the ownership of the /home/apps/application directory to apps:apps. Indeed, the passenger runit script is set to use apps as both the owner and the group. Unfortunately, the best I can get without tearing capistrano apart is for the application to be deployed as deploy:apps.

I'm thinking the simplest is to either give the apps user sudo privileges and deploy with that user or to provide my own version of rackbox's passenger runit template that specifies deploy:apps as the user:owner for running passenger.

Of course, the most likely thing, as no one else seems to be encountering this issue, is that I've missed something obvious...

[agentdave]

I'm also able to get around this problem by doing the following in the capistrano deploy.rb file:

namespace :deploy do
  task :set_permissions, :roles => :app do
    run "sudo chown -R apps:apps #{release_path}"
    run "sudo chown -R apps:apps #{shared_path}"
  end

  task :unset_permissions, :roles => :app do
    run "sudo chown -R deploy:apps #{shared_path}"
  end
end

after "deploy:update_code", "deploy:set_permissions"
before "deploy:update_code", "deploy:unset_permissions"

The first cap deploy with this will work without unset_permissions, but it's necessary on the following runs. Note that this also requires :use_sudo == true, which I know is not recommended. It seems more than a little wrong to do things this way, but I like the idea of being able to keep the deploy user only involved in the deployment step, rather than leave it hanging around as the running user for passenger.