Chapitre 3 Amélioration de la fonctionnalité d'un package (opérations)

Ce chapitre décrit la création facultative de fichiers d'information et de scripts d'installation d'un package. Alors que le Chapitre2Création d'un package aborde la configuration minimale requise pour la création d'un package, le présent chapitre traite des fonctions supplémentaires qui peuvent être intégrées à un package. Ces fonctions supplémentaires dépendent des critères que vous avez retenus pour concevoir votre package. Pour plus d'informations, reportez-vous à Critères à prendre en considération avant de créer un package.

La liste suivante répertorie les informations fournies dans ce chapitre :

• Création de fichiers d'information et de scripts d'installation (liste de tâches)

• Création de fichiers d'information

• Création de scripts d'installation

• Création de packages signés

Création de fichiers d'information et de scripts d'installation (liste de tâches)

La liste de tâches suivante décrit les fonctions facultatives pouvant être intégrées à un package.

Création de fichiers d'information

Cette section se consacre aux fichiers facultatifs d'information de package. Ces fichiers permettent de définir les dépendances des packages, de fournir un message de copyright et de réserver de l'espace supplémentaire sur le système cible.

Définition des dépendances d'un package

Vous devez déterminer si votre package a des dépendances vis à vis d'autres packages et si d'autres packages dépendent du vôtre. Les dépendances et les incompatibilités d'un package peuvent être définies à l'aide de deux des fichiers facultatifs d'information de package, compver et depend.

Le fichier compver vous permet d'indiquer les versions antérieures de votre package qui sont compatibles avec le package à installer.

Le fichier depend vous permet de définir trois types de dépendances associées à votre package. Ces types de dépendances sont les suivants :

• Package prérequis : votre package dépend de l'existence d'un autre package ;

• Dépendance inverse : un autre package dépend de l'existence du vôtre ;

  ---

  Remarque –

  Utilisez le type dépendance inverse uniquement lorsqu'un package incapable de fournir un fichier depend dépend de votre package.

  ---

• Package incompatible : votre package est incompatible avec le package nommé.

Le fichier depend ne résout que des dépendances très simples. Si votre package dépend d'un fichier spécifique, de son contenu ou de son comportement, le fichier depend ne fournit pas les informations appropriées. Dans ce cas, vous devez vous servir d'un script request ou d'un script checkinstall pour effectuer un contrôle détaillé des dépendances. Le script checkinstall est également le seul script capable d'effectuer un arrêt net de la procédure d'installation du package.

