Les installations Kickstart nous permettent de créer facilement des scripts et de répliquer des installations sans surveillance ou semi-sans surveillance de Fedora, Red Hat Enterprise Linux ou CentOS. Les instructions nécessaires à l'installation du système d'exploitation sont spécifiées, avec une syntaxe dédiée, dans un fichier Kickstart qui est transmis au programme d'installation d'Anaconda. Dans ce tutoriel nous allons voir comment réutiliser un LUKS déjà existant (Linux Unified Keys Setup) lors de l'exécution d'une installation Kickstart :c'est quelque chose qui ne peut pas être réalisé uniquement avec les instructions Kickstart et qui nécessite quelques étapes supplémentaires.
Dans ce didacticiel, vous apprendrez :
- Comment utiliser un conteneur LUKS existant lors d'une installation Kickstart de Fedora, RHEL ou CentOS
- Comment créer et utiliser un fichier updates.img à utiliser avec le programme d'installation d'Anaconda.
Comment installer Fedora/RHEL/CentOS via kickstart sur un appareil LUKS existant Configuration logicielle requise et conventions utilisées
| Catégorie | Exigences, conventions ou version du logiciel utilisée |
|---|---|
| Système | Fedora/Rhel/CentOS |
| Logiciel | Aucun logiciel spécifique n'est nécessaire pour suivre ce tutoriel. |
| Autre |
|
| Conventions | # - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant sudo commande$ – nécessite que les commandes linux données soient exécutées en tant qu'utilisateur normal non privilégié |
Présentation
Kickstart nous permet de répliquer et de personnaliser facilement les installations du système d'exploitation d'une manière qui est tout simplement impossible à réaliser à partir de l'installateur graphique Anaconda. Nous pouvons, par exemple, déclarer quels packages ou groupes de packages doivent être installés sur le système et ce qui doit être exclu à la place.
Nous avons également la possibilité d'exécuter des commandes personnalisées avant ou après l'installation, en les spécifiant dans le %pre dédié et %post sections du fichier Kickstart respectivement. Nous profiterons de cette dernière fonctionnalité mentionnée pour utiliser un LUKS déjà existant périphérique pendant le processus d'installation.
Chiffrement avec la syntaxe native Kickstart
La création de conteneurs LUKS est assez simple et peut être effectuée en utilisant simplement les instructions de démarrage natives. Voici un exemple :
part pv.01 --ondisk=sda --encrypted --luks-type=luks1 --cipher=aes-xts-plain64 --pbkdf-time=5000 --passphrase=secretpassphrase
Dans l'exemple ci-dessus, en utilisant le part instruction, nous créons un lvm chiffré volume physique sur /dev/sda disque. Nous spécifions le LUKS version à utiliser (luks1 dans ce cas – du moins dans les versions récentes de Fedora, luks2 est devenu la valeur par défaut), le cipher , et le temps, exprimé en millisecondes, à passer pour PBKDF (Fonction de dérivation de clé basée sur le mot de passe) traitement de la phrase secrète (c'est l'équivalent d'utiliser le --iter-time option de cryptsetup ).
Même si ce n'est pas une habitude sûre, nous avons également utilisé le --passphrase de fournir la phrase secrète de chiffrement :sans cette option, le processus d'installation serait interrompu et nous serions invités à en fournir une de manière interactive.
Nous pouvons clairement voir comment, en utilisant Kickstart, nous obtenons beaucoup plus de flexibilité par rapport à une installation traditionnelle ; pourquoi aurions-nous besoin d'effectuer des étapes supplémentaires, alors ? Il y a encore certaines tâches que nous ne pouvons pas réaliser en utilisant uniquement la syntaxe standard de Kickstart. Entre autres choses, nous ne pouvons pas créer LUKS conteneurs sur les périphériques bruts (uniquement sur les partitions) ou spécifiez l'algorithme de hachage à utiliser pour le LUKS configuration de la clé, qui par défaut est définie sur sha256 (rien à redire).
Pour ces raisons, nous pouvons vouloir créer notre configuration de partition avant d'effectuer l'installation, soit manuellement, soit en utilisant des outils comme parted à l'intérieur du %pre section du fichier kickstart lui-même. Nous pouvons également avoir un LUKS existant configuration que nous ne voulons pas détruire. Dans tous ces cas, nous devons effectuer les étapes supplémentaires que nous verrons dans un instant.
La section kickstart %pre
Le %pre section d'un fichier kickstart est la première à être analysée lorsque le fichier est récupéré. Il est utilisé pour exécuter des commandes personnalisées avant le démarrage de l'installation et doit être fermé explicitement avec le %end instruction.
Dans %pre , l'interpréteur shell bash est utilisé par défaut, mais d'autres peuvent être spécifiés via le --interpreter option (pour utiliser python nous écrirons %pre --interpreter /usr/bin/python ). Nous pouvons utiliser cette section pour exécuter les commandes nécessaires pour ouvrir le LUKS existant récipient. Voici ce que nous pouvons écrire :
%pre
iotty="$(tty)"
exec > "${iotty}" 2> "${iotty}"
while true; do
cryptsetup luksOpen /dev/sda1 cryptroot - && break
done
%end
Jetons un coup d'œil au code ci-dessus. Tout d'abord, nous stockons le résultat du tty commande, qui imprime le nom de fichier du terminal connecté à l'entrée standard, dans le iotty variables.
Avec le exec> "${iotty}" 2> "${iotty}" commande, nous avons redirigé la sortie standard et l'erreur standard vers le même terminal :
de cette façon, nous pourrons entrer le mot de passe du conteneur lorsque le crytpsetup luksOpen La commande sera exécutée et l'invite s'affichera à l'écran. La commande est lancée dans une boucle infinie qui n'est interrompue que si le LUKS le conteneur est ouvert avec succès.
Si nous voulons exécuter une installation complètement sans surveillance, nous devons transmettre la phrase de passe directement à cryptsetup (encore une fois, ce n'est pas recommandé). On écrirait :
%pre echo -n "ourverysecretpassphrase" | cryptsetup luksOpen /dev/sda1 cryptroot - %end
Dans l'exemple ci-dessus, nous avons passé la phrase secrète à l'entrée standard de la commande cryptsetup via un tube | :nous avons utilisé le echo commande avec le -n option pour éviter qu'un caractère de nouvelle ligne soit ajouté à la fin de la phrase secrète.
Patch du programme d'installation anaconda de Fedora 31
Si nous essayons d'utiliser un conteneur LUKS déverrouillé lors de l'installation de Fedora 31 via Kickstart, nous recevrons le message suivant
et le processus sera abandonné :
L'appareil LUKS déverrouillé existant ne peut pas être utilisé pour l'installation sans une clé de cryptage spécifiée pour cet
appareil. Veuillez réanalyser le stockage.
Cela est dû à ce commit introduit dans la version Fedora 31 du programme d'installation d'Anaconda. Le code vérifie essentiellement qu'un périphérique LUKS existant a une clé enregistrée, si ce n'est pas le cas, l'installation est abandonnée. Le problème est que blivet , la bibliothèque python utilisée par Anaconda pour gérer la partition n'acquiert la clé que si le conteneur est ouvert par celle-ci :cela peut être fait à partir de l'installateur graphique mais il n'y a pas, au moment de la rédaction, d'instruction Kickstart pour déverrouiller un LUKS récipient. J'ai personnellement commenté le commit expliquant la situation, et un bogue a été ouvert sur red hat bugzilla.
Création d'un fichier updates.img
Pour le moment, la seule solution de contournement (que je connaisse) consiste à corriger le code source d'Anaconda, en commentant la ligne qui exécute le contrôle introduit avec le commit mentionné ci-dessus. La bonne nouvelle est qu'il s'agit d'une opération très simple.
Dans un premier temps, nous devons cloner le référentiel git Anaconda, en particulier le f31-release branche :
$ git clone https://github.com/rhinstaller/anaconda -b f31-release
Une fois le repo cloné, nous entrons dans le anaconda répertoire et modifiez le pyanaconda/storage/checker.py fichier :il suffit de commenter la ligne 619 :
def set_default_checks(self):
"""Set the default checks."""
self.checks = list()
self.add_check(verify_root)
self.add_check(verify_s390_constraints)
self.add_check(verify_partition_formatting)
self.add_check(verify_partition_sizes)
self.add_check(verify_partition_format_sizes)
self.add_check(verify_bootloader)
self.add_check(verify_gpt_biosboot)
self.add_check(verify_swap)
self.add_check(verify_swap_uuid)
self.add_check(verify_mountpoints_on_linuxfs)
self.add_check(verify_mountpoints_on_root)
#self.add_check(verify_unlocked_devices_have_key)
self.add_check(verify_luks_devices_have_key)
self.add_check(verify_luks2_memory_requirements)
self.add_check(verify_mounted_partitions)
On sauve la modification et, depuis la racine du repository, on lance les makeupdates script qui se trouve dans les scripts annuaire. Pour que le script soit exécuté, nous devons avoir python2 installé :
$ ./scripts/makeupdates
Le script générera le updates.img fichier qui contiendra nos modifications. Pour vérifier son contenu, nous pouvons utiliser le lsinitrd commande :
$ lsinitrd updates.img Image: updates.img: 8.0K ======================================================================== Version: Arguments: dracut modules: ======================================================================== drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 . drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install/updates drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install/updates/pyanaconda drwxr-xr-x 2 egdoc egdoc 0 Jan 30 09:29 run/install/updates/pyanaconda/storage -rw-r--r-- 1 egdoc egdoc 25443 Jan 30 09:29 run/install/updates/pyanaconda/storage/checker.py ========================================================================
Nous utiliserons ce fichier pour « patcher » le programme d'installation de Fedora 31.
Appliquer le correctif
Pour appliquer les modifications contenues dans le fichier que nous venons de générer, nous devons le placer quelque part où nous pouvons facilement y accéder, peut-être via ftp ou http, ou même sur un périphérique de bloc local, et utiliser le inst.updates paramètre pour le référencer à partir de l'image du programme d'installation de Fedora. Dans le menu grub, nous mettons en surbrillance l'entrée de menu "Installer Fedora" :
Menu d'installation de Fedora 31
Une fois la ligne de menu sélectionnée, on appuie sur la touche Tab :la ligne de commande du noyau associée à l'entrée s'affiche en bas de l'écran :
La ligne de commande du noyau utilisée par l'entrée "Install Fedora" Tout ce que nous avons à faire maintenant est d'ajouter le
inst.updates instruction et fournissez le chemin vers le fichier updates.img fichier que nous avons créé. En supposant que le fichier Kickstart et le fichier updates.img soient accessibles via http sur un serveur local avec l'ip 192.168.0.37, nous écrirons :vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_31-31 quiet inst.updates=http://192.168.0.37/updates.img inst.ks=http://192.168.0.37/ks.cfg
À ce stade, nous pouvons appuyer sur Entrée pour démarrer. Avec la modification ci-dessus, l'installateur ne se plaindra plus de
le LUKS déverrouillé périphérique, et l'installation se déroulera sans problème.
Conclusion
Dans cet article, nous avons vu comment régler une installation kickstart afin de réutiliser un LUKS déjà existant appareil, en le déverrouillant dans le %pre section du fichier kickstart, et comment appliquer une petite solution de contournement au programme d'installation de Fedora 31 Anaconda qui, autrement, échouerait lorsqu'un tel type d'installation est tenté. Si vous êtes curieux de connaître la syntaxe Kickstart, veuillez consulter la documentation en ligne.