Cette annexe est destinée aux administrateurs système qui doivent utiliser le programme d'installation JumpStart personnalisée 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.
Les références documentaires ci-dessous fournissent des informations d'arrière-plan sur les conditions de gestion des modules.
Pour assurer le bon fonctionnement du programme JumpStart personnalisé et de Solaris Live Upgrade, les modules doivent être conformes aux normes SVR4 pour les modules. Pour toute information plus spécifique concernant les conditions de gestion des modules 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 modules 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.
Tableau G–1 Informations sur les exigences
Méthode d'installation |
Détails des exigences |
---|---|
Solaris Live Upgrade |
|
Programme d'installation JumpStart personnalisée |
|
Un environnement d'initialisation inactif est une copie de l'environnement d'exploitation et non le système en cours de fonctionnement. Tout module 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 modules doivent reconnaître et respecter les spécificateurs de l'environnement d'initialisation inactif.
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 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 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 G–2 contient des exemples de syntaxe correcte.
Tableau G–2 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 module. 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 module.
# pkgadd -R /a SUNWvxvm |
$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 l'environnement d'initialisation et non 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 ce module 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 |
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 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 inactif peut être activé/désactivé à l'aide de Solaris Live Upgrade, les scripts de procédure du module 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, 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 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 de la commande -f umount a été ajoutée à la version 7 de Solaris. Pour vérifier qu'une commande ou option est prise en charge par la version Solaris 2.6, consultez le manuel Solaris 2.6 Reference Manual AnswerBook sur http://docs.sun.com.
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 |
Indique le nom du répertoire où le module réside.
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.
Un module 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_module 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, 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 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, pkgadd -v et pkgrm peuvent tester la conformité de l'installation du module 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 rubrique, reportez-vous aux pages dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M) et pkgrm(1M) du manuel.
Le programme d'installation JumpStart personnalisée garantit que des modules 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 module peut participer aux mises à niveau Solaris. Pour qu'un module 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 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'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 module sans confirmation de l'utilisateur. Pour de plus amples informations, consultez les pages, admin(4) et pkgadd(1M) du manuel.
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 module requiert plus d'espace que celui qui est disponible sur le système, l'utilitaire the 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