AppScript-C. Définir un journal d’installation

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.

_Log

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)

(Batch)
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).

(PShell)
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.

 

(VBscript)
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.

(Batch)
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

(VBscript)
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

 

(PShell)
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é…

 

Retour au sujet principal

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *