Script : Que se passe t'il dans mon script

Retour à la page d'accueil Trucs et Astuces pour NT, 95, ... Boite à outils pour NT Mes amis sur le Web Liens
[Sommaire] [Fiche Précédente] [Fiche Suivant]
ObjetQue se passe t’il dans mon script, présentation des mécanismes de trace
Date le 22/10/2007.
Modifiéle 01/11/2007.
A consulterArticle paru dans ITPRO (Novembre 2006)
Accès rapide

[Exemple][Script][Tools][Conclusion][Liens]

Dans le domaine de l’administration des systèmes, la différence entre une solution commerciale et un petit un petit outil est souvent liée à la capacité du premier à produire de beaux rapports, précis et complets. Il vous signale ce qui marche, ce qui ne marche pas, ce qu’il faut corriger. Sans aller jusque là, il est parfois très simple de mettre en place des éléments de trace et de rapport même dans les scripts les plus simples.

Avoir des (bonnes) habitudes

Une des premières recommandations que je ferais c’est … d’avoir des habitudes… (de bonnes habitudes bien sur !).
Mes serveurs se ressemblent tous. Normal me direz-vous car je les déploie avec toujours les mêmes scripts.
Dans le cas qui nous intéresse, on y trouve toujours un dossier LOGS à la racine de C:.
Ce dossier est partagé (en lecture seule) pour permettre la consultation des rapports générés par les scripts.
J’essaye d’y rassembler tous les logs, les jours, les traces (IIS, DHCP, Firewall etc). Il m’est ainsi plus facile de chercher et de consulter ces logs mais aussi de faire le ménage et d’éviter ainsi un engorgement du disque système.
Je regroupe aussi tous mes scripts (que je déploie depuis ma station d’administration) dans un dossier Scripts. Je fais attention d’en limiter l’accès en écriture à un nombre limité de comptes et les comptes de services que j’utilise pour lancer ces scripts n’ont pas d’accès en modifications et j’utilise un dossier différent pour la création des fichiers journaux d’exécutions.

Quels sont les différents éléments à notre disposition ?

Pour savoir ce qui se passe (en temps réel) ou ce qui c’est passé lors de l’exécution d’un script plusieurs techniques sont à notre disposition :

  1. L’affichage à l’écran (Suivi instantané).
  2. La création d’un fichier texte et ses variantes fichier Excel/csv et fichier HTML (Consultation différée).
  3. L’utilisation des fonctionnalités intégrées de certains outils (Consultation différée)
  4. L’envoi de notification (Suivi instantané).
  5. L’envoi d’emails (Consultation différée).
  6. La création d’entrées dans le journal d’événements (Suivi presque instantané et Consultation différée).
  7. L’utilisation de Syslog (Suivi instantané et Consultation différée).

Affichage à l’écran

L’écran n’est qu’un fichier particulier pour l’interpréteur de commande. L’affichage des étapes sur l’écran reste un bon moyen de chercher les erreurs dans un script.
On peut aussi utiliser ces affichages pour les rediriger dans un fichier au moyen de l’opérateur « > » ou « >> ».

Pour envoyer un message sur l’écran, le plus simple reste la commande Echo qui accepte aussi les variables d’environnement du shell Windows.

C:\>Echo Etape 1 du programme
Etape 1 du programme

C:\>Set Message=Voici mon Message
C:\>Echo %Message%
Voici mon Message

C:\>Echo Exécution sur %computername% avec le compte %username%
Exécution sur XP02 avec le compte fdunoyer

On peut aussi varier les choses avec les commandes comme date, time

C:\>Date /t
24/09/2007

C:\>time /t
22:11

C’est aussi ce que fait le petit outil NOW.exe. Il cumule les fonctions de Echo et de Date /T :

C:\>now « Lancement du script»
Mon Sep 25 08:00:00 2007 – Lancement du Script

La création d’un fichier texte et ses variantes (fichier Excel/csv et fichier HTML)

Une fois la commande echo (now, date, time) maitrisée, vous pouvez soit contrôler l’écriture des résultats dans un fichier, soit rediriger la sortie globale du script vers un fichier.
La première solution permet un contrôle plus fin de ce qui sera dans le fichier, la redirection permet de facilement passer de l’écran au fichier.
Dans ce cas on se contentera de lancer le script de la manière suivante

C:\>MonScript >c:\logs\resultat.txt

