Erreurs sporadiques possibles avec les machines Windows

8

Je rencontre des problèmes d'activation et de désactivation lors de l'utilisation d'hôtes Windows dans mes playbooks Ansible. J'utilise Ansible 2.3 avec pywinrm 0.2.2 installé. J'utilise l'authentification de base avec l'utilisateur administrateur local.

Parfois, je reçois ce problème lorsque j'exécute une tâche:

 [WARNING]: FATAL ERROR DURING FILE TRANSFER: Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 267, in _winrm_exec
  self._winrm_send_input(self.protocol, self.shell_id, command_id, data, eof=is_last)
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 248, in _winrm_send_input
  protocol.send_message(xmltodict.unparse(rq))
File "/usr/local/lib/python2.7/dist-packages/winrm/protocol.py", line 207, in send_message
   return self.transport.send_message(message)
File "/usr/local/lib/python2.7/dist-packages/winrm/transport.py", line 191, in send_message
   raise WinRMTransportError('http', error_message) WinRMTransportError: (u'http', u'Bad HTTP response returned from server. Code 500')

D'autres fois, lorsque j'essaie d'exécuter un win_shell/win_command/raw moduleet with_itemssur un groupe d'hôtes Windows, il semble échouer sur les fichiers temporaires créés par Ansible.

La tâche que j'essaie d'exécuter est:

- name: Check services up
  win_command: 'sc queryex {{ item }} | Findstr RUNNING'
  with_items: '{{ component_services }}'
  register: command_result
  ignore_errors: yes

Et l'erreur que je peux obtenir est:

changed: [172.16.104.169] => (item=Dnscache)
failed: [172.16.104.176] (item=Dnscache) => {"failed": true, "item": "Dnscache", 
  "module_stderr": "Exception calling \"Run\" with \"1\" argument(s): \"Exception calling \"Invoke\" with \r\n\"0\" 
     argument(s): \"The running command stopped because 
           the preference variable \r\n\"ErrorActionPreference\" 
           or common parameter is set to 
   Stop: (0) : cannot open \r\nC:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\RESB3FF.tmp 
  for writing\r\n(1) : 
     using System;\r\n\"\"\r\nAt line:45 char:1\r\n+ 
     $output = $entrypoint.Run($payload)\r\n+ 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n+ 
  CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE \r\nxception\r\n+ 
  FullyQualifiedErrorId : ScriptMethodRuntimeException\r\n", 
  "module_stdout": "", "msg": "MODULE FAILURE", "rc": 1}
     changed: [172.16.104.141] => (item=Dnscache)
     changed: [172.16.104.168] => (item=Dnscache)
     changed: [172.16.104.145] => (item=Dnscache)

Les deux problèmes sont absolument aléatoires et peuvent même ne pas apparaître du tout sur une séquence de différentes exécutions.

Une assistance?

ansible windows powershell Asaf Haim
la source
Combien d'éléments que vous exécutez contre cet hôte, ont à peu près le même problème avec des erreurs aléatoires winrm 500 lors de l'exécution d'une boucle ansible avec de nombreux éléments sur un hôte spécifique Vous ne pouvez pas également le découvrir, vous l'avez trouvé entre-temps?
daBONDi
4 et plus .. Je crains qu'il n'y ait pour l'instant aucune solution de mon côté :(
Asaf Haim

Réponses:

2

Vous devriez probablement créer un problème Ansible pour cela car c'est probablement un bogue dans Ansible.

La première erreur me fait penser au pipelining WinRM:

  • Ansible 2.3.0 a introduit une fonctionnalité de pipelining WinRM toujours active (similaire au pipelining SSH ), et cela peut être à l'origine de cela.
  • Le pipelining SSH peut provoquer des problèmes dans Ansible pour Linux, et il peut être utile de le désactiver, mais ce n'est pas encore possible pour le pipelining WinRM.

Ce problème connexe comprend certains commits Git qui réactiveront le mode `` non pipeliné '' dans une future version (devrait maintenant être publié en 2.4, éventuellement avec un backport dans le cadre de 2.3.2 - voir ce commentaire )

Essayez de passer à Ansible 2.4.1+ (qui fonctionne généralement bien) pour obtenir le correctif. Ou essayez de rétrograder vers Ansible 2.2.3 pour voir si cela aide - cela désactivera le pipelining WinRM et peut éviter d'autres bogues de régression dans cette zone.

  • Si vous avez installé Ansible à l'aide de pip, vous pouvez procéder pip install ansible==2.4.1 à la mise à niveau (ou ansible==2.2.3à la rétrogradation), puis si cela ne vous aide pas, faites de même avec la 2.3.1mise à niveau à nouveau.
  • vous devez également passer à la dernière version, pywinrmcomme indiqué dans les problèmes ci-dessus
RichVel
la source
1

J'ai trouvé qu'Ansible 2.3.2 était le plus stable, mais je n'ai pas encore passé beaucoup de temps avec 2.4.1. 2.4.0 a définitivement des problèmes de stabilité en ce qui concerne winrm.

Trondh
la source