Chapitre 2 Conception et création d'images Oracle Solaris

Pour concevoir et créer des images Oracle Solaris avec le constructeur de distribution, réalisez les quatre tâches suivantes.

La création d'une machine virtuelle nécessite des instructions particulières, qui diffèrent des instructions générales ci-dessous. Pour créer une machine virtuelle, reportez-vous au Chapitre 3x86 : conception et création d'une machine virtuelle.

1. Vérifiez la section Configuration système requise et installez l'application du constructeur de distribution sur votre système.

2. Facultatif : Personnalisation de l'image en modifiant les fichiers manifest.

3. Facultatif : Personnalisation avancée d'une image à l'aide des scripts de finalisation.

4. Création d'une image.

Pour obtenir des instructions complètes, reportez-vous aux sections suivantes.

Configuration système requise

Pour pouvoir utiliser le constructeur de distribution, configurez les fonctionnalités suivantes sur votre système.

# pkg install distribution-constructor

Personnalisation de l'image en modifiant les fichiers manifest

Le constructeur de distribution crée des images en fonction des paramètres indiqués dans des fichiers XML, appelés fichiers manifest. Les fichiers manifest contiennent les spécifications relatives au contenu et aux paramètres des images ISO créées à l'aide du constructeur de distribution. Le constructeur de distribution contient des fichiers manifest par défaut permettant de créer un Live CD, une image du programme d'installation en mode texte x86 ou SPARC, une image ISO d'installation automatisée x86 ou SPARC ou une image de machine virtuelle personnalisés.

Spécifiez des paramètres manifest, tels que :

• Nom des packages à inclure dans l'image

• Emplacement réseau du référentiel auquel accéder pour récupérer les packages pour l'image

• Nom et emplacement des scripts utilisés pour terminer la création de la nouvelle image

Lorsque vous utilisez le constructeur de distribution pour créer des images ISO, notez les points suivants :

L'archive root pour les images x86 diffère de l'archive root pour les images SPARC. L'archive whole root, ou boot_archive, pour les images x86, est un système de fichiers UFS compressé à l'aide de gzip. La plate-forme SPARC ne prend pas en charge la compression de l'archive whole root de cette manière. Au lieu de cela, les archives SPARC utilisent DCFS, qui compresse chaque fichier individuellement. Ces fichiers compressés séparément peuvent nécessiter un traitement spécifique dans le fichier manifest. Pour plus d'instructions, reportez-vous au champ <boot_archive_contents> de la page de manuel dc_manifest(4).

Les fichiers manifest par défaut inclus dans le package distribution-constructor sont répertoriés dans le tableau ci-dessous.

/usr/share/distro_const/slim_cd/
all_lang_slim_cd_x86.xml

/usr/share/distro_const/
text_install/text_mode_x86.xml

/usr/share/distro_const/
text_install/text_mode_sparc.xml

/usr/share/distro_const/
auto_install/ai_sparc_image.xml

/usr/share/distro_const/
auto_install/ai_x86_image.xml

/usr/share/distro_const/
vmc/vmc_image.xml

Modification du contenu des fichiers manifest

Tous les champs des fichiers manifest fournissent des valeurs par défaut, prédéfinies, qui créent le type d'image ISO dont vous avez besoin, ainsi que, pour les systèmes x86, des images USB. Vous pouvez modifier manuellement ces champs prédéfinis dans un fichier manifest afin de personnaliser davantage l'image obtenue.

Si vous souhaitez modifier les informations d'un fichier manifest, effectuez la procédure suivante :

1. Copiez un des fichiers manifest par défaut et créez un fichier manifest personnalisé avec un nouveau nom de fichier.

   Vous ferez référence au fichier manifest par son nom lorsque vous utiliserez la commande distro_const pour créer une image.

   ---

   Remarque –

   Sauvegardez toujours le fichier manifest d'origine et les scripts par défaut avant de les copier.

   ---

2. Modifiez les champs du fichier manifest selon vos besoins. Reportez-vous à la page de manuel dc_manifest(4) pour obtenir des instructions.

