Les scripts de post-installation (updaté pour la version 1.6IBE+)

vendredi 5 mai 2006
par  f
popularité : 25%

Les scripts de post-installation sont vos amis. Il vous permettront de finaliser le déploiement de vos images de base et vos packages. Vous trouverez ici des exemples d’utilisation de scripts de post-installation.

Un script de post-installation, qu’est-ce que c’est ?

C’est tout d’abord un script écrit en Rembo-C. Il est donc indispensable de se référer à la documentation Rembo pour entreprendre l’écriture d’un tel script. Il peut-être utilisé sous sa forme source (.rbc) ou sous sa forme compilé (.rbx) grâce à l’utilitaire Rembo rbcc.

Un script de post-installation est associé à une distribution ou à un logiciel et est exécuté après son déploiement. Le but d’un script de post-installation est multiple :
- modifier les fichiers de configurations ou bases de registres contenus dans les images de base ou packages après leurs déploiements afin de les rendre moins architecture-dépendants,
- mettre à jour des fichiers inclus dans images de base et package (comme des fichiers de licence par exemple),
- corriger des erreurs faites à la création de l’image de base ou du package,
- pallier en partie à la non gestion de dépendances,

... et bien d’autres choses encore.

Ajouter un script de post-installation dans la base

Pour écrire le script :

- vous pouvez utiliser votre éditeur de texte préféré. Une fois votre script écrit, vous le compilez si vous le souhaitez ( un avantage de ceci est la détection des erreurs de syntaxe lors de la compilation ), et vous devez le déposer sur le serveur Rembo. Pour cela, vous pouvez utilisez l’interface JeDDLaJ si le serveur http possède les prérequis permettant la connexion au serveur Rembo, indiqués ici, comme suit :

  • cliquez sur le menu "Connexion au serveur Rembo",
  • rendez vous dans le répertoire de dépots des scripts de post-installation en cliquant sur les liens entre chevrons représentants les répertoires du serveur,
  • cliquez sur le bouton "Déposer un fichier"
  • recherchez le fichier sur votre machine en cliquant sur le bouton "Parcourir" ou "Browse" suivant le navigateur,
  • cliquez enfin sur le bouton "Déposer".

- si le serveur http possède les prérequis permettant la connexion au serveur Rembo, indiqués ici, vous pouvez utiliser l’éditeur en ligne de JeDDLaJ :

  • cliquez sur le menu "Connexion au serveur Rembo",
  • rendez vous dans le répertoire de dépots des scripts de post-installation en cliquant sur les liens entre chevrons représentants les répertoires du serveur,
  • cliquez sur le bouton "Nouveau fichier",
  • écrivez votre script dans la zone de texte,
  • cliquez sur le bouton "Enregistrer sous"
  • entrez le nom du script ( avec de préférence l’extension .rbc afin qu’il soit éditable par la suite. L’extension choisie n’a par contre pas d’incidence sur l’exécution du script ),
  • cliquez sur le bouton "Enregistrer" suivant le nom du script,
  • cliquez sur le bouton "Fermer".

Il vous faudra ensuite associer le script à un logiciel ou une distribution. Pour cela :
- cliquez sur le menu "Ajouter postinstall_script",
- indiquez le nom complet ( avec l’extension ) du script,
- compléter le chemin vers le script, si il est dans un répertoire se trouvant sous l’arborescence des dépots,
- indiquez si le script est applicable à un groupe d’ordinateurs, ou à un seul oridnateur,
- enfin, cochez le ou les logiciels ou les distributions concernés pas l’exécution du script de post-installation.

Utiliser les variables et fonctions définies dans JeDDLaJ

Les scritps de post-installation sont appelés depuis le script de déploiement de JeDDLaJ. Celui contient des variables globales et des fonctions que vous pouvez (devez) utiliser dans vos scripts.

Les variables