Un petit rappel sur les opérateurs de redirection « > » et « >> » : le premier permet de rediriger les affichages dans un fichier qui sera créé ou recréé pour l’occasion. Le second permet de compléter un fichier existant. Ces opérateurs peuvent être employés au niveau du lancement du script (comme dans l’exemple précédent) ou à l’intérieur même du script au niveau de chacune des commandes (pour l’écriture dans un ou plusieurs fichiers cf. l’exemple de script en fin d’article). On peut aussi mixer ce qui apparaît à l’écran et ce qui est envoyé dans un fichier. Exemple d’affichages multiples :

:: Definition des sorties
Set LogBrief=c:\logs\bref.txt
Set LogFull=c:\Logs\full.txt
Set Message=Lancement du script de test des affichages
:: Affichage à l’écran
Echo %Message%
:: Création du fichier « Bref » et affichage d’un message daté.
Now %Message% >%LogBrief%
:: ajout dans le fichier « complet » du message
Now %Message% >>%logFull%
:: Exécution de commande diverses avec redirections dans le fichier « complet »
Dir c:\windows >>%LogFull%
:: on peut aussi utiliser les fichiers créés lors du script pour un affichage écran en fin de script
If exist %LogFull% type %LogFull%

Je peux aussi créer des fichiers plus structurés comme un fichier CSV

:: Definition des sorties
Set Sortie=c:\logs\sortie.csv
Echo Machine ;User >%Sortie%
Echo %ComputerName% ;%userName% >>%sortie
:: on peut même lancer directement Excel sur le fichier ainsi créé
If exist %Sortie% start %Sortie%

Pour la création d’un fichier HTML, c’est à peine plus compliqué qu’un fichier texte, il faut juste préparer un fichier d’entete et un fichier pied de page avec les lignes suivantes :

Entete.txt :

<html>
<body>

Pied.txt :

</body>
</html>

Pourquoi passer par ces fichiers ? Les caractères < et > sont pris par l’interpréteur de commande comme des caractères de redirection.

Le Script qui génère du HTML ressemblerait à :

:: Definition des sorties
Set Sortie=c:\logs\dir.html
Set Entete=c:\scripts\HTML-entete.txt
Set Pied=c:\scripts\HTML-entete.txt
:: initialisation
If exist %Entete% type %Entete% >%Sortie%
:: Corps du Script (par exemple)
Echo %ComputerName% >>%Sortie%
Echo %UserName% >>%Sortie%
:: Fin de fichier
If exist %Pied% type %Pied% >>%Sortie%

:: Affichage du fichier obtenu
If exist %Sortie% start %Sortie%

Une des grandes limites de l’interpréteur de commande pour générer des fichiers HTML, c’est son incapacité à gérer les <> qui sont les caractères utilisés dans le HTML pour gérer les balises. Mais avec un peu d’astuce ont peu faire quand même des choses (mais ça, ce sera une autre histoire).

L’utilisation des fonctionnalités intégrées de certains outils

La problématique du rapport d’exécution ou de la recherche d’incident d’exécution est parfois intégrée dans les outils. Ils sont alors à même de produire un fichier texte avec un journal d’exécution. La souplesse de la création du journal (où, choix du nom de fichier, ajout sur un fichier existant) est dépendante de l’outil. Si le nom et la localisation du journal est figée ce sera au script de traiter ce journal pour l’intégrer dans son rapport d’exécution.
Un des outils que j’utilise souvent (Robocopy) permet de créer un journal (/Log:nometchemindujournal) mais aussi d’insérer un compte rendu d’exécution dans un journal existant (/Log+:nometchemindujournal).

L’envoi de notification

Dans les outils natifs du système, la commande net send permet d’envoyer un message instantanée vers un opérateur ou un groupe d’utilisateurs. Son utilisation est simple :

C:\>net send fdunoyer « Ca marche »


Cf doc clipboard02.jpg

Le gros inconvénient c’est qu’elle demande que le service « Affichage des messages » soit lancé sur tous les postes de travail et que ce service introduit un brèche de sécurité sur les postes où il est démarré et dans bien des cas le service est non seulement arrêté mais aussi désactivé. (Au passage, avez-vous vérifié votre système ????)

La création d’entrées dans le journal d’événements.

Le mécanisme normal d’enregistrement de l’activité sur un système Windows est la consignation dans le journal d’événements.
Votre script peut aussi utiliser les journaux d’événements locaux et distants pour marquer les étapes de son exécution. L’un des avantages du journal d’événements, c’est de pouvoir replacer les étapes de votre script dans la continuité des évènements du système.
Exemple d’utilisation de LogEvent :

