Cela a été un problème assez irritant maintenant que je pensais enfin demander à la communauté dans son ensemble quelle pourrait être une solution. C'est encore plus irritant que je semble être le seul à rencontrer ce problème.
Essentiellement, à tout moment dans CentOS 7.x, les configurations sshd ou toute partie de sshd sont modifiées et le démon est redémarré / rechargé à un certain "point aléatoire" dans les 3 minutes suivantes, les connexions ssh sont toutes réinitialisées, puis ce serveur est inaccessible pendant quelques secondes via ssh.
Ceci est particulièrement un problème pour ansible dans la mesure où il doit parfois effectuer lui-même ces modifications sur sshd, et également le recharger (par exemple dans les nouvelles versions de serveur CentOS 7x). Mais ensuite, à l'avenir, il ne peut tout simplement pas se connecter au hasard à ssh, et il fait exploser le reste du livre de lecture / joue pour cet hôte qui n'a pas pu être contacté. C'est particulièrement mauvais pour un grand modèle d'hôte, car quelques-uns se termineront au hasard, mais les autres échoueront à différentes étapes du manuel après que sshd ait été manipulé. Il est à noter que rien de ce genre ne se produit dans CentOS 5x, 6x ou même sur Solaris.
Le mieux que je puisse faire pour éviter cela est de créer une attente de 90 secondes après toute modification de sshd, et même ce n'est pas totalement infaillible. Cela fait que ces playbooks prennent plus de 20 minutes à fonctionner si elle est invoquée 7 à 8 fois.
Voici quelques faits sur cet environnement:
Toutes les nouvelles installations proviennent de DVD ISO officiels. Chaque serveur est un invité hyper-v 2012 Chaque serveur qui a ce problème est CentOS 7.x
Voici une sortie réelle des problèmes et des solutions galvaudées:
L'échec:
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}]}
Exemple d'une des modifications apportées à 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
Le gestionnaire suivant:
- name: sshd reload Linux 7x
systemd:
state: restarted
daemon_reload: yes
name: sshd
Enfin mon correctif ghetto pour essayer de tenir compte de ce problème:
- 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")
Il doit y avoir une meilleure solution que ce que j'ai proposé, et il est difficile de croire que tout le monde le rencontre et le supporte également. Y a-t-il quelque chose que je dois configurer dans les serveurs CentOS 7.x pour éviter cela? Y a-t-il quelque chose en ansible qui est nécessaire pour faire face à cela, comme plusieurs tentatives ssh par jeu lors du premier échec?
Merci d'avance!
Restart=on-failure
? Si oui, quel était le statut de sortie? Et sshd n'a-t-il pas enregistré de message d'erreur?
sshd
et que se passe-t-il avec votre connexion? Utilisez-vous également SSH ControlMaster
avec Ansible? Vous pouvez l'activer dans ansible.cfg ssh_args = -o ControlMaster=auto -o ControlPersist=60s
.