sprinkle-tool / sprinkle

Sprinkle is a software provisioning tool you can use to build remote servers with. eg. to install a Rails, or Sinatra stack on a brand new slice directly after its been created
https://github.com/sprinkle-tool/sprinkle
MIT License
1.15k stars 138 forks source link

use_sudo should support :as => user syntax #103

Open koenpunt opened 11 years ago

koenpunt commented 11 years ago

To continue discussion at #85

An option in general or only for runner to run commands as a specific user.

joshgoebel commented 11 years ago

Were there installers other than runner you were using it with?

I like it as an option for runner, but I'm not sure I like wrapping all the commands in a sub-shell... I'd like to see commands.map instead of commands.join... I spent a lot of effort on really nice error handling and it works best when commands can be executed one at a time by the actor - so if one raises an error we know where the error was raised - unless you know another solution to that problem.

ghost commented 11 years ago

I second Josh's opinion on having :as_user as an option for runner.

However, it's not the only case. Now, I find myself in a case where I need to build applications using customised installers as a different user (let's say: prey). Also, I need to transfer some files (let's say: redis.conf) as root and then chmod/chown to redis:redis on Ubuntu and install rbenv (ok, that is a runner) under the deploy account. Those all in a single installation script. Would be much simpler if we could just tell the line to do it for me. That's only an idea, BTW.

Regards!

joshgoebel commented 11 years ago

Doesn't su require a password from STDIN if you aren't root already? Or is that configurable? Tell the line how? Some pseudo-code or a pseudo-package might be helpful to see.

joshgoebel commented 11 years ago

Honestly I think we'd want to hook this into our sudo framework, so it works everywhere sudo works now (actor, package, installer).

package "apache" do
use_sudo true, :as => "apache"
# or
runner "blah", :sudo => "apache"

Then sudo_cmd in coordination with the actors sudo_command would have to build out the proper command... one last caveat is that right now even if sudo is true installers can decide they don't need to do anything special, so they just don't call sudo_cmd... :as though seems like we'd want it to always force a sudo... so some additional logic is needed to make that happen.