Why I Stopped Guessing at Linux Distros and Started Asking AI to Reason Through It

Promptez votre chemin vers Linux : une série en 4 parties

Partie 1 : Choisir votre distro → Partie 2 : Stockage et chiffrement → Partie 3 : Installation manuelle → Partie 4 : Services et GPU

J'ai installé Linux plus de fois que je ne peux en compter. À chaque fois, le choix de la distro reposait sur l'instinct ou sur ce que j'avais utilisé la dernière fois. Voilà le problème : si vous construisez quelque chose de précis, l'instinct ne suffira pas. Un nœud cerveau de sécurité qui a besoin de Docker, PostgreSQL, de modèles d'IA locaux et de capture de paquets sur trois disques chiffrés ? C'est un problème d'architecture, pas une question de feeling.

Ce chapitre vous montre comment formuler la conversation pour que l'IA vous fournisse une véritable architecture, et non un résumé Wikipedia. Vous lui soumettrez votre charge de travail réelle, obtiendrez un raisonnement structuré en retour, mapperez votre matériel sur un plan de stockage, et repérerez les problèmes de firmware avant qu'ils ne vous coûtent des heures. À la fin, vous disposerez d'une méthode reproductible qui fonctionne pour n'importe quel projet, n'importe quel matériel, n'importe quelle distro.

Le premier prompt est le plus important

Voici ce que la plupart des gens tapent dans ChatGPT quand ils pensent à Linux :

« Quelle distro Linux devrais-je installer ? »

Et ils obtiennent exactement ce à quoi on pourrait s'attendre : une liste de distributions avec des descriptions superficielles. Ubuntu est convivial pour les débutants. Fedora a des paquets plus récents. Arch est pour les gens qui aiment souffrir. Merci, c'est d'une inutilité remarquable.

Le problème n'est pas l'IA. C'est le prompt. Vous posez une question générique et vous obtenez une réponse générique. Dès que vous passez de « que devrais-je installer » à « voici ce que cette machine doit faire », la conversation change du tout au tout.

Voici le modèle de prompt qui fonctionne vraiment :

1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?

Structure simple. Différence massive dans la qualité des réponses. Vous donnez à l'IA suffisamment de contexte pour raisonner, pas seulement pour réciter.

Ce dont votre projet a réellement besoin

Avant d'envoyer ce prompt, soyez précis sur le rôle. Ne dites pas « un serveur Linux ». Dites ce qu'il fait. Pour un nœud cerveau de sécurité (le projet que cette série parcourt), la liste des charges de travail ressemble à ceci :

• Conteneurs Docker exécutant plusieurs outils et services de sécurité
• PostgreSQL et Redis pour les données structurées et la mise en cache
• Ollama pour exécuter des modèles d'IA locaux (sans dépendance au cloud)
• Futur passage GPU NVIDIA pour l'inférence accélérée
• Stockage d'artefacts d'attaque avec une séparation appropriée de la chaîne de custody
• Stockage multi-disques chiffré sur NVMe, SSD et HDD
• Stabilité à long terme sans ruptures constantes dues aux mises à jour de pointe

Ce n'est plus une question de « quelle distro ». C'est une question d'architecture. Et quand vous la formulez ainsi, l'IA commence à réfléchir aux écosystèmes de paquets, aux calendriers de support du noyau, à la disponibilité des pilotes et aux outils communautaires. Votre rôle est de fournir les contraintes. Le rôle de l'IA est de les analyser.

Comment le raisonnement se décompose

Soumettez à l'IA une liste de charges de travail comme celle-là et vous n'obtiendrez pas seulement une réponse. Vous obtiendrez le raisonnement derrière chaque option. Voici ce à quoi vous attendre :

Kali Linux reçoit la recommandation la plus forte. Il est basé sur Debian, ce qui signifie une gestion des paquets solide et une large compatibilité. Les outils de sécurité sont préinstallés ou accessibles via un simple apt install. Les versions rolling maintiennent les outils à jour sans l'instabilité d'un système comme Arch. Et la communauté est spécifiquement axée sur le type de travail que cette machine effectue.

Ubuntu Server arrive en deuxième position. Excellent support Docker, grande communauté, versions LTS. Mais pour un projet axé sur la sécurité, vous passeriez vos deux premiers jours à installer des outils que Kali fournit par défaut. C'est une base généraliste quand vous avez besoin d'une base spécialisée.

