Avoid sudo password prompt

[Chuck]

Last week, I successfully deployed with Capistrano with no password
prompts. I set up a cron job to run a script that went to the right
directory and then did a 'cap deploy'. Since then, it has been
prompting me for a sudo password. Is there a way to avoid this?

[Jochen Kaechelin]

You can edit /etc/sudoers on your linux box and add:

deploy_username ALL=(ALL) NOPASSWD: ALL

--
Jochen

[Mason Browne]

You can either set your sudo password in your deploy file so it's able
to handle the password request, or give your sudoer the ability to
sudo commands without a password.

[Chuck]

I have that set up exactly in the sudoers file as specified and if I'm
logged into the machine, I can sudo at will with no password prompt.
However, the capistrano script still prompts me for a password.

[Chuck]

Ok, that was strange. I updated capistrano (2.2.0 to 2.3.0) to the
latest version and it started working...

Go figure.

[gobigdave]

Strange, I had the opposite effect. I upgraded to 2.3.0, and now I
have to enter my sudo password. I have the following in my sudoers
file:

dave ALL = NOPASSWD: /usr/local/bin/god

dave is the user I'm using for this example. Run "sudo god status" on
the remote box, and there is no prompt for a password. However, when
cap runs "sudo("god restart mongrels")", I get prompted for a
password.

My deploy setup worked perfectly for a while, and the only thing that
changed was capistrano (2.2 -> 2.3).

On May 13, 4:53 pm, Chuck <ch...@lostjungles.com> wrote:
> Ok, that was strange. I updated capistrano (2.2.0 to 2.3.0) to the
> latest version and it started working...
>
> Go figure.
>
> On May 13, 2:41 pm, Chuck <ch...@lostjungles.com> wrote:
>
> > I have that set up exactly in the sudoers file as specified and if I'm

> > logged into the machine, I cansudoat will with no  password prompt.

> > However, the capistrano script still prompts me for a password.
>
> > On May 13, 2:32 pm, Jochen Kaechelin <giss...@humanized.de> wrote:
>
> > > Am 13.05.2008 um 22:26 schrieb Chuck:
>
> > > > Last week, I successfully deployed with Capistrano with no password
> > > > prompts. I set up a cron job to run a script that went to the right
> > > > directory and then did a 'cap deploy'. Since then, it has been

> > > > prompting me for asudopassword. Is there a way to avoid this?

[Jamis Buck]

Yeah, this is my bad. I was trying to be clever, to make it so that
the sudo helper would work as many people expect when you try to chain
multiple commands together in a single sudo call, e.g.:

sudo("cd /path/to/something && do_something")

In cap 2.2 and earlier that wouldn't work, because only the first
command would execute as sudo, but not the latter. Cap 2.3 silently
wraps your command in an sh -e "..." invocation...which (duh) breaks
when you've got sudo configured to only execute certain commands. I'll
be rolling this back in the next release, but this also means that
deploy:setup won't use sudo (again), because it currently does "umask
0220 && mkdir", which breaks with the older sudo model.

I'm open to suggestions on this. These kinds of regressions are really
demotivating for me. :(

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[Wes Gamble]

Hmm..

I guess the question is: Which use of sudo is the more common/legitimate case - the case where all commands are available via sudo or the case where the set of commands is limited?  I used to think the latter until I got my Mac a couple months back and discovered that I have sudo access for everything.

Wes

-------------- Original message from Jamis Buck <ja...@37signals.com>: --------------

[Jamis Buck]

I think the best route is to assume that people aren't giving global
sudo access to themselves. I'm just stuck now wondering how to make a
sudo helper that can execute chained commands correctly. This feels
way too complicated. :(

- Jamis

[Wes Gamble]

This could be ugly, but when Cap is presented with "sudo x && y", could that actually be executed as "sudo x && sudo y"?

I haven't tested it and have no idea if it would work with regard to both running both commands successfully and returning the correct values for success/failure on the first command for short circuiting purposes.

Wes

[Jamis Buck]

The real sticky one this when you're using conditionals or something,
e.g.

if [ -x /path/to/something ]; then cd /path/to; something; fi

First of all, you can't do "sudo if [...] ... fi", because "if" isn't
a command, it's shell syntax. You either need to do "sudo sh -e '...'"
or you do "if [...]; then sudo cd /path/to; sudo something; fi".

Basically, I don't know that there is a good way to do this generally.
Maybe cap just needs to expose a simple way to "inject" sudo into
commands...

- Jamis

[David Masover]

Well, one possibility would be to try to parse everything, and be smart:

if sudo [ -x /path/to/something ]; then cd /path/to; sudo something; fi

Yes, /usr/bin/[ does exist, at least for me. But this way lies madness -- that 'cd' obviously must be run in some kind of shell to affect the following commands, but the user running the command might not even have access to that path.

One way would be to make sudo simply stick 'sudo ' on the beginning of a 'run' command. This won't work for everything, but it's simple enough to be predictable, once you know what it does. A 'sudosh' command could be added to make it run a '/bin/sh', also.

As for 'injecting' sudo, I don't think it gets any simpler than just typing 'sudo' -- maybe with a shell quoting helper, so you could do:

run "if [ ! -d /path/to/something ]; then sudo #{shellquote('rm -f /path/to/something && umask whatever && mkdir /path/to/something')}; fi"

The idea is that shellquote() would escape anything needed to make it a single literal argument (most likely just wrap it in single quotes and deal with those). Should be nestable. Something like it probably already exists (probably even in Cap), but I haven't looked.

Of course, that syntax is hideous, but I'm out of ideas...  maybe something like SQL placeholder substitution?

[Jamis Buck]

I like the SQL placeholder comparison. That might be a more sane
approach than some of the options I've been considering.

- Jamis

[John Trupiano]

A basic first step might just be to allow cap's sudo() function to
take an array of commands. The expectation of the user would be that
these individual commands would be prepended with sudo and &&'d
together. I realize this only handles one (common) case, but it would
certainly serve me well. The question then moves to how to define a
syntax to properly handle complex chains (||, &&, etc.).

e.g. syntax

cmds = [
"do_something_dangerous",
"do_something_else_dangerous",
"stand_up",
"take_a_bow"
]
sudo(cmds) # --> run("sudo do_something_dangerous && sudo
do_something_else_dangerous && sudo stand_up && sudo take_a_bow")

Regarding ifs, it might be ugly, but you'd just create two separate
arrays......if_true_commands and else_commands.

Just a thought.....I'm actually putting in a helper function for me
right now to do just this. Any thoughts?

-John

> smime.p7s
> 3KDownload

[Jamis Buck]

The next release actually makes it so you can do this:

run "#{sudo} something && #{sudo} something else"

In other words, the sudo() helper, if called without arguments (or with
only a hash of options) will return the command needed to invoke sudo.
Otherwise, it works as it always had.

http://github.com/jamis/capistrano/commit/b45290e6ae3acce465ab5b7b8a82b7ad73a022e3

- Jamis