| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| dossier:machine_titux:accueil [2026/10/02 08:34] – bernard.rolland | dossier:machine_titux:accueil [2026/10/04 09:07] (Version actuelle) – bernard.rolland |
|---|
| |
| ===== 1. Manifeste Philosophique de l'Architecture Titux ===== | ===== 1. Manifeste Philosophique de l'Architecture Titux ===== |
| |
| La vision de l'association **Titux** repose sur trois piliers fondamentaux de l'administration système moderne : | |
| |
| ==== Le Cloisonnement par les Privilèges (RBAC) & La Mission de "Tux" ==== | ==== Le Cloisonnement par les Privilèges (RBAC) & La Mission de "Tux" ==== |
| 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 : | 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). Il est structurellement et volontairement isolé des fichiers lourds de l'infrastructure. | * 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.** Si un script technique ou une machine virtuelle gérée par Tux commet une erreur critique, les données personnelles de la session principale restent totalement inviolables et protégées. | * 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. |
| |
| ==== La Transactionnalité & L'Idempotence (Zéro Maillon Faible) ==== | ==== 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) : on valide que 100% de la charge utile est présente et saine dans le cache local avant d'alterer le système. Si le réseau coupe, l'OS reste intact. De même, l'usage de variables en mémoire évite les pièges de copier-coller d'adresses web instables. | 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). |
| |
| ==== L'Évolutivité Matérielle Structurelle ==== | ==== L'Évolutivité Matérielle Structurelle ==== |
| Une machine Titux est pensée pour l'avenir. Même si on n'utilise pas immédiatement toutes les fonctionnalités, la structure est modifiée dès l'installation (Layout Btrfs à plat, isolation No_CoW) pour que l'activation future de services lourds (serveurs auto-hébergés, bases de données) se fasse par simple emboîtement, sans jamais nécessiter de réinstaller le système. | 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. Index des Modules Techniques (Sommaire Directeur) ===== | ===== 2. Index des Modules Techniques (Sommaire Directeur) ===== |
| |
| Suivez rigoureusement les modules ci-dessous dans l'ordre chronologique pour déployer l'architecture Titux. | |
| |
| ==== Module 1 : Initialisation du Système (Post-Install Immédiat) ==== | ==== Module 1 : Initialisation du Système (Post-Install Immédiat) ==== |
| Dès le premier démarrage sur une installation fraîche de Fedora 44 KDE : | * Mise à jour initiale : Synchronisez les catalogues et le noyau Linux via la console ou l'outil Discover. |
| * **Mise à jour initiale** : Synchronisez les catalogues et le noyau Linux via la console ou l'outil Discover. | |
| * **Nettoyage préventif** : Assurez-vous de l'absence de résidus ou de caches DNF5 corrompus. | |
| |
| ==== Module 2 : Gestion Matérielle & Pilote Graphique ==== | ==== Module 2 : Gestion Matérielle & Pilote Graphique ==== |
| Stabilisation de l'affichage hybride et du calcul GPU pour les architectures portables modernes (ex: Dell G16 Raptor Lake + GeForce RTX). | * Accès à la fiche détaillée : [[./installation_pilote_nvidia|Consulter la Procédure Technique NVIDIA complète]]. |
| * **Contournement Intel IBT** : Injection obligatoire du paramètre ''ibt=off'' dans GRUB via Grubby pour empêcher le gel du noyau. | |
| * **Déploiement NVIDIA** : Configuration isolée des dépôts RPM Fusion Nonfree par serveurs directs et compilation synchrone. | |
| * **Accès à la fiche détaillée** : [[./installation_pilote_nvidia|Consulter la Procédure Technique NVIDIA complète]]. | |
| |
| ==== Module 3 : Restructuration du Système de Fichiers Btrfs ==== | ==== Module 3 : Restructuration du Système de Fichiers Btrfs ==== |
| Action de réorganiser l'organisation interne du disque pour préparer le système aux sauvegardes instantanées. Les informaticiens anglophones emploient souvent le terme de **refactoring** pour désigner ce procédé (qui signifie simplement : *"réordonner l'intérieur d'un système pour le rendre plus propre sans changer ce qu'il fait"*). | * Accès à la fiche détaillée : [[./restructuration_btrfs_hors_ligne|Consulter le Protocole de Restructuration Btrfs hors-ligne]]. |
| * **Layout Snapper** : Migration de la racine ''root'' vers le sous-volume ''@'', et du répertoire utilisateur ''home'' vers ''@home''. | |
| * **Sécurisation des Snapshots** : Création du sous-volume ''@snapshots'' isolé pour éviter les boucles récursives de sauvegarde. | |
| * **Accès à la fiche détaillée** : [[./restructuration_btrfs_hors_ligne|Consulter le Protocole de Restructuration Btrfs hors-ligne]]. | |
| |
| ==== Module 4 : Configuration de la Virtualisation KVM & Compte Tux ==== | ==== Module 4 : Configuration de la Virtualisation KVM & Compte Tux ==== |
| Mise en pratique du manifeste philosophique à travers la création de l'environnement technique. | * Accès à la fiche détaillée : [[./cloisonnement_roles_virt_kvm|Consulter la Fiche d'Architecture et de Virtualisation KVM]]. |
| * **Création de Tux** : Déploiement du profil technique isolé. | |
| * **Rattachement Libvirt** : Intégration de l'utilisateur ''tux'' au groupe système ''libvirt'' pour piloter Virt-Manager sans droits root. | |
| * **Optimisation No_CoW** : Configuration des répertoires de stockage avec l'attribut d'écriture directe ''+C'' pour préserver le SSD. | |
| * **Accès à la fiche détaillée** : [[./cloisonnement_roles_virt_kvm|Consulter la Fiche d'Architecture et de Virtualisation KVM]]. | |
| |
| ==== Module 5 : Déploiement des Services Avancés ==== | ==== Module 5 : Déploiement des Services Avancés ==== |
| Une fois l'infrastructure validée par la métrologie, la machine est prête pour les projets avancés de l'association : | * Accès à la fiche détaillée : [[./projet_infra_pool_machines|Consulter la Fiche d'Infrastructure Pool Machines]]. |
| * **Machines Virtuelles KVM** : Déploiement d'un serveur de services complet et indépendant (ex: [[./projet_yunohost_kvm|Serveur YunoHost auto-hébergé derrière Proton VPN]]). | |
| * **Conteneurs Applicatifs Rootless** : Utilisation de Podman sous le profil ''tux'' pour exécuter les micro-services de la toile de manière étanche. | |
| | |
| ^ Version de la doc ^ Date de révision ^ Statut de validation Titux ^ | |
| |
| | v1.0 (Stable) | 02 Octobre 2026 | **Validé sur le terrain par les faits (Dell G16)** | | |
| |