- HostName : nom DNS de la machine récupéré par le DHCP
- DomainName : nom de domaine
- nom_dns : nom FQDN de ma machine ( clef primaire dans la base de données JeDDLaJ )
- nom_netbios : nom netbios.
- sid : sid Windows.
- num_disque : numéro du disque durant le traitement d’une image de base.
- num_partition : numéro de la partition durant le traitement d’une image de base.
- nom_os : nom du système d’exploitation en cours de traitement.
- id_os : id du système d’exploitation en cours de traitement.
- id_logiciel : id du logiciel en cours de traitement.
- disk : device rembo sur lequel se trouve le système d’exploitation en cours de traitement.
- hres : résolution horizontale en pixels.
- vres : résolution verticale en pixels.
- vfreq : fréquence verticale en Hz.
- hfreq :fréquence horizontale en kHz.
- bpp : nombre de bits par pixel.
- modeline : modeline pour fichier de configuration X-Windows.
- ram : quantité de ram en Mo.
- signature : signature matérielle.
- id_idb : id de l’image de base en cours de traitement.
- nom_idb : nom de l’image de base en cours de traitement.
- nom_distribution : nom de la distribution en cours de traitement.
- version_distribution : version de la distribution en cours de traitement.
- rembo_version : version de Rembo.

Les fonctions

- AfficheInfo(str info) : affiche le message dans une fenêtre et dans le Log,

  • prend en argument une chaîne assimilée à un message d’information,
  • ne renvoie rien.

- MySQLQuery(str myquery) : ouvre et ferme une connexion TCP vers le serveur Rembo,

  • prend en argument une requête MyQSL,
  • renvoie une tableau à double entrée contenant le resultat de la requête.

- RealPath(str filepath) : détermine le chemin Rembo complet vers un fichier ou un répertoire, c’est à dire un chemin préfixé du device Rembo ("disk ://x:y") où se trouve le fichier ou le répertoire

  • prend en argument un chemin depuis la racine vers un fichier ou un répertoire,
  • renvoie une chaîne de caractères correspondant au chemin passé en argument préfixé du device Rembo le contenant :
    • sous Windows renvoie le chemin préficé de la variable disk,
    • sous Linux renvoie le résultat de la fonction LinuxDiskPath(str filepath).

- MyPatchFile(str filepath,str pattern,str patch,bool inc) : permet d’insérer une chaîne dans un fichier à une position repérée par une autre chaîne,

  • prend en arguments :
    • prend en argument le chemin Rembo complet vers le fichier où l’on doit insérer la chaîne ou, pour compatibilité ascendante, le chemin vers ce même fichier,
    • la chaîne repérant l’endroit où l’on doit écrire la nouvelle chaîne,
    • la nouvelle chaîne à écrire,
    • un booléen qui indique si on laisse la chaîne repère (pour réappliquer à nouveau la fonction) ou si on la remplace,
  • ne renvoie rien.
  • affiche au cours du traitement les occurrences trouvées de la chaîne repère.

- AddToEnd(str path,str text) : ajoute une chaîne à la fin d’un fichier

  • prend en arguments :
    • le chemin Rembo complet vers le fichier où l’on doit insérer la chaîne,
    • la chaîne à insérer,
  • ne renvoie rien.

- RemoveLine(str filepath,str pattern) : retire d’un fichier les lignes contenant un motif donné,

  • prend en arguments :
    • le chemin Rembo complet vers un fichier,
    • un motif (le caractère * permet de désigner n’importe quelle suite de caractères),
  • ne renvoie rien.

- IsLineInFile(str filepath,str pattern) : indique si un motif se trouve dans un fichier,

  • prend en arguments :
    • le chemin Rembo complet vers un fichier,
    • un motif (le caractère * permet de désigner n’importe quelle suite de caractères),
  • renvoie vrai si le motif a été trouvé, faux sinon.

- RemoveFileIE(str filepath) : détruit un fichier seulement si celui-ci existe :

  • prend en argument le chemin Rembo complet du fichier à détruire,
  • ne renvoie rien.

