Nevermind to this one, I discovered it was a stupid error on my part on
the server (like puppet had overwritten something I didn't realize it had).
On 7/11/2012 2:16 PM, Jonathan Rochkind wrote:
So I have capistrano using a certain account name for remote
operations.
On the remote servers, I have that account name authorized to do -
certain- sudo operations without a password (but not to do ALL without
a password, that seems dangerous).
If I log in directly to that server, as that user, and do a `sudo
something`, then it works fine, without a password.
But if I tell capistrano to do:
run "#{sudo} something", :pty => true
Then it's still prompting me for a password. To verify that it's not
just cap's "#{sudo}" wrapper, i did the (not good)
run "sudo something", :pty => true
---still prompted for a password (directly by the remote server, in a
way that doesn't work to enter it, but that's what #{sudo} is for, I
know, this was just a test to figure out what's going on).
I think that the _way_ capistrano is executing the command (inside
it's own 'sh') is getting around my attempts to set up passwordless
sudo for only certain commands.
How do I figure out _exactly_ what cap is executing in a shell when
I'm telling it to "run #{sudo} something"?
Or, cutting to the chase, is there any way people have succesfully set
things up to allow the capistrano user to do _some_ things with
passwordless sudo, but not _everything_? Everything seems like a
terrible security problem -- as would allowing it to do "sudo sh"
which is, I'm afraid, what it does, but I don't want to allow that
passwordless, right? So, any suggestions?
--
* 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
