Installation des systèmes Oracle® Solaris 11.2

Quitter la vue de l'impression

Mis à jour : Juillet 2014
 
 

Création d'un script de manifeste dérivé

De manière générale, un script de manifeste dérivé récupère des informations du client et les utilise pour modifier un manifeste AI de base en vue de créer un manifeste AI personnalisé pour ce client uniquement. Un script de manifeste dérivé peut également combiner plusieurs manifestes AI partiels. Le manifeste dérivé final doit être complet et passer la validation.

Un script de manifeste dérivé peut être n'importe quel type de script pris en charge dans l'image. Par exemple, ksh93 et python sont dans l'image par défaut. Si vous souhaitez utiliser un autre type de script, assurez-vous qu'il est pris en charge dans l'image.

Récupération des attributs client

Le script de manifeste dérivé peut exécuter des commandes pour lire les attributs système. AI exécute le script en tant que rôle aiuser. Le rôle aiuser dispose de tous les privilèges d'un utilisateur non privilégié et des privilèges supplémentaires suivants :

solaris.network.autoconf.read
solaris.smf.read.*

Le rôle aiuser ne dispose pas de privilèges mais peut lire plus d'informations à partir du système que les autres utilisateurs sans privilèges. Le rôle aiuser ne peut pas modifier le système.

Pour plus d'informations sur les rôles, profils et privilèges, reportez-vous à la section Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.2 .

Outre l'utilisation de commandes pour lire les attributs système, les attributs du client sont disponibles via les variables d'environnement présentées dans le tableau ci-après.

Table 10-1  Variables d'environnement des attributs client
Nom de la variable d'environnement
Description
SI_ARCH
Architecture du client à installer. Correspond à la sortie de uname -p.
SI_CONFIG_PROFILE_DIR
Le répertoire dans lequel l'utilisateur a fourni des profils de configuration système peut être stocké et utilisé par le service d'installation.
SI_CPU
ISA ou type de processeur du client à installer. Correspond à la sortie de uname -p.
SI_DISKNAME_#
Ensemble plat de variables représentant les noms des disques trouvés sur le client. Il y aura un nombre SI_NUMDISKS de variables SI_DISKNAME_#, où le # est remplacé par un nombre entier commençant à 1 et jusqu'à SI_NUMDISKS. Cet ensemble de variables est corrélé à l'ensemble des variables décrites par SI_DISKSIZE_#.
SI_DISKSIZE_#
Ensemble plat de variables représentant les tailles des disques trouvés sur le client. Il y aura un nombre SI_NUMDISKS de variablesSI_DISKSIZE_#, où # est remplacé par un nombre entier en partant de 1 et jusqu'à SI_NUMDISKS. Cet ensemble de variables est corrélé à l'ensemble des variables décrites par SI_DISKNAME_#. Les tailles sont des nombres entiers de méga-octets.
SI_HOSTADDRESS
Adresse IP du client telle que définie dans l'environnement d'installation.
SI_HOSTNAME
Nom d'hôte du client tel que défini dans l'environnement d'installation.
SI_INSTALL_SERVICE
Nom du service d'installation utilisé pour obtenir le script de manifeste. Cette variable d'environnement a une valeur uniquement pour les initialisations réseau et pas pour les initialisations à partir d'un média.
SI_KARCH
Architecture du noyau du client. Correspond à la sortie de uname -m.
SI_MEMSIZE
Quantité de mémoire physique sur le client. La taille est un nombre entier de méga-octets.
SI_NATISA
Architecture du jeu d'instructions natif du client. Correspond à la sortie de isainfo -n.
SI_NETWORK
Numéro de réseau du client. Le numéro de réseau est (IP_ADDR & netmask).
SI_NUMDISKS
Nombre de disques sur le client.
SI_PLATFORM (or SI_MODEL)
Plate-forme du client. Correspond à la sortie de uname -i pour les systèmes x86 et prtconf -b pour les systèmes SPARC.
SI_SYSPKG
La version du package d'incorporation Oracle Solaris sur le client (actuellement nommée entire). Si le package entier du client est pkg://solaris/entire@0.5.11,5.11-0.175.0.0.0.2.0:20111020T143822Z, la valeur de SI_SYSPKG serait pkg:/entire@0.5.11-0.175.0. Pour une version de mise à jour ou sru, si le pkg entier du client est pkg://solaris/entire@0.5.11,5.11-0.175.1.19.0.6.0:20140508T221351Z, la valeur de SI_SYSPKG serait pkg:/entire@0.5.11-0.175.1.

