Issue with template module

[lift...@gmail.com]

We have a playbook that uses a jinja2 template to prepare a report and email us.  For some reason, the template module is failing.  Here's what I'm calling in my playbook:

  - name: Prepare report

    template:

      src: templates/yum_output.txt.j2

      dest: /tmp/yum_output.txt

    connection: local

    run_once: true

It tries to generate the report on the first host in our play, and fails as follows:

Failed to get information on remote file (/tmp/yum_output.txt): /bin/sh: /usr/bin/python: No such file or directory

On that server, which is RHEL 7.9, python 2.7.5 is installed at /bin/python, and /usr/bin/python is symbolically linked to /usr/bin/python2, which is symbolically linked to /usr/bin/python2.7.

So why would this happen and how can we fix that?

Thanks,
Harry

[rajthecomputerguy]

Use Verbose -vvv to see more details on error

[steve missoh]

I dont think the issue is with your remote RHEL79.

But rather from the host you are running the play from.

Because you are using "connection: local", your localhost is responding on behalf of your remote.

check the python path on your localhost; there are chances it doesnt have python2 but only python3.

the question left is why does your ansible uses python2 as interpreter by default ? which version of ansible are you on ?

Thx.

[lift...@gmail.com]

To be honest, we're running this playbook out of Tower, so I'm not sure why its choosing the server it is to generate the report via the template module.  Is there a way I can tell it to use the Ansible control node?

Thanks,

Harry

[steve missoh]

if the host you are running from is the control node, then a trick can consist in setting the python interpreter "wrongly"

so in your inventory file, in front of your remote managed node (the rhel79 one), put this variable:  ansible_python_interpreter=/usr/bin/python3 (or the location of python on your control node)

But be aware: that way, you are deceiving the ansible engine :) !

but even with that, you may avoid the error but I am not sure you'll get the expected results.
The best way to approach it is to remove the "connection: local" directive, and if you need to run something locally, use the "delegate_to: localhost" directive.