Annexe C Conditions supplémentaires de gestion des modules SvR4 - Références

Cette annexe est destinée aux administrateurs système qui doivent utiliser le programme JumpStart personnalisé ou Solaris Live Upgrade pour installer ou supprimer des modules, et plus particulièrement des modules 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.

Une racine alternative (/) est une copie de l'environnement d'exploitation, et non du système actif.

Aperçu des conditions relatives à la gestion des modules

Pour que le programme JumpStart fonctionne correctement, les modules doivent être conformes aux conditions SvR4. Le Application Packaging Developer's Guide fournit davantage de définitions de termes et d'informations sur les conditions relatives à la gestion des modules. Consultez tout particulièrement le chapitre : "Advanced Package Creation Techniques" in Application Packaging Developer's Guide

Pour des informations de base sur l'ajout et la suppression de modules et le fichier d'administration de l'installation, reportez-vous à "Managing Software (Overview)" in System Administration Guide: Basic Administration. Consultez également les pages correspondantes du manuel.

Pour obtenir des informations détaillées 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 C-1 contient des informations concernant Solaris Live Upgrade ou le programme JumpStart personnalisé.

Conditions relatives à la racine alternative (/) du programme JumpStart personnalisé et de Solaris Live Upgrade

Une racine alternative (/) est une copie de l'environnement d'exploitation, et non du système actif. Un module destiné à être utilisé par Live Upgrade ou par le programme JumpStart personnalisé 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 suivante détaille les conditions relatives à la racine aternative (/).

• Pour que le système d'exploitation s'installe avec succès, les modules doivent reconnaître et respecter les indicateurs de la racine alternative (/).

  Les modules peuvent contenir des chemins absolus dans leur fichier pkgmap (structure du module). Si ces fichiers existent, ils sont rédigés en fonction de l'option - R de la commande pkgadd. Les modules 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 modules 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 modules installés à l'aide de pkgadd -R ou retirés à l'aide de pkgrm -R ne doit altérer le système d'exploitation actif. Tout script d'installation fourni par vous doit faire référence au répertoire ou au fichier avec la variable $PKG_INSTALL_ROOT en préfixe. Le module 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 C-2 contient des exemples de syntaxe correcte.

  Tableau C-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 module. Il est paramétré à l'argument -R de la commande pkgadd. Par exemple, si la commande suivante est exécutée :

# pkgadd -R /a SUNWvxvm

Alors, $PKG_INSTALL_ROOT est ajouté au début de /a pendant l'installation du module.

$BASEDIR indique le répertoire de base mobile dans lequel les objets mobiles du module 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 la racine alternative (/), mais pas en fonction de $BASEDIR. Si un module 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 module.

Par exemple, imaginez que le fichier pkgmap d'un module 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 le module est installé à l'aide de la commande suivante :

# pkgadd -R /a SUNWtest

Alors ls est installé dans /a/opt/sbin/ls, mais ls2 s'installe sous la forme de /a/sbin/ls2 .

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

Lorsque vous utilisez Solaris Live Upgrade et créez un nouvel environnement d'initialisation, vous pouvez éviter des problèmes en respectant les consignes suivantes :

• 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 modules. 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 alternatif peut être activé/désactivé à l'aide de Solaris Live Upgrade, les scripts de procédure 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, la racine alternative active (/) ne doit pas être modifiée, sauf dans le cadre des règles présentées dans la rubrique "Conditions relatives à la racine alternative (/) du programme JumpStart personnalisé et de 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 qui n'existent pas dans les versions antérieures à la version 2.6. Par exemple, ils ne peuvent pas exécuter la commande pgrep. Depuis la version 2.6, de nouvelles fonctions ont été ajoutées à de nombreuses commandes. 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 -f est une nouveauté de la commande umount.

• Tous les modules doivent être validés par pkgchk. Avant d'installer un module venant d'être créé, il doit être vérifié à l'aide de la commande suivante :

  # pkgchk -d nom_rép nom_module

  nom_rép	Indique le nom du répertoire où le module réside.
  nom_module	Indique le nom du module.

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

  # pkgchk -d /export SUNWvxvm

  Aucune erreur ne doit s'afficher.

  Une fois un module créé, testez-le en l'installant à un emplacement racine alternatif (/) à l'aide de l'option -R dir_name de pkgadd. Une fois ce contrôle effectué, l'exactitude du module doit être vérifiée à l'aide de pkgchk, comme dans cet exemple.

  # pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm

  Aucune erreur ne doit s'afficher.

• De même, les modules ne doivent pas exécuter de commandes contenues dans le module 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, modification et 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 modules 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 module. Les commandes truss et pkgadd peuvent tester la conformité de l'installation du module runtime, mais ne fonctionnent pas nécessairement dans tous les cas. Dans l'exemple suivant, la commande truss supprime tous les accès en lecture seule non-$BASEDIR et n'affiche que les accès en lecture/écriture vers des chemins qui n'appartiennent pas à la racine alternative indiquée (/).

# BASEDIR=/a; export BASEDIR
# truss -t open /usr/sbin/pkgadd -R ${BASEDIR} SUNWvxvm \
2>&1> /dev/null | grep -v O_RDONLY | grep -v \
'open("'${BASEDIR}

Pour obtenir des informations détaillées sur les commandes mentionnées dans cette rubrique, consultez les pages dircmp(1), fssnap(1M), ps(1) ou truss(1) du manuel.

Conformité des mises à niveau à l'aide du programme JumpStart personnalisé

La conformité du programme JumpStart personnalisé garantit que des modules puissent être ajoutés ou retirés tout en faisant partie des utilitaires d'installation traditionnels Solaris, qui sont les suivants :

• Le programme JumpStart personnalisé

• Le programme suninstall de Solaris

• La méthode d'installation Solaris Web Start

La conformité du programme JumpStart personnalisé garantit également que le module puisse participer aux mises à niveau Solaris. Pour qu'un module soit conforme au programme JumpStart personnalisé, il doit également respecter les conditions relatives à la racine alternative (/) définie dans la rubrique "Conditions relatives à la racine alternative (/) du programme JumpStart personnalisé et de Solaris Live Upgrade".

Pour pouvoir utiliser correctement le programme JumpStart personnalisé, des modules doivent être ajoutés ou retirés sans que l'utilisateur ne soit invité à entrer d'informations. Pour empêcher toute interaction de l'utilisation, configurez un nouveau fichier d'administration à l'aide de pkgadd -a. L'option -a définit un 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 peut vous inviter à saisir plus d'informations. Vous pouvez créer un fichier d'administration qui indique à la commande pkgadd qu'elle doit ignorer ces contrôles, et installer le module avec une confirmation de l'utilisateur. 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 sera probablement 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 effectue une recherche dans /tmp/nocheck.

  # pkgadd -a /tmp/nocheck

Vous trouverez ci-dessous un exemple de fichier d'administration de l'installation qui empêche pkgadd de demander la confirmation de l'utilisateur avant l'installation du module.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=nocheck
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default

Pour plus de détails, consultez les pages admin( 4) ou pkgadd(1M) du manuel.