- MkDirINE(str filepath) : crée un répertoire seulement si celui n’existe pas déjà :

  • prend en argument le chemin Rembo complet du répertoire à créer,
  • ne renvoie rien.

- DelTreeIE(str filepath) : détruit une arborescence seulement si celle-ci existe :

  • prend en argument le chemin Rembo complet de l’arborescence à détruire,
  • ne renvoie rien.

Variables et fonctions spécifiques pour Linux

- nparts : nombre de partitions linux.
- result1 : partitions système Linux.
- result1[][0] : numero disque.
- result1[][1] : numero partition.
- result1[][2] : nom partition.
- result1[][3] : type_partition.
- result1[][4] : linux device.

- WhichLinuxPart(str filepath) : permet de trouver la partition où est installé un fichier,

  • prend en argument un chemin vers un dossier ou un fichier de l’arborescence Linux,
  • renvoie l’indice i de result1[i][] correspondant à la partition où se trouve ledit dossier ou fichier.

- LinuxDiskPath(str filepath) : détermine le chemin Rembo complet vers la partition contenant un fichier ou un répertoire d’un système Linux :

  • prend en argument un chemin depuis la racine vers un fichier ou un répertoire,
  • renvoie une chaîne de caractères correspondant au chemin passé en argument préfixé du device Rembo correspondant à la partition qui le contient.

Variables et fonctions spécifiques pour Windows

- nt : booléen à vrai s’il s’agit d’un système de type NT.
- NTSystemRoot : répertoire d’installation du système NT (windows ou winnt)
- affiliation_windows : workgroup ou domain.
- nom_affiliation : nom du domaine ou groupe de travail à joindre.

- MSWindowsRunOnce(str cmd) : permet d’exécuter une commande Windows par un mécanisme de run once (plus de détails sur cette fonction dans l’article Workgroups, Domaines et MSWindowsRunOnce),

  • prend en argument la commande à exécuter sous Windows,
  • ne renvoie rien.

- RegisterCriticalMassStorage(str id_composant,str driver,str path) : permet d’enregistrer un pilote de stockage de masse critique dans la base de registre (plus de détails sur cette fonction dans l’article Windows, Sysprep, DriversPacks, Image Universelle et JeDDLaJ),

  • prend en argument :
    • l’id du composant sous forme nnnn:nnnn,
    • le nom du pilote sans son extension .sys,
    • le chemin vers le répertoire qui contient ce pilote,
  • ne renvoie rien.

- IsSysprepPrepared() :

Plein de beaux exemples

Pour illustrer l’utilisation des variables et fonctions énumérées ci-dessus et de quelques fonctions Rembo, voici quelques exemples de scripts de post-installation.

Script de post-installation pour l’installation d’une distribution Linux Debian

Nous reprenons ici notre idée d’une image de base Linux déployable sur toute machine à base de noyau modulaire, et dont le schéma de partitionnement est indépendant de celui utilisé pour faire l’image de base. Le script de post-installation va permettre de modifier les fichiers de configurations du système afin que le système soit fonctionnel pour la machine cible. Nous utiliserons ici la base de connaissances de JeDDLaJ pour ce qui est des modules plutôt qu’un logiciel d’autodétection du genre discover.

- Copie du noyau à la racine du système : comme nous l’avons dit ici, il est indispensable que le noyau se trouve à la racine du système pour que le loader de JeDDLaJ fonctionne. Si vous avez omis cette copie dans votre image de base, rien n’est perdu, vous pouvez le faire au moment de l’éxécution du script avec la fonction Rembo CopyFile. Vous pourrez également utiliser cette façon de faire pour le déploiement d’un noyau packagé.

