Exigences d'environnement d'initialisation inactif pour le programme d'installation JumpStart personnalisée et pour Solaris Live Upgrade

Un environnement d'initialisation inactif est une copie de l'environnement d'exploitation et non le système en cours d'exécution. 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 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 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