Vérifiez que les fichiers depend et compver ont des entrées dans le fichier prototype. Le type de fichier doit être i (fichier d'information de package).

Reportez-vous aux pages de manuel depend(4) et compver(4) pour plus d'informations.

Procédure de définition des dépendances d'un package

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. S'il existe des versions précédentes de votre package et que vous devez spécifier que la nouvelle version est compatible avec les anciennes, créez un fichier nommé compver à l'aide d'un éditeur de texte.

   Répertoriez les versions compatibles avec votre package. Utilisez le format suivant :

   string string . . .

   La valeur de chaîne est identique à la valeur attribuée au paramètre VERSION dans le fichier pkginfo pour chaque package compatible.

3. Enregistrez les modifications et quittez l'éditeur.

4. Si votre package dépend de l'existence d'autres packages, si d'autres packages dépendent de l'existence du vôtre ou, si votre package est incompatible avec un autre package, créez un fichier nommé depend avec votre éditeur de texte.

   Ajoutez une entrée pour chaque dépendance. Utilisez le format suivant :

   type pkg-abbrev pkg-name (arch) version (arch) version . . .

   type

   Définit le type de dépendance. Doit être l'un des caractères suivants : P (package prérequis), I (package incompatible) ou R (dépendance inverse).

   pkg-abrév

   Indique l'abréviation du package telle que SUNWcadap.

   pkg-nom

   Indique le nom complet du package tel que Chip designers need CAD application software to design abc chips. Runs only on xyz hardware and is installed in the usr partition.

   (arch)

   Facultatif. Indique le type de matériel sur lequel le package s'exécute. Par exemple, sparc ou x86. Si vous spécifiez une architecture, vous devez utiliser des parenthèses comme séparateurs.

   version

   Facultatif. Indique la valeur attribuée au paramètre VERSION dans le fichier pkginfo.

   Pour plus d'informations, reportez-vous à depend(4).

5. Enregistrez les modifications et quittez l'éditeur.

6. Effectuez l'une des opérations suivantes :

   • Si vous souhaitez créer des fichiers d'information et des scripts d'installation supplémentaires, passez à l'étape suivante, Procédure de rédaction d'un message de copyright.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de création d'un fichier prototype à l'aide de la commande pkgproto. Passez à l'Étape 7.

   • Si vous avez déjà créé un fichier prototype, modifiez-le en ajoutant une entrée pour chaque fichier qui vient d'être créé.

7. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Exemple 3–1 Fichiercompver

Cet exemple contient quatre versions d'un package : 1.0, 1.1, 2.0 et le nouveau package, 3.0. Le nouveau package est compatible avec les trois versions précédentes. Le fichier compver de la nouvelle version est comme suit :

release 3.0
release 2.0
version 1.1
1.0

Les entrées ne doivent pas nécessairement apparaître en séquence. Elles doivent cependant parfaitement correspondre à la définition du paramètre VERSION figurant dans le fichier pkginfo de chaque package. Dans cet exemple, les concepteurs de package ont utilisé des formats différents dans les trois premières versions.

Exemple 3–2 Fichier depend

Cet exemple suppose que le package SUNWcadap nécessite l'installation préalable des packages SUNWcsr et SUNWcsu sur le système cible. Le fichier depend de SUNWcadap est comme suit :

P SUNWcsr Core Solaris, (Root)
P SUNWcsu Core Solaris, (Usr)

Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vé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.

Rédaction d'un message de copyright

Vous devez décider si votre package doit afficher un message de copyright lors de son installation. Dans l'affirmative, créez le fichier copyright.

Vous devez inclure un fichier copyright afin d'offrir une protection juridique à votre application logicielle. Renseignez-vous auprès du service juridique de votre société pour connaître la formulation exacte du message.

Pour fournir un message de copyright, vous devez créer un fichier nommé copyright. Le message s'affiche au cours de l'installation tel qu'il apparaît dans le fichier (sans aucun formatage). Reportez-vous à la page de manuel copyright(4) pour plus d'informations.

Vérifiez que votre fichier copyright dispose d'une entrée dans le fichier prototype. Le type de fichier doit être i (fichier d'information de package).

Procédure de rédaction d'un message de copyright

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Créez un fichier nommé copyright à l'aide de votre éditeur de texte.

   Saisissez le texte du message de copyright tel qu'il doit apparaître lors de l'installation de votre package.

3. Enregistrez les modifications et quittez l'éditeur.

4. Effectuez l'une des opérations suivantes :

   • Si vous souhaitez créer des fichiers d'information et des scripts d'installation supplémentaires, passez à l'étape suivante, Procédure de réservation d'espace supplémentaire sur un système cible.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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 fichier d'information qui vient d'être créé.

5. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Exemple 3–3 Fichier copyright

Un message de copyright partiel peut être comme suit :

Copyright (c) 2003 Company Name
All Rights Reserved
 
This product is protected by copyright and distributed under
licenses restricting copying, distribution, and decompilation.

Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vé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.

Réservation d'espace supplémentaire sur un système cible

Vous devez déterminer si votre package nécessite de l'espace disque supplémentaire sur le système cible. Cet espace vient s'ajouter à l'espace requis par les objets du package. Dans l'affirmative, créez le fichier d'information space. Cette opération diffère de la création de fichiers et répertoires vides lors de la phase d'installation, comme indiqué à la rubrique Définition d'objets supplémentaires à créer lors de la phase d'installation.

