Ce chapitre présente des études de cas permettant d'illustrer divers scénarios d'empaquetage, notamment l'installation d'objets de manière conditionnelle, la prise de décision lors de l'exécution du nombre de fichiers à créer et la modification d'un fichier de données existant au cours de l'installation et de la suppression d'un package.
Chaque étude de cas commence par une description, suivie d'une liste de techniques d'empaquetage utilisées, d'une description de la démarche à suivre pour appliquer ces techniques et d'exemples de fichiers et de scripts associés à l'étude de cas.
Les études de cas décrites dans ce chapitre sont les suivantes :
Création d'un fichier lors de l'installation et enregistrement du fichier lors de la suppression
Définition des compatibilités et des dépendances d'un package
Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe
Modification d'un fichier à l'aide de la classe sed et d'un script postinstall
Installation et suppression d'un pilote à l'aide de scripts de procédure
Installation d'un pilote à l'aide de la classe sed et de scripts de procédure
Le package décrit dans cette étude de cas contient trois types d'objets. L'administrateur peut sélectionner le type d'objets qu'il souhaite installer et l'emplacement des objets sur la machine d'installation.
Cette étude de cas illustre les techniques suivantes :
Utilisation de noms de chemin paramétriques (variables contenues dans les noms de chemin d'objet utilisées pour définir plusieurs répertoires de base)
Pour plus d'informations sur les noms de chemin paramétriques, reportez-vous à Noms de chemin paramétriques.
Utilisation d'un script request pour demander la participation de l'administrateur
Pour plus d'informations sur les scripts request, reportez-vous à Rédaction d'un script request.
Définition de valeurs conditionnelles pour un paramètre d'installation.
Pour définir l'installation sélective de cette étude de cas, vous devez effectuer les opérations suivantes :
Définir une classe pour chaque type d'objet pouvant être installé.
Dans cette étude de cas, les trois types d'objet sont les fichiers exécutables du package, les pages de manuel et les exécutablesemacs. Chaque type dispose de sa propre classe : respectivement bin, man et emacs. Notez que dans le fichier prototype, tous les fichiers d'objets appartiennent à une de ces trois classes.
Donner au paramètre CLASSES du fichier pkginfo la valeur nulle.
En règle générale lorsque vous définissez une classe, vous devez indiquer cette classe dans le paramètre CLASSES du fichier pkginfo. Aucun objet de cette classe ne peut sinon être installé. Dans cette étude de cas, la valeur de ce paramètre est au départ nulle, signifiant qu'aucun objet ne peut être installé. Le paramètre CLASSES est ensuite remplacé via le script request, en fonction des choix de l'administrateur. De cette façon, le paramètre CLASSES ne contient que la valeur des types d'objet que l'administrateur souhaite installer.
Il est recommandé de donner aux paramètres une valeur par défaut. Si le package contient par exemple des composants communs aux trois types d'objet, vous pouvez les attribuer à la classe none et donner au paramètre CLASSES la valeur none.
Insérer les noms de chemin paramétriques dans le fichier prototype.
Le script request donne à ces variables d'environnement la valeur fournie par l'administrateur. La commande pkgadd résout ensuite ces variables d'environnement lors de la phase d'installation pour connaître l'emplacement de l'installation du package.
Les trois variables d'environnement utilisées dans cet exemple sont définies sur leur valeur par défaut dans le fichier pkginfo et ont les rôles suivants :
$NCMPBIN définit l'emplacement des exécutables des objets ;
$NCMPMAN définit l'emplacement des pages de manuel ;
$EMACS définit l'emplacement des exécutables emacs.
L'exemple de fichier prototype illustre la manière de définir les noms de chemin des objets avec des variables.
Créer un script request pour demander à l'administrateur quelles parties du package doivent être installées et à quel endroit les placer.
Le script request de ce package pose deux questions à l'administrateur :
Cette partie du package doit-elle être installée ?
Lorsque la réponse est oui, le nom de classe approprié est ajouté au paramètre CLASSES. Par exemple, lorsque l'administrateur choisit d'installer les pages de manuel associées au package, la classe man est ajoutée au paramètre CLASSES.
Dans ce cas, à quel endroit cette partie du package doit-elle être placée ?
La variable d'environnement appropriée est définie sur la réponse à cette question. Dans l'exemple des pages de manuel, la variable $NCMPMAN prend la valeur donnée en réponse.
Ce deux questions sont réitérées pour chacun de trois types d'objet.
À la fin du script request, les paramètres sont mis à la disposition de l'environnement d'installation pour la commande pkgadd et tout autre script d'empaquetage. Le script request effectue cette opération en enregistrant ces définitions dans le fichier fourni par l'utilitaire d'appel. Aucun autre script n'est fourni pour cette étude de cas.
Remarquez dans ce script request que les questions sont générées par les outils de validation des données ckyorn et ckpath. Pour plus d'informations sur ces outils, reportez-vous à ckyorn(1) et ckpath(1).
PKG=ncmp NAME=NCMP Utilities CATEGORY=application, tools BASEDIR=/ ARCH=SPARC VERSION=RELEASE 1.0, Issue 1.0 CLASSES="" NCMPBIN=/bin NCMPMAN=/usr/man EMACS=/usr/emacs |
i pkginfo i request x bin $NCMPBIN 0755 root other f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other x emacs $EMACS 0755 root other f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other d man $NCMPMAN 0755 root other d man $NCMPMAN/man1 0755 root other f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other |
trap 'exit 3' 15 # determine if and where general executables should be placed ans=`ckyorn -d y \ -p "Should executables included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES bin" NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \ -p "Where should executables be installed" ` || exit $? fi # determine if emacs editor should be installed, and if it should # where should the associated macros be placed ans=`ckyorn -d y \ -p "Should emacs editor included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES emacs" EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \ -p "Where should emacs macros be installed" ` || exit $? fi |
Remarquez qu'un script request peut s'arrêter sans ne laisser aucun fichier dans le système de fichiers. Dans le cadre des installations sur les versions antérieures à 2.5 de Solaris et versions compatibles (où aucun script checkinstall ne peut être utilisé), le script request est l'endroit où effectuer tous les tests nécessaires vis à vis du système de fichiers afin de garantir le succès de l'installation. Lorsque le script request contient le code 1, l'installation s'arrête nette.
Ces exemples de fichiers illustrent l'emploi des chemins paramétriques pour définir plusieurs répertoires de base. Toutefois, la méthode recommandée implique l'utilisation du paramètre BASEDIR qui est géré et validé par la commande pkgadd. Chaque fois que plusieurs répertoires de base sont utilisés, prenez les mesures nécessaires en prévision de l'installation de plusieurs versions et architectures sur la même plate-forme.
Cette étude de cas crée un fichier de base de données lors de la phase d'installation et enregistre une copie de la base de données à la suppression du package.
Cette étude de cas illustre les techniques suivantes :
Utilisation de classes et de scripts d'action de classe pour effectuer des opérations particulières sur différents groupes d'objets
Pour plus d'informations, reportez-vous à Rédaction de scripts d'action de classe.
Utilisation du fichier space pour informer la commande pkgadd que de l'espace supplémentaire est nécessaire au bon déroulement de l'installation de ce package
Pour plus d'informations sur le fichier space, reportez-vous à Réservation d'espace supplémentaire sur un système cible.
Utilisation de la commande installf pour installer un fichier non défini dans les fichiers prototype et pkgmap.
Pour créer un fichier de base de données lors de l'installation et enregistrer une copie lors de la suppression, vous devez pour cette étude de cas effectuer les opérations suivantes :
Définir trois classes.
Les trois classes suivantes doivent être définies dans le paramètre CLASSES pour le package de cette étude de cas :
La classe standard none qui contient un groupe de processus appartenant au sous-répertoire bin ;
La classe admin qui contient un fichier exécutable config et un répertoire contenant des fichiers de données ;
La classe cfgdata qui contient un répertoire.
Faire du package un package réadressable collectivement.
Remarquez dans le fichier prototype qu'aucun des noms de chemin ne commence par une barre oblique ni par une variable d'environnement. Ceci indique qu'ils sont réadressables collectivement.
Calculer la quantité d'espace requise par le fichier de la base de données et créer un fichier space à fournir avec le package. Ce fichier informe la commande pkgadd que le package nécessite de l'espace supplémentaire et indique la quantité requise.
Créer un script d'action de classe pour la classe admin (i.admin).
L'exemple de script initialise une base de données à l'aide des fichiers de données appartenant à la classe admin. Pour effectuer cette opération, il procède comme suit :
Il copie le fichier de données source à l'emplacement de destination approprié.
Il crée un fichier vide nommé config.data et l'attribue à une classe cfgdata.
Il exécute la commande bin/config, qui est fournie avec le package et est déjà installée, pour renseigner le fichier de base de données config.data à l'aide des fichiers de données appartenant à la classe admin.
Il exécute la commande installf -f pour terminer l'installation de config.data.
Aucune opération particulière n'est nécessaire vis à vis de la classe admin lors de la phase de suppression et pour cette raison, aucun script d'action de classe de suppression n'est créé. Tous les fichiers et répertoires de la classe admin sont donc supprimés du système.
Créer un script d'action de classe pour la classe cfgdata (r.cfgdata).
Le script de suppression crée une copie du fichier de la base de données avant sa suppression. Aucune opération particulière n'est nécessaire vis à vis de cette classe lors de la phase d'installation et pour cette raison, aucun script d'action de classe d'installation n'est nécessaire.
N'oubliez pas que les valeurs à indiquer dans un script de suppression correspondent à la liste des noms de chemin à supprimer. Les noms de chemin s'affichent toujours par ordre alphabétique inverse. Ce script de suppression copie les fichiers dans le répertoire nommé $PKGSAV. Une fois tous les noms de chemin traités, le script supprime tous les répertoires et fichiers associés à la classe cfgdata.
Le résultat de cette suppression est la copie de config.data dans $PKGSAV, suivie de la suppression du fichier config.data et du répertoire de données.
PKG=krazy NAME=KrAzY Applications CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1 CLASSES=none cfgdata admin |
i pkginfo i request i i.admin i r.cfgdata d none bin 555 root sys f none bin/process1 555 root other f none bin/process2 555 root other f none bin/process3 555 root other f admin bin/config 500 root sys d admin cfg 555 root sys f admin cfg/datafile1 444 root sys f admin cfg/datafile2 444 root sys f admin cfg/datafile3 444 root sys f admin cfg/datafile4 444 root sys d cfgdata data 555 root sys |
# extra space required by config data which is # dynamically loaded onto the system data 500 1 |
# PKGINST parameter provided by installation service # BASEDIR parameter provided by installation service while read src dest do cp $src $dest || exit 2 done # if this is the last time this script will be executed # during the installation, do additional processing here. if [ "$1" = ENDOFCLASS ] then # our config process will create a data file based on any changes # made by installing files in this class; make sure the data file # is in class `cfgdata' so special rules can apply to it during # package removal. installf -c cfgdata $PKGINST $BASEDIR/data/config.data f 444 root sys || exit 2 $BASEDIR/bin/config > $BASEDIR/data/config.data || exit 2 installf -f -c cfgdata $PKGINST || exit 2 fi exit 0 |
Cet exemple illustre une situation rare dans laquelle installf est approprié dans un script d'action de classe. Le fichier space ayant été utilisé pour réserver de l'espace sur un système de fichiers spécifique, ce nouveau fichier peut être ajouté sans problèmes bien qu'il ne soit pas inclus dans le fichier pkgmap.
# the product manager for this package has suggested that # the configuration data is so valuable that it should be # backed up to $PKGSAV before it is removed! while read path do # path names appear in reverse lexical order. mv $path $PKGSAV || exit 2 rm -f $path || exit 2 done exit 0 |
Le package de cette étude de cas utilise des fichiers d'information facultatifs pour définir les compatibilités et les dépendances d'un package, et afficher un message de copyright au cours de l'installation.
Cette étude de cas illustre les techniques suivantes :
Utilisation du fichier copyright
Utilisation du fichier compver
Utilisation du fichier depend
Pour plus d'informations sur ces fichiers, reportez-vous à Création de fichiers d'information.
Pour respecter les critères fournis dans la description, vous devez :
Créez un fichier copyright.
Un fichier copyright contient le texte ASCII d'un message de copyright. Le message illustré dans l'exemple de fichier s'affiche à l'écran lors de l'installation du package.
Créer un fichier compver.
Le fichier pkginfo illustré sur la figure suivante définit la version du package comme étant la version 3.0. Le fichier compver définit la version 3.0 comme étant compatible avec les versions 2.3, 2.2, 2.1, 2.1.1, 2.1.3 et 1.7.
Créer un fichier depend.
Les fichiers répertoriés dans un fichier depend doivent déjà être installés sur le système au moment de l'installation d'un package. L'exemple de fichier indique que 11 packages doivent déjà être installés sur le système au moment de l'installation.
PKG=case3 NAME=Case Study #3 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 3.0 CLASSES=none |
Copyright (c) 1999 company_name All Rights Reserved. THIS PACKAGE CONTAINS UNPUBLISHED PROPRIETARY SOURCE CODE OF company_name. The copyright notice above does not evidence any actual or intended publication of such source code |
Version 3.0 Version 2.3 Version 2.2 Version 2.1 Version 2.1.1 Version 2.1.3 Version 1.7 |
P acu Advanced C Utilities Issue 4 Version 1 P cc C Programming Language Issue 4 Version 1 P dfm Directory and File Management Utilities P ed Editing Utilities P esg Extended Software Generation Utilities Issue 4 Version 1 P graph Graphics Utilities P rfs Remote File Sharing Utilities Issue 1 Version 1 P rx Remote Execution Utilities P sgs Software Generation Utilities Issue 4 Version 1 P shell Shell Programming Utilities P sys System Header Files Release 3.1 |
Cette étude de cas modifie un fichier existant lors de l'installation d'un package à l'aide de classes standard et de scripts d'action de classe. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de la classe sed et d'un script postinstall et Modification d'un fichier à l'aide de la classe build. Le fichier modifié est /etc/inittab .
Cette étude de cas illustre la façon d'utiliser les scripts d'action de classe d'installation et de suppression. Pour plus d'informations, reportez-vous à Rédaction de scripts d'action de classe.
Pour modifier /etc/inittab au cours de l'installation à l'aide de classes et de scripts d'action de classe, vous devez effectuer les opérations suivantes :
Créer une classe.
Créez une classe appelée inittab . Vous devez fournir un script d'action de classe d'installation et de suppression pour cette classe. Définissez la classe inittab dans le paramètre CLASSES du fichier pkginfo.
Créer un fichier inittab.
Ce fichier contient les informations de l'entrée à ajouter dans /etc/inittab . Remarquez dans le fichier prototype que inittab appartient à la classe inittab et que son type de fichier est e (modifiable).
Créer un script d'action de classe d'installation (i.inittab).
N'oubliez pas que les scripts d'action de classe doivent produire les mêmes résultats chaque fois qu'ils sont exécutés. Le script d'action de classe effectue les procédures suivantes :
Il regarde si cette entrée a déjà été ajoutée.
Si elle a déjà été ajoutée, il supprime toutes les versions de l'entrée qu'il trouve.
Il modifie le fichier inittab et ajoute des lignes de commentaires indiquant d'où provient l'entrée.
Il replace le fichier temporaire dans /etc/inittab.
Il exécute la commande init q lorsqu'il reçoit l'indicateur ENDOFCLASS.
Notez que la commande init q peut être effectuée par ce script d'installation. Cette démarche ne requiert pas de script postinstall d'une ligne.
Créer un script d'action de classe de suppression (r.inittab).
Le script de suppression est très similaire au script d'installation. Les informations ajoutées par les scripts d'installation sont supprimées et la commande init q est exécutée.
Cette étude de cas est plus complexe que la suivante ; reportez-vous à Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Au lieu de fournir deux fichiers, trois sont nécessaires et le fichier /etc/inittab fourni n'est qu'un substituant contenant un segment de l'entrée à insérer. Ce segment aurait pu être placé dans le fichier i.inittab mais la commande pkgadd doit avoir un fichier à transmettre au fichier i.inittab. En outre, la procédure de suppression doit être placée dans un fichier distinct (r.inittab ). Bien que cette méthode fonctionne bien, il est recommandé de la réserver aux situations impliquant l'installation complexe de plusieurs fichiers. Reportez-vous à Modification de fichiers crontab au cours de l'installation.
Le programme sed utilisé dans Modification d'un fichier à l'aide de la classe sed et d'un script postinstall prend en charge plusieurs instances d'un package puisque le commentaire situé à la fin de l'entrée inittab se base sur l'instance d'un package. L'étude de cas de la rubrique Modification d'un fichier à l'aide de la classe build illustre une démarche plus rationalisée de modification du fichier /etc/inittab pendant l'installation.
PKG=case5 NAME=Case Study #5 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=inittab |
i pkginfo i i.inittab i r.inittab e inittab /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 sed -e "s/$/#$PKGINST" $src >> /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done if [ "$1" = ENDOFCLASS ] then /sbin/init q || exit 2 fi exit 0 |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done /sbin/init q || exit 2 exit 0 |
rb:023456:wait:/usr/robot/bin/setup |
Cette étude de cas modifie un fichier présent sur la machine d'installation lors de l'installation du package. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe build. Le fichier modifié est /etc/inittab.
Cette étude de cas illustre les techniques suivantes :
Utilisation de la classe sed
Pour plus d'informations sur la classe sed, reportez-vous à Script de classe sed.
Utilisation d'un script postinstall
Pour plus d'informations sur ce script, reportez-vous à Rédaction de scripts de procédure.
Pour modifier /etc/inittab lors de l'installation à l'aide de la classe sed, vous devez effectuer les opérations suivantes :
Ajoutez le script de la classe sed dans le fichier prototype.
Le nom du script doit être le nom du fichier à modifier. Dans l'exemple, le fichier à modifier est /etc/inittab et le script sed est de ce fait nommé /etc/inittab. Les champs mode, owner et groupe d'un script sed n'ont aucune spécification (ce qui est indiqué dans l'exemple prototype par des points d'interrogation). Le type de fichier du script sed doit être e (indiquant qu'il s'agit d'un fichier modifiable).
Incluez dans le paramètre CLASSES la classe sed.
Comme l'illustre l'exemple de fichier, sed est la seule classe à installer. Il pourrait cependant s'agir de bien d'autres classes.
Créer un script d'action de classe sed.
Votre package ne peut pas fournir de copie de /etc/inittab à l'apparence souhaitée, car /etc/inittab est un fichier dynamique ; il est donc impossible de prévoir son apparence à l'installation du package. Toutefois, l'utilisation d'un script sed vous permet de modifier le fichier /etc/inittab lors de l'installation du package.
Créez un script postinstall.
Vous devez exécuter la commande init q pour informer le système que le fichier /etc/inittab a été modifié. Dans l'exemple, cette opération ne peut être effectuée que dans un script postinstall. En examinant l'exemple du script postinstall, vous remarquerez que son seul objectif est d'exécuter la commande initq.
Cette démarche de modification du fichier /etc/inittab lors de l'installation présente un inconvénient ; elle nécessite un script complet (le script postinstall) pour la simple exécution de la commande init q.
PKG=case4 NAME=Case Study #4 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=sed |
i pkginfo i postinstall e sed /etc/inittab ? ? ? |
!remove # remove all entries from the table that are associated # with this package, though not necessarily just # with this package instance /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d !install # remove any previous entry added to the table # for this particular change /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d # add the needed entry at the end of the table; # sed(1) does not properly interpret the '$a' # construct if you previously deleted the last # line, so the command # $a\ # rb:023456:wait:/usr/robot/bin/setup #ROBOT # will not work here if the file already contained # the modification. Instead, you will settle for # inserting the entry before the last line! $i\ rb:023456:wait:/usr/robot/bin/setup #ROBOT |
# make init re-read inittab /sbin/init q || exit 2 exit 0 |
Cette étude de cas modifie un fichier présent sur la machine d'installation lors de l'installation du package. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Le fichier modifié est /etc/inittab.
Cette étude de cas illustre l'utilisation de la classe build. Pour plus d'informations sur la classe build, reportez-vous à Script de classe build.
Cette démarche de modification du fichier /etc/inittab utilise la classe build. Un script de classe build est exécuté comme un script shell et son résultat devient la nouvelle version du fichier exécuté. Autrement dit, le fichier de données /etc/inittab fourni avec ce package est exécuté et le résultat de cette exécution devient /etc/inittab.
Le script de classe build est exécuté lors de l'installation et de la suppression du package. L'argument install est transmis au fichier s'il est exécuté lors de la phase d'installation. Remarquez dans l'exemple de script de classe build que la procédure d'installation est définie en testant cet argument.
Pour modifier /etc/inittab à l'aide de la classe build, vous devez effectuer les opérations suivantes :
Définir le fichier de version dans le fichier prototype.
L'entrée correspondant au fichier de version dans le fichier prototype doit le placer dans la classe build et définir son type de fichier comme étant e. Vérifiez que la valeur du paramètre CLASSES figurant dans le fichier pkginfo est build.
Créer le script de classe build.
L'exemple de script de classe build effectue les procédures suivantes :
Il modifie le fichier /etc/inittab pour modifier toute modification apportée à ce package. Remarquez que le nom de fichier /etc/inittab est codé en dur dans la commande sed.
Si l'installation du package est en cours, il ajoute le nouvelle ligne à la fin du fichier /etc/inittab. La nouvelle entrée inclut une balise de commentaire qui indique sa provenance.
Il exécute la commande init q.
Cette solution résout les inconvénients décrits dans les études de cas des rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Seul un bref fichier est nécessaire (outre les fichiers pkginfo et prototype). Le fichier fonctionne avec plusieurs instances d'un package puisque le paramètre PKGINST est utilisé ; par ailleurs, aucun script postinstall n'est requis puisque la commande init q peut être exécutée à partir du script de classe build.
PKG=case6 NAME=Case Study #6 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=build |
i pkginfo e build /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service # remove all entries from the existing table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab || exit 2 if [ "$1" = install ] then # add the following entry to the table echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" || exit 2 fi /sbin/init q || exit 2 exit 0 |
Cette étude de cas modifie les fichiers crontab lors de l'installation du package.
Cette étude de cas illustre les techniques suivantes :
Utilisation de classes et de scripts d'action de classe
Pour plus d'informations, reportez-vous à Rédaction de scripts d'action de classe.
Utilisation de la commande crontab dans un script d'action de classe.
La manière la plus efficace de modifier plusieurs fichiers lors de l'installation consiste à définir une classe et à fournir un script d'action de classe. Si vous avez utilisé la démarche de la classe build, vous devez fournir un script de classe build pour chaque fichier crontab modifié. La définition d'une classe cron représente une démarche plus globale. Pour modifier les fichiers crontaben suivant cette démarche, vous devez effectuer les opérations suivantes :
Définir les fichiers crontab à modifier dans le fichier prototype.
Créez une entrée dans le fichier prototype pour chaque fichier crontab à modifier. Définissez cron comme classe et e comme type de fichier de chaque fichier. Utilisez le nom réel du fichier à modifier.
Créer les fichiers crontab du package.
Ces fichiers contiennent les informations à ajouter aux fichiers crontab actuels du même nom.
Créer un script d'action de classe d'installation pour la classe cron.
L'exemple de script de classe i.cron effectue les procédures suivantes :
Il détermine l'ID utilisateur (UID).
Le script i.cron définit la variable user sur le nom de base du script de classe cron traité. Ce nom est l'UID. Par exemple, le nom de base de /var/spool/cron/crontabs/root est root, qui est également l'UID.
Il exécute la commande crontab, en se servant de l'UID et de l'option - l.
L'utilisation de l'option -l indique à crontab de transmettre dans le résultat standard, le contenu du fichier crontab de l'utilisateur défini.
Il envoie le résultat de la commande crontab dans un script sed qui supprime toute entrée ajoutée précédemment par cette technique d'installation.
Il place le résultat modifié dans un fichier temporaire.
Il ajoute le fichier de données de l'UID root (fourni avec le package) dans le fichier temporaire et insère une balise indiquant la provenance des entrées.
Il exécute la commande crontab avec le même UID et lui transmet les fichiers temporaires comme entrée.
Créer un script d'action de classe de suppression pour la classe cron.
Le script r.cron est identique au script d'installation à ceci près qu'il n'existe pas de procédure pour ajouter des informations dans le fichier crontab.
Ces procédures sont effectuées pour chaque fichier de la classe cron.
Les scripts i.cron et r.cron décrits ci-après sont exécutés par le superutilisateur. Modifier le fichier crontab d'un autre superutilisateur peut avoir des conséquences imprévisibles. Si nécessaire, remplacez l'entrée suivante de chaque script :
crontab $user < /tmp/$$crontab ||
par celle-ci :
su $user -c "crontab /tmp/$$crontab" ||
PKG=case7 NAME=Case Study #7 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 1.0 CLASSES=cron |
i pkginfo i i.cron i r.cron e cron /var/spool/cron/crontabs/root ? ? ? e cron /var/spool/cron/crontabs/sys ? ? ? |
# PKGINST parameter provided by installation service while read src dest do user=`basename $dest` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 sed -e "s/$/#$PKGINST/" $src >> /tmp/$$crontab || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit 0 |
# PKGINST parameter provided by installation service while read path do user=`basename $path` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit |
41,1,21 * * * * /usr/lib/uucp/uudemon.hour > /dev/null 45 23 * * * ulimit 5000; /usr/bin/su uucp -c "/usr/lib/uucp/uudemon.cleanup" > /dev/null 2>&1 11,31,51 * * * * /usr/lib/uucp/uudemon.poll > /dev/null |
0 * * * 0-6 /usr/lib/sa/sa1 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A |
Si la modification d'un groupe de fichiers augmente la taille globale des fichiers de plus de 10 Ko, fournissez un fichier space pour que la commande pkgadd puisse accommoder cette augmentation. Pour plus d'informations sur le fichier space, reportez-vous à Réservation d'espace supplémentaire sur un système cible.
Ce package installe un pilote.
Cette étude de cas illustre les techniques suivantes :
Installation et chargement d'un pilote à l'aide d'un script postinstall
Déchargement d'un pilote à l'aide d'un script preremove
Pour plus d'informations sur ces scripts, reportez-vous à Rédaction de scripts de procédure.
Créer un script request.
Le script request détermine l'emplacement d'installation des objets du pilote en interrogeant l'administrateur et en appliquant la réponse obtenue au paramètre $KERNDIR.
Le script se termine par une routine permettant de mettre les deux paramètres CLASSES et KERNDIR à disposition de l'environnement d'installation et du script postinstall.
Créez un script postinstall.
Le script postinstall effectue l'installation du pilote. Il est exécuté une fois que les deux fichiers buffer et buffer.conf sont installés. Le fichier postinstall illustré dans cet exemple effectue les opérations suivantes :
Il utilise la commande add_drv pour charger le pilote sur le système.
Il crée un lien vers le périphérique à l'aide de la commande installf.
Il termine l'installation à l'aide de la commande installf -f.
Il crée un script preremove.
Le script preremove utilise la commande rem_drv pour décharger le pilote du système, puis supprime le lien /dev/buffer0 .
PKG=bufdev NAME=Buffer Device CATEGORY=system BASEDIR=/ ARCH=INTEL VERSION=Software Issue #19 CLASSES=none |
Pour installer un pilote lors de l'installation, vous devez inclure les fichiers d'objets et de configuration du pilote dans le fichier prototype.
Dans cet exemple, le module exécutable du pilote est nommé buffer ; la commande add_drv opère sur ce fichier. Le noyau utilise le fichier de configuration, buffer.conf pour aider à configurer le pilote.
i pkginfo i request i postinstall i preremove f none $KERNDIR/buffer 444 root root f none $KERNDIR/buffer.conf 444 root root |
Remarquez les points suivants dans le fichier prototype de cet exemple :
Les objets du package ne nécessitant aucun traitement particulier, vous pouvez les placer dans la classe standard none. Le paramètre CLASSES est défini sur none dans le fichier pkginfo.
Les noms de chemin de buffer et buffer.conf commencent par la variable $KERNDIR. Cette variable est définie dans le script request et permet à l'administrateur de choisir l'emplacement d'installation des pilotes. Le répertoire par défaut est /kernel/drv.
Le script postinstall (script effectuant l'installation du pilote) dispose d'une entrée.
trap 'exit 3' 15 # determine where driver object should be placed; location # must be an absolute path name that is an existing directory KERNDIR=`ckpath -aoy -d /kernel/drv -p \ “Where do you want the driver object installed”` || exit $? # make parameters available to installation service, and # so to any other packaging scripts cat >$1 <<! CLASSES='$CLASSES' KERNDIR='$KERNDIR' ! exit 0 |
# KERNDIR parameter provided by `request' script err_code=1 # an error is considered fatal # Load the module into the system cd $KERNDIR add_drv -m '* 0666 root sys' buffer || exit $err_code # Create a /dev entry for the character node installf $PKGINST /dev/buffer0=/devices/eisa/buffer*:0 s installf -f $PKGINST |
err_code=1 # an error is considered fatal # Unload the driver rem_drv buffer || exit $err_code # remove /dev file removef $PKGINST /dev/buffer0 ; rm /dev/buffer0 removef -f $PKGINST |
Cette étude de cas décrit l'installation d'un pilote à l'aide de la classe sed et de scripts de procédure. Elle diffère par ailleurs de l'étude de cas précédente (reportez-vous à Installation et suppression d'un pilote à l'aide de scripts de procédure) sur le fait que ce package est composé à la fois d'objets absolus et d'objets réadressables.
Cette étude de cas illustre les techniques suivantes :
Création d'un fichier prototype contenant des objets absolus et des objets réadressables.
Pour plus d'informations sur la création d'un fichier prototype, reportez-vous à Création d'un fichier prototype.
Utilisation d'un script postinstall
Pour plus d'informations sur ce script, reportez-vous à Rédaction de scripts de procédure.
Utilisation d'un script preremove
Pour plus d'informations sur ce script, reportez-vous à Rédaction de scripts de procédure.
Utilisation d'un fichier copyright
Pour plus d'informations sur ce fichier, reportez-vous à Rédaction d'un message de copyright.
Créez un fichier prototype contenant des objets de package absolus et des objets de package réadressables.
La procédure est abordée en détail à la rubrique Fichier prototype.
Ajoutez le script de la classe sed dans le fichier prototype.
Le nom du script doit être le nom du fichier à modifier. Dans l'exemple, le fichier à modifier est /etc/devlink.tab et le script sed est de ce fait nommé /etc/devlink.tab. Les champs mode, owner et groupe d'un script sed n'ont aucune spécification (ce qui est indiqué dans l'exemple prototype par des points d'interrogation). Le type de fichier du script sed doit être e (indiquant qu'il s'agit d'un fichier modifiable).
Incluez dans le paramètre CLASSES la classe sed.
Créez un script d'action de classe sed ( /etc/devlink.tab ).
Créez un script postinstall.
Le script postinstall doit exécuter la commande add_drv pour ajouter le pilote du périphérique sur le système.
Créez un script preremove.
Le script preremove doit exécuter la commande rem_drv pour supprimer le pilote du périphérique du système avant la suppression du package.
Créez un fichier copyright.
Un fichier copyright contient le texte ASCII d'un message de copyright. Le message illustré dans l'exemple de fichier s'affiche à l'écran lors de l'installation du package.
PKG=SUNWsst NAME=Simple SCSI Target Driver VERSION=1 CATEGORY=system ARCH=sparc VENDOR=Sun Microsystems BASEDIR=/opt CLASSES=sed |
Par exemple, cette étude de cas utilise la structure hiérarchique des objets de package illustrée ci-après.
Les objets du package sont installés dans les mêmes fichiers que sur l'illustration du répertoire pkg ci-dessus. Les modules du pilote ( sst et sst.conf) sont installés dans /usr/kernel/drv et le fichier include est installé dans /usr/include/sys/scsi/targets. Les fichiers sst, sst.conf et sst_def.h sont des objets absolus. Le programme test sstest.c et son répertoire SUNWsst sont tous deux réadressables ; leur emplacement d'installation est défini par le paramètre BASEDIR.
Les autres composants du package (tous les fichiers de contrôle) doivent être placés dans le répertoire supérieur du package sur la machine de développement, à l'exception du script de la classe sed . Celui-ci est appelé devlink.tab d'après le nom du fichier qu'il modifie et doit être placé dans etc, répertoire contenant le vrai fichier devlink.tab.
À partir du répertoire pkg, exécutez la commande pkgproto comme suit :
find usr SUNWsst -print | pkgproto > prototype |
Le résultat de la commande ci-dessus est comme suit :
d none usr 0775 pms mts d none usr/include 0775 pms mts d none usr/include/sys 0775 pms mts d none usr/include/sys/scsi 0775 pms mts d none usr/include/sys/scsi/targets 0775 pms mts f none usr/include/sys/scsi/targets/sst_def.h 0444 pms mts d none usr/kernel 0775 pms mts d none usr/kernel/drv 0775 pms mts f none usr/kernel/drv/sst 0664 pms mts f none usr/kernel/drv/sst.conf 0444 pms mts d none SUNWsst 0775 pms mts f none SUNWsst/sstest.c 0664 pms mts |
Le fichier prototype n'est pas encore terminé. Pour terminer le fichier, vous devez lui apporter les modifications suivantes :
Insérez les entrées pour les fichiers de contrôle (type de fichier i) car ils utilisent un format différent des autres objets de package.
Supprimez les entrées correspondant aux répertoires qui se trouvent déjà sur le système cible.
Modifiez les droits d'accès et la propriété de chaque entrée.
Préfixez le nom des objets de package absolus d'une barre oblique.
Fichier prototype final :
i pkginfo i postinstall i preremove i copyright e sed /etc/devlink.tab ? ? ? f none /usr/include/sys/scsi/targets/sst_def.h 0644 bin bin f none /usr/kernel/drv/sst 0755 root sys f none /usr/kernel/drv/sst.conf 0644 root sys d none SUNWsst 0775 root sys f none SUNWsst/sstest.c 0664 root sys |
Les points d'interrogation de l'entrée correspondant au script sed indiquent que les droits d'accès et la propriété du fichier présent sur la machine d'installation ne doivent pas être modifiés.
Dans l'exemple de pilote, un script de classe sed est utilisé pour ajouter une entrée correspondant au pilote dans le fichier /etc/devlink.tab. Ce fichier est utilisé par la commande devlinks pour créer des liens symboliques de /dev à /devices. Script sed :
# sed class script to modify /etc/devlink.tab !install /name=sst;/d $i\ type=ddi_pseudo;name=sst;minor=character rsst\\A1 !remove /name=sst;/d |
La commande pkgrm n'exécute pas la partie du script correspondant à la suppression. Il s'avère parfois nécessaire d'ajouter une ligne au script preremove afin d'exécuter sed directement pour supprimer l'entrée du fichier /etc/devlink.tab.
Dans cet exemple, il suffit au script d'exécuter la commande add_drv.
# Postinstallation script for SUNWsst # This does not apply to a client. if [$PKG_INSTALL_ROOT = "/" -o -z $PKG_INSTALL_ROOT]; then SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/add_drv sst STATUS=$? BASEDIR=$SAVEBASE; export BASEDIR if [ $STATUS -eq 0 ] then exit 20 else exit 2 fi else echo "This cannot be installed onto a client." exit 2 fi |
La commande add_drv utilise le paramètre BASEDIR ; le script doit pour cette raison annuler la valeur définie pour BASEDIR avant d'exécuter la commande et la rétablir après l'exécution.
Une des opérations effectuées par la commande add_drv est l'exécution de devlinks qui utilise l'entrée placée dans /etc/devlink.tab par le script de classe sed pour créer les entrées /dev correspondant au pilote.
Le code de sortie du script postinstall est significatif. Le code de sortie 20 indique à la commande pkgadd de demander à l'utilisateur de réinitialiser le système (opération nécessaire après l'installation d'un pilote) et le code de sortie 2 indique à la commande pkgadd d'informer l'utilisateur que l'installation a partiellement échoué.
Dans cet exemple de pilote, il supprime les liens figurant dans /dev et exécute la commande rem_drv sur le pilote.
# Pre removal script for the sst driver echo “Removing /dev entries” /usr/bin/rm -f /dev/rsst* echo “Deinstalling driver from the kernel” SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/rem_drv sst BASEDIR=$SAVEBASE; export BASEDIR exit |
Le script supprime lui-même les entrées /dev alors que les entrées /devices sont supprimées par la commande rem_drv.
Ce fichier est un simple fichier ASCII contenant le texte d'un avis de copyright. L'avis s'affiche au début de l'installation du package tel qu'il apparaît dans le fichier.
Copyright (c) 1999 Drivers-R-Us, Inc. 10 Device Drive, Thebus, IO 80586 All rights reserved. This product and related documentation is protected by copyright and distributed under licenses restricting its use, copying, distribution and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Drivers-R-Us and its licensors, if any. |