Différences

Ci-dessous, les différences entre deux révisions de la page.

--- dossier:machine_titux:cloisonnement_roles_virt_kvm [2026/10/03 06:11] – créée bernard.rolland
+++ dossier:machine_titux:cloisonnement_roles_virt_kvm [2026/10/04 07:36] (Version actuelle) – bernard.rolland
@@ Ligne 6: / Ligne 6: @@
 ===== 1. Phase d'Installation : Déploiement de l'Hyperviseur (QEMU/KVM) =====
-Les commandes de ce bloc doivent être exécutées depuis votre session utilisateur principale dans un terminal (Konsole).
+Les commandes de ce bloc décrivent la pile logicielle active en production.
-==== Étape 1 : Installation de la pile logicielle KVM ====
+==== Étape 1 : Validation de la pile logicielle KVM ====
-Nous demandons à DNF5 d'installer l'interface graphique de gestion (Virt-Manager), le démon de contrôle d'arrière-plan, et les outils d'authentification client :
+L'hyperviseur et ses clients de contrôle sont installés et verrouillés sur les versions de production :
 <code>
 sudo dnf install -y virt-manager libvirt-daemon-kvm libvirt-client
 </code>
-==== Étape 2 : Activation et démarrage du service système ====
+==== Étape 2 : Activation du démon système ====
-Sous Fedora, les services de virtualisation ne sont pas lancés par défaut. Nous activons le démon pour qu'il s'exécute immédiatement et se relance automatiquement à chaque démarrage de la machine :
+Le service d'arrière-plan gérant l'hyperviseur est actif en mémoire vive et configuré pour démarrer automatiquement :
 <code>
 sudo systemctl enable --now libvirtd
 </code>
-===== 2. Phase de Configuration : Gestion de l'Identité Technique =====
+===== 2. Phase de Configuration : L'Identité Technique et le sous-volume vol_tux =====
-==== Étape 1 : Création du profil technique ====
+==== Étape 1 : Modèle de Co-administration ====
-Nous initialisons le compte "tux" en forçant la création de son répertoire personnel pour accueillir ses futurs espaces de stockage isolés :
+L'utilisateur technique **tux** possède une double compétence sur le système :
-<code>
+  * **Accès Hyperviseur** : Rattaché au groupe système ''libvirt'' pour instancier des machines et des conteneurs sans droits root.
-sudo useradd -m -c "Compte Infrastructure Tux" tux
+  * **Accès Co-administrateur** : Rattaché au groupe système ''wheel'' pour configurer le réseau de l'hôte, le pare-feu et créer les profils des utilisateurs tiers.
-</code>
-==== Étape 2 : Sécurisation de l'accès ====
+==== Étape 2 : Pérennité et Isolation du Profil (vol_tux) ====
-Définissez un mot de passe robuste dédié à cette identité technique :
+Pour garantir qu'une réinstallation du système n'affecte pas l'environnement technique, le répertoire personnel ''/home/tux'' est isolé dans son propre sous-volume Btrfs nommé **''vol_tux''**. Ce sous-volume est créé à plat au niveau racine de la partition (Top Level 5).
-<code>
-sudo passwd tux
-</code>
-==== Étape 3 : Directives d'attribution du rôle de Virtualisation ====
+==== Étape 3 : Optimisation Matérielle No_CoW (+C) ====
-Le groupe "libvirt" ayant été créé lors de la phase d'installation de l'hyperviseur, nous pouvons y ajouter l'utilisateur "tux". Cela lui donne le droit de configurer des serveurs complets (comme YunoHost) dans Virt-Manager sans jamais avoir besoin d'utiliser sudo :
+Pour préserver les performances du SSD NVMe face aux écritures aléatoires intensives des outils techniques, le sous-volume autonome vol_tux (monté sur /home/tux) est marqué de manière préventive avec l'attribut d'écriture directe :
 <code>
-sudo usermod -aG libvirt tux
+sudo chattr +C /home/tux/
 </code>
 ===== 3. Phase d'Audit : Vérification de la Conformité (Métrologie) =====
-Ce bloc regroupe les commandes de contrôle permettant de valider de manière indiscutable la bonne santé de la structure avant la mise en production.
+Commandes de contrôle permettant de valider la bonne santé et l'étanchéité de la structure.
-==== Contrôle 1 : Rôles et privilèges de Tux ====
+==== Contrôle 1 : Rôles et privilèges actifs de Tux ====
 <code>
-groups tux
+id tux
 </code>
-* **Résultat probant attendu :** Le terminal doit retourner : "tux : tux libvirt".
+* **Résultat probant attendu** : Le terminal doit retourner l'appartenance aux groupes : ''uid=1001(tux) gid=1001(tux) groupes=1001(tux),10(wheel),967(libvirt)''.
 ==== Contrôle 2 : État du démon de virtualisation ====
@@ Ligne 53: / Ligne 49: @@
 systemctl status libvirtd | grep -E "Active:|Main PID:"
 </code>
-* **Résultat probant attendu :** La ligne doit indiquer explicitement : "Active: active (running)".
+* **Résultat probant attendu** : La ligne doit indiquer explicitement : ''Active: active (running)''.
-==== Contrôle 3 : Accessibilité de l'Hyperviseur ====
+==== Contrôle 3 : Validation du No_CoW ====
 <code>
-virsh --connect qemu:///system uri
+sudo lsattr -d /home/tux
-</code>
-* **Résultat probant attendu :** Le terminal doit vous renvoyer strictement la chaîne : "qemu:///system".
-===== 4. Évolutivité Matérielle & Performance Disque (Le No_CoW) =====
-Les images disques lourdes (fichiers ".qcow2") créées dans Virt-Manager génèrent des écritures aléatoires intensives. Pour éviter l'effondrement des performances du SSD dû au mécanisme Copy-on-Write (CoW) natif de Btrfs, le répertoire accueillant les machines de l'utilisateur technique doit impérativement être créé avec l'attribut d'écriture directe **No_CoW (+C)**.
-Pour appliquer cet attribut de manière préventive sur le dossier de stockage de l'utilisateur technique :
-<code>
-sudo chattr +C /home/tux/
 </code>
-*Note d'ingénierie : L'attribut +C doit impérativement être appliqué sur un dossier vide ou nouvellement créé pour que les futurs fichiers volumineux en héritent nativement.*
+* **Résultat probant attendu** : La console doit afficher la présence de la lettre majuscule ''C'' dans les attributs.
 [[ ./ | retour ]]