Personnalisation du manifeste AI

Pour ajouter ou modifier des éléments XML dans un manifeste AI, utilisez la commande /usr/bin/aimanifest.

    Un fichier à modifier par aimanifest doit contenir au moins les éléments suivants :

  • Une référence !DOCTYPE à un DTD valide pour le manifeste XML en cours de développement.

  • L'élément root pour ce DTD.

L'exemple suivant montre le fichier manifeste de base minimum pour un manifeste AI, y compris le fichier DTD AI pour le service d'installation où ce script de manifeste dérivé sera ajouté :

<!DOCTYPE auto_install SYSTEM "file:///imagepath/auto_install/ai.dtd.1">
<auto_install/>

La valeur de l'argument imagepath correspond au chemin renvoyé par la commande suivante, où svcname correspond au nom du service d'installation auquel ce script de manifeste dérivé sera ajouté :

$ installadm list -v -n svcname

Remarque -  Modifiez le chemin d'image pour revenir à ///usr/share avant d'utiliser le script pour installer un client AI.

Utilisez la sous-commande load de la commande aimanifest pour charger un manifeste de base avant tout autre appel aimanifest dans le script de manifeste dérivé. Tous les fichiers que vous chargez doivent être accessibles par le client au moment de son installation. Par exemple, vous pouvez charger un manifeste depuis imagepath/auto_install/manifest/ vers le service d'installation cible.

Dans ce chapitre, les exemples chargent le fichier /usr/share/auto_install/manifest/default.xml. Le manifeste exemple dans /usr/share/auto_install/manifest/ peut varier des manifestes dans le service d'installation cible. Dans l'environnement de production, vous ne devez pas charger de manifestes depuis /usr/share/auto_install/manifest/.

La sous-commande load peut également être utilisée pour charger ou insérer des manifestes partiels.

Utilisez la sous-commande add pour ajouter de nouveaux éléments. La sous-commande set permet d'ajouter des attributs d'élément ou de modifier des valeurs d'élément ou d'attribut. Pour plus d'informations, reportez-vous à la page de manuel aimanifest(1M). La page de manuel et les exemples de scripts qui suivent fournissent des exemples d'utilisation de la commande aimanifest.


Remarque - Si une valeur spécifiée dans une commande aimanifest contient l'un des caractères suivants, cette valeur doit être entourées de guillemets simples ou doubles pour éviter que le caractère soit interprété comme une partie du nom de chemin XML :
/'"@[]=

Il peut être nécessaire de neutraliser les guillemets en les faisant précéder d'une barre oblique inverse (\) selon les règles du shell utilisé, afin que celui-ci n'interprète pas ni ne supprime les guillemets.


L'exemple suivant renvoie l'action de l'élément software_data qui contient le nom du package pkg:/entire. Dans cet exemple, les guillemets sont nécessaires autour de pkg:/entire car la barre oblique est un caractère spécial. Les barres obliques inverses sont nécessaires pour neutraliser les guillemets si cette commande est appelée dans un script shell, tel qu'un script ksh93.

# /usr/bin/aimanifest get software_data[name=\"pkg:/entire\"]@action

Conseil  - Il est recommandé de configurer un déroutement d'arrêt en cas d'erreur.

Le script partiel suivant constitue un modèle correct de script de manifeste dérivé :

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load baseAImanifest.xml

# Customize AI manifest. For example:
/usr/bin/aimanifest load -i manifest_fragment.xml
/usr/bin/aimanifest set origin@name file:///net/myserver/myrepo/repo.redist