La commande pkgadd vérifie que suffisamment d'espace disque est disponible pour l'installation de votre package, en fonction de la définition des objets figurant dans le fichier pkgmap. Toutefois, un package requiert parfois de l'espace disque supplémentaire pour accommoder d'autres éléments outre les objets définis dans le fichier pkgmap. Par exemple, votre package peut créer un fichier à l'issue de l'installation contenant une base de données, des fichiers journaux ou tout autre fichier à taille croissante et utilisant donc de plus en plus d'espace disque. Pour vous assurer que suffisamment d'espace disque soit réservé à cet effet, vous devez inclure un fichier space spécifiant l'espace disque requis. La commande pkgadd recherche l'espace supplémentaire spécifié dans un fichier space. Reportez-vous à la page de manuelspace(4) pour plus d'informations.

Vérifiez que votre fichier space dispose d'une entrée dans le fichier prototype. Le type de fichier doit être i (fichier d'information de package).

Procédure de réservation d'espace supplémentaire sur un système cible

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Créez un fichier nommé space à l'aide de votre éditeur de texte.

   Spécifiez l'espace disque supplémentaire requis par votre package. Utilisez le format suivant :

   pathname blocks inodes

   nomdechemin

   Indique un nom de répertoire qui peut correspondre au point de montage de systèmes de fichiers.

   blocs

   Indique le nombre de blocs de 512 octets à réserver.

   i-nodes

   Indique le nombre d'i-nodes requis.

   Pour plus d'informations, reportez-vous à la page de manuel space(4).

3. Enregistrez les modifications et quittez l'éditeur.

4. Effectuez l'une des opérations suivantes :

   • Pour créer des scripts d'installation, passez à l'opération suivante, Procédure de rédaction d'un script request.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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 fichier d'information qui vient d'être créé.

5. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Exemple 3–4 Fichier space

Cet exemple de fichier space indique que 1000 blocs de 512 octets et 1 i-node doivent être réservés dans le répertoire /opt sur le système cible.

/opt   1000   1

Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vé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.

Création de scripts d'installation

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 :

• Script request

  Le script request demande des données à l'administrateur qui installe un package afin d'attribuer ou de redéfinir des variables d'environnement.

• Script checkinstall

  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.

  ---

• Scripts de procédure

  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.

• Scripts d'action de classe

  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).

Traitement des scripts pendant l'installation d'un package

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 :

1. 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 .

2. 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.

3. Elle exécute le script preinstall.

4. 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.

   1. Crée des liens symboliques, des périphériques, des tubes nommés et les répertoires requis.

   2. 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.

   3. Crée tous les liens physiques.

5. Elle exécute le script postinstall.

Traitement des scripts pendant la suppression d'un package

Lors de la suppression d'un package, la commande pkgrm effectue les opérations suivantes :

1. Elle exécute le script preremove.

2. 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.

   1. Supprime les liens physiques.

   2. Supprime les fichiers standard.

   3. Supprime les liens symboliques, les périphériques et les tubes nommés.

3. Elle exécute le script postremove.

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.

