Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'installation Oracle Solaris 10 8/11 : planification des mises à niveau et de Solaris Live Upgrade |
Partie I Mise à niveau avec Solaris Live Upgrade
1. Emplacement des informations de planification pour l'installation de Solaris
2. Solaris Live Upgrade - Présentation
3. Solaris Live Upgrade - Planification
4. Utilisation de Solaris Live Upgrade pour créer un environnement d'initialisation - Tâches
5. Procédure de mise à niveau avec Solaris Live Upgrade - Tâches
6. Reprise sur échec : restauration de l'environnement d'initialisation d'origine (Tâches)
7. Maintenance des environnements d'initialisation de Solaris Live Upgrade - Tâches
9. Solaris Live Upgrade - Exemples
10. Solaris Live Upgrade - Références de commandes
Partie II Mise à niveau et migration avec Solaris Live Upgrade vers un pool racine ZFS
11. Solaris Live Upgrade et ZFS (Présentation)
12. Solaris Live Upgrade pour ZFS (Planification)
13. Création d'un environnement d'initialisation pour des pools racine ZFS
14. Solaris Live Upgrade pour ZFS comportant des zones non globales
B. Conditions supplémentaires de gestion des packages SVR4 - Références
Empêcher la modification du système d'exploitation actif
Utilisation de chemins absolus
Utilisation de la commande pkgadd avec l'option -R
Présentation des différences entre $PKG_INSTALL_ROOT et $BASEDIR
Directives pour la rédaction de scripts
Empêcher les utilisateurs d'intervenir lors d'une installation ou d'une mise à niveau
Configuration des paramètres des packages pour les zones
Pour des informations générales
C. Utilisation de l'analyseur de patchs lors de la mise à niveau (Tâches)
La section ci-dessous explique comment préserver le système d'exploitation actif.
Pour que l'installation d'un système d'exploitation se déroule correctement, il faut que les packages reconnaissent et respectent les systèmes de fichiers racines (/) alternatifs, tels qu'un environnement d'initialisation Solaris Live Upgrade 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 des chemins absolus et relatifs (mobiles) peuvent être également installés dans un système de fichiers racine alternatif (/). $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. Cette fonction est utilisée par le programme d'installation JumpStart personnalisée, Solaris Live Upgrade, les zones non globales et les clients sans disque.
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 B-1 fournit des exemples de syntaxe de script.
Tableau B-1 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 package. Il est paramétré à l'argument -R de la commande pkgadd. Par exemple, si la commande suivante est appelée, $PKG_INSTALL_ROOT devient /a au cours 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
Les scripts de procédure des packages doivent être indépendants du système d'exploitation actif afin qu'il ne puisse être modifié. 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.
Tableau B-2 Directives pour la création de scripts
|
Les packages ne doivent pas exécuter de commandes contenues dans le package lui-même. Ceci permet de gérer la compatibilité des clients sans disque et évite d'exécuter des commandes requérant des bibliothèques partagées qui ne sont pas encore installées.
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 dir_name pkg_name
Indique le nom du package.
Exemple B-1 Test d'un package
Après avoir créé un package, vous devez le tester en l'installant dans un emplacement de système de fichiers racine alternatif (/) en utilisant l'option -R nom_rép dans 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.
Exemple B-2 Test d'un package sur /export/SUNWvxvm
Si un package existe à l'adresse /export/SUNWvxvm, émettez la commande suivante :
# pkgchk -d /export SUNWvxvm
Aucune erreur ne doit s'afficher.
D'autres commandes permettent de vérifier le package lorsque vous créez, modifiez ou supprimez des fichiers. Vous trouverez ci-dessous des exemples de commande.
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}