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. Etant 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 ni lancer ou arrêter un processus, ni dépendre de l'édition de commandes telles que ps ou truss, qui dépendent elles-mêmes 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 section "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 dir_name pkg_name

  dir_name	Indique le nom du répertoire où le module réside.
  pkg_name	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. Après avoir installé le module, 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 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 de plus amples informations sur les commandes mentionnées dans cette section, consultez les pages dircmp(1), fssnap(1M), ps(1) ou truss(1) du manuel.