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)
Création de fichiers d'information et de scripts d'installation (liste de tâches)
Création de fichiers d'information
Définition des dépendances d'un package
Définition des dépendances d'un package
Rédaction d'un message de copyright
Rédaction d'un message de copyright
Réservation d'espace supplémentaire sur un système cible
Réservation d'espace supplémentaire sur un système cible
Création de scripts d'installation
Traitement des scripts pendant l'installation d'un package
Traitement des scripts pendant la suppression d'un package
Variables d'environnement de package mises à la disposition des scripts
Obtention d'informations sur un package pour un script
Comportements du script request
Règles de conception pour les scripts request
Recueil de données d'un système de fichiers à l'aide du script checkinstall
Comportements du script checkinstall
Règles de conception pour les scripts checkinstall
Recueil de données d'un système de fichiers
Rédaction de scripts de procédure
Comportements des scripts de procédure
Règles de conception des scripts de procédure
Rédaction de scripts de procédure
Rédaction de scripts d'action de classe
Définition de classes d'objets
Traitement des classes pendant l'installation d'un package
Traitement des classes pendant la suppression d'un package
Comportements des scripts d'action de classe
Ajout de certificats de confiance au keystore de package
Ajout d'un certificat utilisateur et d'une clé privée au keystore de package
Vérification du keystore de package
Suppression de certificats de confiance et de clés privées du keystore d'un package
Création d'un package non signé au format répertoire
Importation des certificats dans le keystore de package
4. Vérification et transfert d'un package
5. Création d'un package : Etudes de cas
Cette section décrit les scripts d'installation de package facultatifs. La commande pkgadd effectue automatiquement toutes les opérations nécessaires pour installer un package à l'aide de fichiers d'information de package comme entrée. Il n'est pas nécessaire de fournir des scripts d'installation de package. Toutefois, pour créer des procédures d'installation personnalisées pour votre package, vous pouvez faire appel à des scripts d'installation. Scripts d'installation :
Ils doivent pouvoir être exécutés par Bourne shell (sh).
Ils doivent contenir des commandes Bourne shell et du texte.
Ils ne doivent pas nécessairement contenir l'identifiant shell #!/bin/sh.
Ils ne doivent pas nécessairement s'agir de fichiers exécutables.
Il existe quatre types de scripts d'installation vous permettant d'effectuer des opérations personnalisées :
Le script request demande des données à l'administrateur qui installe un package afin d'attribuer ou de redéfinir des variables d'environnement.
Le script checkinstall examine le système cible à la recherche des données nécessaires, peut définir ou modifier les variables d'environnement du package et détermine si l'installation peut avoir lieu.
Remarque - Le script checkinstall est disponible depuis la version 2.5 de Solaris et versions compatibles.
Les scripts de procédure identifient la procédure à appeler avant ou après l'installation ou la suppression d'un package. Les quatre scripts de procédure sont preinstall, postinstall, preremove et postremove.
Les scripts d'action de classe définissent une action ou un groupe d'actions à appliquer à une classe de fichiers lors de l'installation ou de la suppression. Vous pouvez définir vos propres classes. Vous pouvez aussi utiliser l'une des quatre classes standard (sed, awk, build et preserve).
Le type de scripts à utiliser dépend du stade de la procédure d'installation auquel l'action du script est requise. Pendant l'installation d'un package, la commande pkgadd effectue les opérations suivantes :
Elle exécute le script request.
Cette opération est la seule au cours de laquelle votre package peut demander la participation de l'administrateur chargé d'installer le package .
Elle exécute le script checkinstall.
Le script checkinstall recueille les données du système de fichiers et peut créer ou modifier la définition des variables d'environnement afin de contrôler l'installation ultérieure. Pour plus d'informations sur les variables d'environnement d'un package, reportez-vous à Variables d'environnement d'un package.
Elle installe les objets de package de chaque classe à installer.
L'installation de ces fichiers s'effectue classe par classe et les scripts d'action de classe sont exécutés en conséquence. La liste des classes employées et l'ordre dans lequel elles doivent être installées sont initialement définis avec le paramètre CLASSES dans votre fichier pkginfo. Toutefois, votre script request ou checkinstall peut modifier la valeur du paramètre CLASSES. Pour plus d'informations sur le traitement des classes pendant l'installation, reportez-vous à Traitement des classes pendant l'installation d'un package.
Crée des liens symboliques, des périphériques, des tubes nommés et les répertoires requis.
Installe les fichiers standard (fichiers de type e, v, f), en fonction de leur classe.
Seuls les fichiers standard à installer sont transmis au script d'action de classe. Tous les autres objets de package sont créés automatiquement à partir des informations figurant dans le fichier pkgmap.
Crée tous les liens physiques.
Lors de la suppression d'un package, la commande pkgrm effectue les opérations suivantes :
Elle supprime les objets de package de chaque classe.
La suppression s'effectue également classe par classe. Les scripts de suppression sont traités dans l'ordre inverse de l'installation, en fonction de la séquence définie dans le paramètre CLASSES. Pour plus d'informations sur le traitement des classes pendant l'installation, reportez-vous à Traitement des classes pendant l'installation d'un package.
Supprime les liens physiques.
Supprime les fichiers standard.
Supprime les liens symboliques, les périphériques et les tubes nommés.
Le script request n'est pas traité lors de la suppression d'un package. Toutefois, le résultat du script est conservé dans le package installé et mis à la disposition des scripts de suppression. Le résultat du script request est une liste de variables d'environnement.
Les groupes suivants de variables d'environnement sont mis à la disposition de tous les scripts d'installation. Certaines variables d'environnement peuvent être modifiées par un script request ou un script checkinstall.
Le script request ou le script checkinstall peut définir ou modifier tout paramètre standard contenu dans le fichier pkginfo, à l'exception des paramètres obligatoires. Les paramètres d'installation standard sont décrits en détail à la page de manuel pkginfo(4).
Remarque - Le paramètre BASEDIR ne peut être modifié qu'à partir de la version 2.5 de Solaris et des versions compatibles.
Vous pouvez définir vos propres variables d'environnement d'installation en leur attribuant des valeurs dans le fichier pkginfo. Ces variables d'environnement doivent être alphanumériques et commencer par une majuscule. Ces variables d'environnement peuvent être modifiées par un script request ou un script checkinstall.
Le script request et le script checkinstall peuvent tous deux définir des variables d'environnement en leur attribuant des valeurs et en les plaçant dans l'environnement d'installation.
Le tableau suivant répertorie les variables d'environnement mises à la disposition de tous les scripts d'installation via l'environnement. Aucune de ces variables d'environnement ne peut être modifiée par un script.
|
Deux commandes peuvent être utilisées à partir de scripts pour demander des informations sur un package :
La commande pkginfo renvoie des informations sur les packages, notamment l'identificateur de l'instance et le nom du package.
La commande pkgparam renvoie des valeurs pour les variables d'environnement demandées.
Reportez-vous aux pages de manuel pkginfo(1) et pkgparam(1), ainsi qu'au Chapitre 4, Vérification et transfert d'un package pour plus d'informations.
Chaque script doit quitter son exécution avec l'un des codes de sortie figurant dans le tableau suivant.
Tableau 3-2 Codes de sortie des scripts d'installation
|
Reportez-vous au Chapitre 5, Création d'un package : Etudes de cas pour consulter des exemples de codes de sortie renvoyés par les scripts d'installation.
Remarque - Tous les scripts d'installation fournis avec votre package doivent disposer d'une entrée dans le fichier prototype. Le type de fichier doit être i (script d'installation de package).
Le script request est le seul moyen d'interaction directe avec l'administrateur chargé d'installer le package. Ce script peut être utilisé par exemple pour demander à l'administrateur s'il souhaite installer certains des éléments facultatifs du package.
Le résultat du script request doit être une liste de variables d'environnement et de leurs valeurs. Cette liste peut inclure tout paramètre créé dans le fichier pkginfo, ainsi que les paramètres CLASSES et BASEDIR. La liste peut également introduire des variables d'environnement non définies ailleurs. Toutefois et dans la mesure du possible, les valeurs par défaut.le doivent toujours être fournies par le fichier pkginfo . Pour plus d'informations sur les variables d'environnement d'un package, reportez-vous à Variables d'environnement d'un package.
Lorsque votre script request attribue des valeurs à une variable d'environnement, il doit par la suite mettre ces valeurs à la disposition de la commande pkgadd et des autres scripts du package.
Le script request ne peut modifier aucun fichier. Ce script ne dialogue qu'avec l'administrateur qui installe le package et crée une liste d'attribution de variables d'environnement basée sur cette interaction. Le script request s'exécute en tant qu'utilisateur non privilégié noaccess si ce dernier existe. Si tel n'est pas le cas, le script est exécuté en tant qu'utilisateur root.
La commande pkgadd appelle le script request avec un argument nommant le fichier réponse du script. Le fichier réponse stocke les réponses de l'administrateur.
Le script request n'est pas exécuté pendant la suppression du package. Toutefois, les variables d'environnement attribuées par le script sont enregistrées et disponibles au cours de la suppression du package.
Un seul script request est autorisé par package. Le script doit être nommé request.
Les attributions de variables d'environnement doivent être ajoutées à l'environnement d'installation pour que la commande pkgadd et d'autres scripts d'empaquetage puissent les utiliser en les enregistrant dans le fichier réponse (connu du script sous le nom $1).
Les variables d'environnement système et les variables d'environnement d'installation standard, à l'exception des paramètres CLASSES et BASEDIR, ne peuvent pas être modifiées par un script request. Toute variable d'environnement créée par vous peut être modifiée.
Remarque - Un script request peut modifier le paramètre BASEDIR depuis la version 2.5 de Solaris et versions compatibles uniquement.
Une valeur par défaut doit être attribuée dans le fichier pkginfo à toute variable d'environnement susceptible d'être manipulée par le script request.
Le format de la liste de résultats est PARAM=value. Par exemple :
CLASSES=none class1
Le terminal de l'administrateur est défini comme entrée standard pour le script request.
N'effectuez pas d'analyses spéciales du système cible dans un fichier request. Il est risqué de tester le système pour déterminer l'éventuelle présence de certains fichiers binaires ou de certains comportements, et de définir des variables d'environnement en fonction de cette analyse. Il n'existe aucune garantie quant à l'exécution du script request lors de la phase d'installation. L'administrateur chargé d'installer le package peut fournir un fichier réponse dont le rôle est d'insérer les variables d'environnement sans jamais appeler le script request. Si le script request évalue aussi le système de fichiers cible, cette évaluation risque de ne pas avoir lieu. Il est recommandé de confier l'analyse du système cible à des fins particulières au script checkinstall.
Remarque - Si les administrateurs chargés d'installer votre package utilisent le produit JumpStart, l'installation du package ne doit pas être interactive. Vous pouvez au choix, ne pas fournir de script request avec votre package ou, indiquer aux administrateurs qu'ils doivent exécuter la commande pkgask avant l'installation. La commande pkgask stocke les réponses fournies au script request. Pour plus d'informations sur la commande pkgask, reportez-vous à la page de manuel pkgask(1M).
Pour créer des scripts d'installation supplémentaires, passez à l'opération suivante, Recueil de données d'un système de fichiers.
Si vous n'avez pas créé de fichier prototype, suivez la procédure Création d'un fichier prototype à l'aide de la commande pkgproto. Passez à l'Étape 5.
Si vous avez déjà créé un fichier prototype, modifiez-le en ajoutant une entrée pour le script d'installation qui vient d'être créé.
Si nécessaire, reportez-vous à la rubrique Création d'un package.
Exemple 3-5 Rédaction d'un script request
Lorsqu'un script request attribue des valeurs à des variables d'environnement, il doit mettre ces valeurs à la disposition de la commande pkgadd. Cet exemple illustre le segment d'un script request qui effectue cette opération pour les quatre variables d'environnement : CLASSES, NCMPBIN, EMACS et NCMPMAN. Supposons que ces variables ont été définies lors d'une session interactive avec l'administrateur au début du script.
# make environment variables available to installation # service and any other packaging script we might have cat >$1 <<! CLASSES=$CLASSES NCMPBIN=$NCMPBIN EMACS=$EMACS NCMPMAN=$NCMPMAN !
Voir aussi
Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre 4, Vérification et transfert d'un package explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un média de distribution.
Le script checkinstall est exécuté peu de temps après le script request facultatif. Le script checkinstall s'exécute en tant qu'utilisateur noaccess, si celui-ci existe. Le script checkinstall ne dispose pas des droits nécessaires pour modifier les données du système de fichiers. Il peut cependant, en fonction des informations qu'il recueille, créer ou modifier des variables d'environnement afin de contrôler la procédure d'installation résultante. Le script est également capable de procéder à un arrêt net de la procédure d'installation.
Le script checkinstall a pour rôle d'effectuer des contrôles de base sur un système de fichiers, contrôles inhabituels pour la commande pkgadd. Ce script peut par exemple être utilisé pour déterminer à l'avance si certains fichiers du package actuel vont écraser des fichiers existants, ou pour gérer les dépendances globales des logiciels. Le fichier depend ne gère que les dépendances au niveau du package.
A l'inverse du script request, le script checkinstall est exécuté qu'un fichier réponse soit fourni ou non. La présence du script ne qualifie pas le package d'interactif. Le script checkinstall peut être des situations où un script request est interdit ou que l'interaction avec l'administrateur n'est pas pratique.
Remarque - Le script checkinstall est disponible depuis la version 2.5 de Solaris et versions compatibles.
Le script checkinstall ne peut modifier aucun fichier. Ce script analyse simplement l'état du système et crée une liste d'attribution de variables d'environnement basée sur cette interaction. Afin d'appliquer cette restriction, le script checkinstall est exécuté en tant qu'utilisateur non privilégié noaccess, si celui-ci existe. Sinon, le script est exécuté en tant qu'utilisateur non privilégié nobody. Le script checkinstall ne dispose pas des droits de superutilisateur.
La commande pkgadd appelle le script checkinstall avec un argument nommant le fichier réponse du script. Le fichier réponse du script est le fichier dans lequel les réponses de l'administrateur sont stockées.
Le script checkinstall n'est pas exécuté pendant la suppression du package. Toutefois, les variables d'environnement attribuées par le script sont enregistrées et disponibles au cours de la suppression du package.
Un seul script checkinstall est autorisé par package. Le script doit être nommé checkinstall.
Les attributions de variables d'environnement doivent être ajoutées à l'environnement d'installation pour que la commande pkgadd et d'autres scripts d'empaquetage puissent les utiliser en les enregistrant dans le fichier réponse (connu du script sous le nom $1).
Les variables d'environnement système et les variables d'environnement d'installation standard, à l'exception des paramètres CLASSES et BASEDIR, ne peuvent pas être modifiées par un script checkinstall. Toute variable d'environnement créée par vous peut être modifiée.
Une valeur par défaut doit être attribuée dans le fichier pkginfo à toute variable d'environnement susceptible d'être manipulée par le script checkinstall.
Le format de la liste de résultats est PARAM=value. Par exemple :
CLASSES=none class1
L'interaction avec l'administrateur n'est pas autorisée pendant l'exécution d'un script checkinstall. L'interaction avec l'administrateur se limite au script request.
Pour créer des scripts d'installation supplémentaires, passez à l'étape suivante, Rédaction de scripts de procédure.
Si vous n'avez pas créé de fichier prototype, suivez la procédure Création d'un fichier prototype à l'aide de la commande pkgproto. Passez à l'Étape 5.
Si vous avez déjà créé un fichier prototype, modifiez-le en ajoutant une entrée pour le script d'installation qui vient d'être créé.
Si nécessaire, reportez-vous à la rubrique Création d'un package.
Exemple 3-6 Rédaction d'un script checkinstall
Cet exemple de script checkinstall vérifie que le logiciel de base de données requis par le package SUNWcadap est installé.
# checkinstall script for SUNWcadap # # This confirms the existence of the required specU database # First find which database package has been installed. pkginfo -q SUNWspcdA # try the older one if [ $? -ne 0 ]; then pkginfo -q SUNWspcdB # now the latest if [ $? -ne 0 ]; then # oops echo "No database package can be found. Please install the" echo "SpecU database package and try this installation again." exit 3 # Suspend else DBBASE="`pkgparam SUNWsbcdB BASEDIR`/db" # new DB software fi else DBBASE="`pkgparam SUNWspcdA BASEDIR`/db" # old DB software fi # Now look for the database file we will need for this installation if [ $DBBASE/specUlatte ]; then exit 0 # all OK else echo "No database file can be found. Please create the database" echo "using your installed specU software and try this" echo "installation again." exit 3 # Suspend fi
Voir aussi
Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre 4, Vérification et transfert d'un package explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un média de distribution.
Les scripts de procédure fournissent la liste d'instructions à suivre à certains stades de l'installation ou de la suppression d'un package. Les quatre scripts de procédure doivent porter un des noms prédéfinis liés au stade de l'exécution des instructions. Les scripts sont exécutés sans arguments.
Ce script est exécuté avant le début de l'installation des classes. Ce script ne doit installer aucun fichier.
Ce script est exécuté une fois tous les volumes installés.
Ce script est exécuté avant le début de la suppression des classes. Ce script ne doit supprimer aucun fichier.
Ce script est exécuté après la suppression de toutes les classes.
Les scripts de procédure sont exécutés en tant que uid=root et gid=other.
Chaque script doit pouvoir être exécuté plusieurs fois puisqu'il est exécuté pour chaque volume d'un package. L'exécution répétée d'un script à partir de la même entrée produit ainsi les mêmes résultats que si le script était exécuté une seule fois.
Chaque script de procédure installant un objet de package dans un fichier autre que pkgmap doit faire appel à la commande installf pour avertir la base de données du package qu'il ajoute ou modifie un nom de chemin. Une fois tous les ajouts et modifications terminés, cette commande doit être appelée avec l'option -f. Seuls les scripts postinstall et postremove peuvent installer les objets de package de cette façon. Reportez-vous à la page de manuel installf(1M) et au Chapitre 5, Création d'un package : Etudes de cas pour plus d'informations.
L'interaction avec l'administrateur n'est pas autorisée lors de l'exécution d'un script de procédure. L'interaction avec l'administrateur se limite au script request.
Chaque script de procédure supprimant des fichiers non installés du fichier pkgmap doit se servir de la commande removef pour avertir la base de données du package qu'il supprime un nom de chemin. Une fois la suppression terminée, cette commande doit être appelée avec l'option -f. Reportez-vous à la page de manuel removef(1M) et au Chapitre 5, Création d'un package : Etudes de cas pour plus d'informations et quelques exemples.
Remarque - Les commandes installf et removef doivent être utilisées car les scripts de procédure ne sont pas automatiquement associés aux noms de chemin répertoriés dans le fichier pkgmap.
Un script de procédure doit porter l'un des noms prédéfinis suivants : preinstall, postinstall, preremove ou postremove.
Pour créer des scripts d'action de classe, passez à l'opération suivante, Rédaction de scripts d'action de classe.
Si vous n'avez pas créé de fichier prototype, suivez la procédure Création d'un fichier prototype à l'aide de la commande pkgproto. Passez à l'Étape 5.
Si vous avez déjà créé un fichier prototype, modifiez-le en ajoutant une entrée pour chaque script d'installation qui vient d'être créé.
Si nécessaire, reportez-vous à la rubrique Création d'un package.
Voir aussi
Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre 4, Vérification et transfert d'un package explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un média de distribution.
Les classes d'objets permettent d'effectuer une série d'opérations sur un groupe d'objets de package lors de l'installation ou de la suppression. Vous attribuez des objets à une classe dans le fichier prototype. Une classe doit être attribuée à tous les objets de package, bien que la classe none soit utilisée par défaut pour les objets ne requérant aucune opération particulière.
Le paramètre d'installation CLASSES défini dans le fichier pkginfo correspond à la liste de classes à installer (y compris la classe none).
Remarque - Les objets définis dans le fichier pkgmap appartenant à une classe non répertoriée dans ce paramètre du fichier pkginfo ne sont pas installés.
La liste CLASSES détermine l'ordre d'installation. La classe none, lorsqu'elle est présente, est toujours installée en premier et supprimée en dernier. Etant donné que les répertoires représentent la structure de prise en charge élémentaire de tous les autres objets d'un système de fichiers, ils doivent tous être attribués à la classe none. Des exceptions peuvent être faites mais en règle générale, la classe none est la plus sûre. Cette stratégie garantit que les répertoires sont créés avant les objets qu'ils contiennent. D'autre part, aucune tentative de suppression d'un répertoire n'est faite avant qu'il n'ait été vidé.
La section suivante décrit le déroulement des opérations système lors de l'installation d'une classe. Les opérations sont répétées une fois pour chaque volume d'un package à l'installation du volume en question.
La commande pkgadd crée une liste de noms de chemin.
La commande pkgadd crée une liste de noms de chemin sur lesquels le script d'action opère. Chaque ligne de la liste contient des noms de chemin source et de destination séparés par un espace. Le nom de chemin source indique où l'objet à installer réside sur le volume d'installation. Le nom de chemin de destination indique l'emplacement d'installation de l'objet sur le système cible. Le contenu de la liste est restreint par les critères suivants :
La liste ne contient que des noms de chemin appartenant à la classe associée.
Si la tentative de création des objets du package échoue, les répertoires, tubes nommés, périphériques en mode caractère, périphériques en mode bloc et liens symboliques sont inclus dans la liste avec comme nom de chemin source, /dev/null. En règle générale, ces éléments sont automatiquement créés par la commande pkgadd (s'ils n'existent pas encore) et il leur est attribué des attributs propres (mode, owner, group) tels qu'ils sont définis dans le fichier pkgmap.
Les fichiers liés dont le type est l ne sont en aucun cas inclus dans la liste. Les liens physiques de la classe donnée sont créés à l'étape 4.
Si aucun script d'action de classe n'est fourni pour l'installation d'une classe spécifique, les noms de chemin figurant dans la liste générée sont copiés du volume à l'emplacement cible approprié.
Si un script d'action de classe est présent, il est exécuté.
Le script d'action de classe est appelé avec l'entrée standard contenant la liste générée à l'étape 1. Si ce volume est le dernier du package ou si cette classe ne contient plus d'objets, le script est exécuté avec le seul argument ENDOFCLASS.
Remarque - Même si aucun fichier standard de cette classe ne figure dans le package, le script d'action de classe est appelé au moins une fois avec une liste vide et l'argument ENDOFCLASS.
La commande pkgadd réalise un audit du contenu et des attributs, et crée des liens physiques.
Une fois l'étape 2 ou l'étape 3 exécutée avec succès, la commande pkgadd audite les informations du contenu et des attributs de la liste des noms de chemin. La commande pkgadd crée automatiquement les liens associés à la classe. Toute incohérence d'attributs des noms de chemin est corrigée dans la liste générée.
Les objets sont supprimés d'une classe après l'autre. Les classes existant pour un package mais non répertoriées dans le paramètre CLASSES sont supprimées en premier (par exemple, un objet installé à l'aide de la commande installf). Les classes répertoriées dans le paramètre CLASSES sont supprimées dans l'ordre inverse. La classe none est toujours supprimée en dernier. La section suivante décrit le déroulement des opérations système lors de la suppression d'une classe :
La commande pkgrm crée une liste de noms de chemin.
La commande pkgrm crée une liste des noms de chemin installés appartenant à la classe indiquée. Les noms de chemin auxquels un autre package fait référence sont exclus de la liste à moins que leur type de fichier ne soit e. Le type de fichier e signifie que le fichier doit être modifié lors de l'installation ou de la suppression.
Si le package à supprimer a modifié des fichiers de type e lors de l'installation, il ne doit supprimer que les lignes qu'il a ajoutées. Ne supprimez pas un fichier modifiable non vide. Supprimez les lignes ajoutées par le package.
Si aucun script d'action de classe n'est présent, les noms de chemin sont supprimés.
Si votre package ne contient aucun script d'action de classe de suppression pour la classe, tous les noms de chemin figurant dans la liste générée par la commande pkgrm sont supprimés.
Remarque - Les fichiers de type e (modifiables) ne sont pas attribués à une classe ni à un script d'action de classe associé. Ces fichiers sont à ce stade supprimés, même si le nom de chemin est partagé avec d'autres packages.
Si un script d'action de classe est présent, il est exécuté.
La commande pkgrm appelle le script d'action de classe avec une entrée standard pour le script contenant la liste générée à l'étape 1.
La commande pkgrm réalise un audit.
Après avoir exécuté le script d'action de classe, la commande pkgrm supprime les références aux noms de chemin figurant dans la base de données du package, à l'exception de celles auxquelles un autre package fait référence.
Ce script d'action de classe définit un groupe d'opérations à exécuter pendant l'installation ou la suppression d'un package. Les opérations sont effectuées sur un un groupe de noms de chemin d'après leur définition de classe. Reportez-vous au Chapitre 5, Création d'un package : Etudes de cas pour consulter des exemples de scripts d'action de classe.
Le nom d'un script d'action de classe est basé sur la classe à laquelle il s'applique et la phase durant laquelle les opérations ont lieu, à savoir pendant l'installation ou la suppression du package. Les deux formats de nom sont indiqués dans le tableau suivant :
|
Par exemple, le nom du script d'installation d'une classe nommée manpage est i.pmanpage. Le script de suppression est nommé r.manpage.
Remarque - Ce format de nom de fichier n'est pas utilisé pour les fichiers appartenant aux classes système sed, awk ou build. Pour plus d'informations sur ces classes spéciales, reportez-vous à Classes système spéciales.
Les scripts d'action de classe sont exécutés en tant que uid=root et gid=other.
Un script est exécuté pour tous les fichiers appartenant à la classe donnée sur le volume actuel.
Les commandes pkgadd et pkgrm créent la liste de tous les objets répertoriés dans le fichier pkgmap qui appartiennent à la classe. Pour cette raison, un script d'action de classe ne peut agir que sur les noms de chemin définis dans le fichier pkgmap qui appartiennent à une classe particulière.
Lorsqu'un script d'action de classe est exécuté pour la dernière fois (autrement dit, qu'aucun autre fichier n'appartient à cette classe), il est exécuté une fois avec l'argument de mots clés ENDOFCLASS.
L'interaction avec l'administrateur n'est pas autorisée lors de l'exécution d'un script d'action de classe.
Si l'installation d'un package a nécessité plusieurs volumes, le script d'action de classe est exécuté une fois sur chaque volume contenant au moins un fichier appartenant à une classe. Chaque script doit pour cette raison pouvoir être exécuté plusieurs fois. L'exécution répétée d'un script à partir de la même entrée doit produire les mêmes résultats que si le script était exécuté une seule fois.
Lorsqu'un fichier appartient à une classe associée à un script d'action de classe, le script doit installer le fichier. La commande pkgadd n'installe pas les fichiers pour lesquels un script d'action de classe existe, bien qu'elle vérifie leur installation.
Un script d'action de classe ne doit jamais ajouter, supprimer, ni modifier un nom de chemin ou un attribut système qui ne figure pas dans la liste générée par la commande pkgadd. Pour plus d'informations sur cette liste, reportez-vous à l'étape 1 de Traitement des classes pendant l'installation d'un package.
Lorsque votre script détecte l'argument ENDOFCLASS, placez des opérations posttraitement dans votre script, telle une opération de nettoyage.
L'interaction avec l'administrateur se limite au script request. Ne tentez pas d'obtenir des informations auprès de l'administrateur à l'aide d'un script d'action de classe.
Le système fournit quatre classes spéciales :
Fournit une méthode d'utilisation des instructions sed pour modifier les fichiers durant l'installation et la suppression d'un package.
Fournit une méthode d'utilisation des instructions awk pour modifier les fichiers durant l'installation et la suppression d'un package.
Fournit une méthode permettant de construire ou de modifier de façon dynamique un fichier à l'aide des commandes Bourne shell.
Fournit une méthode permettant de conserver les fichiers qui ne doivent pas être remplacés lors des futures installations de packages.
Permet l'installation et la désinstallation automatisées des services SMF associés à un manifeste. La classe manifest doit être utilisée pour tous les manifestes SMF d'un package.
Si plusieurs fichiers d'un package nécessitent un traitement spécial pouvant être intégralement défini par les commandes sed, awk ou sh, l'installation est plus rapide avec les classes système qu'avec plusieurs classes et les scripts d'action de classe qui leur sont associés.
La classe sed offre un moyen de modifier un objet existant sur le système cible. Le script d'action de classe sed s'exécute automatiquement à l'installation en présence d'un fichier appartenant à la classe sed. Le nom du script d'action de classe sed doit être identique au nom du fichier sur lequel les instructions sont exécutées.
Un script d'action de classe sed fournit des instructions sed au format suivant :
Deux commandes indiquent à quel moment les instructions doivent être exécutées. Les instructions sed qui suivent la commande !install sont exécutées pendant l'installation du package. Les instructions sed qui suivent la commande !remove sont exécutées pendant la suppression du package. L'ordre dans lequel les commandes sont utilisées dans le fichier n'est pas important.
Pour plus d'informations sur les instructions sed, reportez-vous à la page de manuel sed(1) Pour consulter des exemples de scripts d'action de classe sed, reportez-vous au Chapitre 5, Création d'un package : Etudes de cas.
La classe awk offre un moyen de modifier un objet existant sur le système cible. Les modifications sont fournies sous forme d'instructions awk dans un script d'action de classe awk.
Le script d'action de classe awk s'exécute automatiquement à l'installation en présence d'un fichier appartenant à la classe awk. Un tel fichier contient des instructions pour un script de classe awk au format suivant :
Deux commandes indiquent à quel moment les instructions doivent être exécutées. Les instructions awk qui suivent la commande !install sont exécutées pendant l'installation du package. Les instructions qui suivent la commande !remove sont exécutées pendant la suppression du package. Ces commandes peuvent être utilisées dans un ordre quelconque.
Le nom du script d'action de classe awk doit être identique au nom du fichier sur lequel les instructions sont exécutées.
Le fichier à modifier est utilisé comme entrée de la commande awk et le résultat du script remplace en fin de compte l'objet d'origine. Aucune variable d'environnement ne peut être transmise à la commande awk avec cette syntaxe.
Pour plus d'informations sur les instructions awk, reportez-vous à la page de manuel awk(1).
La classe build crée ou modifie un fichier d'objets de package en exécutant des instructions Bourne shell. Ces instructions sont fournies en tant qu'objet de package. Les instructions s'exécutent automatiquement lors de l'installation si l'objet de package appartient à la classe build.
Le nom du script d'action de classe build doit être identique au nom du fichier sur lequel les instructions sont exécutées. Le nom doit également pouvoir être exécuté par la commande sh. Le résultat du script devient la nouvelle version du fichier à mesure qu'il est créé ou modifié. Si le script ne produit aucun résultat, le fichier n'est ni créé ni modifié. De ce fait, le script peut modifier ou créer le fichier.
Par exemple, si un package fournit un fichier par défaut, /etc/randomtable, qui n'existe pas encore sur le système cible, l'entrée du fichier prototype peut être comme suit :
e build /etc/randomtable ? ? ?
L'objet de package, /etc/randomtable, peut être comme suit :
!install # randomtable builder if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then echo "/etc/randomtable is already in place."; else echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable echo "1121554 # first random number" >> $PKG_INSTALL_ROOT/etc/randomtable fi !remove # randomtable deconstructor if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then # the file can be removed if it's unchanged if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then rm $PKG_INSTALL_ROOT/etc/randomtable; fi fi
Reportez-vous au Chapitre 5, Création d'un package : Etudes de cas pour consulter un autre exemple utilisant la classe build.
La classe preserve conserve un fichier d'objets de package en déterminant si un fichier existant doit être supprimé lorsque le package est installé. Deux des scénarios possibles avec l'utilisation du script de classe preserve sont :
Si le fichier à installer n'existe pas encore dans le répertoire cible, il est installé de la manière habituelle.
Si le fichier à installer se trouve déjà dans le répertoire cible, un message s'affiche pour vous en avertir et le fichier n'est pas installé.
Le résultat des deux scénarios est considéré comme positif par le script preserve. Un message d'erreur s'affiche uniquement dans le deuxième scénario si le fichier ne peut pas être copié dans le répertoire cible.
A compter de la version 7 de Solaris, le script i.preserve et une copie de ce script, i.CONFIG.prsv, sont fournis dans le répertoire /usr/sadm/install/scripts avec les autres scripts d'action de classe.
Modifiez le script pour indiquer le nom du ou des fichiers à conserver.
La classe manifest installe et désinstalle automatiquement les services SMF (Service Management Facility) associés à un manifeste SMF. Si vous ne connaissez pas les services SMF, reportez-vous au Chapitre 18, Gestion des services (présentation) du manuel Administration d’Oracle Solaris : Administration de base pour plus d'informations sur l'utilisation des services SMF dans la gestion des services.
Tous les manifestes de service contenus dans les packages doivent être identifiés avec la classe manifest. Les scripts d'action de classe qui installent et suppriment les manifestes de service sont inclus dans le sous-système du package. Lorsque la commande pkgadd(1M) est invoquée, le manifeste du service est importé. Lorsque la commande pkgrm(1M) est invoquée, les instances contenues dans le manifeste du service qui sont désactivées sont supprimées. Tous les services contenus dans le manifeste et pour lesquels il n'existe plus aucune instance sont également supprimés. Si l'option -R est ajoutée à la commande pkgadd(1M) ou pkgrm(1M), ces actions de manifeste de service sont effectuées à la prochaine réinitialisation du système avec cet autre chemin root.
La portion de code suivante provient d'un fichier d'information de package et illustre l'utilisation de la classe manifest.
# packaging files i pkginfo i copyright i depend i preinstall i postinstall # # source locations relative to the prototype file # d none var 0755 root sys d none var/svc 0755 root sys d none var/svc/manifest 0755 root sys d none var/svc/manifest/network 0755 root sys d none var/svc/manifest/network/rpc 0755 root sys f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys
Remarque - N'incluez pas les fichiers i.manifest et r.manifest dans vos packages car ces scripts d'action de classes font partie du SE Oracle Solaris et varient d'une version à l'autre. L'ajout de ces fichiers atténuerait la portabilité de ces modules entre les différentes versions d'Oracle Solaris.
Par exemple, l'attribution des noms de classe application et manpage à des objets est comme suit :
f manpage /usr/share/man/manl/myappl.1l f application /usr/bin/myappl
Par exemple, des entrées pour les classes application et manpage sont comme suit :
CLASSES=manpage application none
Remarque - La classe none est toujours installée en premier et supprimée en dernier, indépendamment de son emplacement dans la définition du paramètre CLASSES.
Par exemple, un script d'installation pour une classe nommée application doit être nommé i.application et un script de suppression, r.application.
N'oubliez pas que lorsqu'un fichier appartient à une classe associée à un script d'action de classe, le script doit installer le fichier. La commande pkgadd n'installe pas les fichiers pour lesquels un script d'action de classe existe, bien qu'elle vérifie leur installation. De plus, si vous définissez une classe sans fournir de script d'action de classe, la seule opération effectuée sur cette classe est la copie de composants, du support d'installation au système cible (comportement pkgadd par défaut).
Si vous n'avez pas créé de fichier prototype, suivez la procédure Création d'un fichier prototype à l'aide de la commande pkgproto, puis passez à l'Étape 7.
Si vous avez déjà créé un fichier prototype, modifiez-le en ajoutant une entrée pour chaque script d'installation qui vient d'être créé.
Si nécessaire, reportez-vous à la rubrique Création d'un package.
Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre 4, Vérification et transfert d'un package vous explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un support de distribution.