Guide d'installation de Solaris 10 8/07 : installation JumpStart personnalisée et installation avancée

Annexe B Conditions supplémentaires de gestion des packages SVR4 – Références

Cette annexe s'adresse aux administrateurs système qui installent ou suppriment des packages, notamment des packages tiers. En vous conformant à la configuration requise par ces packages, vous pourrez :

Ce chapitre se compose des sections suivantes :

Empêcher la modification du système d'exploitation actif

La rubrique ci-dessous explique comment préserver le système d'exploitation actif.

Utilisation de chemins absolus

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 des chemins absolus et relatifs (mobiles) peuvent être également 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.

Utilisation de la commande pkgadd avec l'option -R

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

Type de script 

Syntaxe correcte 

Syntaxe erronée 

Fragments d'instructions "if" Bourne Shell  

if [ -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf ] ; then
if [ -f /etc/myproduct.conf ] ; \
 then

Suppression d'un fichier  

/bin/rm -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
/bin/rm -f /etc/myproduct.conf 

Modification d'un fichier  

echo "test=no" > ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
echo "test=no" > \
/etc/myproduct.conf

Présentation des différences entre $PKG_INSTALL_ROOT et $BASEDIR

$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

Directives pour la rédaction de scripts

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.

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.

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.

Les commandes appelées par un script doivent être disponibles dans toutes les versions prises en charge, car un package doit s'exécuter sur toutes les versions. Par conséquent, vous ne pouvez pas utiliser les commandes ajoutées ou supprimées après la version Solaris 8.  

Pour vérifier qu'une commande ou une option est prise en charge dans la version Solaris 8, 9 ou 10, reportez-vous à la version spécifique de Solaris Reference Manual AnswerBook sur le site Web http://docs.sun.com.

 

Gestion de la compatibilité avec les clients sans disque

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.

Vérification des packages

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
nom_rép

Indique le nom du répertoire où le package réside.

nom_package

Indique le nom du package.


Exemple B–1 Test d'un package

Après avoir créé un package, vous devez le tester en l'installant dans un emplacement de système de fichiers racine alternatif (/) en utilisant l'option -R nom_rép dans 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.



Exemple B–2 Test d'un package sur /export/SUNWvxvm

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.


# 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}

Empêcher les utilisateurs d'intervenir lors d'une installation ou d'une mise à niveau

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.

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 de manuel admin(4) ou pkgadd(1M).

Les exemples suivants indiquent comment la commande pkgadd utilise le fichier d'administration.


Exemple B–3 Fichier d'administration d'installation

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 module 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 module 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

Configuration des paramètres des packages pour les zones

Les packages possèdent des paramètres qui contrôlent la distribution et la visibilité de leur contenu sur un système comportant des zones non globales. Les paramètres des packages SUNW_PKG_ALLZONES , SUNW_PKG_HOLLOW et SUNW_PKG_THISZONE définissent les caractéristiques des packages sur un système comportant des zones. Vous devez configurer ces paramètres pour permettre l'administration de ces packages dans un système comportant des zones non globales.

Le tableau suivant répertorie les quatre combinaisons valides de configuration des paramètres des packages. Si vous choisissez d'autres combinaisons que celles mentionnées, ces paramètres ne sont pas valides et l'installation du package échoue.


Remarque –

Veillez à configurer les trois paramètres des packages. Vous pouvez également n'en définir aucun. Les outils de package interprètent un paramètre de zone manquant comme une erreur mais ne pas régler les paramètres est fortement déconseillé. En définissant les trois paramètres de package, vous indiquez aux outils le comportement à adopter lors de l'installation ou de la suppression du package.


Tableau B–3 Configuration de paramètres de package valides pour les zones

Paramètre SUNW_PKG_ALLZONES

Paramètre SUNW_PKG_HOLLOW

Paramètre SUNW_PKG_THISZONE

Description 

false 

false 

false 

Il s'agit de la configuration par défaut des packages. Aucune valeur n'est spécifiée pour tous les paramètres de package de zone. 

