A little poking finds that lib/ansible/utils/__init__.py is the only place 
that uses SUDO-SUCCESS and then only in make_sudo_cmd. That function is 
called in a lot of connection_plugins files.  I can't work out how the 
script module is implemented based on a cursory look because it is not like 
any of the other modules I have looked at.

I hope that this helps somewhat...

Adam 

On Tuesday, January 7, 2014 4:14:46 PM UTC-8, Michael DeHaan wrote:
>
> This is already done here
>
> https://github.com/ansible/ansible/issues/5533
>
>
>
>
> On Tue, Jan 7, 2014 at 7:13 PM, Adam Morris <[email protected]<javascript:>
> > wrote:
>
>> One of my colleagues just ran into this same thing on 1.4.4.  It looks 
>> like the script module is picking up the results of sudo and claiming 
>> success no matter what the script actually claims.  
>>
>> I'll report this issue on github tomorrow morning if Luciano hasn't.
>>
>> Adam
>>
>>
>> On Tuesday, January 7, 2014 9:30:24 AM UTC-8, Michael DeHaan wrote:
>>
>>> Might be specific to the script module and the way it's implemented, but 
>>> yes, this seems bug-ish.
>>>
>>> Please report this one on github even if you don't get a chance to dive 
>>> in.
>>>
>>> I would probably look to see what's normally absorbing this message and 
>>> why it doesn't in the script module case, provided you can see this 
>>> behavior on the development branch.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 7, 2014 at 11:34 AM, Luciano Cavalheiro da Silva <
>>> [email protected]> wrote:
>>>
>>>> Hello,
>>>>
>>>> I've possibly found a bug, but I would like to confirm before creating 
>>>> a ticket.
>>>>
>>>> I'm trying to capture output of a remote script executed using the 
>>>> 'script' module. If sudo is not enabled, everything works just fine and I 
>>>> can use result.stdout. However, if sudo is enabled, sudo "success_key" is 
>>>> embedded into result.stdout if I'm using the script module. The same 
>>>> problem do not affect 'command' module.
>>>>
>>>> This was tested with ansible 1.4.3 (pip), as well as the development 
>>>> version from git. It used to work just fine with ansible 1.3.4.
>>>>
>>>>
>>>> The following playbook demonstrates the issue:
>>>>
>>>> ---
>>>> #
>>>> - name: "Test with sudo and register"
>>>>   hosts: www-php5-4
>>>>
>>>>   tasks:
>>>>     - command: /bin/ls /
>>>>       register: result
>>>>
>>>>     - debug: "var=result.stdout"
>>>>
>>>>     - script: files/scripts/list_dir "/"
>>>>       register: result
>>>>
>>>>     - debug: "var=result.stdout"
>>>>
>>>> Where list_dir could be any script.
>>>>
>>>>
>>>> Here is the verbose output:
>>>>
>>>> TASK: [command /bin/ls /] ******************************
>>>> ***********************
>>>> changed: [www-php5-4] => {"changed": true, "cmd": ["/bin/ls", "/"], 
>>>> "delta": "0:00:00.009592", "end": "2014-01-07 13:58:27.294366", "rc": 0, 
>>>> "start": "2014-01-07 13:58:27.284774", "stderr": "", "stdout": 
>>>> "bin\nboot\ndev\netc\nhome\nhome-sys\ninitrd.img\nlib\nlib64
>>>> \nlost+found\nmedia\nmnt\nopt\nproc\nroot\nrun\nsbin\
>>>> nselinux\nsrv\nsys\ntmp\nusr\nvar\nvmlinuz"}
>>>>
>>>> TASK: [debug var=result.stdout] ******************************
>>>> *****************
>>>> ok: [www-php5-4] => {
>>>>     "result.stdout": "bin\nboot\ndev\netc\nhome\nho
>>>> me-sys\ninitrd.img\nlib\nlib64\nlost+found\nmedia\nmnt\nopt\
>>>> nproc\nroot\nrun\nsbin\nselinux\nsrv\nsys\ntmp\nusr\nvar\nvmlinuz"
>>>> }
>>>>
>>>> TASK: [script files/scripts/list_dir "/"] ******************************
>>>> *******
>>>> changed: [www-php5-4] => {"changed": true, "rc": 0, "stderr": "", 
>>>> "stdout": "\r\nSUDO-SUCCESS-wbzcrtmosfpuylypyhbeoaxovzwkmgjw\r\nbin 
>>>> etc\tinitrd.img  lost+found\topt   run      srv  usr\r\nboot home\tlib\t   
>>>>  media\tproc  sbin     sys  var\r\ndev   home-sys\tlib64\t    mnt\t\troot 
>>>>  selinux  tmp  vmlinuz\r\n"}
>>>>
>>>> TASK: [debug var=result.stdout] ******************************
>>>> *****************
>>>> ok: [www-php5-4] => {
>>>>     "result.stdout": 
>>>> "\r\nSUDO-SUCCESS-wbzcrtmosfpuylypyhbeoaxovzwkmgjw\r\nbin 
>>>> etc\tinitrd.img  lost+found\topt   run      srv  usr\r\nboot home\tlib\t   
>>>>  media\tproc  sbin     sys  var\r\ndev   home-sys\tlib64\t    mnt\t\troot 
>>>>  selinux  tmp  vmlinuz\r\n"
>>>> }
>>>>
>>>> I think "SUDO-SUCCESS-wbzcrtmosfpuylypyhbeoaxovzwkmgjw" do not belong 
>>>> there. Would you confirm this is a bug?
>>>>
>>>>
>>>> If you have some hint on where possibly is the problem, I would not 
>>>> mind to dig a bit further and submit a patch.
>>>>
>>>> Best regards,
>>>>
>>>> Luciano
>>>>
>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Michael DeHaan <[email protected]>
>>>
>>> CTO, AnsibleWorks, Inc.
>>> http://www.ansibleworks.com/
>>>
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Michael DeHaan <[email protected] <javascript:>>
> CTO, AnsibleWorks, Inc.
> http://www.ansibleworks.com/
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to