C:\>Set Message=Message pour l’eternite
c:\>logevent -s I -r "Clonage" -e 999 %Message%
Logevent command completed successfully!

Je viens d’enregistrer un évènement dans le journal d’application :


On retrouve dans l’événement la source (clonage), l’ID d’évènement (999) et mon message pour l’éternité.

Un des avantages de l’enregistrement d’évènements c’est qu’il est possible de visualiser les étapes avant la fin du déroulement du script.

L’envoi d’emails.

L’envoi d’un email permet de matérialiser la fin de l’exécution du programme ou une erreur majeure dans son déroulement.
Un des avantages des outils d’envoi de mails, c’est leur indépendance par rapport au système qui les héberge. Un mail peut être émis par un compte qui n’a qu’un minimum de droits sur le système contrairement à la création d’une entrée dans le journal d’événements. La consultation du mail rentre dans une démanche normale de l’activité des destinataires. Ceux-ci peuvent être des utilisateurs « classiques » (comptable, trésorier, directeur).

L’utilisation de Syslog.

Syslog est un service issu du monde Unix qu’on pourrait décrire comme un enregistreur d’événements au travers du réseau.
L’idée c’est de mettre en place un serveur qui collecte tous les événements qui peuvent survenir sur le réseau. Ca peut être l’imprimante qui manque de papier ou un serveur en train de s’arrêter. Attention car les messages Syslog passent en clair sur le réseau.

C:\>Set Message="Etape 2 : Envoie d'un message Syslog"
C:\>klog -h %Syslog% -F user -L notice -m %Message%

Pour suivre les événements syslog, on peut soit avoir une console qui affiche en temps réel les messages qui transitent sur le réseau, soit travailler sur l’enregistrement de ces messages dans un fichier.

Exemple de message sur un serveur syslog

Voir la fiche mise en place d'un serveur SYSLOG [Fiche -14]

Choisissez le ou les outils qui conviennent à votre problématique.

L’intérêt n’est peut être pas de déployer toutes ces méthodes en même temps mais de pouvoir choisir celle qui correspond à vos besoins ou à vos attentes.
L’utilisation simultanée de plusieurs de ces méthodes permet aussi de disposer de comptes-rendus complémentaires. Le fichier Log-full par exemple contient un compte rendu de chacune des étapes de l’action lancée, l’enregistrement des événements ou le syslog permet de savoir ce qui se passait sur le serveur ou sur le réseau au moment d’une action.

Que voulons-nous faire ?

Voila un scénario qui peut être le votre dans une PMI/PME sans solution de sauvegarde centralisée.

J'ai un parc de serveurs du domaine chezmoi.local sur lequel le serveur SERCOM (\\SERCOM) héberge le dossier de la compta (d:\compta).
Ce serveur qui héberge les données de la comptabilité doit être sauvegardé tous les jours pour éviter de perdre plus d'une journée de travail de la comptable et repartir le plus vite possible en cas d'incident (Sauvegarde à J-1).

Toutes les nuits à 00:01, je vais donc copier le dossier des données de la compta sur un autre serveur SERDVP (\\SERDVP) dédié au développement mais qui comporte un espace disque suffisant pour héberger un dupliqua des données comptables.

Une fois cette copie effectuée, je ferais une sauvegarde sur fichier de l'état du système (à l’aide de l’outil NTBackup). Chacune des étapes sera journalisée dans le journal d'événements du serveur de la Compta et le serveur syslog (syslog.chezmoi.local) de la société sera aussi "informé" de toutes les actions.
En fin d'action, un mail (serveur de mail chezmoi.com) sera envoyé à l'administrateur système pour le notifier de l'achèvement des opérations.

Outils utilisés

Un exemple de script commenté :

Un libellé et un petit commentaire ne font jamais de mal.

@title Titre de la fenetre d'execution
Rem +---------------------------------------------------------------+
Rem + Mise a Jours du dossier Compta +
Rem + FD-Service - Montpellier +
Rem + François Dunoyer +
Rem +----------------------------------------------------------------+
Rem + Date : 01/09/2006                 +
Rem + maj : 22/10/2007 +
Rem +----------------------------------------------------------------+

Mise en place du reporting.

Initialisation des variables. L'utilisation de ces variables permet d'adapter facilement le script à toutes sortes de situations. Pour des raisons d'efficacité des copies, il vaut mieux que le script s'exécute directement sur un des serveurs mais ce n'est pas obligatoire pour la partie copie des fichiers.

