Planisware : déterminer la version des différents composants d'un Intranet Server
Introduction
Afin d’assurer une gestion de configuration efficace d’une application sous Planisware il est nécessaire de pouvoir identifier la version de chacun des composants techniques (version du noyau, version de l’applet, etc…). Cet article ne traite pas de la gestion des objets d’environnement (ou paramétrage) Planisware.
<table class= »table »border= »1″ cellpadding= »1″ cellspacing= »1″ >
<tr>
<td>
<strong>Composant</strong>
</td>
<td>
<strong>Exemple</strong>
</td>
</tr>
<tr>
<td>
Noyau – version majeure
</td>
<td>
P5 SP3
</td>
</tr>
<tr>
<td>
Noyau – version patch (« officiels »+deltas)
</td>
<td>
Maintenance Pack 5.3.2.7 + <em>liste des obin complémentaires</em>
</td>
</tr>
<tr>
<td>
Java
</td>
<td>
5.3.2.42
</td>
</tr>
<tr>
<td>
Ajax
</td>
<td>
5.3.2.7
</td>
</tr>
<tr>
<td>
mod_opx2.so
</td>
<td>
<span >5.3.0.2</span>
</td>
</tr>
</table>
Déterminer la version du noyau Planisware
Le noyau d’un Intranet Server Planisware se compose de 2 parties :
→ la version majeure du noyau installée
→ les patchs noyau (fichiers *.obin)
L’ensemble de ces 2 éléments constitue la version du noyau Planisware.
A / Déterminer la version majeur du noyau installée
La version majeure est en générale connue (OPX2R4, P5SP1, P5SP2, P5SP3….). On peut cependant la retrouver sous « OPX2Modules\bin » via le fichier *.pll.
Exemple : opx2r510w64.pll pour un noyau sous Planisware P5 SP1.
B / Déterminer la version des patchs noyau
Sur le serveur
La version des patchs noyau est l’ensemble des fichiers situés sous « OPX2Modules\updates » et qui sont compilés au démarrage. Ces patchs noyaux sont généralement livrés sous forme de Technical Pack ou Medical Pack versionnés.
Une première méthode consiste à ajouter dans le répertoire un fichier texte indiquant la version de patchs présente dans le répertoire. Cependant, pour plus de clarté dans la gestion de configuration des ces patchs, nous conseillons de créer un répertoire update par version livrée. Ainsi, au lieu de remplacer le contenu du répertoire « updates » à chaque livraison on mettra en place un nouveau répertoire (ex. « HotFix_Kernel_5.3.2.7 », « HotFix_Kernel_5.3.2.9 », etc…). On peut aussi rajouter une version applicative au nom du dossier car dans certains cas des patchs correctifs peuvent être livrés en plus du package « officiel ».
Exemple : un répertoire « update_01.02_HotFix_Kernel_5.3.2.7 » placé sous « OPX2Modules\ » contenant les patchs (*.obin) de la version 01.02 de notre application et basé sur le package de patchs « standard » 5.3.2.7.
Dans le répertoire « OPX2Modules\ » on aura donc les répertoires de chaque livraison applicative :
→ « update_01.02_HotFix_Kernel_5.3.2.7 »
→ « update_01.03_HotFix_Kernel_5.3.2.7 »
→ « update_01.04_HotFix_Kernel_5.3.2.9 »
Il suffira ensuite de préciser à Planisware qu’il faut pointer vers telle ou telle configuration de patchs. Pour cela 2 approches sont possibles :
→ modifier le fichier *.ini pour remplacer l’instruction (:set-fixes-directory « updates ») par (:set-fixes-directory « update_01.04_HotFix_Kernel_5.3.2.9 »)
→ laisser le fichier *.ini inchangé (ie. pointer vers « updates ») mais supprimer le répertoire historique « updates » et le remplacer par un lien symbolique nommé « updates » pointant vers la configuration de patch souhaitée.
Exemple : updates -> update_01.04_HotFix_Kernel_5.3.2.9
A titre personnel je conseille fortement l’utilisation des liens symboliques qui est très pratique et très claire.
Ces méthodes présentent les avantages suivants :
→ lecture immédiate de la configuration
→ les patchs des différentes versions peuvent pas être mélangés
→ le retour arrière en cas de problème est très simple (il suffit de modifier le lien symbolique ou le fichier *.ini)
En client léger
Il est également possible d’afficher la configuration des patchs noyau depuis le client léger Planisware. Pour cela il suffit de passer par le menu suivant :
Démarrer > A propos de Planisware
On note ici qu’il s’agit d’une version Planisware 5 SP3.
On retrouve ces informations sous « Infos version » :
Pour obtenir la version précise du noyau il suffit de cliquer ensuite sur « Lister les sc » :
La liste exhaustive de tous les patchs noyau (scXXXX.obin) apparait donc sous forme de liste. On peut également lire le Maintenance Pack appliqué (ici le Maintenance Pack 5.3.2.7).
Enfin on peut afficher le delta entre la conf de patchs et le package « officiel » (ici les deltas de patchs avec le Maintenance Pack 5.3.2.7).
Déterminer la version de l’applet Java
L’applet Java est un élément incontournable de la gestion de configuration d’un Intranet Server auquel les utilisateurs accèdent via Java. Sa version peut être déterminée soit sur le serveur hébergeant l’application, soit depuis le client léger.
Depuis le serveur
La version d’AJAX est indiquée dans le fichier « version.txt » du répertoire « OPX2HttpRoot\Java\ ».
Ex. « 5,3,2,42 »
Depuis le client léger
Il est possible de lire la version de l’applet java utilisé en affichant la console Java après avoir lancé l’application.
Dans l’exemple ci-dessus la version de l’applet est la 5.3.2.46.
Déterminer la version d’AJAX
La version d’AJAX est indiquée dans le fichier « version.txt » du répertoire « OPX2HttpRoot\Java\ajax ».
Ex. 5.3.2.7
Déterminer la version du module apache planisware : mod_opx2.so
Pour les Intranet Server utilisant apache comme serveur web un module apache permet de gérer les échanges entre Apache et Planisware (ex. authentification). Il s’agit du module mod_opx2.so qui possède sa propre version.
Cependant le fichier mod_opx2.so n’est pas lisible car il est compilé. Pour afficher les informations qu’il contient (notamment la version) il faut passer par la commande suivante sous unix (depuis le répertoire « /OPX2HttpServer/modules/ ») :
strings mod_opx2.so | sort | head