Ansible: module_stdout : "/bin/sh : 1 : /usr/bin/python : introuvable\r\n",

Veuillez utiliser le modèle de problème au lieu de le supprimer - ce n'est pas un rapport de bogue exploitable ou utile. Je soupçonne que vous utilisez Ubuntu 16+ ou autre chose sans python3 par défaut installé, mais nous ne pouvons pas le dire sans un rapport de bogue complet.

Les dernières images dans AWS n'ont pas de Python utilisable installé... vous devez l'ajouter en tant que pré-tâche :

  pre_tasks:

    - name: Refresh apt cache
      become: no
      local_action: shell ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=5 {{ inventory_hostname }} sudo apt-get update

    - name: Install Python-apt to pull in Python
      become: no
      local_action: shell ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=5 {{ inventory_hostname }} sudo apt-get install --no-install-recommends --assume-yes python-apt

Je dois l'utiliser dans mes tâches pour que l'AMI fonctionne correctement avec Ansible.

Ubuntu Xenial a installé Python3 par défaut et je pense qu'il se trouve à /usr/bin/python3 (je ne suis pas très sûr cependant).

Voir cette réponse : http://stackoverflow.com/questions/32429259/ansible-fails-with-bin-sh-1-usr-bin-python-not-found

Notez qu'il est important de désactiver la collecte de faits pour les tâches d'initialisation.

Oui, le chemin de l'interpréteur python peut être donné au moment de l'exécution comme
-e 'ansible_python_interpreter=/usr/local/bin/python' lors de l'exécution du script.

Mais il doit y avoir un moyen dans le fichier de configuration ansible où nous pouvons mentionner le chemin de l'interpréteur python OU est-il là?

Si ce n'est pas le cas, il doit être mis en œuvre.

Utilisez simplement ansible_python_interpreter=/usr/bin/python3 dans votre fichier d'inventaire

@guruprasad85 Ce problème attend votre réponse. Merci de répondre ou le problème sera clos.

cliquez ici pour l'aide du bot

@guruprasad85 Salutations ! Merci d'avoir pris le temps d'ouvrir ce sujet. Pour que la communauté traite efficacement votre problème, nous avons besoin d'un peu plus d'informations.

Voici les articles que nous n'avons pas pu trouver dans votre description :

• type de probleme
• version ansible
• Nom du composant

Veuillez définir la description de ce problème avec ce modèle :
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

cliquez ici pour l'aide du bot

Comme j'avais besoin de python2, j'ai ajouté comme première tâche :

- name: dependency provisioning
  hosts: all
  become: yes
  become_method: sudo
  gather_facts: false
  tasks:
    - name: install python2
      raw: sudo apt-get -y install python-simplejson

Plus d'infos ici

@guruprasad85 Ce problème attend votre réponse. Merci de répondre ou le problème sera clos.

cliquez ici pour l'aide du bot

Les explications ci-dessus sont suffisantes pour résoudre ce problème.

Quelques lectures supplémentaires :

http://docs.ansible.com/ansible/faq.html#how -do-i-handle-python-pathing-not-having-a-python-2-x-in-usr-bin-python-on- une-télécommande

Si vous avez d'autres questions, veuillez passer par IRC ou la liste de diffusion :

• IRC : #ansible sur irc.freenode.net
• liste de diffusion : https://groups.google.com/forum/#!forum/ansible -project

Vous pouvez également désactiver le _Gathering Facts_, le mettre dans votre livre

- hosts: anything
  gather_facts: False

@bcoca @sivel est-il prévu de revoir cela ? Il me semble qu'Ansible devrait au moins essayer d'utiliser /usr/bin/python3 (ou /usr/bin/python2 selon le cas) si /usr/bin/python n'est pas disponible.
@SpamapS a signalé que les AMI Ubuntu officielles sur AWS ne sont /usr/bin/python3 :

