It would be incredibly hacky, but I suppose that you could do some sort
of analysis of the /etc/sudoers file to figure out if the logged in user
was restricted to a specific command set.
I'll keep thinking about it.
Wes
Jamis Buck wrote:
> I apologize for that. This issue you're encountering is caused by the
> "fix" for the problem where doing sudo("foo && bar") would execute foo
> via sudo, but not bar.
>
> You can try doing this:
>
> default_run_options[:shell] = false
>
> But I'm sure that'll have other issues, too. (I suspect deploy:setup
> will have a good chance of not working correctly if you run without
> wrapping the command in a shell.)
>
> Otherwise, you can try running without sudo:
>
> set :use_sudo, false
>
> But again, that may break things, too, especially if your environment
> requires the use of sudo. At this point, I don't know how to fix both
> of these issues--have sudo work when the sudoer is restricted to a
> specific command-set, AND allow things like sudo("foo && bar") to work
> as expected. If anyone has any suggestions, I'd love to hear them.
>
> - Jamis
>
> On May 15, 2008, at 6:09 PM, Wes Gamble wrote:
>
>>
>> All,
>>
>> I recently ran my first deployment with cap 2.3 and noticed that my
>> custom sudo commands failed because there were being executed by
>> spawning a new shell and passing the command string to it, like so:
>>
>> /bin/sh -c '<command string from my deploy file>'
>>
>> I was able to resolve this by modifying my /etc/sudoers file and putting
>> "/bin/sh -c" in front of the command. But is there a way to suppress
>> the spawning of a new shell so that it works the way it did in 2.2?
>>
>> Thanks,
>> Wes
>>
>> >>
>
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