Variables d'environnement de package mises à la disposition des scripts

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.

  Variable d'environnement	Description
  CLIENT_BASEDIR	Répertoire de base pour le système cible. Alors que BASEDIR est la variable à utiliser pour faire référence à un package spécifique du système d'installation (un serveur dans la majorité des cas), CLIENT_BASEDIR est le chemin à inclure dans les fichiers placés sur le système client. CLIENT_BASEDIR existe si BASEDIR existe et est identique à BASEDIR en l'absence de PKG_INSTALL_ROOT.
  INST_DATADIR	Répertoire dans lequel le package lu se trouve. Si le package est lu à partir d'une bande, cette variable correspond à l'emplacement d'un répertoire temporaire dans lequel le package a été transféré au format répertoire. En d'autres termes, en supposant que le nom du package ne porte pas d'extension (par exemple, SUNWstuff.d), le script request du package actuel se trouve dans $INST_DATADIR/$PKG/install.
  PATH	Liste de recherche utilisée par sh pour trouver des commandes à l'appel d'un script. La variable PATH est habituellement définie sur /sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin.
  PKGINST	Identificateur d'instance du package installé. Si aucune autre instance du package n'est installée, la valeur correspond à l'abréviation du package (par exemple, SUNWcadap). Sinon, la valeur correspond à l'abréviation du package auquel est ajouté un suffixe, comme par exemple SUNWcadap.4.
  PKGSAV	Répertoire dans lequel les fichiers peuvent être enregistrés afin d'être utilisés par les scripts de suppression ou dans lequel des fichiers précédemment enregistrés se trouvent. Uniquement disponible dans la version 2.5 de Solaris et les versions compatibles.
  PKG_CLIENT_OS	Système d'exploitation du client sur lequel le package doit être installé. La valeur de cette variable est Solaris.
  PKG_CLIENT_VERSION	Version de Solaris au format x.y.
  PKG_CLIENT_REVISION	Révision de la version Solaris.
  PKG_INSTALL_ROOT	Système de fichiers racine du système cible sur lequel le package doit être installé. Cette variable n'existe que si les commandes pkgadd et pkgrm ont été appelées avec l'option -R. Cette existence conditionnelle simplifie son utilisation dans les scripts de procédure sous la forme ${PKG_INSTALL_ROOT}/cheminquelconque.
  PKG_NO_UNIFIED	Variable d'environnement définie si les commandes pkgadd et pkgrm ont été appelées avec les options -M et -R. Cette variable d'environnement est transmise à tout script d'installation de package ou commande de package faisant partie de l'environnement du package.
  UPDATE	Cette variable d'environnement est absente de la plupart des environnements d'installation. Si cette variable existe (valeur yes), elle signifie l'une des deux choses suivantes : Un package de même nom, de même version et de même architecture est déjà installé sur le système. Ou, ce package remplace un package déjà installé de même nom, sous la direction de l'administrateur. Dans ces situations, le répertoire de base d'origine est toujours utilisé.

Obtention d'informations sur un package pour 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 Chapitre4Vérification et transfert d'un package pour plus d'informations.

Codes de sortie des scripts

Chaque script doit quitter son exécution avec l'un des codes de sortie figurant dans le tableau suivant.

Reportez-vous au Chapitre5Création d'un package : Études de cas pour consulter des exemples de codes de sortie renvoyés par les scripts d'installation.

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).

Rédaction d'un script request

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.

Comportements du script request

• 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é install 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.

Règles de conception pour les scripts request

• 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=valeur. 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.

Si les administrateurs chargés d'installer votre package utilisent le produit JumpStart^TM, 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 utiliser 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).

Procédure de rédaction d'un script request

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Créez un fichier nommé request à l'aide de votre éditeur de texte.

3. Enregistrez vos modifications puis quittez l'éditeur.

4. Effectuez l'une des opérations suivantes :

   • Pour créer des scripts d'installation supplémentaires, passez à l'opération suivante, Procédure de recueil de données d'un système de fichiers.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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éé.

5. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de 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 Chapitre4Vé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.

Recueil de données d'un système de fichiers à l'aide du script checkinstall

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 install, si celui-ci existe, ou en tant qu'utilisateur nobody. 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.

À 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.

Le script checkinstall est disponible depuis la version 2.5 de Solaris et versions compatibles.

Comportements du script checkinstall

• 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 request est exécuté en tant qu'utilisateur non privilégié checkinstall, 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.

Règles de conception pour les scripts checkinstall

• 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=valeur. 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.

Procédure de recueil de données d'un système de fichiers

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Créez un fichier nommé checkinstall à l'aide de votre éditeur de texte.

3. Enregistrez vos modifications puis quittez l'éditeur.

