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.
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 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 C-1 contient des informations concernant Solaris Live Upgrade ou le programme JumpStart personnalisé.
Tableau C-1 Informations sur les conditions
Méthode d'installation |
Détails des conditions |
---|---|
Solaris Live Upgrade |
|
Programme JumpStart personnalisé |
|
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 vos soins 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
$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. 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 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 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, 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.
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é
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éfinies dans la section "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.