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

Cette annexe est destinée aux administrateurs système devant utiliser le programme d'installation JumpStart personnalisée ou Solaris Live Upgrade pour installer ou supprimer des packages, et plus particulièrement des packages de fournisseurs tiers. Si vous respectez ces conditions, l'installation JumpStart personnalisée reste non-interactive et n'affecte pas le système actif, ce qui vous permet d'effectuer une mise à niveau à l'aide de Solaris Live Upgrade.

Aperçu des conditions de gestion des packages

Les références documentaires ci-dessous fournissent des informations d'arrière-plan sur les conditions de gestion des packages.

• Pour assurer le bon fonctionnement du programme JumpStart personnalisé et de Solaris Live Upgrade, les packages doivent être conformes aux normes SVR4 pour les packages. Pour toute information plus spécifique concernant les conditions de gestion des packages et toute définition terminologique, reportez-vous à l'Application Packaging Developer's Guide. Consultez tout particulièrement le chapitre “Advanced Package Creation Techniques” in Application Packaging Developer's Guide

• Pour toute information de base concernant l'ajout et la suppression de packages et le fichier d'administration de l'installation, reportez-vous à la rubrique “Managing Software (Overview)” in System Administration Guide: Basic Administration. Consultez également les pages correspondantes du manuel.

• Pour de plus amples informations sur les commandes mentionnées dans la présente annexe, consultez les pages dircmp(1), fssnap(1M), ps(1) ou truss(1) du manuel.

Le Tableau G–1 contient des informations concernant Solaris Live Upgrade et le programme JumpStart.

Exigences d'environnement d'initialisation inactif pour le programme d'installation JumpStart personnalisée et pour Solaris Live Upgrade

Un environnement d'initialisation inactif est une copie de l'environnement d'exploitation et non le système en cours de fonctionnement. Tout package destiné à être utilisé par Live Upgrade ou par le programme d'installation JumpStart personnalisée doit répondre aux conditions suivantes :

• permettre une mise à jour ou une installation JumpStart personnalisée sans intervention de l'utilisateur ;

• ne requérir aucune modification du système actif, contrairement à Solaris Live Upgrade.

La liste ci-dessous détaille les conditions de conformité d'un environnement d'initialisation inactif.

• Pour que le système d'exploitation s'installe avec succès, les packages doivent reconnaître et respecter les spécificateurs de l'environnement d'initialisation 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 une racine alternative (/). $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.

  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 G–2 contient des exemples de syntaxe correcte.

  Tableau G–2 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

Aperçu 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 ci-après est invoquée, $PKG_INSTALL_ROOT sera alors ajouté au début de /a lors 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

Conformité de l'environnement d'initialisation inactif Solaris Live Upgrade

Lorsque vous utilisez Solaris Live Upgrade et créez un nouvel environnement d'initialisation, suivez les directives suivantes pour éviter tout problème :

• Vos scripts de procédure doivent être indépendants de l'environnement d'initialisation actif. 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. Étant donné qu'un environnement d'initialisation inactif peut être activé/désactivé à l'aide de Solaris Live Upgrade, les scripts de procédure du package doivent être indépendants de l'environnement d'exploitation actif.

  • 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 d'exploitation actif.

  • Les scripts de procédure peuvent utiliser d'autres commandes UNIX telles que expr, cp et ls et d'autres commandes qui facilitent la génération de scripts shell. Toutefois, l'environnement d'initialisation inactif ne doit pas être modifié, sauf dans le cadre des règles présentées dans la rubrique Exigences d'environnement d'initialisation inactif pour le programme d'installation JumpStart personnalisée et pour Solaris Live Upgrade.

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

  • Les scripts de procédure ne doivent pas exécuter de commandes ne figurant pas dans 2.6 et les versions antérieures. Par exemple, ils ne peuvent pas exécuter la commande pgrep. Depuis la version 2.6, de nombreuses commandes ont été dotées de nouvelles fonctions. Les scripts de procédure ne doivent pas utiliser d'options de commande qui n'existaient pas dans la version 2.6. Par exemple, l'option de la commande -f umount a été ajoutée à la version 7 de Solaris. Pour vérifier la prise en charge d'une commande ou option dans la version Solaris 2.6, reportez-vous au document Solaris 2.6 Reference Manual AnswerBook sur le site http://docs.sun.com.

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

  Par exemple, si un package existe à l'adresse /export/SUNWvxvm, émettez la commande suivante :

  # pkgchk -d /export SUNWvxvm

  Aucune erreur ne doit s'afficher.

  Un package créé doit être testé. Pour cela, il doit être installé à un emplacement de l'environnement d'initialisation inactif à l'aide de l'option -R nom_rép de 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.

• De même, les packages ne doivent pas exécuter de commandes contenues dans le package lui-même. Ceci permet de gérer la compatibilité sans disque et évite d'exécuter des commandes requérant des bibliothèques partagées qui ne sont pas encore installées.

Ces conditions de création, de modification et de suppression de fichiers peuvent être vérifiées à l'aide de diverses commandes. 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 suivant, la commande truss supprime tous les accès en lecture seule non-$TEMPDIR et n'affiche que les accès en lecture/écriture vers des chemins qui n'appartiennent pas à 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}

Pour de plus amples informations sur les commandes mentionnées dans cette section, reportez-vous aux pages de manuel dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M), ou pkgrm(1M).

Conformité des mises à niveau effectuées à l'aide du programme d'installation JumpStart personnalisée

Le programme d'installation JumpStart personnalisée garantit que des packages peuvent être ajoutés ou retirés tout en faisant partie des utilitaires d'installation traditionnels de Solaris, qui sont les suivants :

• programme d'installation JumpStart personnalisée ;

• Programme suninstall de Solaris ;

• méthode d'installation Solaris Web Start.

Le programme d'installation JumpStart personnalisée garantit également que le package peut participer aux mises à niveau Solaris. Pour qu'un package soit conforme au programme d'installation JumpStart personnalisée, il doit également respecter les conditions de conformité d'environnement d'initialisation inactif définies dans la rubrique Exigences d'environnement d'initialisation inactif pour le programme d'installation JumpStart personnalisée et pour Solaris Live Upgrade.

Pour pouvoir utiliser correctement le programme d'installation JumpStart personnalisée, des packages doivent être ajoutés ou retirés sans que l'utilisateur ne soit invité à entrer d'informations. Pour empêcher toute interaction de l'utilisateur, créez un nouveau fichier d'administration à l'aide de la commande pkgadd -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 de plus amples informations, consultez les pages de manuel admin(4) ou pkgadd(1M).

Les exemples suivants montrent comment utiliser le fichier d'administration pkgadd.

• Si aucun fichier de ce type n'existe, pkgadd emploie /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 mentionné dans la ligne de commande, pkgadd recherche le nom du fichier dans /var/sadm/install/admin et l'utilise. Dans cet exemple, le fichier d'administration relatif est appelé nocheck et pkgadd recherche /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