Cette annexe est destinée aux administrateurs système chargés de l'installation ou de la suppression de packages, notamment de packages tiers. En vous conformant à la configuration requise par ces packages, vous pourrez :
empêcher toute modification du système actif de sorte à pouvoir effectuer une mise à niveau avec Solaris Live Upgrade, créer des zones non globales et des clients sans disque et les gérer ;
empêcher un package d'être interactif pour automatiser les installations effectuées avec des programmes d'installation, tels que JumpStart personnalisé.
Ce chapitre se compose des sections suivantes :
La rubrique ci-dessous explique comment préserver le système d'exploitation actif.
Pour que l'installation d'un système d'exploitation se déroule correctement, il faut que les packages reconnaissent et respectent les systèmes de fichiers racines (/) alternatifs, tels qu'un environnement d'initialisation Solaris Live Upgrade inactif.
Les packages peuvent contenir des chemins absolus dans leur fichier pkgmap (structure du package). Si ces fichiers existent, ils sont rédigés en fonction de l'option -R de la commande pkgadd. Les packages qui contiennent à la fois des chemins absolus et relatifs (mobiles) peuvent également être installés dans un système de fichiers racine (/) alternatif. $PKG_INSTALL_ROOT est ajouté au début des fichiers absolus et relatifs, de sorte que tous les chemins sont reproduits correctement lors de l'installation par le biais de pkgadd.
Les packages installés à l'aide de pkgadd -R ou retirés à l'aide de pkgrm -R ne doivent pas altérer le système d'exploitation actif. Cette fonction est utilisée par le programme d'installation JumpStart personnalisée, Solaris Live Upgrade, les zones non globales et les clients sans disque.
Aucun script de procédure fourni avec les packages installés à l'aide de l'option -R de la commande pkgadd ou retirés à l'aide de l'option -R de la commande pkgrm ne doit altérer le système d'exploitation actif. Tout script d'installation fourni par vos soins doit faire référence au répertoire ou au fichier avec la variable $PKG_INSTALL_ROOT en préfixe. Le package doit rédiger tous les répertoires et fichiers à l'aide du préfixe $PKG_INSTALL_ROOT. Il ne doit pas supprimer les répertoires sans préfixe $PKG_INSTALL_ROOT.
Le Tableau B–1 fournit des exemples de syntaxe de script.
Tableau B–1 Exemples de syntaxe de script d'installation
$PKG_INSTALL_ROOT est l'emplacement du système de fichiers racine (/) de la machine sur laquelle vous ajoutez le package. Il est paramétré à l'argument -R de la commande pkgadd. Par exemple, si la commande suivante est appelée, $PKG_INSTALL_ROOT devient /a au cours de l'installation du package.
# pkgadd -R /a SUNWvxvm |
$BASEDIR indique le répertoire de base mobile dans lequel les objets mobiles du package sont installés. Seuls les objets mobiles y sont installés. Les objets fixes (possédant des chemins absolus dans le fichier pkgmap) sont toujours installés en fonction de l'environnement d'initialisation et non pas en fonction de $BASEDIR. Si un package ne possède pas d'objets mobiles, il est dit absolu (fixe), $BASEDIR n'est pas défini et ne peut contenir aucun script de procédure du package.
Par exemple, imaginez que le fichier pkgmap d'un package comporte deux entrées :
1 f none sbin/ls 0555 root sys 3541 12322 1002918510 1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332 |
Par ailleurs, le fichier pkginfo contient une indication pour $BASEDIR :
BASEDIR=/opt |
Si ce package est installé à l'aide de la commande ci-dessous, ls est installé dans /a/opt/sbin/ls, mais ls2 s'installe sous la forme /a/sbin/ls2.
# pkgadd -R /a SUNWtest |
Les scripts de procédure des packages doivent être indépendants du système d'exploitation actif afin qu'il ne puisse être modifié. Les scripts de procédure définissent les actions qui surviennent à un moment donné pendant l'installation et la suppression de packages. Il est possible de créer quatre scripts de procédure avec les noms prédéfinis suivants : preinstall, postinstall, preremove et postremove.
Tableau B–2 Directives pour la création de scripts
Instructions |
A une incidence sur Solaris Live Upgrade |
A une incidence sur les zones non globales |
---|---|---|
Les scripts doivent être rédigés en Bourne shell (/bin/sh). Bourne shell est l'interpréteur utilisé par la commande pkgadd pour exécuter les scripts de procédure. |
X |
X |
Ces scripts ne doivent pas lancer ou arrêter de processus, ni dépendre de l'édition de commandes, telles que ps ou truss, qui dépendent du système d'exploitation et fournissent des informations relatives au système actif. |
X |
X |
Les scripts peuvent utiliser d'autres commandes UNIX standard, telles que expr, cp et ls ou encore d'autres commandes facilitant l'écriture de scripts de shell. |
X |
X |
Toute commande appelée par un script doit être disponible dans toutes les versions prises en charge, car un package doit être exécuté sur toutes ces versions. Par conséquent, vous ne pouvez pas utiliser de commandes ajoutées ou supprimées après la version Solaris 8. Pour vérifier la prise en charge d'une option ou d'une commande spécifique dans Solaris 8, 9 ou 10, reportez-vous à la version spécifique de Solaris Reference Manual AnswerBook sur le site http://docs.sun.com. |
X |
Les packages ne doivent pas exécuter de commandes contenues dans le package lui-même. Ceci permet de gérer la compatibilité des clients sans disque et évite d'exécuter des commandes requérant des bibliothèques partagées qui ne sont pas encore installées.
Tous les packages doivent être validés par pkgchk. Avant d'installer un package venant d'être créé, il doit être vérifié à l'aide de la commande suivante :
# pkgchk -d nom_rép nom_package |
Indique le nom du répertoire où le package réside.
Indique le nom du package.
Une fois le package créé, vous devez le tester en l'installant à un autre emplacement du système de fichiers racine (/) avec l'option -R dir_name et la commande pkgadd. Après avoir installé le package, assurez-vous qu'il fonctionne correctement à l'aide de la commande pkgchk, comme dans l'exemple ci-dessous.
# pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm |
Aucune erreur ne doit s'afficher.
Si un package existe à l'adresse /export/SUNWvxvm, émettez la commande suivante :
# pkgchk -d /export SUNWvxvm |
Aucune erreur ne doit s'afficher.
D'autres commandes permettent de vérifier le package lorsque vous créez, modifiez ou supprimez des fichiers. Vous trouverez ci-dessous des exemples de commande.
Par exemple, les commandes dircmp ou fssnap peuvent être utilisées pour vérifier que les packages fonctionnent correctement.
De même, la commande ps peut servir à tester la compatibilité du démon en s'assurant que les démons ne sont pas arrêtés ou démarrés par le package.
Les commandes truss, pkgadd -v et pkgrm peuvent tester la conformité de l'installation du package runtime, mais ne fonctionnent pas nécessairement dans toutes les circonstances. Dans l'exemple ci-dessous, la commande truss supprime tous les accès en lecture seule non-$TEMPDIR et affiche uniquement les accès qui ne sont pas en lecture seule et qui sont associés à des chemins qui ne figurent pas dans l'environnement d'initialisation inactif indiqué.
# TEMPDIR=/a; export TEMPDIR # truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \ 2>&1 > /dev/null | grep -v O_RDONLY | grep -v \ 'open("'${TEMPDIR} |
Les packages doivent être installés et supprimés sans qu'un utilisateur ne puisse être invité à entrer des informations lorsqu'il se sert des utilitaires Solaris standard suivants.
programme d'installation JumpStart personnalisée ;
Solaris Live Upgrade
Programme Installation de Solaris ;
Solaris Zones
Pour tester un package afin de vous assurer qu'il sera installé sans aucune interaction d'utilisateur, vous pouvez configurer un nouveau fichier d'administration avec la commande pkgadd et l'option - a. L'option -a définit le fichier d'administration de l'installation qui sera utilisé à la place du fichier par défaut. Si vous utilisez le fichier par défaut, le système risque de vous inviter à entrer un plus grand nombre d'informations. Vous pouvez créer un fichier d'administration indiquant à la commande pkgadd qu'elle doit ignorer ces contrôles, et installer le package sans confirmation de l'utilisateur. Pour plus de détails, reportez-vous à la page man admin(4) ou pkgadd(1M).
Les exemples suivants indiquent comment la commande pkgadd utilise le fichier d'administration.
Si aucun fichier d'administration n'est fourni, la commande pkgadd utilise le fichier /var/sadm/install/admin/default. Si vous utilisez ce fichier, une intervention de l'utilisateur pourrait être requise.
# pkgadd |
Si un fichier d'administration relatif est fourni dans la ligne de commande, pkgadd recherche le nom de fichier dans /var/sadm/install/admin et l'utilise. Dans cet exemple, le fichier d'administration relatif est appelé nocheck et la commande pkgadd recherche le nom /var/sadm/install/admin/nocheck .
# pkgadd -a nocheck |
Si un fichier absolu existe, pkgadd l'utilise. Dans cet exemple, pkgadd recherche le fichier d'administration nocheck dans /tmp.
# pkgadd -a /tmp/nocheck |
Vous trouverez ci-dessous un exemple de fichier d'administration d'installation requérant une intervention réduite de la part de l'utilisateur au niveau de l'utilitaire pkgadd. Excepté si le package requiert plus d'espace que celui qui est disponible sur le système, l'utilitaire pkgadd utilise ce fichier et procède à l'installation du package sans inviter l'utilisateur à entrer d'autres d'informations.
mail= instance=overwrite partial=nocheck runlevel=nocheck idepend=nocheck space=ask setuid=nocheck confiict=nocheck action=nocheck basedir=default
Les références suivantes proposent des informations générales sur la configuration requise par les packages ainsi que des syntaxes de commande spécifiques.
Pour obtenir des informations plus spécifiques sur la configuration requise en termes de packages et sur la terminologie : |
Chapitre 6, Advanced Techniques for Creating Packages du Application Packaging Developer’s Guide |
Pour obtenir des informations de base sur l'ajout et la suppression de packages et sur le fichier d'administration d'installation |
Chapitre 16, Managing Software(Overview) du System Administration Guide: Basic Administration |
Pour obtenir des informations détaillées sur les commandes dont il est fait référence dans cette annexe, reportez-vous à ces pages de manuel |
dircmp(1), fssnap(1M), ps(1) ou truss(1) pkgadd(1M), pkgchk(1M) ou pkgrm(1M) |
Pour une présentation de Solaris Live Upgrade | |
Pour une présentation du programme d'installation JumpStart personnalisée | |
Pour une présentation de Solaris Zones |