3. Si les scripts de finalisation par défaut ne laissent pas build_area comme vous le souhaitez, vous pouvez créer vos propres scripts pour procéder à des modifications supplémentaires. Si vous créez de nouveaux scripts, mettez à jour les références de script dans la section de finalisation du fichier manifest.

   Pour les instructions sur la modification de la section relative au script de finalisation dans le fichier manifest, reportez-vous à la page de manuel dc_manifest(4).

   Pour obtenir des instructions sur la création de nouveaux scripts, reportez-vous à la section Personnalisation avancée d'une image à l'aide des scripts de finalisation.

4. Une fois toutes les modifications apportées au fichier manifest, et, éventuellement, les scripts de finalisation personnalisés comme décrit à la section suivante, vous pouvez passer à l'exécution de l'utilitaire distro_const pour créer une image. Pour plus d'instructions, reportez-vous à la section Création d'une image.

Personnalisation avancée d'une image à l'aide des scripts de finalisation

Le constructeur de distribution vous permet de spécifier les scripts qui peuvent être utilisés afin de personnaliser l'installation selon le type d'images créées. Ces scripts sont appelés scripts de finalisation. Les fichiers manifest désignent les scripts de finalisation, et ceux-ci transforment l'image générique en une distribution spécifique au support. Un ensemble de scripts par défaut est fourni dans les packages d'application.

L'application du constructeur de distribution inclut les scripts par défaut dans le répertoire /usr/share/distro_const et ses sous-répertoires. Ces scripts sont référencés dans la section de finalisation des fichiers manifest.

Par exemple, le tableau suivant répertorie certains scripts de finalisation par défaut utilisés pour créer un Live CD ou « Slim CD » x86.

Création de scripts de finalisation personnalisés

Il est recommandé d'utiliser les scripts de finalisation fournis sans les modifier. Vous pouvez toutefois écrire et ajouter vos propres scripts afin d'effectuer d'autres opérations, comme décrit ci-dessous. Si vous créez de nouveaux scripts, modifiez les fichiers manifest pour qu'ils les désignent.

La prise en charge des scripts est limitée aux scripts par défaut, non modifiés, fournis avec les packages d'application. Si vous décidez de personnaliser ces scripts, sauvegardez les scripts d'origine au préalable.

1. Concevez vos nouveaux scripts. Utilisez les scripts existants comme modèles pour les nouveaux scripts. Reportez-vous à la section Caractéristiques des scripts de finalisation.

   Consultez également les exemples de scripts personnalisés suivants :

   • Exemple de script permettant d'ajouter des packages à une image

   • Exemple de script permettant de tester d'autres packages

   • Exemple de script permettant d'ajouter un package SVR4 à une image

2. Créez vos nouveaux scripts.

3. Ajoutez les nouveaux scripts au répertoire /usr/local/, à votre répertoire personnel ou ailleurs sur le système ou réseau. Assurez-vous que le rôle root puisse exécuter ces scripts.

4. Ajoutez le nom des nouveaux scripts dans la section de finalisation du fichier manifest approprié. Veillez à spécifier le chemin d'accès complet à vos scripts dans le fichier manifest, même s'ils se trouvent dans le répertoire /usr/share/distro_const.

5. Lorsque vous ajoutez une référence pour un nouveau script dans la section de finalisation d'un fichier manifest, vous devez spécifier un nom de point de contrôle utilisé pour interrompre la création de l'image avant que ce script ait effectué sa tâche ou après. Vous pouvez également inclure un message personnalisé associé au nom du point de contrôle. Si vous n'ajoutez pas un tel message, le chemin du script est utilisé comme message de point de contrôle par défaut.

   ---

   Remarque –

   Attribuez aux points de contrôle des noms explicites plutôt que des nombres. Si de nouveaux scripts sont ajoutés, les nouvelles étapes correspondant à ces nouveaux scripts perturberont l'ordre des points de contrôle numérotés.

   ---

   Par exemple, la référence suivante dans un fichier manifest spécifie le nom de point de contrôle "ba-arch" pour un script d'archivage de l'archive d'initialisation et le message associé est "archivage de l'archive d'initialisation".

   <script name="/usr/share/distro_const/boot_archive_archive.py"> <checkpoint name="ba-arch" message="Boot archive archiving"/> </script>

   Cet exemple vous permet de spécifier une commande distro_const pour créer votre image, ou interrompre ou reprendre la création à partir du point de contrôle "ba-arch". La création d'image s'interrompt juste avant que le script d'archivage de l'archive d'initialisation effectue sa tâche.

   Pour en savoir plus sur le référencement des points de contrôle dans la commande distro_const, reportez-vous à la section Création d'une image par étapes.