ubuntu@ip-172-16-178-247:~$ uname -a
Linux ip-172-16-178-247 4.4.0-1065-aws #75-Ubuntu SMP Fri Aug 10 11:14:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ip-172-16-178-247:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial
ubuntu@ip-172-16-178-247:~$ ls -al /usr/bin |grep python
lrwxrwxrwx  1 root   root          26 May 18  2016 dh_pypy -> ../share/dh-python/dh_pypy
lrwxrwxrwx  1 root   root          29 May 18  2016 dh_python3 -> ../share/dh-python/dh_python3
lrwxrwxrwx  1 root   root          23 Nov 28  2017 pdb3.5 -> ../lib/python3.5/pdb.py
lrwxrwxrwx  1 root   root          31 Mar 23  2016 py3versions -> ../share/python3/py3versions.py
lrwxrwxrwx  1 root   root          26 May 18  2016 pybuild -> ../share/dh-python/pybuild
lrwxrwxrwx  1 root   root           9 Mar 23  2016 python3 -> python3.5
-rwxr-xr-x  2 root   root     4464400 Nov 28  2017 python3.5
-rwxr-xr-x  2 root   root     4464400 Nov 28  2017 python3.5m
-rwxr-xr-x  1 root   root         976 Nov 27  2015 python3-jsondiff
-rwxr-xr-x  1 root   root        3662 Nov 27  2015 python3-jsonpatch
-rwxr-xr-x  1 root   root        1342 Oct 24  2015 python3-jsonpointer
lrwxrwxrwx  1 root   root          10 Mar 23  2016 python3m -> python3.5m

Pour la postérité, il s'agit d'une opportunité d'amélioration connue pour Ansible et son inclusion dans la feuille de route pour >=2,8 est envisagée.

Dans mon cas (ansible 2.7.0):
monIp | ÉCHOUÉ! => {
"changé": faux,
"module_stderr": "",
"module_stdout": "/bin/sh : /usr/bin/python : aucun fichier ou répertoire de ce type\r\n",
"msg": "MODULE FAILURE\nVoir stdout/stderr pour l'erreur exacte",
"rc": 127
}

$ll |grep python
lrwxrwxrwx 1 root root 32 juin 5 15:44 kylinpy -> /usr/local/python2.7/bin/kylinpy
lrwxrwxrwx 1 root root 34 16 novembre 2016 python -> /usr/local/python2.7/bin/python2.7
lrwxrwxrwx 1 racine racine 6 8 septembre 2016 python2 -> python
-rwxr-xr-x 1 root root 4864 29 mai 2014 python2.6
-rwxr-xr-x 1 root root 1418 29 mai 2014 python2.6-config

pourquoi softlink ne fonctionne pas non plus ?

Dans mon cas (ansible 2.7.0):
monIp | ÉCHOUÉ! => {
"changé": faux,
"module_stderr": "",
"module_stdout": "/bin/sh : /usr/bin/python : aucun fichier ou répertoire de ce type\r\n",
"msg": "MODULE FAILURE\nVoir stdout/stderr pour l'erreur exacte",
"rc": 127
}

$ll |grep python
lrwxrwxrwx 1 root root 32 juin 5 15:44 kylinpy -> /usr/local/python2.7/bin/kylinpy
lrwxrwxrwx 1 root root 34 16 novembre 2016 python -> /usr/local/python2.7/bin/python2.7
lrwxrwxrwx 1 racine racine 6 8 septembre 2016 python2 -> python
-rwxr-xr-x 1 root root 4864 29 mai 2014 python2.6
-rwxr-xr-x 1 root root 1418 29 mai 2014 python2.6-config

pourquoi softlink ne fonctionne pas non plus ?

désolé, c'est de ma faute.Utilisez le lien logiciel, cela fonctionne

un simple : ln -s /usr/bin/python3 /usr/bin/python a résolu mon problème

Utilisez simplement ansible_python_interpreter=/usr/bin/python3 dans votre fichier d'inventaire

Merci, ça marche maintenant

Cela semble avoir des problèmes avec pyenv pyenv global <version> .

Il devrait le caler, mais je suppose qu'Ansible est codé en dur pour regarder /usr/bin/python , par opposition à la simple utilisation de la commande python ?

Si oui, est-ce que cela risque de changer ? Ou existe-t-il une solution de contournement que je peux utiliser?

Si oui, est-ce que cela risque de changer ?

Non, ce n'est pas le cas.

Vous devrez définir explicitement ansible_python_interpreter sur un interpréteur python si vous souhaitez utiliser autre chose que /usr/bin/python .

Ce qui dans le cas de pyenv serait probablement juste le chemin vers la cale ( which python3.6 ) ou vers le vrai binaire ( pyenv which python3.6 ). Notez que dans de nombreuses circonstances, vous devez coder cela en dur et ne pouvez pas utiliser l'expansion du shell.