A.3. Scripts dans le fichier Kickstart
Un fichier kickstart peut inclure les scripts suivants :
-
%pre
-
%pre-install
-
%post
Cette section fournit les détails suivants sur les scripts :
- Temps d'exécution
- Types de commandes pouvant être incluses dans le script
- Objectif du scénario
- Options de script
A.3.1. %pre script
Les scripts %pre
sont exécutés sur le système immédiatement après le chargement du fichier Kickstart, mais avant qu'il ne soit complètement analysé et que l'installation ne commence. Chacune de ces sections doit commencer par %pre
et se terminer par %end
.
Le script %pre
peut être utilisé pour l'activation et la configuration des périphériques de réseau et de stockage. Il est également possible d'exécuter des scripts à l'aide des interprètes disponibles dans l'environnement d'installation. L'ajout d'un script %pre
peut s'avérer utile si la mise en réseau et le stockage nécessitent une configuration spéciale avant de procéder à l'installation, ou si vous disposez d'un script qui, par exemple, définit des paramètres de journalisation ou des variables d'environnement supplémentaires.
Le débogage des problèmes avec les scripts %pre
peut s'avérer difficile, il est donc recommandé de n'utiliser un script %pre
qu'en cas de nécessité.
La section %pre
de Kickstart est exécutée à l'étape de l'installation qui se produit après la récupération de l'image d'installation (inst.stage2
) : cela signifie que after root passe à l'environnement d'installation (l'image d'installation) et after l'installateur Anaconda
lui-même démarre. La configuration de %pre
est alors appliquée et peut être utilisée pour récupérer des paquets à partir de référentiels d'installation configurés, par exemple, par URL dans Kickstart. Cependant, elle cannot peut être utilisée pour configurer le réseau afin de récupérer l'image (inst.stage2
) à partir du réseau.
Les commandes relatives au réseau, au stockage et aux systèmes de fichiers sont disponibles dans le script %pre
, en plus de la plupart des utilitaires présents dans les répertoires de l'environnement d'installation /sbin
et /bin
.
Vous pouvez accéder au réseau dans la section %pre
. Cependant, le service de noms n'a pas été configuré à ce stade, de sorte que seules les adresses IP fonctionnent, et non les URL.
Le pré script ne s'exécute pas dans l'environnement chroot.
A.3.1.1. options de la section pré script
Les options suivantes peuvent être utilisées pour modifier le comportement des scripts de pré-installation. Pour utiliser une option, ajoutez-la à la ligne %pre
au début du script. Par exemple :
%pre --interpreter=/usr/libexec/platform-python -- Python script omitted -- %end
--interpreter=
Permet de spécifier un autre langage de script, tel que Python. Tout langage de script disponible sur le système peut être utilisé ; dans la plupart des cas, il s'agit de
/usr/bin/sh
,/usr/bin/bash
et/usr/libexec/platform-python
.Notez que l'interpréteur
platform-python
utilise la version 3.6 de Python. Vous devez modifier vos scripts Python des versions précédentes de RHEL en fonction du nouveau chemin d'accès et de la nouvelle version. En outre,platform-python
est destiné aux outils système : Utilisez le paquetpython36
en dehors de l'environnement d'installation. Pour plus de détails sur Python dans Red Hat Enterprise Linux, reportez-vous à Introduction à Python dans Installing and using dynamic programming languages.--erroronfail
-
Affiche une erreur et interrompt l'installation si le script échoue. Le message d'erreur vous dirige vers l'endroit où la cause de l'échec est enregistrée. Le système installé peut se retrouver dans un état instable et non amorçable. Vous pouvez utiliser l'option
inst.nokill
pour déboguer le script. --log=
Enregistre la sortie du script dans le fichier journal spécifié. Par exemple :
%pre --log=/tmp/ks-pre.log
A.3.2. script de pré-installation
Les commandes du script pre-install
sont exécutées une fois que les tâches suivantes sont terminées :
- Le système est partitionné
- Les systèmes de fichiers sont créés et montés sous /mnt/sysroot
- Le réseau a été configuré conformément aux options de démarrage et aux commandes kickstart
Chacune des sections %pre-install
doit commencer par %pre-install
et se terminer par %end
.
Les scripts %pre-install
peuvent être utilisés pour modifier l'installation et pour ajouter des utilisateurs et des groupes avec des identifiants garantis avant l'installation du paquet.
Il est recommandé d'utiliser les scripts %post
pour toutes les modifications nécessaires à l'installation. N'utilisez le script %pre-install
que si le script %post
ne permet pas d'effectuer les modifications requises.
Remarque : le script The pre-install
ne s'exécute pas dans un environnement chroot.
A.3.2.1. options de la section du script de pré-installation
Les options suivantes peuvent être utilisées pour modifier le comportement des scripts pre-install
. Pour utiliser une option, ajoutez-la à la ligne %pre-install
au début du script. Par exemple :
%pre-install --interpreter=/usr/libexec/platform-python -- Python script omitted -- %end
Notez que vous pouvez avoir plusieurs sections %pre-install
, avec des interprètes identiques ou différents. Elles sont évaluées dans leur ordre d'apparition dans le fichier Kickstart.
--interpreter=
Permet de spécifier un autre langage de script, tel que Python. Tout langage de script disponible sur le système peut être utilisé ; dans la plupart des cas, il s'agit de
/usr/bin/sh
,/usr/bin/bash
et/usr/libexec/platform-python
.Notez que l'interpréteur
platform-python
utilise la version 3.6 de Python. Vous devez modifier vos scripts Python des versions précédentes de RHEL en fonction du nouveau chemin d'accès et de la nouvelle version. En outre,platform-python
est destiné aux outils système : Utilisez le paquetpython36
en dehors de l'environnement d'installation. Pour plus de détails sur Python dans Red Hat Enterprise Linux, voir Introduction à Python dans Installing and using dynamic programming languages.--erroronfail
-
Affiche une erreur et interrompt l'installation si le script échoue. Le message d'erreur vous dirige vers l'endroit où la cause de l'échec est enregistrée. Le système installé peut se retrouver dans un état instable et non amorçable. Vous pouvez utiliser l'option
inst.nokill
pour déboguer le script. --log=
Enregistre la sortie du script dans le fichier journal spécifié. Par exemple :
%pre-install --log=/mnt/sysroot/root/ks-pre.log
A.3.3. %post script
Le script %post est un script de post-installation qui est exécuté une fois l'installation terminée, mais avant le premier redémarrage du système. Vous pouvez utiliser cette section pour exécuter des tâches telles que l'abonnement au système.
Vous avez la possibilité d'ajouter des commandes à exécuter sur le système une fois l'installation terminée, mais avant le premier redémarrage du système. Cette section doit commencer par %post
et se terminer par %end
.
La section %post
est utile pour des fonctions telles que l'installation de logiciels supplémentaires ou la configuration d'un serveur de noms supplémentaire. Le script de post-installation est exécuté dans un environnement chroot
. Par conséquent, l'exécution de tâches telles que la copie de scripts ou de paquets RPM à partir du support d'installation ne fonctionne pas par défaut. Vous pouvez modifier ce comportement en utilisant l'option --nochroot
comme décrit ci-dessous. Le script %post
sera alors exécuté dans l'environnement d'installation, et non dans chroot
sur le système cible installé.
Comme le script de post-installation s'exécute dans un environnement chroot
, la plupart des commandes systemctl
refuseront d'effectuer la moindre action.
Notez que pendant l'exécution de la section %post
, le support d'installation doit toujours être inséré.
A.3.3.1. options de la section post script
Les options suivantes peuvent être utilisées pour modifier le comportement des scripts de post-installation. Pour utiliser une option, ajoutez-la à la ligne %post
au début du script. Par exemple :
%post --interpreter=/usr/libexec/platform-python -- Python script omitted -- %end
--interpreter=
Permet de spécifier un autre langage de script, tel que Python. Par exemple, il est possible de spécifier un langage de script différent, tel que Python :
%post --interpreter=/usr/libexec/platform-python
Tout langage de script disponible sur le système peut être utilisé ; dans la plupart des cas, il s'agit de
/usr/bin/sh
,/usr/bin/bash
et/usr/libexec/platform-python
.Notez que l'interpréteur
platform-python
utilise la version 3.6 de Python. Vous devez modifier vos scripts Python des versions précédentes de RHEL en fonction du nouveau chemin d'accès et de la nouvelle version. En outre,platform-python
est destiné aux outils système : Utilisez le paquetpython36
en dehors de l'environnement d'installation. Pour plus de détails sur Python dans Red Hat Enterprise Linux, voir Introduction à Python dans Installing and using dynamic programming languages.--nochroot
Permet de spécifier les commandes que vous souhaitez exécuter en dehors de l'environnement chroot.
L'exemple suivant copie le fichier /etc/resolv.conf sur le système de fichiers qui vient d'être installé.
%post --nochroot cp /etc/resolv.conf /mnt/sysroot/etc/resolv.conf %end
--erroronfail
-
Affiche une erreur et interrompt l'installation si le script échoue. Le message d'erreur vous dirige vers l'endroit où la cause de l'échec est enregistrée. Le système installé peut se retrouver dans un état instable et non amorçable. Vous pouvez utiliser l'option
inst.nokill
pour déboguer le script. --log=
Enregistre la sortie du script dans le fichier journal spécifié. Notez que le chemin du fichier journal doit tenir compte de l'utilisation ou non de l'option
--nochroot
. Par exemple, sans--nochroot
:%post --log=/root/ks-post.log
et avec
--nochroot
:%post --nochroot --log=/mnt/sysroot/root/ks-post.log
A.3.3.2. Exemple : Montage de NFS dans un script de post-installation
Cet exemple de section %post
monte un partage NFS et exécute un script nommé runme
situé à /usr/new-machines/
sur le partage. Notez que le verrouillage des fichiers NFS n'est pas pris en charge en mode Kickstart, c'est pourquoi l'option -o nolock
est nécessaire.
# Start of the %post section with logging into /root/ks-post.log %post --log=/root/ks-post.log # Mount an NFS share mkdir /mnt/temp mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp openvt -s -w -- /mnt/temp/runme umount /mnt/temp # End of the %post section %end