Caractéristiques des scripts de finalisation

Lorsque vous créez vos propres scripts de finalisation, prenez en compte les points suivants :

• Les scripts peuvent être des programmes Python, des scripts shell ou des fichiers binaires.

• Les scripts sont exécutés dans leur ordre d'apparition dans le fichier manifest.

• La sortie standard (stdout) et la sortie d'erreur (stderr) des commandes exécutées dans les scripts de finalisation (modules shell et python) sont enregistrées dans les fichiers journaux. La sortie stderr est enregistrée dans le journal simple. Les sorties stdout et stderr sont capturées dans le journal détaillé.

• Le constructeur de distribution transmet cinq arguments initiaux à tous les scripts exécutés. Ces cinq arguments ne sont pas inclus en tant qu'entrées dans le fichier manifest. Le fichier manifest spécifie d'autres arguments transmis après ces cinq arguments. Les arguments initiaux sont les suivants.

PKG_IMG_PATH=$2
/usr/bin/grep jack $PKG_IMG_PATH/etc/passwd >/dev/null
if [[ $? == "0" ]] ; then
   print "Found Jack"
fi 

TMP_DIR=$3
/usr/sbin/mkfile $TMP_DIR/boot_archive_archive
/usr/sbin/lofiadm -a $TMP_DIR/boot_archive_archive 

BR_BUILD=$4      # Boot archive build area

# Set nodename to solaris
echo "solaris" > $BR_BUILD/etc/nodename

MEDIA_DIR=$5
...
DIST_ISO=${MEDIA_DIR}/${DISTRO_NAME}.iso
... 

<argslist>
     "/usr/share/distro_const/slim_cd/slimcd_generic_live.xml"
     ".livecd"
</argslist>

Utilisation du lecteur de fichiers manifest

Le constructeur de distribution transmet le socket du lecteur de fichiers manifest comme premier argument dans les scripts de finalisation. Dans un script shell de finalisation, transmettez cet argument en tant que premier argument à /usr/bin/ManifestRead pour accéder aux données du fichier manifest. Dans un module python, transmettez cet argument pour créer une instance d'un objet ManifestRead().

Les exemples de scripts shell suivants appellent ManifestRead afin de demander l'élément name à partir du fichier manifest. ManifestRead renvoie zéro ou plusieurs éléments, chacun sur sa propre ligne. Si ManifestRead doit rechercher plusieurs éléments, les lignes renvoyées contiennent l'élément recherché et un résultat.

MFEST_SOCKET=$1

VOLNAME=`/usr/bin/ManifestRead ${MFEST_SOCKET} "name"`
if [ "XX${VOLNAME}" == "XX" ] ; then
       print -u2 "$0: Error retrieving volume ID"
       exit 1
fi

L'exemple suivant montre comment utiliser ManifestRead à partir d'un script Python :

from osol_install.ManifestRead import ManifestRead

# get the manifest reader object from the socket
manifest_reader_obj = ManifestRead(MFEST_SOCKET)

# get boot_archive compression type

BR_COMPR_TYPE = get_manifest_value(manifest_reader_obj,
   "img_params/output_image/boot_archive/compression/type")
if (BR_COMPR_TYPE == None):
       raise Exception, (sys.argv[0] +
           ": boot_archive compression type missing from manifest")

Spécification de paires clé-valeur

Une autre méthode pour transmettre des arguments aux scripts consiste à spécifier une paire clé-valeur. Elle est utile pour transmettre le même argument à plusieurs scripts sans duplication. Un script peut accéder à une valeur codée en spécifiant la clé de /usr/bin/ManifestRead à partir du script. Indiquez le socket de serveur comme premier argument, puis précisez les chemins d'accès du nœud aux éléments dont les valeurs sont nécessaires, comme dans les exemples suivants.

Exemple 2–1 Script shell

L'exemple suivant appelle ManifestRead à partir d'un script shell pour obtenir une valeur codée.

...
  MFEST_SOCKET=$1
  ...
  /usr/bin/ManifestRead -k $MFEST_SOCKET iso_sort
  iso_sort_file=`/usr/bin/ManifestRead $MFEST_SOCKET iso_sort`

Exemple 2–2 Script Python

L'exemple suivant appelle ManifestRead à partir d'un script Python pour obtenir la même valeur codée.

