Les packages : création/insertion

vendredi 8 octobre 2004
par  G a.k.a Gérard Milhaud
popularité : 1%

Brique fondamentale de JeDDLaJ, une interface de création de packages utilisant la technologie des images incrémentales de Rembo est désormais disponible depuis la version 0.6p (jamais diffusée) de JeDDLaJ.
Le bonus est que nous avons contourné l’obligation de devoir partir, pour faire un incrémental, d’une image telle qu’elle est stockée sur le serveur Rembo, ce qui nécessite de réinstalller la machine pour pouvoir fabriquer des packages.
Avec JeDDLaJ, on peut partir d’une machine quelconque de son parc y ajouter un nouveau soft, en faire un package et l’introduire automatiquement dans la base : la machine — mis à part l’ajout du soft — est dans le même état qu’avant.
En gros les avantages de l’approche Prism dans un contexte pur Rembo sans soft tierce...

ENFIN...

Après de longues périodes de réflexion, beaucoup d’idées, beaucoup d’impasses, nous disposons enfin aujourd’hui, fin Mai 2004, du module logiciel qui manquait le plus à JeDDLaJ : une interface simple de création de packages pouvant fonctionner sur n’importe quelle machine présente dans la base JeDDLaJ. La section suivante décrit son utilisation, tandis que les plus curieux trouveront ici une petite explication des problèmes et des choix qui ont mené à l’élaboration de notre mécanisme de package.

Concrétement, et en photos : les étapes de la création d’ un package

  1. On passe, via l’interface web, la machine sur laquelle on veut créer le package en état création de packages via le menu idoine.
  2. on reboote la machine, qui va alors présenter ce menu
  3. On fait une photo du système en cliquant sur l’icône 1 (si plusieurs OS sont installés sur la machine, un menu demandera sur lequel on souhaite travailler, choix qui restera valide jusqu’au prochain clic sur l’icône 1). On a 4 minutes pour aller , par exemple, voir la météo du week-end.
  4. À l’invite "Voulez-vous booter sur le système ?", accepter afin de booter la machine sous son OS. On installe le logiciel à packager avec toutes les opérations nécessaires (modifications éventuelles de droits sur des fichiers à protéger, création de menus/raccourcis supplémentaires, etc.). On reboote.
  5. De retour dans l’interface de création des packages, on clique sur l’icône 2 pour générer le fichier de log correspondant à l’installation du logiciel
  6. À l’invite "Voulez-vous editer le fichier de Log ?", choisissez "Oui". ET OUI, bonus JeDDLaJique, on va éditer le fichier de log directement sur la machine, sans avoir besoin de se déplacer jusqu’au serveur.Quelques précisions sur l’édition du fichier de log sous l’interface JeDDLaJ :
    • Tout d’abord, convention REMBO, les lignes commencent par un caractères indiquant la nature de l’opération effectué sur le fichier associé à ladite ligne :
      • signe "+" : fichier ajouté
      • signe "-" : fichier supprimé
      • signe "#" : fichier modifié
    • Pour supprimer une ligne, on la sélectionne en rouge par un clic gauche,
    • Pour sélectionner un bloc : clic gauche sur la première ligne, clic droit sur la dernière
    • Pour déselectionner, mêmes manips
    • Nouveauté Juin 2004 : le bouton "Rechercher dans le fichier de log", qui vous permet aussi de sélectionner automatiquement les lignes recherchées (bouton "Sélectionner"). On peut voir ici, pour fixer les idées, un screenshot d’édition de fichier de log.

    ATTENTION CEPENDANT : si le fichier de log est trop gros (packages MS-Office ou Cygwin par exemple), un bug de REMBO fait que l’édition sous l’interface JeDDLaJ ne fonctionnera pas. Arghhh !! Dans ce cas là, il faut répondre "Non" à l’invite d’édition, puis cliquer sur le bouton 6 pour booter la machine sous son OS, et vous éditez avec votre éditeur préféré (donc vim évidemment) le fichier de log que JeDDLaJ sauve toujours pour vous à la racine du système de fichiers, sous le nom DNS complet de la machine sur laquelle on travaille.

  7. La question qui tue, surtout sous Windows : Mais il y a des milliers de lignes, que faut-il enlever/garder ???. Certes c’est un problème, mais l’application des quelques règles suivantes permet de s’en sortir la plupart du temps sans encombres  :
    • Supprimer toutes les lignes correspondant à des fichiers qui n’ont rien à voir avec le paquetage, soit en particulier toutes les lignes concernant les fichiers du profil d l’utilisateur sous lequel on a installé le package.
    • [Windows XP] Supprimer les lignes de ce type dans la partie Système du registre, sous peine de générer des redétections de matériel malséantes lors de l’utilisation du package (on les reconnait au PnPBIOS_XX) :
      • # ControlSet001/Enum/Root/*PNP0401/PnPBIOS_13/LogConf/BasicConfigVector.resreq
      • # ControlSet001/Enum/Root/*PNP0501/PnPBIOS_11/LogConf/BasicConfigVector.resreq
    • [Windows 2000/XP] IMPORTANT : Supprimer toutes les lignes de la section SAM du registre, sinon le package ne fonctionne pas d’une machine sur l’autre (Windows 2000, XP).
  8. On clique sur l’icône 3 pour fermer le fichier de log et, oui, on désire enregistrer les modifications...
  9. On clique sur l’icône 4 pour générer le package (fonction MakeDiff de Rembo-C). Plus il est gros et... plus c’est long. Les fichiers associés à ce package sont alors sauvés dans le répertoire global/snapshots sur le serveur sous les noms nom_dns.{fil,sec,sof,sys,ini,def}.
  10. À l’invite "Voulez-vous inserer le package dans la base ?", répondez "Oui" pour insérer le package dans la base JeDDLaJ.
    • Si le package est déjà existant (cas d’écrasement d’un ancien package), répondre "Non" à l’invite "Est-ce un nouveau package ?", puis le sélectionner dans la liste déroulante [1]. Cliquer enfin sur le bouton "Remplacer le package sur le serveur" pour finaliser l’opération. (Screenshot)
    • En revanche, si le package est nouveau, alors une autre question se pose. Fabrique-t-on un package associé à un nouveau logiciel ou à un logiciel existant ? Et oui, n’oubliez pas que pour un même logiciel on peut avoir plusieurs packages en fonction de l’OS mais aussi de l’éventuelle spécificité du package qui peut par exemple être attaché à une machine qui dispose d’une carte particulière utilisée pour ce logiciel. Cliquez donc sur le radio-bouton correspondant [2]. Dans le cas d’un nouveau logiciel, on renseigne :
      • le nom du logiciel
      • la version du logiciel
      • éventuellement son icône

      Enfin, dans tous les cas, renseigner :

      • le nom du package
      • le répertoire de stockage du package dont le début du chemin est imposé.
      • la spécificité du package

      Cliquer enfin sur le bouton "Insérer les données dans la base" qui va updater la base JeDDLaJ. Si ça vous dit, voici un screenshot résumant ce qui vient d’être dit : cas de l’ajout d’un nouveau package, pour un nouveau logiciel.

  11. Si on veut continuer à faire d’autres packages, on le précise et on reprend en 1. Sinon, la machine repasse automatiquement en état installé et boote.

