Prise en charge du réadressage dans un environnement hétérogène
Le concept d'origine sur lequel repose l'empaquetage du System V présumait une architecture par système. Le concept d'un serveur ne jouait aucun rôle dans la conception. De nos jours, bien entendu, un seul serveur peut prendre en charge plusieurs architectures, ce qui peut se traduire par la présence de plusieurs copies d'un logiciel sur un même serveur, chacune étant destinée à une architecture différente. Bien que les packages Solaris soient isolés dans la limite des systèmes de fichiers recommandés (par exemple, / et /usr), les bases de données des produits étant stockées à la fois sur le serveur et sur chaque client, les installations ne prennent pas toutes nécessairement en charge cette division. Certaines implémentations prennent en charge une structure entièrement différente et impliquent une base de données de produits commune. Bien que diriger les clients vers des versions différentes soit très simple, installer des packages System V dans des répertoires de base différents peut s'avérer complexe pour l'administrateur.
Lors de la conception de votre package, vous devez également prendre en considération les méthodes courantes employées par les administrateurs pour introduire la nouvelle version d'un logiciel. Les administrateurs souhaitent souvent installer et tester la toute dernière version parallèlement à la version déjà installée. La procédure consiste à installer la nouvelle version dans un répertoire de base autre que celui dans lequel la version actuelle est installée et à rediriger une poignée de clients non importants vers la nouvelle version afin de la tester. À mesure que sa confiance augmente, l'administrateur redirige de plus en plus de clients vers la nouvelle version. Après un certain temps, l'administrateur ne conserve l'ancienne version que pour des cas d'urgence et finit par la supprimer.
En d'autres termes, les packages destinés aux systèmes hétérogènes modernes doivent prendre en charge le vrai réadressage au sens où l'administrateur peut être amené à les placer à tout endroit raisonnable du système de fichiers et s'attendre à pouvoir utiliser toutes leurs fonctionnalités. L'environnement Solaris 2.5 et les versions compatibles offrent divers outils très utiles qui permettent d'installer correctement plusieurs architectures et versions sur un même système. Solaris 2.4 et les versions compatibles prennent également en charge le vrai réadressage mais leur procédure n'est pas aussi évidente.
Approche traditionnelle
Packages réadressables
L'ABI du System V suggère que le premier objectif d'un package réadressable était de simplifier l'installation du package pour l'administrateur. De nos jours, la nécessité des packages réadressables va plus loin. Il n'est plus seulement question de commodité puisqu'il arrive souvent lors de l'installation qu'un produit logiciel actif se trouve déjà dans le répertoire par défaut. Un package non conçu dans l'optique de gérer cette situation peut soit remplacer le produit existant, soit suspendre l'installation. Par contre, un package conçu pour gérer plusieurs architectures et plusieurs versions peut procéder à l'installation correctement et offrir à l'administrateur diverses options entièrement compatibles avec les habitudes d'administration déjà en place.
D'une certaine manière, le problème lié à l'existence de plusieurs architectures et celui lié à plusieurs versions est le même. Il faut pouvoir installer une variante du package actuel parallèlement à d'autres variantes et pouvoir diriger les clients ou les utilisateurs de systèmes autonomes de fichiers exportés vers n'importe laquelle de ces variantes sans y perdre en fonctionnalité. Bien que Sun ait établi des méthodes permettant de gérer plusieurs architectures sur un serveur, les administrateurs ne se conforment pas toujours à ces recommandations. Tous les packages doivent pouvoir se conformer aux souhaits raisonnables des administrateurs en matière d'installation.
Exemple : Package réadressable traditionnel
L'exemple suivant illustre l'apparence d'un package réadressable traditionnel. Le package doit être placé dans /opt/SUNWstuf et ses fichiers pkginfo et pkgmap peuvent s'afficher comme suit :
Fichier pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
Fichier pkgmap
: 1 1758 1 d none SUNWstuf 0775 root bin 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
On parle ici de méthode traditionnelle car chaque objet de package est installé dans le répertoire de base défini par le paramètre BASEDIR du fichier pkginfo. Par exemple, le premier objet du fichier pkgmap est installé comme répertoire /opt/SUNWstuf.
Packages absolus
Un package absolu est un package qui s'installe sur un système de fichiers root (/) particulier. Ces packages sont difficiles à gérer du point de vue de plusieurs versions et architectures. En règle générale, tous les packages doivent être réadressables. Il existe cependant de très bonnes raisons d'inclure des éléments absolus dans un package réadressable.
Exemple : Package absolu traditionnel
Si le package SUNWstuf était un package absolu, le paramètre BASEDIR ne devrait pas être défini dans le fichier pkginfo et le fichier pkgmap serait comme suit :
Fichier pkgmap
: 1 1758 1 d none /opt ? ? ? 1 d none /opt/SUNWstuf 0775 root bin 1 d none /opt/SUNWstuf/EZstuf 0775 root bin 1 f none /opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none /opt/SUNWstuf/HRDstuf 0775 root bin 1 f none /opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
Dans cet exemple, si l'administrateur a spécifié un autre répertoire de base lors de l'installation, il est ignoré par la commande pkgadd. Ce package s'installe toujours dans /opt/SUNWstuf du système cible.
L'argument -R de la commande pkgadd fonctionne comme prévu. Par exemple,
pkgadd -d . -R /export/opt/client3 SUNWstuf |
installe les objets dans /export/opt/client3/opt/SUNWstuf ; toutefois, il s'agit du seul semblant de réadressage de ce package.
Notez l'emploi du point d'interrogation (?) pour le répertoire /opt du fichier pkgmap. Il indique que les attributs actuels ne doivent pas être modifiés. Cela ne signifie pas « créer le répertoire à partir des attributs par défaut », bien que cela puisse se produire dans certaines situations. Tout répertoire spécifique au nouveau package doit spécifier tous les attributs de manière explicite.
Packages composites
Tout package contenant des objets réadressables est appelé un package réadressable. Ceci peut porter à confusion puisque le fichier pkgmap du package réadressable peut contenir des chemins absolus. L'utilisation d'une entrée racine (/) dans un fichier pkgmap peut améliorer les aspects réadressables du package. Les packages contenant à la fois des entrées réadressables et des entrées racines sont appelés des packages composites.
Exemple : Solution traditionnelle
Supposons qu'un objet dans le package SUNWstuf soit un script de démarrage exécuté au niveau d'exécution 2. Vous devez installer le fichier /etc/rc2.d/S70dostuf en tant que partie du package mais vous ne pouvez pas le placer dans le répertoire de base. Supposons qu'un package réadressable soit l'unique solution ; les fichiers pkginfo et pkgmap seraient comme suit :
Fichier pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/ VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
Fichier pkgmap
: 1 1758 1 d none opt/SUNWstuf/EZstuf 0775 root bin 1 f none opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none opt/SUNWstuf/HRDstuf 0775 root bin 1 f none opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none etc ? ? ? 1 d none etc/rc2.d ? ? ? 1 f none etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
Il n'existe pas de grandes différences entre cette approche et celle utilisée pour le package absolu. Un package absolu est en fait plus approprié car si l'administrateur a spécifié un autre répertoire de base, cette solution ne fonctionne pas.
En fait, seul un fichier de ce package doit être relatif à la racine ; les autres peuvent être placés n'importe où. L'utilisation d'un package composite comme solution à ce problème est abordée dans la suite de cette section.
Au-delà de la tradition
L'approche décrite dans cette section n'est pas applicable à tous les packages mais elle permet d'améliorer les performances lors de l'installation sur un environnement hétérogène. Les packages fournis dans le cadre du système d'exploitation Solaris (packages fournis en standard) sont peu concernés par cette approche ; par contre, les packages non fournis en standard peuvent se servir de l'empaquetage non traditionnel.
La raison pour laquelle les packages réadressables sont recommandés est la prise en charge de la spécification suivante :
Lorsqu'un package est ajouté ou supprimé, les comportements actuels souhaités des produits logiciels restent inchangés.
Les packages non fournis en standard doivent résider dans /opt pour s'assurer que le nouveau package n'interfère pas avec les produits existants.
Informations supplémentaires sur les packages composites
Deux règles doivent être appliquées lors de la création d'un package composite fonctionnel :
-
Établir le répertoire de base en fonction de la destination de la majorité des objets du package.
-
Lorsqu'un objet de package doit être placé dans un répertoire commun autre que le répertoire de base (par exemple, /etc), le spécifier en tant que nom de chemin absolu dans le fichier prototype.
En d'autres termes, puisque qu'un objet réadressable peut par définition être installé à tout endroit et fonctionner correctement ainsi, aucun script de démarrage exécuté par init lors de l'initialisation ne peut être considéré comme réadressable. Bien que spécifier /etc/passwd en tant que chemin relatif dans le package livré n'est en soi pas incorrect, il ne peut y avoir qu'une destination.
Noms de chemins absolus à l'apparence réadressable
Lorsque vous créez un package composite, les chemins absolus doivent fonctionner sans interférer avec les logiciels déjà installés. Un package pouvant être intégralement contenu dans /opt évite ce problème puisque aucun fichier ne représente un obstacle. Lorsqu'un fichier placé dans /etc est inclus dans le package, vous devez vous assurer que les noms de chemins absolus se comportent comme des noms de chemins relatifs. Réfléchissez aux deux exemples suivants :
Exemple : Modification d'un fichier
Description
Une entrée est ajoutée à un tableau ou l'objet est un nouveau tableau susceptible d'être modifié par d'autres programmes ou packages.
Implémentation
Définissez l'objet comme ayant le type de fichier e et appartenant à la classe build, awk ou sed. Le script effectuant cette opération doit se supprimer aussi efficacement qu'il s'ajoute.
Exemple
Une entrée doit être ajoutée à /etc/vfstab pour prendre en charge le nouveau disque dur électronique.
L'entrée dans le fichier pkgmap pourrait être :
1 e sed /etc/vfstab ? ? ? |
Le script request demande à l'opérateur si /etc/vfstab doit être modifié par le package. Si l'opérateur répond par la négative, le script request imprime les instructions de la procédure manuelle et exécute :
echo "CLASSES=none" >> $1 |
Si l'opérateur répond par l'affirmative, il exécute :
echo "CLASSES=none sed" >> $1 |
Ceci active le script d'action de classe qui doit apporter les modifications requises. La classe sed indique que le fichier de package /etc/vfstab est un programme sed qui contient les procédures d'installation et de suppression du fichier du même nom sur le système cible.
Exemple : Création d'un fichier
Description
L'objet est un fichier entièrement nouveau peu susceptible d'être modifié ultérieurement ou un fichier qui en remplace un autre appartenant à un package différent.
Implémentation
Définissez l'objet de package comme ayant le type de fichier f et installez-le à l'aide d'un script d'action de classe capable d'annuler la modification.
Exemple
Un tout nouveau fichier est nécessaire dans /etc afin de fournir les informations requises pour la prise en charge du disque dur électronique, appelé /etc/shdisk.conf . L'entrée dans le fichier pkgmap peut être :
. . . 1 f newetc /etc/shdisk.conf . . . |
Le script d'action de classe i.newetc est chargé d'installer ce fichier ainsi que tout autre fichier devant être placé dans /etc. Il vérifie qu'aucun autre fichier ne s'y trouve. Si le répertoire est vide, il y copie tout simplement le fichier. S'il contient déjà un fichier, il le sauvegarde avant d'installer le nouveau fichier. Le script r.newetc supprime ces fichiers et le cas échéant, rétablit les originaux. Vous trouverez ci-après le fragment clé du script d'installation.
# i.newetc
while read src dst; do
if [ -f $dst ]; then
dstfile=`basename $dst`
cp $dst $PKGSAV/$dstfile
fi
cp $src $dst
done
if [ "${1}" = "ENDOFCLASS" ]; then
cd $PKGSAV
tar cf SAVE.newetc .
$INST_DATADIR/$PKG/install/squish SAVE.newetc
fi
|
Notez que ce script utilise la variable d'environnement PKGSAV pour stocker une sauvegarde du fichier à remplacer. Lorsque l'argument ENDOFCLASS est transmis au script, autrement dit lorsque la commande pkgadd informe le script qu'il s'agit des dernières entrées de cette classe, le script archive et compresse les fichiers enregistrés à l'aide d'un programme de compression privé stocké dans le répertoire d'installation du package.
Bien que l'utilisation de la variable d'environnement PKGSAV ne soit pas fiable pendant la mise à jour d'un package, si le package n'est pas mis à jour (à l'aide d'un patch par exemple), le fichier de sauvegarde est sécurisé. Le script de suppression suivant inclut un code permettant de résoudre le deuxième problème, à savoir, le fait que dans les anciennes versions, la commande pkgrm ne transmet pas aux scripts le bon chemin d'accès à la variable d'environnement PKGSAV .
Le script de suppression peut être comme suit :
# r.newetc
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
while read file; do
rm $file
done
if [ "${1}" = ENDOFCLASS ]; then
if [ -f $PKGSAV/SAVE.newetc.sq ]; then
$UNSQUISH_CMD $PKGSAV/SAVE.newetc
fi
if [ -f $PKGSAV/SAVE.newetc ]; then
targetdir=dirname $file # get the right directory
cd $targetdir
tar xf $PKGSAV/SAVE.newetc
rm $PKGSAV/SAVE.newetc
fi
fi
|
Ce script utilise un algorithme de désinstallation privé (unsquish) situé dans le répertoire d'installation de la base de données des packages. Ceci est automatiquement effectué par la commande pkgadd lors de la phase d'installation. Tous les scripts non spécifiquement reconnus comme ayant l'attribut d'installation seule par la commande pkgadd sont stockés dans ce répertoire afin d'être utilisés par la commande pkgrm. Vous ne pouvez pas compter sur l'emplacement de ce répertoire mais vous pouvez être sûr qu'il est plat et qu'il contient toutes les informations et scripts d'installation appropriés du package. Ce script trouve le répertoire en raison du fait que le script d'action de classe s'exécute systématiquement à partir du répertoire contenant le programme unsquish.
Notez également que ce script ne suppose pas simplement que le répertoire cible est /etc. Il peut en fait s'agir de /export/root/client2/etc . Le répertoire approprié peut être créé de deux façons.
-
utilisez la construction ${PKG_INSTALL_ROOT}/etc, ou
-
utilisez le nom de répertoire d'un fichier transmis par la commande pkgadd (ce que le script fait).
L'utilisation de cette approche pour chaque objet absolu du package vous assure que le comportement actuel souhaité reste inchangé ou qu'il est au moins récupérable.
Exemple : Package composite
L'exemple suivant illustre les fichiers pkginfo et pkgmap d'un package composite.
Fichier pkginfo
PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none daemon PSTAMP=hubert990707141632 |
Fichier pkgmap
: 1 1758 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i i.daemon 509 39560 752978103 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 1 i r.daemon 320 24573 742152591 |
Alors que S70dostuf appartient à la classe daemon, les répertoires qui y accèdent (déjà en place lors de la phase d'installation) appartiennent eux à la classe none. Même si les répertoires étaient uniques à ce package, vous devriez les laisser dans la classe none. Ceci, parce que les répertoires doivent être créés en premier et supprimés en dernier, ce qui est toujours vrai de la classe none. La commande pkgadd crée des répertoires qui ne sont ni copiés à partir du package, ni transmis à un script d'action de classe afin d'être créés. Ils sont par contre créés par la commande pkgadd avant qu'elle n'appelle le script d'action de classe ; la commande pkgrm par ailleurs supprime les répertoires une fois le script d'action de classe de suppression terminé.
De ce fait, lorsqu'un répertoire d'une classe spéciale contient des objets de la classe none, la tentative de suppression du répertoire par la commande pkgrm échoue car le répertoire n'est pas vidé à temps. Si un objet de la classe none doit être inséré dans un répertoire d'une classe spéciale, le répertoire en question n'est pas créé à temps pour recevoir l'objet. La commande pkgadd crée le répertoire à la volée au cours de l'installation de l'objet et ne parvient parfois pas à synchroniser les attributs de ce répertoire lorsqu'elle trouve la définition pkgmap.
Remarque –
Lorsque vous attribuez un répertoire à une classe, pensez toujours à l'ordre de création et de suppression.
- © 2010, Oracle Corporation and/or its affiliates