Une contribution à la création de paquets logiciels dans OPSI

 

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.

 

Comments

  1. 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!

Laisser un commentaire