from osol_install.ManifestRead import ManifestRead

...
  IS_KEY = True

  iso_sort_file = manifest_reader_obj.get_values("iso_sort", IS_KEY)
  fd = open(iso_sort_file,....)

Création d'une image

Après avoir configuré le fichier manifest que vous avez choisi d'utiliser et, éventuellement, personnalisé les scripts de finalisation, vous êtes prêt à créer une image en exécutant la commande distro_const.

Pour exécuter la commande distro_const, assumez le rôle root en exécutant la commande su -.

Vous pouvez utiliser la commande distro_const pour effectuer l'une des opérations suivantes :

• Créer une image en une seule étape.

• Créer une image, mais interrompre et redémarrer le processus de création selon les besoins pour examiner le contenu de l'image et déboguer les scripts de finalisation en cours d'exécution.

La syntaxe complète de cette commande est la suivante :

Syntax: distro_const build [-R] [-r step] [-p step] [-l] manifest

Création d'une image en une seule étape

Pour exécuter la création complète d'une image sans interruption, utilisez la commande distro_const de base sans option, comme suit :

# distro_const build manifest

Remplacez manifest par le nom du fichier manifest à utiliser comme empreinte pour votre image. La sous-commande build est requise. Lorsque vous tapez cette commande, le constructeur de distribution extrait les packages requis pour l'image et crée l'image selon les spécifications définies dans le fichier manifest.

Création d'une image par étapes

Vous pouvez utiliser les options offertes par la commande distro_const pour arrêter et redémarrer le processus de création à différentes étapes du processus de génération d'image, afin de contrôler et de déboguer votre sélection de fichiers, packages et scripts pour l'image en cours de création. Ce processus d'arrêt et de redémarrage au cours de la création est appelé création de points de contrôle.

La création de points de contrôle prend en charge le processus de développement et de débogage des images. Vous pouvez commencer à créer une image, interrompre le processus à tout moment pour examiner le contenu de l'image, puis reprendre la création de l'image. La création de points de contrôle est facultative.

La fonction de création de points de contrôle est activée par défaut dans le fichier manifest. Toutefois, un jeu de données ZFS ou un point de montage lié à un jeu de données ZFS, doit être spécifié comme zone de construction.

Vous pouvez également désactiver la création de points de contrôle dans le fichier manifest en définissant le paramètre checkpoint_enable sur false.

Utilisez les options de création de points de contrôle disponibles dans la commande distro_const comme décrit dans les instructions de base ci-dessous. Consultez également la page de manuel distro_const(1M).

Création d'une image par étapes à l'aide de l'option de points de contrôle

1. Avant de créer l'image, vérifiez les étapes valides au cours desquelles vous pouvez choisir d'interrompre ou reprendre la création à l'aide de la commande suivante :

   # distro_const build -l manifest

   ---

   Remarque –

   La sous-commande build est requise.

   ---

   Un point de contrôle dans le processus de création est créé après chaque exécution du script de finalisation.

   Cette commande affiche les points de contrôle valides auxquels vous pouvez interrompre ou reprendre la création d'une image. Utilisez les noms d'étapes fournis par cette commande comme valeurs correctes pour les autres options de commande de création de points de contrôle.

   Par exemple, la commande suivante confirme les points de contrôle disponibles, pour un fichier manifest nommé slim_cd_x86.xml.

   # distro_const build -l slim_cd_x86.xml

   Une fois la commande exécutée, les étapes de création de points de contrôle valides s'affichent. Les étapes de création de points de contrôle sont décrites ci-après.

   Step Resumable Description -------------- --------- ------------- im-pop X Populate the image with packages im-mod X Image area modifications slim-im-mod Slim CD image area modifications ba-init Boot archive initialization slim-ba-config Slim CD boot archive configuration ba-config Boot archive configuration ba-arch Boot archive archiving (64-bit) ba-arch-32 Boot archive archiving (32-bit) slim-post-mod Slim CD post boot archive image area modifications grub-setup Grub menu setup post-mod Post boot archive image area modification gen-slim-cont Generate Slim CD image content list iso ISO image creation usb USB image creation

   ---

   Remarque –

   Dans le résultat de la commande, une coche dans le champ de reprise indique que vous pouvez reprendre la création à partir de cette étape.

   ---