4. Effectuez l'une des opérations suivantes :

   • Pour créer des scripts d'installation supplémentaires, passez à l'étape suivante, Procédure de rédaction de scripts de procédure.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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éé.

5. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de 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 Chapitre4Vé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.

Rédaction de scripts de procédure

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.

• Script preinstall

  Ce script est exécuté avant le début de l'installation des classes. Ce script ne doit installer aucun fichier.

• Script postinstall

  Ce script est exécuté une fois tous les volumes installés.

• Script preremove

  Ce script est exécuté avant le début de la suppression des classes. Ce script ne doit supprimer aucun fichier.

• Script postremove

  Ce script est exécuté après la suppression de toutes les classes.

Comportements des scripts de procédure

Les scripts de procédure sont exécutés en tant que uid=root et gid=other.

Règles de conception des scripts de procédure

• 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 Chapitre5Création d'un package : Études 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 Chapitre5Création d'un package : Études 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.

  ---

Procédure de rédaction de scripts de procédure

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Créez un ou plusieurs scripts de procédure à l'aide de votre éditeur de texte.

   Un script de procédure doit porter l'un des noms prédéfinis suivants : preinstall, postinstall, preremove ou postremove.

3. Enregistrez les modifications et quittez l'éditeur.

4. Effectuez l'une des opérations suivantes :

   • Pour créer des scripts d'action de classe, passez à l'opération suivante, Procédure de rédaction de scripts d'action de classe.

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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éé.

5. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de 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 Chapitre4Vé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.

Rédaction de scripts d'action de classe

Définition de classes d'objets

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).

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. Étant 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é.

Traitement des classes pendant l'installation d'un package

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.

1. 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.

2. 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é.

3. 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.

   ---

4. 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 vérifie 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.

Traitement des classes pendant la suppression d'un package

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 :

1. 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.

2. 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.

   ---

3. 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.

4. 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.

Script d'action de classe

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 Chapitre5Création d'un package : Études 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.

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.

Comportements des scripts d'action de classe

• 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.

Règles de conception des scripts 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.

Classes système spéciales

Le système fournit quatre classes spéciales :

• Classe sed

  Offre un moyen d'utiliser les instructions sed pour modifier des fichiers lors de l'installation et de la suppression d'un package.

• Classe awk

  Offre un moyen d'utiliser les instructions awk pour modifier des fichiers lors de l'installation et de la suppression d'un package.

• Classe build

  Offre un moyen de créer ou de modifier un fichier dynamiquement à l'aide de commandes Bourne shell.

• La classe preserve

  Offre un moyen de conserver des fichiers qui ne doivent pas être remplacés lors de futures installations de packages.

• La classe manifest

  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.

Script de classe sed

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 Chapitre5Création d'un package : Études de cas.

Script de classe awk

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).

Script de classe build

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 Chapitre5Création d'un package : Études de cas pour consulter un autre exemple utilisant la classe build.

Script de classe preserve

La classe preserve conserve un fichier d'objets de package en déterminant si un fichier existant doit ou non être remplacé à l'installation du package. 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.

À 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.

Script de classe manifest

La classe manifest installe et désinstalle automatiquement les services SMF (Service Management Facility) associés à un manifeste SMF. Si vous n'êtes pas familier avec SMF, reportez-vous au Chapitre 17, Managing Services (Overview) du System Administration Guide: Basic Administration pour plus d'informations sur la gestion des services à l'aide de SMF.

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 racine.

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
i i.manifest
i r.manifest
#
# 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

Procédure de rédaction de scripts d'action de classe

1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

2. Donnez aux objets du package le nom de classe souhaité dans le fichier prototype.

   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

3. Modifiez le paramètre CLASSES figurant dans le fichier pkginfo afin qu'il contienne les noms de classe à utiliser dans votre package.

   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.

   ---

4. Si vous créez un script d'action de classe pour un fichier appartenant à la classe sed, awk ou build, faites du répertoire contenant l'objet de package votre répertoire de travail.

