Par contre, actuellement je ne vois pas le résultat des exécutions cronées. Faut que je me décide entre :
* une bête alerte renvoyée par le cron si l'exécution renvoie une erreur
* rediriger l'output dans un log et centraliser les logs sur un serveur
* utiliser ARA
Pour le premier point, il me semble que c'était le cas par défaut (je mets l'imparfait parce-que je ne jure de rien avec systemd) Quand il y a une erreur, ou si une sortie est générée, alors tu en auras une trace dans les journaux. De plus, les systèmes traditionnels, pourvu que tu actives l'option (une variable à positionner), un mail est alors envoyé au propriétaire de la crontab en cas d'erreur ou si une sortie est générée. Par contre, si l'envoie de messages n'est pas configuré, ces messages vont juste se retrouver dans le fichier de messages localement. (les gens ne le savent pas toujours et laissent le spool gonfler ad vitam eternam...)
Pour le second point, Ansible a une directive prévue à rajouter dans le ansible.cfg dans la section [default] : log_path = chemin/vers/le/fichier/de/log ...Il faut juste que ce fichier puisse être écrit par le compte avec lequel tu lances les commandes ansible*
C'est presque comparable au fait de faire suivre l'exécution de son playbook par des redirections (ou mieux | tee quand on est devant), mais en mieux car ça a une vraie tête de journal : les lignes sont précédées de l'horodatage ainsi que le compte et le PId exécutant ; ce qui est pratique bien des fois.
ARA est l'étape au dessus : ça défini juste une autre sortie parallèle qui enregistre les informations dans une base de données et permet ensuite de consulter la métrologie via une interface web (bon, en vrai il y a une API pas mal aussi ce qui fait que les usages peuvent être repensés/démultipliés) Cette couche supplémentaire a de l'intérêt quand on travaille quotidiennement et en équipe avec Ansible et qu'on n'est pas prêt à des solutions plus lourdes comme Tower/AWX.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: pas besoin de ssh
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 (Suite). Évalué à 0.
Petite remarque intéressante
Pour le premier point, il me semble que c'était le cas par défaut (je mets l'imparfait parce-que je ne jure de rien avec systemd) Quand il y a une erreur, ou si une sortie est générée, alors tu en auras une trace dans les journaux. De plus, les systèmes traditionnels, pourvu que tu actives l'option (une variable à positionner), un mail est alors envoyé au propriétaire de la crontab en cas d'erreur ou si une sortie est générée. Par contre, si l'envoie de messages n'est pas configuré, ces messages vont juste se retrouver dans le fichier de messages localement. (les gens ne le savent pas toujours et laissent le spool gonfler ad vitam eternam...)
Pour le second point, Ansible a une directive prévue à rajouter dans le
ansible.cfgdans la section[default]:log_path = chemin/vers/le/fichier/de/log...Il faut juste que ce fichier puisse être écrit par le compte avec lequel tu lances les commandesansible*C'est presque comparable au fait de faire suivre l'exécution de son playbook par des redirections (ou mieux
| teequand on est devant), mais en mieux car ça a une vraie tête de journal : les lignes sont précédées de l'horodatage ainsi que le compte et le PId exécutant ; ce qui est pratique bien des fois.ARA est l'étape au dessus : ça défini juste une autre sortie parallèle qui enregistre les informations dans une base de données et permet ensuite de consulter la métrologie via une interface web (bon, en vrai il y a une API pas mal aussi ce qui fait que les usages peuvent être repensés/démultipliés) Cette couche supplémentaire a de l'intérêt quand on travaille quotidiennement et en équipe avec Ansible et qu'on n'est pas prêt à des solutions plus lourdes comme Tower/AWX.
"It is seldom that liberty of any kind is lost all at once." ― David Hume