LC_MESSAGES should also be forced: Ansible may not behave the same depending on your ssh_config SendEnv values

[batmat]

Hi,
Just spent some hours yesterday digging into an issue.
To sum up, we (4 people) all run our playbooks from the same control machine we connect with ssh to.

The tested playbook was working fine for everyone but me.

We finally found out it has to do with /etc/ssh/ssh_config 's (which seems to be a default setting nowadays on servers, a mistake imo, but that's another story):
SendEnv LC_*

And then some yum messages get displayed in my native language, instead of english. Which makes Ansible unable to correctly parse out the "Nothing to do" string, as it actually becomes "Rien à faire".

I was the only one (using Linux as my box) having this settings, since the others were connecting from Windows machines... A pure waste as you migh imagine :-).

Anyway, IMO, the value of Ansible is that you expect it to kind of behave the same not depending on who's running the playbook. And in this case, Ansible fails in some cases because ssh sub-layers screws up.

One might say that the solution is just to comment out the line above in the ssh_config, but though we indeed already did it, I don't feel this is a durable/solid solution. Hence I think we should enforce this in the Ansible code setting LC_MESSAGES as is already done with setting LC_CTYPE and LANG.

[ansibot]

Can You Help Us Out?

Thanks for filing a ticket! I am the friendly GitHub Ansibot.

It looks like you might not have filled out the issue description based on our standard issue template. You might not have known about that, and that's ok too, we'll tell you how to do it.

We have a standard template because Ansible is a really busy project and it helps to have some standard information in each ticket, and GitHub doesn't yet provide a standard facility to do this like some other bug trackers. We hope you understand as this is really valuable to us!.

Solving this is simple: please copy the contents of this template and paste it into the description of your ticket. That's it!

If You Had A Question To Ask Instead

If you happened to have a "how do I do this in Ansible" type of question, that's probably more of a user-list question than a bug report, and you should probably ask this question on the project mailing list instead.

However, if you think you have a bug, the report is the way to go! We definitely want all the bugs filed :) Just trying to help!

About Priority Tags

Since you're here, we'll also share some useful information at this time.

In general tickets will be assigned a priority between P1 (highest) and P5, and then worked in priority order. We may also have some follow up questions along the way, so keeping up with follow up comments via GitHub notifications is a good idea.

Due to large interest in Ansible, humans may not comment on your ticket immediately.

Mailing Lists

If you have concerns or questions, you're welcome to stop by the ansible-project or ansible-development mailing lists, as appropriate. Here are the links:

• https://groups.google.com/forum/#!forum/ansible-project - for discussion of bugs and how-to type questions
• https://groups.google.com/forum/#!forum/ansible-devel - for discussion on how to implement a code change, or feature brainstorming among developers

Thanks again for the interest in Ansible!

[batmat]

For reference, the parsing code in the yum ansible core module:
https://github.com/ansible/ansible-modules-core/blob/19b328c4df2157b6c0191e9144236643ce2be890/packaging/os/yum.py#L558

[bcoca]

closing this in favor of the PR

[batmat]

Sure, np. I thought it might be useful to give a bit more context and I didn't feel like putting all this in the commit itself. Granted I also could have put inside the PR comment. Didn't know what the Ansible project process generally.