Este ha sido un problema bastante irritante ahora que pensé que finalmente le preguntaría a la comunidad en general cuál sería la posible solución. Es aún más irritante que parezca ser el único que experimenta este problema.
Esencialmente, en cualquier momento en CentOS 7.x, las configuraciones de sshd, o cualquier parte de sshd se modifican, y el demonio se reinicia / recarga en algún "punto aleatorio" en los próximos 3 minutos, todas las conexiones ssh se reinician, y luego ese servidor se reinicia inalcanzable por unos segundos a través de ssh.
Esto es especialmente un problema para ansible, ya que a veces necesita hacer estos cambios en sshd, y también volver a cargarlo (por ejemplo, en las nuevas versiones del servidor CentOS 7x). Pero luego, en el futuro, no se puede conectar aleatoriamente a ssh, y explota el resto del libro de jugadas / jugadas para ese host que no pudo ser contactado. Esto es especialmente malo para un patrón de host grande, ya que algunos se completarán al azar, pero los otros fallarán en varias etapas a lo largo del libro de jugadas después de manipular sshd. Es de destacar que nada de eso ocurre en CentOS 5x, 6x, o incluso en Solaris.
Lo mejor que puedo hacer para evitar esto es crear una espera de 90 segundos después de cualquier cambio en sshd, e incluso esto no es totalmente infalible. Sin embargo, hace que esos libros de jugadas tarden más de 20 minutos en ejecutarse si se invocan de 7 a 8 veces.
Aquí hay algunos datos sobre este entorno:
Todas las nuevas instalaciones son de DVD ISO oficiales. Todos los servidores son invitados de Hyper-v 2012 Todos los servidores que tienen este problema son CentOS 7.x
Aquí hay algunos resultados reales de los problemas y algunas soluciones trilladas:
La falla:
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}]}
Ejemplo de uno de los cambios en 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
El siguiente controlador:
- name: sshd reload Linux 7x
systemd:
state: restarted
daemon_reload: yes
name: sshd
Finalmente, mi solución de ghetto para tratar de resolver este 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")
Tiene que haber una solución mejor que la que se me ocurrió, y es difícil creer que todos los demás se encuentren con esto y también lo toleren. ¿Hay algo que deba configurar en los servidores CentOS 7.x para evitar esto? ¿Hay algo en ansible que se necesita para lidiar con esto, como múltiples intentos de ssh por jugada en el primer fallo?
¡Gracias por adelantado!
Restart=on-failure? Si es así, ¿cuál era el estado de salida? ¿Y sshd no registró ningún mensaje de error?
sshdy qué sucede con su conexión? ¿También estás usando SSH ControlMastercon Ansible? Puede habilitarlo en ansible.cfg ssh_args = -o ControlMaster=auto -o ControlPersist=60s.