Lancer des scripts avec retour graphique via cron

Support Debian
#1

Bonjour à tous…

voilà, je cherche à faire ceci:
lancer, via crontab, une série de script .sh (par exemple) afin d’exécuter une commande sur plusieurs machines, mais avec un retour graphique via une fenêtre de terminal PAR machine.
Ca prendrait la forme d’une fenêtre de terminal, qui se “logge toute seule” (les clés ssh ont été copiées avant, par exemple) et me lance la commande avec les arguments… et j’ai, dans ma fenêtre, un « retour » d’information.

Prenons un exemple, j’utilise un soft cli d’encodage vidéo (appelons le videolib) qui encode automatiquement les vidéos dans un dossier précis … que je veux lancer avec qq arguments (selon les paramètres d’encodage, quoi)… normalement, si je suis sur la machine en direct et que l’exec est dans le dossier Documents du dossier utilisateur en cours, je lance ~/Documents/videolib -arguments1 -arguments2
ou bien je me déplace dans le bon dossier avec cd, puis je tape ./videolib -arguments1 -arguments2

et dans mon terminal, je vois l’encodage qui se lance, le nom du codec utilisé, le bitrate, etc… (en fonction des arguments) et j’ai un retour toute les 30 secondes, me disant: xx% done, no bad block, no error, VBR= xxxx b/s, etc… ce qui me permet de vérifier de garder un oeil sur l’encodage (et également de vérifier que les machines tournent bien…)… évidemment, si ca plante, ou si j’ai une coupure réseau, ca me mettra un retour selon le cas… « bad call », « error machin » « connection aborted » , etc… en fonction du souci.
Evidemment, les retours sont déjà programmés dans l’exec, hein… (mais pas par moi, ce n’est pas de ma compétence… hélas)

L’idée d’avoir le retour juste par un mail ou dans un fichier texte, beeeen, non. L’idée c’est que dès que je me connecte à la machine, je vois rapidement les diverses fenetres de terminal, et les retours d’info pour relancer si besoin, etc…

ah oui: et ce serait sur un Pi, donc, Raspbian…

Merci de vos lumières !

#2

Bonjour,

À ma connaissance, je pense qu’il n’y a que Ansible qui puisse faire ce genre de choses.
Le problème que tu risques de rencontrer sera de récupérer depuis ton serveur “maître” l’évolution de l’exécution sur chacun de tes serveurs “esclaves”.

Mais ta problématique est très intéressante, je vais y réfléchir ce week-end.

LeDub qui pense TWS serait un peu trop puissant pour cette tâche !!!

#3

Ansible oui pourquoi pas, mais aussi Saltstack et compagnie, l’avantage de Ansible c’est que tu aura le retour dans le terminal de chaque commande, et c’est agentless

#4

Bon alors, j’ai avancé sur ma problématique… j’ai trouvé l’essentiel de la solution avec xdotools… c’est un peu “bourrin”, j’en doute pas mais mes connaissances en l’état me limitent bcp…

mon script démarre avec

killall lxterminal (pour virer toutes les instances précédentes)
lxterminal -e ssh -t user@adressip1 /Users/user/Documents/videolib -arguments1 -arguments2 (ce qui m’affiche automatiquement un lxterminal avec la commande) puis j’embraye avec xdotool
xdotool key ctrl+shift+t
sleep 1
xdotool key type "ssh -t user@adressip2 /Users/user/Documents/videolib -arguments1 -arguments2"
xdotool keu "Return"
sleep1
et je recommande pour la machine en ip 3, etc…

Quand je lance le script à la main, ca fait le job (y’a peut etre des choses à améliorer, hein ?)… par contre, j’arrive pas à le faire déclencher par cron…
j’ai mis, par exemple, le fait que la machine redémarre à 8h00, en semaine, et qu’elle lance le script dès qu’elle a rebooté… donc dans cron:
00 08 * * 1,2,3,4,5 pi reboot
@reboot pi /home/pi/Documents/script.sh
mais également, comme je veux que le script se lance en fin de journée, en semaine, à 20h00, par exemple, j’ai également mis:
00 20 * * 1,2,3,4,5 pi /home/pi/Documents/script.sh
et puis j’ai fait un sudo service cron reload pour charger les nouvelles infos…
mais rien… j’ai autant mis cela dans crontab -e que dans sudo crontab -e (avec l’utilisateur root dans ce cas)
je suppose que c’est simplement dû à ma méconnaissance de cron… alors si on veut bien m’aider la dessus également…

#5

