Différences

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

--- dossier:machine_titux:accueil [2026/10/02 08:12] – bernard.rolland
+++ dossier:machine_titux:accueil [2026/10/04 09:07] (Version actuelle) – bernard.rolland
@@ Ligne 1: / Ligne 1: @@
-====== Architecture Système : Cloisonnement des Rôles et Virtualisation KVM (Fedora 44 KDE) ======
+====== Portail Technique Titux : Post-Installation & Architecture Fedora 44 KDE ======
-Cette page documente la mise en place d'une structure de comptes et de privilèges asymétriques (RBAC) sur une station de travail Linux. L'objectif est de séparer l'identité du quotidien (usage bureautique/personnel) de l'identité technique dédiée au pilotage des infrastructures virtuelles (VMs KVM, conteneurs Podman/Docker).
+Bienvenue sur le portail technique de l'association **Titux**. Cette page sert de guide directeur, de manifeste philosophique et de sommaire pour configurer une station de travail Linux standardisée, performante et hautement évolutive.
-Cette approche garantit une étanchéité totale des données et offre une structure hautement évolutive pour accueillir de futurs services (ex: serveurs YunoHost, environnements de tests) sans corrompre le profil principal de l'utilisateur.
+===== 1. Manifeste Philosophique de l'Architecture Titux =====
-===== 1. Vision Philosophique & Modèle de Sécurité =====
+==== Le Cloisonnement par les Privilèges (RBAC) & La Mission de "Tux" ====
-Plutôt que d'exécuter l'ensemble des tâches d'infrastructure depuis un compte unique doté de privilèges globaux, le système applique le principe du **moindre privilège** à travers deux identités distinctes :
+La sécurité d'un système ne doit pas reposer sur l'usage d'un compte unique "fourre-tout". Nous appliquons le principe du moindre privilège en séparant l'identité physique de l'identité technique :
+  * L'utilisateur classique : C'est le compte de session principale. Il est dédié aux tâches courantes (bureautique, navigation, messagerie Proton).
+  * L'utilisateur technique (tux) : C'est le gestionnaire exclusif des infrastructures de la machine. Le rôle de Tux est de piloter l'hyperviseur KVM et les conteneurs de manière autonome, sans jamais détenir les privilèges root globaux du système.
-^ Identité ^ Type de Compte ^ Rôle Système ^ Impact Sécurité ^
+==== La Transactionnalité & L'Idempotence (Zéro Maillon Faible) ====
+Chaque installation de pilote ou de ressource (comme notre déploiement NVIDIA) doit être prédictible. La philosophie Titux impose l'utilisation de verrous transactionnels (le mode "--downloadonly" de DNF5).
-| **bernard** | Utilisateur Standard / Sudoer | Navigation, messagerie Proton, tâches courantes. | Totalement isolé des fichiers des machines virtuelles. |
+==== L'Évolutivité Matérielle Structurelle ====
-| **tux** | Compte Technique Dédié | Gestion des conteneurs, scripts d'infrastructure, Virt-Manager. | Ne possède pas les droits root globaux. Ses erreurs ne peuvent pas impacter le profil ''bernard''. |
+Une machine Titux est pensée pour l'avenir. La structure est modified dès l'installation (Layout Btrfs à plat, isolation No_CoW) pour que l'activation future de services lourds se fasse par simple emboîtement.
-===== 2. Phase d'Installation : Déploiement de l'Hyperviseur (QEMU/KVM) =====
+===== 2. Index des Modules Techniques (Sommaire Directeur) =====
-Les commandes de ce bloc doivent être exécutées depuis votre session utilisateur principale dans un terminal (**Konsole**).
-==== Étape 1 : Installation de la pile logicielle KVM ====
+==== Module 1 : Initialisation du Système (Post-Install Immédiat) ====
-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 :
+  * Mise à jour initiale : Synchronisez les catalogues et le noyau Linux via la console ou l'outil Discover.
-<code>
-sudo dnf install -y virt-manager libvirt-daemon-kvm libvirt-client
-</code>
-==== Étape 2 : Activation et démarrage du service système ====
+==== Module 2 : Gestion Matérielle & Pilote Graphique ====
-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 (--now) et se relance automatiquement à chaque démarrage de la machine :
+  * Accès à la fiche détaillée : [[./installation_pilote_nvidia|Consulter la Procédure Technique NVIDIA complète]].
-<code>
-sudo systemctl enable --now libvirtd
-</code>
-===== 3. Phase de Configuration : Gestion de l'Identité Technique =====
+==== Module 3 : Restructuration du Système de Fichiers Btrfs ====
+  * Accès à la fiche détaillée : [[./restructuration_btrfs_hors_ligne|Consulter le Protocole de Restructuration Btrfs hors-ligne]].
-==== Étape 1 : Création du profil technique ====
+==== Module 4 : Configuration de la Virtualisation KVM & Compte Tux ====
-Nous initialisons le compte ''tux'' en forçant la création de son répertoire personnel (''/home/tux'') pour accueillir ses futurs espaces de stockage isolés :
+  * Accès à la fiche détaillée : [[./cloisonnement_roles_virt_kvm|Consulter la Fiche d'Architecture et de Virtualisation KVM]].
-<code>
-sudo useradd -m -c "Compte Infrastructure Tux" tux
-</code>
-==== Étape 2 : Sécurisation de l'accès ====
+==== Module 5 : Déploiement des Services Avancés ====
-Définissez un mot de passe robuste dédié à cette identité technique :
+  * Accès à la fiche détaillée : [[./projet_infra_pool_machines|Consulter la Fiche d'Infrastructure Pool Machines]].
-<code>
-sudo passwd tux
-</code>
-==== Étape 3 : Attribution du rôle de Virtualisation ====
-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'' :
-<code>
-sudo usermod -aG libvirt tux
-</code>
-===== 4. Phase d'Audit : Vérification de la Conformité (Métrologie) =====
-Ce bloc thématique regroupe les commandes de contrôle permettant de valider de manière indiscutable la bonne santé et l'étanchéité de la structure avant la mise en production.
-==== Contrôle 1 : Rôles et privilèges de Tux ====
-Cette commande valide que l'identité technique possède bien les accès d'administration requis pour la virtualisation :
-<code>
-groups tux
-</code>
-* **Résultat probant attendu :** Le terminal doit factuellement retourner : ''tux : tux libvirt''.
-==== Contrôle 2 : État du démon de virtualisation ====
-Cette commande interroge le gestionnaire de services pour vérifier que le moteur de virtualisation est actif en mémoire vive :
-<code>
-systemctl status libvirtd | grep -E "Active:|Main PID:"
-</code>
-* **Résultat probant attendu :** La ligne doit indiquer explicitement : ''Active: active (running)''.
-==== Contrôle 3 : Accessibilité de l'Hyperviseur ====
-Cette commande teste la connectivité locale du protocole client vers l'hyperviseur :
-<code>
-virsh --connect qemu:///system uri
-</code>
-* **Résultat probant attendu :** Le terminal doit vous renvoyer strictement la chaîne : ''qemu:///system''.
-===== 5. Évolutivité Matérielle & Performance Disque =====
-Les images disques lourdes (fichiers ''.qcow2'') créées par ''tux'' 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 natif de Btrfs, le répertoire accueillant les VMs de ''tux'' devra impérativement être créé avec l'attribut d'écriture directe **No_CoW (+C)** lors de la prochaine phase de refactoring des sous-volumes.