Recherche de site Web

Comment installer Fedora/RHEL/CentOS via kickstart sur un appareil LUKS existant

Les installations Kickstart nous permettent de scripter et de répliquer facilement des installations sans surveillance ou semi-automatisées 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 à l’installateur d’Anaconda. Dans ce tutoriel, nous allons voir comment réutiliser un conteneur LUKS (Linux Unified Keys Setup) déjà existant lors de l’installation d’un Kickstart : c’est quelque chose qui ne peut pas être réalisé uniquement avec des instructions Kickstart et qui nécessite quelques étapes supplémentaires.

Dans ce tutoriel, vous allez apprendre :

  • Comment utiliser un conteneur LUKS existant lors de l’installation Kickstart de Fedora, RHEL ou CentOS
  • Comment créer et utiliser un fichier updates.img à utiliser avec l’installateur d’Anaconda.

Comment installer Fedora/RHEL/CentOS via kickstart sur un appareil LUKS existant

Configuration logicielle requise et conventions utilisées

Introduction

Kickstart nous a permis de reproduire et de personnaliser facilement les installations du système d’exploitation d’une manière tout simplement impossible à réaliser à partir de l’installateur graphique Anaconda. Nous pouvons, par exemple, déclarer quels paquets ou groupes de paquets 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 les sections dédiées %pre et %post du fichier Kickstart respectivement. Nous profiterons de cette dernière fonctionnalité pour utiliser un appareil LUKS déjà existant lors du processus d’installation.

Chiffrement avec la syntaxe native Kickstart

La création de conteneurs LUKS est assez facile et peut être effectuée en utilisant simplement les instructions de démarrage natives. En 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 l’instruction part, nous créons un volume physique lvm chiffré sur le disque /dev/sda. Nous spécifions la version de LUKS à utiliser (luks1 dans ce cas – au moins dans les versions récentes de Fedora, luks2 est devenu la valeur par défaut), le chiffrement et le temps, exprimé en millisecondes, à consacrer au traitement de la phrase de passe PBKDF (Password-Based Key Derivation Function) (c’est l’équivalent de l’utilisation de l’option --iter-time de cryptsetup).

Même si ce n’est pas une habitude sûre, nous avons également utilisé la phrase de passe --passphrase pour fournir la phrase de passe 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 accomplir en utilisant uniquement la syntaxe standard de Kickstart. Entre autres choses, nous ne pouvons pas créer de conteneurs LUKS sur des périphériques bruts (uniquement sur des partitions) ou spécifier l’algorithme de hachage à utiliser pour la configuration de la clé LUKS, qui par défaut est définie à 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 dans la section %pre du fichier kickstart lui-même. Il se peut aussi que nous n’ayons qu’une configuration LUKS existante 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

La section %pre d’un fichier kickstart est la première à être analysée lors de la récupération du fichier. Il est utilisé pour exécuter des commandes personnalisées avant le démarrage de l’installation et doit être fermé explicitement avec l’instruction %end.

Dans %pre, l’interpréteur shell bash est utilisé par défaut, mais d’autres peuvent être spécifiés via l’option --interpreter (pour utiliser python, nous écririons %pre --interpreter /usr/bin/python). Nous pouvons utiliser cette section pour exécuter les commandes requises pour ouvrir le conteneur LUKS existant. Voici ce que l’on peut é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 de la commande tty, qui imprime le nom de fichier du terminal connecté à l’entrée standard, dans la variable iotty.

Avec la commande exec > « $ {iotty} » 2> « $ {iotty} », nous avons redirigé la sortie standard et l’erreur standard vers le même terminal :
crytpsetup luksOpen sera exécutée et l’invite sera affichée à l’écran. La commande est lancée dans une boucle infinie qui n’est interrompue que si le conteneur LUKS est ouvert avec succès.

Si nous voulons avoir besoin d’exécuter une installation complètement sans surveillance, nous devons passer la phrase de passe directement à cryptsetup (encore une fois, ce n’est pas recommandé). Nous écririons :

%pre
echo -n "ourverysecretpassphrase" | cryptsetup luksOpen /dev/sda1 cryptroot -
%end

Dans l’exemple ci-dessus, nous avons passé la phrase de passe à l’entrée standard de la commande cryptsetup via un pipe | : nous avons utilisé la commande echo avec l’option -n pour éviter qu’un caractère de saut de ligne ne soit ajouté à la fin de la phrase de passe.

Correctif de l’installateur de Fedora 31 anaconda

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é :

Le périphérique LUKS déverrouillé existant ne peut pas être utilisé pour l’installation sans une clé de cryptage spécifiée pour ce périphérique
. Veuillez réanalyser le stockage.

Cela se produit en raison de ce commit introduit dans la version Fedora 31 de l’installateur d’Anaconda. Le code vérifie essentiellement qu’un appareil LUKS existant dispose d’une clé enregistrée, si ce n’est pas le cas, l’installation est interrompue. Le problème est que blivet, la librairie 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 se faire depuis l’installateur graphique mais il n’y a pas, au moment de la rédaction, d’instruction Kickstart pour déverrouiller un conteneur LUKS existant. J’ai personnellement commenté le commit en expliquant la situation, et un bug 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) est de patcher le code source d’Anaconda, en commentant la ligne qui exécute le contrôle introduit avec le commit que nous avons mentionné ci-dessus. La bonne nouvelle est qu’il est très simple à utiliser.

Tout d’abord, nous devons cloner le dépôt git d’Anaconda, en particulier la branche f31-release :

git clone https://github.com/rhinstaller/anaconda -b f31-release

Une fois le dépôt cloné, on entre dans le répertoire anaconda et on modifie le fichier pyanaconda/storage/checker.py : il ne nous reste plus qu’à 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 sauvegarde la modification et, depuis la racine du dépôt, on lance le script makeupdates qui se trouve dans le répertoire scripts. Pour que le script soit exécuté, nous devons avoir python2 installé :

./scripts/makeupdates

Le script générera le fichier updates.img qui contiendra nos modifications. Pour vérifier son contenu, nous pouvons utiliser la commande lsinitrd :

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 allons utiliser ce fichier pour « patcher » l’installateur de Fedora 31.

Application du 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 paramètre inst.updates pour le référencer à partir de l’image d’installation de Fedora. Dans le menu grub, nous mettons en évidence 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 l’instruction inst.updates et de fournir le chemin vers le fichier updates.img 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’adresse ip 192.168.0.37, nous écririons :

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
du périphérique LUKS déverrouillé, et l’installation se déroulera sans problème.

Conclusions

Dans cet article, nous avons vu comment régler une installation kickstart afin de réutiliser un périphérique LUKS déjà existant, en le déverrouillant dans la section %pre du fichier kickstart, et comment appliquer une petite solution de contournement à l’installateur de Fedora 31 Anaconda qui échouerait autrement lorsqu’un tel type d’installation est tenté. Si vous êtes curieux de connaître la syntaxe Kickstart, veuillez consulter la documentation en ligne.

Articles connexes: