Désinstallation et scripts de pré-desinstallation

mardi 27 janvier 2009
par  f
popularité : 27%

La version 1.6IBE+ propose une désinstallation plus optimale des logiciels que dans les versions antérieures de JeDDLaJ. Vous avez la possibilité de ne pas l’utiliser. Mais après avoir comparé les deux méthodes décrites dans ce document, vous vous empresserez de l’adopter et vous lancerez sans doute dans l’écriture de scripts de pré-désinstallation.

Loi de JeDDLaJ : un logiciel sera désinstallé au prochain démarrage d’une machine si dans la configuration logicielle il est "coché vert" dans l’"état actuel" et "coché rouge" dans l’"état voulu".

Remarque : le menu "Désinstallation d’un logiciel" de la zone HWC ne produisant aucune action physique sur les machines (lire La zone HWC) est ici hors sujet.

La désinstallation des logiciels avant la version 1.6IBE+

Il n’y avait en fait pas de désinstallation des logiciels : il s’agissait d’une réinstallation de la distribution et des logiciels que l’on ne souhaitait pas supprimer.

Cette opération peut être réalisée de façon relativement rapide par l’intermédiaire d’une image virtuelle : au lieu de faire directement la réinstallation sur le disque, on crée en mémoire un descriptif du système de fichiers de l’image de base (distribution) sur lequel on greffe les descriptifs des systèmes de fichiers des packages (logiciels). Ensuite on synchronise le système de fichiers obtenu en mémoire avec celui du disque physique de façon à ce que soient présents sur le disque tous, et seulement tous, les fichiers décrits dans l’image virtuelle et tels qu’ils y sont décrits .

Le hic de cette méthode est que l’on ne peut pas ajouter (greffer) autant de descriptifs de systèmes de fichiers des packages que l’on veut au descriptif du système de fichiers de l’image de base. Chaque ajout nécessite une ouverture de fichiers (en fait deux) et on arrive assez rapidement à l’erreur "Too many open files". Cette limitation est clairement identifiée sous Rembo 2 et n’autorise qu’une image virtuelle composée de 11 logiciels. Sous Rembo 4 et 5 elle semble autorisée autour de 25 logiciels. Lorsqu’on atteint ces limites et que l’on ne peut alors pas utiliser cette méthode, on réinstalle l’un après l’autre les logiciels sur le disque en ayant au préalable reformaté la partition et installé la distribution.

Dans les 2 cas, les scripts de post-installation sont ré-exécutés en agissant directement sur le disque, et pour Windows, les images incrémentales des registres sont également ré-appliquées directement sur le disque.

La désinstallation des logiciels avec la version 1.6IBE+

L’algorithme

L’idée de base est simple : on supprime tout répertoire, fichier et clef de registre qui appartient seulement au logiciel à supprimer.

L’algorithme est donc le suivant :
- on ouvre le descriptif du système de fichiers du package à désinstaller ;
- pour chaque répertoire, fichier et clef de registre qu’il contient :

  • s’il est contenu dans le descriptif du système de fichiers de l’image de base ou de l’un des packages restants : on le conserve ;
  • sinon on le supprime.

Une barre de progression avance au fur et à mesure de la suppression des fichiers. Elle ne donne qu’une indication d’activité du processus, mais pas un réel état de l’avancement : elle peut arriver en bout de course et repartir du début.

La désinstallation d’un logiciel est relativement rapide car :

  1. l’algorithme est un peu plus optimisé que cela ;-) (notamment par une ouverture non systématique des descriptifs des systèmes de fichiers) ;
  2. TOUT EST CONTENU EN LOCAL DANS LE CACHE

Rappelons en effet que l’un des intérêts de Rembo est l’utilisation d’une portion du disque, appelée cache, pour stocker les images et les packages téléchargés (sous forme compressée) avant leurs copies dans l’espace partitionné. Ainsi les multiples ouvertures de fichiers se font depuis le disque et jamais depuis le serveur. Ajoutons que dans le fonctionnement normal de JeDDLaJ, le cache contient au moins tout ce qui est installé sur le disque, car la demande d’effacement du cache n’est possible que depuis l’interface de dépannage où l’action est obligatoirement suivi d’une réinstallation (qui induit un ré-approvisionnement du cache).

Les subtilités de l’url "cache ://" ou pourquoi JeDDLaJ est atteint de rebootades aigües sous Rembo 2

Tout est stocké dans le cache mais comment y accéder ? Ou plutôt comment y accéder sans faire un appel au serveur Rembo ?

Sous Rembo 4 et 5, la solution est simple : le cache disque est accessible par l’url "disk ://0-1/rembo" (sous JeDDLaJ le cache est toujours sur le premier disque) où l’on retrouve les fichiers téléchargés sous la même structure arborescence que celle du serveur : global/hdimages, global/incrementals, etc... Par contre, sous Rembo 2, le cache du disque ne contient que des répertoires partagés qui ne rendent pas accessible un fichier par un simple nom. Il faut utiliser l’url "cache ://"