Debian Stable est trop conservateur. Les versions des paquets sont en retard par rapport à ce dont Ollama et les pilotes NVIDIA récents ont besoin. Vous seriez constamment à vous battre avec les backports.

Arch Linux dispose des paquets les plus récents, mais l'instabilité d'une version rolling sur une machine exécutant des bases de données en production et des services Docker est une invitation aux problèmes. Un mauvais pacman -Syu et votre instance PostgreSQL est hors service.

Fedora Server est intéressant mais introduit des outils basés sur RPM qui ne s'alignent pas avec l'écosystème Kali/Debian que la plupart des outils de sécurité ciblent.

Pour ce projet, le choix est Kali. Non pas parce que c'est tendance ou parce qu'une vidéo YouTube le dit, mais parce que le profil de charge de travail correspond directement à ce pour quoi Kali est conçu, et que la base Debian offre la stabilité que Docker et PostgreSQL exigent. Votre projet pourrait pointer ailleurs. C'est tout l'intérêt de laisser l'IA raisonner plutôt que de deviner.

La conversation de découverte du matériel

Une fois la distribution choisie, ne cherchez pas encore l'ISO. Commencez par découvrir exactement avec quel matériel vous travaillez. C'est là que la conversation avec l'IA devient vraiment puissante.

Essayez ce prompt :

1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?

Relisez-le. Vous ne demandez pas « comment vérifier mon CPU ». Vous demandez à l'IA de concevoir toute la séquence de découverte en fonction de ce qu'elle a besoin de savoir pour la planification. C'est une interaction fondamentalement différente. Vous mettez l'IA aux commandes de l'investigation pendant que vous exécutez les commandes et rapportez les résultats.

Ce que l'IA demande (et pourquoi chaque catégorie est importante)

Vous obtiendrez en retour une liste structurée de commandes, regroupées par catégorie. Pas des commandes aléatoires. Un protocole de découverte délibéré. Voici ce à quoi vous attendre :

Mode firmware (ls /sys/firmware/efi ou vérification des paramètres BIOS) : cela détermine toute votre stratégie de démarrage. UEFI signifie des tables de partitions GPT et des partitions ESP. Legacy BIOS signifie MBR et des configurations de chargeur de démarrage différentes. Faites une erreur ici et vous réinstallez.

CPU et RAM (lscpu, free -h) : le nombre de cœurs et la taille de la mémoire déterminent combien de conteneurs Docker vous pouvez exécuter simultanément, si les modèles d'IA locaux tiendront en mémoire, et à quel point votre configuration PostgreSQL peut être agressive.

Inventaire des disques (lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL, fdisk -l) : la taille, le type d'interface (NVMe, SATA) et le statut rotatif de chaque disque. C'est le fondement de l'architecture de stockage.

Modes du contrôleur (paramètres BIOS, dmesg | grep -i ahci) : le mode AHCI vs RAID vs IDE affecte les performances des disques et la compatibilité Linux. Certains contrôleurs en mode RAID masquent les disques individuels à l'installateur.

Matériel GPU (lspci | grep -i vga, lspci -nn | grep -i nvidia) : critique pour deux raisons. Premièrement, les GPU NVIDIA peuvent provoquer des plantages de l'installateur s'ils ne sont pas gérés correctement. Deuxièmement, connaître le modèle exact du GPU détermine quelle version de pilote vous aurez besoin plus tard.

Périphériques réseau (ip link, lspci | grep -i net) : vous avez besoin d'un accès réseau pendant l'installation pour télécharger des paquets. Savoir si vous avez un réseau Intel, Realtek ou Broadcom détermine si vous aurez besoin de paquets firmware.

Tables de partitions existantes (fdisk -l, blkid) : toutes les données ou schémas de partitions existants doivent être compris avant d'effacer quoi que ce soit.

Santé SMART (smartctl -a /dev/sdX) : les données de santé des disques vous indiquent quels lecteurs sont fiables pour le stockage à long terme et lesquels pourraient tomber en panne sous des charges de travail importantes.

Le modèle de flux de travail

Voici comment cela se déroule en pratique :

1. L'IA vous donne un lot de commandes
2. Vous les exécutez dans le terminal
3. Vous collez la sortie dans le chat
4. L'IA interprète les résultats et pose des questions de suivi
5. Répétez jusqu'à ce que le tableau complet se dégage

