Separate tasks by permissions rather than config target

[patcon]

It seems that these tasks are assuming liberal access to sudo command, which not everyone would be willing to give to the deploy user.

For example, those using configuration management tools like Chef would likely provision the server and do all the appropriate setup as root, and then only give the deploy user what it needs.

I would recommend storing all the config and init files in the shared_path (perhaps building and syncing all those config in one task), and then have smaller tasks for generating the symlinks with root. That way, someone using a config management tool can create those high-privilege symlinks with it, and just use cap to update that files in shared_path when required.

Would that make sense? I would really not like to give my deploy user anything but the most minimal of access to sudo (ie. just /etc/init.d/nginx reload)

[bruno-]

Hi, thanks for getting involved. This is an interesting question that touches into a lot of areas. I've labeled this with 'opinions wanted' because we better discuss this well before taking any action. Also, it would be good to hear the opinion of others.

Yes, this plugin liberally uses passwordless sudo and this is something that should be discussed.

Here are the things I personally wouldn't like to give up on:

• minimal or no configuration for both single and multi-server deployments
• no manual ssh to the server requred
• accessible to beginners (those that manually scrapped a server and do not know what the word "provisioning" means)

Given the above constraints I'm not sure I'd first go with the big update to this plugin.

These solutions come to my mind though:

• advise writing custom capistrano tasks for those users that do not want to use sudo.
• create a separate plugin for "advanced" users that would not require sudo. This plugin could implement everything @patcon mentioned above.
• provide a no_sudo flag. Tasks would be done differently without `sudo.

Thoughs? Feedback?

[patcon]

I totally agree that I love how simple this setup is for most people -- i wouldn't want to change that.

I wasn't thinking my suggestion would even change anything for those who don't care, but I was more wondering whether we could decompose both the unicorn and nginx setup tasks each into a "config setup" task (where config is copied into shared_path), and a "create symlink" task (where symlinking in /etc/init.d and /etc/nginx/sites-available happens). So what is theoretically two tasks now ("setup nginx" and "setup unicorn") is now 4 subtasks, with wrappers that allow the same simplicity with have now, for those who don't care.

The one other change that's wrapped up with this is also moving config/unicorn.rb into shared. But since we're specifically pointing to the config in unicorn_init anyhow, if shouldn't matter, right? (A config management tool will be wrestling with capistrano if unicorn.rb in the repo itself.)

[tomasz-krol]

Hi @patcon I have a deployer user on my server and I didn't want to give him sudo access to everything. I wrote simple scripts that reload nginx or symlink unicorn init file to /etc/init.d, added those scripts to sudoers for deployer user and run with sudo without password. Now I'm sure that he didn't stop my whole nginx, he can just reload it. I also moved unicorn and nginx file to shared directory. Maybe you may have a look at this commit: https://github.com/tomasz-krol/capistrano-unicorn-nginx/commit/89e307f49d6ace21874d367ba8b3d6a2f7327566

I'm not a server ninja, but I think it's a quite good approach. It's now in a test phase. Please tell what you think about that.

[patcon]

Thanks! I'm not using this right now, but I'm sure someone will find your experience useful later :)