5. Créez les scripts d'action de classe ou les objets de package (pour les fichiers appartenant à la classe sed, awk ou build).

   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).

6. Effectuez l'une des opérations suivantes :

   • Si vous n'avez pas créé de fichier prototype, suivez la procédure Procédure de 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éé.

7. Créez votre package.

   Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Autres ressources

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vé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.

Création de packages signés

La procédure de création de packages signés implique un certain nombre d'étapes et nécessite la compréhension de nouveaux concepts et d'une nouvelle terminologie. Cette section fournit des informations sur les packages signés, la terminologie correspondante et des informations sur la gestion des certificats. Elle fournit également des procédures détaillées relatives à la création d'un package signé.

Packages signés

Un package signé est un package au format flux de données standard contenant une signature numérique (signature numérique PKCS7 au chiffrement PEM définie ci-après) qui garantit les points suivants :

• Le package provient de l'entité qui l'a signé ;

• L'entité l'a en effet signé ;

• Le package n'a pas été modifié depuis que l'entité l'a signé ;

• L'entité qui l'a signé est une entité de confiance.

La seule différence entre un package signé et un package non signé est sa signature ; Un package signé est compatible binaire avec un package non signé. De ce fait, un package signé peut être utilisé avec d'anciennes versions d'outils d'empaquetage. Toutefois, la signature est dans ce cas ignorée.

La technologie d'empaquetage signé emploie une nouvelle terminologie et de nouvelles abréviations décrites dans le tableau suivant :

Gestion de certificats

Avant de créer un package signé, vous devez disposer d'un keystore de package. Ce keystore de package contient des certificats sous la forme d'objets. Un keystore de package contient deux types d'objets :

Certificat de confiance

Certificat de confiance contenant un seul certificat à clé publique appartenant à une autre entité. Le certificat de confiance est nommé ainsi parce que le propriétaire du keystore espère que la clé publique contenue dans le certificat appartient en effet à l'entité indiquée par le sujet (propriétaire) du certificat. L'émetteur du certificat garantit cette confiance en signant le certificat.

Les certificats de confiance sont utilisés lors de la vérification des signatures et lors de l'initialisation d'une connexion à un serveur sécurisé (SSL).

Clé utilisateur

Une clé utilisateur renferme toutes les informations sensibles de la clé de chiffrement. Ces informations sont stockées dans un format protégé pour empêcher tout accès non autorisé. Une clé utilisateur se compose de la clé privée d'un utilisateur et du certificat à clé publique correspondant à la clé privée.

Les clés utilisateur sont utilisées dans le cadre de la création d'un package signé.

Par défaut, le keystore du package est stocké dans le répertoire /var/sadm/security. Les utilisateurs peuvent disposer de leur propre keystore stocké par défaut dans le répertoire $HOME/.pkg/security.

Sur disque, un keystore de package peut utiliser deux formats : un format multifichier et un format monofichier. Un format multifichier stocke ses objets dans plusieurs fichiers. Chaque type d'objet est stocké dans un fichier distinct. Tous ces fichiers doivent être chiffrés à l'aide de la même phrase de passe. Un keystore monofichier stocke tous ses objets dans un seul fichier dans le système de fichiers.

Le principal utilitaire servant à gérer les certificats et le keystore du package est la commande pkgadm. Les sous-sections suivantes décrivent les opérations de gestion du keystore du package les plus courantes.

Ajout de certificats de confiance au keystore du package

Vous pouvez ajouter un certificat de confiance au keystore du package à l'aide de la commande pkgadm. Le certificat peut être au format PEM ou DER. Exemple :

$ pkgadm addcert -t /tmp/mytrustedcert.pem

Dans cet exemple, le certificat au format PEM appelé moncertdeconf.pem est ajouté au keystore du package.

Ajout d'un certificat utilisateur et d'une clé privée au keystore du package