Un package ainsi configuré peut être installé dans une zone globale ou non globale.  

  • Si vous exécutez la commande pkgadd dans la zone globale, le package est installé dans la zone globale et dans toutes les zones non globales.

  • Si vous exécutez la commande pkgadd dans une zone non globale, le package n'est installé que dans cette dernière.

Dans l'un ou l'autre cas, l'intégralité du contenu du package est visible dans toutes les zones où il a été installé. 

false 

false 

true 

Un package ainsi configuré peut être installé dans une zone globale ou non globale. Si, après installation, de nouvelles zones globales sont créées, le package n'est pas étendu à ces dernières. 

  • Si vous exécutez la commande pkgadd dans la zone globale, le package n'est installé que dans cette dernière.

  • Si vous exécutez la commande pkgadd dans une zone non globale, le package n'est installé que dans cette dernière.

Dans l'un ou l'autre cas, l'intégralité du contenu du package est visible dans la zone où il a été installé. 

true 

false 

false 

Vous ne pouvez installer un package ainsi configuré que dans la zone globale. Si vous exécutez la commande pkgadd, le package est installé dans la zone globale et dans toutes les zones non globales. L'intégralité du contenu est visible dans toutes les zones.


Remarque –

Toute tentative d'installation du package dans une zone non globale échoue.


true 

true 

false 

Un package ainsi configuré ne peut être installé que dans la zone globale, par l'administrateur global. Si vous exécutez la commande pkgadd, le contenu du package est complètement installé dans la zone globale. Si les paramètres d'un package sont configurés sur ces valeurs, le contenu du package lui-même n'est distribué à aucune zone non globale. Pour indiquer qu'un package est installé, seules les informations indispensables sont installées sur toutes les zones non globales. Ces informations permettent d'installer d'autres packages en fonction de ce package. Pour plus d'informations sur les packages "vides", reportez-vous au Chapitre 24, À propos des packages et des patchs pour les systèmes Solaris comportant des zones installées (présentation) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris.

Afin de contrôler la dépendance du package, ce dernier apparaît comme étant installé dans toutes les zones. 

  • Dans la zone globale, l'intégralité du contenu du package est visible.

  • À la racine des zones non globales, le contenu du package est totalement invisible.

  • Si une zone non globale hérite d'un système de fichiers de la zone globale, tout package présent sur ce système est visible dans une zone non globale. Tous les autres fichiers fournis par le package sont invisibles dans la zone non globale.

    Par exemple, une zone non globale racine creuse partage quelques répertoires avec la zone globale. Ces répertoires sont en lecture seule. Les zones non globales racine creuses partagent notamment le système de fichiers /platform. Entre autres exemples figurent également les packages qui ne distribuent que les fichiers appropriés à l'initialisation du matériel.


Remarque –

Toute tentative d'installation du package dans une zone non globale échoue.


Description 

Pour plus d'informations 

Pour plus d'informations sur les packages et les zones 

Chapitre 24, À propos des packages et des patchs pour les systèmes Solaris comportant des zones installées (présentation) du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris

Pour une présentation des zones racine creuses et complètes 

Chapitre 16, Introduction aux zones Solaris du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris

Pour plus d'informations sur les caractéristiques et les paramètres des packages 

pkginfo(4)

Pour plus d'informations sur l'affichage des valeurs attribuées aux paramètres des packages 

pkgparam(1)

Pour des informations générales

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), or truss(1) pkgadd(1M), pkgchk(1M), or pkgrm(1M)

Pour une présentation de Solaris Live Upgrade 

Chapitre 2, Solaris Live Upgrade – Présentation du Guide d’installation de Solaris 10 8/07 : Solaris Live Upgrade et planification de la mise à niveau

Pour une présentation du programme d'installation JumpStart personnalisée 

Chapitre 2, Méthode d'installation JumpStart personnalisée – Présentation

Pour une présentation de Solaris Zones 

Chapitre 16, Introduction aux zones Solaris du Guide d’administration système : Gestion des ressources conteneurs Solaris et des zones Solaris