Quand on ouvre un fichier avec l’url "cache ://mon_fichier", un accès est d’abord fait au serveur pour comparer le mon_fichier qu’il possède avec celui présent dans le cache de la machine : s’ils diffèrent, alors le mon_fichier du serveur est au préalable téléchargé dans le cache avant d’être ouvert sur la machine. Un explorateur de fichiers ouvert à l’url "cache ://" nous montre le système de fichiers du serveur.

Si l’on utilisait donc l’url "cache ://" dans notre algorithme de désinstallation, il y aurait une multitudes d’accès au serveur, qui dans le cas d’une exécution massive sur un grand nombre de machines, conduirait vite à une congestion de ce dernier. De plus, les fichiers à supprimer sont ceux contenus dans le package présent localement en cache et non ceux d’une possible nouvelle version qui se trouverait sur le serveur.

Mais en fait, l’url "cache ://" est contextuelle : ce qui est dit plus haut est vrai si la machine a démarré Rembo depuis le réseau. Si elle a démarré Rembo depuis un cdrom, alors il faut remplacer serveur par cdrom, et si la machine démarre depuis son disque dur (mode offline), en fait depuis son cache, alors l’url "cache ://" nous montre le cache du disque et tous les fichiers deviennent accessibles nominativement.

Moralité, pour réaliser une désinstallation sous Rembo 2, la machine doit passer en mode offline. D’où les multiples redémarrage pour retirer des logiciels :

  1. démarrage de la machine sur le réseau ;
  2. exécution des scripts de pré-désinstallation ;
  3. redémarrage en mode offline ;
  4. désinstallation des logiciels ;
  5. nouveau démarrage sur le réseau ;
  6. fin du traitement JeDDLaJ (ajout de logiciels, etc...)

Remarque : En cas d’erreur, la machine redémarre connectée au réseau pour envoyer le message d’erreur, puis passe en état dépannage.

Heureux possesseurs de Rembo 2, vous avez compris pourquoi votre machine reboote plusieurs fois lorsque vous retirez un logiciel ? oui ? Par contre vous vous demandez ce qu’est un script de pré-désinstallation.

Les scripts de pré-désinstallation

Les scripts de pré-désinstallation sont à la désinstallation de logiciels ce que les scripts de post-installation sont à l’installation de logiciels.

L’algorithme décrit plus haut supprime les répertoires, fichiers, et clefs de registre contenus dans le package mais ne défait pas les actions faites par le script de post-installation associé à son logiciel. Afin de réaliser les actions inverses, il est nécessaire de les inscrire dans un script exécuté avant la désinstallation.

Exemple : pour le logiciel JDK 1.6 sous Linux, vous avez écrit le script de post-installation qui ajoute la variable JAVA_HOME dans /etc/environnement :

Vous écrirez alors le script de pré-désinstallation qui retire cette même variable de ce même fichier :

Les scripts de pré-désinstallation sont incontournables dans le cas des logiciels possédant un mode d’installation unattended.
Ils s’écrivent de la même façon que des scripts de post-installation.

Conclusion : faites votre choix

À moins de retirer un très grand nombre de logiciels, la "vraie" désinstallation est plus rapide (quelque soit la version de Rembo) qu’une synchronisation ou qu’une réinstallation. Même si les conditions permettent une synchronisation, il ne faut pas négliger le temps mis par la phase de finalisation (paramétrage du système, déroulement de sysprep, application des scripts de post-installation,...) qui est le même que dans le cas d’une réinstallation.

Si vous optez pour l’algorithme de vraie désinstallation, positionnez la variable RealDeinstallation à true dans le fichier preferences.rbc (sachant que si vous voulez forcer une synchronisation, il vous suffit de la déclencher via l’interface JeDDLaJ). Si vous trouvez que "c’était mieux avant", positionnez la valeur à false (mais vous n’aurez pas la possibilité de l’utiliser de façon ponctuelle via un menu de JeDDLaJ).

Question subsidiaire : pourquoi pas des décrémentaux pour la désinstallation ?

Pour créer un package (ici de façon raccourcie, mais en détails dans Les packages : création/insertion) :

  1. on fait une photo du système sans le logiciel ;
  2. on installe le logiciel sur le système ;
  3. on fait une nouvelle photo du système ;

Le package, dit incrémental, est l’ensemble des modifications du système déduit par comparaison de la première et de la deuxième photo.

Le package, que l’on pourrait dire décrémental, serait l’ensemble des modifications du système déduit par comparaison de la deuxième et la première photo (on inverse l’état du système au départ et à l’arrivée).

Techniquement ça marche, on peut réaliser un package décremental. Le problème survient quand on l’applique : s’il contient un répertoire, fichier ou clef de registre commun à d’autres packages, ce répertoire, fichier ou clef sera retiré de façon inconditionnelle.

Exemple : imaginons que nous ayons plusieurs logiciels provenant de l’éditeur Adobe. Les fichiers des logiciels sont en partie stockés sous Program Files\Abode. Il suffit de retirer un des logiciels pour que ce répertoire disparaisse et avec lui, tous les fichiers des autres logiciels de cet éditeur.

Cependant, à titre d’information, un décremental des fichiers .inf est construit à la volée lors du processus de désinstallation. Ceci est dû au fait que les fichiers .inf sont traités au niveau de leur contenu dans les créations des incrémentaux (contrairement à tous les autres fichiers).


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