Un moyen simple de modifier un package déjà créé

Imaginons que vous ayez oublié, dans un package complexe de type cygwin, de modifier les droits sur une clé de registre. Une première solution consiste à refaire complètement le package, puis d’indiquer ensuite que vous remplacez l’ancien. Une deuxième solution serait de créer un postinstall script associé à ce package qui fait les modifs voulues (ce n’est pas toujours possible : par exemple, modifier les droits sur une clé de registre en ligne de commande DOS reste à ce jour impossible pour nous...).

Comme il s’agit d’un problème récurrent, nous avons prévu une solution dans JeDDLaJ. Il suffit de procéder presque comme pour une création de nouveau package (cf. section précédente), avec la variation suivante :

- juste après avoir fait la photo du système (étape 3 de la section précédente), utiliser le bouton "Ajouter un logiciel de la base sur cette machine" pour ajouter le logiciel correspondant au package à modifier (un petit screenshot), puis booter ensuite la machine pour faire la modif manquante. Procédez ensuite comme indiqué dans la section précédente en indiquant que le package que vous créez remplace l’ancien (étape 10 de la section précédente).

Comment sortir de l’interface de création de packages à tout moment

Il peut arriver que vous souhaitiez pour diverses raisons sortir de l’état "Création de packages" sans finir (voire sans commencer...) la création d’un package. Pour cela il suffit de cliquer sur le texte [3] "Sortie de l’état création de packages" en bas à droite : la machine s’arrêtera alors après être passée en état "Installé".

Génèse du mécanisme de création de packages de JeDDLaJ

Nous souhaitions avant tout nous abstraire d’une des limitations du mécanisme de paquetages de REMBO Toolkit : l’obligation de repartir d’une image disque enregistrée sur le serveur pour effectuer la photo du système avant l’installation du soft à packager.

