Bien que la réponse acceptée soit généralement correcte et qu'elle explique bien ce qui se passe, j'ai pensé que je pourrais apporter quelques éclaircissements qui manquent et montrer une variante de mise en œuvre réelle que j'utilise et qui démontre certaines de ces choses.
Tout d'abord, insistons sur le point des "variables". Le site %pre et %post Les blocs sont simplement des enveloppes autour d'un code arbitraire qui n'a aucune signification pour l'installateur. Il considère tout ce qui se trouve dans ces blocs comme un simple texte qui est transmis au programme d'installation. --interpreter . En fait, vous pourriez utiliser %pre --interpreter=/bin/sh et %post --interpreter=/usr/bin/python Dans ce cas, les variables des deux blocs ne seraient même pas syntaxiquement compatibles. Ainsi, la variable "scope" est d'abord locale à un bloc de type %pre/%post à tout le moins, puis serait encore plus restreint selon les règles de "portée" de la langue spécifiées par l'équipe de l --interpreter option.
Maintenant, un point important que la réponse acceptée n'a pas abordé est le %pre est exécuté dans l'environnement d'installation. L'environnement d'installation est comme un live-cd
- Il utilise un système de fichiers résidant en mémoire vive.
- Vous n'avez accès qu'aux commandes et aux utilitaires qui sont inclus dans le système de fichiers de l'installateur.
- Les dispositifs et leurs noms dans l'environnement "install" peuvent différer de ceux de l'environnement "installé".
Par exemple, cette %pre --log /tmp/pre-install.log peut ne pas faire ce que vous attendez. Si l'installation échoue pour une raison quelconque avant que l'installateur ne démarre dans la nouvelle installation, vous pouvez utiliser l'installateur Shell pour cat ce fichier. Mais une fois le redémarrage effectué, tout ce qui a été écrit dans le système de fichiers de l'installateur temporaire sera perdu.
De plus, c'est techniquement incorrect :
Une idée serait d'utiliser des fichiers satellites où conserver vos données (comme vous écrivez un fichier /tmp/f dans votre %pre et le récupérez ensuite dans votre %post... que vous pouvez faire)
Tu pourrais le faire, mais seulement si vous l'écrivez sur un système de fichiers qui persistera à travers les redémarrages, comme un montage USB, iSCSI, NFS, CIFS, etc.
Dans cette optique, suivez le principe KISS (Keep It Simple...) lorsqu'il s'agit de l'élaboration de la politique de l'entreprise. %pre sélection. Il se peut que vous n'ayez pas accès aux commandes/outils/langues les plus avancés ; cela dépendra de ce qui se trouve ou non dans le paquet d'installation et les différentes distros et versions peuvent modifier cela au fil du temps.
A l'inverse, vous avez carte blanche dans le domaine de la santé. %post puisque, à ce moment-là, vous aurez accès à tout ce que vous avez spécifié dans le bloc %packages bloc.
Bien que vous vouliez garder le %pre est simple en termes d'outils et de langages utilisés, plus vous configurez le système à l'aide des commandes de l'installateur, moins vous serez contraint de "patcher" la configuration dans le système d'exploitation. %post bloc.
Exemple de travail - Variation
Lorsque je provisionne de nouveaux hôtes, je commence par collecter et/ou générer trois éléments (dans le cadre de cet exemple) : l'adresse MAC, l'adresse IP et le nom de l'hôte. Si je dispose d'un grand nombre de ces éléments, ils sont généralement placés dans une feuille de calcul de configuration. L'étape suivante consiste à créer des réservations dans le DHCP, ce qui permet de relier l'adresse MAC réelle ou virtuelle à l'adresse IP qui lui est attribuée. L'adresse IP et le nom d'hôte sont ensuite placés dans les zones de recherche directe et inverse du DNS. Vous pouvez utiliser des formules dans la feuille de calcul pour générer les entrées DHCP et DNS afin que cela devienne un exercice de découpage. Une fois le DHCP et le DNS terminés, il suffit de démarrer le boîtier en réseau pour que la configuration correcte se produise. Je trouve qu'une réservation DHCP est un petit prix à payer pour la cohérence et l'efficacité du déploiement et même du redéploiement des instances de serveur.
Voici le fichier de démarrage, qui a été réduit à un peu plus que les entrées pertinentes.
#version=RHEL8
text
%include /tmp/network.ks
eula --agreed
reboot
skipx
%pre
#!/bin/bash
DEVICE=$(ip r|grep default|grep -oP '(?<=dev )\S*')
declare -A value
while IFS= read -r line; do
kvp=${line##DHCP4.OPTION\[*\]:*[ ][ ]}
value+=([${kvp% = *}]=${kvp#* = })
done <<< $(nmcli -f dhcp4 device show $DEVICE)
echo "network --device link --bootproto static --ip ${value[ip_address]} --netmask ${value[subnet_mask]} --gateway ${value[routers]} --hostname ${value[host_name]}.${value[domain_name]} --nameserver ${value[domain_name_servers]} --onboot yes --noipv6" > /tmp/network.ks
%end
%post --log=/root/install-post.log
cat << EOF >> /etc/hosts
$(hostname -i) $(hostname -s) $(hostname -f)
EOF
%end
Puisque j'ai déjà créé une réservation DHCP pour la configuration "Statique" que je souhaite utiliser, dans le fichier %pre bloc que j'utilise nmcli pour obtenir les paramètres DHCP pertinents et les utiliser pour générer dynamiquement les network... pour que le programme d'installation l'utilise. Ce fichier généré dynamiquement est ensuite inclus dans le corps du script de kickstart.
Une chose qui peut sembler un peu confuse ici est l'utilisation de $DEVICE pour interroger le dhcp4 mais j'utilise les paramètres network --device link ... . La raison en est la différence entre les périphériques de l'installateur, qui est ce que je dois interroger, et le nom du ou des périphériques réseau dans le système installé, que je ne force pas en spécifiant le "premier lien actif" et en permettant à l'installateur de nommer les périphériques comme il l'entend. J'ai eu des problèmes dans le passé en supposant que le nom actif dans l'environnement de l'installateur sera le même dans l'environnement installé... et ensuite les choses ont dérapé.
Dans le %post bloquez-moi une chose dont j'ai besoin et qui n'est pas faite par le network... ajoutez l'IP et le nom d'hôte au fichier hosts. Si toutes les étapes précédentes ont configuré le système correctement au moment où la commande %post s'exécute, vous pouvez saisir tout ce dont vous avez besoin directement à partir de la configuration en cours d'exécution... vous n'avez pas besoin de faire persister l'une ou l'autre des informations de la configuration. %pre puisque le système fonctionnera sur elles à ce stade.
