Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Ansible-3 throws and error -> Aborting, target uses selinux but python bindings (libselinux-python) aren't installed! , while dnf install libselinux-python3 results in -> Package libselinux-python3-2.7-2.fc27.x86_64 is already installed, skipping. Version-Release number of selected component (if applicable): ansible-3 2.4.0.0 How reproducible: 100% Steps to Reproduce: 1. dir structure : project/ ansible.cfg file.conf.j2 inventory/ playground site.yml files: ansible.cfg -> [defaults] inventory = ./inventory/playground file.conf.j2 -> #Test inventory/playground -> *hostname* ansible_connection=local site.yml -> --- - hosts: all tasks: - name: Updating file.conf from template template: dest: /etc/file.conf group: root owner: root selevel: s0 serole: object_r setype: etc_t seuser: system_u src: file.conf.j2 become: True 2. $ ansible-playbook-3 site.yml Actual results: TASK [Updating file.conf from template] ************************************************************************************************************** fatal: [hostname]: FAILED! => {"changed": false, "checksum": "somechecksum", "failed": true, "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"} Additional info: playbook runs as expected, when hosts: localhost in playbook The stage where the playbook/module fails -> EXEC /bin/sh -c 'sudo -H -S -p "[sudo via ansible, key=somekey] password: " -u root /bin/sh -c '"'"'echo BECOME-SUCCESS-somekey; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-somenumber/copy.py; rm -rf "/home/user/.ansible/tmp/ansible-tmp-somenumber/" > /dev/null 2>&1'"'"' && sleep 0'
I (un)reasonably presumed, that the ansible-python3 and it's submodules set the flag for ansible_python_interpreter as /usr/bin/python3, given the way they are launched especially in case, where ansible_connection=local. I leave it to powers to be to decide if the given problem constitutes as bug. Otherwise adding ansible_python_interpreter=/usr/bin/python3 to host via means allowed by ansible resolves the functionality intended
Ansible is behaving as designed here. Setting ansible_python_interpreter is the correct way to change the python interpreter for other hosts. Since I test most of the pythn3 bugfixes upstream here's a snippet of my inventory file: [all:vars] ansible_python_interpreter=/usr/bin/python3 [py2hosts] centos6-test centos7-test [py2hosts:vars] ansible_python_interpreter=/usr/bin/python That might be of interest to you as a way to set defaults that work better in your environment.
(In reply to Toshio Kuratomi from comment #2) Ansible,as a software is behaving as designed, no questions there. But fedora is shipping ansible-3 package, py3 entry points, and dependencies. One would reasonably expect a patch/modifier where py3 is a default interpreter, not dragging out py2 from graveyard and holding back py3 for undesired and unnecessary py2 compatibility. Otherwise the whole ansible-3 package tree is redundant, one would achieve the same by launching $python3 ansible ...
it only makes sense to change the interpreter to python3 if ansible is only useful in homogenous environments. Ansible, however, is used in many environments where the controller does not match the managed systems. So changing the interpreter would only spawn more confusion for people who are trying to navigate upstream documentation and understand how ansible works. Upstream does have a feature planned to add autodetection of python on the remote machine. This could address this issue if you do not have python2 installed there. I'll let Matt Davis talk more about that, though, as he's the one working on the feature.
See also: https://github.com/ansible/ansible/issues/45852#issuecomment-422897705 This should be addressed in Ansible 2.8 with automatic Python interpreter detection.