2. Utilisez la commande suivante pour créer une image et pour interrompre la création de l'image à l'étape spécifiée.

   # distro_const build -p step manifest

   ---

   Remarque –

   La sous-commande build est requise. Les champs step et manifest sont obligatoires.

   ---

   Par exemple, la commande suivante lance la création d'une image et interrompt la construction avant que l'étape im-mod ne modifie la zone d'image :

   # distro_const build -p im-mod slim_cd_x86.xml

3. Reprenez la création à partir de la dernière étape exécutée ou d'une étape de votre choix, en utilisant l'une des options suivantes :

   • Utilisez la commande suivante pour reprendre la création de l'image à partir d'une étape spécifiée.

     # distro_const build -r step manifest

     ---

     Remarque –

     L'étape spécifiée doit être l'étape à laquelle la création antérieure a été interrompue ou une étape précédente. Une étape ultérieure n'est pas valide. Les champs step et manifest sont obligatoires. La sous-commande build est requise.

     ---

     Par exemple, la commande suivante reprend la création de l'image là où im-mod modifie la zone d'image :

     # distro_const build -r im-mod slim_cd_x86.xml

   • Utilisez la commande suivante pour reprendre la création de l'image à partir de la dernière étape exécutée.

     ---

     Remarque –

     L'argument manifest et la sous-commande build sont requis.

     ---

     # distro_const build -R manifest

     Par exemple, la commande suivante reprend la création de l'image là où le processus avait été interrompu.

     # distro_const build -R slim_cd_x86.xml

Dépannage du constructeur de distribution

Vérifiez les éléments de dépannage suivants.

Des messages d'erreur s'affichent lorsque je télécharge un package

Assurez-vous que la commande pkg(1) sur votre système fonctionne correctement et que votre connexion avec le serveur IPS est stable. Parfois le délai de connexion du serveur IPS arrive à expiration lors du téléchargement d'un grand cluster de packages. Pour effectuer une vérification en dehors de l'environnement du constructeur de distribution, essayez d'imiter ce que le constructeur effectue en termes d'installation des packages. Assumez le rôle root en exécutant la commande su -. Essayez ensuite les commandes suivantes, en confirmant leur fonctionnement.

pkg image-create -F -a opensolaris.org=http://pkg.opensolaris.org
pkg -R /tmp/test_img install SUNWcsd
pkg -R /tmp/test_ima install SUNWcs
pkg -R /tmp/test_img install slim_install

Débogage des fichiers manifest présentant des erreurs de validation

Si un fichier manifest n'est pas validé, comme cela peut être le cas après sa modification, exécutez l'utilitaire ManifestServ dans un mode détaillé pour trouver l'erreur.

L'utilitaire ManifestServ, /usr/bin/ManifestServ, sans aucun argument affiche l'usage suivant :

ManifestServ  
Usage: /bin/ManifestServ [-d] [-h|-?] [-s] [-t] [-v] [-f <validation_file_base> ] 
    [-o <out_manifest.xml file> ] <manifest.xml file> 
where: 
  -d: turn on socket debug output (valid when -s also specified) 
  -f <validation_file_base>: give basename for schema and defval files 
      Defaults to basename of manifest (name less .xml suffix) when not provided 
  -h or -?: print this message 
  -o <out_manifest.xml file>: write resulting XML after defaults and 
      validation processing 
  -t: save temporary file 
      Temp file is "/tmp/<manifest_basename>_temp_<pid> 
  -v: verbose defaults/validation output 
  -s: start socket server for use by ManifestRead 

Le constructeur de distribution valide le fichier manifest par rapport à un schéma XML et un fichier manifest par défaut. ManifestServ vous permet d'effectuer une validation manuelle, en utilisant un mode détaillé qui affiche l'emplacement des problèmes.

Exemple 2–3 Débogage des erreurs de validation de schéma

L'exemple suivant présente un cas dans lequel le fichier manifest n'est pas validé par rapport au schéma. Le message en gras ci-après indique une erreur de validation du schéma.

# distro_const build my_distro.xml 
/usr/share/distro_const/DC-manifest.defval.xml validates 
/tmp/all_lang_slim_cd_x86_temp_7861.xml:350: element pair:
Relax-NG validity error : Element pair failed to validate attributes
/tmp/my_distro_temp_7861.xml fails to validate
validate_vs_schema: Validator terminated with status 3
validate_vs_schema: Validator terminated abnormally
Error validating manifest against schema
/usr/share/distro_const/DC-manifest.rng

