Résoudre les erreurs de connexion Ansible lors de la gestion des équipements Junos
Les sections suivantes décrivent les erreurs de connexion que vous pouvez rencontrer lors de l’utilisation d’Ansible pour gérer des équipements Junos. Ces sections présentent également les causes potentielles et les solutions pour chaque erreur.
Résoudre les erreurs de connexion ayant échoué ou incorrectes
Problème
Description
Lors de l’exécution d’un juniper.device module sur un équipement Junos, le nœud de contrôle Ansible génère une erreur concernant un échec de connexion SSH ou une commande inconnue. Par exemple:
UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ", "unreachable": true}
ou
unknown command: /bin/sh\r\n
Cause
Ces erreurs peuvent se produire lorsque le module n’est pas exécuté localement sur le nœud de contrôle Ansible.
Normalement, Ansible requiert Python sur le nœud managé, et le nœud de contrôle Ansible envoie le module au nœud, où il est exécuté puis supprimé. Les modules Juniper Networks n’ont pas besoin de Python sur les équipements Junos, car ils utilisent Junos PyEZ et l’API Junos XML sur NETCONF pour s’interfacer avec l’appareil. Par conséquent, pour effectuer des opérations sur les équipements Junos, vous devez exécuter les modules localement sur le nœud de contrôle Ansible sur lequel Python est installé. Si Ansible tente d’exécuter un module directement sur l’équipement Junos, cela génère une erreur.
Solution
Pour demander au nœud de contrôle Ansible d’exécuter les juniper.device modules localement, incluez-le connection: local dans le playbook Ansible ou incluez l’argument de ligne de commande lors de l’exécution --connection local de modules individuels. Par exemple:
--- - name: Get Device Facts hosts: junos connection: local gather_facts: no
Dépannage des erreurs sur l’hôte inconnu
Problème
Description
Lors de l’exécution d’un juniper.device module, le noeud de contrôle Ansible génère une ConnectUnknownHostError erreur.
"msg": "Unable to make a PyEZ connection: ConnectUnknownHostError(dc1a.example.net)"
Cause
L’hôte n’est pas défini dans le fichier d’inventaire Ansible ou le nœud de contrôle Ansible ne parvient pas à résoudre le nom d’hôte.
Lors de l’exécution d’un module Ansible, soit directement, soit à partir d’un playbook, tout hôte référencé dans les arguments du module ou dans le playbook doit être défini dans le fichier d’inventaire Ansible. L’emplacement par défaut du fichier d’inventaire est /etc/ansible/hosts. Si le fichier d’inventaire fait référence à un nom d’hôte, le nœud de contrôle Ansible doit être en mesure de résoudre le nom d’hôte.
Solution
Mettez à jour le fichier d’inventaire Ansible pour inclure l’hôte manquant et assurez-vous que la résolution DNS fonctionne correctement.
Pour plus d’informations sur le fichier d’inventaire Ansible, reportez-vous à la section Présentation du fichier d’inventaire Ansible lors de la gestion des équipements Junos, ainsi qu’à la documentation officielle d’Ansible sur https://www.ansible.com/.
Résoudre les erreurs de connexion refusée
Problème
Description
Lors de l’exécution d’un juniper.device module, le noeud de contrôle Ansible génère une ConnectRefusedError erreur. Par exemple:
"msg": "Unable to make a PyEZ connection: ConnectRefusedError(dc1a.example.net)"
Cause
La cause la plus probable d’une erreur de connexion refusée est que NETCONF sur SSH n’est pas activé sur le périphérique Junos.
Pour tester rapidement si NETCONF est activé, vérifiez que le compte d’utilisateur exécutant le module Ansible peut démarrer une session NETCONF avec l’appareil.
user@ansible-cn:~$ ssh user@dc1a.example.net -p 830 -s netconf
Si l’utilisateur parvient à établir une session NETCONF avec le périphérique sur le port NETCONF par défaut (830) ou sur un port spécifiquement configuré pour NETCONF sur votre périphérique, NETCONF est activé. Sinon, vous devez activer NETCONF sur SSH sur l’appareil.
Solution
Activez le service NETCONF-over-SSH sur l’équipement Junos.
[edit] user@host# set system services netconf ssh user@host# commit