$ ansible -i ../inv -m ping -e ansible_user=giraffe ubuntu14-test -k -vvv
Using /etc/ansible/ansible.cfg as config file
SSH password:
META: ran handlers
Using module file /srv/ansible/stable-2.3/lib/ansible/modules/system/ping.py
<ubuntu14-test> ESTABLISH SSH CONNECTION FOR USER: root
<ubuntu14-test> SSH: EXEC sshpass -d13 ssh -C -o ControlMaster=auto -o ControlPersist=60s -o User=root -o ConnectTimeout=10 -o ControlPath=/home/badger/.ansible/cp/c441de2c92 ubuntu14-test '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
<ubuntu14-test> (5, '', 'Permission denied, please try again.\r\n')
<ubuntu14-test> ESTABLISH SSH CONNECTION FOR USER: root
<ubuntu14-test> SSH: EXEC sshpass -d13 ssh -C -o ControlMaster=auto -o ControlPersist=60s -o User=root -o ConnectTimeout=10 -o ControlPath=/home/badger/.ansible/cp/c441de2c92 ubuntu14-test '/bin/sh -c '"'"'( umask 77 && mkdir -p "` echo ~/.ansible/tmp/ansible-tmp-1507073697.14-214300290277387 `" && echo ansible-tmp-1507073697.14-214300290277387="` echo ~/.ansible/tmp/ansible-tmp-1507073697.14-214300290277387 `" ) && sleep 0'"'"''
<ubuntu14-test> (5, '', 'Permission denied, please try again.\r\n')
ubuntu14-test | UNREACHABLE! => {
"changed": false,
"msg": "Authentication failure.",
"unreachable": true
Bug might lie here: https://github.com/ansible/ansible/blob/devel/lib/ansible/playbook/play_context.py#L68
But ansible_ssh_user is deprecated so perhaps we should just remove it: http://docs.ansible.com/ansible/latest/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
I can reproduce this problem, too.
The bigges impact is on developing with vagrant and dynamic inventory with ubuntu/xenial64 box. The user must be ubuntu, not vagrant...
I get problem with ansible 2.4.1.0 and 2.4.0.0
it is not supposed to, ansible_ssh_user is 'ssh specific' and ansible_user is general for all plugins. We did deprecate it at 2.0 but have since then reversed that.
It's the same thing with "ansible_user"
In the docs it says everything in command (ad hoc) should override other variables but that is not the case when directly set in host vars/group vars/inventory vars (maybe same result when set in ansible.cfg)
the same variable overrides the 'same variable', ansible_ssh_user > ansible_user, so if you define ansible_user ANYWHERE it will still prefer ansible_ssh_user.
To do what you want, you need 2 occurrences of the same, as extras > inventory, but it must be the same var (ansible_user vs ansible_user and ansible_ssh_user vs ansible_ssh_user)
If you mix and match it can get confusing. You have 2 levels of precedence, one across vars, the other depending on where the vars are defined.
hmm maybe, i'll need to retry (but now i moved on to something else, too many issues lol)
but this could still be improved no? since one var is equal to the other
one has higher precedence?? but in the doc:
Ansible 2.0 has deprecated the “ssh” from ansible_ssh_user, ansible_ssh_host, and ansible_ssh_port to become ansible_user, ansible_host, and ansible_port.
So it's the same variable, one is older, one is current.
Note I still use ansible_ssh_user because it makes it clearer that it's for ssh connection to me
Also, related to the same issue, I encountered a "bug" (but really it's too harassing to open a bug report that will be ignored on ansible repository so I'm posting it here, sorry, I have already 5 bug reports I noted down that will be posted later) :
if we set ansible_become: yes in the vars, and we want to override that setting at task level, we can only do become: no. But this doesn't work. We can't type ansible_become: no at task level (it's invalid). So it's not overriden but it's the same variable feature!!! And that created a really big issue when delegating_to: localhost not being able to disable the become
The only difference I see between both variables is that ansible_become can be used in other files while become must be used in the playbook/task. But if you want to add an ansible_become_password for one specific play, then you have defined the different become vars in both the playbook play and in the playbook vars which is dirty looking.
That doc is out of date (i believe it is already fixed, but i need to double check).
to answer your become question (really you should asks mailing lists/irc):
- mytask: ...
vars:
ansible_become: no
As it is a variable, not a keyword (which become is)
omg we can do this?? i looked "vars on task level" and couldn't find and didn't try (already trying so many weird things all the time :P)
Thank you!!!!!!!!!!!!!!! and I didn't know about IRC, will use this when in an urgent need, thank you!
