Sommaire
I. Présentation
Ce troisième volet relatif aux techniques de script,correspond certainement à la phase la plus négligée lorsque tout va bien. En effet, les journaux sont généralement délaissés lors de l’élaboration des scripts techniques qui vont à l’essentiel. Mais je ne vais pas dénoncer un travers dans lequel je me laisse aussi aller parfois.
Je vais donc essayer de développer ce sujet afin d’exposer quelques aspects pratiques.
II. Définir un journal d’installation
En matière de journalisation, on peut distinguer 2 approches distinctes mais également complémentaires.
1. Journalisation via le programme lui-même
On laisse souvent le soin de a journalisation d’un processus d’installation au programme lui-même (ou pas 🙂 ). Donc la première question à se poser est : Est-ce que ce programme laisse des traces exploitables, une fois l’installation achevée ? Chaque éditeur est libre de ses choix, et peut consigner ces traces dans un fichier (.log ou autre) ou dans un journal Windows (spécialisé ou non). Toutefois, la technologie MSI permet de conserver un niveau d’information variable dans un fichier, en ajoutant le commutateur “/L” suivi d’une option* et du fichier journal, comme par exemple :
msiexec /i "C:\Applis\MonPackage\Exemple.msi" /L*V "C:\log\exemple.log"
Les options du commutateur de journalisation MSI sont très fournies :
Le commutateur “/L” est à minima toujours requis afin de stipuler le chemin d’accès et le nom du fichier journal.
| Option | Signification |
| i | Enregistre les messages d’état / d’information |
| w | Enregistre les messages d’avertissements non bloquants / récupérables |
| e | Enregistre tous les messages d’erreur |
| a | Enregistre le démarrage des actions |
| r | Enregistre les informations spécifiques aux actions. |
| u | Enregistre les demandes des utilisateurs. |
| c | Enregistre les paramètres initiaux de l’interface graphique d’utilisateur. |
| m | Enregistre les dépassements de mémoire insuffisante, et erreurs fatales |
| o | Enregistre les dépassements d’espace disque |
| p | Enregistre les propriétés du terminal. |
| v | Enregistre les données détaillées (Verbose mode) |
| x | Enregistre des informations de débogage supplémentaires |
En complément de ces options, il est possible de stipuler un pondérateur
| Pondérateur | Signification |
| + | Ajoute au fichier journal existant. (Append mode) |
| ! | Force l’écriture de chaque ligne dans le fichier journal (En cas de plantage) |
| * | Enregistre toutes les informations (Requis pour les options “v” et “x”) |
Retrouvez toutes les options de ligne de commande “msiexec” sur https://msdn.microsoft.com/fr-fr/library/cc759262(v=ws.10).aspx
Pour les autres processus d’installation, reportez-vous aux informations de l’éditeur.
2. Journalisation personnalisée via le script
En complément de ce que propose le programme d’installation, vous pouvez consigner vos propres informations, en ayant recours à différentes techniques telles que :
-
L’usage des redirecteurs de sortie (vers un fichier)
Pour cela, en mode batch (mais aussi Powershell), il suffit d’utiliser les redirecteurs “>” ou “>>” suivis du chemin et nom du fichier journal souhaité, comme par exemple
MaCommande.exe > c:\Logs\Exemple.txt
Cette directive peut être renseignée au niveau de chaque ligne de script pour laquelle vous souhaitez conserver le résultat (ou lors de l’appel du script lui-même)
Vous pouvez également ajouter la directive ” 2>&1 ” après le nom du journal afin de récupérer le canal d’erreur (2) en plus du flux de sortie standard (1).
En powershell, il est possible d’enregistrer les messages de console en stipulant simplement, en début puis en fin de script, les directives suivantes :
Start-Transcript -Path "c:\Logs\Journal.log" [-Append] ... Stop-Transcript
Je publierais prochainement une information sur certaines limitations ou contrainte de cette pratique.
Si vous débutez en matière de gestion des erreurs en Powershell, vous pouvez vous reporter à cet article http://www.it-connect.fr/powershell-pour-les-debutants-4eme-partie/
Dans la mesure du possible, essayez de ne pas mixer les langages de script afin de garantir l’homogénéité des canaux de sortie et d’erreur. En effet, l’usage de plusieurs interpréteurs imbriqués engendre des contextes différents et vous risquez de perdre certaines informations utiles aux dépannages.
En vbscript, (et de manière plus générale) le plus élégant consiste à écrire une fonction dédiée à la gestion d’un journal.
Function WriteLog(sLogFile,sMessage)
dStamp = Now()
Set oFso = CreateObject("Scripting.FileSystemObject")
sFolder = oFSO.GetParentFolderName(sLogFile)
If Not oFso.FolderExists(sFolder) Then oFso.CreateFolder(sFolder)
Const ForAppending = 8
Set oLog = oFso.OpenTextFile(sLogFile, ForAppending, True)
oLog.WriteLine(cstr(dStamp) + " -" + vbTab + sMessage)
oLog.Close
Set oLog = Nothing
Set oFso = Nothing
End Function
' Appel de la fonction
Call WriteLog("C:\Logs\Journal.log","Message de test")
Vous pourrez remarquer l’ajout de la date et heure de chaque enregistrement qui constitue un point important en matière de journaux d’installation.
Mais il s’agit là d’un simple exemple, qu’il conviendrait de compléter en ajoutant d’autres capacités telles que la criticité du message, l’origine ou d’autres informations susceptibles d’aider les diagnostics.
-
Utilisation des journaux d’événements Windows
Le recours aux journaux d’événements Windows, est également une bonne pratique, que ce soit le journal d’application ou un journal dédié. Il est possible de créer votre propre journal dédié, mais cette pratique est généralement retenue pour consigner l’activité des programmes installés plutôt que leur processus d’installation.
En mode batch, vous pouvez recourir à l’outil “eventcreate” comme par exemple :
Eventcreate /T Error /ID 100 /L Application /D "Mon message de test." /SO MonScript
En vbscript, on peut utiliser 2 techniques :
- Soit l’usage de la méthode “.LogEvent” fournie par un objet “Shell” mais cette technique sera limitée au journal “Application” et la source mentionnée sera “WSH”
Const tERROR = 1
Const tWARNING = 2
Const tINFORMATION = 4
Const tAUDIT_SUCCESS = 8
Const tAUDIT_FAILURE = 16
Set oShell = CreateObject("Wscript.Shell")
oShell.LogEvent tSUCCESS, "Mon message de test via oShell.LogEvent"
- Soit recourir à l’outil précédemment cité qui vous offrira plus de possibilités
Set WshShell = WScript.CreateObject("WScript.Shell")
strCommand = "eventcreate /T Error /ID 100 /L Scripts /D " & _
Chr(34) & " Mon message de test." & Chr(34)
WshShell.Run strcommand
Enfin, en powershell, le choix est vaste …
- Soit via une fonction chargée d’alimenter un fichier à l’instar de l’exemple vbs précédent.
Function WriteLog {
Param ($LogFile, $Message)
$TimeStamp = $([DateTime]::Now)
If (!(Test-Path -Path $LogFile)) { New-Item -Path $LogFile -ItemType File -Force }
Add-Content -Path $LogFile -Value "$TimeStamp -`t $Message"
}
WriteLog -LogFile "C:\Logs\Journal.log" -Message "Message de test"
Là encore, il s’agit d’un modèle de base qu’il convient d’améliorer en fonction de vos attentes et les exemples ne manquent pas sur le Net.
- Si vous optez pour l’écriture dans les journaux d’événements Windows, il vous suffira d’utiliser l’applet de commande
Write-EventLog -LogName Application -Source MonScript -EntryType Information -Message "Message de test" -EventId 100
Et le tour est joué…