Différences

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

--- dossier:machine_titux:accueil [2026/10/02 08:03] – créée 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 Gestion des Ressources (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é 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. Déploiement de l'Utilisateur Technique (Ligne de Commande) =====
+===== 2. Index des Modules Techniques (Sommaire Directeur) =====
-Les commandes suivantes doivent être exécutées depuis une session active (par exemple depuis le compte ''bernard'') dans un terminal (**Konsole**).
-==== Étape 1 : Création du profil technique ====
+==== Module 1 : Initialisation du Système (Post-Install Immédiat) ====
-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 de conteneurs :
+  * Mise à jour initiale : Synchronisez les catalogues et le noyau Linux via la console ou l'outil Discover.
-<code>
-sudo useradd -m -c "Compte Infrastructure Tux" tux
-</code>
-==== Étape 2 : Sécurisation de l'accès ====
+==== Module 2 : Gestion Matérielle & Pilote Graphique ====
-Définissez un mot de passe robuste dédié à cette identité technique :
+  * Accès à la fiche détaillée : [[./installation_pilote_nvidia|Consulter la Procédure Technique NVIDIA complète]].
-<code>
-sudo passwd tux
-</code>
-==== Étape 3 : Attribution du rôle de Virtualisation (Sans accès Root) ====
+==== Module 3 : Restructuration du Système de Fichiers Btrfs ====
-C'est le pivot de notre architecture évolutive. Nous ajoutons l'utilisateur ''tux'' au groupe système ''libvirt''. Cela lui donne le droit de configurer l'hyperviseur QEMU/KVM et de gérer des serveurs complets (comme YunoHost) dans Virt-Manager sans jamais avoir besoin d'utiliser ''sudo'' ou de connaître le mot de passe root de la machine :
+  * Accès à la fiche détaillée : [[./restructuration_btrfs_hors_ligne|Consulter le Protocole de Restructuration Btrfs hors-ligne]].
-<code>
-sudo usermod -aG libvirt tux
-</code>
-===== 3. Comportement du Cloisonnement et Évolutivité =====
+==== Module 4 : Configuration de la Virtualisation KVM & Compte Tux ====
+  * Accès à la fiche détaillée : [[./cloisonnement_roles_virt_kvm|Consulter la Fiche d'Architecture et de Virtualisation KVM]].
-==== Gestion Isolée de Podman (Conteneurs d'applications) ====
+==== Module 5 : Déploiement des Services Avancés ====
-Par défaut, Fedora utilise **Podman** pour la gestion des conteneurs légers (Docker Hub). Podman fonctionne en mode //Rootless// (sans privilèges super-utilisateur).
+  * Accès à la fiche détaillée : [[./projet_infra_pool_machines|Consulter la Fiche d'Infrastructure Pool Machines]].
-Lorsque le compte ''tux'' lancera des conteneurs, 100% de la charge utile et des images téléchargées seront stockées de manière étanche dans :
-<code>
-/home/tux/.local/share/containers/
-</code>
-Le compte ''bernard'' reste vierge de tout résidu de conteneurisation.
-==== Gestion des Fichiers de Machines Virtuelles (QEMU/KVM) ====
-Les images disques lourdes (fichiers ''.qcow2'') créées par ''tux'' dans Virt-Manager devront être stockées dans un espace accessible.
-/!\ **Note d'Ingénierie Btrfs (Évolutivité matérielle)** : Les fichiers d'images virtuelles 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.
-===== 4. Validation Métrologique =====
-Pour vérifier que l'organisation des rôles est conforme et active sur le système, exécutez :
-<code>
-groups tux
-</code>
-Le terminal doit factuellement retourner l'appartenance aux groupes : ''tux : tux libvirt''.