exit $SCRIPT_SUCCESS

Exemples de scripts de manifeste dérivé

Cette section indique comment écrire des scripts de manifeste dérivé permettant de déterminer des attributs client et d'utiliser ces informations pour personnaliser le manifeste AI. Ces exemples n'incluent pas nécessairement toutes les informations requises pour produire un manifeste AI valide.

    Pour tester ces exemples, effectuez les étapes de configuration suivantes :

  1. Définissez la variable d'environnement AIM_MANIFEST sur un emplacement où le script va développer le manifeste AI.

    Le fichier $AIM_MANIFEST est réécrit pour chaque commande aimanifest modifiant le fichier. Chaque appel de aimanifest avec la sous-commande load, add, delete ou set ouvre, modifie et enregistre le fichier AIM_MANIFEST. Si AIM_MANIFEST n'est pas défini, les commandes aimanifest échouent.

  2. Définissez la variable d'environnement AIM_LOGFILE sur un emplacement où le script peut écrire des informations détaillées et des messages d'erreur.

    La commande aimanifest consigne le nom de la sous-commande, les valeurs d'argument et le statut de renvoi de chaque appel aimanifest à l'écran et au fichier $AIM_LOGFILE s'il est défini.

  3. Assurez-vous que la commande aimanifest est disponible sur le système sur lequel vous exécutez le script. Si la commande aimanifest n'est pas disponible, installez le package auto-install-common.

  4. Définissez des variables d'environnement. Les exemples suivants illustrent l'utilisation des variables d'environnement pour récupérer des informations sur le client. Pour tester ces exemples, vous devez définir des valeurs pour ces variables d'environnement.

    Lorsque vous installez un système utilisant l'AI, les variables d'environnement répertoriées dans le Table 10–1 ont des valeurs et sont disponibles pour un script de manifeste dérivé à utiliser.

Exemple 10-1  Spécification du partitionnement de disque en fonction de la taille du disque

Cet exemple personnalise le manifeste AI de sorte qu'il n'utilise que la moitié du disque cible sur une partition fdisk Oracle Solaris si la taille du disque est supérieure à 1 To. Essayez de définir SI_DISKSIZE_1 sur moins de 1 To, puis sur plus de 1 To pour différentes exécutions du script. Définissez également SI_NUMDISKS et SI_DISKNAME_1 avant d'exécuter le script. Notez que ce script ne peut être utilisé qu'avec les clients x86 car le partitionnement spécifié ne s'applique qu'aux clients x86.

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

# Check that there is only one disk on the system.
if [[ $SI_NUMDISKS -gt "1" ]] ; then
    print -u2 "System has too many disks for this script."
    exit $SCRIPT_FAILURE
fi

/usr/bin/aimanifest add \
    /auto_install/ai_instance/target/disk/disk_name@name $SI_DISKNAME_1