La commande pkgadm ne génère pas de certificats utilisateur ni de clés privées. Les certificats utilisateur et les clés privées sont en général obtenus auprès d'une autorité de certification telle que Verisign. Ils sont aussi générés localement en tant que certificat autosigné. Une fois la clé et le certificat obtenus, vous pouvez les importer dans le keystore du package à l'aide de la commande pkgadm. Exemple :

pkgadm addcert -n myname -e /tmp/myprivkey.pem /tmp/mypubcert.pem

Dans cet exemple, les options suivantes sont utilisées :

Vérification du keystore du package

La commande pkgadm sert également à afficher le contenu du keystore du package. Exemple :

$ pkgadm listcert

Cette commande affiche les certificats de confiance et clés privées contenus dans le keystore du package.

Suppression de certificats de confiance et de clés privées du keystore d'un package

La commande pkgadm peut être utilisée pour supprimer des certificats de confiance et des clés privées du keystore du package.

Lorsque vous supprimez des certificats utilisateur, l'alias de la paire certificat/clé doit être spécifié. Exemple :

$ pkgadm removecert -n myname

L'alias du certificat correspond au nom usuel du certificat, qui peut être identifié à l'aide de la commande pkgadm listcert. Par exemple, la commande suivante supprime un certificat de confiance appelé Trusted CA Cert 1 :

$ pkgadm removecert -n "Trusted CA Cert 1"

Si un certificat de confiance et un certificat utilisateur sont stockés sous le même nom d'alias, ils sont tous deux supprimés lorsque vous spécifiez l'option -n.

Création de packages signés

La procédure de création de packages signés se déroule en trois étapes :

1. Création d'un package non signé au format répertoire.

2. Importation du certificat de signature, des certificats AC et de la clé privée dans le keystore du package.

3. Signature du package de l'étape 1 avec les certificats de l'étape 2.

Les outils d'empaquetage ne créent pas de certificats. Ces certificats doivent être obtenus auprès d'une autorité de certification telle que Verisign ou Thawte.

Chaque étape de la création de packages signés est décrite dans les procédures suivantes.

Procédure de création d'un package non signé au format répertoire

La procédure de création d'un package non signé au format répertoire est identique à la procédure de création d'un package standard décrite précédemment dans ce manuel. La procédure suivante décrit les étapes de la création d'un package non signé au format répertoire. Pour plus d'informations, reportez-vous aux sections précédentes relatives à la création des packages.

1. Créez le fichier pkginfo.

   Le fichier pkginfo doit avoir le contenu de base suivant :

   PKG=SUNWfoo BASEDIR=/ NAME=My Test Package ARCH=sparc VERSION=1.0.0 CATEGORY=application

2. Créez le fichier prototype.

   Le fichier prototype doit avoir le contenu de base suivant :

   $cat prototype i pkginfo d none usr 0755 root sys d none usr/bin 0755 root bin f none usr/bin/myapp=/tmp/myroot/usr/bin/myapp 0644 root bin

3. Répertoriez le contenu du répertoire source des objets.

   Exemple :

   $ ls -lR /tmp/myroot

   Le résultat pourrait être comme suit :

   /tmp/myroot: total 16 drwxr-xr-x 3 abc other 177 Jun 2 16:19 usr /tmp/myroot/usr: total 16 drwxr-xr-x 2 abc other 179 Jun 2 16:19 bin /tmp/myroot/usr/bin: total 16 -rw------- 1 abc other 1024 Jun 2 16:19 myapp

4. Créez le package non signé.

   pkgmk -d `pwd`

   Le résultat peut être comme suit :

   ## Building pkgmap from package prototype file. ## Processing pkginfo file. WARNING: parameter <PSTAMP> set to "syrinx20030605115507" WARNING: parameter <CLASSES> set to "none" ## Attempting to volumize 3 entries in pkgmap. part 1 -- 84 blocks, 7 entries ## Packaging one part. /tmp/SUNWfoo/pkgmap /tmp/SUNWfoo/pkginfo /tmp/SUNWfoo/reloc/usr/bin/myapp ## Validating control scripts. ## Packaging complete.

   Le package se trouve dorénavant dans le répertoire actuel.

