failed to parse: LDAP Config Summary

Archives Ansible Project
1

Hi,

Our current sudo configuration is using LDAP and has sudoers_debug 2 which gives a lot of debug output (we can’t change it).
This is possibly breaks ansible play:

fatal: => failed to parse: LDAP Config Summary

uri …skipped…

sudo: ldap_set_option: debug → 0
…skipped…
LDAP Config Summary

uri …skipped…

sudo: ldap_set_option: debug → 0
…skipped…
sudo: sudo_ldap_lookup(0)=0x02
{“msg”: “”, “changed”: false, “results”: [“unzip-6.0-1.el6.x86_64 providing unzip is already installed”, "wget-1.12-1.4.el6.x86_64 providing w

get is already installed", “glibc-2.12-1.80.el6_3.5.i686 providing glibc.i686 is already installed”], “rc”: 0}
FATAL: all hosts have already failed – aborting

My playbook:


> - name: Install packages
>   yum: name=${item} state=present
>   sudo: yes
>   with_items:
>     - unzip
>     - wget
>     - glibc.i686

Are there any workarounds without changing sudo debug level?

Thanks,
Dmitry
2

So unless there were some terminal copy/paste issues here, I’m not seeing a failed=True in there, nor a non-zero return code.

Was the failure on a different line perhaps or maybe something didn’t get pasted?

Can you show me the Ansible task header above the output where the failure was?

“fatal: => failed to parse: LDAP Config Summary”

perhaps it is where the string “LDAP Config Summary” occurs?

3

Hi Michael,

Start of play:

PLAY [playbook] *************************************************************
GATHERING FACTS ***************************************************************
ok: [hostname1]
TASK: [Install packages] ******************************************************
fatal: [hostname1] => failed to parse: LDAP Config Summary

End of play:

{“msg”: “”, “changed”: false, “results”: [“unzip-6.0-1.el6.x86_64 providing unzip is already installed”, “wget-1.12-1.4.el6.x86_64 providing w get is already installed”, “glibc-2.12-1.80.el6_3.5.i686 providing glibc.i686 is already installed”], “rc”: 0}

FATAL: all hosts have already failed – aborting
PLAY RECAP ********************************************************************
to retry, use: --limit @/var/tmp/ansible/endeca.retry
hostname1 : ok=1 changed=0 unreachable=1 failed=0

Some more lines from sudo output around LDAP Config Summary

sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=unix,dc=domain,dc=com
LDAP Config Summary

uri ldap://hostname ldap:hostname
ldap_version 3

Regards,
Dmitry

4

Ah, I see. You are getting spewage from the yum process in your standard output for some reason.

Ansible 1.2 contains some code to look for the start of JSON in some events, which may help you in this case. It will skip down and start parsing at the first “{”.

If you are not using 1.2 (and actually this might be in 1.1, but I forget), that might be helpful.

If you are still getting parse errors, let me know, it’s in the middle of the output or already printed a “{” and we may have to do some fiddling.

5

I’m using latest 1.2
In sudo output there are no any extra {. Where is this code about catching JSON in ansible? I will try to check that too

Regards,
Dmitry

6

Sure thing, the fact that it’s inline may mean we need to pass more arguments to yum to surpress that output, unless possibly LDAP is doing something like a “broadcast to all terminals” or something, I’d hope redirection and usage of the library was sufficient.

(Also, what OS are you using? If an older yum, is the repoquery binary available? The code takes a bit different track if not.)

Line 242 (at present) here:

https://github.com/ansible/ansible/blob/devel/lib/ansible/utils/init.py

7

Just an update - changing sudoers_debug to 0 solved the problem (as no output during sudo operations)
OS: redhat 6.3