# 

Exécutez ManifestServ, /usr/bin/ManifestServ en spécifiant l'option -t afin d'enregistrer le fichier temporaire, et l'option -v pour obtenir une sortie détaillée contenant le numéro de ligne de l'erreur.

# ManifestServ -f /usr/share/distro_const/DC-manifest -t -v manifest_file

ManifestServ -f /usr/share/distro_const/DC-manifest -t -v my_distro.xml 
/usr/share/distro_const/DC-manifest.defval.xml validates 
Checking defaults for name 
Checking defaults for distro_constr_params/distro_constr_flags/stop_on_error 
Checking defaults for distro_constr_params/pkg_repo_default_authority/main/url 
...
...
(omitted content)
...
...
/tmp/my_distro_temp_7870.xml:350: element pair: Relax-NG validity error
: Element pair failed to validate attributes 
/tmp/all_lang_slim_cd_x86_temp_7870.xml fails to validate 
validate_vs_schema: Validator terminated with status 3 
validate_vs_schema: Validator terminated abnormally 
Error validating manifest against schema /usr/share/distro_const/DC-manifest.rng 
Error running Manifest Server 
schema_validate: Schema validation failed for DC manifest /tmp/my_distro_temp_7870.xml 

Le fichier temporaire sera nommé vers la fin de la sortie. Dans l'exemple ci-dessus, le fichier est /tmp/my_distro_temp_7870.xml. Selon les messages d'erreur en gras, ouvrez ce fichier et recherchez le problème à la ligne 350. Dans cet exemple, la ligne 350 ressemble à ceci :

<key_value_pairs> 
    <pair value='/usr/share/distro_const/slim_cd/slimcd_iso.sort' key='iso_sort'/> 
    <pair VaLuE='myvalue' key='mykey'/>
</key_value_pairs>

L'attribut VaLuE est incorrect. Dans cet exemple artificiel, value devrait être en minuscules, comme dans la ligne juste au-dessus. Les messages de la deuxième à la dernière ligne indiquent que la validation du schéma a échoué. Le schéma utilisé pour la validation du constructeur de distribution est /usr/share/distro_const/DC-manifest.xml. Le schéma indique que les seuls attributs pour <pair> sont <value> et <key>, pas <VaLuE>.

Débogage des erreurs de validation sémantique

Une validation sémantique est également réalisée. La validation sémantique contrôle le contenu à la recherche d'erreurs de "signification" et de contexte, et ne contrôle pas uniquement la syntaxe. Par exemple, les scripts de finalisation répertoriés dans un fichier manifest peuvent être validés pour confirmer qu'ils sont des fichiers exécutables.

L'exemple suivant illustre un cas où le fichier manifest ne passe pas la validation sémantique.

# distro_const build -l my_distro_sem.xml 
/usr/share/distro_const/DC-manifest.defval.xml validates 
/usr/share/distro_const/grub_setup.py either doesn't exist 
or is not an executable file 
validate_node: Content "/usr/share/distro_const/grub_setup.py" 
at img_params/output_image/finalizer/script/name did not validate 
Error validating manifest tree content 

La validation sémantique utilise des fonctions afin de mener à bien la validation. Ces fonctions impriment des messages d'erreur expliquant pourquoi le fichier manifest a échoué à la validation. Dans ce cas, le fichier /usr/share/distro_const/grub_setup.py est absent et le message d'erreur indique directement ce problème. Dans ce cas, grub_setup.py doit être restauré, ou, le cas échéant, la référence à ce fichier doit être supprimée du fichier manifest.

Vous pouvez toujours exécuter ManifestServ avec l'option -v pour obtenir plus de détails sur la validation sémantique. Toutefois, si elle est spécifiée, l'option de commande -v indiquera simplement l'échec parmi de nombreuses réussites, ce qui peut donner une sortie plus difficile à lire.

Vérification des données

Une fois la validation et d'autres traitements préalables terminés, ManifestServ demande les données à vider et vérifier. Cette étape est plus utile pour tester le processus utilisant les données que les données elles-mêmes, dans la mesure où les données sont parfaitement visibles dans le fichier manifest même.

Informations supplémentaires relatives à l'installation

Reportez-vous aux ressources supplémentaires suivantes.