Procédure d'importation des certificats dans le keystore du package

Le certificat et la clé privée à importer doivent être un certificat X.509 et une clé privé chiffrés au format PEM ou DER. En outre, tout certificat intermédiaire ou à chaînes liant votre certificat de signature à l'autorité de certification doit être importé dans le keystore du package avant la signature d'un package.

Chaque autorité de certification peut établir des certificats dans divers formats. Pour extraire les certificats et la clé privée du fichier PKCS12 et les importer dans le fichier X.509 chiffré au format PEM (approprié à l'importation dans le keystore du package), servez-vous d'un utilitaire de conversion en freeware tel que OpenSSL.

Si votre clé privée est chiffrée (ce qui est habituellement le cas), un message vous invite à saisir la phrase de passe. Un autre message vous invite par ailleurs à saisir un mot de passe afin de protéger le keystore du package résultant. Ce mot de passe n'est pas obligatoire mais sans mot de passe, le keystore du package n'est pas chiffré.

La procédure suivante décrit l'importation des certificats à l'aide de la commande pkgadm une fois convertis au format approprié.

1. Importez tous les certificats fournis par l'autorité de certification situés dans votre fichier de certificats X.509 chiffrés au format PEM ou DER.

   Par exemple, pour importer tous les certificats de l'autorité de certification situés dans le fichier ca.pem, vous devez saisir la commande suivante :

   $ pkgadm addcert -k ~/mykeystore -ty ca.pem

   Le résultat peut être comme suit :

   Trusting certificate <VeriSign Class 1 CA Individual \ Subscriber-Persona Not Validated> Trusting certificate </C=US/O=VeriSign, Inc./OU=Class 1 Public \ Primary Certification Authority Type a Keystore protection Password. Press ENTER for no protection password (not recommended): For Verification: Type a Keystore protection Password. Press ENTER for no protection password (not recommended): Certificate(s) from <ca.pem> are now trusted

   Pour importer votre clé de signature dans le keystore du package, vous devez fournir un alias qui sera utilisé ultérieurement lors de la signature du package. Cet alias peut également être utilisé pour supprimer la clé du keystore du package.

   Par exemple, pour importer votre clé de signature à partir du fichier sign.pem, vous devez saisir la commande suivante :

   $ pkgadm addcert -k ~/mykeystore -n mycert sign.pem

   Le résultat peut être comme suit :

   Enter PEM passphrase: Enter Keystore Password: Successfully added Certificate <sign.pem> with alias <mycert>

2. Vérifiez que les certificats se trouvent dans le keystore du package.

   Par exemple, pour afficher les certificats contenus dans le keystore créé à l'étape précédente, vous devez saisir la commande suivante :

   $ pkgadm listcert -k ~/mykeystore

Procédure de signature du package

Une fois les certificats importés dans le keystore du package, le package peut être signé. La signature du package en tant que telle s'effectue à l'aide de la commande pkgtrans.

1. Signez le package à l'aide de la commande pkgtrans. Indiquez l'emplacement du package non signé et l'alias de la clé pour signer le package.

   Par exemple, en partant des exemples des procédures précédentes, vous devez saisir la commande suivante pour créer un package signé appelé SUNWfoo.signed :

   $ pkgtrans -g -k ~/mykeystore -n mycert . ./SUNWfoo.signed SUNWfoo

   Le résultat de cette commande peut être comme suit :

   Retrieving signing certificates from keystore </home/user/mykeystore> Enter keystore password: Generating digital signature for signer <Test User> Transferring <SUNWfoot> package instance

   Le package signé est créé dans le fichier SUNWfoo.signed, au format flux de données de package. Ce package signé peut être copié sur un site Web et, installé à l'aide de la commande pkgadd et d'une URL.