ceci dit, si on veut bien m’expliquer un peu plus Ansible, je suis fermé à rien, hein (:slight_smile:

#6

Ansible utilise ce que l’on appel des Play Book décrivant des actions à faire depuis une machine vers un ou plusieurs machines.
Pour ce qui est de t’expliquer plus en avant je t’invite plutôt à mettre ne place un Ansible et à écrire une première recettes toi-même (un grand nombre d’article traite de on utilisation libre à toi.


https://memo-linux.com/ansible-mes-premiers-pas/

Avec tout ça tu devrais avoir ce qu’il te faut pour démarrer, commencer avec Ansible c’est l’adopter.

Pour information avec Ansible et Terraform j’ai trouver mes outils de Dev-ops favori pour le montage de mes labs incessant :wink:

1 J'aime
#7

bon en l’état actuel, c’est CRON qui bloque… j’ai beau rentrer les infos comme ci dessus (donc a priori comme il faut ??) … ben ca se lance pas.

que ce soit dans crontab de base ou celle du sudo…

si quelqu’un veut bien m’aider, là, ca fait des jours que je tourne et je comprends pas. Si je lance mes scripts à la main, aucun souci… ils sont executables, ils font ce que je veux… mais pour un lancement automatique, je vais me faire cuire un oeuf pour linstant…

#8

Bonjour le monde,

J’ai réfléchi à ton problème, le plus simple qu’Ansible (que j’ai pourtant proposé mais qui présente l’inconvénient de l’étudier de façon importante) serait de pratiquer comme cela :

  1. Connexion en SSH sur chacun de tes serveurs
  2. Exporter la variable DISPLAY en y mentionnant l’IP de ton poste maître
  3. Exécuter un terminal avec la ligne de commande à lancer

Ainsi, chaque serveur va envoyer son terminal sur le serveur X du poste maître.

Je reconnais que la méthode risque d’être un peu plus compliquée à mettre en place avec une CRON.

LeDub qui va jouer, dans 2 semaines, avec Ansible … youpi !!!

#9

après avoir consulté les syslog, mon action en cron est présente… donc, c’est que ca se lance, quand meme… mais qu’il ne se passe rien ???

il faut que je creuse… exporter la variable display, ok mais comment ? peux tu me donner un exemple ?

#10

Pour reprendre un peu à l’heure actuelle ton script se lance avec quel utilisateur (si c’est un utilisateur regarde bien du côté du fichier de configuration de sudoers) ?
Tu lance une commande à rallonge ou un simple script bash (si oui fais toi un peu de echo pour savoir ou ça plante) ?

#11

pour un script 1.sh, situé dans le dossier Documents de l’utilisateur user1 ,à exécuter à midi, en semaine ca donnerait, normalement, si j’ai bien compris:

00 12 * * 1-5 user1 /home/user1/Documents/1.sh

ici, user1 est évidemment un sudoer…
faire un peu de echo, ok, mais je suis tjrs un gentil neophyte, comment je fais ca ? :slight_smile:
en l’état, la seule chose que je vois, c’est une ligne dans le syslog a l’heure dite, avec cron, qui semble me dire que ca se lance… mais aucun résultat. Le script, en gros, lance lxterminal et y applique des commandes.

#12

je continue à chercher. EN l’état, je pense que cron appelle bien mon script. j’ai demandé à ce qu’il exporte le résultat dans un fichier texte. Celui ci est mis à jour à la bonne heure à chaque fois…mais il est vide !

Donc, je pense que c’est que mon script n’a pas toutes les fonctions pour être exécuté par CRON … peut etre dois déclarer un DISPLAY ? ou bien réveiller ce même display ??

#13

Je te propose d’ajouter, au début de ton script 1.ksh ces 3 lignes :

set -xv
exec 1>/tmp/sortie.log
exec 2>/tmp/sortie.err

Puis après un exécution, tu regardes les fichier /tmp/sortie.log et /tmp/sortie.err.

La variable DISPLAY est l’adresse qu’un client (une fenêtre) va utiliser pour joindre le serveur X. En changeant cette variable, tu changes la destination de l’affichage de la fenêtre.
Pour que cela soit possible, côté serveur X, il faut jouer avec “xhost” pour autoriser l’affichage dont l’expéditeur n’est pas local.

LeDub qui conseille à Krr d’avancer à petits pas et de ne pas brûler les étapes.

#14

je ne compte rien bruler mais en fait, j’aimerais que la chose soit en place pour l’été -___-’

mais je sais que “va piano, va sano” … quoiqu’il en soit, j’ai qq améliorations: parfois ca se lance à l’heure, parfois pas !! Depuis que j’ai rajouté, dans cron, avant ma commande un DISPLAY=.0 …donc, je pense que c’est une question de savoir si le display est “sleep” ou pas…maintenant…

mais je vais voir de rajouter ce que tu dis pour comparer.

#15

Krr, le dépannage de ton problème ne pourra se faire qu’après analyse des fichiers /tmp/sortie.log et sortie.err.
As-tu regardé les traces /var/log/cron* pour savoir si ton script est exécuté ?
D’ailleurs, pour ton fichier de ta crontable, je te conseille d’y mettre cette ligne à la place de la tienne :

0 12 * * 1-5 user1 /home/user1/Documents/1.sh 1>/tmp/sortie_cron.log 2>/tmp/sortie_cron.err

LeDub qui va, dans quelques jours, jouer avec des GNU/Linux à foison !!!

#16

J’ai déja un fichier output.txt qui prends la sortie du cron…

je n’ai pas de log cron… mais je vois bien le cron qui s’active avec la commande, à l’heure dite, dans syslog…

je suis sur Raspbian… peut etre cela explique qq différences ?

#17

je suis sur Raspbian… peut etre cela explique qq différences ?
Non, il n’y a aucune différence car Raspbian reste quand même une debian !

#18

le fichier .err … que suis je sensé voir dedans ?

il semble reproduire chaque ligne de mon script… en dessous de celle ci mais commencant par le char +

??

#19

Hello !!

ok, j’ai compris le principe du fichier .err … cool.

J’ai aussi compris que, parfois, l’erreur est qu’il n’arrive pas à ouvrir le display… je suppose que c’est parce que le Pi se met en veille ??? ou autre chose…

comment puis je dire, dans mon script, de réveiller le Pi ? ou d’avoir un écran actif comme si qq’un était connecté ?? car le Pi en question, évidemment, est Headless…