As I responded to someone else in another topic: this is totally my bad. I'll be reverting this in the next release, but it means that deploy:setup (which finally uses sudo in 2.3) will have to revert to non-sudo in the next release unless someone has a good idea of how to make something like sudo("umask 0220 && mkdir") work. :(

- Jamis

On May 16, 2008, at 6:04 AM, Geoff wrote:


How did putting /bin/sh -c in front of the command help? I've tried
this in visudo and I was still being prompted for the password, even
when entered it said the user did not have permission to run the
command as root.

Checking the sudoers file could work but you'd need to make sure you
checked for a restricted command set for the user and all the groups
it belongs to.

For now to get my deployments working I've reverted to 2.2.0

Geoff

On May 16, 5:53 am, Wes Gamble <[EMAIL PROTECTED]> wrote:
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
-~----------~----~----~----~------~----~------~--~---


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to