Using `as` and sudo with NOPASSD and !requiretty

Inizia dalle posizioni dello stack trace in lib/sshkit/backends/abstract.rb e lib/sshkit/backends/netssh.rb, quindi confronta l’esempio as con il comando sudo esplicito. Il lavoro è completato quando viene documentato come ispezionare il comando generato da as e viene spiegato quale comportamento di sudoers è rilevante.

I'm having a lot of trouble using the as syntax. I realize this is more of a support request than a bug report, but the results of this might go into the documentation.

What doesn't work:

task :clear_cache do
    on roles :app do
        as :web1 do
           within shared_path do
              execute :rm, '-rf', 'src/cache/twig'
           end
        end
    end
end

However, this works:

task :clear_cache do
    on roles :app do
        within shared_path do
            execute :sudo, '-u', 'web1', :rm, '-rf', 'src/cache/twig'
        end
    end
end

My sudoers file looks like this:

Cmnd_Alias              CLEAR_CACHE = /usr/bin/whoami, /bin/rm -rf src/cache/twig
Defaults!CLEAR_CACHE    !requiretty
david                   ALL=(web1) NOPASSWD: CLEAR_CACHE                                   

I've been trying to use the debug log level in both capistrano and sshkit to figure out what the difference is between these two, more specifically how the as syntax executes the command, but all I ever got was:

** Invoke clear_cache (first_time)
** Execute clear_cache
00:00 clear_cache
      01 rm -rf src/cache/twig
      01 sudo: no tty present and no askpass program specified
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as david@remote-host: rm exit status: 1
rm stdout: Nothing written
rm stderr: sudo: no tty present and no askpass program specified
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/runners/parallel.rb:15:in `rescue in block (2 levels) in execute'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/runners/parallel.rb:11:in `block (2 levels) in execute'
SSHKit::Command::Failed: rm exit status: 1
rm stdout: Nothing written
rm stderr: sudo: no tty present and no askpass program specified
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/command.rb:100:in `exit_status='
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/netssh.rb:165:in `execute_command'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:141:in `block in create_command_and_execute'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:141:in `tap'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:141:in `create_command_and_execute'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:74:in `execute'
/home/kwisatz/1024/projects/a_project/Capfile:35:in `block (4 levels) in <top (required)>'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:85:in `within'
/home/kwisatz/1024/projects/a_project/Capfile:34:in `block (3 levels) in <top (required)>'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:112:in `as'
/home/kwisatz/1024/projects/a_project/Capfile:33:in `block (2 levels) in <top (required)>'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:29:in `instance_exec'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/backends/abstract.rb:29:in `run'
/home/kwisatz/1024/projects/a_project/.vendor/bundle/ruby/2.4.0/gems/sshkit-1.13.1/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => clear_cache

How can I see what exact command sshkit is running when using as ? I'd presume that it doesn't correspond to what I allowed in the sudoers file.