Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide du développeur de l'empaquetage d'applications Oracle Solaris 10 1/13 Information Library (Français) |
3. Amélioration de la fonctionnalité d'un package (opérations)
4. Vérification et transfert d'un package
5. Création d'un package : Etudes de cas
6. Techniques avancées de création de packages
Spécification du répertoire de base
Fichier de valeurs d'administration par défaut
Utilisation du paramètre BASEDIR
Utilisation des répertoires de base paramétriques
Exemples : Utilisation des répertoires de base paramétriques
Prise en compte du réadressage
Parcours des répertoires de base
Utilisation du paramètre BASEDIR
Exemple : Analyse de scripts parcourant un BASEDIR
Utilisation de chemins paramétriques relatifs
Exemple : Script request parcourant un chemin paramétrique relatif
Prise en charge du réadressage dans un environnement hétérogène
Exemple : Package réadressable traditionnel
Exemple : Package absolu traditionnel
Exemple : Solution traditionnelle
Informations supplémentaires sur les packages composites
Noms de chemins absolus à l'apparence réadressable
Exemple : Modification d'un fichier
Exemple : Création d'un fichier
Création de packages pouvant être installés à distance
Exemple : Installation sur un système client
Exemple : Installation sur un serveur ou un système autonome
Exemple : Montage de systèmes de fichiers partagés
Application de patchs à des packages
Création de packages d'archives de classe
Structure du répertoire d'un package d'archive
Mots clés de prise en charge des packages d'archive de classe
Plusieurs méthodes sont disponibles pour spécifier l'emplacement de l'installation d'un package et il est important de pouvoir modifier le répertoire de base de l'installation dynamiquement lors de la phase d'installation. Lorsque cette spécification est effectuée correctement, un administrateur peut installer plusieurs versions et plusieurs architectures sans difficulté.
Cette section aborde les méthodes courantes avant de passer à des démarches permettant d'améliorer les installations sur des systèmes hétérogènes.
Les administrateurs chargés de l'installation des packages peuvent se servir des fichiers d'administration pour contrôler l'installation des packages. Toutefois, en tant que concepteur de package, vous devez savoir ce qu'est un fichier d'administration et de quelle manière un administrateur peut modifier l'installation prévue d'un package.
Un fichier d'administration indique à la commande pkgadd si elle doit ou non effectuer les contrôles et afficher les invites qu'elle effectue/affiche habituellement. Les administrateurs doivent pour cette raison maîtriser la procédure d'installation d'un package et les scripts qui lui sont associés avant de se servir des fichiers d'administration.
Le système d'exploitation SunOS est livré avec un fichier de valeurs d'administration par défaut que vous trouverez dans /var/sadm/install/admin/default. Il s'agit du fichier établissant le niveau de politique d'administration le plus basique en matière d'installation de produits logiciels. Le fichier tel qu'il est livré est comme suit :
#ident "@(#)default 1.4 92/12/23 SMI" /* SVr4.0 1.5.2.1 */ mail= instance=unique partial=ask runlevel=ask idepend=ask rdepend=ask space=ask setuid=ask conflict=ask action=ask basedir=default
L'administrateur peut modifier ce fichier afin d'établir de nouveaux comportements par défaut ou, créer un autre fichier d'administration et spécifier son existence à l'aide de l'option -a dans la commande pkgadd.
Onze paramètres peuvent être définis dans un fichier d'administration ; toutefois, certains sont facultatifs. Pour plus d'informations, reportez-vous à admin(4).
Le paramètre basedir spécifie la manière dont le répertoire de base est généré à l'installation d'un package. La plupart des administrateurs conservent la valeur default mais le paramètre basedir peut prendre une des valeurs suivantes :
ask, qui signifie que le répertoire de base doit toujours être demandé à l'administrateur
Un nom de chemin absolu
Un nom de chemin absolu contenant $PKGINST, qui signifie que l'installation doit toujours être effectuée dans un répertoire de base généré à partir de l'instance du package
Remarque - Si la commande pkgadd est appelée avec l'argument - a none, elle demande systématiquement le répertoire de base à l'administrateur. Malheureusement, cette commande définit également tous les paramètres du fichier sur la valeur par défaut quit qui est susceptible d'engendrer des problèmes supplémentaires.
Un administrateur contrôle tous les packages installés sur un système via l'utilisation d'un fichier d'administration. Un autre fichier de valeurs d'administration par défaut est malheureusement souvent fourni par le concepteur du package ; ce fichier ignore en effet les souhaits de l'administrateur.
Les concepteurs de package incluent parfois un autre fichier d'administration qui leur permet (et non pas à l'administrateur) de contrôler l'installation d'un package. Etant donné que l'entrée basedir du fichier de valeurs d'administration par défaut ignore tous les autres répertoires de base, elle représente une méthode simple de sélection du répertoire de base lors de la phase d'installation. Dans toutes les versions du SE Oracle Solaris antérieures à 2.5, cette méthode était considérée comme la plus simple pour contrôler le répertoire de base.
Toutefois, vous devez tenir compte des souhaits de l'administrateur relatifs à l'installation du produit. La présence d'un fichier temporaire de valeurs d'administration par défaut destiné à contrôler l'installation induit la méfiance chez les administrateurs. Utilisez un script request et un script checkinstall pour contrôler ces installations sous la direction de l'administrateur. Si le script request implique véritablement l'administrateur dans la procédure, l'empaquetage du System V bénéficiera à la fois aux administrateurs et aux concepteurs de package.
Le fichier pkginfo de tout package réadressable doit contenir une entrée spécifiant le répertoire de base par défaut dans le format suivant :
BASEDIR=absolute_path
Il ne s'agit que du répertoire de base par défaut et peut de ce fait être remplacé par l'administrateur au cours de l'installation.
Bien que certains packages requièrent plusieurs répertoires de base, l'avantage que présente ce paramètre pour le placement du package est que le répertoire de base est déjà créé et prêt à être utilisé dès le lancement de l'installation. Le chemin d'accès approprié au répertoire de base du serveur et du client est mis à la disposition de tous les scripts de procédure sous la forme de variables d'environnement réservées. La commande pkginfo -r SUNWstuf affiche la base d'installation actuelle du package.
Dans le script checkinstall, BASEDIR est le paramètre tel qu'il a été défini dans le fichier pkginfo (non encore déterminé). Afin de vérifier le répertoire de base cible, la construction ${PKG_INSTALL_ROOT}$BASEDIR est nécessaire. Ceci signifie que le script request ou checkinstall peut remplacer la valeur de BASEDIR dans l'environnement d'installation avec des résultats prévisibles. Le temps que le script preinstall soit appelé, le paramètre BASEDIR a été remplacé par le pointeur entièrement conditionné du répertoire de base actuel sur le système cible, même si le système est un client.
Remarque - Le script request se sert du paramètre BASEDIR différemment selon la version du système d'exploitation SunOS. Afin de tester un paramètre BASEDIR dans un script request, le code suivant doit être utilisé pour déterminer le répertoire de base alors utilisé.
# request script constructs base directory if [ ${CLIENT_BASEDIR} ]; then LOCAL_BASE=$BASEDIR else LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR fi
Si un package nécessite plusieurs répertoires de base, vous pouvez les créer à l'aide de noms de chemin paramétriques. Cette méthode est devenue assez populaire bien qu'elle présente les inconvénients suivants :
Un package contenant des noms de chemin paramétriques se comporte généralement comme un package absolu mais est traité par la commande pkgadd comme un package réadressable. Le paramètre BASEDIR doit être défini même s'il n'est pas utilisé.
L'administrateur ne peut pas déterminer la base d'installation du package avec les utilitaires du System V (la commande pkginfo -r ne fonctionne pas).
L'administrateur ne peut pas se servir de la méthode établie pour réadresser le package (il est qualifié d'adressable mais se comporte comme un package absolu).
L'installation de plusieurs architectures ou de plusieurs versions nécessite de prévoir des plans d'urgence pour chacun des répertoires de base cible, ce qui se traduit souvent par l'utilisation de scripts d'action de classe complexes.
Bien que les paramètres qui déterminent les répertoires de base soient définis dans le fichier pkginfo, ils peuvent être modifiés par le script request. Cette caractéristique est une des raisons principales de la popularité de cette approche. Les inconvénients sont cependant chroniques et il est recommandé de n'utiliser cette configuration qu'en dernier ressort.
# 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=/ EZDIR=/usr/stuf/EZstuf HRDDIR=/opt/SUNWstuf/HRDstuf VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert980707141632
: 1 1758 1 d none $EZDIR 0775 root bin 1 f none $EZDIR/dirdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/usrdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/filedel 0555 bin bin 40 773 751310229 1 d none $HRDDIR 0775 root bin 1 f none $HRDDIR/mksmart 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mktall 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mkcute 0555 bin bin 40 773 751310229 1 f none $HRDDIR/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
Tout package disponible en plusieurs versions ou destiné à plusieurs architectures doit être conçu de sorte à pouvoir, le cas échéant, parcourir le répertoire de base. Le parcours d'un répertoire de base signifie que si une version précédente ou une architecture différente du package sur le point d'être installée se trouve déjà dans le répertoire de base, ce package résout le problème, en créant par exemple un nouveau répertoire de base sous un nom légèrement différent. Les scripts request et checkinstall de Solaris 2.5 et des versions compatibles sont en mesure de modifier la variable d'environnement BASEDIR. Ceci n'est pas le cas des versions précédentes du système d'exploitation Oracle Solaris.
Même dans les versions plus anciennes du système d'exploitation Oracle Solaris, le script request pouvait redéfinir les répertoires au sein de la base d'installation. Le script request est en mesure d'effectuer cette opération d'une manière prenant en charge la plupart des préférences d'administration.