- Construction de la fstab : il est nécessaire d’inscrire dans le fichier /etc/fstab tous les points de montage déclarés dans la base. Pour cela, on construit une chaîne de caractères à l’aide des informations de la base avec la commande MySQLQuery, et on sauve cette chaîne dans /etc/fstab avec la commande Rembo CreateTextFile (on écrase celui existant dans l’image de base). Pour :

  1. les partitions systèmes : on parcourt le tableau result1,
  2. les partitions non système : n’étant pas utilisées lors du déploiement de l’image de base, on doit faire une nouvelle requête dans la table partitions,
  3. les partitions de swap : n’étant pas utilisées lors du déploiement de l’image de base, on doit faire une nouvelle requête dans la table partitions,
  4. les périphériques : il faut faire une requête dans la table stockages_de_masse et créer les points de montage dans le système de fichiers. Pour plus de souplesse on crée des liens symboliques avec les noms des périphériques vers les noms de devices linux.

- Ajout des modules liés aux composants détectés : il s’agit ici d’insérer dans le fichier /etc/modules les noms de modules linux associés aux composants installés sur la machine. Pour cela, on forme une chaîne de caractères construite à partir des informations des tables composants et composant_est_installe_sur et concernant les modules de type "kernel". On écrase le fichier /etc/modules.

- Modification de la configuration X11 : il s’agit pour notre exemple de modifier le fichier /etc/X11/XF86Config-4 avec la commande MyPatchFile en remplaçant l’occurrence du nom de module XFree utilisé dans l’image de base par celui correspondant à la carte vidéo de la machine. Comme précédemment l’information est récupérée dans la base.

- Conversion des partitions ext2 vers ext3 : le type ext3 n’est pas réellement géré par Rembo. Une façon de pallier à cela est d’ajouter un script qui s’éxécutera au lancement du système et qui convertira les systèmes de fichiers ext2 des différentes partitions en ext3. Le script sera détruit à la fin de son éxécution pour que la conversion n’ait lieu qu’au premier démarrage de la machine. On crée donc un script S01tune2fs dans /etc/rcS.d qui convertit les partitions concernées (requête dans la base sur les partitions de type ext3).

- Changement du nom d’hôte : création du fichier /etc/hostname

script de post-installation pour des logiciels s’appuyant sur la signature du disque sous Windows

Certains logiciels verrouillent leur installation en enregistrant un identifiant unique du système : adresse MAC, volume ID... C’est le cas par exemple de Matlab sous Windows qui se base sur le volume ID du disque : le package du logiciel va contenir le volume ID du disque de la machine source. Or ce volume ID est généré de façon aléatoire au formatage du disque, ce qui rend impossible le déploiement...même sur la machine source en cas de réinstallation du système. La solution :
- noter le volume ID du disque sur lequel est fait le package. Pour cela ouvrez une invite de commandes et taper dir. La seconde ligne affichée contient ce volume ID : "Le numéro de série du volume est XXXX-XXXX".
- changer le volume ID du disque où est déployé le package grâce à un script de post-installation avec les commandes DevWriteUUID.html . Il faut également utiliser la commande BinFromHex afin de convertir le volume ID en une variable binaire. Attention : le volume ID doit y être écrit en le lisant de droite à gauche comme une chaîne formée de 4 nombres hexadécimaux. Par exemple 12AB-34CB doit être écrit CD34AB12.

Script de post-installation pour des logiciels nécessitant des mises à jour

Certains logiciels, comme les anti-virus, ont besoin d’être mis à jour quotidiennement. Est-il raisonnable d’inclure l’automatisation de cette mise à jour ( par exemple par tâche planifiée pour Windows, cron pour Linux ) dans le package du logiciel ? Il existe au moins 2 raisons pour répondre non :
- les tâches planifiées sous Windows ne sont pas "imageables" ( et ceci est indépendant du système de déploiement ) à cause de la façon dont est enregistré le mot de passe lié à l’utilisateur de la tâche planifiée.
- le goulot d’étranglement lié à l’accés à la ressource fournissant la mise à jour : toutes les machines où va être déployé le logiciel lanceront leur mise à jour à exactement à la même heure de la journée.

