Issue with template module

Archives Ansible Project
1

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

2

Use Verbose -vvv to see more details on error

3

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.

4

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

5

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 :slight_smile: !
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.