Vous n'avez pas besoin de comprendre ce que signifie chaque ligne de la sortie de lspci. L'IA la lit, signale ce qui est pertinent et vous dit ce que cela implique pour votre projet. Considérez cela comme un dépannage collaboratif : vous êtes les mains, l'IA est l'analyste. Cette division du travail fonctionne parce que l'IA peut traiter une sortie technique dense plus rapidement que la plupart des humains ne peuvent la lire.

L'IA interprète votre matériel

Une fois que vous avez parcouru les commandes de découverte, voici le type d'inventaire avec lequel vous travaillerez (c'est le matériel exact pour le projet de cette série) :

• SSD NVMe, 1 To : Samsung 970 EVO Plus, ~3 500 Mo/s en lecture séquentielle
• HDD SATA, 1 To : Western Digital Blue, 5 400 RPM, mécanique
• SSD SATA, 128 Go : Kingston plus ancien, correct mais petit, SMART indiquant des événements de température élevée
• GPU : Intel intégré + NVIDIA GeForce (configuration hybride/Optimus)
• RAM : 32 Go DDR4
• CPU : Intel i7, 8 cœurs / 16 threads

Les spécifications brutes ne sont que des chiffres. Ce qui compte, c'est la façon dont l'IA les mappe sur votre charge de travail. Collez la sortie de votre matériel dans le chat et regardez-la dériver une architecture de stockage basée sur la façon dont les caractéristiques de chaque disque correspondent aux exigences que vous avez décrites précédemment.

Architecture de stockage à trois niveaux

Pour un projet multi-disques, l'IA proposera un système à niveaux où chaque disque sert les charges de travail pour lesquelles il est le mieux adapté :

Niveau 1 : NVMe (le cheval de bataille) pour tout ce qui nécessite de la vitesse. Le système d'exploitation, le stockage des conteneurs Docker, les bases de données PostgreSQL, les données Redis et les modèles d'IA Ollama. Ces charges de travail génèrent de lourdes E/S aléatoires, et le NVMe gère cela sans effort. Ce disque reçoit un chiffrement LUKS avec LVM pour une gestion flexible des partitions.