Une solution est que le déclenchement de la mise à jour soit poussé sur les machines où est installé le logiciel, par une machine particulière ( par exemple le serveur Rembo ) à l’aide de commandes comme ssh sous Linux ou pssexec sous Windows.
Le rôle du script de post-installation est ici de créer un fichier texte consultable par la machine qui va déclencher les mises à jour et contenant le nom des machines concernées. Le déclenchement des mises à jour se faisant par lecture séquentielle du fichier, on évite ainsi le goulot d’étranglement.
On utilise id_logiciel dans la reqûete au serveur pour retrouver le logiciel en cours de déploiement. Dans l’exemple ci-dessous on utilise nom_netbios pour l’utilisation, par exemple, de pssexec

Script de post-installation pour pallier à des problèmes de dépendances

Supposons que nous disposions des packages pour le logiciel Mozilla et pour le logiciel VideoLan client incluant les plugins Mozilla pour Windows. Il est nécessaire pour que Mozilla dispose des plugins VLC que ceux-ci se trouvent dans le répertoire plugins de Mozilla à la fin du déploiement.

On écrit un script de post-installation pour le logiciel VLC qui teste que le répertoire d’installation de Mozilla existe, auquel cas on y copie les plugins VLC.

On écrit un script de post-installation pour le logiciel Mozilla qui teste si le répertoire de plugins VLC pour Mozilla est disponible, auquel cas on copie les plugins depuis ce répertoire.

Si les deux logiciels sont installés, et ce dans n’importe quel ordre, Mozilla disposera des plugins VLC.

Script de post-installation pour des packages incluant des modifications de fichiers texte

Il est vivement recommandé de ne pas inclure les modifications faites sur les fichiers textes dans les packages ( sous Linux ces fichiers sont souvent des fichiers de configurations ). Pourquoi ? Imaginons que le logiciel L1 ajoute la ligne ligne1 au fichier fichier.txt contenu dans l’image de base I1 : le package P1 de L1 contiendra le fichier fichier.txt dont la dernière ligne sera ligne1. Imaginons que le logiciel L2 ajoute la ligne ligne2 au fichier fichier.txt contenu dans l’image de base I1 ( I1 ne contient pas le logiciel L1 et donc fichier.txt ne contient pas la ligne ligne1 ) : le package P2 de L2 contiendra le fichier fichier.txt dont la dernière ligne sera ligne2. Si l’on déploie les packages P1 puis P2 sur l’image de base I1, le fichier fichier.txt ne contiendra pas les lignes ligne1 et ligne2 mais seulement ligne2 ( et seulement ligne1 si l’on déploie P2 puis P1).

Donc au moment de la création d’un package, il faudra regarder les fichiers de type texte modifiés, noter les modifications et les effectuer au moment du déploiement par un script de post-installation. Un exemple simple est celui de l’ajout d’une variable d’environnement à la fin du fichier /etc/environment. Par exemple si l’on fait un package de J2SDK 1.5 installé dans /usr/local, en utilisant la fonction AddToEnd :


Brèves

12 février 2009 - JeDDLaJ passe sur SourceSup à partir de la version 1.6IBE+

La communauté JeDDLaJ manquait jusqu’alors cruellement de certains services et moyens de (...)

12 février 2009 - 11/2/2009 : La version 1.6 IBE+ est disponible !!!

Ça y est. Après tant de mois (18 à peu près...) de gestation, d’hésitations, de :wq et autres (...)

12 février 2009 - JeDDLaJ gagne le concours DEVA => nouvelles fonctionnalités pour vous !!!

JOIE !!! BONHEUR !!! FIERTÉ !!!
JeDDLaJ remporte le concours DEVA (DEVeloppements (...)

9 juillet 2007 - Précision importante sur la compatibilité MySQL 5 de JeDDLaJ 1.4IBE

Dans le cas d’un serveur Rembo sous Windows, 2 moyens pour pouvoir utiliser MySQL 5 :
soit (le (...)

9 juillet 2007 - Déjà le SP1 pour JeDDLaJ 1.4IBE : désormais TPMfOSd-ready !!!

Description
Ce service pack n’apporte principalement qu’une amélioration... mais de taille... (...)