Table des Matières
Article encore en chantier !
1 Pourquoi cet article ?
Nous sommes passés à OPSI il y a 2 ans après 3 années de WPKG … et dans WPKG, il y a un système puissant de vérification des installations.
Or OPSI permet de passer quelques lignes de codes (puissant) mais n’a pas un système de vérification des installations aussi abouti que WPKG …
La bonne efficacité des paquets produits dépend donc beaucoup de la façon dont ils sont écrits.
Un lien indispensable : http://download.uib.de/opsi_stable/doc/html/en/opsi-winst-manual/opsi-winst-manual.html
Voici quelques idées / recettes sur le sujet
2 Templates Opsi
Il me semble nécessaire de partir d’un template si l’on veut être efficace.
Les templates fournis par Opsi sont biens, mais il manque à mon avis quelques éléments.
Dans les templates Opsi, on trouve systématiquement les 3 fichiers suivants :
- setup.ins
- uninstall.ins
- delsub.ins
Cette architecture me semble une très bonne idée, et je pense qu’il faut la conserver (elle est très inspirée de WPKG d’ailleurs).
Dans les fichiers setup.ins et uninstall.ins, on introduit des variables qui seront utilisées dans le sous-programme appelé delsub.ins, qui est dédié à la désinstallation.
Le setup appelle donc d’abord la désinstallation. Ceci est une très bonne pratique, on évite beaucoup d’erreurs ainsi. Le paquet peut repasser 2 fois, ce n’est pas grave. Il faut d’ailleurs quand on teste un paquet toujours veiller à l’installer 2 fois de suite pour voir s’il n’est pas bloquant au deuxième passage.
3 Que manque-t-il par défaut ?
3.1 Vérification de l’espace disponible
Le template opsi arrive avec une vérification de l’espace disque disponible… même si on peut penser que ce n’est pas fondamental pour la plupart des logiciels… Pourquoi ne pas la laisser
Set $MinimumSpace$ = "10 MB" if not(HasMinimumSpace ("%SystemDrive%", $MinimumSpace$)) LogError "Not enough space on %SystemDrive%, " + $MinimumSpace$ + " on drive %SystemDrive% needed for " + $ProductId$ isFatalError ; Stop process and set installation status to failed else ; on continue l'installation
3.2 Architecture 64bits ?
Un certain nombre de logiciels arrivent maintenant avec une version 64bits. Il me semble que pour ces logiciels, il faudrait prendre en compte l’architecture dans le paquet.
En exemple, l’installation de 7zip à partir des msi
Set $INST_SystemType$ = GetSystemType set $INST_architecture$ = GetProductProperty("install_architecture","system specific") if (($INST_SystemType$ = "x86 System") and ($INST_architecture$ = "system specific")) or ($INST_architecture$ = "both") or ($INST_architecture$ = "32 only") Message "Installing " + $ProductId$ + " 32 Bit..." comment "Start setup program" Winbatch_install_32 Sub_check_exitcode set $InstallDir$ = $InstallDir32$ comment "Create shortcuts" LinkFolder_install endif if ($INST_SystemType$ = "64 Bit System") and (($INST_architecture$ = "system specific") or ($INST_architecture$ = "both") or ($INST_architecture$ = "64 only")) Message "Installing " + $ProductId$ + " 64 Bit..." comment "Start setup program" Winbatch_install_64 Sub_check_exitcode set $InstallDir$ = $InstallDir64$ comment "Create shortcuts" LinkFolder_install endif
3.3 Une ultime vérification
La dernière série d’instructions dans la section Actions du paquet doit être à mon avis la vérification que l’installation s’est effectivement bien passée.
Pour cela, on peut soit vérifier que le logiciel est inscrit dans la BDR, soit vérifier la présence et/ou la version des fichiers installés.
3.3.1 Vérification sur l’entrée dans la BDR
Voici un extrait de code Winst permettant de vérifier la présence d’une entrée Audacity dans le menu Ajout/Suppression de programmes
comment "Test for installation success" ; Test if software marked as installed in registry if NOT (GetRegistryStringValue("[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Audacity 1.3 Beta (Unicode)_is1] DisplayName") = "Audacity 1.3.13 (Unicode)") logError "Fatal: After Installation La clef de base de regsitre n'est pas la bonne" isFatalError else comment "Successful Installation" endif
3.3.2 Vérification sur la version de fichier installé
Voici un extrait de code Winst permettant de vérifier la présence et la version d’un fichier, en l’occurence on vérifie la présence d’un fichier .dll permettant aux navigateurs d’utiliser Flashplayer
Defvar $InstalledFileFF$ set $InstalledFileFF$ = "%system%\Macromed\Flash\NPSWF32.dll" if not (FileExists($InstalledFileFF$)) logError "Fatal: DLL non présente" isFatalerror else if NOT (getValue("file version with dots", getFileInfoMap($InstalledFileFF$))="11.1.102.55") logError "Fatal: mauvaise version de la DLL" isFatalerror else comment "Vérification de Flashplayer pour FF : OK" endif endif
4 Des bouts de code intéressants ?
4.1 Inscriptions de clefs de base de registre
Winst permet d’écrire dans la base de registre de façon très simple, et notamment en se contentant presque d’un copier-coller depuis un export .reg.
En voici un exemple
[Registry_Taches_Quotidiennes] ;On peut insérer directement les lignes regedit si l'appel est fait avec l'option /regedit openkey [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config] set "MaxNegPhaseCorrection"=REG_DWORD:0xffffffff set "MaxPosPhaseCorrection"=REG_DWORD:0xffffffff set "AnnounceFlags"=REG_DWORD:0x00000005 openkey [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters] set "NtpServer"="ntp,0x1" set "Type"="NTP" openkey [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient] set "SpecialPollInterval"=REG_DWORD:0x00002a30 openkey [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer] set "Enabled"= REG_DWORD:0x00000001
Une remarque en passant, pour passer du .reg au fichier .ins, il suffit d’ajouter set ou openkey en début de ligne.
Cependant, il faut penser à remplacer DWORD par REG_DWORD par exemple.
Une autre solution pour fainéant, mais pas testée encore… Utiliser un export de regedit et lancer
registry loadUnicodeTextFile("%scriptpath%/MonExportDepuisRegedit.reg") /regedit
4.2 Lancement de code batch
On peut lancer facilement du batch par Winst. Il suffit d’appeler la section par DosBatch_mon_bout_de_batch ou DosInAnIcon_mon_bout_de_batch
Dans la section principale, on appelle
[Actions] DosBatch_mon_bout_de_batch
Et dans la section secondaire
[DosBatch_mon_bout_de_batch] REM Ceci est du batch echo "Bonjour !" pause
Une remarque ! Apparemment, ceci est exécuté avec le compte System, depuis le chemin C:WindowsSystem32…
4.3 Lancement de code AutoIt
Autoit3 est un outil de script très puissant. En outre, il y a des forums super actifs.
Pour lancer de l’Autoit, vous prenez votre code et vous le mettez dans une section ExecWith_mon_bout_de_code_AutoIt
Dans la section principale, on appelle
[Actions] ExecWith_mon_bout_de_code_AutoIt autoit3.exe
Et dans la section secondaire
[ExecWith_mon_bout_de_code_AutoIt] ; Ceci est de l'autoit MsgBox(0,"hello Word!","Cliquer pour continuer ou attendre 10s",10)
AutoIt est très puissant dans l’interaction avec les fenêtres. Il me semble d’ailleurs que c’était sa raison d’être au départ. Du coup, il peut permettre d’installer des applications donc l’installation n’est pas nativement silencieuse.
Une remarque : Il faut que l’exécutable autoit3.exe soit accessible par Windows. Il y a plusieurs possibilités pour le faire.
- Installer AutoIt et mettre le chemin d’accès à autoit3.exe dans le %PATH% du système. C’est ce que je fais.
- Fournir l’exécutable autoit3.exe dans le paquet et l’appeler par ExecWith_mon_bout_de_code_AutoIt $scripath$autoit3.exe.
- Donner le chemin complet de l’exécutable si AutoIt est installé. Pas testé.
Un bug ! Actuellement (décembre 2012) l’appel avec l’option /letThemGo (qui permet normalement de lancer une tâche dans un nouveau processus) ne fonctionne pas.
Howdy! This blog post couldn’t be written much better!
Going through this post reminds me of my previous roommate!
He constantly kept talking about this. I most certainly
will forward this post to him. Pretty sure he’ll have a good read.
Thanks for sharing!