Questo è stato un problema abbastanza irritante ora che pensavo che avrei finalmente chiesto alla comunità in generale quale potrebbe essere una possibile soluzione. È ancora più irritante che sembri essere l'unico a riscontrare questo problema.
In sostanza, in qualsiasi momento in CentOS 7.x, le configurazioni sshd o qualsiasi parte di sshd vengono modificate e il demone viene riavviato / ricaricato in qualche "punto casuale" nei prossimi 3 minuti, tutte le connessioni ssh vengono ripristinate e quindi quel server è irraggiungibile per alcuni secondi tramite ssh.
Questo è particolarmente un problema per rispondere in quanto ha bisogno di fare queste modifiche da solo a sshd a volte, e anche ricaricarlo (ad esempio nelle nuove build di server CentOS 7x). Ma poi in futuro le riproduzioni casuali non possono collegarsi a ssh, e fa esplodere il resto del playbook / riproduzioni per quell'host che non è stato contattato. Ciò è particolarmente negativo per un modello host di grandi dimensioni, poiché alcuni verranno completati in modo casuale, ma gli altri falliranno in varie fasi lungo il playbook dopo la manipolazione di sshd. È da notare che nulla del genere si verifica in CentOS 5x, 6x o persino su Solaris.
Il meglio che posso fare per evitarlo è quello di creare un'attesa di 90 secondi dopo qualsiasi modifica a sshd, e anche questo non è totalmente infallibile. Fa sì che quei playbook impieghino più di 20 minuti a funzionare se viene invocato 7-8 volte.
Ecco alcuni fatti su questo ambiente:
Tutte le nuove installazioni provengono da DVD ISO ufficiali. Ogni server è un guest hyper-v 2012 Ogni server che presenta questo problema è CentOS 7.x
Ecco alcuni output effettivi dei problemi e alcune soluzioni compromesse:
Il fallimento:
fatal: [voltron]: UNREACHABLE! => {"changed": false, "msg": "All items completed", "results": [{"_ansible_item_result": true, "item": ["rsync", "iotop", "bind-utils", "sysstat.x86_64", "lsof"], "msg": "Failed to connect to the host via ssh: Shared connection to voltron closed.\r\n", "unreachable": true}]}
Esempio di una delle modifiche a sshd:
- name: Configure sshd to disallow root logins for security purposes on CentOS and Redhat 7x servers.
lineinfile:
backup: yes
dest: /etc/ssh/sshd_config
regexp: '^(#PermitRootLogin)'
line: "PermitRootLogin no"
state: present
when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
notify: sshd reload Linux 7x
Il seguente gestore:
- name: sshd reload Linux 7x
systemd:
state: restarted
daemon_reload: yes
name: sshd
Finalmente la mia correzione del ghetto per cercare di spiegare questo problema:
- name: Wait a bit on CentOS/Redhat 7x servers to ensure changes don't mess up ssh and screw up further plays.
pause:
seconds: 90
when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
Deve esserci una soluzione migliore di quella che mi è venuta in mente, ed è difficile credere che tutti gli altri lo incontrino e lo tollerino. C'è qualcosa che devo configurare nei server CentOS 7.x per impedirlo? C'è qualcosa in ansible che è necessario per affrontare questo, come più tentativi ssh per gioco al primo fallimento?
Grazie in anticipo!
Restart=on-failure? In tal caso, qual era lo stato di uscita? E sshd non ha registrato alcun messaggio di errore?
sshde cosa succede con la tua connessione? Inoltre stai usando SSH ControlMastercon Ansible? Puoi abilitarlo in ansible.cfg ssh_args = -o ControlMaster=auto -o ControlPersist=60s.