Exécuter un script

Un script du registre (voir « Gérer les scripts ») se lance depuis sa fiche : affichez la version voulue, puis Exécuter. Ces écrans sont réservés aux Administrateurs.

Lancer une exécution

L'écran Exécuter demande d'abord les Paramètres déclarés par la version (un astérisque marque ceux qui sont obligatoires), puis la Cible :

• Agent unique : une machine équipée d'un agent Outpost actif ;
• Groupe de machines : tous les agents d'un groupe de machines à la fois. Au-delà du seuil de confirmation du script (25 machines par défaut, voir « Gérer les scripts »), cochez Je confirme le déclenchement sur plusieurs machines à la fois., sinon le lancement est refusé ;
• Locale, marquée Sensible : le script tourne sur le serveur de Portail ZAPP lui-même. Ce choix n'est pas proposé sur une instance hébergée en SaaS.

Quand le module Agents Outpost n'est pas activé, les cibles distantes sont grisées et seule l'exécution locale reste possible.

Exécuter lance le script et ouvre le suivi de l'exécution (ou du lot, pour un groupe de machines).

Ce qui peut bloquer un lancement

Un message d'erreur s'affiche au-dessus du formulaire quand :

• une valeur de paramètre ne respecte pas les règles de la version (obligatoire, format, minimum, maximum, liste de valeurs) ;
• le Ciblage du script exclut la cible choisie (par exemple un script Local uniquement lancé sur un agent) ;
• vous n'êtes pas couvert par une règle d'Autorisation par cible pour cet agent (exécution distante) ;
• une exécution du même script est déjà en cours sur la même cible. Pour un agent unique, la nouvelle demande est mise en attente et part dès que la précédente est terminée ; pour un groupe de machines ou en local, elle est refusée ;
• vous avez lancé plus de 20 exécutions dans la dernière minute ;
• le script référence un secret introuvable, ou le module Secrets n'est pas activé ;
• un administrateur a coupé toutes les exécutions (voir plus bas).

Le message est dans votre langue et précise la cause (paramètre en cause, nombre de machines et seuil de confirmation…). L'API des exécutions (POST /api/v1/script-executions/local, /remote, /remote-group, /{id}/cancel) répond alors 400 avec le code stable (error, celui du tableau de dépannage plus bas), une phrase en anglais (message), la clé de traduction (messageKey) et ses valeurs (parameters) ; le message technique reste dans le journal du serveur.

Suivre une exécution

L'écran Exécution indique le Statut (En attente, En cours, Réussie, Échouée, Annulée, Expirée (timeout)), la Cible, la Machine, l'Exit code, l'Horodatage et la personne qui l'a lancée (Déclenché par), puis la Sortie du script. Une sortie trop longue est coupée et le signale par « Sortie tronquée. ». Quand une exécution échoue sans rien écrire, la Raison de l'échec (rapportée par l'agent) est affichée. Un avertissement signale aussi le cas où l'agent n'a pas pu limiter le processeur et la mémoire du script.

Tant que l'exécution n'est pas terminée :

• Actualiser interroge l'agent pour obtenir le dernier état ;
• Annuler demande l'arrêt de l'exécution, après confirmation.

Une exécution qui dépasse le timeout du script passe à Expirée (timeout).

Lots et historique

• Un lancement sur un groupe de machines ouvre l'écran Exécution sur un groupe de machines : une ligne par machine avec son statut et son exit code ; Détail ouvre l'exécution de cette machine.
• Une machine désactivée (révoquée, en quarantaine ou archivée) pendant un lancement sur un groupe n'arrête pas le lot : sa ligne est en échec, avec « L'agent Outpost était révoqué, en quarantaine ou archivé au moment de l'envoi : le script ne lui a pas été envoyé. », et les autres machines du groupe exécutent le script.
• Une machine annulée dans un lot reste dans le lot (statut Annulée). Quand toutes les machines du lot ont terminé et qu'au moins une a échoué, a été annulée ou a expiré, les destinataires des notifications d'échec du script reçoivent une seule notification pour le lot — y compris quand le lancement a été interrompu par un arrêt du serveur : le lot est alors repris au redémarrage ou dans le quart d'heure qui suit.
• Historique (depuis la fiche du script ou une exécution) liste toutes les exécutions du script, la plus récente en premier, avec la version, la cible, la machine, le statut et l'auteur du lancement.

Quand le module Grilles de données est installé, ces listes s'affichent en grille (tri, filtres).

Couper toutes les exécutions en urgence

Le paramètre ScriptRunner:KillSwitchEnabled de l'écran Configuration, passé à true, refuse aussitôt tout nouveau lancement de script, quelle que soit la cible. Les exécutions déjà en cours ne sont pas arrêtées : annulez-les une à une si besoin. Repassez le paramètre à false pour rétablir les lancements.

Dépannage des exécutions planifiées

Une exécution planifiée (créée par l'API de ScriptRunner) est une tâche du Planificateur (Administration › Instance et exploitation › Planificateur). Quand le lancement échoue, l'Historique d'exécution de la tâche affiche la cause dans votre langue ; l'API et les exports reçoivent le code stable suivi d'une phrase en anglais. Le message technique reste dans le journal du serveur.

Un code absent de ce tableau s'affiche « Échec du déclenchement : code » ; une erreur imprévue s'affiche « Erreur inattendue » avec son type, le détail étant dans le journal du serveur.

Voir aussi

• « Gérer les scripts » : créer un script, ses versions et ses règles d'autorisation.
• « Suivre les agents Outpost » : les agents et les groupes de machines.