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.
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.
|
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
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.
/'"@[]=
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
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
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 :
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.
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.
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.
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.
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_SUCCESSExemple 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_SUCCESSExemple 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> EOFExemple 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.
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.
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.
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>
Pour tester votre script de manifeste dérivé, exécutez le script dans un environnement similaire à l'environnement d'installation AI.
Configurez un manifeste AI pour le script à modifier.
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é :
$ installadm list -v -n svcname| grep Image
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.
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.
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.
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.
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.
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.
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.
Initialisez une image AI sur ce système client en mode "programme d'installation en mode texte et ligne de commande".
Utilisez wget ou sftp pour copier votre script depuis le serveur AI.
Utilisez l'une des méthodes suivantes pour déboguer le script :
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
Copiez de nouveau le script sur le serveur AI, si des modifications ont été apportées.