Création d'un manifeste AI lors de l'installation du client

Au lieu de créer des manifestes AI personnalisés avant de procéder à l'installation du client, vous pouvez écrire un script qui crée de manière dynamique un manifeste AI pour chaque client lors de l'installation du client. Le script peut interroger les variables d'environnement et d'autres informations de configuration du client afin de créer un manifeste AI personnalisé pour chaque client. Etant donné que le manifeste est basé sur des attributs des clients découverts lors de l'installation, le manifeste est qualifié de manifeste dérivé.

Un manifeste dérivé est particulièrement utile si vous disposez d'un grand nombre de systèmes pouvant être installés de manière quasi identique de sorte que les différences entre les manifestes AI pour ces systèmes soient relativement faibles. Créez un manifeste AI qui spécifie les paramètres d'installation communs à ce groupe de systèmes. A partir de ce manifeste commun, créez un script de manifeste dérivé qui ajoute les paramètres variant pour chaque client au manifeste commun lors de l'installation des clients. Par exemple, un script de manifestes dérivé peut détecter le nombre et la taille des disques connectés à chaque système client et modifier le manifeste AI lors de l'installation du client de manière à spécifier une configuration de disque personnalisée pour chaque client.

Création et application d'un script de manifestes dérivés

1. Sélectionnez un manifeste à modifier.

   Identifiez un manifeste AI existant qui servira de manifeste de base à modifier.

   Pour développer et tester votre script, vous pouvez travailler avec une copie locale. Au moment de l'installation, le manifeste de base doit être accessible par chaque client utilisant ce script de manifestes dérivés.

2. Rédigez un script pour modifier le manifeste.

   Ecrivez un script pour modifier de façon dynamique le manifeste de base au moment de l'installation en fonction d'attributs du client en cours d'installation.

3. Ajoutez le script au service d'installation.

   Ajoutez le script de manifestes dérivés au service d'installation AI approprié, en spécifiant des critères définissant les clients qui doivent utiliser ce script pour créer leurs instructions d'installation au moment de l'installation. Si vous ne souhaitez pas spécifier de critères de sélection de client, vous pouvez ajouter ce script dans le manifeste AI par défaut pour le service.

   AI exécute le script au moment de l'installation du client pour produire une instance d'un manifeste AI. AI valide la syntaxe du manifeste résultant.

   ---

   Remarque - Si un manifeste n'est pas créé ou si le manifeste dérivé n'est pas validé, l'installation du client est annulée. Pour rechercher la cause de l'échec de la validation, reportez-vous au /tmp/install_log sur le client.

   ---

   Si l'installation du client s'est effectuée correctement, le manifeste dérivé est copié dans /var/log/install/derived/manifest.xml sur le client et le script utilisé pour dériver le manifeste est copié dans /var/log/install/derived/manifest_script.

Création d'un script de manifestes dérivés

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

Un script de manifestes dérivés 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 manifestes dérivés 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, les profils et les privilèges, reportez-vous à la Partie III, Rôles, profils de droits et privilèges du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.

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.

Tableau 10-1 Variables d'environnement des attributs client

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 racine 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 manifestes dérivés sera ajouté :

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

Le # est un nombre entier tel que 1. 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 manifestes dérivés sera ajouté :

$ installadm list -n svcname

La sous-commande load de la commande aimanifest permet de charger un manifeste de base avant tout autre appel de aimanifest dans le script de manifestes dérivés. 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.

La sous-commande add permet d'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 de détails, 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.

/'"@[]=

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

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

#!/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 manifestes dérivés

Cette section montre comment écrire des scripts de manifestes dérivés 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 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, des valeurs d'argument, et renvoie le statut de chaque appel aimanifest à l'écran et au fichier $AIM_MANIFEST_LOG 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 Tableau 10-1 ont des valeurs et sont disponibles pour un script de manifestes dérivés à 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 racine en fonction de l'existence de disques supplémentaires

Cet exemple permet de personnaliser le manifeste AI pour configurer un miroir du pool racine 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 nécessaires, 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 manifestes dérivés 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 nécessaires, 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 manifestes dérivés 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 du 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 manifestes dérivés 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 le 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 nécessaires, 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 manifestes dérivés 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 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 manifestes dérivés

Pour tester vos scripts de manifestes dérivés, 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 manifestes dérivés sera ajouté :

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

      Le # est un nombre entier tel que 1. 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 manifestes dérivés sera ajouté :

      $ installadm list -n svcname

   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. 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 manifestes dérivés 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.

5. 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 du script de manifestes dérivés. Le fichier exemple /usr/share/auto_install/derived_manifest_test_env.sh peut être utilisé comme modèle. Modifiez les valeurs selon le cas.

   Lorsqu'AI procède à l'installation, les variables d'environnement répertoriées dans le Tableau 10-1 ont des valeurs et sont disponibles pour un script de manifestes dérivés à utiliser.

Le système client prévu peut être très différent du serveur d'installation ou d'un autre système sur lequel vous pouvez tester le script de manifestes dérivés. 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 manifestes dérivés

Cette procédure décrit les étapes à suivre pour tester le script de manifestes dérivés sur l'un des systèmes client prévus.

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 d'installation AI.

   Utilisez wget ou sftp pour copier votre script depuis le serveur d'installation 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 d'installation.

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

Ajout d'un script de manifestes dérivés à un service d'installation

Ajoutez un script à un service d'installation AI de la même façon que vous ajoutez un manifeste XML au service d'installation. Utilisez les mêmes options pour spécifier des critères de sélection des clients qui utiliseront ce script pour créer un manifeste pour leur installation. Vous pouvez mettre à jour un script tout comme vous pouvez mettre à jour un manifeste XML. Un script peut être défini comme manifeste par défaut pour le service. Les scripts sont affichés lorsque vous répertoriez des manifestes associés à un service. Le contenu d'un script peut être exporté de la même manière qu'un manifeste XML.

Lorsque vous ajoutez un manifeste XML à un service d'installation, le manifeste est validé. Lorsque vous ajoutez un script à un service d'installation, le script n'est pas validé.

Validez un manifeste AI dérivé avant d'ajouter le script à un service d'installation.

1. Exécutez le script dans un environnement similaire au système client prévu.

2. 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.

Ajoutez le script au service d'installation AI, en spécifiant des critères définissant les clients qui doivent utiliser ces instructions d'installation. Si vous ne souhaitez pas spécifier de critères de sélection de client, vous pouvez utiliser l'option -d pour ajouter ce script dans le manifeste AI par défaut pour le service.

$ pfexec installadm create-manifest -n solaris11_1-i386 -f ./mac1.ksh -m mac1 \
-c mac=BB:AA:AA:AA:AA:AA

Vous pouvez spécifier plusieurs options -c ou un fichier -C. Reportez-vous également à la sous-commande set-criteria. Reportez-vous à la section Chapitre 9, Personnalisation des installations pour plus d'informations sur la spécification de critères de clients.

Reportez-vous à la section Maintenance d'un serveur d'installation pour plus d'informations sur les sous-commandes installadm, list, export, create-manifest, set-criteria, update-manifest et set-service.