Ansible 2.0.0.2 forwarding LANG and LC_ALL and modules failing

Archives Ansible Developer
1

Hi,

I have experienced that Ansible 2.0.0.2 forwards the LANG and LC_ALL variables from the controller machine to the hosts.

I hadn’t experienced this behaviour with versions 1.9.X, and this results in modules depending on literals (e.g: yum, searching for “Nothing to do” ).

I have experienced that setting the variable ANSIBLE_MODULE_LANG to “C”, “en-us.UTF-8” or even “C” solves the problem, but if the default value of the parameter is “C” (as the documentation says so) it should work without setting the value.

I have found this issue and it’s been closed and redirected to this list. The fact is that with Ansible 2.X this will happen to many people now.

I would like to start a discussion to determine if this behaviour is the right one or should be changed. Personally I think it is misbehaving as it is not enforcing the default value.

Thanks!

2

Env vars get set from the default in ansible.cfg or the var you
mention, we changed from a default of 'C' to "en-us.UTF-8" a while
back to deal with unicode filesystems, any other value you are seeing
should be because someone explicitly changed this.

3

Hi Brian,

In Ansible 2.0.0.2, if I don’t define ANSIBLE_MODULE_LANG or module_lang in the defaults section of ansible.cfg, then the LANG variables are, by default, forwarded from the locale variables of the controller machine.

I can reproduce that.

Regards,

4

looking at teh code:

lib/ansible/plugins/shell/sh.py: LANG = C.DEFAULT_MODULE_LANG,
lib/ansible/plugins/shell/sh.py: LC_ALL = C.DEFAULT_MODULE_LANG,
lib/ansible/plugins/shell/sh.py: LC_MESSAGES = C.DEFAULT_MODULE_LANG,

i don't see this changed from 1.9

5

Hi Brian,

So, if I don’t set any value for the variable, the LANG and LC used for communication should be “C”, isn’t it? It that assumption is correct, the current behaviour (forwarding the local value of the controller) could be a bug.

Regards,

6

No, en_us.UTF-8, that is the default as the previous default of C had
issues with unicode paths.

7

Ok, it’s the same.

The issue is that the variables in the ansible SSH session are the ones forwarded, not en_us.UTF-8. Should that be correct?

Regards,

8

should not be, unless you are forcing it in your ssh config, still we
set these in the command line and should override the forwarded ones.

9

Running ansible with '-m shell -a "echo \$LANG"'
results in
IP_CENSORED | SUCCESS | rc=0 >>
de_DE.UTF-8

ansible 2.1.0 (devel e3a6accc1d)
last updated 2016/01/20 08:57:23 (GMT +200)

Running the same on 1.9.4 I get en_US.UTF-8.
In both cases variables from ssh SendEnv config will also be transfered. In 1.9.4 LANG is still overwritten.
module_lang in defaults section of ansible.cfg replaces the environment values as expected. (Both 1.9.4 and 2.x)

From -vvv:

'LANG=de_DE.UTF-8 LC_ALL=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8 /usr/bin/python'

vs.

/bin/sh -c 'LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 /usr/bin/python'

So beside different env there is a "/bin/sh -c" in 1.9.4. That change feels right but can anyone point out side effects we should look for...?

Best regards,
Harald

10

I just added /bin/sh -c back to 2.0 as there were other breakages.
What is the user's default shell? I suspect this was only hitting only
'non bash/sh' shells.

11

Client and server have bash as default shell.