Avec ce système, la façon de faire la plus immédiate est d’injecter une image de base dans une machine, puis de faire le package (par script Rembo-C et ses fonctions TextDiff et MakeDiff, en passant par l’édition du fichier de log créé par TextDiff sur le serveur.

Bilan : à moins de se réserver une machine à cet effet, il faut descendre une image sur une machine, faire le package avec intervention sur le serveur pour l’édition du fichier de log, puis redescendre sur la machine son image complète, avec ses softs. Difficile, sans compter le temps d’installation du soft à packager, de descendre en dessous d’une heure d’intervention...

Nous voulions, au contraire, se retrouver dans la simplicité d’utilisation de logiciels de packaging de type Prism Deploy : on prend une machine dans n’importe quel état (i.e. quels que soient les logiciels qui y sont installés), et on prend cet état pour la photo du système avant installation.

Première idée, sans doute la meilleure sur le papier : on fait un TextDiff() avant l’installation du logiciel, qui nous donne un fichier log contenant toutes les différences entre l’état actuel et l’image sur le serveur. On installe ensuite le logiciel, puis on refait un TextDiff qui nous rend un nouveau fichier log des différences avec l’image de référence sur le serveur. Il ne reste plus qu’à comparer les deux fichiers pour en constituer un troisième ne contenant que les différences, c’est-à-dire ce qui s’est passé lors de l’installation du logiciel, puis MakeDiff à partir de ce dernier fichier et voilà. Aucune image à descendre, de simples comparaisons de fichiers assez facilement automatisables : l’idéal.

Super sauf que... ça ne peut pas fonctionner. En effet, l’information contenue dans les fichiers de logs est trop incomplète : elle indique uniquement si un fichier (ou une clé de registre) a été ajoutée, supprimée ou modifiée. En cas d’ajout ou de suppression, pas de problème. En revanche, imaginons que dans le log initial (avant l’install du logiciel), le fichier UltraImportant.ext soit marqué modifié. Cela signifie donc que le fichier a été modifié entre l’image de base stockée sur le serveur et le système tel qu’il est actuellement sur la machine, probablement donc lors de l’installation d’un des logiciel présents dans le système actuel. Imaginons qu’il en soit de même dans le second log, donc après l’installation du logiciel a packager. Alors que faire ? Enlever la ligne puisqu’il n’y pas de différence entre les 2 logs ? Mais si jamais le fichier a été modifié aussi lors de l’installation du logiciel à packager : il faut alors garder trace de cette modification dans le package... Laisser la ligne ? Mais peut-être que le fichier n’a effectivement pas été modifié lors de l’installation du logiciel... Gasp ! Le problème est indécidable. Impasse, il faut faire autrement...

Deuxième idée : on crée une image du système tel qu’il est sur la machine, et on la pose sur le serveur. Ensuite, parce que TexteDiff travaille par rapport au cache, on doit la poser dans le cache de la machine (soit au moins 15 minutes avec une machine de 2004). On a alors une situation saine pour effectuer la photo avant et toutes les lignes du fichier de log de l’installation du logiciel à packager seront pertinentes et exploitables. OK, ça marche. Mais, un inconvénient de taille : c’est très long, en fait bien trop long. D’autant plus que la manip. doit être effectuée pour chaque création de package. C’est inexploitable : il faut faire autrement...

Troisième idée : et si on faisait pareil, mais en modifiant les fonctions TextDiff et MakeDiff() afin qu’elles travaillent sur des images Rembo stockées non pas sur le disque serveur mais... dans le cache Rembo local. Et si lorsqu’on produisait l’image du système avant l’installation du logiciel à packager, on la posait dans le cache local et non pas sur le serveur... Bingo ! Ca marche beaucoup plus vite ! Enfin, pondérons tout de même, ça n’est pas instantané, mais ça devient largement utilisable : 4 minutes pour faire la photo d’un système XP avec quelques logiciels sur un portable Centrino 1,2Ghz (par exemple juste le temps de taper meteo.fr sur le poste d’à côté pour savoir s’il fera beau ce week-end à Hyères ou à Briançon, selon la saison...).


[1Pour voir apparaître les valeurs correctes (i.e. celles associées au package que l’on vient de sélectionner : nom du logiciel, version, etc.) dans les champs du formulaire, il est malheureusement nécessaire de cliquer sur le bouton "Détails" (les fonctions javascript du Rembo-C sont plus pauvres que le vrai Javascript...). Attention : les valeurs qui s’affichent sont là pour information : leur modification ne sera pas prise en compte...

[2Attention : seules les infos correspondant au choix cliqué (existant ou nouveau) seront prises en compte i.e. si on choisit un logiciel existant dans la liste SANS avoir cliqué sur le bouton "existant", c’est les infos associés au bouton "Nouveau" qui seront soumises... Le Javascript Rembo ne permet pas de sélectionner le bouton automatiquement dès qu’on change les infos qui s’y rapportent

[3attention : sur le texte et non sur le bouton, qui lui aussi fait booter, mais laisse en état "Création de packages".


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