Ansible 2.0.0.2: Ansible doesn't respect the “-u” switch

[bfqrst]

BUG REPORT

I'm probing a freshly installed Archlinux installation on a Raspberry PI 2 like so:

ansible -i PI2 arch -m setup -c paramiko -k -u alarm -vvvv

This reads to me: Fire the setup module against the IP connecting with the user "alarm" asking for the password of this specific user. However the user that eventually attempts to connect is "root".

Here's the debug response:

Loaded callback minimal of type stdout, v2.0
<192.168.1.18> ESTABLISH CONNECTION FOR USER: root on PORT 22 TO 192.168.1.18
192.168.1.18 | UNREACHABLE! => {
    "changed": false, 
    "msg": "ERROR! Authentication failed.", 
    "unreachable": true
}

The inventory looks like this:

[arch]
192.168.1.18

ansible.cfg is:

[defaults]

host_key_checking = False
private_key_file = /Users/xyz/.ssh/id_rsa_ansible
deprecation_warnings = True
system_warnings = True
retry_files_enabled = False

[paramiko_connection]

record_host_keys=False

[ssh_connection]
pipelining = True

The expected result, as version 1.9.4 delivers is:

 ⤷ ansible --version
 ansible 1.9.4
  configured module search path = None
(ANS19TEST)~/Documents/Code/VENVS/ANS19TEST

⤷ ansible -i PI2 arch -m setup -c paramiko -k -u alarm -vvvv

SSH password: 
<192.168.1.18> ESTABLISH CONNECTION FOR USER: alarm on PORT 22 TO 192.168.1.18
<192.168.1.18> REMOTE_MODULE setup

The control machine is a MBA on 10.11.3. The command was run against a Raspberry PI 2 running Archlinux.
Cheers
Ralph

[dagwieers]

@bfqrst I am trying to reproduce this on my laptop (v2.0.0.2), and for me it seems to work out fine.

[dag@moria ansible.dag]$ ansible --version
ansible 2.0.0.2
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

[dag@moria ansible.dag]$ ansible localhost -m setup -c paramiko -k -u dag -vvvv
Using /etc/ansible/ansible.cfg as config file
SSH password: 
Loaded callback minimal of type stdout, v2.0
<localhost> ESTABLISH CONNECTION FOR USER: dag on PORT 22 TO localhost

Only when I deliberately override the SSH user in the inventory I can see the same behaviour you experience ?

[dag@moria ansible.dag]$ grep localhost /etc/ansible/hosts
localhost ansible_ssh_user=root

[dag@moria ansible.dag]$ ansible localhost -m setup -c paramiko -k -u dag -vvvv
Using /etc/ansible/ansible.cfg as config file
SSH password: 
Loaded callback minimal of type stdout, v2.0
<localhost> ESTABLISH CONNECTION FOR USER: root on PORT 22 TO localhost

To rule out inventory-related causes, I created a similar inventory as you:

[dag@moria ansible.dag]$ cat PI2
[arch]
127.0.0.1

[dag@moria ansible.dag]$ ansible -i PI2 arch -m setup -c paramiko -k -u dag -vvvv
Using /etc/ansible/ansible.cfg as config file
SSH password: 
Loaded callback minimal of type stdout, v2.0
<127.0.0.1> ESTABLISH CONNECTION FOR USER: dag on PORT 22 TO 127.0.0.1

To rule out the ansible.cfg file I also recreated it with the same content:

[dag@moria ansible.dag]$ cat ansible.cfg
[defaults]

host_key_checking = False
private_key_file = /Users/xyz/.ssh/id_rsa_ansible
deprecation_warnings = True
system_warnings = True
retry_files_enabled = False

[paramiko_connection]

record_host_keys=False

[ssh_connection]

[dag@moria ansible.dag]$ ansible -i PI2 arch -m setup -c paramiko -k -u dag -vvvv
Using /home/dag/home-made/ansible.dag/ansible.cfg as config file
SSH password: 
Loaded callback minimal of type stdout, v2.0
<127.0.0.1> ESTABLISH CONNECTION FOR USER: dag on PORT 22 TO 127.0.0.1
127.0.0.1 | UNREACHABLE! => {
    "changed": false, 
    "msg": "ERROR! [Errno 2] No such file or directory: u'/Users/xyz/.ssh/id_rsa_ansible'", 
    "unreachable": true
}

The error is obviously to be expected :-)

Is there something you could have done differently ?

[bfqrst]

Hi @dagwieers ,

thanks for investigating. I think I got something. I omitted the upper part of my inventory for brevity and because I thought it has no relevance, but it turns out it is the interesting part. Have a look at my updated inventory:

[hypriot]
192.168.1.18 ansible_user=root

[arch]
192.168.1.18

As you can see there are two distinct sections but they are pointing to the same IP. Now Ansible 1.9.4 seems to use the latter, whereas Ansible 2 uses the former and subsequently uses root as user . Maybe a parsing issue of some sort?

I confirmed this behavior using two separate virtualenvs.

Let me apologize for omitting crucial parts of my setup. I understand that in order to debug stuff you need to have the exact setup. My bad.

Thanks

EDIT:

Just realized in Ansible 1.9.4 you need to actually use ansible_ssh_user... After that the results are consistent between Ansible 1 and Ansible 2 in the fact that both of the times the root user is used.

[dagwieers]

@bfqrst Great. Because that is what I was expecting. The names used in the inventory is the key in a dictionary. So everything you put in there as host-specific variables will be merged into one big dictionary. That means that in some conflicting cases variables are superseded by other values.

You can prevent this by using different names for the same host (e.g. using IP address and hostname, or an alias or DNS-alias) and in that case you can still do what you like to do.

In the meantime #14268 (this issue) can be closed. @bcoca ?

[bfqrst]

Thanks, I will keep that in mind. I must admit that usually you don't have duplicate entries in your inventory. Using this like I did is a kind of an edge case. But then again, I would imagine that Raspberry PI et al users do trip over this. The reason is as obvious as it is simple. You have a PI which usually gets assigned the same IP from the home router. Then you fiddle around with different OSes. You have different SD cards with Raspbian, Archlinux, HyprIoT, OpenELEC, OSMC, you name it... Out of the box you may or may not know what the hostname will be, but you know the IP, right? At least that's how my inventory file ended up like it did. In terms of the title of this issue, I think we all agree that Ansible does respect the -u switch.

I'd imagine that a mention of these edge cases in the documentation would be helpful?

Anyway, I appreciate you guys looking into it. Thanks for the insight.

Cheers
Ralph

[bcoca]

Closing as per above, thanks @dagwieers

@bfqrst I would have actually expected this to work the same across both versions, a host should get the variables from all the groups it is defined in, this looks like a bug in 1.9 for not picking up the variable. Making a note to fix this in possible 1.9.5 release.

[dagwieers]

@bcoca And that is the case, but ansible_user is not effective on v1, while it is on v2.

So everything is fine, no note needed ;-)

[bcoca]

ah, DUH!, it would work the same if it where ansible_ssh_user but since ansible_user is not used in 1.9 ....

removed note, this all works as expected.

[bfqrst]

This inventory file works for me. (Ansible 2.0.0.2)

[hypriot]
hypriot_local ansible_host=192.168.1.18 ansible_user=root

[archlinux]
arch_local ansible_host=192.168.1.18

Thanks for helping @dagwieers @bcoca

[dagwieers]

@bfqrst That is what I meant ! Well done.