Rem Machine source et Machine de destination
Set Source=\\SVRCOM
Set Dest=\\SVRDVP

Je pars toujours du principe que je suis sur un machine connue sur laquelle j’ai pu mettre en place (pour des raisons de taille disque ou autres) une organisation différente de mon organisation habituelle. Si tel est le cas, j’ai du prendre la peine de modifier les variables d’environnement pour en tenir compte. Je peux aussi modifier temporairement ces variables avant d’appeler un script. Par contre, si les variables d’environnement ne sont pas positionnées le script se chargera de travailler sur mes valeurs habituelles.

Rem Repertoire de Log (D:\repertoire).
:: valeurs par defaut si non configurees dans les paramètres systèmes
if "%SysLog%"=="" Set Syslog=syslog.chezmoi.local
if "%LogDir%"=="" Set LogDir=c:\Logs
if "%SMTPS%"=="" Set SMTPS=smtp.chezmoi.local

Il y'a création de 2 files journaux d’exécution. Un fichier de compte rendu "bref" qui est envoyé par mail à l'administrateur et un fichier de compte rendu détaillé "Full" à consulter sur la machine en cas de problème. Ce fichier détaillé peut être daté pour garder un historique. Il faut alors faire attention à purger régulièrement le dossier historique.

Pour Windows 2003 et XP, les lignes suivantes créent une chaine AAAAMMJJ. Il y'a une "pirouette" pour gérer les dates sur Windows 2000 qui sont de la forme "lun 19/09/2006".

Rem Calcul de la chaine DATE AAAAMMJJ
Set WD=%DATE:/=%
if "%WD:~4,1%"=="2" (
    set D=%WD:~4,4%%WD:~2,2%%WD:~0,2%
) ELSE set D=%WD:~9,4%%WD:~7,2%%WD:~5,2%

Il y'a création de 2 fichiers "Log". Un fichier de compte rendu "bref" qui est envoyé par mail à l'administrateur et un fichier de compte rendu détaillé qui reste sur la machine.

Set LogFileBref=BCK-log.log
Set LogFileFull=BCK-Log-%D%.log

Rem Dossier a sauvegarder
Set COMPTAREFDIR=d$\compta
Rem Dossier de stockage des sauvegardes
Set DestDir=d$\Sauvegardes\compta

Destinataires principaux et secondaires des messages d'information. Il vaut mieux préférer l'émission vers un alias ou un groupe de diffusion qui permet de changer les destinataires sans remettre en cause le script.

:: Destinataire(s)
set destinataire=adminserveurs@chezmoi.com

Mise en place des logs (en double pour le log bref et le log détaillé). Les fichiers sont crées.

Set message=Mise en place du backup Comptabilite depuis %Source% vers %Dest%
now %Message% >%LogDir%\%LogFileBref%
now %Message% >%LogDir%\%LogFileFull%
klog -h %Syslog% -F user -L notice -m %Message%

Mise à jour du journal des événements local et distant. L'utilisation des noms de machine permet éventuellement d'utiliser une 3eme machine pour effectuer les taches.

Set Message="Clonage Compta de %ComputerName% vers %Dest% - Debut "
logevent -m %Source% -s I -r "Clonage" -e 1 "%Message%"
logevent -m %Dest% -s I -r "Clonage" -e 1 "%Message%"
klog -h %Syslog% -F user -L notice -m %Message%

Copie différentielle de tous les fichiers *.cpt depuis le partage \\SVRCOM\d$\Compta vers le partage \\SVRDVP\d$\sauvegardes\compta.
Pas d'affichage des barres de progression.
Purge des fichiers excédentaires à l'arrivée,
exploration des sous arborescences
et log dans le fichier log détaillé c:\logs\BCK-Log-Full.log

robocopy %Source%\%COMPTAREFDIR% %RootBck%\%DestDir% *.cpt /s /r:3 /w:5 /NP /Purge /Log+:%LogDir%\%LogFileFull%
logevent -m %Source% -s I -r "Clonage" -e 999 "Clonage Compta de %ComputerName% vers %Dest% - Fin"
klog -h %Syslog% -F user -L notice -m %Message%

Mise à jour des journaux : fin de la copie. Le message est enregistré à la fois dans le fichier journal détaillé et dans le fichier journal sommaire.