if [[ $SI_DISKSIZE_1 -gt "1048576" ]] ; then
    typeset -i PARTN_SIZE=$SI_DISKSIZE_1/2

    # Default action is to create.
    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk[disk_name@name=\"$SI_DISKNAME_1\"]/partition@name 1
    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk/partition[@name=1]/size@val \
        ${PARTN_SIZE}mb
else
    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk[disk_name@name=\"$SI_DISKNAME_1\"]/partition@action \
        use_existing_solaris2
fi
exit $SCRIPT_SUCCESS

Pour les clients dont la valeur de SI_DISKSIZE_1 est inférieure ou égale à 1048576, les éléments suivants sont ajoutés à $AIM_MANIFEST :

<target>
  <disk>
    <disk_name name="/dev/dsk/c0t0d0s0"/>
    <partition action="use_existing_solaris2"/>
  </disk>
  <!-- <logical> section -->
</target>

Pour les clients dont la valeur de SI_DISKSIZE_1 est supérieure à 1048576, des éléments semblables aux éléments suivants sont ajoutés à $AIM_MANIFEST, en fonction de la valeur de SI_DISKSIZE_1 :

<target>
  <disk>
    <disk_name name="/dev/dsk/c0t0d0s0"/>
    <partition name="1">
      <size val="524288mb"/>
    </partition>
  </disk>
  <!-- <logical> section -->
</target>

disk_name est spécifié dans la commande pour ajouter la partition afin d'éviter la création d'une autre spécification du disque pour la partition. Le script de cet exemple indique que la partition se trouve sur le disque $SI_DISKNAME_1 et non sur un autre disque. Si les lignes appropriées de cet exemple sont remplacées par les lignes suivantes, vous n'obtenez pas le résultat que vous souhaitez :

    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk/partition@name 1
    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk/partition[@name=1]/size@val \
        ${PARTN_SIZE}mb
else
    /usr/bin/aimanifest add \
        /auto_install/ai_instance/target/disk/partition@action \
        use_existing_solaris2

Au lieu de la sortie illustrée ci-dessus, ce script vous donne la sortie erronée suivante :

<target>
  <disk>
    <disk_name name="c0t0d0s0"/>
  </disk>
  <disk>
    <partition name="1">
      <size val="524288mb"/>
    </partition>
  </disk>
</target>
Exemple 10-2  Spécification de la disposition du pool root en fonction de l'existence de disques supplémentaires

Cet exemple permet de personnaliser le manifeste AI pour configurer un miroir du pool root si un deuxième disque existe ou configurer un miroir tridirectionnel si un troisième disque existe. Définissez SI_NUMDISKS et SI_DISKNAME_1 avant d'exécuter le script. Définissez SI_DISKNAME_2, SI_DISKNAME_3, et tous les autres, si nécessaire, en fonction de la valeur que vous définissez pour SI_NUMDISKS. Ces variables d'environnement seront définies et disponibles pour les scripts de manifeste dérivé lors des installations AI.

Cet exemple illustre l'utilisation du chemin de retour aimanifest (–r option). Pour plus d'informations sur le chemin de retour, reportez-vous à la page de manuel aimanifest(1M).

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

# Use the default if there is only one disk.
if [[ $SI_NUMDISKS -ge 2 ]] ; then
    typeset -i disk_num

    # Turn on mirroring. Assumes a root zpool is already set up.
    vdev=$(/usr/bin/aimanifest add -r \
        target/logical/zpool[@name=rpool]/vdev@name mirror_vdev)
    /usr/bin/aimanifest set ${vdev}@redundancy mirror

    for ((disk_num = 1; disk_num <= $SI_NUMDISKS; disk_num++)) ; do
        eval curr_disk="$"SI_DISKNAME_${disk_num}
        disk=$(/usr/bin/aimanifest add -r target/disk@in_vdev mirror_vdev)
        /usr/bin/aimanifest set ${disk}@in_zpool rpool
        /usr/bin/aimanifest set ${disk}@whole_disk true
        disk_name=$(/usr/bin/aimanifest add -r \
            ${disk}/disk_name@name $curr_disk)
        /usr/bin/aimanifest set ${disk_name}@name_type ctd
    done
fi
exit $SCRIPT_SUCCESS

Dans le cas d'un système doté de deux disques nommés c0t0d0 et c0t1d0, la sortie de cet exemple est l'élément XML suivant :

<target>
  <disk in_vdev="mirror_vdev" in_zpool="rpool" whole_disk="true">
    <disk_name name="c0t0d0" name_type="ctd"/>
  </disk>
  <disk in_vdev="mirror_vdev" in_zpool="rpool" whole_disk="true">
    <disk_name name="c0t1d0" name_type="ctd"/>
  </disk>
  <logical>
    <zpool name="rpool" is_root="true">
      <vdev name="mirror_vdev" redundancy="mirror"/>
      <filesystem name="export" mountpoint="/export"/>
      <filesystem name="export/home"/>
      <be name="solaris"/>
    </zpool>
  </logical>
</target>
Exemple 10-3  Spécification d'une configuration en miroir si au moins deux disques d'une taille donnée sont présents

Cet exemple permet de personnaliser le manifeste AI pour spécifier une configuration en miroir si le système dispose d'au moins deux disques de 200 Go. Utilisez les deux premiers disques trouvés qui font au moins 200 Go. Définissez SI_NUMDISKS, SI_DISKNAME_1 et SI_DISKSIZE_1 dans votre environnement de test avant d'exécuter le script. Définissez également SI_DISKNAME_2, SI_DISKSIZE_2 et tous les autres, si nécessaire, en fonction de la valeur que vous définissez pour SI_NUMDISKS. Ces variables d'environnement seront définies et disponibles pour les scripts de manifeste dérivé lors des installations AI.

Cet exemple montre comment modifier un noeud lorsque plusieurs noeuds avec le même chemin sont présents. L'implémentation shell utilise l'option (– r) de chemin de retour de aimanifest pour renvoyer le chemin à un noeud spécifique et utilise ce chemin pour apporter d'autres modifications au noeud. L'implémentation Python illustre l'utilisation de sous-chemin (utilisation de [] à l'intérieur d'un chemin de noeud) pour apporter d'autres modifications à ce noeud.

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

# Find the disks first.
typeset found_1
typeset found_2
typeset -i disk_num

for ((disk_num = 1; disk_num <= $SI_NUMDISKS; disk_num++)) ; do
    eval curr_disk="$"SI_DISKNAME_${disk_num}
    eval curr_disk_size="$"SI_DISKSIZE_${disk_num}
    if [[ $curr_disk_size -ge "204800" ]] ; then
        if [ -z $found_1 ] ; then
            found_1=$curr_disk
        else
            found_2=$curr_disk
            break
        fi
    fi
done

# Now, install them into the manifest.
# Let the installer take the default action if two large disks are not found.

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

if [[ -n $found_2 ]] ; then
    # Turn on mirroring.
    vdev=$(/usr/bin/aimanifest add -r \
        /auto_install/ai_instance/target/logical/zpool/vdev@redundancy mirror)
    /usr/bin/aimanifest set ${vdev}@name mirror_vdev

    disk=$(/usr/bin/aimanifest add -r \
        /auto_install/ai_instance/target/disk@in_vdev mirror_vdev)
    disk_name=$(/usr/bin/aimanifest add -r ${disk}/disk_name@name $found_1)
    /usr/bin/aimanifest set ${disk_name}@name_type ctd

    disk=$(/usr/bin/aimanifest add -r \
        /auto_install/ai_instance/target/disk@in_vdev mirror_vdev)
    disk_name=$(/usr/bin/aimanifest add -r ${disk}/disk_name@name $found_2)
    /usr/bin/aimanifest set ${disk_name}@name_type ctd
fi

exit $SCRIPT_SUCCESS

Le script suivant est une version Python de la version Korn shell précédente.

#!/usr/bin/python2.6

import os
import sys

from subprocess import check_call, CalledProcessError

SCRIPT_SUCCESS = 0
SCRIPT_FAILURE = 1

def main():

    # Find the disks first.
    found_1 = ""
    found_2 = ""

    si_numdisks = int(os.environ["SI_NUMDISKS"])
    for disk_num in range(1, si_numdisks + 1):
        curr_disk_var = "SI_DISKNAME_" + str(disk_num)
        curr_disk = os.environ[curr_disk_var]
        curr_disk_size_var = "SI_DISKSIZE_" + str(disk_num)
        curr_disk_size = os.environ[curr_disk_size_var]
        if curr_disk_size >= "204800":
            if not len(found_1):
                found_1 = curr_disk
            else:
                found_2 = curr_disk
                break

    # Now, write the disk specifications into the manifest.
    # Let the installer take the default action if two large disks are not found.

    try:
        check_call(["/usr/bin/aimanifest", "load",
            "/usr/share/auto_install/manifest/default.xml"])
    except CalledProcessError as err:
        sys.exit(err.returncode)

    if len(found_2):
        try:
            check_call(["/usr/bin/aimanifest", "add",
               "target/logical/zpool[@name=rpool]/vdev@redundancy", "mirror"])
            check_call(["/usr/bin/aimanifest", "set",
               "target/logical/zpool/vdev[@redundancy='mirror']@name", "mirror_vdev"])

            check_call(["/usr/bin/aimanifest", "add",
                "target/disk/disk_name@name", found_1])
            check_call(["/usr/bin/aimanifest", "set",
                "target/disk/disk_name[@name='" + found_1 + "']" + "@name_type", "ctd"])
            check_call(["/usr/bin/aimanifest", "set",
                "target/disk[disk_name@name='" + found_1 + "']" + "@in_vdev", "mirror_vdev"])

            check_call(["/usr/bin/aimanifest", "add",
                "target/disk/disk_name@name", found_2])
            check_call(["/usr/bin/aimanifest", "set",
                "target/disk/disk_name[@name='" + found_2 + "']" + "@name_type", "ctd"])
            check_call(["/usr/bin/aimanifest", "set",
                "target/disk[disk_name@name='" + found_2 + "']" + "@in_vdev", "mirror_vdev"])
        except CalledProcessError as err:
            sys.exit(err.returncode)

    sys.exit(SCRIPT_SUCCESS)

if __name__ == "__main__":
    main()
Exemple 10-4  Spécification des packages à installer en fonction de l'adresse IP

Cet exemple permet de personnaliser le manifeste AI pour installer un package si l'adresse IP du client se trouve dans une plage spécifiée et installer un autre package si l'adresse IP du client se trouve dans une autre plage. Définissez SI_HOSTADDRESS dans votre environnement de test avant d'exécuter le script. Cette variable d'environnement sera définie et disponible pour les scripts de manifeste dérivé lors des installations AI.

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

# First determine which range the host IP address of the client is in.
echo $SI_HOSTADDRESS | sed 's/\./ /g' | read a b c d

# Assume all systems are on the same class A and B subnets.

# If the system is on class C subnet = 100, then install the /pkg100 package.
# If the system is on class C subnet = 101, then install the /pkg101 package.
# Otherwise, do not install any other additional package.

if ((c == 100)) ; then
    /usr/bin/aimanifest add \
    software/software_data[@action='install']/name pkg:/pkg100
fi
if ((c == 101)) ; then
    /usr/bin/aimanifest add \
    software/software_data[@action='install']/name pkg:/pkg101
fi

exit $SCRIPT_SUCCESS
Exemple 10-5  Spécification que la taille du disque cible doit être au moins égale à une certaine taille

Cet exemple permet de personnaliser le manifeste AI pour ne procéder à l'installation que sur un disque d'au moins 50 Go. Ignorez les disques de volume inférieur. Définissez SI_NUMDISKS, SI_DISKNAME_1 et SI_DISKSIZE_1 dans votre environnement de test avant d'exécuter le script. Définissez également SI_DISKNAME_2, SI_DISKSIZE_2 et tous les autres, si nécessaire, en fonction de la valeur que vous définissez pour SI_NUMDISKS. Ces variables d'environnement seront définies et disponibles pour les scripts de manifeste dérivé lors des installations AI.

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

typeset found
typeset -i disk_num
for ((disk_num = 1; disk_num <= $SI_NUMDISKS; disk_num++)) ; do
    eval curr_disk="$"SI_DISKNAME_${disk_num}
    eval curr_disk_size="$"SI_DISKSIZE_${disk_num}
    if [[ $curr_disk_size -ge "512000" ]] ; then
        found=$curr_disk
        /usr/bin/aimanifest add \
            /auto_install/ai_instance/target/disk/disk_name@name $found
        break
    fi
done

if [[ -z $found ]] ; then
    exit $SCRIPT_FAILURE
fi

exit $SCRIPT_SUCCESS
Exemple 10-6  Ajout d'un profil de configuration système

Il arrive qu'une modification de la configuration système soit nécessaire pour chaque client. Plutôt que de devoir créer un profil de configuration système individuel sur le serveur AI pour chaque client, vous pouvez configurer un script de manifeste dérivé pour créer le profil pour vous. Le profil doit être enregistré dans /system/volatile/profile afin de pouvoir utiliser le service d'installation. Dans cet exemple, les paramètres du routeur local par défaut sont utilisés lorsque le client est reconfiguré.

ROUTER-CONFIG=/system/volatile/profile/router-config.xml
ROUTER=`netstat -rn | grep "^default" | awk '{print $2}'`

cat<<EOF>${ROUTER-CONFIG}
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
 <service_bundle type="profile" name="router">
   <service name="network/install" version="1" type="service">
     <instance name="default" enabled="true">
       <property_group name="install_ipv4_interface" type="application">
         <propval name="default_route" type="net_address_v4" value="${ROUTER}"/>
       </property_group>
     </instance>
   </service>
 </service_bundle>
EOF
Exemple 10-7  Scripts avec spécifications de manifeste incorrectes

Le script de cet exemple contient des erreurs.

#!/bin/ksh93

SCRIPT_SUCCESS=0
SCRIPT_FAILURE=1

function handler
{
    exit $SCRIPT_FAILURE
}

trap handler ERR

/usr/bin/aimanifest load /usr/share/auto_install/manifest/default.xml

/usr/bin/aimanifest set \
    software[@type="IPS"]/software_data/name pkg:/driver/pcmcia
/usr/bin/aimanifest set \
    software/software_data[@name=pkg:/driver/pcmcia]@action uninstall

return $SCRIPT_SUCCESS

    Cet exemple comporte trois problèmes d'écriture sur $AIM_MANIFEST.

  1. La sous-commande set de aimanifest peut modifier la valeur d'un élément existant ou d'un attribut ou créer un nouvel attribut. La sous-commande set ne peut pas créer un nouvel élément. La première sous-commande set tente de modifier un nom de package existant dans le manifeste au lieu de créer un nouveau nom de package. Si plusieurs noms de package existent déjà dans le manifeste, une erreur d'ambiguïté se produit car il est impossible de déterminer le package à modifier. La première sous-commande set dans cet exemple doit être une sous-commande add.

  2. Dans la deuxième sous-commande set de cet exemple, un élément name avec la valeur pkg:/driver/pcmcia est précédée d'un signe @. Bien que les valeurs d'attributs soient précédées d'un signe @, les valeurs d'éléments ne le sont pas.

  3. La valeur pkg:/driver/pcmcia doit être placée entre guillemets. Les valeurs comprenant des barres obliques ou d'autres caractères spéciaux doivent être mises entre guillemets.

Les deux lignes set dans cet exemple doivent être remplacées par les lignes suivantes :

/usr/bin/aimanifest add \
    software[@type="IPS"]/software_data@action uninstall
/usr/bin/aimanifest add \
    software/software_data[@action=uninstall]/name pkg:/driver/pcmcia

Ces deux sous-commandes add ajoutent les lignes suivantes à la fin de la section software du manifeste en cours d'écriture :

<software_data action="uninstall">
  <name>pkg:/driver/pcmcia</name>
</software_data>

Test des scripts de manifeste dérivé

    Pour tester votre script de manifeste dérivé, exécutez le script dans un environnement similaire à l'environnement d'installation AI.

  1. Configurez un manifeste AI pour le script à modifier.

    1. Assurez-vous que la première commande aimanifest dans votre script est une commande aimanifest load. Assurez-vous que le fichier en cours de chargement contient une définition <!DOCTYPE> qui spécifie le DTD approprié à utiliser de sorte que le manifeste AI soit validé pour le service d'installation cible. L'exemple suivant montre le fichier manifeste de base minimum pour un manifeste AI, y compris le fichier DTD AI pour le service d'installation où ce script de manifeste dérivé sera ajouté :

      <!DOCTYPE auto_install SYSTEM "file:///imagepath/auto_install/ai.dtd.1">
      <auto_install/>

      La valeur de l'argument imagepath correspond au chemin renvoyé par la commande suivante, où svcname correspond au nom du service d'installation auquel ce script de manifeste dérivé sera ajouté :


      Remarque -  Assurez-vous de réinitialiser le chemin d'image au chemin par défaut, ///usr/share, avant d'essayer d'utiliser le script sur un client.
      $ installadm list -v -n svcname| grep Image
    2. Définissez AIM_MANIFEST sur un emplacement où le script va développer le manifeste AI. Cet emplacement doit être accessible en écriture par l'utilisateur non privilégié aiuser.


      Remarque - Lorsqu'AI procède à l'installation, AIM_MANIFEST n'a pas besoin d'être défini. AI définit une valeur par défaut.
  2. Définissez AIM_LOGFILE sur un emplacement où le script peut écrire des informations détaillées et des messages d'erreur. Cet emplacement doit être accessible en écriture par l'utilisateur non privilégié aiuser.


    Remarque - Lorsqu'AI procède à l'installation, AIM_LOGFILE n'a pas besoin d'être défini. Ces informations du journal font partie du journal d'installation plus grand, /system/volatile/install_log.
  3. Assurez-vous que la commande aimanifest est disponible sur le système sur lequel vous testez le script. Si la commande aimanifest n'est pas disponible, installez le package auto-install-common.

  4. Définissez des variables d'environnement dans l'environnement de test avec des valeurs représentant les systèmes client qui seront installés à l'aide de ce script de manifeste dérivé. Le fichier exemple /usr/share/auto_install/derived_manifest_test_env.sh peut être utilisé comme modèle. Modifiez les valeurs selon le cas.

    Lorsque l'AI procède à l'installation, les variables d'environnement répertoriées dans le Table 10–1 ont des valeurs et sont disponibles pour un script de manifeste dérivé à utiliser.

  5. Assurez-vous que vous êtes en mesure de prendre le rôle root. Dans le rôle root, vous pouvez prendre le rôle aiuser sans indiquer de mot de passe.

    $ su
    Password: 
    # su aiuser -c ./script
    # 

    AI exécute le script de manifeste dérivé en tant que rôle aiuser. Pour se rapprocher de l'environnement d'installation AI, prenez le rôle aiuser pour l'exécution du script. Si vous exécutez le script en tant qu'utilisateur disposant d'autres privilèges que ceux du rôle aiuser, certaines opérations dans le script peuvent avoir des résultats différents.

  6. Utilisez la sous-commande validate sur le manifeste qui en résulte.

    $ /usr/bin/aimanifest validate

    Des messages s'affichent uniquement si la validation échoue.

Le système client prévu peut être très différent du serveur AI ou d'un autre système sur lequel vous pouvez tester le script de manifeste dérivé. Les commandes que vous appelez dans le script peuvent être indisponibles ou il peut s'agir d'une autre version avec un comportement différent. Les systèmes peuvent avoir des architectures différentes ou des disques de nombre et de taille différents. La définition de variables d'environnement dans l'environnement de test comme décrit permet de tenir compte de ces différences.

Test du script de manifeste dérivé dans un environnement d'installation

Cette procédure décrit les étapes à suivre pour tester le script de manifeste dérivé sur l'un des systèmes client prévu sans avoir à exécuter le processus d'installation complet.

  1. Initialisez une image AI sur ce système client.

    Initialisez une image AI sur ce système client en mode "programme d'installation en mode texte et ligne de commande".

  2. Sélectionnez Shell dans le menu initial du programme d'installation.
  3. Copiez votre script depuis le serveur AI.

    Utilisez wget ou sftp pour copier votre script depuis le serveur AI.

  4. Déboguez le script.

    Utilisez l'une des méthodes suivantes pour déboguer le script :

    • Exécutez le script manuellement.
    • Exécutez AI en mode de test.

      Utilisez la commande suivante pour exécuter AI en mode de test :

      $ auto-install -m script -i

    Examinez le fichier journal AI /system/volatile/install_log. Le fichier journal doit contenir la ligne suivante pour indiquer que le script est valide :

    Derived Manifest Module: XML validation completed successfully
  5. Copiez de nouveau le script sur le serveur AI.

    Copiez de nouveau le script sur le serveur AI, si des modifications ont été apportées.