Risposte a errori sporadici con macchine Windows

8

Sto riscontrando alcuni problemi di attivazione e disattivazione quando utilizzo gli host di Windows nei miei Playbook Ansible. Sto eseguendo Ansible 2.3 con pywinrm 0.2.2 installato. Sto utilizzando l'autenticazione di base con l'utente amministratore locale.

A volte ricevo questo problema quando eseguo un'attività:

 [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')

Altre volte, quando provo a eseguire un win_shell/win_command/raw modulee with_itemssu un gruppo di host Windows, sembra non riuscire su file temporanei creati da Ansible.

L'attività che sto cercando di eseguire è:

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

E l'errore che posso ottenere è:

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)

Entrambi i problemi sono assolutamente casuali e potrebbero anche non apparire affatto in una sequenza di diverse esecuzioni.

Qualche assistenza?

ansible windows powershell

— Asaf Haim
fonte

Quanti oggetti esegui di nuovo su quell'host, hanno quasi lo stesso problema con errori errati di winrm 500 quando esegui un ciclo di risposta con molti elementi su un host specifico Non riesci a scoprirlo, lo hai trovato nel frattempo?

— daBONDi,

4 e più .. Temo che nessuna soluzione da parte mia sia ancora :(

— Asaf Haim

2

Probabilmente dovresti creare un problema Ansible per questo in quanto molto probabilmente è un bug in Ansible.

Il primo errore mi fa pensare al pipelining WinRM:

Ansible 2.3.0 ha introdotto una funzionalità di pipelining WinRM sempre attiva (simile alla pipelining SSH ), e ciò potrebbe essere alla base di questo.
Il pipelining SSH può causare problemi in Ansible per Linux e può essere utile disattivarlo, ma questo non è ancora possibile per il pipelining WinRM.

Questo problema correlato include alcuni commit di Git che riattiveranno la modalità "non pipeline" in una versione futura (dovrebbe ora essere rilasciata in 2.4, possibilmente con un backport come parte della 2.3.2 - leggi questo commento )

Prova ad aggiornare ad Ansible 2.4.1+ (che generalmente funziona bene) per ottenere la correzione. Oppure prova il downgrade ad Ansible 2.2.3 per vedere se questo aiuta - questo disabiliterà il pipelining WinRM e potrebbe evitare altri bug di regressione in quest'area.

Se hai installato Ansible usando pip, puoi eseguire pip install ansible==2.4.1 l'aggiornamento (o il ansible==2.2.3downgrade), quindi se ciò non aiuta, fai lo stesso con 2.3.1l'aggiornamento.
dovresti anche eseguire l'aggiornamento alla versione pywinrmpiù recente, come indicato nei problemi sopra

— RichVel
fonte

1

Ho trovato Ansible 2.3.2 il più stabile, anche se non ho ancora trascorso molto tempo con 2.4.1. 2.4.0 ha sicuramente alcuni problemi di stabilità quando si tratta di winrm.

— Trondh
fonte