Set message=Fin du backup Comptabilite depuis %Source% vers %Dest%
now %Message% >>%LogDir%\%LogFileBref%
now %Message% >>%LogDir%\%LogFileFull%
klog -h %Syslog% -F user -L notice -m %Message%

Mise à jour du journal des événements local et distant.

Set Message="Clonage Compta de %ComputerName% vers %Dest% - Fin"
logevent -m %Source% -s I -r "Clonage" -e 999 %Message%
logevent -m %Dest% -s I -r "Clonage" -e 999 %Message%
klog -h %Syslog% -F user -L notice -m %Message%

Sauvegarde de l'état du système de la machine où s'exécute le script

Set Message="Etat du systeme de %ComputerName% : demarrage"
now %Message% >>%LogDir%\%LogFileBref%
now %Message% >>%LogDir%\%LogFileFull%
klog -h %Syslog% -F user -L notice -m %Message%
Set BackupName=%Cible%\d$\sauvegardes\ES\%ComputerName%-ES-%D%.bkf
ntbackup.exe backup systemstate /n "Etat du systeme pour %ComputerName% au %DATE%" /d "ES-%ComputerName%-%D%" /F "%BackupName%" /v:no /r:no /rs:no /hc:off /m normal /j "ES-%ComputerName%-%D%" /l:f /snap:on
Set Message="Etat du systeme de %ComputerName% enregistré"
klog -h %Syslog% -F user -L notice -m %Message%

Ajout des Informations de localisation du fichier Log détaillé. Ces informations feront parties du mail que recevra l’opérateur désigné en début de Script.

:: Ajouts de Commentaires sur le fichier détaille
Echo Le compte rendu detaille de l'operation est disponible >>%LogDir%\%LogFileBref%
Echo dans le dossier \\%ComputerName%\Logs$ >>%LogDir%\%LogFileBref%
Echo Voir le fichier file:\\%ComputerName%\Logs$\%LogFileFull% >>%LogDir%\%LogFileBref%

Envoi d'un message en fin de travail. L’utilisation de l’adresse @chezMoi.local est intentionnelle dans mon domaine chezmoi.com. Comme je ne créé pas un compte de mail pour chacun des serveurs, les mails venant d’un utilisateur inconnu de mon domaine de messagerie seraient refusés. Chezmoi.local est un domaine « externe » pour mon serveur de messagerie.

Rem Notifications
blat %LogDir%\%LogFileBref% -t f%Destinataire% -s "%ComputerName% : Fin du backup"
rem Envoie du message par mail
Set Message=%ComputerName% : Backup des fichiers Compta blat %LogDir%\%LogFileBref% -to %Destinataire% -subject "%Message%" -noh -f %computerName%@chezmoi.local -server %SMTPs%
Set Message="Emission des mails de fin de script"
klog -h %Syslog% -F user -L notice -m %Message%

En conclusion

Au travers de ces différentes techniques, nous avons pu voir comme tracer l’exécution d’un script et récupérer les résultats d’exécution de logiciels qui ne sont pas toujours prévus pour cela.
Je me suis volontairement limité à l’utilisation de l’interpréteur de commande standard enrichi de quelques uns de mes outils préférés.
Une fois ces outils maitrisés, d’autres voies de développement peuvent s’offrir à vous en utilisant des environnements de scripts plus riches comme Kixtart, VBScript ou maintenant PowerShell.

Références / Biblio / Liens :

Les autres fiches

O01 : Accès rapide à l'annuaire interne (Active Directory) via le carnet d'adresse
O02 : Utilisation de la messagerie.
O03 : Envoyer de gros documents
O04 : Utilisation des Dates dans les noms de fichiers (ou pour le tri)
O05 : Archiver un dossier Outlook manuellement
O06 : Déplacer le dossier Documents and Settings
O07 : TSE : Installation d'une application en mode terminal Server
O08 : Création de nouveaux Utilisateurs[10/2007]
O09 : Un exemple de Script de backup
O10 : Activer la recherche automatique du Proxy
O11 : Périmètre d'utilisation de VNC, recommandation et optimisation
O12 : Visualiser l'Active Directory dans l'Explorateur
O13 : Que se passe t'il dans mon script, présentation des mécanismes de trace[10/2007]
O14 : Mise en place d'un serveur SYSLOG[11/2007]

Q99 : Fini pour le moment ?


Le tabac nuit gravement à la santé ! Et la nicotine encrasse non seulement les poumons mais aussi les claviers et les ventilateurs ! Copyright ©1997-2008, François Dunoyer, Dernière modification le  
Recommander cette page