Niveau 2 : SSD SATA (l'espace de travail actif) pour l'analyse en cours. Lorsque vous travaillez sur un cas, vous avez besoin d'un accès rapide aux échantillons extraits, aux sorties temporaires des outils et aux données en cours de traitement. Le SSD de 128 Go offre un accès à vitesse SSD sans polluer le NVMe principal avec des fichiers transitoires. Également chiffré avec LUKS, monté comme espace de travail dédié.

Niveau 3 : HDD SATA (l'archive froide) pour la rétention à long terme. Captures de paquets, exports forensiques, archives de preuves et tout ce qui doit exister mais n'a pas besoin d'un accès rapide. Le disque mécanique est parfait ici : grand, économique et fiable pour les écritures séquentielles. Chiffré avec LUKS avec une clé séparée.

« Ne mettez pas vos bases de données sur des disques rotatifs, et ne gaspillez pas la bande passante NVMe sur des fichiers que vous ouvrez deux fois par an. Faites correspondre le niveau de stockage au modèle d'accès. »

Pourquoi le petit SSD est rejeté comme disque racine

Voici un piège dans lequel vous pourriez tomber : utiliser un SSD plus petit comme disque racine pour garder le NVMe « libre » pour les données. Cela semble logique. L'IA s'y opposera fermement, et voici pourquoi.

Les images Docker et les volumes de conteneurs seuls peuvent consommer 40 à 60 Go sur un poste de travail de sécurité. Ajoutez les répertoires de données PostgreSQL, les fichiers de modèles Ollama (qui peuvent faire 4 à 8 Go chacun) et les paquets système, et vous regardez un minimum de 80 à 100 Go pour une partition racine confortable. Sur un disque de 128 Go, cela laisse presque aucune marge de croissance. Un grand téléchargement Docker et vous êtes à 95 % de capacité.

Les données SMART ajoutent une autre préoccupation. Si le SSD a enregistré des événements de limitation thermique, il n'est pas en train de tomber en panne, mais ce n'est pas non plus le disque que vous voulez comme racine système.

Le NVMe est le choix évident comme disque principal. Plus rapide, plus grand, plus sain, et conçu exactement pour le type de charge de travail mixte aléatoire/séquentielle qu'une partition racine avec Docker et des bases de données génère. N'y réfléchissez pas trop.

La vérification du firmware qui vous fait gagner des heures

C'est là que le processus de découverte se rentabilise avant qu'un seul octet ne touche le disque.

L'une des premières commandes de découverte pourrait révéler que votre machine fonctionne en mode Legacy BIOS. La machine fonctionne bien en mode legacy. Mais pour un projet multi-disques chiffré, c'est incorrect. C'est exactement le genre de chose que l'IA détecte et que vous pourriez ne pas penser à vérifier. Voici pourquoi c'est important :

Legacy BIOS + MBR vous limite à quatre partitions primaires par disque. Pour un projet chiffré à trois disques avec LVM, c'est une vraie contrainte. Vous finissez par utiliser des partitions étendues et des volumes logiques d'une manière qui ajoute une complexité inutile.

UEFI + GPT supprime la limitation du nombre de partitions, prend en charge nativement des tailles de disques plus grandes et offre un processus de démarrage plus propre. Pour un projet multi-volumes chiffré, GPT est simplement la bonne fondation.

Votre prochaine étape si l'IA signale cela : trois modifications du firmware avant l'installation.

1. Passer en mode UEFI dans les paramètres du BIOS
2. Désactiver le Secure Boot (l'installateur de Kali peut gérer le Secure Boot, mais cela ajoute des frictions lors de la configuration initiale et de l'installation des pilotes, surtout avec NVIDIA)
3. Vérifier le mode AHCI pour les contrôleurs SATA (peut déjà être configuré, mais confirmez-le)

C'est le genre de problème que vous ne savez pas chercher jusqu'à ce qu'il vous morde. Le détecter pendant la découverte, avant même que la clé USB ne soit flashée, vous fait gagner un temps et une frustration réels. Le changement de firmware prend cinq minutes dans les paramètres du BIOS. Découvrir le problème en pleine installation signifie tout recommencer depuis le début.

Votre méthode reproductible

Voici à quoi se résume tout ce processus : une méthodologie que vous pouvez utiliser pour n'importe quel projet, n'importe quel matériel, n'importe quelle distribution. Épinglez ceci.

Étape 1 : Décrivez vos objectifs avec précision. Pas « je veux Linux » mais « j'ai besoin d'un système qui exécute ces services, gère ces charges de travail et stocke ce type de données ». Plus vous êtes précis, mieux l'IA peut raisonner sur vos options.

Étape 2 : Laissez l'IA concevoir la découverte. Ne cherchez pas des commandes individuelles sur Google. Dites à l'IA quel rôle elle joue et demandez-lui de concevoir l'investigation. Elle demandera des choses que vous n'auriez pas pensé à vérifier.

Étape 3 : Exécutez et rapportez. Lancez les commandes, collez la sortie. Vous êtes les mains ; l'IA est l'analyste. Cette division du travail fonctionne parce que l'IA peut traiter une sortie technique dense plus rapidement que la plupart des humains ne peuvent la lire.

Étape 4 : Laissez l'IA interpréter par rapport à vos objectifs. Les spécifications brutes sont sans signification sans contexte. Un SSD de 128 Go convient parfaitement comme partition racine pour un serveur multimédia. Il est dangereusement petit pour un poste de travail de sécurité à forte utilisation de Docker. L'IA mappe le matériel sur les exigences de charge de travail et signale les inadéquations que vous manqueriez.

Étape 5 : Itérez jusqu'à ce que le tableau soit complet. La découverte se fait rarement en un seul tour. L'IA posera des questions de suivi. « Que montre smartctl pour ce SSD plus ancien ? » ou « Le GPU NVIDIA est-il l'adaptateur d'affichage principal ? » Chaque tour affine le plan.

« Vous n'avez pas besoin de mémoriser les commandes Linux. Vous devez savoir ce que vous construisez. L'IA gère la traduction entre les objectifs et la mise en œuvre. »

Cette méthodologie fonctionne que vous configuriez un serveur multimédia domestique, un poste de travail de développement, un appareil réseau ou un rig de test de pénétration. Les commandes changent. Le modèle reste le même.

Vous avez maintenant une distro choisie, un inventaire matériel complet, un plan de stockage à niveaux et des paramètres firmware propres. Tout ce qui suit est de l'exécution. La partie 2 prend tout cela et le transforme en un schéma de partitions réel : volumes chiffrés, disposition LVM, points de montage et le script de préparation qui valide tout avant que l'installateur ne touche un disque. C'est là que le projet devient concret.

Prochaine étape : Partie 2 : Stockage et chiffrement couvre la conception des volumes chiffrés, la disposition LVM et le script de vérification de sécurité qui valide votre matériel avant le début de l'installation. Préparez votre terminal.