SSH fail during node_exporter installation

[lykholat]

Hello the node exporter installation is failing during this part: TASK [prometheus.prometheus.node_exporter : Download node_exporter binary to local folder] **** fatal: [.**..***]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ubuntu@localhost: Permission denied (publickey).", "unreachable": true}

I tried this line and no errors were obtained but the installation ended up being moved to the provisioning machine and not in the target: ansible-playbook nodeexp.yml -i inventory --connection=local

I'm using the simplest example of playbook and all the other tasks executed fine

• hosts: targets become: true roles:
  • prometheus.prometheus.node_exporter

[lykholat]

Issue solved by modifying the install.yml file. I removed all lines that say "delegate_to: localhost"

[gardar]

Do you have the hostname "localhost" in your ansible inventory? Ansible should default to a local connection and not ssh for localhost.

Passing --connection=local to ansible-playbook is not ideal as it will attempt to use the local connection for all of the targets. instead, you could do something like this in your inventory:

localhost ansible_connection=local

[Ezzahhh]

Also ran into this and rolled back to 0.5.1 for now. I don't have any localhost in inventory as far as I can see Maybe we could have a PR to add connection: local to those steps?

[N07070]

I'm having the same issue, with the following inventory:

server:
  hosts:
    server.example.com:
  children:
    gitea:
    nextcloud:
    transmission:
    status:

other:
  hosts:
    localhost:

localhost:
  ansible_connection: local

# What --------------------

status:
  hosts:
    status.example.com:

[daynyxx]

Adding connection: local to the tasks where delegate_to: local is set would solve this issue. Or putting a section in the README stating a requirement for localhost to exist in your inventory for this collection to work.

[gardar]

This issue might also be happening due to the fact that elevated privileges could have been applied to the tasks inadvertently previously.

Can any one of you try the latest version of the collection and see if the issue is still present? As I've been unable to reproduce this issue myself.