par Dick Lewis
Un script Perl aide à attraper un voleur.
Ou comment détecter l'extinction d'une machine et transmettre l'information à l'équipe de surveillance ...
Pendant les nuits et les week-ends, voilà que des RAM, des CPU et des cartes vidéo haut de gamme commencèrent à disparaître des PC de ma société. Le voleur éteignait les appareils, forçait les boîtiers et retirait les composants. Le matin suivant, les utilisateurs découvraient les appareils ventre ouvert. Il y a bien des patrouilles de gardiens dans l'immeuble, mais en raison de la surface et de la grande quantité de PC, ils ne peuvent pas surveiller tous les ordinateurs à la fois. Pourtant les gardiens avaient leur petite idée sur le moyen d'attraper le voleur. Les utilisateurs éteignent leurs moniteurs pendant la nuit pour économiser de l'énergie, mais beaucoup d'entre eux laissent leurs PC allumés pour rester en réception. Les gardiens ont pensé qu'ils pourraient appréhender le coupable s'ils étaient informés immédiatement de la mise hors tension des PC. C'est ainsi que mon équipe a développé un script Perl qui envoie des " pings " aux PC sous tension et alerte les gardiens dès que l'on éteint un PC.
Les gardiens et mon équipe ont dressé ensemble la liste des exigences pour le script. Nous avons aussi parlé de quelques fonctions que les gardiens auraient aimées, mais qui n’étaient pas indispensables. Mon équipe a ensuite traduit les exigences en pseudocode : des phrases décrivant ce que l’on attend du code. Puis ces phrases ont été transformées en script. Pendant le processus de traduction, nous avons choisi le langage script le plus adéquat pour ce projet et comment répondre à chaque critère. Voici la liste des exigences avec nos considérations et solutions pour chacune d’elles.
Exigence 1 : Envoyer un » ping » à une liste de PC cible et informer le gardien quand un PC ne répond pas correctement au ping.
Considérations : Nous aurions pu écrire ce code en script shell Windows ou l’un de plusieurs autres langages, mais nous avons choisi Perl parce qu’il sollicite très peu la CPU. Le script lit dans des fichiers d’entrée et Perl est efficace dans ce genre d’exercice.
Solution : Utiliser les modules Perl Net::Ping pour le test ping et Mail::Sendmail pour le e-mail et les notifications par pager. Si possible, fragmenter le code en sous-routines de paging et de test.
Exigence 2 : Le message de paging doit indiquer le nom du PC et son emplacement dans l’immeuble.
Considérations : Créer une liste d’entrées contenant le nom et l’emplacement de chaque PC. Les descriptions de l’emplacement peuvent contenir des espaces.
Solution : Créer un fichier CSV (Comma Separated Value) et utiliser la fonction split de Perl pour diviser la ligne en nom de PC et emplacement. Vérifier que ce fichier d’entrée existe et, dans la négative, sortir avec un message d’erreur.
Exigence 3 : Comme la liste des destinataires du paging n’est nullement figée, il faut pouvoir la modifier facilement.
Considérations : Nous aurions pu coder en dur la liste des destinataires dans le script, mais il est toujours risqué de modifier un script testé parce qu’une simple faute de frappe peut vous renvoyer en phase de débogage. Il est toujours préférable d’utiliser un fichier d’entrée que le script passe au crible.
Solution : Créer une liste d’entrées contenant les adresses des destinataires du paging. Vérifier que ce fichier d’entrée existe et, dans la négative, sortir avec un message d’erreur.
Exigence 4 : Enregistrer les échecs du ping – heure, nom du PC, détails sur l’incident lié à l’échec – dans un fichier journal.
Considérations : Aussi bien les gardiens que la direction veulent avoir un fichier journal détaillant les résultats de la session pour pouvoir analyser l’heure et l’emplacement des incidents de vol.
Solution : Créer un fichier de sortie pour y enregistrer les échecs du ping. Incorporer dans le nom du fichier journal, sa date et son heure de création. Journaliser les incidents d’échec de ping – y compris l’heure, le nom du PC et les détails de l’incident – dans le fichier.
Exigence 5 : Quand le script est lancé chaque jour, il doit interroger les ordinateurs et enlever de la liste toute machine offline à ce moment-là .
Considérations : Quand le script démarre, il doit envoyer un ping à tous les noeuds pendant une session d’initialisation, puis utiliser cette liste pendant la période de test. A sa prochaine exécution, le script devra supprimer cette liste temporaire et en créer une nouvelle.
Solution : Utiliser le fichier d’entrée avec la première session de script et collecter les noeuds qui répondent, dans un tableau contenant leurs noms et emplacements pendant la période de test. Cette section d’initialisation peut justifier sa propre sous-routine.
Exigence 6 : Quand un PC se met offline, n’envoyer un paging qu’une fois pour indiquer cela. Si le PC revient online, envoyer un paging » all clear » (tout va bien).
Considérations : Suivre le dernier état d’un noeud soumis au ping. Quand l’état change, déclencher un paging avec un message approprié indiquant l’état offline ou online. On pourrait utiliser un fichier, ou plusieurs (un par noeud), des streams de fichiers NTFS, ou une liste Perl pour suivre l’état des PC. La lecture de fichiers ou de streams de fichiers NTFS ajouterait de l’overhead.
Solution : Créer une liste Perl des noeuds défaillants. Un noeud qui n’est pas sur la liste était online lors du dernier ping.
Exigence 7 : Réduire au minimum les fausses alarmes tout en offrant une détection et une notification rapides.
Considérations : Les résultats du ping ne sont pas toujours fiables. Un ping peut échouer une fois, puis réussir à la tentative suivante. Si le résultat du test n’était fondé que sur un ping, un raté de réseau momentané pourrait provoquer une fausse alarme. A l’inverse, on pourrait utiliser un ping avec une longue valeur de temporisation (timeout). Mais, cela pourrait ralentir la notification.
Solution : Si le premier ping d’un noeud échoue, répéter aussitôt le ping sur ce noeud. N’envoyer le paging qu’après deux échecs du ping.
Fonction facultative 1 : Indiquer dans le paging la probabilité d’un véritable incident. La probabilité d’un vol est plus grande si plusieurs PC sont offline que s’il n’y en a qu’un seul.
Considérations : Nous savons déjà si les machines sont online ou offline. Il suffit donc de compter le nombre de machines offline pour évaluer le niveau de risque.
Solution : Compter le nombre de noeuds en échec sur la liste Perl créée pour satisfaire à l’exigence 6. Si la liste contient un noeud, le risque est faible ; avec deux noeuds, il est moyen ; avec trois noeuds ou plus, le risque est élevé.
Fonction facultative 2 : Quand un incident potentiel est détecté, passer à la détection en mode sensible.
Considérations : Nous envoyons déjà des pings aux machines pour déterminer si elles sont offline. Si un noeud quelconque est offline, nous pouvons réduire la durée entre les pings (c’est-à -dire le temps de mise en sommeil) pour rendre le script plus sensible. Si la machine offline se réveille, nous pouvons rétablir l’intervalle par défaut pour le temps de mise en sommeil.
Solution : Placer la liste Perl des noeuds défaillants dans une instruction If et diminuer l’intervalle ping de 30 secondes à 10 secondes après avoir détecté le premier échec du noeud. Remarque : Si un grand nombre de machines sont soumises au ping, il faudra peut-être allonger sensiblement le cycle entre les pings, parce que les machines reçoivent le ping l’une après l’autre et pas simultanément.
