mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
Merge remote-tracking branch 'origin/develop' into HEAD
This commit is contained in:
MacRimi
@@ -0,0 +1,254 @@
|
||||
{
|
||||
"site": {
|
||||
"name": "ProxMenux",
|
||||
"tagline": "Menu interactif et tableau de bord web pour Proxmox VE"
|
||||
},
|
||||
"nav": {
|
||||
"home": "Accueil",
|
||||
"docs": "Documentation",
|
||||
"documentation": "Documentation",
|
||||
"guides": "Guides",
|
||||
"changelog": "Journal des modifications",
|
||||
"github": "GitHub",
|
||||
"rss": "RSS",
|
||||
"rssTitle": "Flux RSS",
|
||||
"menuOpen": "Ouvrir le menu"
|
||||
},
|
||||
"footer": {
|
||||
"sponsorHeading": "Soutenir le projet",
|
||||
"sponsorBody": "Si vous souhaitez soutenir le projet.",
|
||||
"sponsorAlt": "Soutenez-moi sur Ko-fi",
|
||||
"connectHeading": "Communauté",
|
||||
"connectBody": "Rejoignez les discussions de la communauté sur GitHub pour obtenir de l’aide, partager vos idées et contribuer au projet. Toutes les idées sont les bienvenues !",
|
||||
"joinDiscussion": "Participer à la discussion",
|
||||
"copyrightPrefix": "ProxMenux, un projet collaboratif et open source créé par",
|
||||
"copyrightSuffix": "."
|
||||
},
|
||||
"language": {
|
||||
"switcher": "Langue",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
"title": "Documentation",
|
||||
"description": "Présentation du système et guides d’utilisation"
|
||||
},
|
||||
"changelog": {
|
||||
"title": "Journal des modifications",
|
||||
"description": "Informations sur les dernières mises à jour"
|
||||
},
|
||||
"guides": {
|
||||
"title": "Guides",
|
||||
"description": "Tutoriels et guides pas à pas pour les tâches courantes"
|
||||
},
|
||||
"github": {
|
||||
"title": "Dépôt GitHub",
|
||||
"description": "Consultez le code source."
|
||||
}
|
||||
},
|
||||
"docSidebar": {
|
||||
"documentation": "Documentation",
|
||||
"items": {
|
||||
"introduction": "Introduction",
|
||||
"installation": "Installation",
|
||||
"proxmenuxMonitor": "ProxMenux Monitor",
|
||||
"monitorOverview": "Vue d’ensemble",
|
||||
"architecture": "Architecture",
|
||||
"accessAuth": "Accès et authentification",
|
||||
"dashboard": "Tableau de bord",
|
||||
"dashboardSystemOverview": "Onglet Vue d’ensemble du système",
|
||||
"dashboardApps": "Onglet Applications",
|
||||
"dashboardStorage": "Onglet Stockage",
|
||||
"dashboardNetwork": "Onglet Réseau",
|
||||
"dashboardVmsLxcs": "Onglet VM et LXC",
|
||||
"dashboardVmsLxcsApp": "Application",
|
||||
"dashboardVmsLxcsUpdates": "Mises à jour",
|
||||
"dashboardHardware": "Onglet Matériel",
|
||||
"dashboardSystemLogs": "Onglet Journaux système",
|
||||
"dashboardTerminal": "Onglet Terminal",
|
||||
"dashboardSecurity": "Onglet Sécurité",
|
||||
"dashboardSettings": "Onglet Paramètres",
|
||||
"healthMonitor": "Surveillance de l’état du système",
|
||||
"auditReport": "Audit et rapports",
|
||||
"auditReportOverview": "Vue d’ensemble",
|
||||
"auditReportAssessment": "Évaluation et inventaire",
|
||||
"auditReportPolicy": "Politique",
|
||||
"auditReportChanges": "Modifications",
|
||||
"auditReportReports": "Rapports et comparaisons",
|
||||
"auditReportScope": "Périmètre et garanties",
|
||||
"notifications": "Notifications",
|
||||
"aiAssistant": "Assistant IA",
|
||||
"apiReference": "Référence de l’API",
|
||||
"integrations": "Intégrations",
|
||||
"ociManager": "OCI manager Apps",
|
||||
"ociOverview": "Vue d’ensemble",
|
||||
"ociArchitecture": "Comment une image OCI est adaptée",
|
||||
"ociCustomImage": "Image absente du catalogue",
|
||||
"ociStorageNetwork": "Données, chemins et réseau",
|
||||
"ociHardware": "Périphériques et accélération",
|
||||
"ociStacks": "Applications à plusieurs conteneurs",
|
||||
"ociLifecycle": "Installer, mettre à jour et modifier",
|
||||
"ociMonitor": "Dans ProxMenux Monitor",
|
||||
"proxmenuxScripts": "ProxMenux Scripts",
|
||||
"postInstallScript": "Script de post-installation",
|
||||
"postInstallOverview": "Vue d’ensemble",
|
||||
"postInstallAutomated": "Automatique",
|
||||
"postInstallCustomizable": "Personnalisable",
|
||||
"postInstallBasicSettings": "Paramètres de base",
|
||||
"postInstallSystem": "Système",
|
||||
"postInstallVirtualization": "Virtualisation",
|
||||
"postInstallNetwork": "Réseau",
|
||||
"postInstallStorage": "Stockage",
|
||||
"postInstallSecurity": "Sécurité",
|
||||
"postInstallCustomization": "Personnalisation",
|
||||
"postInstallMonitoring": "Surveillance",
|
||||
"postInstallPerformance": "Performances",
|
||||
"postInstallOptional": "Facultatif",
|
||||
"postInstallUpdates": "Appliquer les mises à jour disponibles",
|
||||
"postInstallUninstall": "Supprimer les optimisations",
|
||||
"gpusCoralTpu": "GPU et Coral TPU",
|
||||
"nvidiaHost": "Installer les pilotes NVIDIA sur l’hôte",
|
||||
"coralHost": "Installer Coral TPU sur l’hôte",
|
||||
"addGpuLxc": "Donner accès à un GPU dans un LXC",
|
||||
"addCoralLxc": "Donner accès à Coral TPU dans un LXC",
|
||||
"addGpuVm": "Attribuer un GPU à une VM (passthrough)",
|
||||
"switchGpuMode": "Changer le mode du GPU (VM ↔ LXC)",
|
||||
"createVm": "Créer une VM",
|
||||
"createVmOverview": "Vue d’ensemble",
|
||||
"createVmSystemNas": "Systèmes NAS",
|
||||
"createVmSynology": "VM Synology",
|
||||
"createVmNasOthers": "Autres systèmes NAS",
|
||||
"createVmSystemWindows": "Systèmes Windows",
|
||||
"createVmSystemLinux": "Systèmes Linux",
|
||||
"diskManager": "Gestionnaire de disques",
|
||||
"diskManagerOverview": "Vue d’ensemble",
|
||||
"diskImportVm": "Importer un disque dans une VM",
|
||||
"diskImportImageVm": "Importer une image disque dans une VM",
|
||||
"diskAddController": "Ajouter un contrôleur ou un périphérique NVMe à une VM",
|
||||
"diskImportLxc": "Importer un disque dans un LXC",
|
||||
"diskFormat": "Formater ou effacer un disque physique",
|
||||
"diskSmart": "État SMART et tests du disque",
|
||||
"storageShareManager": "Gestion du stockage et des partages",
|
||||
"storageShareOverview": "Vue d’ensemble",
|
||||
"hostStorage": "Intégration du stockage à l’hôte",
|
||||
"hostNfs": "Ajouter un partage NFS comme stockage Proxmox",
|
||||
"hostSamba": "Ajouter un partage Samba comme stockage Proxmox",
|
||||
"hostIscsi": "Ajouter une cible iSCSI comme stockage Proxmox",
|
||||
"hostLocalDisk": "Ajouter un disque local comme stockage Proxmox",
|
||||
"hostLocalShared": "Créer un répertoire partagé sur l’hôte",
|
||||
"lxcMountPoints": "Points de montage LXC (hôte ↔ CT)",
|
||||
"lxcNetworkSharing": "Partages réseau dans LXC",
|
||||
"lxcNfsClient": "Client NFS dans LXC",
|
||||
"lxcSambaClient": "Client Samba dans LXC",
|
||||
"lxcNfsServer": "Serveur NFS dans LXC",
|
||||
"lxcSambaServer": "Serveur Samba dans LXC",
|
||||
"network": "Réseau",
|
||||
"networkOverview": "Vue d’ensemble",
|
||||
"networkDiagnostics": "Diagnostic",
|
||||
"networkMonitoring": "Outils de surveillance en temps réel",
|
||||
"networkBridge": "Analyse et réparation des ponts réseau",
|
||||
"networkConfig": "Analyse et nettoyage de la configuration",
|
||||
"networkPersistent": "Noms persistants des interfaces",
|
||||
"networkBackup": "Sauvegarde et redémarrage des interfaces",
|
||||
"security": "Sécurité",
|
||||
"securityOverview": "Vue d’ensemble",
|
||||
"securityFail2ban": "Fail2Ban",
|
||||
"securityLynis": "Lynis",
|
||||
"utilities": "Utilitaires",
|
||||
"utilsOverview": "Vue d’ensemble",
|
||||
"utilsUupDump": "Création d’ISO avec UUP Dump",
|
||||
"utilsSystemUtils": "Installation d’utilitaires système",
|
||||
"utilsSystemUpdate": "Mise à jour du système Proxmox",
|
||||
"utilsUpgradePve": "Passer de PVE 8 à PVE 9",
|
||||
"utilsExportVm": "Exporter une VM au format OVA/OVF",
|
||||
"utilsImportVm": "Importer une VM depuis OVA/OVF",
|
||||
"settingsProxmenux": "Paramètres de ProxMenux",
|
||||
"settingsOverview": "Vue d’ensemble",
|
||||
"settingsMonitor": "ProxMenux Monitor",
|
||||
"settingsBeta": "Changer de canal de publication",
|
||||
"settingsVersion": "Afficher les informations de version",
|
||||
"settingsUninstall": "Désinstaller ProxMenux",
|
||||
"commandsReference": "Référence des commandes",
|
||||
"commandsOverview": "Vue d’ensemble",
|
||||
"commandsSystem": "Commandes système utiles",
|
||||
"commandsVmCt": "Gestion des VM et CT",
|
||||
"commandsStorage": "Stockage et disques",
|
||||
"commandsNetwork": "Commandes réseau",
|
||||
"commandsUpdates": "Mises à jour et paquets",
|
||||
"commandsGpu": "Passthrough GPU",
|
||||
"commandsZfs": "Gestion de ZFS",
|
||||
"commandsBackup": "Sauvegarde et restauration",
|
||||
"commandsTools": "Outils système en ligne de commande",
|
||||
"glossary": "Glossaire",
|
||||
"about": "À propos",
|
||||
"aboutOverview": "Vue d’ensemble",
|
||||
"aboutFaq": "FAQ",
|
||||
"aboutContributors": "Contributeurs",
|
||||
"aboutContributing": "Contribuer",
|
||||
"aboutCodeOfConduct": "Code de conduite",
|
||||
"externalRepositories": "Dépôts externes",
|
||||
"backupRestore": "Sauvegarde et restauration",
|
||||
"backupRestoreOverview": "Vue d’ensemble",
|
||||
"backupRestoreHowItWorks": "Fonctionnement",
|
||||
"backupRestoreDestinations": "Destinations",
|
||||
"backupRestoreDestOverview": "Vue d’ensemble",
|
||||
"backupRestoreDestLocal": "Archive locale",
|
||||
"backupRestoreDestPbs": "Proxmox Backup Server",
|
||||
"backupRestoreDestBorg": "Borg",
|
||||
"backupRestoreCreating": "Créer des sauvegardes",
|
||||
"backupRestoreJobs": "Tâches planifiées",
|
||||
"backupRestoreRestoring": "Restaurer",
|
||||
"backupRestoreCrossKernel": "Restauration entre versions du noyau",
|
||||
"backupRestoreGlossary": "Glossaire"
|
||||
}
|
||||
},
|
||||
"hero": {
|
||||
"title": "ProxMenux",
|
||||
"tagline": "Un menu interactif et un tableau de bord web pour Proxmox VE",
|
||||
"description": "ProxMenux réunit un menu interactif et un tableau de bord web pour Proxmox VE. Exécutez des commandes, des scripts et des assistants depuis le terminal, ou consultez l’état de l’hôte, ses métriques et ses notifications dans un navigateur.",
|
||||
"installButton": "Installer maintenant",
|
||||
"whatIsButton": "Qu’est-ce que ProxMenux ?",
|
||||
"logoAlt": "Logo ProxMenux"
|
||||
},
|
||||
"docNav": {
|
||||
"previous": "Précédent",
|
||||
"next": "Suivant"
|
||||
},
|
||||
"tocPanel": {
|
||||
"onThisPage": "Sur cette page"
|
||||
},
|
||||
"supportProject": {
|
||||
"heading": "Soutenez le projet !",
|
||||
"body": "Si <strong>ProxMenux</strong> vous est utile, donnez-lui une ⭐ sur GitHub pour aider d’autres personnes à le découvrir.",
|
||||
"button": "Ajouter une étoile sur GitHub"
|
||||
},
|
||||
"rssLink": {
|
||||
"heading": "Suivez les nouveautés !",
|
||||
"body": "Abonnez-vous à notre flux RSS pour être informé des nouveautés.",
|
||||
"copy": "Copier",
|
||||
"copied": "Copié !",
|
||||
"copyTitle": "Copier l’URL du flux RSS",
|
||||
"openFeed": "Ouvrir le flux RSS",
|
||||
"openTitle": "Ouvrir le flux RSS"
|
||||
},
|
||||
"changelog": {
|
||||
"pageTitle": "Journal des modifications",
|
||||
"meta": {
|
||||
"title": "Journal des modifications de ProxMenux",
|
||||
"titleSuffix": "Notes de version",
|
||||
"latest": "Dernière version",
|
||||
"mostRecent": "Version la plus récente",
|
||||
"description": "Notes de version et historique des mises à jour de ProxMenux, le script à menus pour administrer Proxmox VE.",
|
||||
"descriptionTail": "Nouvelles fonctionnalités, corrections de bugs, mises à jour de sécurité, améliorations de ProxMenux Monitor, compatibilité avec les fournisseurs d’IA, sécurisation du passthrough GPU et bien plus.",
|
||||
"ogDescription": "Notes de version de ProxMenux.",
|
||||
"ogTail": "Abonnez-vous au flux RSS ou revenez consulter les nouvelles versions."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Code de conduite | Documentation ProxMenux",
|
||||
"description": "Code de conduite et bonnes pratiques de ProxMenux pour les contributeurs, les testeurs et les utilisateurs.",
|
||||
"ogTitle": "Code de conduite | Documentation ProxMenux",
|
||||
"ogDescription": "Attentes concernant la responsabilité du code, le signalement des vulnérabilités et le périmètre des PR du projet ProxMenux."
|
||||
},
|
||||
"errors": {
|
||||
"notFound": "Erreur : fichier CODE_OF_CONDUCT.md introuvable.",
|
||||
"loadFailed": "Erreur : Impossible de charger le contenu du Code de conduite."
|
||||
},
|
||||
"contentMarkdown": "# 📝 Code de conduite et bonnes pratiques\n\nCe document définit les **principes et les consignes** d’utilisation de **ProxMenux**, afin de promouvoir le **respect, la collaboration et la sécurité** dans le développement.\n\n## 📌 1. Attribution du code et reconnaissance\n\n- Si des **scripts, extraits de code ou idées** proviennent d’autres dépôts ou développeurs, leur auteur d’origine sera toujours cité.\n- Un commentaire dans le code ou la documentation indiquera la source et, si possible, un lien vers le dépôt original.\n- Lors de l’utilisation de code soumis à une **licence** particulière, ses conditions doivent être respectées.\n\n### ✅ Exemple d’attribution correcte dans le code :\n\n```bash\n# Script fondé sur le travail de [Auteur] dans [Lien du dépôt]\n```\n\n## 🔒 2. Sécurité et responsabilité du code\n\n- Tout le code de ce dépôt suit les bonnes pratiques de développement sécurisé.\n- Les contributions introduisant volontairement des vulnérabilités ou des pratiques dangereuses sont interdites.\n- Les scripts ne doivent jamais compromettre la sécurité du système ni les données des utilisateurs.\n- Avant leur mise en œuvre, les contributions doivent être examinées pour vérifier leur sécurité et leur stabilité.\n\n### ⚠️ Divulgation responsable des vulnérabilités\n\nSi vous découvrez une vulnérabilité de sécurité, ne la signalez PAS dans des issues ou forums publics.\n\nSignalez-la plutôt en privé par e-mail :\n\n📧 proxmenux@macrimi.pro\n\nPour en savoir plus sur les vulnérabilités et leur signalement, consultez notre [politique de sécurité](./SECURITY.md).\n\n## 🤝 3. Règles de la communauté\n\nPour maintenir un cadre respectueux et professionnel, tous les utilisateurs doivent suivre ces règles :\n\n- ✅ Restez respectueux et constructifs dans les discussions.\n- ❌ Le harcèlement, les propos haineux et les comportements offensants ne seront pas tolérés.\n- ✅ Formulez vos retours de manière professionnelle, sans attaques personnelles.\n- ❌ Les manquements peuvent entraîner des avertissements ou des exclusions selon leur gravité.\n\n##\n\nCe document encourage un usage éthique du code, la vigilance en matière de sécurité et une communauté respectueuse.\n\n📢 Construisons ensemble quelque chose de remarquable !\n"
|
||||
}
|
||||
@@ -0,0 +1,293 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Contribution à ProxMenux | ProxMenux Documentation",
|
||||
"description": "Comment contribuer à ProxMenux : modèle de branches (main / develop / feature/*), processus de pull request, en-tête de script avec attribution et lien de soutien facultatif, interface en deux phases, fonctions de message et passage d’une branche de fonctionnalité à une version stable.",
|
||||
"ogTitle": "Contribuer à ProxMenux",
|
||||
"ogDescription": "Modèle de branches, processus, attribution dans l’en-tête et règle d’interface en deux phases à respecter pour contribuer."
|
||||
},
|
||||
"header": {
|
||||
"title": "Contribuer à ProxMenux",
|
||||
"description": "ProxMenux accueille les contributions de la communauté : nouveaux scripts, corrections, amélioration des dialogues, traductions et intégrations. Cette page présente la structure du dépôt, le modèle de branches, le processus de pull request, l’en-tête avec attribution et lien de soutien facultatif, ainsi que les conventions à respecter.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"twoPagesCallout": {
|
||||
"title": "Deux pages connexes, un projet",
|
||||
"body": "Ne confondez pas cette page avec <contributorsLink>Contributeurs</contributorsLink>, qui met à l’honneur les testeurs, relecteurs et développeurs déjà impliqués. Cette page s’adresse à <em>vous</em>, futur contributeur, et explique comment préparer une pull request en vue de son intégration."
|
||||
},
|
||||
"branching": {
|
||||
"heading": "Modèle de branchement",
|
||||
"intro": "ProxMenux utilise un modèle de branchement à trois niveaux :",
|
||||
"headerBranch": "Branche",
|
||||
"headerPurpose": "Objet",
|
||||
"rows": [
|
||||
{
|
||||
"branch": "main",
|
||||
"purposeRich": "Code stable, prêt pour la production. Seules les modifications prêtes à être publiées sont intégrées ici. C’est la version obtenue lors d’une installation normale de ProxMenux."
|
||||
},
|
||||
{
|
||||
"branch": "develop",
|
||||
"purposeRich": "Branche de développement actif : tous les nouveaux changements y sont intégrés en premier. Elle correspond au canal « bêta ». Lorsqu’une version stable est prête, elle est publiée dans <code>main</code> à partir de cette branche."
|
||||
},
|
||||
{
|
||||
"branch": "feature/*",
|
||||
"purposeRich": "Branches temporaires pour une fonctionnalité, une correction ou une amélioration. Créées à partir de <code>develop</code>, puis fusionnées dans <code>develop</code> par pull request après relecture."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Ce que cela signifie pour les utilisateurs",
|
||||
"calloutBody": "Les utilisateurs qui suivent <code>main</code> reçoivent des versions testées. Ceux qui souhaitent les nouveautés plus tôt et acceptent quelques imperfections peuvent suivre <code>develop</code>. Les nouvelles fonctions passent toujours d’abord par <code>develop</code> ; rien n’arrive dans <code>main</code> sans ce cycle."
|
||||
},
|
||||
"workflow": {
|
||||
"heading": "Processus de pull request",
|
||||
"intro": "De l'idée à la version fusionnée en cinq étapes:",
|
||||
"step1Lead": "<strong>Créer une branche de fonction à partir de <code>develop</code></strong>:",
|
||||
"step1Code": "git clone https://github.com/MacRimi/ProxMenux.git\ncd ProxMenux\ngit checkout develop\ngit pull origin develop\ngit checkout -b feature/your-feature-name",
|
||||
"step1Trail": "Utilisez un nom descriptif de branche : <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
|
||||
"step2Lead": "<strong>Travailler sur vos changements et pousser la branche:</strong>",
|
||||
"step2Code": "# Make your changes, then:\ngit add scripts/...\ngit commit -m \"Add ZFS ARC tuning script\"\ngit push -u origin feature/your-feature-name",
|
||||
"step3": "<strong>Ouvrez une pull request vers <code>develop</code></strong>, pas vers <code>main</code>. Vérifiez sur GitHub que la branche de base est <code>develop</code>. Décrivez le rôle du script, ses modifications et les versions de Proxmox VE utilisées pour les tests.",
|
||||
"step4": "<strong>Après relecture, les modifications sont fusionnées dans <code>develop</code>.</strong> Un responsable vérifie le code, les conventions d’en-tête et la règle d’interface en deux phases. S’il demande des corrections, envoyez de nouveaux commits dans la même branche : la PR se met à jour automatiquement.",
|
||||
"step5": "<strong>Les versions stables passent de <code>develop</code> à <code>main</code>.</strong> Lors d’une publication, <code>main</code> est avancée jusqu’à <code>develop</code> par fast-forward, puis étiquetée. Votre contribution entre dans la prochaine version stable."
|
||||
},
|
||||
"scriptHeader": {
|
||||
"heading": "En-tête de script — métadonnées et description",
|
||||
"intro": "Chaque script de ProxMenux s'ouvre avec deux blocs de commentaires adjacents qui forment ensemble l'en-tête. Ils sont <strong>tous les deux requis</strong> — ensemble, ils font savoir à tout lecteur qui a écrit le script et ce qu'il fait, le tout sans ouvrir le code lui-même.",
|
||||
"bullets": [
|
||||
"<strong>Bloc supérieur : métadonnées.</strong> Auteur, liens GitHub/de soutien facultatifs, responsable, copyright, licence, version et date de mise à jour. C’est aussi la <em>reconnaissance des contributeurs</em> : pour un nouveau script, ajoutez votre nom et, si vous le souhaitez, votre page GitHub et un profil de soutien tel que Ko-fi, GitHub Sponsors ou Buy Me a Coffee.",
|
||||
"<strong>Bloc inférieur : description.</strong> Un court paragraphe en anglais simple explique le rôle du script. Il se lit <em>avant</em> le code et doit se suffire à lui-même : objectif, actions principales, ressources concernées et prérequis."
|
||||
],
|
||||
"licenseCalloutTitle": "La ligne de licence est fixe — GPL-3.0",
|
||||
"licenseCalloutBody": "ProxMenux est publié sous la licence publique générale <strong>GNU v3.0</strong>. Chaque script du projet est livré sous cette même licence; la ligne <code>License</code> dans l'en-tête est toujours la référence GPL-3.0 montrée dans l'exemple ci-dessous — ce n'est pas un choix par script. En contribuant un script, vous acceptez de le publier sous GPL-3.0, ce qui signifie que n'importe qui peut le lire, le modifier et le redistribuer (y compris les modifications) tant qu'ils le conservent sous la même licence. Le texte entier vit à <licenseLink>MacRimi/ProxMenux/LICENSE</licenseLink>.",
|
||||
"templateCode": "#!/bin/bash\n\n# ==========================================================\n# ProxMenux - A menu-driven script for Proxmox VE management\n# ==========================================================\n# Author : Your Name\n# GitHub : github.com/yourhandle\n# Sponsor : ko-fi.com/yourhandle\n# Maintainer : MacRimi\n# Copyright : (c) 2026 MacRimi & contributors\n# License : (GPL-3.0) (https://github.com/MacRimi/ProxMenux/blob/main/LICENSE)\n# Version : 1.0\n# Last Updated: DD/MM/YYYY\n# ==========================================================\n# Description:\n# Short paragraph explaining what the script does.\n# Mention the main actions (e.g. \"creates a ZFS pool\",\n# \"configures IOMMU and reboots\", \"imports an ISO into a VM\"),\n# the resources it touches, and any prerequisites the user\n# should be aware of before running it.\n# ==========================================================",
|
||||
"optionalNote": "Les lignes <code>GitHub</code> et <code>Sponsor</code> sont optionnelles — laissez-les dehors si vous ne voulez pas les publier. Tout le reste est nécessaire.",
|
||||
"whyCalloutTitle": "Pourquoi cela est important",
|
||||
"whyCalloutBody": "Contribuer à l’open source est un travail bénévole. Le nom et le lien de soutien éventuel dans le code rendent l’auteur visible à chaque lecture, au lieu de le cacher derrière le projet. La description a un autre rôle : c’est la première chose qu’un futur responsable ou utilisateur curieux lit. Sa clarté détermine souvent si le script inspire confiance ou est évité."
|
||||
},
|
||||
"structure": {
|
||||
"heading": "Structure du projet",
|
||||
"intro": "Où chaque type de script vit dans le dépôt :",
|
||||
"treeCode": "scripts/\n├── menus/ # Top-level menu scripts (entry points)\n├── storage/ # Disk, storage and passthrough scripts\n├── share/ # NFS, Samba, local share scripts\n├── vm/ # VM creation and configuration scripts\n├── gpu_tpu/ # GPU / TPU passthrough scripts\n├── post_install/ # Post-install automation scripts\n├── backup_restore/ # Backup and restore scripts\n├── utilities/ # System utility scripts\n├── global/ # Shared helper libraries (sourced by other scripts)\n├── utils.sh # Shared utility functions and message helpers\n└── help_info_menu.sh # Interactive help and command reference",
|
||||
"outro": "Chaque script charge <code>utils.sh</code> au démarrage avec source pour obtenir les fonctions de message, l’indicateur d’attente, les couleurs et le système de traduction. Les bibliothèques communes dans <code>scripts/global/</code> sont chargées explicitement par les scripts qui les utilisent."
|
||||
},
|
||||
"twoPhase": {
|
||||
"heading": "La règle de conception de l’interface en deux phases",
|
||||
"intro": "C’est la convention la plus importante de ProxMenux et celle qui entraîne le plus souvent des demandes de correction dans les PR. Chaque script est divisé en <strong>exactement deux phases</strong> :",
|
||||
"headerPhase": "Phase",
|
||||
"headerPurpose": "Objet",
|
||||
"headerScreen": "État de l'écran",
|
||||
"rows": [
|
||||
{
|
||||
"phaseRich": "<strong>Phase 1 — Sélection</strong>",
|
||||
"purposeRich": "Recueillir chaque décision de l'utilisateur. Effectuer tout travail préparatoire nécessaire (sondes, scans, vérifications).",
|
||||
"screenRich": "<code>dialog</code> superpositions. Si une sonde entre deux menus prend plus d'une seconde ou deux, montrez un spinner <code>msg_info</code> afin que l'utilisateur sache que le script n'a pas gelé, puis appelez <code>stop_spinner</code> juste avant la boîte de dialogue suivante."
|
||||
},
|
||||
{
|
||||
"phaseRich": "<strong>Phase 2 — Exécution</strong>",
|
||||
"purposeRich": "Exécutez toutes les opérations. Affichez l'historique complet des progrès accumulés à l'écran.",
|
||||
"screenRich": "Messages visibles <code>msg_info</code> / <code>msg_ok</code>; jamais <code>dialog</code>."
|
||||
}
|
||||
],
|
||||
"principle": "Le principe: <strong> collecte tout d'abord, puis exécute tout</strong>. L'utilisateur voit un menu de dialogue propre (phase 1), puis une vue d'exécution propre (phase 2). Pas de mélange — pas de dialogue apparaissant au milieu de l'exécution, pas de bruit de progression pendant la sélection.",
|
||||
"phase1Heading": "Phase 1 — modèle typique",
|
||||
"phase1Code": "# Silent preparatory work between dialogs\nmsg_info \"$(translate \"Checking disk assignments...\")\"\nASSIGNED_TO=$(check_assignments \"$DISK\")\nstop_spinner # ← clears line silently, result saved in variable\n\n# Next dialog can now use ASSIGNED_TO\nif [ -n \"$ASSIGNED_TO\" ]; then\n dialog --yesno \"$(translate \"Disk already assigned. Continue?\")\" $UI_YESNO_H $UI_YESNO_W\nfi\n\n# Collect multiple decisions per item with parallel arrays\ndeclare -a DISK_LIST=()\ndeclare -a DISK_FORMAT_TYPES=()\ndeclare -a DISK_MOUNT_POINTS=()\nfor DISK in $SELECTED; do\n msg_info \"$(translate \"Analyzing disk...\")\"\n CURRENT_FS=$(lsblk -no FSTYPE \"$DISK\" | xargs)\n stop_spinner\n\n FORMAT=$(dialog --backtitle \"$BACKTITLE\" \\\n --title \"$(translate \"Select Filesystem\")\" \\\n --menu \"...\" $UI_SHORT_MENU_H $UI_SHORT_MENU_W $UI_SHORT_MENU_LIST_H \\\n \"ext4\" \"...\" \"xfs\" \"...\" \"btrfs\" \"...\" \\\n 2>&1 >/dev/tty)\n [ -z \"$FORMAT\" ] && continue\n\n DISK_LIST+=(\"$DISK\")\n DISK_FORMAT_TYPES+=(\"$FORMAT\")\ndone",
|
||||
"phase1RulesIntro": "Règles <strong> pour la phase 1:</strong>",
|
||||
"phase1Rules": [
|
||||
"Si un spinner <code>msg_info</code> est en cours d'exécution et que vous devez ouvrir un menu <code>dialog</code> ou <code>whiptail</code>, appelez d'abord <code>stop_spinner</code> — le spinner ne peut pas coexister avec la superposition dessinée par l'un ou l'autre des outils. Si aucun spinner n'est actif, vous n'avez pas besoin de l'appeler.",
|
||||
"Utilisez <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code> pour donner un contexte visuel à une opération longue en phase 1, par exemple une vérification de plus de cinq secondes. La fonction efface déjà l’écran : n’appelez pas <code>clear</code> avant.",
|
||||
"N'appelez pas <code>show_proxmenux_logo</code> entre les menus de dialogue où il n'y a rien à afficher — le nettoyage de l'écran pour un terminal vide n'est que du bruit visuel.",
|
||||
"Conservez toutes les décisions et les résultats de la sonde dans des variables ou des tableaux parallèles. La récapitulation visible se produit au début de la phase 2, pas dans la phase 1."
|
||||
],
|
||||
"phase2Heading": "Phase 2 — modèle typique",
|
||||
"phase2Code": "# ── PHASE 2 — EXECUTION ─────────────────────────────\nshow_proxmenux_logo\nmsg_title \"$(translate \"My Script Title\")\"\n\n# Recap Phase 1 preparatory results — show what was already done\nmsg_ok \"$(translate \"CT $CTID selected.\")\"\nmsg_ok \"$(translate \"Repositories verified.\")\"\nmsg_ok \"$(translate \"Disks to process: ${#DISK_LIST[@]}\")\"\n\n# Now execute operations\nfor i in \"${!DISK_LIST[@]}\"; do\n DISK=\"${DISK_LIST[$i]}\"\n FORMAT=\"${DISK_FORMAT_TYPES[$i]}\"\n\n msg_info \"$(translate \"Formatting\") $DISK $(translate \"as\") $FORMAT...\"\n mkfs.\"$FORMAT\" \"$DISK\" >/dev/null 2>&1\n msg_ok \"$(translate \"Formatted.\")\"\ndone\n\nmsg_ok \"$(translate \"Completed. ${#DISK_LIST[@]} disk(s) processed.\")\"\nmsg_success \"$(translate \"Press Enter to return to menu...\")\"\nread -r",
|
||||
"phase2Rules": "<strong>Règles pour la phase 2:</strong> toujours commencer avec <code>show_proxmenux_logo + msg_title</code>; récapituler immédiatement les résultats de la phase 1 sous la forme de lignes <code>msg_ok</code>; n'appelez plus jamais <code>show_proxmenux_logo</code> (il effacerait les progrès accumulés); n'appelez jamais <code>dialog</code> dans la phase 2 — si une décision d'exécution est vraiment inévitable, utilisez <code>whiptail</code> (voir la section suivante)."
|
||||
},
|
||||
"dialogVsWhiptail": {
|
||||
"headingRich": "Quand utiliser <code>dialog</code> vs <code>whiptail</code>",
|
||||
"intro": "Les deux outils dessinent des interfaces utilisateur en mode texte, mais ils se comportent très différemment à l'écran — et ProxMenux les utilise en deux phases distinctes pour une raison.",
|
||||
"headerTool": "Outil",
|
||||
"headerWhen": "Quand l'utiliser",
|
||||
"headerEffect": "Effet sur l'écran",
|
||||
"rows": [
|
||||
{
|
||||
"toolRich": "<strong><code>dialog</code></strong>",
|
||||
"whenRich": "<strong>Toujours dans la phase 1.</strong> Chaque sélection interactive — choisir un VM, un disque, un système de fichiers, confirmer une action — utilise <code>dialog</code>. C'est l'outil d'interface utilisateur par défaut de ProxMenux.",
|
||||
"effectRich": "Prend le contrôle du terminal : efface l’écran, dessine son interface et rétablit l’état précédent à la fermeture. Cela convient à la phase 1, où aucun résultat utile n’est encore affiché."
|
||||
},
|
||||
{
|
||||
"toolRich": "<strong><code>whiptail</code></strong>",
|
||||
"whenRich": "<strong>Seulement en phase 2, en cas de nécessité.</strong> Le cas typique est la proposition de redémarrage en fin d’exécution. N’utilisez pas <code>whiptail</code> pour demander « continuer ? » en cours d’exécution : cette décision devait être prise en phase 1.",
|
||||
"effectRich": "Interface plus légère qui <em>n’efface pas</em> le contexte du terminal. L’historique <code>msg_ok</code>/<code>msg_info</code> de la phase 2 reste visible derrière la boîte de dialogue. Elle convient donc lorsque la progression est déjà affichée."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Pourquoi la scission est importante",
|
||||
"calloutBody": "Si vous appelez <code>dialog</code> au milieu de la phase 2, chaque ligne <code>msg_ok</code> que l'utilisateur regarde disparaît. Vous effacez la piste de vérification. <code>whiptail</code> évite cela. Donc la règle n'est pas arbitraire — il s'agit de préserver la vision de l'utilisateur de ce que le script a fait jusqu'ici.",
|
||||
"rebootHeading": "Proposition de redémarrage : le cas type de whiptail en phase 2",
|
||||
"rebootIntro": "Si un script peut nécessiter un redémarrage après l’activation d’IOMMU ou la modification du noyau, la question de fin de phase 2 utilise <code>whiptail</code>. Prévoyez toujours une branche « Non » avertissant de ne pas utiliser la ressource concernée avant le redémarrage :",
|
||||
"rebootCode": "if [[ \"$HOST_REBOOT_REQUIRED\" == \"yes\" ]]; then\n echo \"\"\n if whiptail --title \"$(translate \"Reboot Required\")\" --yesno \\\n \"\\n$(translate \"A host reboot is required before starting the VM. Reboot now?\")\" \\\n 13 78; then\n msg_warn \"$(translate \"Rebooting the system...\")\"\n reboot\n else\n echo \"\"\n msg_info2 \"$(translate \"Do not start the VM until the system has been rebooted.\")\"\n fi\nfi\n\nmsg_success \"$(translate \"Press Enter to return to menu...\")\"\nread -r"
|
||||
},
|
||||
"messageFunctions": {
|
||||
"heading": "Référence des fonctions du message",
|
||||
"intro": "Toutes sont définies dans <code>utils.sh</code>. Utilisez-les par défaut pour les sorties visibles afin de garder une présentation cohérente entre scripts. Si une fonction manque, par exemple un niveau de sévérité ou un outil de mise en page, proposez-la dans votre pull request. Elle sera examinée et ajoutée à <code>utils.sh</code> si elle est utile à plusieurs scripts.",
|
||||
"headerFunction": "Fonction",
|
||||
"headerWhen": "Quand utiliser",
|
||||
"headerSpinner": "Indicateur de progression",
|
||||
"rows": [
|
||||
{
|
||||
"function": "msg_info \"text\"",
|
||||
"whenRich": "Opération en cours.",
|
||||
"spinner": "Démarre"
|
||||
},
|
||||
{
|
||||
"function": "stop_spinner",
|
||||
"whenRich": "Fin des travaux préparatoires silencieux dans la phase 1 — tue spinner, efface la ligne.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_ok \"text\"",
|
||||
"whenRich": "Opération réussie. À utiliser aussi pour une fonction activée, même si un redémarrage reste nécessaire.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_warn \"text\"",
|
||||
"whenRich": "Avertissement réel ou état dégradé.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_error \"text\"",
|
||||
"whenRich": "Erreur fatale.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_info2 \"text\"",
|
||||
"whenRich": "Conseil sans blocage, dans une ligne d’information cyan.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_success \"text\"",
|
||||
"whenRich": "Message final « Appuyez sur Entrée pour revenir » en fin de phase 2.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_title \"text\"",
|
||||
"whenRich": "Titre gras avec espacement intégré. Utilisé au début de la phase 2.",
|
||||
"spinner": "—"
|
||||
},
|
||||
{
|
||||
"function": "show_proxmenux_logo",
|
||||
"whenRich": "Efface l’écran et affiche le logo. À appeler <em>une seule fois</em> au début de la phase 2.",
|
||||
"spinner": "—"
|
||||
}
|
||||
]
|
||||
},
|
||||
"dialogConventions": {
|
||||
"heading": "conventions de dialogue",
|
||||
"bullets": [
|
||||
"Passez toujours <code>--backtitle \"$BACKTITLE\"</code> à chaque appel <code>dialog</code> et <code>whiptail</code>. <code>$BACKTITLE</code> est toujours <code>\"ProxMenux\"</code> — réglé une fois à l'en-tête du script et jamais dépassé. L'utilisateur doit toujours voir le nom du projet comme le contexte de cadrage, jamais le propre titre du script.",
|
||||
"Enveloppez toujours les titres et les messages avec <code>$(translate \"...\")</code>.",
|
||||
"Redirige toujours la sortie <code>dialog</code> avec <code>2>&1 >/dev/tty</code> — le stdout capturé devient la sélection de l'utilisateur, tandis que la boîte de dialogue elle-même s'appuie sur le terminal.",
|
||||
"Utilisez les variables standard de dimension UI (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, etc.) pour un calibrage cohérent entre les scripts.",
|
||||
"Vérifiez toujours les choix vides ou annulés et gérez-les proprement."
|
||||
],
|
||||
"exampleIntro": "Exemple complet — construire un menu de sélection VM et gérer l'annulation:",
|
||||
"exampleCode": "# 1) Build the list of VMs as alternating \"ID NAME\" pairs.\n# dialog --menu expects this exact shape: tag1 description1 tag2 description2 ...\nVM_LIST=\"\"\nfor vmid in $(qm list | awk 'NR>1 {print $1}'); do\n vm_name=$(qm config \"$vmid\" | awk -F': ' '/^name:/ {print $2}')\n VM_LIST=\"$VM_LIST $vmid \\\"$vm_name\\\"\"\ndone\n\n# 2) Show the dialog. Captured stdout is the user's selection (the VMID).\nVMID=$(eval \"dialog --backtitle \\\"\\$BACKTITLE\\\" \\\n --title \\\"\\$(translate \\\"Select VM\\\")\\\" \\\n --menu \\\"\\$(translate \\\"Choose a VM from the list:\\\")\\\" \\\n \\$UI_MENU_H \\$UI_MENU_W \\$UI_MENU_LIST_H \\\n $VM_LIST \\\n 2>&1 >/dev/tty\")\n\n# 3) Empty result means the user pressed Cancel or Esc — exit silently.\nif [ -z \"$VMID\" ]; then\n exit 0\nfi\n\n# 4) Continue with the rest of Phase 1, knowing VMID is now set.\necho \"User selected VMID=$VMID\""
|
||||
},
|
||||
"translation": {
|
||||
"heading": "Politique de traduction",
|
||||
"intro": "Toutes les chaînes visibles par l'utilisateur doivent être enveloppées avec la fonction <code>translate</code>. ProxMenux les traduit automatiquement dans toutes les langues prises en charge — vous écrivez l'anglais, l'utilisateur lit leur langue maternelle.",
|
||||
"code": "msg_ok \"$(translate \"Operation completed successfully.\")\"\nmsg_error \"$(translate \"Failed to start container\") $CTID.\"\ndialog --title \"$(translate \"Select Storage\")\" ...",
|
||||
"bullets": [
|
||||
"Écrivez les chaînes en anglais : la traduction est gérée automatiquement lors du build.",
|
||||
"Rédigez des chaînes concises. Évitez si possible les variables dans de longues phrases.",
|
||||
"Ne traduisez <strong>pas</strong> les noms de variables, chemins ou identifiants techniques."
|
||||
]
|
||||
},
|
||||
"variableStyle": {
|
||||
"heading": "Conventions de variables et de style",
|
||||
"bullets": [
|
||||
"Utilisez <code>UPPER_CASE</code> pour les variables de niveau script.",
|
||||
"Utiliser <code>lower_case</code> pour les variables de fonction locales (déclarer avec <code>local</code>).",
|
||||
"Entourez les expansions de variables de guillemets : <code>\"$VAR\"</code>, pas <code>$VAR</code>.",
|
||||
"Utiliser <code>[[ ]]</code> pour les conditions, et non <code>[ ]</code> (sauf lorsque POSIX est nécessaire).",
|
||||
"<code>show_proxmenux_logo</code> est le moyen prévu pour effacer l’écran : il le nettoie et affiche le logo du projet pour conserver un contexte visuel. Appelez-le une fois au début de la phase 2, et éventuellement avant une longue attente en phase 1."
|
||||
],
|
||||
"standardNamesIntro": "Noms de variables standard dans l'ensemble du projet :",
|
||||
"standardNamesCode": "CTID # container ID\nVMID # virtual machine ID\nDISK # device path (e.g. /dev/sdb)\nPARTITION # partition path (e.g. /dev/sdb1)\nSTORAGE # Proxmox storage name\nMOUNT_POINT # filesystem mount path",
|
||||
"redirectHeading": "Réorienter la sortie de l'outil pendant la phase 2",
|
||||
"redirectIntro": "La phase 2 affiche un journal de lignes <code>msg_info → msg_ok</code>. Si un outil appelé, comme apt, mkfs, qm, pct ou dd, écrit sur stdout/stderr, sa sortie fait défiler les messages et brouille la présentation. L’utilisateur ne distingue plus la progression du script des détails produits par l’outil.",
|
||||
"withoutRedirectIntro": "<strong>Sans redirection</strong> — ce que l'utilisateur voit si vous ne manipulez pas le bruit:",
|
||||
"withoutRedirectCode": "ℹ Installing kernel package...\nReading package lists... Done\nBuilding dependency tree... Done\nReading state information... Done\nThe following NEW packages will be installed:\n proxmox-kernel-6.5\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 12.5 MB of archives.\nAfter this operation, 47.2 MB of additional disk space will be used.\nGet:1 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 ...\n... [200+ more lines of dpkg output] ...\n✓ Kernel installed.",
|
||||
"withRedirectIntro": "<strong>Avec redirection</strong> — à quoi ressemble la même opération lorsque le bruit est envoyé ailleurs:",
|
||||
"withRedirectCode": "ℹ Installing kernel package...\n✓ Kernel installed.\nℹ Configuring kernel command line...\n✓ Configured.\nℹ Refreshing boot loader...\n✓ Boot loader updated.",
|
||||
"twoPatternsIntro": "Deux modèles à choisir :",
|
||||
"discardLead": "<strong>Éliminez la sortie</strong> lorsque vous n'en avez pas besoin — plus rapide et plus simple:",
|
||||
"discardCode": "DEBIAN_FRONTEND=noninteractive apt-get install -y \"$package\" >/dev/null 2>&1",
|
||||
"logLead": "<strong>Envoyez la sortie à un fichier journal</strong> lorsque vous voudrez peut-être l'inspecter plus tard (débogage d'une installation échouée, vérification de ce que dpkg a fait réellement). C'est le modèle préféré pour toute opération apt:",
|
||||
"logCode": "apt-get install -y \"$package\" >> \"$log_file\" 2>&1",
|
||||
"referenceOutro": "Le script <code>scripts/global/update-pve9_2.sh</code> est une implémentation de référence — chaque appel <code>apt-get</code> envoie une sortie vers un fichier journal de sorte que l'utilisateur ne voit que le flux propre <code>msg_info → msg_ok</code>, tandis que le journal sur le disque vous permet de reconstruire exactement ce qu'apt a fait si quelque chose tourne mal."
|
||||
},
|
||||
"dosAndDonts": {
|
||||
"heading": "Faites et ne faites pas",
|
||||
"doHeading": "✅ À faire",
|
||||
"doBullets": [
|
||||
"<code>stop_spinner</code> avant un <code>dialog</code> dans la phase 1 seulement quand un spinner <code>msg_info</code> est en cours d'exécution.",
|
||||
"La phase 2 commence par <code>show_proxmenux_logo + msg_title + msg_ok</code> pour récapituler les résultats de la phase 1.",
|
||||
"Utilisez <code>msg_ok</code> pour des fonctionnalités activées avec succès, même si un redémarrage est nécessaire.",
|
||||
"Utilisez le <code>whiptail</code> (et non le <code>dialog</code>) pour toute invitation après exécution qui doit apparaître dans la phase 2.",
|
||||
"Prévoyez toujours une branche « Non » dans les dialogues de redémarrage pour avertir de ne pas démarrer la ressource concernée avant le redémarrage.",
|
||||
"Protégez la logique VM uniquement en vérifiant <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code> — les contrôleurs et NVMe PCIe ne peuvent pas être ajoutés aux conteneurs LXC.",
|
||||
"Utiliser <code>ensure_repositories</code> de <code>utils-install-functions.sh</code> au lieu de <code>apt-get update</code> inconditionnel.",
|
||||
"Utiliser des tableaux parallèles dans la phase 1 lorsque chaque élément nécessite plusieurs dialogues."
|
||||
],
|
||||
"dontHeading": "❌ À éviter",
|
||||
"dontBullets": [
|
||||
"Appelez <code>dialog</code> alors qu'un spinner est actif.",
|
||||
"Passez la récapitulation de la phase 1 au début de la phase 2.",
|
||||
"Appelez <code>show_proxmenux_logo</code> une deuxième fois — il efface tout ce que la phase 2 a imprimé.",
|
||||
"Utiliser <code>dialog</code> dans la phase 2 (utiliser <code>whiptail</code> pour le cas inévitable rare).",
|
||||
"Utiliser <code>clear</code> seul.",
|
||||
"Enveloppez <code>msg_title</code> dans des lignes vierges <code>echo \"\"</code> — il inclut déjà l'espacement.",
|
||||
"Utilisez <code>msg_warn</code> pour signaler une fonctionnalité activée avec succès — c'est un <code>msg_ok</code>.",
|
||||
"Exécuter sans condition <code>apt-get update</code> — utiliser <code>ensure_repositories</code>."
|
||||
]
|
||||
},
|
||||
"submitting": {
|
||||
"heading": "Soumettre votre contribution",
|
||||
"steps": [
|
||||
"Créez un fork de <code>MacRimi/ProxMenux</code> sur GitHub, puis clonez votre fork.",
|
||||
"Créer une branche <code>feature/*</code> à partir de <code>develop</code> (voir <em>Modèle de branchage</em> ci-dessus).",
|
||||
"Suivez ce guide pour tout script nouveau ou modifié. Écrivez l'en-tête avec votre nom; ajoutez la ligne de sponsor optionnelle si vous voulez.",
|
||||
"Testez le script sur une véritable instance Proxmox VE : phase 1 avec toutes les branches de dialogue, et phase 2 avec chaque opération et son retour arrière propre en cas d’erreur.",
|
||||
"Ouvrez une pull request <strong>vers <code>develop</code></strong> avec une description claire : rôle du script, changements et version Proxmox VE utilisée pour les tests.",
|
||||
"Assurez-vous que votre contribution respecte le <cocLink>Code de conduite</cocLink>."
|
||||
],
|
||||
"securityOutro": "Pour les questions sensibles à la sécurité, suivez le flux de divulgation dans <securityLink>SECURITY.md</securityLink> plutôt que d'ouvrir une question publique."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite",
|
||||
"items": [
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/blob/main/CONTRIBUTING.md",
|
||||
"label": "CONTRIBUTING.md (guide complet)",
|
||||
"tail": "— la source de vérité pour chaque convention, y compris les modèles matériels avancés."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/contributors",
|
||||
"label": "Contributeurs",
|
||||
"tail": " — les personnes dont le travail a façonné les versions de ProxMenux. Il s’agit d’une autre page."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"label": "Code de conduite",
|
||||
"tail": "— les normes que chaque contributeur accepte de respecter."
|
||||
},
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"label": "GitHub Discussions",
|
||||
"tail": "— demander avant de construire si vous n'êtes pas sûr si une idée correspond, ou de trouver des collaborateurs sur une fonctionnalité plus grande."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Contributeurs | Documentation ProxMenux",
|
||||
"description": "Un hommage aux personnes qui rendent ProxMenux possible : testeurs, relecteurs et développeurs qui contribuent à chaque version.",
|
||||
"ogTitle": "Contributeurs | Documentation ProxMenux",
|
||||
"ogDescription": "Rencontrez les contributeurs derrière ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Contributeurs",
|
||||
"description": "Le projet ProxMenux grandit grâce à ses contributeurs. Cette page reconnaît leur travail : tester les versions avant leur publication, détecter les régressions, examiner les PR et orienter les nouvelles fonctionnalités.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"beyond": {
|
||||
"title": "Au-delà de cette liste",
|
||||
"body": "De nombreuses autres personnes contribuent en signalant des bugs, en proposant des fonctionnalités dans Discussions, en testant les versions bêta ou en traduisant le projet. La liste complète des contributeurs au code figure dans le <extlink>graphique des contributeurs GitHub</extlink>. La page ci-dessous met en avant les personnes les plus actives dans les tests et la vérification des versions de ProxMenux."
|
||||
},
|
||||
"testers": {
|
||||
"heading": "Testeurs et évaluateurs",
|
||||
"intro": "Ces personnes ont été parmi les premières à contribuer au projet. Leurs tests, signalements de problèmes et suggestions ont aidé ProxMenux à devenir ce qu’il est aujourd’hui.",
|
||||
"roles": {
|
||||
"testing": "Tests",
|
||||
"testingReviewer": "Tests et relecture"
|
||||
},
|
||||
"youtube": "YouTube"
|
||||
},
|
||||
"contribute": {
|
||||
"heading": "Vous voulez contribuer ?",
|
||||
"intro": "Toute contribution est la bienvenue — code, test, conception, documentation, ou tout simplement partager vos idées:",
|
||||
"tester": "<strong>Testeur</strong> — essayez le <beta>canal bêta</beta> et signalez ce qui fonctionne ou non avant la publication des versions stables.",
|
||||
"developer": "<strong>Développeur</strong> — Bash, Next.js (TypeScript) et un peu de Python pour l’environnement virtuel de traduction (venv). Les PR sont les bienvenues sur <gh>GitHub</gh>.",
|
||||
"designer": "<strong>Designer</strong> — Améliorations de l'interface utilisateur, icônes, captures d'écran pour la documentation.",
|
||||
"ideas": "<strong>Idées</strong> — ouvrez un sujet dans <disc>GitHub Discussions</disc> avant de créer une issue pour demander une fonctionnalité."
|
||||
},
|
||||
"coc": {
|
||||
"title": "Lisez d'abord le Code de conduite",
|
||||
"body": "Avant de proposer du code ou de signaler un problème, lisez le <coclink>Code de conduite et les bonnes pratiques</coclink>. Il précise les attentes sur la responsabilité du code, le signalement des vulnérabilités et le périmètre des PR."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Questions fréquentes | Documentation ProxMenux",
|
||||
"description": "Questions fréquentes sur ProxMenux : présentation, installation, compatibilité à partir de PVE 8, personnalisation, mises à jour, sécurité, utilisation en production, fichiers système, contributions et désinstallation.",
|
||||
"ogTitle": "Questions fréquentes | Documentation ProxMenux",
|
||||
"ogDescription": "Questions fréquentes sur l’installation de ProxMenux, sa compatibilité, sa sécurité et les façons de contribuer."
|
||||
},
|
||||
"header": {
|
||||
"title": "Foire aux questions",
|
||||
"description": "Questions courantes sur ProxMenux : présentation, public visé, installation, mise à jour, désinstallation, compatibilité, personnalisation, sécurité et contributions. Si votre question n’est pas ici, consultez GitHub Discussions ou ouvrez une issue.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"quickLinks": {
|
||||
"title": "Liens rapides",
|
||||
"installationLabel": "Installation",
|
||||
"installationSuffix": "— la commande d'installation en une seule ligne + dépendances.",
|
||||
"introductionLabel": "Présentation",
|
||||
"introductionSuffix": " — ce que fait ProxMenux, en cinq minutes.",
|
||||
"uninstallLabel": "Désinstaller",
|
||||
"uninstallSuffix": " — désinstallation propre.",
|
||||
"issuesLabel": "GitHub Issues",
|
||||
"discussionsLabel": "Discussions"
|
||||
},
|
||||
"q1": {
|
||||
"question": "Qu'est-ce que ProxMenux et dans quel cas est-il utilisé?",
|
||||
"p1Rich": "<strong>ProxMenux</strong> est un outil interactif à menus qui rend <strong>Proxmox VE</strong> accessible à tous, quel que soit le niveau technique. Il simplifie l’exécution des commandes et permet d’agir sur le système sans connaissances avancées de Linux.",
|
||||
"p2": "Les utilisateurs moins expérimentés exécutent les commandes depuis des menus structurés, avec moins de saisie manuelle dans le terminal. Les administrateurs expérimentés gagnent du temps sur les tâches répétitives : sécurisation après installation, passthrough GPU, importation de VM OVF et rotation des instantanés ZFS.",
|
||||
"p3": "Proxmox VE est largement utilisé pour:",
|
||||
"items": [
|
||||
"Virtualisation de qualité entreprise",
|
||||
"HomeLab et solutions cloud personnelles",
|
||||
"Serveurs multimédias, automatisation et plus encore"
|
||||
]
|
||||
},
|
||||
"q2": {
|
||||
"question": "Comment installer ProxMenux ?",
|
||||
"p1Rich": "Suivez le <installlink>guide d’installation</installlink>. En résumé :",
|
||||
"stableInstall": "bash -c \"$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)\"",
|
||||
"p2": "Une fois l’installation terminée, lancez simplement :",
|
||||
"menuCmd": "menu"
|
||||
},
|
||||
"q3": {
|
||||
"question": "ProxMenux est-il compatible avec toutes les versions Proxmox ?",
|
||||
"bodyRich": "<strong>Non — ProxMenux nécessite Proxmox VE 8 ou une version ultérieure.</strong> PVE 7 et les versions antérieures ne sont pas pris en charge. Passez d’abord de PVE 7 à 8.x en suivant la procédure officielle Proxmox. ProxMenux peut ensuite gérer le passage de 8 à 9 via <upgradelink>Utilitaires → Mettre à niveau PVE 8 vers PVE 9</upgradelink>."
|
||||
},
|
||||
"q4": {
|
||||
"question": "Puis-je personnaliser ProxMenux ?",
|
||||
"p1Rich": "Les mises à jour peuvent écraser les modifications locales des scripts principaux. Évitez donc de modifier directement ces fichiers. Voici ce que vous <em>pouvez</em> personnaliser :",
|
||||
"items": [
|
||||
"La bannière console via l'outil <strong>FastFetch</strong> dans les options Post-Install.",
|
||||
"Quels composants optionnels sont installés (Monitor, Fail2Ban, Lynis...) — choisissez lors de l'installation ou via le menu correspondant plus tard."
|
||||
]
|
||||
},
|
||||
"q5": {
|
||||
"question": "Comment mettre à jour ProxMenux?",
|
||||
"p1Rich": "Lorsqu’une nouvelle version est disponible, ProxMenux la détecte au prochain lancement de <code>menu</code> et propose la mise à jour. Si vous acceptez, les fichiers et la configuration de l’outil sont remplacés dans l’installation existante ; aucun téléchargement manuel n’est nécessaire.",
|
||||
"p2Rich": "Les utilisateurs de la version stable reçoivent les mises à jour stables, et ceux de la bêta, les mises à jour bêta. Lorsqu’une version stable est publiée, la bêta le signale à la prochaine ouverture du menu et propose de basculer automatiquement. Consultez le <betalink>programme bêta</betalink>."
|
||||
},
|
||||
"q6": {
|
||||
"question": "Où puis-je signaler les problèmes?",
|
||||
"p1Rich": "Signalez les bogues sur <issueslink>GitHub Issues</issueslink>. Indiquez les étapes pour les reproduire, le message d’erreur et, si nécessaire, la sortie de Monitor obtenue avec <code>journalctl -u proxmenux-monitor -n 50</code>.",
|
||||
"p2Rich": "Pour les problèmes de <strong>sécurité</strong>, <strong>ne les divulguez pas publiquement</strong>. Suivez la procédure de signalement responsable du <coclink>code de conduite et des bonnes pratiques</coclink>."
|
||||
},
|
||||
"q7": {
|
||||
"question": "Puis-je contribuer au ProxMenux?",
|
||||
"p1Rich": "<strong>Bien sûr.</strong> ProxMenux est un projet libre et collaboratif. Vous pouvez contribuer au code (Bash, Next.js/TypeScript et outils de traduction en Python), aux tests, à la documentation, au design ou proposer des idées.",
|
||||
"item1Rich": "Discutez des idées dans <discusslink>GitHub Discussions</discusslink> avant d'ouvrir une demande de fonctionnalité.",
|
||||
"item2Rich": "Avant de soumettre une pull request, lisez le <coclink>code de conduite et les bonnes pratiques</coclink>.",
|
||||
"item3Rich": "Consultez la <contriblink>page des contributeurs</contriblink> pour connaître les personnes qui participent actuellement aux tests et aux revues."
|
||||
},
|
||||
"q8": {
|
||||
"question": "Est-ce que ProxMenux modifie les fichiers système critiques?",
|
||||
"p1Rich": "<strong>L’installation de ProxMenux ajoute les composants suivants.</strong>",
|
||||
"item1Rich": "Dépendances via apt : <code>dialog</code>, <code>curl</code>, <code>jq</code> et <code>git</code>. Les traductions utilisent des catalogues JSON préconstruits ; l’installateur n’ajoute aucun environnement virtuel de traduction à l’hôte.",
|
||||
"item2Rich": "L'arborescence des scripts à <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "Le lanceur situé dans <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "En option : le service systemd de Monitor, <code>proxmenux-monitor.service</code>.",
|
||||
"p2Rich": "ProxMenux ne modifie <em>pas</em> la configuration principale de Proxmox, sauf si vous le demandez explicitement depuis un menu dédié. Par exemple, la réparation du réseau modifie <code>/etc/network/interfaces</code>, mais seulement après votre confirmation et la création d’une sauvegarde."
|
||||
},
|
||||
"q9": {
|
||||
"question": "Est-il sûr d'utiliser ProxMenux en production?",
|
||||
"bodyRich": "<strong>Oui.</strong> ProxMenux ne modifie les fichiers principaux de Proxmox que sur demande explicite et peut donc être utilisé en production. Comme pour toute automatisation, testez d’abord dans un environnement contrôlé et prévoyez des sauvegardes avant les opérations destructives : mise à niveau de PVE 8 vers 9, formatage d’un disque, suppression d’une VM, etc."
|
||||
},
|
||||
"q10": {
|
||||
"question": "Comment désinstaller ProxMenux ?",
|
||||
"p1Rich": "Dans ProxMenux : <strong>Paramètres → Désinstaller ProxMenux</strong>. La désinstallation supprime l’arborescence des scripts, le lanceur et le service Monitor, ainsi que les dépendances sélectionnées si vous le souhaitez. Elle restaure <code>/root/.bashrc</code> et <code>/etc/motd</code> depuis les sauvegardes de l’installation, si elles existent.",
|
||||
"p2Rich": "Étape par étape : <uninstalllink>Désinstaller ProxMenux</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal affiche l'URL d'installation — est-ce sûr?",
|
||||
"p1Rich": "Le résultat de 1/95 attribué à <em>Chong Lua Dao</em> et signalé dans l’issue #162 a été identifié par le mainteneur comme un faux positif. L’installateur utilise le modèle <code>curl | bash</code> et peut télécharger <code>jq</code> depuis sa version officielle sur GitHub. Ce <em>comportement</em> peut déclencher des analyses heuristiques ; ce rapport historique ne préjuge pas de tous les téléchargements futurs.",
|
||||
"p2Rich": "ProxMenux est entièrement open source. Vous pouvez examiner le script d’installation ligne par ligne : <scriptlink>install_proxmenux.sh</scriptlink>. Plus de contexte dans l’<issuelink>issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,67 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "À propos | Documentation ProxMenux",
|
||||
"description": "À propos de ProxMenux : objectifs du projet, contributeurs, FAQ et code de conduite. Cet outil de gestion open source à menus pour Proxmox VE 8+ est développé et maintenu par MacRimi avec une petite équipe de testeurs et de contributeurs.",
|
||||
"ogTitle": "À propos | Documentation ProxMenux",
|
||||
"ogDescription": "À propos de ProxMenux — un outil de gestion open source à menus pour Proxmox VE 8+."
|
||||
},
|
||||
"header": {
|
||||
"title": "À propos",
|
||||
"description": "Informations sur le projet, FAQ, contributeurs et code de conduite. ProxMenux est un outil de gestion open source à menus pour Proxmox VE 8+, développé et maintenu par MacRimi avec l’aide d’une petite équipe de testeurs et de contributeurs.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"callout": {
|
||||
"title": "Open source, porté par la communauté",
|
||||
"body": "ProxMenux est distribué sous licence GPL-3.0 et développé publiquement sur GitHub. Chaque script peut être examiné et chaque modification retracée. Les contributions sont les bienvenues : signalements de bugs, idées, code et tests."
|
||||
},
|
||||
"section": {
|
||||
"heading": "Dans cette section",
|
||||
"options": [
|
||||
{
|
||||
"icon": "HelpCircle",
|
||||
"href": "/docs/about/faq",
|
||||
"title": "FAQ",
|
||||
"description": "Questions fréquentes : présentation de ProxMenux, installation, compatibilité, personnalisation, mises à jour, sécurité, utilisation en production et désinstallation."
|
||||
},
|
||||
{
|
||||
"icon": "Users",
|
||||
"href": "/docs/about/contributors",
|
||||
"title": "Contributeurs",
|
||||
"description": "Un hommage aux personnes qui rendent ProxMenux possible : testeurs, relecteurs et développeurs qui contribuent à chaque version."
|
||||
},
|
||||
{
|
||||
"icon": "ScrollText",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"title": "Code de conduite",
|
||||
"description": "Valeurs du projet, attentes en matière de responsabilité du code et lignes directrices en matière de contribution. Lecture obligatoire avant d'ouvrir un PR ou un rapport."
|
||||
}
|
||||
]
|
||||
},
|
||||
"involved": {
|
||||
"heading": "Participer",
|
||||
"intro": "Trois endroits pour participer au projet :",
|
||||
"cards": [
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/issues/new",
|
||||
"title": "🐛 Signaler un bug",
|
||||
"description": "GitHub Issues — joignez les journaux et les étapes pour reproduire le problème."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"title": "💡 Proposer une fonctionnalité",
|
||||
"description": "GitHub Discussions — échangez des idées avant d'ouvrir un PR."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/pulls",
|
||||
"title": "🔀 Proposer une PR",
|
||||
"description": "GitHub Pull Requests — lisez d’abord le code de conduite."
|
||||
}
|
||||
]
|
||||
},
|
||||
"support": {
|
||||
"heading": "Soutenir le projet",
|
||||
"introRich": "Si ProxMenux vous fait gagner du temps, le moyen le plus simple de le faire découvrir est de <starlink>donner une ⭐ au dépôt sur GitHub</starlink>. Pour aller plus loin :",
|
||||
"kofiLabel": "Soutien sur Ko-fi",
|
||||
"kofiOutro": "— achète au responsable un café et continue le développement."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,220 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Création de sauvegardes — flux de sauvegarde interactif ProxMenux",
|
||||
"description": "Le processus de sauvegarde interactif de ProxMenux : deux points d’entrée (le menu TUI de Scripts et l’interface web de Monitor), trois destinations, deux modes de profil, une étape de préparation temporaire et une boîte de dialogue de confirmation. Cette page décrit la matrice de six options, les profils par défaut et personnalisé, et ce que voit l’utilisateur entre le choix d’une sauvegarde et l’enregistrement de l’archive à destination.",
|
||||
"ogTitle": "Sauvegarde ProxMenux — création de sauvegardes",
|
||||
"ogDescription": "Le processus de sauvegarde interactif avec trois destinations, deux profils et une étape commune de préparation temporaire.",
|
||||
"twitterTitle": "Création de sauvegardes ProxMenux",
|
||||
"twitterDescription": "Flux de sauvegarde interactif avec trois destinations et deux modes de profil."
|
||||
},
|
||||
"header": {
|
||||
"title": "Création de sauvegardes",
|
||||
"description": "Le processus de sauvegarde interactif : choisissez une destination et un profil, vérifiez le récapitulatif de confirmation et suivez l’enregistrement de l’archive. Les deux points d’entrée partagent le même backend et produisent des archives identiques.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Deux points d'entrée, fonctionnalité identique",
|
||||
"body": "La TUI de Scripts et l’interface web de Monitor offrent <strong>exactement les mêmes fonctions</strong>. Chaque sauvegarde — manuelle ou programmée — utilise la même matrice de choix (trois destinations × deux profils) et appelle la même fonction backend par cellule (<code>_bk_pbs</code>, <code>_bk_borg</code> ou <code>_bk_local</code>). Les archives produites depuis les deux points d’entrée sont identiques. Le choix dépend des préférences : la TUI se prête à SSH et aux scripts ; Monitor permet une utilisation à la souris et regroupe les vues des notifications et du suivi des journaux."
|
||||
},
|
||||
"entryPoints": {
|
||||
"heading": "Les deux points d'entrée",
|
||||
"rows": [
|
||||
{
|
||||
"entry": "ProxMenux Scripts (TUI)",
|
||||
"path": "menu → Utilities → Host Config Backup",
|
||||
"detail": "Processus fondé sur des boîtes de dialogue, adapté à SSH. Le menu principal présente directement les six options. Utilise <code>backup_menu</code> dans <code>backup_host.sh</code>."
|
||||
},
|
||||
{
|
||||
"entry": "ProxMenux Monitor (interface utilisateur Web)",
|
||||
"path": "Backups tab → Create backup",
|
||||
"detail": "Processus guidé par un assistant. Les six mêmes options sont présentées dans un formulaire en deux étapes (destination → profil). Les mêmes fonctions backend sont appelées via l’API Flask."
|
||||
}
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Sauvegardes manuelles ou programmées",
|
||||
"body": "Les sauvegardes peuvent être produites en deux modes : <strong>manuel</strong> (le processus interactif décrit sur cette page — l'utilisateur choisit une destination et un profil à partir d'un menu et suit l’enregistrement de l’archive) ou <strong>programmé</strong> (un travail sans surveillance qui fonctionne sur un minuteur de style cron et applique la rétention configurée sur le travail). Les deux modes supportent les mêmes trois destinations et les mêmes deux profils, et les deux sont disponibles à partir des deux points d'entrée — le menu Scripts TUI et l'onglet Sauvegardes Monitor. Les tâches programmées utilisent les mêmes fonctions de backend que le flux manuel à travers <code>run_scheduled_backup.sh</code> ; les archives produites sont indistinguables.",
|
||||
"seeAlso": "La page des tâches programmées décrit tout le processus, notamment la création d’une tâche, son association à un minuteur vzdump PVE existant et la configuration des valeurs de rétention.",
|
||||
"monitorAlt": "L'onglet Sauvegardes ProxMenux Monitor affiche la boîte de dialogue Nouvelle sauvegarde programmée avec les champs destination, profil, calendrier et conservation.",
|
||||
"monitorCaption": "Sauvegarde programmée — ProxMenux Monitor. La même boîte de dialogue de style assistant qui crée une sauvegarde manuelle porte les champs de planning et de rétention en bas pour le chemin sans surveillance."
|
||||
},
|
||||
"matrix": {
|
||||
"heading": "La matrice de six options",
|
||||
"intro": "Le choix détermine le backend exécuté et la stratégie de sélection des chemins. Consultez les pages de chaque destination pour connaître les détails de configuration de chaque cellule.",
|
||||
"rows": [
|
||||
{
|
||||
"combo": "1",
|
||||
"destination": "PBS",
|
||||
"profile": "Par défaut",
|
||||
"action": "Envoie le profil par défaut et les ajouts persistants vers un dépôt PBS configuré."
|
||||
},
|
||||
{
|
||||
"combo": "2",
|
||||
"destination": "Borg",
|
||||
"profile": "Par défaut",
|
||||
"action": "Crée une archive avec le profil par défaut plus des extras persistants dans le dépôt Borg sélectionné."
|
||||
},
|
||||
{
|
||||
"combo": "3",
|
||||
"destination": "Locale",
|
||||
"profile": "Par défaut",
|
||||
"action": "Écrit une archive <code>.tar.zst</code> avec le profil par défaut et des suppléments persistants à la cible locale configurée."
|
||||
},
|
||||
{
|
||||
"combo": "4",
|
||||
"destination": "PBS",
|
||||
"profile": "Personnalisé",
|
||||
"action": "Ouvre le sélecteur de chemins avant l’envoi vers PBS ; l’utilisateur coche les chemins et peut en ajouter."
|
||||
},
|
||||
{
|
||||
"combo": "5",
|
||||
"destination": "Borg",
|
||||
"profile": "Personnalisé",
|
||||
"action": "Ouvre le sélecteur de chemin avant la création de l'archive Borg."
|
||||
},
|
||||
{
|
||||
"combo": "6",
|
||||
"destination": "Locale",
|
||||
"profile": "Personnalisé",
|
||||
"action": "Ouvre le sélecteur de chemin avant d'écrire le <code>.tar.zst</code> local."
|
||||
}
|
||||
]
|
||||
},
|
||||
"profiles": {
|
||||
"heading": "Profil par défaut vs personnalisé",
|
||||
"defaultTitle": "Profil par défaut",
|
||||
"defaultBody": "Le profil par défaut est la liste prédéfinie de <code>hb_default_profile_paths</code> (documentée dans <em>Comment ça marche</em> sous <em>Catégories de chemins</em>) plus chaque entrée dans le fichier supplémentaire persistant <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. L'utilisateur confirme les options de destination et de chiffrement et la sauvegarde se déroule sans autre sélection de chemin.",
|
||||
"customTitle": "Profil personnalisé",
|
||||
"customBody": "Le profil personnalisé ouvre une liste à cocher avec tous les chemins du profil par défaut (décochés) et tous les ajouts persistants (précochés, avec le préfixe <code>[+]</code>). L’utilisateur coche les chemins pour cette exécution et peut cliquer sur <em>Ajouter un chemin personnalisé</em> pour ajouter un chemin absolu. Tout chemin ainsi ajouté est enregistré dans <code>backup-extra-paths.txt</code> afin que les sauvegardes suivantes l’incluent automatiquement. Décocher un ajout persistant l’exclut de cette exécution sans le supprimer du fichier — la suppression se fait séparément par <em>Gérer les chemins personnalisés</em>, en dehors du processus de sauvegarde.",
|
||||
"customPickerAlt": "Liste de contrôle de profil personnalisé montrant les chemins de profil par défaut (non coché) et les extras persistants (pré coché avec un préfixe [+]), ainsi que des boutons pour ajouter un nouveau chemin ou confirmer la sélection.",
|
||||
"customPickerCaption": "Profil personnalisé — le sélecteur de chemins. Les chemins du profil par défaut sont décochés ; les ajouts persistants sont précochés avec le préfixe [+]. L’utilisateur coche les chemins pour cette exécution.",
|
||||
"manageCustomAlt": "Menu de gestion des chemins personnalisés montrant les ajouts persistants et les options pour les ajouter, les supprimer ou les modifier.",
|
||||
"manageCustomCaption": "Gérer les chemins personnalisés — le point d'entrée où des extras persistants sont ajoutés ou supprimés. Chaque chemin listé ici est automatiquement inclus dans les sauvegardes en mode Défaut sans avoir à ouvrir le sélecteur personnalisé."
|
||||
},
|
||||
"commonPipeline": {
|
||||
"heading": "Ce qui s’exécute quelle que soit la destination",
|
||||
"intro": "Une fois le profil défini, chaque backend suit le même processus de préparation temporaire avant de passer à sa propre méthode d’envoi. <code>hb_prepare_staging</code> assemble l’arborescence de l’archive dans <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> et remplit chacun des trois blocs de données.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"name": "Assemblage du rootfs",
|
||||
"detail": "Exécute <code>rsync -a</code> pour chaque chemin sélectionné dans <code>staging_root/rootfs/</code>. La base de données pmxcfs de <code>/var/lib/pve-cluster/config.db</code> est capturée séparément via <code>sqlite3 .backup</code> pour produire un instantané cohérent sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync; lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé comme base de données lors de l’importation. Les sous-chemins volatils (historique bash, caches, poubelles) sont exclus du <code>/root/</code>. Les chemins absents de la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"name": "Génération de manifestes",
|
||||
"detail": "<code>build_manifest.sh</code> coordonne les six collecteurs et écrit <code>manifest.json</code> à la racine du répertoire temporaire. Si un collecteur échoue, la section concernée reçoit une valeur vide par défaut documentée ; le manifeste reste valide."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"name": "Inventaire des paquets",
|
||||
"detail": "<code>apt-mark showmanual</code> est capté mot à mot dans <code>metadata/packages.manual.list</code>. L'état des composants est déjà à l'intérieur des rootfs restauré (<code>components_status.json</code>) car <code>/usr/local/share/proxmenux/</code> fait partie du profil par défaut."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"name": "Informations sur l’exécution",
|
||||
"detail": "<code>metadata/run_info.env</code> enregistre l'identité d'exécution de sauvegarde — nom d'hôte, horodatage, version du noyau — utilisée par la vérification de compatibilité de la restauration pour déterminer la direction du cross-kernel."
|
||||
},
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Notification (démarrage)",
|
||||
"detail": "<code>hb_notify_lifecycle \"start\"</code> est déclenché. Si les notifications sont configurées dans Monitor, un événement <em>Sauvegarde de l’hôte démarrée</em> est envoyé à l’utilisateur. Aucun envoi si aucun canal n’est configuré."
|
||||
}
|
||||
]
|
||||
},
|
||||
"included": {
|
||||
"heading": "Ce qui entre et ce qui reste en dehors",
|
||||
"intro": "Chaque chemin dans le profil résolu (par défaut + suppléments persistants + sélection en mode personnalisé) est copié avec <code>rsync -aAXH --numeric-ids</code>. Une liste d'exclusion partagée s'applique à chaque chemin, et deux répertoires comportent d'autres exclusions spécifiques au chemin.",
|
||||
"globalTitle": "Les exclusions globales (appliquées à chaque voie)",
|
||||
"globalItems": [
|
||||
"<code>images/</code> — images de disque exportées.",
|
||||
"<code>dump/</code> — sorties vzdump.",
|
||||
"<code>tmp/</code> — fichiers temporaires.",
|
||||
"<code>*.log</code> — fichiers journaux."
|
||||
],
|
||||
"rootTitle": "Exclusions de <code>/root/</code>",
|
||||
"rootBody": "<code>/root/</code> fait partie du profil par défaut, de sorte que les scripts utilisateur et la configuration se trouvent dans l'archive. Les sous-chemins volatils sont abandonnés:",
|
||||
"rootItems": [
|
||||
"<code>.bash_history</code>",
|
||||
"<code>.cache/</code>",
|
||||
"<code>tmp/</code>",
|
||||
"<code>.local/share/Trash/</code>"
|
||||
],
|
||||
"proxmenuxTitle": "Exclusions de <code>/usr/local/share/proxmenux/</code>",
|
||||
"proxmenuxBody": "Ce répertoire ne livre que l'état utilisateur — <code>components_status.json</code>, préférences, cache post-installation. Code que la destination aura déjà de sa propre installation ProxMenux est exclu de sorte qu'une restauration n'écrase pas les binaires actuels de la cible avec les plus anciens:",
|
||||
"proxmenuxItems": [
|
||||
"<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
|
||||
"<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
|
||||
"<code>images/</code>, <code>json/</code>",
|
||||
"<code>utils.sh</code>, <code>helpers_cache.json</code>",
|
||||
"<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
|
||||
],
|
||||
"notInProfileTitle": "Chemins en dehors du profil",
|
||||
"notInProfileBody": "Tout ce qui n'est pas listé dans <code>hb_default_profile_paths</code> et qui n'est pas ajouté en tant qu'extra personnalisé ou persistant ne fait pas partie de la sauvegarde. Exemples notables:",
|
||||
"notInProfileItems": [
|
||||
"<strong>Disques des VM et des LXC</strong> — manipulés par <code>vzdump</code>, pas par cette fonctionnalité. Les fichiers de configuration invités sous <code>/etc/pve/nodes/*/qemu-server/*.conf</code> et <code>lxc/*.conf</code> sont capturés (ils vivent sous <code>/etc/pve</code>) de sorte que la restauration reproduit l'inventaire; les disques eux-mêmes sont ré-attachés à partir d'une sauvegarde existante vzdump/PBS.",
|
||||
"<strong><code>/boot</code> et <code>/boot/efi</code></strong> — les binaires du noyau, les initramfs et la partition ESP UEFI sont régénérés par les propres <code>update-initramfs</code>, <code>update-grub</code> ou <code>proxmox-boot-tool refresh</code> après la restauration. Le chargeur de démarrage n’est jamais recopié à l’identique.",
|
||||
"<strong>Les systèmes de fichiers de noyau et d'exécution du système</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> et <code>/run</code> sont des pseudo-systèmes de fichiers produits par le noyau et l'udev; ils ne persistent nulle part.",
|
||||
"<strong>Binaires des paquets sous <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — réinstallés par APT sur la cible à partir de <code>packages.manual.list</code>.",
|
||||
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — état d'exécution par hôte, non restauré.",
|
||||
"<strong><code>/home/USER</code></strong> — pas dans le profil par défaut. Ajoutez-le comme un chemin personnalisé lorsqu'un système transporte des répertoires d'utilisateur qui doivent survivre à une restauration."
|
||||
],
|
||||
"customPathsTitle": "Comment les chemins personnalisés sont gérés",
|
||||
"customPathsBody": "Un chemin personnalisé ajouté en ligne en mode personnalisé ou maintenu dans <code>backup-extra-paths.txt</code> passe par le même pipeline <code>rsync</code> que les chemins de profil par défaut. Les exclusions globales s'appliquent. Si le chemin personnalisé se trouve sous <code>/root/</code> ou <code>/usr/local/share/proxmenux/</code>, les exclusions spécifiques au chemin ci-dessus s'appliquent toujours. Chaque chemin archivé — par défaut ou personnalisé — est enregistré dans <code>metadata/paths_archived.txt</code>. Les chemins qui n'existent pas sur la source sont enregistrés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
|
||||
},
|
||||
"archiveStructure": {
|
||||
"heading": "Structure des archives",
|
||||
"intro": "Le répertoire de préparation temporaire produit par chaque moteur suit la même disposition quelle que soit la destination. L'archive tarball, PBS <code>.pxar</code> ou Borg stocke cet arbre dans son intégralité.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│ ├── packages.manual.list # output of apt-mark showmanual\n│ ├── run_info.env # hostname, timestamp, kernel version, pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n ├── root/ # /root without volatile subpaths\n ├── usr/local/ # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
|
||||
},
|
||||
"confirmation": {
|
||||
"heading": "Résumé de la confirmation",
|
||||
"body": "Avant que le moteur n'écrive quoi que ce soit à la destination, ProxMenux affiche une boîte de dialogue de résumé avec la destination, l’identifiant de sauvegarde ou le nom de l’archive, l'état de chiffrement et la liste des chemins copiés. Annuler ici avorte la sauvegarde proprement — le répertoire temporaire est supprimé par le gestionnaire <code>trap</code> défini dans la fonction backend et aucune donnée partielle n'arrive à destination."
|
||||
},
|
||||
"writing": {
|
||||
"heading": "Écrire à la destination",
|
||||
"intro": "Après confirmation, chaque backend exécute sa propre étape d’écriture. Les pages des destinations en décrivent le fonctionnement ; les éléments communs sont le journal, le fichier annexe et la notification de fin.",
|
||||
"rows": [
|
||||
{
|
||||
"topic": "Fichier journal",
|
||||
"detail": "Chaque moteur écrit sa sortie complète sur <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> et, en cas d'échec, propose de l'ouvrir dans une boîte de dialogue défilante. Le chemin du journal n'est imprimé dans le résumé d'achèvement que lorsque le fichier contient du contenu."
|
||||
},
|
||||
{
|
||||
"topic": "Sidecar (local seulement)",
|
||||
"detail": "<code>hb_write_archive_sidecar</code> dépose un <code>*.proxmenux.json</code> à côté de l'archive locale afin que le moniteur l'identifie comme une sauvegarde d'hôte ProxMenux même après des déplacements ou des renoms."
|
||||
},
|
||||
{
|
||||
"topic": "Notification (réussite/échec)",
|
||||
"detail": "<code>hb_notify_lifecycle \"complete\"</code> ou <code>\"fail\"</code> est déclenché avec la durée, la taille de l’archive et — en cas d’échec — la dernière ligne du journal qui ressemble à une erreur."
|
||||
}
|
||||
]
|
||||
},
|
||||
"finishedScreens": {
|
||||
"heading": "A quoi ressemble une sauvegarde terminée",
|
||||
"intro": "Le même événement d'achèvement est présenté par les deux points d'entrée. Le TUI écrit un bloc de résumé au terminal; l'onglet Sauvegardes de Monitor affiche l'exécution dans la liste des archives avec la taille, la durée et les badges d'état.",
|
||||
"scriptsAlt": "ProxMenux Scripts TUI montrant une sauvegarde d'hôte terminée — destination, ID de sauvegarde, chemin instantané, taille des données, durée et état de chiffrement.",
|
||||
"scriptsCaption": "Sauvegarde terminée — ProxMenux Scripts (TUI). Le bloc d'achèvement imprime la destination, l'ID de sauvegarde, le nom d'instantané ou d'archive, la taille des données, la durée et l'état de chiffrement.",
|
||||
"monitorAlt": "Onglet de sauvegarde ProxMenux Monitor montrant une entrée de sauvegarde d'hôte terminée avec taille, durée, badge de méthode et indicateur de chiffrement.",
|
||||
"monitorCaption": "Sauvegarde terminée — onglet Sauvegardes ProxMenux Monitor. La nouvelle sauvegarde apparaît dans la liste des archives avec le badge de la méthode de destination, la taille, la durée et, le cas échéant, l'indicateur de verrouillage de chiffrement."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite?",
|
||||
"items": [
|
||||
{
|
||||
"label": "Destinations",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— détails de configuration pour Local, PBS et Borg."
|
||||
},
|
||||
{
|
||||
"label": "Tâches programmées",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": " — exécuter la même sauvegarde sans intervention selon un calendrier, plutôt que de façon interactive."
|
||||
},
|
||||
{
|
||||
"label": "Restauration",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— le flux qui consomme ce que cette page produit."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Restauration entre noyaux différents — détection, filtrage et adaptation | ProxMenux",
|
||||
"description": "Comment ProxMenux restaure une sauvegarde d’hôte sur une version principale différente du noyau. Détection du sens de l’écart, filtre des chemins critiques si la cible utilise un noyau plus récent et adaptation en quatre phases pour réappliquer IOMMU, ID VFIO et paramètres de ligne de commande sans recopier tels quels les fichiers liés au noyau.",
|
||||
"ogTitle": "ProxMenux Backup — restauration entre versions du noyau et adaptation",
|
||||
"ogDescription": "Restauration entre versions du noyau tenant compte du sens du changement, avec filtrage sûr et adaptation indépendante du noyau.",
|
||||
"twitterTitle": "Restauration entre noyaux différents | ProxMenux",
|
||||
"twitterDescription": "Comment ProxMenux gère une restauration lorsque le noyau cible diffère de celui de la sauvegarde."
|
||||
},
|
||||
"header": {
|
||||
"title": "Restauration entre versions du noyau",
|
||||
"description": "Comment ProxMenux gère une restauration lorsque l'hôte cible exécute un noyau différent de celui enregistré dans la sauvegarde, surtout lorsque la cible exécute un noyau plus récent. Explique comment la différence est détectée, comment les chemins critiques de démarrage qui pourraient briser la cible sont filtrés, et comment la configuration propre de l'utilisateur est réappliquée sans copier les fichiers liés au noyau mot pour mot.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Chaque saut du noyau est géré différemment",
|
||||
"body": "Le noyau d'un hôte Proxmox est identifié par une chaîne de version comme <code>6.17.13-2-pve</code>. Les deux premiers nombres (<strong>6.17</strong> dans cet exemple) définissent la version principale : lorsqu'ils changent, certains fichiers de configuration écrits pour le noyau précédent peuvent ne pas être valides sur le nouveau. Lorsque la restauration détecte que la sauvegarde et la cible ont différentes versions majeures du noyau, les branches de flux basées sur la direction du saut — que la sauvegarde soit plus ancienne ou plus récente que la cible — parce que les deux cas ont des modes de défaillance opposés. Les sauvegardes plus récentes que la cible restaurent proprement comme-est (vérifiées sur plusieurs sauts du noyau). Les sauvegardes plus anciennes que la cible ont besoin d'un filtre pour éviter de casser le démarrage de la cible avec une configuration écrite pour un noyau qui a depuis changé."
|
||||
},
|
||||
"directionCheck": {
|
||||
"heading": "Le contrôle de direction",
|
||||
"intro": "Lors de la vérification de compatibilité, <code>hb_compat_check</code> compare le noyau enregistré dans le manifeste de sauvegarde au noyau courant de la cible (<code>uname -r</code>) et classifie la restauration dans l'un des trois cas, stockés dans la variable interne <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
|
||||
"rows": [
|
||||
{
|
||||
"direction": "same",
|
||||
"condition": "La version principale du noyau correspond entre la sauvegarde et la cible.",
|
||||
"behavior": "Le flux complet de restauration est inchangé. Pas de filtre supplémentaire, pas d'hydratation, pas de notice spéciale dans l'interface utilisateur."
|
||||
},
|
||||
{
|
||||
"direction": "bk_newer",
|
||||
"condition": "Le noyau de la sauvegarde est PLUS RÉCENT que celui de la cible (exemple : sauvegarde sous 7.0, cible sous 6.17).",
|
||||
"behavior": "Le processus complet reste inchangé, comme pour <code>same</code>, sans filtre. Les essais rapportés ont montré la réinstallation des pilotes pour le noyau cible, l’application de la configuration IOMMU et le démarrage des VM avec passthrough GPU."
|
||||
},
|
||||
{
|
||||
"direction": "bk_older",
|
||||
"condition": "Le noyau de la sauvegarde est PLUS ANCIEN que celui de la cible (exemple : sauvegarde sous 6.17, cible sous 7.0).",
|
||||
"behavior": "Le filtre sous-ensemble et l'hydratation en quatre phases ci-dessous sont activés. Le processus de restauration — la cible reproduit la source, mais les fichiers critiques de démarrage ne sont pas copiés mot à mot."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyBkNewerIsSafe": {
|
||||
"heading": "Pourquoi une sauvegarde avec un noyau plus récent que la cible restaure inchangé",
|
||||
"body": "Lorsque la restauration s'exécute contre une cible avec un noyau <em>plus ancien</em> que celui enregistré dans la sauvegarde, chaque mécanisme dont dépend la restauration est indépendant de la version du noyau. Les installateurs de pilotes GPU et d'autres installateurs PCI détectent le noyau en cours d'exécution avec <code>uname -r</code> et compilent DKMS contre tout ce que la cible a. Le paquet APT installe tire des binaires construits pour la distribution de la cible. Les jetons IOMMU cmdline comme <code>intel_iommu=on</code> sont stables dans les principales versions du noyau. La sauvegarde porte des chemins écrits sous un noyau plus récent, mais ces chemins (module blacklists, GRUB par défaut, initramfs config) sont toujours valides sur l'ancien — les noyaux ignorent les jetons qu'ils ne reconnaissent pas au lieu d'échouer. Ce cas est équivalent en pratique à une restauration du même noyau, et ProxMenux le traite comme tel."
|
||||
},
|
||||
"safeSubsetFilter": {
|
||||
"heading": "Le filtre de sous-ensemble de sécurité (uniquement lorsque le noyau cible est plus récent)",
|
||||
"intro": "Lorsque le noyau cible est plus récent que celui de la sauvegarde, la vérification de compatibilité ajoute des chemins critiques de démarrage 16 de <code>hb_unsafe_paths_cross_version</code> à <code>RS_SKIP_PATHS</code>. Ces chemins sont exclus de la restauration parce que l'écriture d'une version d'un noyau plus ancien sur une cible en cours d'exécution d'un nouveau a causé des paniques du noyau dans les tests de banc. Les chemins couvrent cinq catégories:",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Chargeur d'amorçage",
|
||||
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
|
||||
"reason": "GRUB est lié à l'ordre du noyau précédent, et à l'état proxmox-boot-tool (cmdline, ESP UUIDs, crochets) qui fait référence aux chemins et aux identifiants de l'ancienne installation."
|
||||
},
|
||||
{
|
||||
"category": "Modules de noyau et artefacts de démarrage",
|
||||
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
|
||||
"reason": "Autoload listes qui peuvent renvoyer des modules rebaptisés entre les majors du noyau, options de module qui peuvent ne pas s'appliquer, initramfs crochets écrits pour l'ancien noyau."
|
||||
},
|
||||
{
|
||||
"category": "Empilement de stockage et identité du système de fichiers",
|
||||
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
|
||||
"reason": "UUID qui peuvent ne pas exister sur cette installation, pilotes multipath qui changent entre les noyaux, paramètres iSCSI qui évoluent, règles udev qui peuvent se lier à des sous-systèmes inexistants, état ZFS (<code>zpool.cache</code> + <code>hostid</code>) qui peuvent verrouiller le pool comme étranger."
|
||||
},
|
||||
{
|
||||
"category": "Sources APT",
|
||||
"paths": "<code>/etc/apt</code>",
|
||||
"reason": "Les suites sources APT peuvent déclencher une dégradation des paquets critiques lors de la prochaine mise à jour."
|
||||
},
|
||||
{
|
||||
"category": "systemd",
|
||||
"paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
|
||||
"reason": "Surcharges d’unités et liens .wants liés à une ancienne version majeure de systemd ; clés de configuration pouvant être invalides pour une version plus récente."
|
||||
}
|
||||
],
|
||||
"outroBody": "Le filtre fonctionne AVANT la boîte de dialogue de confirmation afin que l'utilisateur voit la liste exacte des chemins qui seront ignorés, catégorisé par la raison. La restauration continue — tout le reste (configuration VM/LXC, réseau, /etc/pve, utilisateurs, cron, état ProxMenux, paquets, pilotes, /root) est restauré normalement."
|
||||
},
|
||||
"hydration": {
|
||||
"heading": "Hydratation du noyau-agnostique",
|
||||
"intro": "Le filtre omet les fichiers critiques ; l’adaptation réapplique certains réglages : paramètres IOMMU, ID VFIO, <code>GRUB_TIMEOUT</code> personnalisé et listes de blocage nvidia. Elle s’exécute si le noyau cible est plus récent. La fusion cmdline conserve les clés de la cible et ajoute les modules manquants. Les valeurs GRUB et fichiers autorisés peuvent remplacer un contenu cible différent. Répéter les mêmes entrées est idempotent.",
|
||||
"phaseRows": [
|
||||
{
|
||||
"phase": "1a — Voie GRUB",
|
||||
"detail": "Pour les hôtes GRUB (installations ext4/lvm). <code>_rs_hyd_grub</code> fusionne les paramètres de <code>manifest.kernel_params.cmdline_extra</code> de la sauvegarde dans <code>GRUB_CMDLINE_LINUX_DEFAULT</code> de la cible, en ignorant les clés déjà présentes. Il reprend ensuite les clés autorisées <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) depuis <code>/etc/default/grub</code> de la sauvegarde si leurs valeurs diffèrent de la cible."
|
||||
},
|
||||
{
|
||||
"phase": "1b — systemd-boot / ZFS",
|
||||
"detail": "Pour systemd-boot (souvent ZFS à la racine). <code>_rs_hyd_kernel_cmdline</code> fusionne les paramètres utilisateur de <code>cmdline_extra</code> dans <code>/etc/kernel/cmdline</code> de la cible tout en préservant ses paramètres de démarrage <code>root=</code>, <code>boot=</code> et <code>rootflags=</code>."
|
||||
},
|
||||
{
|
||||
"phase": "2 — Fusion /etc/modules",
|
||||
"detail": "<code>_rs_hyd_modules</code> ajoute des modules de <code>manifest.kernel_params.modules_loaded_at_boot</code> qui sont dans la liste blanche (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) ET n'est pas déjà présent dans la cible <code>/etc/modules</code>."
|
||||
},
|
||||
{
|
||||
"phase": "3 — Copie des fichiers figurant sur la liste blanche",
|
||||
"detail": "<code>_rs_hyd_files</code> copie les fichiers rédigés par l’utilisateur depuis les rootfs jusqu'à la cible en direct lorsque le contenu diffère. La liste blanche couvre les fichiers VFIO/nvidia/blacklist sous <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, et la règle de liaison ProxMenux VFIO + règles nvidia udev sous <code>/etc/udev/rules.d</code>. Les fichiers appartenant à des Distro (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) sont délibérément exclus — leur contenu évolue entre les versions."
|
||||
},
|
||||
{
|
||||
"phase": "4 — Forcer la régénération après démarrage",
|
||||
"detail": "Les quatre phases écrivent directement à la cible en direct EN DEHORS DE le pipeline normal de restauration. Pour que les paramètres/modules/fichiers fusionnés prennent effet sur le prochain boot, <code>HB_HYDRATION_APPLIED=1</code> se propage via <code>plan.env</code> vers <code>apply_pending_restore.sh</code>, ce qui force <code>NEEDS_INITRAMFS=1</code> et <code>NEEDS_GRUB=1</code> indépendamment de ce qui était dans la liste d'application. Le répartiteur post-démarrage régénère ensuite les initramfs et rafraîchit le chargeur."
|
||||
}
|
||||
]
|
||||
},
|
||||
"planCommit": {
|
||||
"heading": "Plan vs commit — l'utilisateur voit d'abord un aperçu",
|
||||
"body": "L'hydratation fonctionne en deux modes. Avant la boîte de dialogue de confirmation, ProxMenux exécute <code>_rs_apply_bk_older_hydration</code> en mode <code>plan</code> : il calcule exactement ce qui serait fusionné, peuple <code>RS_HYDRATION_SUMMARY</code> avec un bloc vert listant chaque action, et retourne sans écrire. La boîte de dialogue de confirmation montre que le bloc vert à côté de la liste orange des chemins exclus, de sorte que l'utilisateur voit À L’AVANCE ce qui sera ré-appliqué automatiquement. Après que l'utilisateur ait confirmé, ProxMenux réexécute le même helper en mode <code>commit</code> — mêmes phases, même logique, mais cette fois chaque phase écrit à la cible en direct. L'annulation de la boîte de dialogue de confirmation laisse la cible intacte."
|
||||
},
|
||||
"flowDiagram": {
|
||||
"heading": "Le flux lorsque le noyau cible est plus récent que celui de la sauvegarde",
|
||||
"intro": "Les étapes ajoutées lorsque le noyau cible est plus récent s'assoient à l'intérieur du flux normal de restauration. Tout le reste — application chaude, préparation en attente, installation de paquets, répartiteur post-démarrage — fonctionne identiquement à une restauration du même noyau.",
|
||||
"diagram": " ┌────────────────────────────────────────────────────────────┐\n │ hb_compat_check │\n │ HB_COMPAT_KERNEL_DIRECTION = bk_older │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Add 16 boot-critical paths to RS_SKIP_PATHS │\n │ /etc/default/grub, /etc/kernel, /etc/modules-load.d, ... │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"plan\" │\n │ Compute what would be merged │\n │ Populate RS_HYDRATION_SUMMARY (green block) │\n │ No writes │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Confirmation dialog │\n │ Amber: paths skipped by safe-subset filter │\n │ Green: tokens/files reapplied by hydration │\n │ User accepts or cancels │\n └───────────────────────────┬────────────────────────────────┘\n │ (accepted)\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"commit\" │\n │ Phase 1a/1b: merge cmdline tokens + GRUB keys │\n │ Phase 2: append modules to /etc/modules │\n │ Phase 3: copy whitelisted vfio/nvidia files │\n │ Set HB_HYDRATION_APPLIED=1 │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Rest of the restore runs normally │\n │ _rs_apply hot (skips RS_SKIP_PATHS) │\n │ _rs_prepare_pending_restore (writes plan.env with │\n │ HB_HYDRATION_APPLIED=1) │\n │ packages.manual.list install │\n │ Reboot │\n │ apply_pending_restore.sh (forces NEEDS_INITRAMFS=1, │\n │ NEEDS_GRUB=1 because of the hydration flag) │\n │ apply_cluster_postboot.sh │\n │ update-initramfs -u -k all │\n │ update-grub / proxmox-boot-tool refresh │\n │ component --auto-reinstall │\n └────────────────────────────────────────────────────────────┘"
|
||||
},
|
||||
"concreteExamples": {
|
||||
"heading": "Exemples concrets",
|
||||
"intro": "Le passe d'hydratation n'est pas abstrait — il produit des résultats observables et corrects pour des scénarios communs. Deux exemples que l'hydratation gère automatiquement :",
|
||||
"rows": [
|
||||
{
|
||||
"scenario": "Passage de GPU (VFIO)",
|
||||
"detail": "La source avait le <code>intel_iommu=on iommu=pt</code> dans la ligne cmd, le <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> dans le <code>/etc/modules</code>, un <code>/etc/modprobe.d/vfio.conf</code> avec le <code>options vfio-pci ids=10de:2216</code> et un <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. L'hydratation fusionne les jetons cmdline dans le GRUB de la cible ou le noyau cmdline, ajoute les modules vfio au <code>/etc/modules</code>, et copie les deux fichiers modprobe rédigés par l’utilisateur. Sur le prochain démarrage, IOMMU est actif, les modules VFIO chargent, le GPU est lié à vfio-pci et le VM est livré avec le travail de passage."
|
||||
},
|
||||
{
|
||||
"scenario": "Par défaut du GRUB personnalisé",
|
||||
"detail": "Source : <code>GRUB_TIMEOUT=1</code> et <code>GRUB_DISABLE_OS_PROBER=true</code>. L'hydratation lit les deux clés de la sauvegarde <code>/etc/default/grub</code>, voit qu'elles diffèrent des valeurs par défaut de la nouvelle installation, et réécrit ces deux lignes dans le fichier de la cible (en laissant tout le reste, y compris <code>GRUB_DISTRIBUTOR</code>, intact)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"warningTitle": "Ce que l'hydratation ne réapplique pas lorsque le noyau cible est plus récent",
|
||||
"warningBody": "L'hydratation ne réapplique que la configuration ProxMenux sait être sûre dans toutes les versions du noyau : jetons IOMMU, ID VFIO, clés GRUB sur liste blanche et modules d'une liste fixe (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Tout ce qui se trouve à l'extérieur de cet ensemble — les crochets initramfs personnalisés sous <code>/etc/initramfs-tools/hooks/</code>, les fichiers non inscrits sur la liste blanche sous <code>/etc/modprobe.d/</code>, les surcharges d’unités systemd rédigées par l’utilisateur — reste exclu. La raison en est concrète : ces fichiers peuvent appeler des interfaces internes au noyau (API modulaires, mise en page <code>/sys</code>, crochets <code>udev</code>) qui changent entre les versions principales, et les appliquer mot à mot sur le nouveau noyau peut empêcher la cible de démarrer. Lorsque la reproduction exacte de la chaîne de démarrage est requise, la restauration doit être exécutée sur un hôte avec la même version principale du noyau que la sauvegarde."
|
||||
},
|
||||
"codeReference": {
|
||||
"heading": "Où vivent les mécanismes",
|
||||
"intro": "Pour les développeurs qui cherchent à tracer ou à étendre le comportement du cross-kernel:",
|
||||
"rows": [
|
||||
{
|
||||
"component": "Détection de la direction",
|
||||
"location": "<code>hb_compat_check</code> dans <code>lib_host_backup_common.sh</code>. Définit <code>HB_COMPAT_KERNEL_DIRECTION</code>."
|
||||
},
|
||||
{
|
||||
"component": "Liste des chemins de sous-ensembles sécurisés",
|
||||
"location": "<code>hb_unsafe_paths_cross_version</code> dans <code>lib_host_backup_common.sh</code>. Émet <code>path\\treason</code> lignes utilisées à la fois par le filtre CLI et le point de terminaison Web <code>/api/host-backups/restore/prepare</code>."
|
||||
},
|
||||
{
|
||||
"component": "Phases d'hydratation",
|
||||
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> dans <code>backup_host.sh</code>. Ordonné par <code>_rs_apply_bk_older_hydration</code>."
|
||||
},
|
||||
{
|
||||
"component": "Régénération forcée après démarrage",
|
||||
"location": "<code>apply_pending_restore.sh</code> lit <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> et force <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
|
||||
},
|
||||
{
|
||||
"component": "Aperçu du Web",
|
||||
"location": "<code>/api/host-backups/restore/prepare</code> dans <code>flask_server.py</code>. Charge la bibliothèque d'aide, exécute <code>_rs_apply_bk_older_hydration</code> en mode plan, renvoie les actions au mode Web."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite?",
|
||||
"items": [
|
||||
{
|
||||
"label": "Restauration",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — le processus complet de restauration qui intègre les mécanismes de cette page."
|
||||
},
|
||||
{
|
||||
"label": "Comment ça marche",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — le manifeste et les collecteurs qui produisent le bloc <code>kernel_params</code> lu par l’adaptation."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,234 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destination Borg — types de dépôts, authentification SSH, chiffrement | ProxMenux",
|
||||
"description": "La destination Borg enregistre les sauvegardes d’hôte ProxMenux dans un dépôt local, sur un disque externe monté ou sur un serveur distant via SSH. Cette page décrit la recherche de l’exécutable borg, les quatre options initiales de clé SSH, le chiffrement repokey, la configuration des destinations enregistrées et la rétention par tâche planifiée.",
|
||||
"ogTitle": "Sauvegarde ProxMenux — Destination borg",
|
||||
"ogDescription": "Comment ProxMenux enregistre les sauvegardes d’hôte dans des dépôts Borg avec authentification SSH et chiffrement repokey.",
|
||||
"twitterTitle": "Destination de sauvegarde Borg: ProxMenux",
|
||||
"twitterDescription": "Dépôts Borg locaux, USB et SSH pour les sauvegardes hôtes."
|
||||
},
|
||||
"header": {
|
||||
"title": "Borg",
|
||||
"description": "La destination Borg écrit des sauvegardes d'hôte dans un dépôt Borg. Trois types de dépôt sont pris en charge : chemin du système de fichiers local, disque externe monté ou serveur distant via SSH. Déduplication au niveau du chunk dans toutes les archives du dépôt et cryptage facultatif des repokey.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"aboutBorg": {
|
||||
"heading": "Ce que Borg est",
|
||||
"body": "Borg, aussi appelé BorgBackup, est un outil de sauvegarde libre avec déduplication, maintenu par la communauté Borg Backup. Il stocke chaque archive sous forme de blocs de longueur variable dans un dépôt. Les blocs sont partagés entre archives : sauvegarder à nouveau des données inchangées ne consomme presque aucun espace supplémentaire. Borg est indépendant de Proxmox et sert dans de nombreux environnements. ProxMenux l’utilise comme l’une des trois destinations de sauvegarde d’hôte ; les mécanismes décrits ici (types de dépôts, borg-serve via SSH, chiffrement repokey, prune) sont ceux de Borg."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Déduplication par blocs avec dépôts locaux ou accessibles via SSH",
|
||||
"body": "Un dépôt Borg stocke des blocs partagés entre toutes ses archives. Sauvegarder à nouveau un fichier inchangé ne transfère ni ne stocke de nouvelles données. ProxMenux utilise <code>borg create</code> pour sauvegarder et <code>borg extract</code> pour restaurer. Le dépôt peut se trouver sur le même système de fichiers que la source, sur un disque externe monté ou sur un hôte distant accessible via SSH."
|
||||
},
|
||||
"binarySourcing": {
|
||||
"heading": "Le binaire borg",
|
||||
"intro": "Borg n'est pas une dépendance de base de l'installateur ProxMenux. Lorsqu'une sauvegarde s'exécute, <code>hb_ensure_borg</code> résout le binaire à partir de quatre sources dans l'ordre et retourne le premier qui fonctionne :",
|
||||
"rows": [
|
||||
{
|
||||
"priority": "1",
|
||||
"source": "Système <code>borg</code>",
|
||||
"detail": "Si l'hôte a déjà <code>borg</code> installé via APT (<code>which borg</code> résout), ce binaire est utilisé."
|
||||
},
|
||||
{
|
||||
"priority": "2",
|
||||
"source": "Cache du répertoire d’état",
|
||||
"detail": "<code>/usr/local/share/proxmenux/borg</code> — conservé d'un téléchargement préalable de GitHub sur cet hôte."
|
||||
},
|
||||
{
|
||||
"priority": "3",
|
||||
"source": "Paquet AppImage du moniteur",
|
||||
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — le AppImage regroupe un borg-linux64 signé. C'est le chemin hors ligne sécurisé : un hôte sans internet a toujours un <code>borg</code> fonctionnant."
|
||||
},
|
||||
{
|
||||
"priority": "4",
|
||||
"source": "Téléchargement GitHub",
|
||||
"detail": "<code>wget</code> contre l'URL <code>borg-linux64</code> épinglée sous <code>github.com/borgbackup/borg/releases/</code>, vérifiée contre une constante SHA-256 dans <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). En cas de somme de contrôle incorrecte, le binaire est rejeté et la sauvegarde avorte. Le fichier téléchargé est mis en cache dans l'état dir afin que les sauvegardes suivantes utilisent le chemin 2."
|
||||
}
|
||||
]
|
||||
},
|
||||
"repoTypes": {
|
||||
"heading": "Types de dépôts",
|
||||
"intro": "Le type de dépôt est choisi lorsqu'une cible est ajoutée. Chaque type résout une URL de dépôt différente que Borg comprend.",
|
||||
"rows": [
|
||||
{
|
||||
"type": "remote",
|
||||
"url": "ssh://USER@HOST/RPATH",
|
||||
"detail": "Le dépôt vit sur un serveur distant qui exécute <code>borg serve</code>. Nécessite une connexion SSH à ce serveur."
|
||||
},
|
||||
{
|
||||
"type": "usb",
|
||||
"url": "/mnt/MOUNTPOINT/borgbackup",
|
||||
"detail": "Le dépôt vit sur un disque externe monté (habituellement USB). Le montage est résolu via <code>hb_prompt_mounted_path</code>, qui détecte, monte ou formate les partitions USB au besoin."
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "Le dépôt vit dans un répertoire local. Signifiant seulement lorsque le répertoire cible est sur un disque physique séparé — un dépôt sur le même disque que la source protège contre l'erreur de l'opérateur mais pas contre la défaillance du disque."
|
||||
}
|
||||
]
|
||||
},
|
||||
"serverSetup": {
|
||||
"heading": "Préparation du serveur Borg (côté serveur)",
|
||||
"intro": "Le type de dépôt <code>remote</code> nécessite un serveur Borg fonctionnel accessible via SSH. ProxMenux ne configure pas le serveur lui-même : il autorise seulement une clé sur un compte existant. Cette section décrit les prérequis du serveur.",
|
||||
"hostChoicesTitle": "Où le serveur peut vivre",
|
||||
"hostChoicesBody": "Tout hôte Linux avec accès SSH se qualifie. Configurations communes :",
|
||||
"hostChoicesItems": [
|
||||
"Un NAS dédié ou une boîte de sauvegarde (Debian, Ubuntu, TrueNAS SCALE avec un shell).",
|
||||
"Un conteneur LXC à l'intérieur d'un nœud Proxmox. Petite empreinte, isolée de l'hôte exécutant les sauvegardes.",
|
||||
"Un autre hôte Proxmox sur le même LAN, ou un VM n'importe où accessible sur SSH."
|
||||
],
|
||||
"lxcWarningTitle": "LXC comme serveur Borg",
|
||||
"lxcWarningBody": "Si le serveur Borg est dans un LXC, generate-auto nécessite un compte acceptant l’authentification SSH par mot de passe pour installer la clé. Sinon, utilisez l’installation manuelle ou l’alternative generate-pct via l’hôte PVE.",
|
||||
"requirementsTitle": "Exigences sur le serveur",
|
||||
"requirementsRows": [
|
||||
{
|
||||
"requirement": "Exécutable borg dans <code>/usr/bin/borg</code>",
|
||||
"detail": "La ligne <code>command=\"/usr/bin/borg serve ...\"</code> écrite par ProxMenux dans <code>authorized_keys</code> utilise ce chemin fixe. L’installation APT (<code>apt install borgbackup</code>) y place l’exécutable. Pour un binaire autonome, créez un lien symbolique à <code>/usr/bin/borg</code>."
|
||||
},
|
||||
{
|
||||
"requirement": "Un compte utilisateur dédié (généralement <code>borg</code>)",
|
||||
"detail": "Possède le répertoire du dépôt et reçoit les connexions SSH entrantes. N'a pas besoin d'accès sudo ou shell — la ligne authorized_keys désactive de toute façon les shells interactifs."
|
||||
},
|
||||
{
|
||||
"requirement": "Un répertoire de dépôt en écriture",
|
||||
"detail": "Le chemin que l'opérateur donne à ProxMenux (par exemple <code>/backup/borgbackup</code>) doit exister sur le serveur et être la propriété de l'utilisateur borg."
|
||||
},
|
||||
{
|
||||
"requirement": "SSH démon acceptant l'utilisateur borg",
|
||||
"detail": "<code>PubkeyAuthentication yes</code> (par défaut). L'authentification par mot de passe n'est nécessaire que pour le flux <em>generate-auto</em>, une fois la clé installée, le serveur peut désactiver complètement le mot de passe auth."
|
||||
}
|
||||
],
|
||||
"minimalSetupTitle": "Configuration minimale du serveur",
|
||||
"minimalSetupBody": "Sur un serveur Debian ou Ubuntu Borg, une référence de travail est quatre commandes comme root:",
|
||||
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
|
||||
"minimalSetupNote": "Une fois le serveur préparé et l’authentification SSH par mot de passe disponible, <code>generate-auto</code> installe la clé via un compte pouvant écrire dans authorized_keys de l’utilisateur borg. Les sauvegardes suivantes utilisent cette clé, limitée à <code>borg serve</code> au chemin configuré. Sans connexion par mot de passe, installez-la manuellement ou via l’hôte PVE."
|
||||
},
|
||||
"sshAuth": {
|
||||
"heading": "authentification SSH (côté client)",
|
||||
"intro": "Les dépôts distants Borg sont accessibles sur SSH. La connexion passe de l'hôte ProxMenux à un compte utilisateur sur le serveur Borg qui exécute <code>borg serve</code>. Cet utilisateur s'appelle généralement <code>borg</code>, PAS l'utilisateur admin/root du serveur — la ligne de commande borg-serve verrouille la connexion à ce chemin de dépôt spécifique (voir les stratégies clés ci-dessous).",
|
||||
"strategiesTitle": "Stratégies de clé SSH",
|
||||
"strategiesIntro": "Lors de l’ajout d’une destination distante, ProxMenux demande l’utilisateur SSH, l’hôte, le port et le chemin distant, puis propose quatre choix d’authentification. L’alternative generate-pct est proposée si l’authentification par mot de passe est refusée. Voici les modes :",
|
||||
"strategyRows": [
|
||||
{
|
||||
"mode": "generate-auto",
|
||||
"label": "Recommandé",
|
||||
"detail": "ProxMenux crée ou réutilise une paire de clés ed25519 dans <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, puis utilise <code>sshpass</code> pour tester la connexion et installer la clé publique dans <code>~borg/.ssh/authorized_keys</code>. Le mot de passe est celui d’un compte autorisé à écrire ce fichier, généralement root ou borg. Il sert pendant la configuration et n’est pas enregistré."
|
||||
},
|
||||
{
|
||||
"mode": "generate-manual",
|
||||
"label": "Pas de mot de passe admin sur cet hôte",
|
||||
"detail": "ProxMenux génère la paire de clés comme ci-dessus, mais affiche la ligne complète <code>authorized_keys</code> pour que l'opérateur colle manuellement dans le serveur. Le mot de passe administrateur ne quitte jamais l'hôte ProxMenux car il n'est jamais demandé."
|
||||
},
|
||||
{
|
||||
"mode": "generate-pct",
|
||||
"label": "Le serveur Borg est un PVE LXC",
|
||||
"detail": "Le serveur Borg fonctionne à l'intérieur d'un LXC sur un nœud PVE. ProxMenux autorise la clé via <code>pct exec</code> de l'hôte PVE — root sur l'hôte PVE écrit dans le LXC de <code>~borg/.ssh/authorized_keys</code> sans avoir besoin de SSH dans le LXC lui-même."
|
||||
},
|
||||
{
|
||||
"mode": "existing",
|
||||
"label": "Utiliser une clé existante",
|
||||
"detail": "ProxMenux recherche dans <code>/root/.ssh/</code> et <code>$HOME/.ssh/</code> les clés privées ed25519/RSA qu’il peut lire, puis les liste. L’opérateur en choisit une ou indique manuellement un chemin non standard."
|
||||
},
|
||||
{
|
||||
"mode": "none",
|
||||
"label": "Config par défaut SSH",
|
||||
"detail": "Aucune clé personnalisée — Borg s'appuie sur la configuration par défaut de l'hôte SSH (généralement <code>~/.ssh/id_rsa</code> ou un agent SSH)."
|
||||
}
|
||||
],
|
||||
"restrictTitle": "La ligne authorized_keys",
|
||||
"restrictBody": "Pour chaque clé générée, la ligne <code>authorized_keys</code> écrite par ProxMenux sur le serveur limite la clé à cet appel borg-serve sur le chemin configuré du dépôt :",
|
||||
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
|
||||
"restrictNote": "Le <code>command=</code> force chaque session SSH en utilisant cette clé pour exécuter seulement la commande borg-serve; <code>restrict</code> désactive le renvoi de port, le renvoi d'agent, le renvoi de X11 et l'allocation de PTY. La clé ne peut pas être utilisée pour ouvrir un shell interactif sur le serveur ou pour accéder à tout autre chemin de dépôt, même si le compte a des privilèges plus larges."
|
||||
},
|
||||
"savedTargets": {
|
||||
"heading": "Objectifs enregistrés",
|
||||
"intro": "Une destination enregistrée conserve la configuration du dépôt sous un nom lisible pour éviter de ressaisir les détails. Fichiers dans le répertoire d’état ProxMenux :",
|
||||
"rows": [
|
||||
{
|
||||
"file": "borg-targets.txt",
|
||||
"content": "Une ligne par destination : <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> la lit pour remplir le menu de sélection des destinations."
|
||||
},
|
||||
{
|
||||
"file": "borg-pass-NAME.txt",
|
||||
"content": "Phrase secrète de la destination nommée NAME ci-dessus (<code>chmod 600</code>). Présente uniquement si le chiffrement repokey a été choisi."
|
||||
}
|
||||
],
|
||||
"outro": "Enregistrer la destination est facultatif. Refuser omet la configuration nommée, mais ne supprime pas une clé SSH générée. Si le chiffrement repokey est activé sans destination enregistrée, ProxMenux conserve tout de même la phrase secrète dans l’ancien fichier borg-pass.txt."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Cryptage",
|
||||
"body": "Les dépôts sont initialisés avec un mode de chiffrement via <code>hb_borg_init_if_needed</code>: le <code>borg repo-create -e MODE</code> moderne quand disponible, ou le <code>borg init --encryption=MODE</code> hérité. ProxMenux expose deux modes : <code>repokey</code> (par défaut) et <code>none</code>. En mode <code>repokey</code> Borg stocke la clé de cryptage à l'intérieur du dépôt lui-même ; l'accès nécessite une phrase de passe, que ProxMenux invite pour deux fois avec vérification de concordance et enregistre dans <code>borg-pass-NAME.txt</code> pour une destination enregistrée, sinon dans l’ancien fichier décrit plus haut. Une boîte de dialogue de reconnaissance obligatoire s'affiche après l'enregistrement de la phrase de passe : la phrase de passe est la seule façon d'accéder aux archives chiffrées, et la perdre rend chaque archive du dépôt inrécupérable."
|
||||
},
|
||||
"runtimeEnv": {
|
||||
"heading": "Environnement d'exécution",
|
||||
"intro": "ProxMenux exporte les variables d'environnement suivantes avant d'invoquer <code>borg</code>. Ils configurent la connexion et déverrouillent le dépôt sans intégrer de secrets dans la ligne de commande.",
|
||||
"rows": [
|
||||
{
|
||||
"var": "BORG_RSH",
|
||||
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
|
||||
"purpose": "Commande distante utilisée par Borg pour les dépôts SSH. Une clé sélectionnée ajoute les options d’identité. Quand une destination est ajoutée avec un port non standard, ProxMenux ajoute aussi -p PORT ; les destinations enregistrées, les tâches planifiées et le Monitor utilisent plutôt le port de l’URL ssh://. Sans clé personnalisée, et pour une nouvelle destination avec le port par défaut, la variable reste non définie et Borg utilise la configuration SSH de l’hôte."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
"value": "(Passphrase de borg-pass-NAME.txt)",
|
||||
"purpose": "Débloque le repokey. Définir uniquement lorsque la cible utilise le chiffrement <code>repokey</code>. N'apparaît jamais dans la liste des arguments du processus."
|
||||
},
|
||||
{
|
||||
"var": "BORG_ENCRYPT_MODE",
|
||||
"value": "repokey | none",
|
||||
"purpose": "Utilisé par <code>hb_borg_init_if_needed</code> lors de l'initialisation d'un dépôt qui n'existe pas encore. Ignoré par <code>borg create</code> sur les dépôts existants."
|
||||
},
|
||||
{
|
||||
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Supprime la confirmation interactive demandée par Borg lorsque l’URL du dépôt diffère de celle utilisée initialement, par exemple après avoir renommé un point de montage ou changé l’adresse du serveur SSH."
|
||||
},
|
||||
{
|
||||
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Supprime l'invite interactive Borg soulève la première fois qu'un dépôt non chiffré est accessible depuis un nouveau client."
|
||||
}
|
||||
]
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Nom et conservation des archives",
|
||||
"intro": "Chaque sauvegarde crée une nouvelle archive dans le dépôt.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
|
||||
"retentionBody": "Pour les tâches programmées, <code>run_scheduled_backup.sh</code> exécute <code>borg prune</code> contre le dépôt après chaque sauvegarde réussie avec les valeurs de conservation configurées sur le travail (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Les sauvegardes interactives ne se prunent pas."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Récupération du côté restauration",
|
||||
"body": "Le flux de restauration liste les archives avec <code>borg list REPO</code> et extrait celui sélectionné avec <code>borg extract REPO::ARCHIVE-NAME</code> dans un répertoire de mise en scène que <code>_rs_check_layout</code> alimente dans le pipeline de restauration standard. Pour la récupération manuelle à l'extérieur de ProxMenux les mêmes commandes fonctionnent; l'arborescence extraite est la mise en page standard à trois payload décrite dans <em>Comment ça marche</em>."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Références",
|
||||
"intro": "Documentation officielle de Borg pour les composants utilisés par ProxMenux.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Documentation borg",
|
||||
"href": "https://borgbackup.readthedocs.io/",
|
||||
"tail": "— point d'entrée principal couvrant les concepts, le déploiement, le démarrage rapide et chaque commande."
|
||||
},
|
||||
{
|
||||
"label": "borg create",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
|
||||
"tail": " — la commande utilisée par ProxMenux pour chaque sauvegarde, avec toutes les options prises en charge."
|
||||
},
|
||||
{
|
||||
"label": "Chiffrement des dépôts",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
|
||||
"tail": "— les modes de cryptage pris en charge par Borg, y compris la repokey que ProxMenux utilise par défaut."
|
||||
},
|
||||
{
|
||||
"label": "borg serve et déploiement via SSH",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
|
||||
"tail": " — configuration d’un serveur Borg central accessible via SSH, avec la commande borg-serve et l’option restrict-to-path inscrites par ProxMenux dans authorized_keys."
|
||||
},
|
||||
{
|
||||
"label": "borg prune",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
|
||||
"tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly appliqué par ProxMenux à chaque tâche planifiée."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destinations des sauvegardes — archive locale, Proxmox Backup Server et Borg | ProxMenux",
|
||||
"description": "Trois moteurs de stockage reçoivent la même charge utile de sauvegarde ProxMenux : une archive locale .tar.zst sur tout système de fichiers accessible en écriture, une sauvegarde PBS dans un datastore Proxmox Backup Server ou une archive Borg dans un dépôt Borg local ou distant. Chaque moteur a ses propres caractéristiques de compression, de déduplication, de chiffrement et de réseau.",
|
||||
"ogTitle": "Destinations de sauvegarde ProxMenux",
|
||||
"ogDescription": "Local, Proxmox Backup Server et Borg — trois moteurs de stockage pour la même charge utile de sauvegarde d'hôte.",
|
||||
"twitterTitle": "Destinations de sauvegarde ProxMenux | ProxMenux",
|
||||
"twitterDescription": "Archives locales, moteurs Proxmox Backup Server et Borg pour les sauvegardes d'hôte."
|
||||
},
|
||||
"header": {
|
||||
"title": "Destinations",
|
||||
"description": "Trois backends de stockage pris en charge par ProxMenux Backup: archive locale, Proxmox Backup Server (recommandé) et Borg. Chacun reçoit la même archive à trois charges; ils diffèrent en format de stockage, déduplication, modèle de chiffrement et exigences du réseau.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Même charge utile, trois moteurs",
|
||||
"body": "Chaque sauvegarde produit les mêmes trois charges utiles (rootfs, manifeste, applications). Ce qui change entre les destinations, c'est comment ces charges sont stockées et comment l'opérateur les récupère pour une restauration. Chaque moteur est implémenté comme une fonction séparée dans <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — mais les trois partagent la même étape de préparation temporaire (<code>hb_prepare_staging</code>) et le même chemin de code de restauration. Le choix de la destination n'affecte que l'écriture et la récupération ; il ne change pas ce qu'une restauration fait ou comment elle consomme l'archive."
|
||||
},
|
||||
"comparison": {
|
||||
"heading": "Comparaison des caractéristiques",
|
||||
"intro": "Le tableau suivant répertorie les différences concrètes entre les trois backends tels qu'ils se comportent dans ProxMenux aujourd'hui. Toutes les valeurs décrivent le comportement observé du backend lui-même, et non des recommandations éditoriales.",
|
||||
"rows": [
|
||||
{
|
||||
"feature": "Format de stockage",
|
||||
"local": "Un seul fichier <code>.tar.zst</code> (ou <code>.tar.gz</code> si <code>zstd</code> est absent).",
|
||||
"pbs": "Sauvegarde PBS (blocs <code>.pxar</code> dans le datastore).",
|
||||
"borg": "Archive Borg à l'intérieur d'un dépôt Borg (fichiers de segments)."
|
||||
},
|
||||
{
|
||||
"feature": "Compression",
|
||||
"local": "zstd (niveau par défaut) via <code>tar --zstd</code>. Repli sur gzip.",
|
||||
"pbs": "Gérée par proxmox-backup-client. ProxMenux ne modifie pas les paramètres de compression.",
|
||||
"borg": "Compression intégrée à Borg. ProxMenux appelle borg create sans modifier les paramètres de compression."
|
||||
},
|
||||
{
|
||||
"feature": "Déduplication",
|
||||
"local": "Aucune. Chaque sauvegarde est une archive indépendante complète.",
|
||||
"pbs": "Déduplication complète de niveau chunk sur toutes les sauvegardes dans le datastore.",
|
||||
"borg": "Déduplication complète au niveau des blocs entre toutes les archives du dépôt."
|
||||
},
|
||||
{
|
||||
"feature": "Chiffrement au repos",
|
||||
"local": "Aucun (dépend de la protection au niveau du système de fichiers).",
|
||||
"pbs": "Chiffrement facultatif côté client avec un fichier de clé. Si activé, le blob de récupération est envoyé dans un groupe de sauvegarde distinct.",
|
||||
"borg": "Chiffrement facultatif des repokey (clé stockée dans la repo, déverrouillée par une phrase de passe)."
|
||||
},
|
||||
{
|
||||
"feature": "Rétention / purge",
|
||||
"local": "Appliquée par tâche programmée via <code>KEEP_LAST</code>. Les anciennes archives sont supprimées avec leurs fichiers annexes et journaux d’exécution. Les sauvegardes interactives ne font pas de purge.",
|
||||
"pbs": "Appliquée par tâche programmée via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge.",
|
||||
"borg": "Appliquée par tâche programmée via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Les sauvegardes interactives ne font pas de purge."
|
||||
},
|
||||
{
|
||||
"feature": "Réseau",
|
||||
"local": "Aucune. Écrit à un point de montage local (généralement un disque interne ou un lecteur USB).",
|
||||
"pbs": "TCP vers le serveur PBS (port par défaut 8007). Nécessite des identifiants PBS + empreinte du certificat.",
|
||||
"borg": "Chemin du système de fichiers local ou tunnel SSH vers un hôte Borg distant."
|
||||
},
|
||||
{
|
||||
"feature": "Dépendances",
|
||||
"local": "<code>tar</code>, <code>zstd</code> (présent sur Proxmox par défaut).",
|
||||
"pbs": "Paquet <code>proxmox-backup-client</code> (fourni avec Proxmox VE 8+).",
|
||||
"borg": "<code>borg</code> binaire. Auto-provisionné par ProxMenux à partir du paquet Moniteur AppImage quand il manque."
|
||||
},
|
||||
{
|
||||
"feature": "Accès pour restaurer",
|
||||
"local": "Tout hôte avec tar+zstd peut extraire l'archive. Pas de PBS/Borg nécessaire.",
|
||||
"pbs": "Nécessite <code>proxmox-backup-client</code>, les identifiants PBS et le fichier de clé (si la sauvegarde est chiffrée).",
|
||||
"borg": "Nécessite <code>borg</code> + le chemin du dépôt + la phrase de passe (si chiffrée)."
|
||||
}
|
||||
],
|
||||
"captionCode": "feature",
|
||||
"captionLocal": "Locale",
|
||||
"captionPbs": "Proxmox Backup Server (recommandé)",
|
||||
"captionBorg": "Borg"
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "La disposition des archives ne change pas avec la destination",
|
||||
"body": "A l'intérieur de l'une des trois destinations, la même disposition <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> décrite dans <em>Comment ça marche</em> est présente. Un <code>.tar.zst</code> extrait d'une archive locale, un <code>.pxar</code> restauré de PBS et une archive Borg extraite de <code>borg extract</code> donnent tous un arbre de répertoire identique. Le chemin du code de restauration (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extraire une sauvegarde à l'extérieur de ProxMenux",
|
||||
"intro": "N'importe lequel des trois formats d'archive peut être lu avec des outils standard sans ProxMenux installé sur l'hôte de lecture. Les commandes ci-dessous produisent le même arbre de répertoire qu'une restauration consomme en interne.",
|
||||
"localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
|
||||
"pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n --repository USER@REALM@HOST:DATASTORE \\\n host/hostcfg-HOST/BACKUP-TIME \\\n hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
|
||||
"borgCmd": "# Depuis une archive Borg (nécessite borg et la phrase de passe des dépôts chiffrés) :\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Sur un dépôt distant accessible par SSH :\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
|
||||
"note": "L'arbre extrait peut ensuite être inspecté manuellement ou alimenté à une restauration manuelle. Consultez les pages de destination individuelles pour connaître le processus de récupération exact que ProxMenux utilise sous le capot."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Détails par destination",
|
||||
"intro": "Chaque destination a sa propre page couvrant le flux de configuration, le format sur disque et la commande de récupération utilisée par la restauration.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Archives locales",
|
||||
"href": "/docs/backup-restore/destinations/local",
|
||||
"tail": "— pré-configuration d'une cible locale, montage d'un lecteur USB, vérification de sécurité contre l'écriture de l'archive en soi, le sidecar JSON qui permet au moniteur d'identifier le fichier."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox Backup Server (recommandé)",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": " — choix du datastore, identifiants et empreinte du certificat, cycle de vie du fichier de clé, phrase de passe de récupération et envoi du blob de récupération à PBS pour restaurer après une nouvelle installation."
|
||||
},
|
||||
{
|
||||
"label": "Borg",
|
||||
"href": "/docs/backup-restore/destinations/borg",
|
||||
"tail": " — dépôts locaux ou accessibles par SSH, provenance du binaire Borg (système / cache / paquet AppImage de Monitor / téléchargement GitHub), initialisation du dépôt, gestion des phrases de passe et configuration des clés SSH pour les dépôts distants."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,75 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Destination d'archive locale — tar.zst sur un système de fichiers ou un lecteur USB ProxMenux",
|
||||
"description": "La destination de sauvegarde locale écrit une seule archive .tar.zst dans n'importe quel répertoire accessible en écriture : un disque interne, un point de montage Proxmox, un partage NFS ou un lecteur USB. Cette page décrit le processus de configuration, la détection USB et la logique de montage, le contrôle de sécurité contre l'écriture de l'archive dans un chemin en cours de sauvegarde, et le sidecar JSON qui identifie le fichier.",
|
||||
"ogTitle": "Sauvegarde ProxMenux — Destination des archives locales",
|
||||
"ogDescription": "Comment ProxMenux écrit des sauvegardes locales comme archives .tar.zst et comment configurer le répertoire de destination ou le lecteur USB.",
|
||||
"twitterTitle": "Destination de sauvegarde locale ProxMenux",
|
||||
"twitterDescription": "Comment ProxMenux écrit des sauvegardes locales comme des archives .tar.zst sur un système de fichiers ou un lecteur USB."
|
||||
},
|
||||
"header": {
|
||||
"title": "Archives locales",
|
||||
"description": "La destination locale écrit une seule archive tar compressée dans n'importe quel répertoire accessible en écriture sur l'hôte : un disque interne, un montage NFS ou SMB ou un lecteur USB.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un fichier autonome",
|
||||
"body": "Une sauvegarde locale produit un seul fichier <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (ou <code>.tar.gz</code> lorsque <code>zstd</code> est absent). Le fichier contient l'arborescence entière de l'archive — <code>manifest.json</code>, <code>metadata/</code> et <code>rootfs/</code> — et peut être restauré sur n'importe quel hôte Proxmox avec le flux de restauration ProxMenux ou extrait manuellement avec <code>tar --zstd -xf</code> sur n'importe quel système Linux. Pas de serveur, pas d’initialisation de dépôt, pas de dépendance externe. C'est la destination avec le chemin de récupération le plus court lorsque ni PBS ni Borg n'est disponible."
|
||||
},
|
||||
"targetConfig": {
|
||||
"heading": "Configuration du répertoire cible",
|
||||
"intro": "La destination locale est un <strong>unique répertoire cible enregistré durablement</strong> — pas une liste. ProxMenux stocke le choix de l'opérateur chez <code>/usr/local/share/proxmenux/local-target.conf</code> et le lit sur chaque sauvegarde. Lorsqu'aucune cible n'a été configurée, le <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> par défaut est utilisé (le même répertoire que Proxmox utilise pour ses propres sorties <code>vzdump</code>). La cible est configurée à partir de <em>Configurer les destinations de sauvegarde → Destinations locales</em>:",
|
||||
"options": [
|
||||
"<strong>Utilisez par défaut (<code>/var/lib/vz/dump</code>).</strong> Le stockage local Proxmox. Présent sur chaque install Proxmox ; l'archive se trouve à côté des sorties vzdump et est captée automatiquement par l'onglet Sauvegardes du moniteur.",
|
||||
"<strong>Entrez un chemin personnalisé.</strong> Tout chemin absolu du système de fichiers peut être utilisé : un montage NFS, un partage SMB monté via <code>fstab</code>, un jeu de données ZFS dédié, un deuxième disque interne. ProxMenux valide que le chemin existe et est un répertoire avant de l’enregistrer.",
|
||||
"<strong>Choisissez un lecteur USB.</strong> Ouvre le sous-menu USB (ci-dessous), qui détecte les appareils amovibles et propose de monter ou de formater un périphérique."
|
||||
]
|
||||
},
|
||||
"usbFlow": {
|
||||
"heading": "Détection et montage du lecteur USB",
|
||||
"intro": "Le sous-menu USB énumère les partitions sur les périphériques amovibles signalées par <code>lsblk</code>. Chaque partition est présentée avec sa taille, l'étiquette du système de fichiers et l'état actuel. L'état détermine l'action ProxMenux offre.",
|
||||
"statesTitle": "Les trois états de l'appareil",
|
||||
"stateRows": [
|
||||
{
|
||||
"state": "monté",
|
||||
"shown": "Taille · étiquette · [fstype] · → /mount/point",
|
||||
"action": "La partition est déjà montée quelque part. La sélection enregistre le point de montage actuel en tant que cible locale. Aucun montage n'est effectué."
|
||||
},
|
||||
{
|
||||
"state": "non monté",
|
||||
"shown": "Taille · étiquette · [fstype] · (non monté — sera monté)",
|
||||
"action": "Un système de fichiers est présent mais n'est pas monté. Lors de la confirmation, ProxMenux exécute <code>hb_mount_usb_partition</code> : crée <code>/mnt/backup-LABEL</code> (ou un chemin basé sur UUID s'il n'y a pas d'étiquette), monte la partition et persiste le point de montage comme cible locale."
|
||||
},
|
||||
{
|
||||
"state": "vide",
|
||||
"shown": "Taille · disque USB brut — aucun système de fichiers (sera FORMATÉ)",
|
||||
"action": "Le périphérique n’a pas de système de fichiers. Cette opération destructive est protégée par deux confirmations. Une boîte de dialogue Oui/Non avertit d’abord que le disque sera effacé. Ensuite, un champ exige de <strong>saisir le chemin exact du périphérique</strong> (par exemple <code>/dev/sdb</code>) avant que ProxMenux crée une nouvelle table GPT avec une partition ext4 et la monte."
|
||||
}
|
||||
],
|
||||
"notMountedFallback": "Lorsqu'aucun périphérique USB n'est détecté, le sous-menu revient à une boîte d'entrée simple. L'opérateur peut entrer un chemin de point de montage arbitraire ; si le chemin n'est pas un point de montage enregistré, une boîte de dialogue de confirmation avertit avant de procéder."
|
||||
},
|
||||
"safetyCheck": {
|
||||
"heading": "Contrôle de sécurité — destination dans un chemin de sauvegarde",
|
||||
"body": "Avant d'écrire l'archive, <code>_bk_local</code> vérifie que le répertoire de destination n'est <strong>pas</strong> un sous-chemin d'un répertoire en cours de sauvegarde. Une erreur courante consisterait à ajouter <code>/root</code> au profil et à choisir <code>/root/backups</code> comme destination — l'archive s'inclurait alors elle-même, produisant soit une archive corrompue, soit s'agrandissant sans limite jusqu'à ce que le disque se remplisse. La vérification résout les deux chemins avec <code>readlink -m</code>, les compare et, en cas de conflit, abandonne la sauvegarde avec une boîte de dialogue qui nomme le chemin en conflit et répertorie trois façons de le résoudre : choisissez une destination en dehors du chemin en conflit, supprimez l'entrée personnalisée qui contient la destination ou utilisez le mode personnalisé pour décocher le chemin en conflit pour cette exécution."
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Format d'archives et compression",
|
||||
"intro": "Le nom du fichier contient le nom d’hôte source et l’horodatage de la sauvegarde, afin de permettre un tri chronologique dans un répertoire contenant plusieurs archives et d’identifier chaque fichier.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
|
||||
"compressionTitle": "Compression",
|
||||
"compressionBody": "Le chemin primaire utilise <code>tar --zstd -cf</code> — un pipeline à commande unique qui compresse au niveau par défaut de zstd. Lorsque <code>zstd</code> n'est pas présent sur la source (rare sur Proxmox mais possible sur des installations minimales), ProxMenux revient à <code>gzip</code>. Dans le chemin de repli, si <code>pv</code> est disponible, une barre de progression est ajoutée au pipeline afin que l'opérateur voit la taille des archives croître en temps réel; sans <code>pv</code>, <code>tar -czf</code> est utilisé en silence.",
|
||||
"sourceTitle": "Ce qui va dans l'archive",
|
||||
"sourceBody": "La commande tar est appelée avec <code>-C \"$staging_root\" .</code>, ce qui archive <strong>toute la racine du répertoire temporaire</strong> : <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code>. Les trois blocs de données se trouvent côte à côte à la racine de l’archive tar. L’extraction produit exactement l’arborescence utilisée par le code de restauration."
|
||||
},
|
||||
"sidecar": {
|
||||
"heading": "Le sidecar JSON",
|
||||
"intro": "Chaque sauvegarde locale réussie produit un fichier compagnon : <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, écrit à côté de l'archive par <code>hb_write_archive_sidecar</code>. Ce petit fichier JSON permet au ProxMenux Monitor d'identifier l'archive comme une sauvegarde d'hôte ProxMenux même s'il est déplacé, rebaptisé ou archivé ailleurs.",
|
||||
"contentTitle": "Contenu du sidecar",
|
||||
"contentBody": "Le sidecar stocke la version du schéma, que la sauvegarde soit issue d'une opération interactive ou d'un travail programmé (<code>kind</code>), l'ID de travail pour les opérations programmées, le mode de profil utilisé (<code>default</code> ou <code>custom</code>), le nom d'hôte source, le nom de base d'archive original, un horodatage de création ISO-8601 et la taille des archives en octets.",
|
||||
"whyBody": "L'onglet Sauvegardes du moniteur scanne les répertoires locaux configurés pour les sidecars <code>*.proxmenux.json</code> — pas pour les fichiers <code>*.tar.zst</code> — parce qu'un <code>.tar.zst</code> sans sidecar pourrait ne pas être une sauvegarde ProxMenux du tout. Le scan est rapide (les fichiers JSON sont minuscules) et l'appariement est stable à travers les renoms de l'archive aussi longtemps que le sidecar est renommé pour correspondre."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Restauration à partir d'une archive locale",
|
||||
"body": "Le flux de restauration ProxMenux découvre les archives locales en scannant la cible locale configurée pour les sidecars et en les affichant dans la liste des archives. La sélection d’une archive déclenche <code>_rs_check_layout</code>, qui extrait le tarball dans un répertoire de préparation temporaire et confirme la mise en page à trois payload avant de procéder. Pour l'extraction manuelle à l'extérieur de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> donne le même arbre que le code de restauration consommé."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Backup Server destination — dépôt, chiffrement, récupération ProxMenux",
|
||||
"description": "La destination PBS enregistre les sauvegardes d’hôte ProxMenux au format PBS. Cette page décrit la détection des dépôts dans /etc/pve/storage.cfg, la configuration manuelle, l’envoi des archives .pxar, le chiffrement côté client avec un fichier clé et sa copie de secours facultative protégée par une phrase secrète, ainsi que sa récupération depuis plusieurs sources sur un hôte réinstallé.",
|
||||
"ogTitle": "ProxMenux Sauvegarde — Proxmox Backup Server destination",
|
||||
"ogDescription": "Comment ProxMenux écrit des sauvegardes d'hôte à Proxmox Backup Server avec le cryptage de fichier clé côté client et la récupération séquestre.",
|
||||
"twitterTitle": "PBS destination de sauvegarde ProxMenux",
|
||||
"twitterDescription": "Destination Proxmox Backup Server avec chiffrement par fichier clé et copie de récupération protégée par une phrase secrète."
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "La destination PBS envoie tout le répertoire de préparation sous forme d’une seule sauvegarde .pxar vers un datastore Proxmox Backup Server. Le chiffrement côté client avec un fichier clé est facultatif, tout comme l’envoi, à côté de chaque sauvegarde, d’une copie de récupération de la clé protégée par une phrase secrète.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"recommendedBadge": "Destination recommandée",
|
||||
"aboutPbs": {
|
||||
"heading": "Qu'est-ce que Proxmox Backup Server",
|
||||
"body": "Proxmox Backup Server (PBS) est le propre produit serveur de sauvegarde de Proxmox, développé et entretenu par la même équipe que les auteurs Proxmox VE. Il s'agit d'un serveur de sauvegarde dédié conçu pour recevoir des sauvegardes des hôtes Proxmox VE (VMs, LXCs et — via <code>proxmox-backup-client</code> — répertoires d'hôtes arbitraires) avec déduplication basée sur le chunk, chiffrement côté client et politiques de rétention appliquées côté serveur. ProxMenux utilise le PBS comme l'une des trois destinations pour les sauvegardes d'hôtes; chaque mécanisme spécifique au PBS décrit sur cette page (groupes de sauvegarde, archives <code>.pxar</code>, <code>--backup-id</code>, cryptage de fichiers clés) est le comportement standard du PBS."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Une sauvegarde par exécution, déduplication par blocs",
|
||||
"body": "Une sauvegarde PBS crée une seule entrée dans le datastore, sous l’identifiant <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Les données sont une archive <code>.pxar</code> contenant la même structure en trois blocs que celle décrite dans <em>Fonctionnement</em>. PBS déduplique les blocs entre toutes les sauvegardes du datastore : les suivantes ne transfèrent et ne stockent que les blocs modifiés de cet hôte. Pour les tâches planifiées, ProxMenux applique lui-même la rétention : après chaque exécution réussie, <code>run_scheduled_backup.sh</code> lance <code>proxmox-backup-client prune</code> avec <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> et les valeurs configurées pour la tâche."
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Sélection du dépôt",
|
||||
"intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> et <code>HB_PBS_FINGERPRINT</code> pour l'exécution.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg de Proxmox (détection automatique)",
|
||||
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
|
||||
"content": "Toute stanza <code>pbs:</code> dans la configuration de stockage propre de Proxmox est captée automatiquement. Serveur, datastore, nom d'utilisateur et empreinte digitale viennent de la stanza. Le mot de passe est lu dans le propre répertoire d'identification de Proxmox. Aucune réentrée nécessaire du côté ProxMenux — le dépôt est disponible dès qu'il est configuré dans Proxmox."
|
||||
},
|
||||
{
|
||||
"source": "Configuration manuelle ProxMenux",
|
||||
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
|
||||
"content": "Ajouté de <em>Configurer les destinations de sauvegarde → PBS destinations → Ajouter PBS</em>. Prompts pour un nom, nom d'utilisateur (<code>root@pam</code> ou <code>user@pbs!token</code>), hôte ou IP, datastore et mot de passe. Le mot de passe reprend sur l'entrée vide — une sauvegarde vide persisterait silencieusement et chaque sauvegarde ultérieure échouerait avec une erreur d'authentification opaque. Ce chemin est utilisé lorsque la cible PBS n'est pas enregistrée comme stockage Proxmox."
|
||||
}
|
||||
],
|
||||
"menuTitle": "Menu de sélection",
|
||||
"menuBody": "Les deux sources sont affichées dans un menu unique, chaque ligne marquée avec son origine (<code>[proxmox]</code> ou <code>[manual]</code>). Les entrées dont le mot de passe n'a pas pu être résolu sont marquées d'un avertissement <code>⚠ no password</code> – la sélection d'une entrée déclenche une réentrée de mot de passe avant le début de la sauvegarde. L'empreinte digitale est transmise à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>; en cas d'absence, le client demande à l'opérateur d'accepter le certificat serveur de manière interactive lors de la première sauvegarde."
|
||||
},
|
||||
"backupCommand": {
|
||||
"heading": "La commande de sauvegarde",
|
||||
"intro": "L’envoi se fait en un seul appel à <code>proxmox-backup-client backup</code>. ProxMenux utilise <code>env</code> pour transmettre au client le mot de passe, le mot de passe de chiffrement et l’empreinte sous forme de variables d’environnement.",
|
||||
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
|
||||
"backupIdTitle": "Nom de l'ID de sauvegarde",
|
||||
"backupIdBody": "L’identifiant de sauvegarde par défaut est <code>hostcfg-HOSTNAME</code>. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de <code>[A-Za-z0-9_-]</code> et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un <em>groupe</em>. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
|
||||
"pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
|
||||
"pxarBody": "La source <code>.pxar</code> est la totalité du <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code> ensemble. Les versions antérieures ont passé le <code>$staging_root/rootfs</code> comme source; cela a laissé le <code>metadata/</code> hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-<code>_rs_check_layout</code> de 3, qui enveloppe un arbre plat <code>etc/var/root/usr</code> dans une hiérarchie <code>rootfs/</code>."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Chiffrement côté client",
|
||||
"glossaryHint": "Cette section emploie les termes <em>fichier clé</em>, <em>phrase secrète</em> et <em>enveloppe de récupération</em>. Le <glosarioLink>glossaire</glosarioLink> résume leurs différences en une phrase par terme.",
|
||||
"intro": "Le chiffrement PBS côté client avec un fichier clé chiffre les blocs sur l’hôte source avant leur envoi. Dans ProxMenux, il est facultatif. Une fois activé, l’opérateur choisit explicitement, par oui ou non lors de la configuration, s’il faut aussi déposer sur PBS une copie de récupération du fichier clé protégée par une phrase secrète ; ce choix reste modifiable dans le moniteur. Le fichier clé se trouve toujours au chemin canonique <code>/usr/local/share/proxmenux/pbs-key.conf</code> et est réutilisé sans nouvelle demande pour chaque sauvegarde chiffrée suivante.",
|
||||
"keyfileTitle": "Configuration du fichier de clés",
|
||||
"keyfileBody": "Le dialogue de chiffrement apparaît lors de la première sauvegarde chiffrée de l’hôte. Il demande d’abord s’il faut chiffrer la sauvegarde : <em>Non</em> poursuit sans chiffrement, <em>Oui</em> passe à la deuxième étape. Celle-ci dépend de la présence d’un fichier clé dans <code>/usr/local/share/proxmenux/pbs-key.conf</code>. S’il existe, il est réutilisé sans nouvelle demande et la sauvegarde continue ; les suivantes ne reposent pas la question. Sinon, un menu propose deux options. <em>Générer un nouveau fichier clé</em> exécute <code>proxmox-backup-client key create --kdf none</code>. <em>Utiliser un fichier clé existant</em> détecte automatiquement une clé gérée par PVE : si le dépôt PBS choisi est enregistré dans Proxmox avec une clé de chiffrement dans <code>/etc/pve/priv/storage/<NAME>.enc</code>, ce fichier est copié sans demande au chemin canonique ProxMenux. Si aucune clé PVE ne correspond au dépôt, le dialogue demande le chemin absolu où l’opérateur a déjà placé le fichier clé sur cet hôte. Dans les deux cas, le fichier est installé au chemin canonique avec <code>chmod 600</code>.",
|
||||
"modesTitle": "Fichier clé par hôte ou partagé",
|
||||
"modesIntro": "Les deux modes sont pris en charge, sans en imposer un : l’opérateur choisit selon l’organisation de son parc.",
|
||||
"modesPerHostTitle": "Fichier de clés par hôte (par défaut)",
|
||||
"modesPerHostBody": "Chaque hôte génère son propre fichier de clé la première fois qu'il permet le cryptage PBS. L'isolement est maximal : compromettre le fichier clé d'un hôte n'expose les sauvegardes d'aucun autre. Recommandé pour les flottes de production et pour les environnements où les hôtes ont différents propriétaires ou limites de conformité.",
|
||||
"modesSharedTitle": "Fichier de clés partagé (import sur chaque hôte)",
|
||||
"modesSharedBody": "Un fichier clé principal généré une fois et installé sur chaque hôte via l’option <em>Utiliser un fichier clé existant</em>. La gestion est plus simple: un seul secret à sauvegarder, et tout hôte peut déchiffrer les archives de n'importe quel autre (utile pour la consolidation, les exercices de restauration cross-host ou la vérification centralisée de sauvegarde). Le compromis est qu'une fuite du fichier de clés partagé expose chaque hôte à la fois. Recommandé pour les labos et les flottes où tous les hôtes ont le même propriétaire et la même limite de confiance.",
|
||||
"recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide",
|
||||
"recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, <em>Déposer la clé sur PBS ?</em>, avec deux réponses. <strong>Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui.</strong> Le choix par défaut est <em>Non, conserver uniquement en local</em> : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton <em>Télécharger le fichier clé</em> du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir <em>Oui, envoyer</em> demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant <code>pbs-key.recovery.enc</code>. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
|
||||
"blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
|
||||
"blobUploadBody1": "Lorsque le mode de dépôt est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
|
||||
"envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?",
|
||||
"envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.",
|
||||
"blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté",
|
||||
"blobUploadConstraintBody": "Un seul appel à <code>proxmox-backup-client backup</code> chiffre toutes ses archives avec le même fichier clé, ou aucune : il ne permet pas de mélanger les deux. La sauvegarde de l’hôte doit être chiffrée avec sa clé, mais l’enveloppe de récupération ne peut pas être envoyée dans le même appel : elle serait alors chiffrée avec le fichier clé qu’elle contient. Sur un hôte réinstallé, il serait impossible de l’ouvrir, puisqu’il faudrait la clé pour déchiffrer cette même clé. Les deux éléments sont donc envoyés indépendamment et apparaissent dans deux groupes. Le client PBS chiffre la sauvegarde de l’hôte avec le fichier clé ; ProxMenux chiffre l’enveloppe avec la phrase secrète avant son envoi. Deux couches de chiffrement distinctes protègent deux éléments différents.",
|
||||
"blobUploadImageAlt": "PBS UI montrant les groupes de sauvegarde hostcfg-HOSTNAME et hostcfg-HOSTNAME-keyrecovery adjacents à la liste datastore.",
|
||||
"blobUploadImageCaption": "PBS UI — les groupes de sauvegarde appariés. Le groupe principal détient les sauvegardes de l'hôte; le groupe -keyrecovery détient le fichier de clés enveloppé de la phrase de passe.",
|
||||
"recoverTitle": "Récupération sur un hôte frais",
|
||||
"recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans <code>/etc/pve/priv/storage/<NAME>.enc</code>, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe <code>-keyrecovery</code> existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie <code>wrong key — manifest's key XX does not match provided key YY</code>. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
|
||||
"monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
|
||||
"monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : <em>Télécharger</em> exporte le fichier actuel vers le navigateur ; <em>Envoyer</em> remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; <em>Supprimer</em> retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Récupération du côté restauration",
|
||||
"body": "La restauration repère les sauvegardes d’hôte ProxMenux sur PBS en listant les groupes du dépôt configuré puis en filtrant leur identifiant. L’onglet Sauvegardes du moniteur affiche la même liste. Choisir une sauvegarde lance <code>proxmox-backup-client restore</code> avec le même dépôt, mot de passe et empreinte, ainsi que <code>--keyfile</code> si elle est chiffrée. L’archive <code>.pxar</code> est extraite dans un répertoire de préparation que <code>_rs_check_layout</code> transmet au processus de restauration standard. Hors de ProxMenux, la même commande extrait l’archive à l’emplacement souhaité pour examiner l’arborescence ou effectuer une restauration manuelle."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Références",
|
||||
"intro": "Documentation officielle de Proxmox Backup Server pour les composants utilisés par ProxMenux.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Documentation Proxmox Backup Server",
|
||||
"href": "https://pbs.proxmox.com/docs/",
|
||||
"tail": "— point d'entrée principal couvrant l'installation, l'administration, le stockage, les utilisateurs et les rôles."
|
||||
},
|
||||
{
|
||||
"label": "proxmox-backup-client",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html",
|
||||
"tail": " — l’outil en ligne de commande appelé par ProxMenux pour chaque sauvegarde et restauration. Décrit les identifiants et types de sauvegarde, les archives, la syntaxe des dépôts et les variables d’environnement."
|
||||
},
|
||||
{
|
||||
"label": "Chiffrement côté client",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
|
||||
"tail": " — création du fichier clé, modes --kdf et modèle de chiffrement que ProxMenux complète par une copie de récupération protégée par une phrase secrète."
|
||||
},
|
||||
{
|
||||
"label": "Gestion des Datastore",
|
||||
"href": "https://pbs.proxmox.com/docs/storage.html",
|
||||
"tail": " — création et gestion des datastores qui reçoivent les sauvegardes d’hôte, avec la structure du stockage des blocs et les permissions."
|
||||
},
|
||||
{
|
||||
"label": "Élagage des sauvegardes et récupération d’espace",
|
||||
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
|
||||
"tail": " — le modèle de rétention de --keep-last / --keep-daily / --keep-weekly que ProxMenux applique par tâche planifiée, et la récupération des blocs inutilisés par PBS après l’élagage."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Glossaire — Sauvegarde et restauration ProxMenux",
|
||||
"description": "Glossaire des termes et définitions de la pile de sauvegarde et de restauration ProxMenux: chiffrement, fichier de clés, mots de passe, enveloppe de récupération, PBS, morceaux, rootfs, manifeste, hydratation coureur et cross-kernel.",
|
||||
"ogTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
|
||||
"ogDescription": "Définitions claires des termes utilisés dans la documentation de sauvegarde et de restauration ProxMenux.",
|
||||
"twitterTitle": "Glossaire de la sauvegarde et de la restauration | ProxMenux",
|
||||
"twitterDescription": "Phrase de passe, fichier clé, enveloppe de récupération, rootfs, manifeste, PBS, morceaux — tous définis en un seul endroit."
|
||||
},
|
||||
"header": {
|
||||
"title": "Glossaire",
|
||||
"description": "Termes utilisés dans la documentation de sauvegarde et de restauration, avec leur définition.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"body": "Les termes sont regroupés par thème. Chaque entrée donne le terme et une courte définition."
|
||||
},
|
||||
"groups": [
|
||||
{
|
||||
"title": "Chiffrement et récupération des clés",
|
||||
"intro": "Vocabulaire pour le bloc de chiffrement PBS. Il implique deux secrets distincts: un fichier de clés binaires et une phrase de passe écrite.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "passphrase-recuperacion",
|
||||
"term": "Phrase secrète de récupération",
|
||||
"def": "Mot de passe texte choisi par l'utilisateur pour protéger l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>. Il est demandé deux fois avec une vérification de correspondance, et n'est utilisé que pour chiffrer l'enveloppe et la déchiffrer si le fichier clé a besoin d'être récupéré. <strong>Ce n'est pas la phrase de passe qui déverrouille le fichier clé lui-même</strong>, et il n'est jamais envoyé à PBS. Pendant une sauvegarde normale, il ne quitte jamais l'hôte."
|
||||
},
|
||||
{
|
||||
"id": "clave-cifrado",
|
||||
"term": "Fichier-clé (clé de chiffrement)",
|
||||
"def": "Fichier de clé utilisé par proxmox-backup-client pour chiffrer les <a href=\"#chunk\">blocs</a> avant leur envoi à PBS. Sans la clé correspondante, les données chiffrées sont illisibles. ProxMenux le stocke dans <code>/usr/local/share/proxmenux/pbs-key.conf</code> avec le mode <code>600</code>. Protégez-le : l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> permet de le récupérer en cas de perte."
|
||||
},
|
||||
{
|
||||
"id": "contrasena-keyfile",
|
||||
"term": "Phrase de passe du fichier clé (phrase de passe KDF)",
|
||||
"def": "Phrase de passe optionnelle que le fichier clé lui-même peut porter, distincte de la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a>. Il n'existe que lorsque le fichier clé a été créé avec <code>--kdf scrypt</code> (généralement un fichier clé importé). Sans cela, le fichier clé ne peut pas être déverrouillé pour utilisation. ProxMenux le maintient sous forme chiffrée sur l'hôte afin que les sauvegardes programmées puissent fonctionner sans une demande interactive."
|
||||
},
|
||||
{
|
||||
"id": "sobre-recuperacion",
|
||||
"term": "Enveloppe de récupération",
|
||||
"def": "Le fichier <a href=\"#clave-cifrado\">keyfile</a> enveloppé dans une couche supplémentaire: il est crypté avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> utilisant <a href=\"#aes-256-cbc\">AES-256-CBC</a> et <a href=\"#pbkdf2\">PBKDF2</a> avant de quitter l'hôte. C'est ce qui est téléchargé sur PBS en tant que groupe <code>-keyrecovery</code>. Sans la phrase de passe, l'enveloppe est opaque : le téléchargement de PBS ne révèle pas le fichier de clés."
|
||||
},
|
||||
{
|
||||
"id": "cifrado-cliente",
|
||||
"term": "Chiffrement côté client",
|
||||
"def": "Modèle de chiffrement dans lequel les données sont chiffrées sur l'hôte source avant d'être téléchargées. PBS ne reçoit et stocke que du texte codé; même un administrateur PBS avec accès datastore ne peut pas le lire sans le fichier clé. ProxMenux s'appuie sur ce modèle et ajoute l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a> sur le dessus."
|
||||
},
|
||||
{
|
||||
"id": "kdf-none",
|
||||
"term": "--kdf none",
|
||||
"def": "Option de <code>proxmox-backup-client key create</code> qui produit un fichier de clés sans phrase de passe jointe. Le fichier de clés peut être utilisé directement sans une prompte, ce qui est essentiel pour les travaux programmés qui ne sont pas surveillés. C'est ce que ProxMenux utilise par défaut lors de la génération d'un nouveau fichier clé."
|
||||
},
|
||||
{
|
||||
"id": "kdf-scrypt",
|
||||
"term": "--kdf scrypt",
|
||||
"def": "Option pour <code>proxmox-backup-client key create</code> qui produit un fichier clé protégé par une <a href=\"#contrasena-keyfile\">phrase de passe du fichier de clé</a>. Chaque utilisation du fichier clé nécessite de le déverrouiller avec cette phrase de passe. ProxMenux accepte ce style de keyfile sur l'importation et stocke la phrase de passe cryptée afin que les sauvegardes programmées puissent toujours fonctionner sans surveillance."
|
||||
},
|
||||
{
|
||||
"id": "aes-256-cbc",
|
||||
"term": "AES-256-CBC",
|
||||
"def": "Chiffrement symétrique standard. ProxMenux l’utilise via <code>openssl enc -aes-256-cbc</code> pour protéger le <a href=\"#clave-cifrado\">fichier de clé</a> avec la <a href=\"#passphrase-recuperacion\">phrase de passe de récupération</a> et produire l’<a href=\"#sobre-recuperacion\">enveloppe</a>."
|
||||
},
|
||||
{
|
||||
"id": "pbkdf2",
|
||||
"term": "PBKDF2",
|
||||
"def": "Fonction cryptographique qui transforme une phrase de passe de type humain en une clé binaire adaptée au chiffrement. Il ralentit les tentatives de force brute en appliquant de nombreuses itérations. ProxMenux l'utilise avec des itérations 600 000 et un sel aléatoire lors du chiffrement de l'enveloppe de récupération."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Structure de sauvegarde",
|
||||
"intro": "Termes décrivant ce qui vit dans une sauvegarde, quelle que soit la destination.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "rootfs",
|
||||
"term": "rootfs / système de fichiers racine",
|
||||
"def": "Copie des fichiers de l’hôte source réalisée par <code>rsync</code> selon le <a href=\"#perfil-defecto\">profil par défaut</a> et les <a href=\"#rutas-personalizadas\">chemins personnalisés</a>. Ce n’est pas une image de disque complet : seuls sont copiés les chemins contenant la configuration ou l’état que Proxmox ne peut pas recréer seul."
|
||||
},
|
||||
{
|
||||
"id": "manifiesto",
|
||||
"term": "Manifeste (manifest.json)",
|
||||
"def": "Document structuré JSON décrivant l'hôte source au moment de la sauvegarde : matériel, stockage, noyau, composants installés par ProxMenux et inventaire des VM et des LXC. Il est produit par six collecteurs indépendants. Le flux de restauration l'utilise pour comparer la source et la cible."
|
||||
},
|
||||
{
|
||||
"id": "staging",
|
||||
"term": "Répertoire de préparation",
|
||||
"def": "Répertoire temporaire où ProxMenux assemble les trois blocs (rootfs, métadonnées et manifeste) avant de les emballer et de les télécharger vers la destination. Il est supprimé automatiquement lorsque la sauvegarde se termine, même sur avorter."
|
||||
},
|
||||
{
|
||||
"id": "perfil-defecto",
|
||||
"term": "Profil par défaut",
|
||||
"def": "Ensemble sélectionné de chemins copiés par défaut dans chaque sauvegarde : configuration PVE, réseau, SSH, noyau, apt, outils ProxMenux et plus encore. Défini dans le code et documenté sur la page <em>Comment ça marche</em>."
|
||||
},
|
||||
{
|
||||
"id": "rutas-personalizadas",
|
||||
"term": "Chemins personnalisés",
|
||||
"def": "Les chemins supplémentaires que l'utilisateur ajoute au dessus du <a href=\"#perfil-defecto\">profil par défaut</a>. Soit persistante (conservée en <code>backup-extra-paths.txt</code>) soit per-run (en mode personnalisé)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Destinations et stockage",
|
||||
"intro": "Termes liés à l'emplacement de la sauvegarde — serveur PBS, archive locale ou dépôt Borg — et comment PBS organise les données.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "repositorio-pbs",
|
||||
"term": "Dépôt PBS",
|
||||
"def": "Combinaison de Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + utilisateur qui reçoit la sauvegarde. Identifié par la chaîne <code>user@realm@host:datastore</code>. Un seul serveur PBS peut héberger plusieurs dépôts."
|
||||
},
|
||||
{
|
||||
"id": "datastore",
|
||||
"term": "Banque de données",
|
||||
"def": "Espace de stockage précis dans un serveur PBS contenant les sauvegardes et leurs blocs. Chaque datastore repose sur un système de fichiers du serveur PBS avec ses propres permissions et politiques."
|
||||
},
|
||||
{
|
||||
"id": "chunk",
|
||||
"term": "Bloc (chunk) / déduplication par blocs",
|
||||
"def": "PBS divise chaque sauvegarde en morceaux de taille variable, identifie chaque morceau par son hachage et ne stocke chaque morceau qu'une seule fois, même s'il apparaît dans de nombreuses sauvegardes différentes. Cela signifie que les sauvegardes successives d'un même hôte — ou d'un hôte similaire — prennent très peu d'espace supplémentaire."
|
||||
},
|
||||
{
|
||||
"id": "fingerprint",
|
||||
"term": "Empreinte",
|
||||
"def": "Empreinte cryptographique du certificat du serveur PBS TLS Il permet au client de vérifier qu'il parle au serveur prévu sans compter sur une autorité de certification publique. ProxMenux le transmet à <code>proxmox-backup-client</code> via la variable d'environnement <code>PBS_FINGERPRINT</code>."
|
||||
},
|
||||
{
|
||||
"id": "grupo-copia",
|
||||
"term": "Groupe de sauvegarde",
|
||||
"def": "Conteneur logique à l'intérieur de PBS sous lequel les sauvegardes successives du même actif s'accumulent. Chaque nouvelle sauvegarde partage la déduplication avec les précédentes dans le même groupe. ProxMenux utilise deux groupes par hôte lorsque le chiffrement est activé : un pour la sauvegarde de l'hôte et un avec un suffixe <code>-keyrecovery</code> pour l’<a href=\"#sobre-recuperacion\">enveloppe de récupération</a>."
|
||||
},
|
||||
{
|
||||
"id": "backup-id",
|
||||
"term": "ID de sauvegarde",
|
||||
"def": "Nom du groupe <a href=\"#grupo-copia\">backup</a>. ProxMenux par défaut sur <code>hostcfg-HOSTNAME</code> et permet à l'utilisateur de l'éditer avant le téléchargement; les caractères non pris en charge sont supprimés automatiquement."
|
||||
},
|
||||
{
|
||||
"id": "pxar",
|
||||
"term": ".pxar",
|
||||
"def": "Format d'archive native PBS pour les répertoires. Il se comporte comme un tar optimisé pour la déduplication des morceaux : au lieu de stocker un fichier opaque, PBS brise son contenu en morceaux réutilisables."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Exécution et calendrier",
|
||||
"intro": "Termes utilisés par le système ProxMenux emploi programmé.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "runner",
|
||||
"term": "Processus d'exécution",
|
||||
"def": "Le script <code>run_scheduled_backup.sh</code> qui exécute une sauvegarde programmée. Il lit la configuration du travail, lance le moteur correspondant (Local, PBS ou Borg), applique la conservation sur le succès et envoie les notifications configurées."
|
||||
},
|
||||
{
|
||||
"id": "trabajo-programado",
|
||||
"term": "Tâche planifiée",
|
||||
"def": "Configuration permanente d'une sauvegarde récurrente. Tient destination, identifiants, chiffrement, calendrier et conservation. Vit à <code>/var/lib/proxmenux/backup-jobs/<id>.env</code>."
|
||||
},
|
||||
{
|
||||
"id": "modo-adjunto",
|
||||
"term": "Mode rattaché",
|
||||
"def": "Tâche sans timer propre. Un hook job-end de PVE <code>vzdump</code> la déclenche après les sauvegardes des invités si le stockage correspond. La tâche parent fournit la destination et la conservation, relue depuis la tâche parent à chaque exécution, mais le hook compare le stockage, pas l’ID parent. Une autre tâche sur ce stockage peut aussi la déclencher. Uniquement Local et PBS."
|
||||
},
|
||||
{
|
||||
"id": "timer-systemd",
|
||||
"term": "Systemd minuterie",
|
||||
"def": "Mécanisme standard systemd qui déclenche une commande sur un calendrier. ProxMenux crée une minuterie par <em>indépendant</em> emploi programmé; <a href=\"#modo-adjunto\"> mode rattaché</a> emplois n'utilisent pas de minuterie, ils fonctionnent via le script PVE-hook."
|
||||
},
|
||||
{
|
||||
"id": "retencion",
|
||||
"term": "Conservation (keep-last, keep-daily…)",
|
||||
"def": "Politique qui décide quelles sauvegardes plus anciennes à conserver et à pruner. Défini par travail avec des paramètres comme <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Appliquée par le processus d’exécution après chaque sauvegarde réussie."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Restaurer",
|
||||
"intro": "Termes du flux de restauration.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "restauracion-universal",
|
||||
"term": "Restauration universelle",
|
||||
"def": "Le flux de restauration ProxMenux n'extrait pas seulement le système de fichiers : il lit le manifeste pour repérer les différences entre la source et la cible, reproduit la configuration du système et réexécute les installateurs des composants gérés par ProxMenux. Le but est de reproduire l'hôte source, pas seulement l'archive."
|
||||
},
|
||||
{
|
||||
"id": "hidratacion",
|
||||
"term": "Hydratation entre versions du noyau",
|
||||
"def": "Étape de restauration qui fusionne les réglages de l’utilisateur depuis la source (paramètres IOMMU, ID VFIO, particularités et clés GRUB) avec la configuration de démarrage neuve de la cible, sans recopier tels quels les fichiers liés au noyau source. S’exécute si le noyau cible est plus récent que celui de la sauvegarde."
|
||||
},
|
||||
{
|
||||
"id": "cross-kernel",
|
||||
"term": "Restaurer le cross-kernel",
|
||||
"def": "Restaurer où le noyau de la cible diffère de (habituellement est plus récent que) celui de la source. Nécessite le passage <a href=\"#hidratacion\">hydration</a> pour éviter de traîner le long de fichiers incompatibles avec le noyau de la cible."
|
||||
},
|
||||
{
|
||||
"id": "instalador-postboot",
|
||||
"term": "Installation après démarrage",
|
||||
"def": "Composants réinstallés après le premier démarrage de l'hôte restauré (drivers NVIDIA, drivers Coral TPU, outils AMD GPU, outils Intel GPU). Chaque installateur fonctionne contre le noyau de la cible, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source."
|
||||
},
|
||||
{
|
||||
"id": "compatibility-check",
|
||||
"term": "Vérification de compatibilité",
|
||||
"def": "Comparaison entre le manifeste source et l'état de la cible que ProxMenux effectue au début de la restauration. Il décide quelles parties sont copiées mot à mot, qui ont besoin d'hydratation et qui sont recréées par un installateur."
|
||||
},
|
||||
{
|
||||
"id": "equipo-recien-instalado",
|
||||
"term": "Installation fraîche",
|
||||
"def": "Hôte juste réinstallé à partir de zéro, sans fichier local <a href=\"#clave-cifrado\">key</a>. La restauration d'une sauvegarde chiffrée nécessite d'abord la récupération du fichier clé à partir de l’<a href=\"#sobre-recuperacion\">enveloppe</a> stockée sur PBS, en utilisant la phrase de passe <a href=\"#passphrase-recuperacion\">de récupération</a>."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"whereNext": {
|
||||
"heading": "Où après",
|
||||
"items": [
|
||||
{
|
||||
"label": "Comment ça marche",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — où se placent rootfs, le manifeste et l’inventaire des applications dans une sauvegarde."
|
||||
},
|
||||
{
|
||||
"label": "Destination Proxmox Backup Server",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "— où le cryptage côté client, le fichier clé, la phrase de récupération et l'enveloppe sont documentés en profondeur."
|
||||
},
|
||||
{
|
||||
"label": "Restauration",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — procédure de restauration et utilisation du manifeste."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,205 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Comment ProxMenux Sauvegarde fonctionne en interne — rootfs, manifeste, applications",
|
||||
"description": "Description détaillée de ce qu'une sauvegarde ProxMenux contient : les rootfs produits par rsync du profil de chemin par défaut, le manifeste structuré construit par six collecteurs indépendants, et l'inventaire d'applications qui entraîne la réinstallation automatique des paquets et des composants après une restauration.",
|
||||
"ogTitle": "Comment la sauvegarde ProxMenux fonctionne en interne",
|
||||
"ogDescription": "Les trois parties d’une sauvegarde ProxMenux : rootfs, manifeste et applications.",
|
||||
"twitterTitle": "Fonctionnement des sauvegardes ProxMenux | ProxMenux",
|
||||
"twitterDescription": "Les trois charges utiles d'une sauvegarde ProxMenux et comment la restauration reproduit l'hôte source à partir d'eux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Comment ça marche",
|
||||
"description": "La structure interne d’une sauvegarde ProxMenux — système de fichiers, manifeste et inventaire des applications — et leur utilisation pour recréer l’hôte source sur une destination dont le noyau peut être différent.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Une archive, trois charges utiles",
|
||||
"body": "Chaque sauvegarde crée trois parties bien définies dans un même répertoire de préparation. L’archive envoyée à la destination (<code>.tar.zst</code> local, sauvegarde PBS ou archive Borg) conserve cette structure. La restauration utilise les trois : <strong>le manifeste</strong> est consulté avant toute modification pour détecter les différences et déterminer les exclusions ; <strong>rootfs</strong> fournit les fichiers de configuration, appliqués à chaud ou après redémarrage ; <strong>l’inventaire des applications</strong> guide l’installation des paquets et la réinstallation des composants après démarrage. Chaque partie peut être examinée ou extraite indépendamment."
|
||||
},
|
||||
"layout": {
|
||||
"heading": "Mise en page des archives",
|
||||
"intro": "Chaque archive suit la même disposition de l'arbre, quelle que soit la destination. Le sous-répertoire <code>metadata/</code> détient les charges utiles structurées; le sous-répertoire <code>rootfs/</code> détient la copie du système de fichiers.",
|
||||
"treeCaption": "Le répertoire de mise en scène a été établi lors d'une sauvegarde. Chaque destination reçoit le même arbre (adapté à son format natif: tar pour local, PBS morceaux pour PBS, segments borg pour Borg).",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state\n├── metadata/\n│ ├── packages.manual.list # apt-mark showmanual\n│ ├── run_info.env # backup run identity + kernel version + pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n ├── root/ # /root (with volatile subdirs excluded)\n ├── usr/local/ # /usr/local/bin, /usr/local/share/proxmenux, …\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
|
||||
},
|
||||
"rootfs": {
|
||||
"heading": "La partie rootfs",
|
||||
"intro": "L’arborescence <code>rootfs/</code> est une <strong>simple copie du système de fichiers</strong>, créée par <code>rsync</code> depuis l’hôte source. Elle contient un <strong>profil par défaut</strong> sélectionnant les chemins nécessaires à une restauration Proxmox, ainsi que les <strong>chemins personnalisés</strong> ajoutés à la tâche ou à la session interactive. La sélection est volontairement limitée aux chemins qui <em>contiennent de la configuration</em> ou <em>conservent un état que Proxmox ne peut pas recréer seul</em>.",
|
||||
"defaultProfileTitle": "Le profil par défaut",
|
||||
"defaultProfileBody": "Le profil par défaut est défini par <code>hb_default_profile_paths</code> dans <code>lib_host_backup_common.sh</code>. Il couvre huit catégories fixes, plus l’état ZFS si nécessaire, qui décrivent ensemble un hôte Proxmox fonctionnel :",
|
||||
"categoriesTitle": "Catégories de chemins",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Noyau PVE",
|
||||
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
|
||||
"why": "Contenus du système de fichiers cluster et vzdump par défaut. La base de données pmxcfs (<code>config.db</code>) est capturée comme un instantané cohérent via <code>sqlite3 .backup</code> sans arrêter le cluster, et les sidecars <code>.db-wal</code> / <code>.db-shm</code> sont exclus du rsync. Lorsque <code>sqlite3</code> n'est pas disponible, un fichier <code>config.db.raw-fallback</code> est créé puis utilisé automatiquement comme base lors de la restauration."
|
||||
},
|
||||
{
|
||||
"category": "Identité de l'hôte & réseau",
|
||||
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
|
||||
"why": "Les éléments nécessaires pour retrouver le réseau avec la même identité. Les fichiers <code>.link</code> dans <code>/etc/systemd/network</code> associent le nom des interfaces à leur adresse MAC, afin de conserver les noms lors des réinstallations et des changements matériels."
|
||||
},
|
||||
{
|
||||
"category": "Accès et authentification",
|
||||
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
|
||||
"why": "Clés SSH, règles sudo et configuration PAM. Les perdre peut empêcher l’utilisateur d’accéder à l’hôte restauré."
|
||||
},
|
||||
{
|
||||
"category": "Noyau et démarrage",
|
||||
"paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
|
||||
"why": "IOMMU jetons, listes noires de module, ID de périphérique VFIO, table de montage, configuration de la pile de stockage."
|
||||
},
|
||||
{
|
||||
"category": "Shell et paramètres régionaux",
|
||||
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
|
||||
"why": "Configuration shell à l'échelle du système, variables d'environnement, configuration de génération locale."
|
||||
},
|
||||
{
|
||||
"category": "Gestion des paquets et cron",
|
||||
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
|
||||
"why": "Sources APT pour une résolution de paquets cohérente, tâches programmées définies par l'utilisateur."
|
||||
},
|
||||
{
|
||||
"category": "État et outils ProxMenux",
|
||||
"paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
|
||||
"why": "Outillage facultatif mais courant Proxmox. Les chemins manquants sont notés dans <code>metadata/missing_paths.txt</code> sans arrêter la sauvegarde."
|
||||
},
|
||||
{
|
||||
"category": "Exécutables ProxMenux et compte root",
|
||||
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (sous-dirs volatils exclus)",
|
||||
"why": "Les binaires installés par ProxMenux et la configuration par utilisateur sous <code>/root</code>. Les chemins volatils (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sont exclus de la copie. <code>/var/lib/proxmenux</code> détient les tâches de sauvegarde programmées et l'état de l'hôte conservé par ProxMenux; la mise en scène de restauration, les copies de retour et les marqueurs post-restauration sont exclus, parce qu'ils appartiennent à l'hôte qui exécute une restauration."
|
||||
},
|
||||
{
|
||||
"category": "État ZFS (conditionnel)",
|
||||
"paths": "/etc/zfs",
|
||||
"why": "Seulement inclus lorsque l'hôte source exécute ZFS. Contient <code>zpool.cache</code> et <code>hostid</code>."
|
||||
}
|
||||
],
|
||||
"customTitle": "Extension du profil avec des chemins personnalisés",
|
||||
"customBody": "Au-delà du profil par défaut, ProxMenux offre deux façons d'inclure des chemins supplémentaires dans une sauvegarde. Ils composent sans conflit et s'appliquent à la fois aux sauvegardes interactives et aux emplois programmés.",
|
||||
"customExtrasTitle": "1. Extras persistants (fichier par hôte)",
|
||||
"customExtrasBody": "Un fichier texte à <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contient une liste de chemins absolus que l'utilisateur a marqués comme « toujours inclure » sur cet hôte. Lorsqu'une sauvegarde fonctionne en mode <strong>Default</strong>, ProxMenux ajoute ces chemins au profil par défaut automatiquement sans demander. Le fichier est édité à partir de l'interface — pas d'édition manuelle nécessaire — et persiste à travers les reboots et les mises à jour. Un chemin absolu par ligne ; les commentaires <code>#</code> sont autorisés.",
|
||||
"customModeTitle": "2. Mode personnalisé (par exécution)",
|
||||
"customModeBody": "Lancer une sauvegarde en mode <strong>Custom</strong> remplace l'application automatique du profil par défaut par une liste de contrôle montrant chaque chemin : les entrées par défaut du profil et les extras persistants (préfixés avec <code>[+]</code> et pré-cochés). L'utilisateur coche ou désactive les entrées pour cette exécution spécifique, et peut également appuyer sur <em>Ajouter un chemin personnalisé</em> pour entrer un nouveau chemin — qui est ensuite maintenu dans le fichier extras pour les futures sauvegardes.",
|
||||
"customMissingTitle": "Voies absentes de la source",
|
||||
"customMissingBody": "Tout chemin du profil (par défaut ou ajouté) qui n'existe pas sur l'hôte source est enregistré dans <code>metadata/missing_paths.txt</code> à l'intérieur de l'archive. La sauvegarde n’échoue ni ne s'arrête — l'utilisateur voit un résumé des chemins archivés et des chemins manquants à la fin. En pratique, cela se produit pour les chemins optionnels d'outillage comme <code>/etc/wireguard</code> ou <code>/etc/prometheus</code> lorsque ces outils ne sont pas installés."
|
||||
},
|
||||
"manifest": {
|
||||
"heading": "La partie manifeste",
|
||||
"intro": "<code>manifest.json</code> est un document structuré JSON qui décrit l'hôte source au moment de la sauvegarde. Il est produit par <strong>six modules de collecte indépendants</strong> orchestrés par <code>build_manifest.sh</code>. Chaque collecteur est en lecture seule, produit un fragment JSON bien défini, et revient à une valeur par défaut vide s'il échoue – le manifeste est toujours utilisable si une section est incomplète.",
|
||||
"orchestratorCaption": "Les six modules de collecte composent le manifeste. Chaque collecteur fonctionne dans son propre sous-processus; une défaillance d'un seul tombe à un défaut de sécurité documenté et avertit mais n'interrompt pas la sauvegarde.",
|
||||
"collectorRows": [
|
||||
{
|
||||
"collector": "collect_source_host.sh",
|
||||
"produces": "source_host",
|
||||
"content": "Nom d'hôte, version PVE (<code>pveversion</code>), version PBS si l'hôte exécute le rôle de serveur de sauvegarde, noyau (<code>uname -r</code>), mode de démarrage (efi/bios), type de système de fichiers racine, modèle CPU + architecture, mémoire en KB."
|
||||
},
|
||||
{
|
||||
"collector": "collect_hardware.sh",
|
||||
"produces": "hardware_inventory",
|
||||
"content": "GPU avec fabricant et correspondance avec l’installateur ProxMenux ; TPU Coral USB et M.2 détectés par <code>lsusb</code>/<code>lspci</code> ; interfaces réseau avec MAC, emplacement PCI et appartenance à un pont ; périphériques sans fil. Les entrées GPU comprennent l’heuristique <code>passthrough_eligible</code>."
|
||||
},
|
||||
{
|
||||
"collector": "collect_storage.sh",
|
||||
"produces": "storage_inventory",
|
||||
"content": "ZFS pools (avec pool type + disques membres résolus à <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> ou crus <code>/dev/sdX</code> chemins en fonction de la façon dont chaque pool a été créé à l'origine), LVM Groupes de volume + mince pools, disques physiques avec SMART capacité, PVE <code>storage.cfg</code> entrées, montages externes."
|
||||
},
|
||||
{
|
||||
"collector": "collect_kernel.sh",
|
||||
"produces": "kernel_params",
|
||||
"content": "Paramètres ajoutés par l’opérateur dans <code>/proc/cmdline</code>, sans les éléments standard comme <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> et <code>splash</code> ; modules chargés au démarrage depuis <code>/etc/modules</code> ; chemins des fichiers <code>/etc/modprobe.d/*.conf</code> contenant des directives effectives (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
|
||||
},
|
||||
{
|
||||
"collector": "collect_proxmenux_state.sh",
|
||||
"produces": "proxmenux_installed_components",
|
||||
"content": "Lire <code>/usr/local/share/proxmenux/managed_installs.json</code> (enregistrement de tout ce que ProxMenux a installé) et <code>installed_tools.json</code>. Chaque entrée conserve le chemin d'installation (<code>menu_script</code>) afin que la restauration puisse déclencher le même flux d'installation."
|
||||
},
|
||||
{
|
||||
"collector": "collect_guests.sh",
|
||||
"produces": "vms_lxcs_at_backup",
|
||||
"content": "Énumère les VM (<code>qm list</code>) et les LXC (<code>pct list</code>) présents au moment de la sauvegarde — VMID, nom, état actuel. Seul l'inventaire : les données des invités sont sous la responsabilité de <code>vzdump</code> / PBS."
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validation du schéma",
|
||||
"schemaBody": "Le manifeste valide contre <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'exécution du <code>build_manifest.sh --validate</code> déclenche une validation de schéma côté Python JSON (exige <code>python3</code> + <code>jsonschema</code>). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "L'inventaire des applications",
|
||||
"intro": "Deux inventaires recensent les logiciels ajoutés aux paquets de base Proxmox VE : la liste des paquets dans <code>metadata/</code> et le registre des composants dans rootfs, détaillés ci-dessous. La restauration les utilise pour réinstaller les logiciels de l’utilisateur avec APT ou les installateurs ProxMenux selon leur mode d’installation initial.",
|
||||
"packagesTitle": "packages.manual.list",
|
||||
"packagesBody": "Une liste alphabétique en texte brut produite par <code>apt-mark showmanual</code>, avec les paquets APT <em>explicitement installés</em> sur l’hôte source. Les dépendances du système Proxmox VE de base sont exclues ; APT les réinstalle automatiquement sur la destination. Lors de la restauration, <code>_rs_run_complete_extras</code> lit la liste et applique un <em>filtre contre les suppressions en cascade</em> en trois passes : <code>dpkg -s</code> repère les paquets déjà installés, la détection des autres versions majeures vise les bibliothèques, et <code>apt-get install --simulate</code> vérifie le risque de suppression en cascade. Les paquets retenus sont installés avec <code>apt-get install -y</code>.",
|
||||
"componentsTitle": "components_status.json (dans rootfs)",
|
||||
"componentsBody": "Un registre JSON sous <code>/usr/local/share/proxmenux/</code> qui enregistre chaque composant ProxMenux a installé avec son état exact : version, drapeaux spécifiques ProxMenux (pour NVIDIA : <code>patched</code> booléen ; pour Coral : DKMS version). Ce fichier vit à l'intérieur des rootfs — pas dans <code>metadata/</code> — parce que c'est <em>lu après</em> la copie de rootfs vers la cible. Le répartiteur post-démarrage (<code>apply_cluster_postboot.sh</code>) itère ses entrées et exécute le crochet <code>--auto-reinstall</code> de chaque composant, qui lit l'état enregistré et reproduit l'installation contre le noyau courant de la cible.",
|
||||
"componentInstallersTitle": "Installateurs de composants",
|
||||
"componentInstallersBody": "Quatre installateurs ProxMenux exposent actuellement un point d'entrée <code>--auto-reinstall</code> :",
|
||||
"installerRows": [
|
||||
{
|
||||
"component": "nvidia_driver",
|
||||
"installer": "gpu_tpu/nvidia_installer.sh",
|
||||
"action": "Lire <code>version</code> + <code>patched</code>. Télécharge exactement le même fichier d'exécution NVIDIA, construit des modules DKMS contre le noyau de la cible, réapplique le patch ProxMenux si la source l'avait."
|
||||
},
|
||||
{
|
||||
"component": "coral_driver",
|
||||
"installer": "gpu_tpu/install_coral.sh",
|
||||
"action": "Lire la version du pilote Coral. Compile le module DKMS contre le noyau de la cible."
|
||||
},
|
||||
{
|
||||
"component": "amdgpu_top",
|
||||
"installer": "gpu_tpu/amd_gpu_tools.sh",
|
||||
"action": "Lis la version enregistrée. Re-télécharge le <code>.deb</code> exact de la version GitHub."
|
||||
},
|
||||
{
|
||||
"component": "intel_gpu_tools",
|
||||
"installer": "gpu_tpu/intel_gpu_tools.sh",
|
||||
"action": "APT-installe le paquet. Idépotent si déjà présent à partir de <code>packages.manual.list</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"restoreFlow": {
|
||||
"heading": "Comment la restauration consomme les trois charges utiles",
|
||||
"intro": "La restauration est un pipeline en six étapes. Chaque étape lit un sous-ensemble spécifique de l'archive et met à jour l'hôte cible. Aucune étape n'exige que l'hôte source soit accessible — l'archive est entièrement autonome.",
|
||||
"stagesCaption": "L’étape 1 consulte le manifeste pour déterminer les modifications possibles. L’étape 2 copie les chemins rootfs applicables à chaud. L’étape 3 prépare les chemins à risque pour le prochain démarrage. L’étape 3b importe les pools ZFS de données ne contenant pas la racine et dont tous les disques sont présents. L’étape 4 installe les paquets. L’étape 5 réinstalle les composants après redémarrage pour le noyau de la destination.",
|
||||
"stageRows": [
|
||||
{
|
||||
"stage": "1",
|
||||
"name": "Vérification de compatibilité",
|
||||
"reads": "manifest.json",
|
||||
"action": "Exécute <code>hb_compat_check</code>. Comparer le matériel source par rapport au matériel cible (NIC, ID de stockage), la version PVE et la version principale du noyau. Ensembles <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> ou <code>bk_older</code>) et peuple <code>RS_SKIP_PATHS</code> avec des exclusions à la dérive matérielle et aux différences de noyau."
|
||||
},
|
||||
{
|
||||
"stage": "2",
|
||||
"name": "Appliquer à chaud",
|
||||
"reads": "rootfs/ (chemins sûrs seulement)",
|
||||
"action": "<code>_rs_apply … hot</code> copie les entrées de <code>hb_classify_path</code>=<code>hot</code> directement à la cible en direct. Tout ce qui est sous <code>/etc/pve</code>, <code>/etc/network</code> ou des chemins classés comme <em>reboot</em>/<em>dangerous</em> est reporté."
|
||||
},
|
||||
{
|
||||
"stage": "3",
|
||||
"name": "En attente de préparation",
|
||||
"reads": "rootfs/ (redémarrage + chemins dangereux)",
|
||||
"action": "<code>_rs_prepare_pending_restore</code> prépare les chemins à risque dans <code>/var/lib/proxmenux/pending-restore/</code>, écrit <code>plan.env</code>, <code>apply-on-boot.list</code> et <code>rs-skip-paths.txt</code>, puis active <code>proxmenux-restore-onboot.service</code> pour le prochain démarrage."
|
||||
},
|
||||
{
|
||||
"stage": "3b",
|
||||
"name": "Importation des pools de données",
|
||||
"reads": "manifest.storage_inventory + état ZFS de la destination",
|
||||
"action": "<code>_rs_import_data_pools</code> tente d’importer chaque pool ZFS ne contenant pas la racine et dont tous les disques sont présents sur la destination. Avec un hostid étranger, l’importation est retentée avec <code>zpool import -f</code>. Si un disque manque, le pool est ignoré avec un avertissement. Le résultat par pool est enregistré dans <code>/var/log/proxmenux/restore-datapools-<timestamp>.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "4",
|
||||
"name": "Installation du paquet",
|
||||
"reads": "metadata/packages.manual.list",
|
||||
"action": "<code>_rs_run_complete_extras</code> exécute le filtre sans risque de cascade et appelle <code>apt-get install -y</code> avec la liste des paquets survivants. La sortie complète va à <code>/var/log/proxmenux/restore-apt-*.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "5",
|
||||
"name": "Après le démarrage",
|
||||
"reads": "rootfs (déjà appliqué) + components_status.json",
|
||||
"action": "Après le redémarrage, <code>apply_pending_restore.sh</code> rejoue les chemins différés et <code>apply_cluster_postboot.sh</code> exécute <code>update-initramfs</code>, <code>update-grub</code> (ou <code>proxmox-boot-tool refresh</code>) et itère sur <code>components_status.json</code> en tirant le crochet <code>--auto-reinstall</code> de chaque composant."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyItWorks": {
|
||||
"heading": "Pourquoi séparer la sauvegarde en trois parties",
|
||||
"body": "La séparation suit le <strong>cycle de vie</strong> des données. Le système de fichiers est transféré avec <code>rsync</code> : rapidement, de façon transparente et atomique par fichier. L’état de configuration à interpréter avant toute modification est du <strong>JSON structuré</strong>, lisible indépendamment, versionnable par schéma et comparable automatiquement à l’état de la destination. Les logiciels à réinstaller sont décrits dans un <strong>inventaire</strong> de noms et versions ; le gestionnaire de paquets et les installateurs ProxMenux choisissent les binaires adaptés. Chaque partie répond à son besoin. Leur combinaison vise une restauration cohérente tout en tolérant les échecs : un manifeste corrompu laisse rootfs récupérable, un paquet manquant n’empêche pas l’installation des composants et l’échec d’un installateur sur une entrée n’arrête pas la suivante."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Sauvegarde et restauration — Présentation | Sauvegarde et restauration complètes de l'hôte pour Proxmox VE",
|
||||
"description": "La fonction de sauvegarde et de restauration de ProxMenux capture l'état complet d'un hôte Proxmox (système de fichiers, manifeste de configuration structuré et paquets/composants installés) et le reproduisent sur le même hôte ou sur un hôte différent. La sauvegarde et la restauration sont autonomes : aucune dépendance externe et les restaurations inter-noyaux sont prises en charge via un filtre de sous-ensemble sécurisé sensible à la direction et une hydratation indépendante du noyau.",
|
||||
"ogTitle": "ProxMenux Sauvegarde et restauration – Présentation",
|
||||
"ogDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants.",
|
||||
"twitterTitle": "ProxMenux Sauvegarde et restauration | ProxMenux",
|
||||
"twitterDescription": "Sauvegarde et restauration complètes de l'hôte pour Proxmox VE avec manifeste structuré, liste de packages et réinstallateurs de composants."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sauvegarde et restauration",
|
||||
"description": "Sauvegarde et restauration de l'hôte complet pour Proxmox VE. Capture le système de fichiers, la configuration et les composants installés dans une seule archive, et reproduit l'hôte sur la même installation Proxmox ou sur une autre installation Proxmox sans dépendances externes.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Qu'est-ce que c'est, en un seul paragraphe",
|
||||
"body": "Une sauvegarde ProxMenux capture l’état complet d’un hôte Proxmox : <strong>le système de fichiers</strong>, avec les répertoires pertinents sous <code>/etc</code>, <code>/root</code> et <code>/var/lib/pve-cluster</code>, ainsi que les chemins personnalisés facultatifs ; <strong>un manifeste structuré</strong> en JSON décrivant le matériel détecté, les paramètres du noyau, la configuration réseau, l’état de ZFS, les utilisateurs et les entrées cron ; et <strong>un inventaire des applications</strong>, avec les paquets marqués comme installés manuellement par APT et les composants installés par ProxMenux, accompagnés de leurs versions exactes. Les trois destinations prises en charge — archive locale, Proxmox Backup Server (recommandé) et Borg — reçoivent le même contenu autonome. Chacune permet de reconstruire l’hôte cible sans que l’hôte source soit accessible pendant la restauration."
|
||||
},
|
||||
"video": {
|
||||
"heading": "Présentation vidéo",
|
||||
"intro": "Vous préférez regarder la sauvegarde et la restauration en action avant de la configurer ? Cette procédure pas à pas couvre une démonstration complète de bout en bout de la fonctionnalité dans ProxMenux.",
|
||||
"title": "ProxMenux — Procédure pas à pas de sauvegarde et de restauration",
|
||||
"caption": "Vidéo externe sur YouTube. Lecture en mode de confidentialité amélioré (pas de cookies jusqu'à ce que vous appuyiez sur play)."
|
||||
},
|
||||
"whatItIsNot": {
|
||||
"heading": "Ce que ce n'est pas",
|
||||
"intro": "Cette section couvre la sauvegarde et la restauration <strong>de l’hôte</strong> : l’installation Proxmox elle-même, et non les applications ou systèmes invités qui y fonctionnent.",
|
||||
"items": [
|
||||
"<strong>Ce n’est pas un outil de sauvegarde des VM/CT.</strong> Cette fonction ne capture ni les disques ni l’état de la RAM des invités ; c’est le rôle de <code>vzdump</code>. Les <strong>fichiers de configuration</strong> des invités (<code>/etc/pve/nodes/<node>/qemu-server/*.conf</code> et <code>lxc/*.conf</code>) sont <strong>bien</strong> sauvegardés. Après restauration, l’inventaire réapparaît et les disques peuvent être restaurés ou rattachés à partir d’une sauvegarde existante sur PBS ou en local.",
|
||||
"<strong>Ce n’est pas une opération à l’échelle du cluster.</strong> Chaque nœud se sauvegarde lui-même. L’appartenance au cluster est enregistrée dans <code>/etc/pve</code> afin de pouvoir réintégrer un nœud restauré, mais la restauration de tout le cluster nécessite de coordonner les différents nœuds.",
|
||||
"<strong>Ce n’est pas une image complète du disque.</strong> Les binaires du noyau, l’initramfs et la partition de démarrage ne sont pas sauvegardés. Lors de la restauration, ProxMenux utilise les fichiers de démarrage de l’hôte cible, régénérés automatiquement par <code>update-initramfs</code> et l’outil du chargeur d’amorçage, puis installe les pilotes adaptés au noyau en cours d’exécution sur la cible."
|
||||
]
|
||||
},
|
||||
"threePillars": {
|
||||
"heading": "Les trois piliers d'une sauvegarde",
|
||||
"intro": "Une archive ProxMenux est structurée autour de trois charges utiles autonomes. La restauration utilise les trois ensemble pour reproduire l'hôte source sur une cible sur laquelle le même noyau n'est peut-être même pas installé.",
|
||||
"diagramCaption": "Chaque sauvegarde expédie les trois mêmes charges utiles, quelle que soit la destination. La restauration consomme les trois : rootfs pour déposer les fichiers, le manifeste pour détecter les dérives et les différences entre les noyaux, et l'inventaire des applications pour réinstaller les packages et les composants sur le propre noyau de la cible.",
|
||||
"pillar1Label": "Système de fichiers",
|
||||
"pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, plus un\ninstantané sqlite3\nde /var/lib/pve-cluster,\n+ chemins facultatifs)",
|
||||
"pillar2Label": "Manifeste",
|
||||
"pillar2Detail": "manifest.json\n(matériel, paramètres\ndu noyau, réseau,\nZFS, utilisateurs, cron,\npools ZFS, stockage)",
|
||||
"pillar3Label": "Applications",
|
||||
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(paquets APT manuels + installateurs\nProxMenux avec versions)"
|
||||
},
|
||||
"restoreIsUniversal": {
|
||||
"heading": "La restauration reproduit l'hôte source, pas l'archive",
|
||||
"body": "La restauration d'une sauvegarde ProxMenux ne se contente pas d'extraire le système de fichiers. Le flux de restauration lit le manifeste pour détecter la dérive entre la source et la cible (différences matérielles, renommages des cartes réseau, version du noyau, identité du pool ZFS), restaure le système de fichiers, puis déclenche le programme d'installation de composant correct pour chaque service installé sur la source (pilote NVIDIA, Coral TPU, outils GPU AMD, outils Intel GPU). Chaque programme d'installation s'exécute sur le <strong>noyau actuel de la cible</strong>, de sorte que l'hôte restauré ne dépend pas de la présence du noyau de la source. Lorsque le noyau de la cible est plus récent que celui de la sauvegarde, une passe d'<strong>hydratation</strong> indépendante du noyau fusionne les propres réglages de l'utilisateur (jetons IOMMU, ID de périphérique VFIO, adaptations particulières, clés GRUB) dans la nouvelle configuration de démarrage de la cible sans copier textuellement les fichiers liés au noyau."
|
||||
},
|
||||
"twoInterfaces": {
|
||||
"heading": "Deux interfaces, un backend",
|
||||
"intro": "Chaque étape du workflow de sauvegarde et de restauration est disponible à partir de deux points d'entrée. Les deux appellent la même bibliothèque shell, produisent des archives identiques et lisent le même registre de tâches.",
|
||||
"cliLabel": "ProxMenux Scripts (TUI)",
|
||||
"cliDetail": "menu → Utilitaires →\nSauvegarde / Restauration de l'hôte\n\nFlux basé sur le dialogue,\nCompatible avec SSH, scriptable\npour une utilisation sans surveillance.",
|
||||
"webLabel": "ProxMenux Monitor (Web UI)",
|
||||
"webDetail": "Onglet Sauvegardes dans\nl’interface web de Monitor.\n\nRestauration en un clic, suivi\ndes journaux en direct, intégré\naux notifications et à la vue\ndes différences de retour arrière."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller à partir d'ici",
|
||||
"intro": "Chaque sous-section ci-dessous couvre en profondeur un aspect du flux de travail. Commencez par <em>Comment ça marche</em> si l'objectif est de comprendre ce que contient l'archive et pourquoi. Accédez à <em>Destinations</em> pour configurer la cible de la copie. Lisez <em>Restauration</em> et <em>Restauration inter-noyaux</em> pour le côté récupération.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Comment ça marche",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "— les trois charges utiles (rootfs, manifeste, applications) en détail, avec les collecteurs qui les produisent et le format de chaque fichier."
|
||||
},
|
||||
{
|
||||
"label": "Destinations",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— comparaison de local, Proxmox Backup Server (recommandé) et Borg, et comment configurer chacun d'eux."
|
||||
},
|
||||
{
|
||||
"label": "Création de sauvegardes",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "— sauvegardes ponctuelles, profil de chemin par défaut, ajout de chemins personnalisés, chiffrement pour PBS."
|
||||
},
|
||||
{
|
||||
"label": "Tâches planifiées",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "— nouvelles tâches ou attachement à une tâche vzdump PVE existante, formats de planification, modal de détail de la tâche."
|
||||
},
|
||||
{
|
||||
"label": "Restauration",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— les trois actions sur une archive (afficher, télécharger, restaurer), la restauration complète ou personnalisée, le répartiteur post-démarrage et pourquoi les dix dernières minutes sont importantes."
|
||||
},
|
||||
{
|
||||
"label": "Restauration inter-noyaux",
|
||||
"href": "/docs/backup-restore/cross-kernel",
|
||||
"tail": " — comportement tenant compte du sens du changement de version lorsque le noyau cible diffère de celui de la sauvegarde, filtre de sous-ensemble sûr et quatre phases d’hydratation."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Tâches planifiées — temporisateurs, mode attach et rétention | ProxMenux",
|
||||
"description": "Tâches de sauvegarde d’hôte ProxMenux programmées. Deux modes de création (minuteur systemd propre ou association à une tâche vzdump PVE existante), règles de rétention appliquées par tâche avec proxmox-backup-client, Borg ou le nettoyage local, fichiers sous /var/lib/proxmenux/backup-jobs et script d’exécution produisant les mêmes archives que le processus interactif.",
|
||||
"ogTitle": "Sauvegarde ProxMenux — tâches programmées",
|
||||
"ogDescription": "Sauvegardes d'hôte programmées non surveillées avec mode de fixation, conservation, et les mêmes trois destinations que le flux interactif.",
|
||||
"twitterTitle": "Tâches planifiées | ProxMenux",
|
||||
"twitterDescription": "Tâches programmées de sauvegarde d’hôte sans intervention, avec mode d’association et rétention."
|
||||
},
|
||||
"header": {
|
||||
"title": "Tâches programmées",
|
||||
"description": "Tâches de sauvegarde d’hôte sans intervention. Deux modèles de création : une nouvelle tâche indépendante avec son propre calendrier, ou une tâche associée à une tâche vzdump PVE existante, dont elle reprend le calendrier et la rétention. Les deux produisent les mêmes archives que le processus interactif.",
|
||||
"section": "Sauvegarde et restauration"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Les deux modèles de tâches programmées",
|
||||
"body": "Une tâche programmée peut être créé selon l'un des deux modèles suivants :",
|
||||
"modelsList": [
|
||||
"<strong>Nouveau travail indépendant</strong> — ProxMenux définit lui-même l'horaire de travail avec sa propre minuterie systemd, indépendamment de toute autre tâche sur l'hôte. Compatible avec les trois destinations : Local, PBS et Borg.",
|
||||
"<strong>Associer à une tâche vzdump PVE existante</strong> — la tâche n’a pas de calendrier propre ; elle s’exécute automatiquement quand la tâche vzdump parente sauvegarde les VM et LXC de cet hôte. Elle reprend son calendrier et sa rétention. Compatible avec les destinations locale et PBS (Borg n’est pas pris en charge, car PVE n’a pas de planificateur natif pour Borg)."
|
||||
]
|
||||
},
|
||||
"attachBadge": {
|
||||
"title": "Mode d’association — recommandé si une tâche vzdump PVE existe déjà",
|
||||
"body": "Lorsqu’une tâche de sauvegarde vzdump PVE est déjà configurée pour les VM et LXC du nœud, l’association de la sauvegarde hôte la fait exécuter après celle des invités, dans le <strong>même cycle de sauvegarde</strong>. À la restauration, les configurations des invités viennent de la sauvegarde hôte (sous <code>/etc/pve</code>) et leurs disques des sauvegardes vzdump du même cycle. Cela facilite la récupération coordonnée du nœud, sans constituer un instantané atomique : des modifications pendant le cycle peuvent créer des écarts entre la configuration hôte et l’état des disques des invités."
|
||||
},
|
||||
"frequencyBadge": {
|
||||
"title": "Fréquence recommandée",
|
||||
"body": "Pour maximiser la compatibilité entre une sauvegarde hôte et sa future restauration, sauvegardez fréquemment l’hôte. Plus la copie est proche de son état actuel, moins la restauration doit réconcilier d’écarts de configuration, de paquets et de composants."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Les deux modes",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Nouveau travail planifié",
|
||||
"backends": "Local, PBS, Borg",
|
||||
"schedule": "Propre expression <code>OnCalendar</code> (syntaxe du calendrier systemd — par exemple <code>daily</code>, <code>Mon..Fri 03:00</code>).",
|
||||
"retention": "Demandée séparément: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Appliquée par le script d’exécution après chaque sauvegarde réussie."
|
||||
},
|
||||
{
|
||||
"mode": "Associer à une tâche vzdump PVE",
|
||||
"backends": "Local, PBS (Borg n'a pas de planificateur côté PVE)",
|
||||
"schedule": "Hérité de la tâche PVE parente. Aucun minuteur systemd n’est installé côté ProxMenux.",
|
||||
"retention": "Héritée de la configuration <code>prune-backups</code> de la tâche parente (associée une à une aux variables <code>KEEP_*</code> du script d’exécution via <code>hb_pve_prune_to_keep_env</code>)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"attachDetail": {
|
||||
"heading": "Comment fonctionne le mode de fixation",
|
||||
"intro": "PVE écrit les tâches <code>vzdump</code> dans <code>/etc/pve/jobs.cfg</code>, avec une section par tâche indiquant le stockage des sauvegardes VM et LXC. Le mode d’association exige un backend compris par ProxMenux (local ou PBS). La sauvegarde hôte s’exécute via le hook job-end après la fin de la tâche de sauvegarde des invités.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"detail": "Lors de la création de tâches, ProxMenux liste les tâches parent PVE compatibles via <code>hb_pve_list_vzdump_jobs_for_backend</code>. L'utilisateur en choisit un."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"detail": "Le <code>.env</code> de l'emploi est écrit avec <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> et les valeurs de <code>KEEP_*</code> héritées; aucun minuteur systemd n'est créé."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"detail": "<code>hb_install_vzdump_hook</code> enregistre un hook dans <code>/etc/vzdump.conf</code>. À la phase job-end de toute tâche vzdump, il compare le <code>$STOREID</code> reçu au <code>PVE_STORAGE</code> de chaque tâche associée activée et appelle le script d’exécution en cas de correspondance. L’association se fait par stockage, et non par identifiant de la tâche parente choisie."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"detail": "L’archive est enregistrée dans le même stockage que les sauvegardes vzdump : <code>path/dump/</code> pour la destination locale ou le dépôt PBS configuré dans l’entrée de stockage PVE."
|
||||
}
|
||||
],
|
||||
"outroBody": "Le mode d’association n’a pas de minuteur propre. Désactiver ou supprimer la tâche PVE parente choisie arrête son déclenchement, mais une autre tâche vzdump utilisant le même stockage peut encore lancer la sauvegarde hôte. Désactivez ou supprimez la tâche ProxMenux elle-même pour l’empêcher. Lors d’une désactivation, son entrée reste sur disque pour permettre une réactivation ou une nouvelle association."
|
||||
},
|
||||
"storageLayout": {
|
||||
"heading": "Fichiers qui constituent un travail",
|
||||
"intro": "Chaque travail programmé est entièrement décrit par trois ou quatre fichiers sur disque. Les lire donne la configuration complète du travail sans compter sur l'interface.",
|
||||
"rows": [
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
|
||||
"content": "Backend, identifiant de sauvegarde ou destination, calendrier (nouvelle tâche) ou tâche PVE parente (association), indicateur d’activation, valeurs de rétention <code>KEEP_*</code> et références aux identifiants."
|
||||
},
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
|
||||
"content": "Un chemin absolu par ligne : la sélection figée à partir du profil lors de la création de la tâche. Modifier le fichier utilise la nouvelle sélection à la prochaine exécution du minuteur."
|
||||
},
|
||||
{
|
||||
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
|
||||
"content": "Nouveau mode seulement. Le service invoque <code>run_scheduled_backup.sh JOB_ID</code>. Le minuteur le planifie avec <code>Persistent=true</code> (exécutions manquées rattrapées au prochain démarrage) et un petit <code>RandomizedDelaySec=120</code> pour répartir la charge lorsque plusieurs tâches partagent la même expression OnCalendar."
|
||||
},
|
||||
{
|
||||
"path": "/etc/vzdump.conf script-hook",
|
||||
"content": "Mode d’association uniquement. Installé une fois par <code>hb_install_vzdump_hook</code> ; compare le <code>PVE_STORAGE</code> de chaque tâche associée au <code>$STOREID</code> transmis par PVE au hook."
|
||||
}
|
||||
]
|
||||
},
|
||||
"runner": {
|
||||
"heading": "Ce que fait une tâche à son déclenchement",
|
||||
"intro": "Chaque travail — qu’il s’agisse d’une nouvelle tâche indépendante ou d’une tâche associée — comporte la même séquence en trois étapes:",
|
||||
"steps": [
|
||||
"<strong>Prépare la sauvegarde.</strong> Lit la configuration de travail (destination, profil, chemins) et assemble l'arborescence des archives exactement comme le flux interactif. Le résultat est la même archive qu'une sauvegarde manuelle avec ces paramètres produirait.",
|
||||
"<strong>Écrire à la destination.</strong> Charge ou écrit l'archive vers la destination configurée — un fichier local <code>.tar.zst</code>, une sauvegarde PBS ou une archive Borg — en utilisant exactement les mêmes outils et identifiants qu’une sauvegarde manuelle vers la même destination.",
|
||||
"<strong>Appliquer la rétention.</strong> Supprime les anciennes sauvegardes de la destination, en maintenant les nombres <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configurés sur le travail. La purge est effectuée par la destination elle-même: PBS applique sa propre conservation, Borg exécute <code>borg prune</code>, et pour Local ProxMenux supprime les fichiers qui tombent en dehors de la fenêtre <code>keep-last</code>."
|
||||
]
|
||||
},
|
||||
"management": {
|
||||
"heading": "Gestion des tâches",
|
||||
"intro": "Le menu planificateur (Scripts TUI) et l'onglet Sauvegardes Monitor exposent les mêmes actions sur n'importe quel travail.",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Exécuter maintenant",
|
||||
"detail": "Appelle immédiatement le script d’exécution, sans attendre le minuteur ou le hook vzdump. Utile pour vérifier la configuration sans attendre le prochain déclenchement."
|
||||
},
|
||||
{
|
||||
"action": "Activer / Désactiver",
|
||||
"detail": "Nouveau mode : <code>systemctl enable/disable --now</code> la minuterie. Attache le mode : retourne le drapeau <code>ENABLED</code> dans le travail env — le script hook l'honore au prochain déclenchement PVE."
|
||||
},
|
||||
{
|
||||
"action": "Modifier",
|
||||
"detail": "Rouvre les champs de destination, calendrier, profil et rétention et réécrit les fichiers de la tâche. Conserve son identifiant."
|
||||
},
|
||||
{
|
||||
"action": "Supprimer",
|
||||
"detail": "Supprime le fichier env, la liste des chemins et le minuteur et service systemd (nouvelle tâche), et désactive l’association au hook (mode d’association). Les archives déjà présentes à destination restent intactes."
|
||||
},
|
||||
{
|
||||
"action": "Voir le journal",
|
||||
"detail": "Affiche en continu <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> : un fichier journal par exécution. Le programme d'exécution émet également une ligne d'état compacte à journald sous le service systemd."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Notifications",
|
||||
"body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite?",
|
||||
"items": [
|
||||
{
|
||||
"label": "Création de sauvegardes",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "— le flux interactif qui partage le moteur avec le planificateur."
|
||||
},
|
||||
{
|
||||
"label": "Destinations",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— configuration par moteur utilisée à la fois par le flux interactif et le planificateur."
|
||||
},
|
||||
{
|
||||
"label": "Restauration",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — le processus qui utilise les sauvegardes produites par les tâches."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Ajouter un contrôleur ou un NVMe à une VM | Documentation ProxMenux",
|
||||
"description": "Attribuez un contrôleur de stockage SATA/SAS HBA ou un périphérique NVMe à une VM Proxmox par passthrough PCI avec ProxMenux. L’outil gère l’activation d’IOMMU, la détection des conflits et l’affectation avec qm set --hostpci.",
|
||||
"ogTitle": "Ajouter un contrôleur ou un NVMe à une VM | Documentation ProxMenux",
|
||||
"ogDescription": "Attribuez un HBA SATA/SAS complet ou un périphérique NVMe à une VM Proxmox. ProxMenux gère IOMMU, la détection des conflits et l’affectation hostpci."
|
||||
},
|
||||
"header": {
|
||||
"title": "Ajouter un contrôleur ou un NVMe à une VM",
|
||||
"description": "Attribuez un adaptateur de bus SATA/SAS (HBA) complet ou un périphérique NVMe à une VM Proxmox par passthrough PCI. ProxMenux vérifie IOMMU et l’active avec votre accord, recense les périphériques compatibles, écarte les conflits et configure l’affectation avec qm set --hostpci.",
|
||||
"section": "Gestionnaire de disque · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cela fait (et ne fait pas)",
|
||||
"body": "Il s’agit d’un <strong>passthrough au niveau du périphérique</strong> : la carte PCIe quitte le contrôle du noyau de l’hôte et est liée à <code>vfio-pci</code>. La VM voit le contrôleur lui-même, au lieu de disques transmis individuellement, et charge son propre pilote pour ce modèle précis. Tous les disques qui y sont raccordés suivent automatiquement, avec les données SMART natives, toutes les fonctions du firmware et aucune couche Proxmox intermédiaire."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le flux a deux phases avec une séparation claire entre \"collecter l'information, vérifier IOMMU et lister les candidats\" et \"en fait fixer l'appareil PCI\". Jusqu'à la confirmation finale rien n'est écrit à la config VM."
|
||||
},
|
||||
"iommu": {
|
||||
"heading": "Les groupes IOMMU — pourquoi la carte entière part à la fois",
|
||||
"body": "La limite d’isolation du passthrough PCI est le <strong>groupe IOMMU</strong>, la plus petite unité que l’IOMMU du CPU peut isoler. Les périphériques d’un même groupe ne peuvent pas être isolés les uns des autres. Si un contrôleur SATA partage son groupe avec un contrôleur USB, le passthrough SATA peut exiger de libérer aussi l’USB de l’hôte, ou être impossible. Il n’attribue pas automatiquement tous les périphériques du groupe à la VM.",
|
||||
"outro": "ProxMenux montre le groupe IOMMU à côté de chaque appareil et vous avertit lorsqu'un groupe porte plus que le contrôleur que vous voulez. Vous pouvez toujours procéder si les périphériques supplémentaires du groupe sont acceptables (tous les contrôleurs de disque, par exemple), ou revenir en arrière s'ils ne le sont pas."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Préalables",
|
||||
"items": [
|
||||
"<strong>Le CPU et la carte mère prennent en charge</strong> VT-d (Intel) ou AMD-Vi, et la fonction est activée dans le firmware (BIOS/UEFI). ProxMenux peut activer la partie noyau, mais ne peut pas modifier le réglage du firmware.",
|
||||
"La VM cible est <strong>éteinte</strong> avant l’affectation de périphériques PCI.",
|
||||
"Le contrôleur/NVMe <strong> n'est pas celui qui détient le système de fichiers racine Proxmox</strong>. Le script cache tout ce qui est utilisé par l'hôte.",
|
||||
"Le système invité dispose des pilotes du contrôleur. Linux prend en charge presque tous les HBA sans ajout de pilote ; sous Windows, le pilote du fabricant doit être installé <em>avant</em> le démarrage avec le contrôleur affecté."
|
||||
],
|
||||
"warnTitle": "La migration à chaud est impossible",
|
||||
"warnBody": "Un VM avec PCI passethrough est lié au noeud qui détient physiquement la carte. La migration en direct à travers les nœuds échouera. Planifiez les sauvegardes / réplication en conséquence."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir la VM cible",
|
||||
"bodyRich": "ProxMenux lit <code>qm list</code> et affiche chaque VM. Choisissez celui qui recevra le contrôleur.",
|
||||
"img": "/disk/nvme-passthrough/vm-selection.png",
|
||||
"alt": "Boîte de dialogue de sélection VM",
|
||||
"caption": "Boîte de dialogue de sélection VM"
|
||||
},
|
||||
{
|
||||
"title": "Vérification IOMMU",
|
||||
"bodyRich": "Si IOMMU n’est pas activé dans la ligne de commande du noyau, ProxMenux propose de l’activer. Il modifie <code>/etc/kernel/cmdline</code> pour systemd-boot ou <code>/etc/default/grub</code> pour GRUB et ajoute le paramètre adapté au CPU :",
|
||||
"items": [
|
||||
"<code>intel_iommu=on</code> pour les processeurs Intel.",
|
||||
"<code>amd_iommu=on</code> pour processeurs AMD."
|
||||
],
|
||||
"outro": "Un redémarrage est nécessaire après cette modification. Le script propose de redémarrer maintenant ou plus tard ; le passthrough ne peut continuer que lorsque la nouvelle ligne de commande du noyau est active.",
|
||||
"img": "/disk/nvme-passthrough/iommu-warning.png",
|
||||
"alt": "Boîte de dialogue IOMMU requis",
|
||||
"caption": "IOMMU requis : proposition d’activation et de redémarrage"
|
||||
},
|
||||
{
|
||||
"title": "Énumération du périphérique",
|
||||
"body": "ProxMenux liste tous les contrôleurs de stockage (SATA / SAS HBA) et tous les périphériques NVMe du bus PCI. Pour chaque appareil, il affiche :",
|
||||
"items": [
|
||||
"Adresse PCI (<code>00:17.0</code>, <code>01:00.0</code>, ...).",
|
||||
"Description du fournisseur / de l'appareil.",
|
||||
"Groupe IOMMU, avec un avertissement ⚠ s’il est partagé avec d’autres périphériques sans rapport.",
|
||||
"Les disques actuellement derrière le contrôleur (pour que vous sachiez ce qui va le suivre au VM)."
|
||||
],
|
||||
"img": "/disk/nvme-passthrough/device-list.png",
|
||||
"alt": "Liste des contrôleurs et périphériques NVMe",
|
||||
"caption": "Liste des contrôleurs et périphériques NVMe avec les groupes IOMMU"
|
||||
},
|
||||
{
|
||||
"title": "Détection des conflits",
|
||||
"bodyRich": "Le script bloque les périphériques manifestement dangereux : ceux déjà attribués à une autre VM via <code>hostpci</code> dans sa configuration, ceux utilisés par l’hôte comme le contrôleur du disque racine, ou ceux d’un groupe IOMMU dont les autres membres ne peuvent pas être identifiés de façon sûre. Les périphériques admissibles sont proposés à la sélection.",
|
||||
"img": "/disk/nvme-passthrough/conflict-warning.png",
|
||||
"alt": "Avertissement de détection des conflits",
|
||||
"caption": "Détection des conflits — dispositif bloqué avec raison"
|
||||
},
|
||||
{
|
||||
"title": "Affecter et terminer",
|
||||
"bodyRich": "Pour chaque appareil sélectionné ProxMenux exécute <code>qm set <VMID> --hostpciN <pci-addr>,pcie=1</code>, en choisissant la prochaine fente libre <code>hostpci</code>. Si IOMMU a été activé pendant cette session, on vous rappelle de redémarrer avant de démarrer le VM.",
|
||||
"img": "/disk/nvme-passthrough/assignment.png",
|
||||
"alt": "Résumé de l'attribution",
|
||||
"caption": "Résumé de l’affectation : emplacements hostpciN et adresses PCI attribuées"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noGroupsTitle": "IOMMU activé, mais aucun groupe dans /sys/kernel/iommu_groups/",
|
||||
"noGroupsBody": "Redémarrer est nécessaire pour que le noyau cmdline prenne effet. Si les groupes sont encore manquants après le redémarrage, VT-d / AMD-Vi est probablement désactivé dans le firmware — vérifiez la configuration BIOS/UEFI.",
|
||||
"busyTitle": "La VM ne démarre pas : \"hostpciN: device busy\"",
|
||||
"busyBody": "Un autre processus utilise encore le périphérique PCI. Les causes courantes sont une VM ayant planté sans le libérer ou le noyau de l’hôte l’ayant repris au dernier démarrage. Exécutez <code>lspci -nnk -s <addr></code> pour identifier le pilote associé ; il devrait s’agir de <code>vfio-pci</code>. Un redémarrage complet de l’hôte résout généralement le problème.",
|
||||
"noDisksTitle": "Invité voit le contrôleur mais pas les disques",
|
||||
"noDisksBody": "Le système invité ne dispose pas du pilote de ce contrôleur. Ce cas est rare sous Linux, mais se présente sous Windows : installez le pilote du fabricant, par exemple LSI/Broadcom pour les anciens HBA SAS, lorsque la carte n’est pas affectée, puis redémarrez avec la carte affectée.",
|
||||
"sharedTitle": "Le groupe IOMMU contient un périphérique sans rapport",
|
||||
"sharedBody": "Options : (a) déplacer la carte vers un autre emplacement PCIe pour changer son groupe, (b) activer <em>ACS override</em> dans le noyau pour diviser les groupes (compromis de sécurité : se renseigner avant de l’appliquer), ou (c) choisir une autre carte dans un groupe mieux isolé."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Importer le disque vers la VM",
|
||||
"tail": "— modèle alternatif: attachez un disque physique via Proxmox sans passage PCIe complet."
|
||||
},
|
||||
{
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"label": "Ajouter GPU à VM (Passthrough)",
|
||||
"tail": "— les mêmes concepts IOMMU/VFIO appliqués à un GPU."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/gpu-commands",
|
||||
"label": "commandes GPU Passthrough",
|
||||
"tail": "— Les commandes de vérification IOMMU s'appliquent également au contrôleur / NVMe passant."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,142 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Formater ou effacer un disque physique | Documentation ProxMenux",
|
||||
"description": "Effacez et formatez les disques physiques sur Proxmox VE avec ProxMenux. Quatre modes, des filtres stricts excluant les disques système, montés ou utilisés, et une double confirmation avec saisie du chemin complet.",
|
||||
"ogTitle": "Formater ou effacer un disque physique | Documentation ProxMenux",
|
||||
"ogDescription": "Effacez ou formatez un disque physique sur Proxmox. Filtres de sécurité, quatre modes et double confirmation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Formater ou effacer un disque physique",
|
||||
"description": "Effacez ou formatez un disque physique sur l’hôte Proxmox. ProxMenux ne montre que les disques entièrement libres : aucun usage par le système, aucune référence dans les invités et aucun montage. Il impose une double confirmation, oui/non puis saisie du chemin complet du disque, avant toute destruction de données.",
|
||||
"section": "Gestionnaire de disques · Utilitaires"
|
||||
},
|
||||
"danger": {
|
||||
"title": "Outil destructif",
|
||||
"body": "Chaque opération ici écrit sur le disque. Il n'y a pas d'annulation. ProxMenux applique des filtres de sécurité stricts et des confirmations, mais la responsabilité de choisir le bon disque est à vous. Lisez le chemin du disque deux fois avant de le taper."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le processus comporte deux phases séparées par un filtre de sécurité à trois contrôles. La première recueille le choix du disque, le mode et les détails du système de fichiers. Aucune écriture n’a lieu avant la validation finale de la seconde phase, juste avant l’exécution."
|
||||
},
|
||||
"visibility": {
|
||||
"heading": "Règles de visibilité",
|
||||
"intro": "Avant même que le menu apparaisse, ProxMenux filtre la liste des disques. Seuls les candidats qui sont en sécurité sont présentés :",
|
||||
"items": [
|
||||
"<strong>Affichés</strong> : les disques <em>non</em> utilisés par l’hôte (pool racine, swap, montages, ZFS/LVM/RAID actifs) et <em>non</em> référencés dans une configuration VM/LXC, que l’invité soit démarré ou arrêté.",
|
||||
"<strong>Masqués</strong> : disques de l’hôte et du système.",
|
||||
"<strong>Masqués</strong> : disques référencés dans une configuration VM/LXC."
|
||||
],
|
||||
"safetyTitle": "Sécurité lors de la confirmation et de l'exécution",
|
||||
"safetyItems": [
|
||||
"Les disques contenant des métadonnées anciennes ou actives déclenchent des avertissements détaillés <em>avant</em> la confirmation.",
|
||||
"Les disques utilisés par une VM <strong>en cours d’exécution</strong> sont <strong>strictement bloqués</strong> à la confirmation.",
|
||||
"Les disques comportant des partitions montées sont <strong>strictement bloqués</strong> à l’exécution. Une nouvelle validation a lieu juste avant toute écriture.",
|
||||
"Deux confirmations sont toujours nécessaires : un dialogue <em>oui/non</em> et la saisie exacte du chemin complet du disque."
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Modes de fonctionnement",
|
||||
"intro": "Après avoir choisi un disque, vous choisissez l'un des quatre modes. Ils diffèrent dans ce qu'ils détruisent et ce qu'ils laissent derrière eux:",
|
||||
"headerMode": "Mode",
|
||||
"headerPart": "Table de partitions",
|
||||
"headerData": "Données",
|
||||
"headerUseCase": "Cas d'utilisation",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "1. Tout effacer",
|
||||
"part": "Détruite",
|
||||
"data": "Signatures effacées",
|
||||
"useCase": "Supprime la table de partitions et les métadonnées de système de fichiers et RAID, met à zéro les 16 premiers et derniers Mio et, sur les disques qui prennent en charge discard, applique un TRIM à tout le disque. Le reste des données n’est pas écrasé et peut encore être récupérable sur un HDD ; ce n’est pas un effacement sécurisé."
|
||||
},
|
||||
{
|
||||
"mode": "2. Supprimer les étiquettes FS",
|
||||
"part": "Préservé",
|
||||
"data": "Préservé",
|
||||
"useCase": "Supprime les anciennes signatures ZFS / LVM / RAID pour empêcher la prise en charge automatique du disque. Les données utilisateur ne sont pas écrasées en bloc, mais la suppression des signatures peut les rendre inaccessibles."
|
||||
},
|
||||
{
|
||||
"mode": "3. Écraser les données avec des zéros",
|
||||
"part": "Préservé",
|
||||
"data": "Détruites (écrasées par des zéros)",
|
||||
"useCase": "Écraser les partitions existantes avec des zéros en conservant la table de partitions. Les espaces non alloués et les zones de réserve des SSD ne sont pas couverts ; cela ne garantit pas un assainissement complet du périphérique."
|
||||
},
|
||||
{
|
||||
"mode": "4. Format complet",
|
||||
"part": "Nouvelle GPT",
|
||||
"data": "Détruite",
|
||||
"useCase": "Disque prêt à utiliser avec une seule nouvelle partition et un nouveau système de fichiers."
|
||||
}
|
||||
],
|
||||
"fullFormatOutro": "<strong>Format complet</strong> continue avec deux dialogues supplémentaires:",
|
||||
"fullFormatItems": [
|
||||
"<strong>Système de fichiers</strong> : <code>ext4</code>, <code>xfs</code>, <code>exfat</code> (portable) ou <code>btrfs</code>. Si un outil manque, par exemple <code>mkfs.btrfs</code>, l’opération s’arrête avec un message explicite.",
|
||||
"<strong>Étiquette</strong> : nom facultatif du système de fichiers pour l’identifier."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir un disque libre",
|
||||
"body": "ProxMenux liste les disques qui passent les filtres ci-dessus. Ceux marqués ⚠ contiennent d’anciennes métadonnées dont les détails sont affichés pour vous indiquer ce que vous allez écraser."
|
||||
},
|
||||
{
|
||||
"title": "Choisir un mode d'opération",
|
||||
"bodyRich": "Choisissez <strong>Tout effacer</strong>, <strong>Supprimer les étiquettes FS</strong>, <strong>Écraser les données avec des zéros</strong> ou <strong>Format complet</strong> selon le tableau ci-dessus."
|
||||
},
|
||||
{
|
||||
"title": "(Format complet seulement) Choisir le système de fichiers et l'étiquette",
|
||||
"body": "ext4 / xfs / exfat / btrfs, plus une étiquette en option."
|
||||
},
|
||||
{
|
||||
"title": "Confirmer deux fois",
|
||||
"bodyRich": "ProxMenux présente un résumé de ce qui va se passer. Vous acceptez avec une boîte de dialogue oui/non et <strong> tapez le chemin complet du disque</strong> exactement comme indiqué (par exemple <code>/dev/sdc</code>). Tout le reste avorte."
|
||||
},
|
||||
{
|
||||
"title": "Revalidation et exécution",
|
||||
"body": "Juste avant d'écrire, le script revérifie l'état du disque. Si une partition a été montée ou un VM a commencé dans l'intervalle, l'exécution est interrompue. Sinon, l'opération choisie tourne et un résumé est imprimé à la fin."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalents manuels",
|
||||
"body": "Si vous préférez exécuter les commandes équivalentes à la main :"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"notListedTitle": "Disque non listé dans le menu",
|
||||
"notListedBody": "Il a été filtré pour la sécurité. Raisons courantes : il est monté (même à <code>/mnt/tmp</code>), il est un membre actif ZFS / LVM / RAID, il est référencé par une config VM ou LXC, ou c'est votre disque racine Proxmox. Exécutez <code>lsblk -f</code> et <code>cat /proc/mdstat</code> sur l'hôte pour comprendre pourquoi.",
|
||||
"busyTitle": "\"Disk may be busy\" / échec du démontage",
|
||||
"busyBody": "Quelque chose tient toujours un fichier ouvert sur une partition de ce disque — le plus souvent un conteneur ou un shell dont cwd est à l'intérieur d'un point de montage. Identifiez-le avec <code>lsof | grep /dev/sdX</code> ou <code>fuser -vm /dev/sdX1</code>, arrêtez-le, puis lancez l'outil."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/smart-disk-test",
|
||||
"label": "Santé et test du disque SMART",
|
||||
"tail": "— vérifier un disque avant / après l'essuyage pour confirmer qu'il est sain."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Importer le disque vers la VM",
|
||||
"tail": "— passer un disque fraîchement formaté à un VM."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Ajouter le disque local comme stockage Proxmox",
|
||||
"tail": " — enregistrer un disque essuyé comme stockage Proxmox pool."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Commandes de stockage et de disques",
|
||||
"tail": " — référence de lsblk, blkid et parted."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Importer une image disque dans une VM | Documentation ProxMenux",
|
||||
"description": "Importez un fichier image disque (.img / .qcow2 / .vmdk / .raw) dans une VM Proxmox existante avec ProxMenux. Interface, émulation SSD et option de démarrage par image, avec qm importdisk en arrière-plan.",
|
||||
"ogTitle": "Importer une image disque dans une VM | Documentation ProxMenux",
|
||||
"ogDescription": "Importer des images disque .img / .qcow2 / .vmdk / .raw dans un VM existant avec ProxMenux. Utilise qm importdisk sous le capot."
|
||||
},
|
||||
"header": {
|
||||
"title": "Importer l'image disque vers la VM",
|
||||
"description": "Importer un fichier image disque (.img, .qcow2, .vmdk ou .raw) dans un Proxmox VM existant. ProxMenux recueille toutes les décisions dès le départ — cible VM, stockage Proxmox, répertoire source, interface, émulation SSD, ordre de démarrage — et exécute ensuite qm importdisk pour chaque image sélectionnée.",
|
||||
"section": "Gestionnaire de disque · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Contrairement à <em>Importer le disque vers la VM</em>, qui affecte un disque physique brut, ce processus utilise un <strong>fichier</strong> sur l’hôte, exporté d’un autre hyperviseur, téléchargé comme image cloud ou extrait d’une sauvegarde. Il le convertit en disque de VM Proxmox sur le stockage choisi. L’original est conservé : ProxMenux le copie sans le déplacer."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le flux a deux phases. La phase 1 recueille toutes les décisions (VM, stockage, répertoire source, images, options par image) directement via des dialogues. La phase 2 exécute <code>qm importdisk</code> pour chaque image sélectionnée. Jusqu'à ce que la phase 2 commence, rien n'est copié et la configuration VM n'est pas touchée."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Préalables",
|
||||
"items": [
|
||||
"Au moins une VM est définie sur l’hôte. La VM cible doit être <strong>éteinte</strong>.",
|
||||
"Au moins un fichier image d'un format pris en charge dans le répertoire source. Prise en charge: <code>.img</code>, <code>.qcow2</code>, <code>.vmdk</code>, <code>.raw</code>.",
|
||||
"Assez d'espace libre sur le stockage Proxmox cible pour tenir chaque disque importé.",
|
||||
"ProxMenux recherche des images dans <code>/var/lib/vz/template/iso</code> par défaut. Vous pouvez le pointer vers n'importe quel autre répertoire de l'hôte quand il le demande."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir la VM cible",
|
||||
"bodyRich": "ProxMenux lit <code>qm list</code> et affiche chaque VM. Choisissez celui qui recevra le ou les disques importés."
|
||||
},
|
||||
{
|
||||
"title": "Choisir le stockage Proxmox",
|
||||
"bodyRich": "La liste contient chaque stockage qui a le type de contenu <code>images</code> activé. S'il n'y a qu'un seul candidat, il est sélectionné automatiquement et le dialogue est ignoré."
|
||||
},
|
||||
{
|
||||
"title": "Choisir le répertoire source",
|
||||
"bodyRich": "Choisissez le répertoire par défaut (<code>/var/lib/vz/template/iso</code>) ou saisissez un autre chemin, généralement celui où vous avez téléchargé ou envoyé l’image. Le script refuse les chemins inexistants."
|
||||
},
|
||||
{
|
||||
"title": "Choisissez une ou plusieurs images",
|
||||
"bodyRich": "Le répertoire est scanné pour les fichiers <code>.img</code> / <code>.qcow2</code> / <code>.vmdk</code> / <code>.raw</code>. Vous pouvez en sélectionner plusieurs à la fois; chacun d'eux passera par les options par image dans la prochaine étape."
|
||||
},
|
||||
{
|
||||
"title": "Options par image",
|
||||
"intro": "Pour chaque image sélectionnée ProxMenux demande:",
|
||||
"items": [
|
||||
"<strong>Interface</strong> — <code>scsi</code> (par défaut), <code>virtio</code>, <code>sata</code> ou <code>ide</code>. Correspond à la façon dont l'invité verra le disque.",
|
||||
"<strong>Émulation SSD</strong> : proposée uniquement pour les interfaces autres que VirtIO. Ajoute <code>ssd=1</code> pour que l’invité reconnaisse un disque SSD. La prise en charge de discard/TRIM doit être configurée séparément.",
|
||||
"<strong>Amorçable</strong> : si vous répondez oui, ProxMenux place le disque en tête de l’ordre de démarrage de la VM."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Importer et connecter",
|
||||
"bodyRich": "ProxMenux exécute <code>qm importdisk</code> pour chaque image, en convertissant le format si nécessaire. Il connecte le disque au prochain emplacement libre (<code>scsiN</code>, <code>sataN</code>, …) avec les options choisies et met à jour l’ordre de démarrage si un disque a été marqué comme amorçable. La progression s’affiche dans le terminal."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "L’importation d’une seule image correspond à trois commandes <code>qm</code> :",
|
||||
"warnTitle": "Conversion du format d'image",
|
||||
"warnBody": "Lorsque le stockage cible ne peut pas contenir le format source nativement (par exemple, le stockage LVM ne peut pas contenir <code>.qcow2</code>), <code>qm importdisk</code> convertit l'image de manière transparente. Cela peut prendre plusieurs minutes pour les images multi-GB; planifier en conséquence et ne pas interrompre le script."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noImagesTitle": "\"Aucune image disque compatible trouvée\"",
|
||||
"noImagesBody": "Le script n’a trouvé aucun fichier <code>.img</code>, <code>.qcow2</code>, <code>.vmdk</code> ou <code>.raw</code>. Vérifiez la casse de l’extension, la présence du fichier directement dans le répertoire choisi (les sous-répertoires ne sont pas parcourus) et les droits de lecture de root.",
|
||||
"slowTitle": "L'importation est lente",
|
||||
"slowBody": "Les conversions entre VMDK, QCOW2 et raw peuvent être limitées par le CPU et les entrées-sorties. La vitesse dépend des lectures à la source, des écritures à destination et de la décompression éventuelle. Préférez des sources raw ou qcow2 si possible.",
|
||||
"uefiTitle": "Le disque importé démarre dans le shell UEFI",
|
||||
"uefiBody": "L’image a été créée pour le mode hérité (SeaBIOS), mais la VM utilise OVMF, ou inversement. Changez le BIOS de la VM dans Proxmox pour correspondre à l’image, ou recréez l’image dans le bon mode avant l’importation."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Importer le disque vers la VM",
|
||||
"tail": "— même flux mais pour les disques physiques bruts (passthrough)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/utils/import-vm",
|
||||
"label": "Importer VM de OVA / OVF",
|
||||
"tail": "— lorsque vous avez un paquet complet VM, pas seulement une image de disque."
|
||||
},
|
||||
{
|
||||
"href": "/docs/utils/UUp-Dump-ISO-Creator",
|
||||
"label": "Créateur d’ISO UUP Dump",
|
||||
"tail": "— générer une ISO Windows si vous en avez besoin pour une nouvelle installation."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Commandes de stockage et de disques",
|
||||
"tail": " — référence de qm importdisk et qemu-img convert."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,115 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Importer le disque vers LXC | ProxMenux Documentation",
|
||||
"description": "Joindre un disque physique à un conteneur LXC existant sur Proxmox VE en utilisant ProxMenux. Gestion de la détection de système de fichiers / formatage, point de montage, non privilégié → conversion privilégiée et chemins de périphériques persistants.",
|
||||
"ogTitle": "Importer le disque vers LXC | ProxMenux Documentation",
|
||||
"ogDescription": "Connectez un disque physique à un conteneur LXC existant. Gestion du système de fichiers, du point de montage et de la conversion de non privilégié à privilégié."
|
||||
},
|
||||
"header": {
|
||||
"title": "Importer un disque vers LXC",
|
||||
"description": "Connectez un disque physique à un conteneur LXC existant sur l’hôte Proxmox. ProxMenux détecte les disques libres, propose de les formater avec un système de fichiers pris en charge, puis relie la partition à un point de montage dans le conteneur à l’aide de chemins de périphériques persistants.",
|
||||
"section": "Gestionnaire de disque · LXC"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Passthrough VM vs Passthrough LXC",
|
||||
"body": "Ce passthrough LXC <strong>ne fournit pas un périphérique bloc brut</strong>. Le conteneur reçoit un <em>point de montage</em>, c’est-à-dire un répertoire reposant sur une partition choisie sur l’hôte. Contrairement à une VM, il utilise le noyau de l’hôte ; le système de fichiers (ext4/xfs/btrfs) est donc lu et géré par l’hôte Proxmox puis exposé au conteneur."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le processus comporte deux phases distinctes : collecte des informations et des choix, puis modification effective de la configuration du conteneur. Rien n’est monté dans le CT avant la confirmation finale.",
|
||||
"summary": "ProxMenux exclut le disque racine, les disques montés et ceux référencés dans une configuration VM/LXC. Les membres actifs de ZFS/LVM/RAID sont masqués ; les anciennes signatures portent un symbole ⚠ pour pouvoir les effacer avant le formatage."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Préalables",
|
||||
"items": [
|
||||
"Au moins un conteneur LXC défini sur l'hôte.",
|
||||
"Le conteneur est <strong>privilégié</strong>, ou vous acceptez la conversion proposée par le script.",
|
||||
"Au moins un disque physique non utilisé par l'hôte ou tout autre invité."
|
||||
],
|
||||
"warnTitle": "Conteneur privilégié requis",
|
||||
"warnBody": "Ce script exige un conteneur <strong>privilégié</strong> pour connecter directement le disque. S’il détecte <code>unprivileged: 1</code>, il propose de modifier <code>/etc/pve/lxc/<CTID>.conf</code> sur place. Cela change le modèle de sécurité sans remapper les propriétaires des fichiers existants. Sauvegardez le conteneur et vérifiez les propriétaires avant d’accepter, ou recréez-le en mode privilégié."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir le conteneur cible",
|
||||
"img": "/disk/select-container.png",
|
||||
"caption": "Menu de sélection des conteneurs",
|
||||
"bodyRich": "ProxMenux liste tous les conteneurs LXC de l’hôte (<code>pct list</code>). Choisissez celui qui recevra le disque. S’il est non privilégié, le script propose de le convertir maintenant."
|
||||
},
|
||||
{
|
||||
"title": "Choisir le disque physique",
|
||||
"img": "/disk/disk-selection-ct.png",
|
||||
"caption": "Disques libres détectés sur l’hôte, avec ⚠ pour les anciennes métadonnées",
|
||||
"bodyRich": "Seuls les candidats sûrs sont affichés. Contrairement au processus pour VM, ce script connecte <strong>un disque par exécution</strong>. Relancez-le pour chaque disque supplémentaire."
|
||||
},
|
||||
{
|
||||
"title": "Formater ou réutiliser",
|
||||
"intro": "Le script inspecte le disque :",
|
||||
"items": [
|
||||
"S'il porte déjà un système de fichiers supporté (ext4 / xfs / btrfs), vous pouvez le réutiliser tel quel (les fichiers existants sont conservés).",
|
||||
"S'il n'a pas de système de fichiers pris en charge, vous êtes offert pour le formater. Choisir ext4 / xfs / btrfs."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Choisir le point de montage",
|
||||
"bodyRich": "Tapez le chemin où le conteneur doit voir le disque, par exemple. <code>/mnt/data</code> ou <code>/mnt/disk_passthrough</code>. C'est le chemin <em>dans le conteneur</em> ; l'hôte voit déjà la partition sous <code>/dev/disk/by-id/…</code>."
|
||||
},
|
||||
{
|
||||
"title": "Connecter et vérifier",
|
||||
"img": "/disk/assignment-ct.png",
|
||||
"caption": "Attribution à CT",
|
||||
"bodyRich": "ProxMenux ajoute une nouvelle entrée <code>mpN:</code> à la configuration du conteneur, saute les index déjà utilisés et relise la configuration pour la confirmer. Si le conteneur est en cours d'exécution, le montage est en direct; sinon, il prend effet au prochain départ.",
|
||||
"extraImg": "/disk/result-point.png",
|
||||
"extraAlt": "Point de montage créé avec succès",
|
||||
"extraCaption": "Point de montage créé et vérifié"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Le script enveloppe <code>pct set</code>. Une invocation directe pour un seul disque ressemble à :"
|
||||
},
|
||||
"important": {
|
||||
"heading": "Considérations importantes",
|
||||
"items": [
|
||||
"<strong>Un disque par exécution</strong>. Relancez le script pour chaque disque supplémentaire.",
|
||||
"Ne connectez <strong>pas</strong> la même partition à plusieurs conteneurs susceptibles de la monter simultanément : les écritures concurrentes corrompent le système de fichiers.",
|
||||
"<strong>Les anciennes métadonnées</strong> (signature RAID / ZFS / LVM) doivent être effacées manuellement avant que le script ne vous laisse formater, sinon <code>mkfs</code> refuse d'écraser. Utilisez l'outil <wipeLink>Format / Wipe Physical Disk</wipeLink> pour cela."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"unprivTitle": "\"Ne peut pas continuer avec un conteneur non privilégié\"",
|
||||
"unprivBody": "Vous avez refusé la conversion : le script s’est arrêté sans rien modifier. Pour continuer, relancez-le et acceptez : le script arrête le conteneur, sauvegarde sa configuration dans <code>/etc/pve/lxc/<CTID>.conf.bak</code> et remplace <code>unprivileged: 1</code> par <code>unprivileged: 0</code>. Ce changement ne convertit pas à lui seul les UID/GID des fichiers existants ; sauvegardez donc d’abord le conteneur et corrigez les propriétaires, ou restaurez ou recréez-le en mode privilégié.",
|
||||
"permsTitle": "Les autorisations à l'intérieur du conteneur sont erronées",
|
||||
"permsBody": "Le montage dans un conteneur privilégié conserve les propriétaires des fichiers existants ; un système de fichiers neuf appartient souvent à <code>root:root</code>. Si le service utilise un autre compte, par exemple <code>www-data</code> pour Nextcloud, vérifiez son UID/GID et ajustez les fichiers nécessaires avec <code>chown</code>/<code>chmod</code>. Ces changements affectent aussi le disque sous-jacent."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Importer le disque vers la VM",
|
||||
"tail": " — processus équivalent pour les VM."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Points de montage LXC (hôte ↔ CT)",
|
||||
"tail": "— partager les répertoires hôtes avec un CT au lieu de fixer un disque entier."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/vm-ct-commands",
|
||||
"label": "Commandes de gestion VM et CT",
|
||||
"tail": "— pct config / push / pull reference."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Importer le disque vers VM | ProxMenux Documentation",
|
||||
"description": "Connectez un disque physique à une VM Proxmox existante avec ProxMenux. Détection excluant les disques système, montés, utilisés ou membres actifs ZFS/RAID/LVM, chemins persistants /dev/disk/by-id et interfaces SATA / SCSI / VirtIO / IDE.",
|
||||
"ogTitle": "Importer le disque vers VM | ProxMenux Documentation",
|
||||
"ogDescription": "Joindre un disque physique à un Proxmox VM existant. Utilise des chemins de /dev/disk/by-id persistants et prend en charge SATA / SCSI / VirtIO / IDE."
|
||||
},
|
||||
"header": {
|
||||
"title": "Importer le disque vers la VM",
|
||||
"description": "Joindre un disque physique qui existe déjà sur l'hôte Proxmox à une machine virtuelle existante. ProxMenux détecte les disques libres, vous permet de choisir la cible VM, le type de bus (SATA / SCSI / VirtIO / IDE) et fixe tout en utilisant des chemins de /dev/disk/by-id persistants afin que la cartographie survive aux reboots et aux changements d'ordre des appareils.",
|
||||
"section": "Gestionnaire de disque · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Cette méthode utilise un disque physique brut comme support d’une interface de disque virtuel. L’invité ne reçoit pas automatiquement les données SMART natives ni les fonctions du contrôleur physique ; utilisez le passthrough PCI du contrôleur si elles sont nécessaires. Le disque est connecté via son chemin <code>/dev/disk/by-id/…</code> lorsqu’il existe, pour préserver l’affectation si l’ordre des périphériques change au démarrage ; sinon, <code>/dev/sdX</code> est utilisé."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le processus comporte deux phases distinctes : collecte des informations et des choix, puis connexion des disques à la VM. La configuration reste inchangée jusqu’à la confirmation finale.",
|
||||
"summary": "ProxMenux exclut les candidats non sûrs : disque racine, disques montés sur l’hôte, membres actifs ZFS/LVM/RAID et disques référencés dans une configuration VM/LXC. Ceux comportant d’<em>anciennes</em> métadonnées ZFS/RAID/LVM inutilisées sont marqués ⚠, sans être bloqués."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Préalables",
|
||||
"items": [
|
||||
"Au moins un VM défini sur l'hôte (le script envoie directement à <code>qm list</code>).",
|
||||
"La <strong>VM cible est éteinte</strong>. Si elle fonctionne, le script s’arrête avec un message ; l’ajout à chaud de disques n’est pas pris en charge par ce processus.",
|
||||
"Au moins un disque physique sur l'hôte qui n'est pas utilisé par l'hôte ou tout autre invité."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir la VM cible",
|
||||
"bodyRich": "ProxMenux liste toutes les VM de l’hôte avec <code>qm list</code>. Choisissez celle qui recevra le disque. Si elle fonctionne, le script s’arrête et demande de l’éteindre d’abord."
|
||||
},
|
||||
{
|
||||
"title": "Choisissez le ou les disques physiques à attacher",
|
||||
"img": "/disk/disk-selection.png",
|
||||
"caption": "Disques libres détectés sur l’hôte, avec ⚠ pour les anciennes métadonnées",
|
||||
"body": "Le script examine les disques de l’hôte et ne propose que ceux pouvant être connectés sans conflit. La liste permet d’en sélectionner plusieurs. Les disques avec d’anciennes signatures ZFS/LVM/RAID restent affichés avec ⚠ pour indiquer qu’il faut effacer ces signatures avant leur formatage par l’invité."
|
||||
},
|
||||
{
|
||||
"title": "Choisissez l'interface du bus",
|
||||
"img": "/disk/disk-assigment.png",
|
||||
"caption": "Sélection de l'interface de bus",
|
||||
"intro": "Choisissez comment l'invité devrait voir le disque:",
|
||||
"items": [
|
||||
"<strong>SCSI</strong> — par défaut moderne pour Linux et Windows avec les pilotes VirtIO-SCSI installés.",
|
||||
"<strong>SATA</strong> — large compatibilité, fonctionne hors de la boîte sur presque tous les invités.",
|
||||
"<strong>VirtIO</strong> : périphérique bloc paravirtualisé efficace ; nécessite des pilotes dans l’invité.",
|
||||
"<strong>IDE</strong> — pour les anciens clients qui n'ont aucun des pilotes ci-dessus."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Connecter et vérifier",
|
||||
"bodyRich": "ProxMenux attache chaque disque sélectionné avec son meilleur chemin <code>/dev/disk/by-id/</code>, saute les index des fentes qui sont déjà utilisés dans la config VM (<code>scsi0</code>, <code>sata0</code>, ...) et relis la config pour confirmer l'assignation. Un résumé est imprimé à la fin."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Le script est un wrapper autour de <code>qm set</code>. La commande exacte pour un seul disque ressemble à ceci :",
|
||||
"migrationTitle": "La migration à chaud est impossible",
|
||||
"migrationBody": "Une VM avec un disque physique connecté directement est <strong>liée à l’hôte qui expose ce disque</strong>. Un autre nœud ne dispose généralement ni du même chemin <code>/dev/disk/by-id/…</code> ni des données. Sauvegardez et transférez ces données séparément, ou utilisez des disques virtuels gérés sur stockage partagé ou avec réplication prise en charge. Ne supposez pas que la réplication Proxmox couvre ce périphérique.",
|
||||
"shareTitle": "Ne partagez pas de disque physique entre VMs",
|
||||
"shareBody": "La fixation du même disque physique à deux VMs en même temps corrompra les données sur l'écriture suivante. ProxMenux détecte cette situation et la bloque, mais si vous contournez le script (direct <code>qm set</code>), assurez-vous qu'un seul invité monte le disque."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noDisksTitle": "\"Aucun disque disponible pour ce VM\"",
|
||||
"noDisksIntro": "Le script a trouvé des disques, mais chaque candidat a été filtré. Raisons communes:",
|
||||
"noDisksItems": [
|
||||
"Chaque disque restant est déjà référencé dans la configuration de la cible VM.",
|
||||
"Chaque disque restant est monté sur l'hôte ou fait partie d'un ZFS / LVM / RAID actif.",
|
||||
"L'hôte a seulement le disque racine installé."
|
||||
],
|
||||
"noDisksOutro": "Exécutez <code>lsblk -f</code> sur l'hôte pour examiner l'état de chaque disque.",
|
||||
"noVisibleTitle": "VM ne voit pas le disque après le démarrage",
|
||||
"noVisibleBody": "Si vous avez choisi <strong>SCSI</strong> ou <strong>VirtIO</strong>, l'invité a besoin du pilote correspondant. Sur Linux qui est natif du noyau; sur Windows vous avez besoin de l'ISO VirtIO et d'un pilote d'installation (voir la page <winLink>Créer VM: Système Windows</winLink>). Le passage à SATA dans l'onglet matériel du VM est une solution rapide pour confirmer que le disque est physiquement attaché."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-image-vm",
|
||||
"label": "Importer l'image disque vers la VM",
|
||||
"tail": " — même processus pour les fichiers image (qcow2 / vmdk / raw / img)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-lxc",
|
||||
"label": "Importer un disque vers LXC",
|
||||
"tail": " — processus équivalent pour les conteneurs LXC."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"label": "Ajouter un contrôleur ou un NVMe à une VM",
|
||||
"tail": "— lorsque vous avez besoin d'un PCIe complet / NVMe passthrough plutôt que le disque attaché."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Commandes de stockage et de disques",
|
||||
"tail": " — référence de qm importdisk et des commandes shell associées."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,135 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Gestionnaire de disques Proxmox : VM/LXC, tests SMART et effacement | ProxMenux",
|
||||
"description": "Gérez les disques physiques d’un hôte Proxmox VE avec ProxMenux : connexion aux VM ou LXC (qm set scsi/sata/virtio, pct mp), import d’images img / qcow2 / vmdk / raw, passthrough de HBA ou contrôleurs NVMe complets, effacement avec contrôles de sécurité et autotests SMART.",
|
||||
"ogTitle": "Gestionnaire de disques Proxmox : VM/LXC, tests SMART et effacement",
|
||||
"ogDescription": "Connecter des disques aux VM/LXC, importer des images, utiliser le passthrough PCI des contrôleurs, effacer avec contrôles de sécurité et lancer des tests SMART sur Proxmox VE.",
|
||||
"twitterTitle": "Gestionnaire de disques Proxmox | ProxMenux",
|
||||
"twitterDescription": "Connexion de disques aux VM/LXC, import d’images, passthrough PCI, effacement avec contrôles de sécurité et tests SMART."
|
||||
},
|
||||
"header": {
|
||||
"title": "Gestionnaire de disque",
|
||||
"description": "Le menu Gestionnaire de disques regroupe les outils ProxMenux pour les disques physiques de l’hôte : connexion aux VM et LXC, import d’images, passthrough d’un contrôleur complet ou d’un périphérique NVMe, effacement avec contrôles de sécurité et tests SMART.",
|
||||
"section": "Gestionnaire de disque"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce menu sert à",
|
||||
"body": "Ces outils utilisent les <strong>disques physiques visibles par l’hôte Proxmox et les fichiers image qui y sont stockés</strong>. Le menu comporte trois groupes : <strong>VM</strong> (connexion de disques ou import d’images), <strong>LXC</strong> (connexion à un conteneur) et <strong>Utilitaires</strong> (formatage et état SMART). Les opérations de connexion et d’effacement masquent ou bloquent les disques système et utilisés ; SMART peut les examiner sans les effacer."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture du menu",
|
||||
"body": "Dans le menu principal de ProxMenux, sélectionnez <strong>Disk Manager</strong>. Vous verrez ceci :",
|
||||
"imageAlt": "Menu Gestionnaire de disque avec blocs VM, LXC et Utilitaires"
|
||||
},
|
||||
"groups": {
|
||||
"heading": "Trois groupes d'outils",
|
||||
"intro": "Le menu est organisé en trois groupes : <strong>VM</strong>, <strong>LXC</strong> et <strong>Utilitaires</strong>. Cliquez sur une carte pour accéder directement aux outils du groupe.",
|
||||
"vmTitle": "VM",
|
||||
"vmBody": "Outils qui fonctionnent sur des machines virtuelles existantes. Le VM doit être éteint; ProxMenux le valide avant de toucher la configuration.",
|
||||
"vmItems": [
|
||||
"Importer le disque vers la VM",
|
||||
"Importer l'image disque vers la VM",
|
||||
"Ajouter un contrôleur ou un NVMe à une VM"
|
||||
],
|
||||
"lxcTitle": "LXC",
|
||||
"lxcBody": "Outils pour conteneurs LXC existants. Ce script exige un conteneur privilégié et propose de changer le paramètre si nécessaire. Lisez d’abord les précautions sur la conversion et les propriétaires des fichiers sur la page de l’outil.",
|
||||
"lxcItems": [
|
||||
"Importer un disque vers LXC"
|
||||
],
|
||||
"utilitiesTitle": "Utilitaires",
|
||||
"utilitiesBody": "Outils côté hôte qui fonctionnent sur les disques eux-mêmes, indépendamment de tout VM ou conteneur.",
|
||||
"utilitiesItems": [
|
||||
"Formater ou effacer un disque physique",
|
||||
"Santé et test du disque SMART"
|
||||
]
|
||||
},
|
||||
"vm": {
|
||||
"heading": "VM",
|
||||
"intro": "Outils qui fonctionnent sur des machines virtuelles existantes. Le VM doit être éteint; ProxMenux le valide avant de toucher la configuration.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "HardDrive",
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"title": "Importer le disque vers la VM",
|
||||
"description": "Joindre un disque physique non assigné à un VM existant. Prend en charge SATA / SCSI / VirtIO / IDE, utilise des chemins de /dev/disk/by-id persistants."
|
||||
},
|
||||
{
|
||||
"icon": "FileDown",
|
||||
"href": "/docs/disk-manager/import-disk-image-vm",
|
||||
"title": "Importer l'image disque vers la VM",
|
||||
"description": "Importez des images disque (.img / .qcow2 / .vmdk / .raw) dans une VM existante. Processus en deux phases utilisant qm importdisk."
|
||||
},
|
||||
{
|
||||
"icon": "Cpu",
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"title": "Ajouter un contrôleur ou un NVMe à une VM",
|
||||
"description": "Passthrough PCI d’un HBA SATA/SAS complet ou d’un périphérique NVMe à une VM. Gestion de l’activation d’IOMMU et de la détection des conflits."
|
||||
}
|
||||
]
|
||||
},
|
||||
"lxc": {
|
||||
"heading": "LXC",
|
||||
"intro": "Outils pour conteneurs LXC existants. Ce script exige un conteneur privilégié et propose de changer le paramètre si nécessaire. Lisez d’abord les précautions sur la conversion et les propriétaires des fichiers sur la page de l’outil.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Boxes",
|
||||
"href": "/docs/disk-manager/import-disk-lxc",
|
||||
"title": "Importer un disque vers LXC",
|
||||
"description": "Joindre un disque physique non assigné à un conteneur LXC existant comme point de montage. Gérer la détection de système de fichiers / format et la conversion privilégiée."
|
||||
}
|
||||
]
|
||||
},
|
||||
"utilities": {
|
||||
"heading": "Utilitaires",
|
||||
"intro": "Outils côté hôte qui fonctionnent sur les disques eux-mêmes, indépendamment de tout VM ou conteneur.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Eraser",
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"title": "Formater/effacer le disque physique (sûr)",
|
||||
"description": "Effacement de disques avec des contrôles stricts : seuls les disques entièrement libres sont affichés et une double confirmation est toujours requise."
|
||||
},
|
||||
{
|
||||
"icon": "Activity",
|
||||
"href": "/docs/disk-manager/smart-disk-test",
|
||||
"title": "Santé et test du disque SMART",
|
||||
"description": "Exécutez des contrôles de santé SMART et des auto-tests courts/longs sur les disques SATA, SAS et NVMe. Exporte JSON pour le moniteur."
|
||||
}
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"title": "Règles de sécurité pour la connexion et l’effacement des disques",
|
||||
"intro": "Les opérations de connexion et d’effacement excluent les périphériques susceptibles de nuire à l’hôte :",
|
||||
"items": [
|
||||
"Le <strong>disque système</strong> et les membres actifs du pool racine, du swap et de ZFS/LVM/RAID sont toujours masqués.",
|
||||
"Les disques <strong> montés</strong> n'importe où sur l'hôte sont cachés ou bloqués lors de l'exécution.",
|
||||
"Les disques <strong> référencés par un VM ou LXC</strong> en cours d'exécution ne peuvent pas être réaffectés ou effacés.",
|
||||
"Les opérations qui peuvent modifier l'état hôte (activer IOMMU, effacer) nécessitent une confirmation explicite."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share",
|
||||
"label": "Gestionnaire de stockage et de partage",
|
||||
"tail": "— enregistrer le stockage dans Proxmox lui-même (NFS / Samba / iSCSI / local) et partager les dossiers entre hôte et CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Commandes de stockage et de disques",
|
||||
"tail": " — référence des périphériques bloc, LVM, pvesm et SMART."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "Commandes de gestion ZFS",
|
||||
"tail": "— pour les pools et ensembles de données ZFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"label": "Ajouter GPU à VM (Passthrough)",
|
||||
"tail": "— les mêmes concepts IOMMU/VFIO appliqués aux GPU."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,146 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "État et tests SMART des disques | Documentation ProxMenux",
|
||||
"description": "Effectuez des contrôles SMART et des tests de disques sur Proxmox VE avec ProxMenux. Prise en charge de SATA/SAS avec smartmontools et de NVMe avec nvme-cli, autotests courts et longs et export JSON pour ProxMenux Monitor.",
|
||||
"ogTitle": "État et tests SMART des disques | Documentation ProxMenux",
|
||||
"ogDescription": "SMART contrôles de santé et auto-tests pour les disques SATA / SAS et NVMe sur Proxmox. Exportation de JSON pour le moniteur."
|
||||
},
|
||||
"header": {
|
||||
"title": "Santé et test du disque SMART",
|
||||
"description": "Lisez les données SMART et lancez des autotests sur les disques physiques de l’hôte Proxmox. ProxMenux installe automatiquement smartmontools pour SATA/SAS et nvme-cli pour NVMe, lance les tests dans le firmware du disque (les tests longs continuent après la fermeture du terminal) et exporte les résultats JSON pour ProxMenux Monitor.",
|
||||
"section": "Gestionnaire de disques · Utilitaires"
|
||||
},
|
||||
"intro": {
|
||||
"title": "C'est pour quoi ?",
|
||||
"body": "SMART (Autosurveillance, analyse et technologie de rapport) permet au lecteur lui-même de signaler sa santé et de faire des auto-tests. Cet outil expose ces données sans que vous ayez besoin de vous souvenir de la bonne invocation <code>smartctl</code> / <code>nvme</code> et persiste la sortie en tant que JSON afin que le moniteur puisse grapher les tendances au fil du temps."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Toutes les actions ici sont non destructives — SMART lit les compteurs de firmware de disque, et les auto-tests sont en attente dans le lecteur lui-même. Aucune séparation de phase n'est nécessaire. Le flux est: vérification de dépendance → sélection de disque → sélection d'action → invocation d'outil (smartctl ou nvme-cli selon le bus disque) → sortie imprimée plus l'exportation de JSON pour le moniteur."
|
||||
},
|
||||
"deps": {
|
||||
"heading": "Dépendances",
|
||||
"body": "L'outil installe automatiquement ce dont il a besoin à la première fois. Les lecteurs SATA / SAS dépendent de <code>smartmontools</code>; les lecteurs NVMe dépendent de <code>nvme-cli</code>. Les deux :"
|
||||
},
|
||||
"actions": {
|
||||
"heading": "Actions disponibles",
|
||||
"headerAction": "Action",
|
||||
"headerWhat": "Ce qu'il lit / exécute",
|
||||
"headerDur": "Durée",
|
||||
"rows": [
|
||||
{
|
||||
"action": "État de santé rapide",
|
||||
"whatRich": "État global PASSED/FAILED et attributs clés.<br /><code>smartctl -H</code> + <code>-A</code> (SATA/SAS) ou <code>nvme smart-log</code> (NVMe).",
|
||||
"dur": "Instantané"
|
||||
},
|
||||
{
|
||||
"action": "Rapport complet",
|
||||
"whatRich": "Données complètes SMART, scrollable. <code>smartctl -x</code> pour SATA/SAS ou <code>nvme smart-log</code> + <code>id-ctrl</code> pour NVMe.",
|
||||
"dur": "Instantané"
|
||||
},
|
||||
{
|
||||
"action": "Essai court",
|
||||
"what": "Contrôle élémentaire de la surface et des circuits, lancé dans le firmware du disque.",
|
||||
"dur": "~2 minutes"
|
||||
},
|
||||
{
|
||||
"action": "Essai long",
|
||||
"what": "Analyse complète de la surface. Elle s’exécute sur le disque et continue même si vous fermez le terminal.",
|
||||
"dur": "Heures (selon la taille du disque)"
|
||||
},
|
||||
{
|
||||
"action": "Vérifier la progression du test",
|
||||
"what": "Statut de l'auto-essai actif ou le plus récent.",
|
||||
"dur": "Instantané"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Les longs essais survivent à la fermeture du terminal",
|
||||
"tipBody": "Un test long s’exécute <em>dans le disque</em> sans dépendre du maintien du processus ProxMenux. Vous pouvez fermer le terminal et revenir à <strong>Vérifier la progression du test</strong>. Un redémarrage de l’hôte, une réinitialisation du contrôleur ou une coupure de courant peut interrompre le test et la collecte des résultats ; ne présumez pas d’une reprise automatique."
|
||||
},
|
||||
"json": {
|
||||
"heading": "Exportation de JSON pour le moniteur",
|
||||
"intro": "Les actions d’état, de test court et de progression écrivent un JSON horodaté dans <code>/usr/local/share/proxmenux/smart/<disk>/</code> ; les résultats des tests longs sont collectés en arrière-plan. Le rapport complet est uniquement affiché. Structure :",
|
||||
"outro": "ProxMenux Monitor utilise ces fichiers pour afficher l’évolution de l’état de chaque disque. Les anciens fichiers sont supprimés automatiquement lorsque la limite de conservation est atteinte."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Étape par étape",
|
||||
"stepLabel": "Étape",
|
||||
"list": [
|
||||
{
|
||||
"title": "Choisir un disque",
|
||||
"body": "ProxMenux répertorie chaque disque physique de l'hôte avec son modèle et sa taille. Contrairement à l'outil Format, cette liste n'est pas filtrée par sécurité — lire SMART est une opération non destructive.",
|
||||
"img": "/disk/smart/disk-selection.png",
|
||||
"alt": "Menu de sélection de disque SMART",
|
||||
"caption": "Menu de sélection de disque SMART"
|
||||
},
|
||||
{
|
||||
"title": "Choisir une action",
|
||||
"body": "Choisissez entre état de santé rapide, rapport complet, test court, test long ou vérifier les progrès. Le menu reste ouvert après chaque action afin que vous puissiez enchaîner plusieurs requêtes contre le même disque.",
|
||||
"img": "/disk/smart/action-menu.png",
|
||||
"alt": "Menu d'action SMART",
|
||||
"caption": "Menu d'action SMART (actions 5 + annulation)"
|
||||
},
|
||||
{
|
||||
"title": "(Test long seulement) Confirmer l'exécution de fond",
|
||||
"body": "ProxMenux indique que le test continuera après la fermeture du terminal et montre où sera enregistré le résultat JSON. Confirmez pour lancer le test.",
|
||||
"img": "/disk/smart/long-test-warning.png",
|
||||
"alt": "Boîte de dialogue de confirmation de test longue",
|
||||
"caption": "Confirmation de test longue — fonctionne en arrière-plan, résultat enregistré en JSON"
|
||||
},
|
||||
{
|
||||
"title": "Examen des résultats",
|
||||
"bodyRich": "L’état, les tests et la progression s’affichent dans le terminal ; <strong>Rapport complet</strong> s’ouvre dans une boîte de dialogue défilante. Le JSON est exporté pour les actions décrites plus haut, sauf Rapport complet. Pour les tests longs, revenez à <strong>Vérifier la progression du test</strong> sur le même disque.",
|
||||
"img": "/disk/smart/quick-status.png",
|
||||
"alt": "État de santé rapide",
|
||||
"caption": "État de santé rapide (SATA — smartctl -H + -A)"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalents manuels",
|
||||
"nvmeWarnTitle": "Les autotests NVMe dépendent du firmware du disque",
|
||||
"nvmeWarnBody": "Chaque lecteur NVMe ne supporte pas la commande d'auto-test courte/long. Si un lecteur refuse le test, le journal SMART et les données du contrôleur ID (<code>nvme smart-log</code> + <code>id-ctrl</code>) sont toujours le signal de santé le plus fiable."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noSmartTitle": "\"Ne pouvait pas lire les données SMART de /dev/sdX\"",
|
||||
"noSmartBody": "Le disque est probablement derrière un contrôleur RAID / SAS qui ne passe pas SMART à travers. Avec des cartes à base de megaraid, essayez <code>smartctl -d megaraid,N /dev/sdX</code>. Pour les HBA en mode IT, l'invocation directe fonctionne.",
|
||||
"longTitle": "Un long test ne se termine jamais",
|
||||
"longBody": "Le disque exécute le test dans son firmware et une forte activité peut le retarder. Essayez pendant une période calme, par exemple la nuit. Pour SATA, <code>smartctl -c</code> indique le pourcentage restant, et pour SAS, <code>smartctl -l selftest</code> ; le journal des autotests contient l’état final et les éventuels LBA en erreur. Une erreur de lecture doit être examinée ; la lenteur seule ne prouve pas un secteur défectueux."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"label": "Formater ou effacer un disque physique",
|
||||
"tail": "— réutiliser un disque après avoir confirmé sa santé."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Commandes de stockage et de disques → État SMART",
|
||||
"tail": "— référence smartctl / nvme."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "Commandes de gestion ZFS",
|
||||
"tail": " — zpool scrub vérifie les sommes de contrôle des données ZFS et complète les tests matériels SMART."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/storage",
|
||||
"label": "ProxMenux Monitor — onglet de stockage",
|
||||
"tail": " — vue détaillée du disque utilisant le JSON exporté ici : table SMART complète, historique et rapport PDF."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/hardware",
|
||||
"label": "ProxMenux Monitor — Onglet matériel",
|
||||
"tail": "— Sommaire de stockage avec modèle, capacité et vitesse de liaison négociée (courant vs maximum sur NVMe)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Aperçu du gestionnaire de disque",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Sauvegarde et redémarrage des interfaces | Documentation ProxMenux",
|
||||
"description": "Capture manuelle, navigation et restauration des sauvegardes /etc/network/interfaces stockées sous /var/backups/proxmenux/. Comprend un redémarrage du service réseau avec confirmation et une vue rapide de la configuration en direct.",
|
||||
"ogTitle": "Sauvegarde et redémarrage des interfaces | Documentation ProxMenux",
|
||||
"ogDescription": "Créez un instantané de la configuration réseau Proxmox et restaurez-la ; redémarrez le service réseau avec confirmation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sauvegarde et redémarrage des interfaces",
|
||||
"description": "Quatre utilitaires qui tournent autour de /etc/network/interfaces: prennent un instantané manuel, visualisent la configuration en direct, restaurent une sauvegarde précédente avec prévisualisation optionnelle et redémarrent le service de réseautage avec un consentement explicite. Même répertoire de sauvegarde utilisé par les flux de réparation guidés.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Gère le même répertoire de sauvegarde utilisé par les flux de réparation guidés (<code>/var/backups/proxmenux/</code>). Permet de prendre un instantané supplémentaire avant tout changement manuel, de parcourir toutes les sauvegardes existantes, et de revenir à l'une d'entre elles — toujours avec une nouvelle sauvegarde pré-restauration prise automatiquement comme deuxième filet de sécurité."
|
||||
},
|
||||
"shared": {
|
||||
"heading": "Le répertoire de sauvegarde partagé",
|
||||
"intro": "Chaque sauvegarde prise n'importe où dans le menu Réseau atterrit au même endroit :",
|
||||
"outro": "Les noms de fichiers sont horodatés, triés par date et jamais écrasés. Le répertoire est créé lors de la première utilisation."
|
||||
},
|
||||
"show": {
|
||||
"heading": "Afficher le fichier de configuration réseau",
|
||||
"body": "Affiche le contenu exact de <code>/etc/network/interfaces</code> dans le terminal. En lecture seule. Utile pour vérifier la configuration avant une sauvegarde ou après une restauration. Il n’existe pas d’outil distinct pour comparer avec la sauvegarde précédente ; examiner le fichier actuel est donc le moyen le plus simple de confirmer son contenu."
|
||||
},
|
||||
"create": {
|
||||
"heading": "Créer une sauvegarde réseau",
|
||||
"body": "Copie le <code>/etc/network/interfaces</code> actuel dans le répertoire de sauvegarde avec un nouvel horodatage. C'est tout — pas d'analyse, pas d'invite, juste un instantané.",
|
||||
"whenTitle": "Quand prendre une sauvegarde manuelle",
|
||||
"whenBody": "Avant de modifier <code>/etc/network/interfaces</code> à la main, d’installer un paquet pouvant toucher la pile réseau (par exemple NetworkManager ou Open vSwitch), ou de changer le matériel. Les réparations guidées créent déjà automatiquement un instantané — cette option sert aux opérations <em>manuelles</em>."
|
||||
},
|
||||
"restore": {
|
||||
"heading": "Restaurer la sauvegarde réseau",
|
||||
"intro": "Liste les sauvegardes de <code>/var/backups/proxmenux/</code>, de la plus récente à la plus ancienne, et guide une restauration avec des garde-fous :",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Choisir une sauvegarde",
|
||||
"body": "Un menu liste chaque sauvegarde par son horodatage. S'il n'y a pas de sauvegardes, le flux sort avec un message clair.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Aperçu facultatif",
|
||||
"body": "Offre d'ouvrir la sauvegarde sélectionnée dans une vue défilante avant de s'engager. Oui par défaut — ne le sautez pas sur un hôte distant.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Sauvegarde avant restauration",
|
||||
"body": "Avant d'écraser <code>/etc/network/interfaces</code>, prend <strong> une autre sauvegarde </strong> de l'état actuel. La restauration d'une sauvegarde est elle-même une action destructrice, de sorte que le nouvel instantané pré-restauration vous permet de revenir si la sauvegarde choisie s'avère être la mauvaise.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer la restauration",
|
||||
"body": "Copie la sauvegarde choisie sur <code>/etc/network/interfaces</code>. Le changement de fichier est sur disque; l'état du noyau en direct reflète toujours la configuration précédente.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Redémarrage facultatif",
|
||||
"body": "Demande s’il faut exécuter <code>systemctl restart networking</code> maintenant. Refusez pour reporter l’application au prochain redémarrage.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"autoBackupTitle": "Une restauration prend sa propre sauvegarde automatiquement",
|
||||
"autoBackupBody": "Sélectionner <em>Restaurer la sauvegarde réseau</em> crée toujours un nouvel instantané de la configuration <em>actuelle</em> avant de l’écraser. Si vous restaurez la mauvaise sauvegarde, le fichier le plus récent dans <code>/var/backups/proxmenux/</code> contient l’état précédent."
|
||||
},
|
||||
"restart": {
|
||||
"heading": "Redémarrer le service réseau",
|
||||
"body": "Exécute <code>systemctl restart networking</code> après confirmation oui/non. Affiche le résultat avec <code>msg_ok</code> / <code>msg_error</code>. La plupart des procédures de ce menu proposent déjà un redémarrage à la fin ; cette option sert après une modification manuelle ou si vous avez refusé le redémarrage proposé auparavant.",
|
||||
"warnTitle": "Brève déconnexion garantie; possibilité de déconnexion permanente",
|
||||
"warnBody": "Redémarrer <code>networking</code> désactive puis reconfigure chaque interface déclarée dans <code>/etc/network/interfaces</code>. Les sessions SSH passant par ces interfaces sont interrompues. Si la nouvelle configuration est invalide, le réseau ne revient pas. N’exécutez cette opération que si :",
|
||||
"warnItems": [
|
||||
"Vous avez la console / IPMI / accès iKVM prêt, <em>ou</em>",
|
||||
"Vous êtes physiquement à côté de la machine, <em> ou</em>",
|
||||
"Vous venez de restaurer avec succès une configuration dont le bon fonctionnement est connu et souhaitez l’appliquer."
|
||||
]
|
||||
},
|
||||
"manualRollback": {
|
||||
"heading": "Retour manuel depuis une console",
|
||||
"intro": "Si vous ne pouvez pas accéder au menu (pas de SSH, plantage de dialog, …) mais disposez d’une console, deux commandes suffisent pour revenir en arrière :",
|
||||
"outro": "C’est la <em>même</em> opération que celle du menu, simplement saisie à la main. Si <code>networking</code> ne démarre toujours pas, consultez <code>journalctl -u networking -b</code> pour identifier l’erreur de syntaxe ou de pilote."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noneTitle": "« Aucune sauvegarde trouvée » lors de la restauration",
|
||||
"noneBody": "Le répertoire <code>/var/backups/proxmenux/</code> n’existe pas ou ne contient aucun fichier <code>interfaces_backup_*</code>. Exécutez <em>Créer une sauvegarde réseau</em> au moins une fois ou lancez une réparation guidée, qui crée automatiquement une sauvegarde. Vérifiez avec <code>ls /var/backups/proxmenux/</code>.",
|
||||
"unreachTitle": "Le redémarrage du réseau réussit, mais l’hôte reste inaccessible",
|
||||
"unreachBody": "La nouvelle configuration est incorrecte ou n’attribue pas votre adresse IP de gestion. Revenez en arrière depuis la console (voir ci-dessus). Utilisez ensuite <bridgeLink>l’analyse des ponts</bridgeLink> et <configLink>l’analyse de configuration</configLink> pour comprendre le problème avant de réappliquer la configuration.",
|
||||
"emptyTitle": "L’aperçu de restauration affiche un fichier vide",
|
||||
"emptyBody": "Le fichier de sauvegarde est vide (0 octet). Cela arrive si une copie a échoué silencieusement lors d’une exécution précédente. Choisissez une sauvegarde plus ancienne ou relancez <em>Créer une sauvegarde réseau</em> maintenant si la configuration actuelle fonctionne."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— la raison la plus courante pour laquelle une sauvegarde se termine ici."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— écrit également à <code>/var/backups/proxmenux/</code> automatiquement."
|
||||
},
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": " — pour vérifier l’état actuel après une restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Analyse des ponts et réparation guidée | Documentation ProxMenux",
|
||||
"description": "Détecte les ponts vmbrX dont les ports physiques sont absents ou invalides, généralement après une réénumération PCI. Les signale avec des commandes shell proposées et offre une réparation guidée en 5 étapes avec sauvegarde obligatoire.",
|
||||
"ogTitle": "Analyse des ponts et réparation guidée | Documentation ProxMenux",
|
||||
"ogDescription": "Vérifiez et réparez les ports des ponts Proxmox après des changements matériels, avec une procédure guidée permettant un retour en arrière sûr."
|
||||
},
|
||||
"header": {
|
||||
"title": "Analyse des ponts et réparation guidée",
|
||||
"description": "Examine chaque pont vmbrX déclaré dans /etc/network/interfaces, vérifie l’existence de ses ports physiques et propose une réparation étape par étape s’ils sont absents. L’analyse est en lecture seule ; la réparation nécessite un accord, présente un aperçu et crée une sauvegarde.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Lit chaque pont dans <code>/etc/network/interfaces</code>, examine sa ligne <code>bridge-ports</code> et vérifie l’existence de chaque port déclaré, par exemple <code>enp3s0</code>, sur l’hôte. Si un port manque, propose un remplacement et applique la modification avec un consentement explicite selon la procédure <strong>sauvegarder, prévisualiser, appliquer, vérifier</strong>."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Quand vous en avez besoin",
|
||||
"intro": "Linux attribue des noms d'interface prévisibles à partir de la topologie PCI et de l'ordre des fentes. Plusieurs événements les mélangent et laissent <code>/etc/network/interfaces</code> se référant à des noms qui n'existent plus :",
|
||||
"items": [
|
||||
"Ajouter ou retirer une carte PCIe (une carte NIC, un GPU, un HBA, un support NVMe).",
|
||||
"Déplacement d'une carte existante vers une autre fente PCIe.",
|
||||
"Mises à jour du BIOS / UEFI qui réénumèrent les périphériques PCI.",
|
||||
"Migrer le disque de démarrage vers différents matériels."
|
||||
],
|
||||
"outro": "Après le prochain démarrage, le pont tente de se fixer à un port qui n'existe plus, ne parvient pas à monter, et l'hôte perd son réseau. <link>Les noms d'interface persistants</link> empêchent cela de se reproduire — mais si vous êtes déjà verrouillé, cette page est le chemin de récupération."
|
||||
},
|
||||
"bigPicture": {
|
||||
"heading": "La situation générale",
|
||||
"diagram1": {
|
||||
"arrowLabel": "étape 1",
|
||||
"nodes": {
|
||||
"sourceLabel": "/etc/network/interfaces",
|
||||
"sourceDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports enp3s0",
|
||||
"bridgeLabel": "Analyser (lecture seule)",
|
||||
"bridgeDetail": "ip link show enp3s0\n→ n’existe pas",
|
||||
"targetLabel": "Rapport + suggestion",
|
||||
"targetDetail": "❌ enp3s0 : INTROUVABLE\nRemplacer par : eno1\n(pas encore de modification)"
|
||||
}
|
||||
},
|
||||
"diagram2": {
|
||||
"arrowLabel": "appliquer avec sauvegarde",
|
||||
"nodes": {
|
||||
"sourceLabel": "Réparation guidée",
|
||||
"sourceDetail": "1. Sauvegarder\n2. Afficher l’état actuel\n3. Prévisualiser les modifications\n4. Appliquer\n5. Vérifier",
|
||||
"targetLabel": "/etc/network/interfaces (nouveau)",
|
||||
"targetDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports eno1"
|
||||
}
|
||||
}
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Étape 1: analyse (lecture seule)",
|
||||
"intro": "Sélectionner <strong>Analyser la configuration des ponts</strong> arrête immédiatement l’outil si l’hôte n’utilise pas la pile classique Debian/Proxmox. Sinon, il examine chaque pont et indique :",
|
||||
"items": [
|
||||
"Nom du pont, état actuel (UP / DOWN), IP assigné.",
|
||||
"Chaque port déclaré et s'il existe actuellement (<code>ip link show <port></code>).",
|
||||
"Pour chaque port invalide : un remplacement proposé (la première interface physique disponible) plus la commande exacte <code>sed</code> pour l'appliquer manuellement.",
|
||||
"Ponts sans <code>bridge-ports</code> du tout et entrées orphelines <code>auto</code> (pas de bloc correspondant <code>iface</code>)."
|
||||
],
|
||||
"readonlyTitle": "Garantie en lecture seule",
|
||||
"readonlyBody": "Jusqu'à ce point, le script n'a pas exécuté une seule commande de modification. Vous pouvez laisser l'analyse ouverte, copier les commandes <code>sed</code> suggérées et les appliquer manuellement si vous préférez — ou accepter l'invite suivante pour entrer dans la réparation guidée."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Étape 2 : réparation guidée (5 étapes)",
|
||||
"intro": "Accessible uniquement si vous acceptez la proposition à la fin de l’analyse. Chaque étape présente l’action prévue et demande une confirmation avant de continuer.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sauvegarde de sécurité",
|
||||
"body": "Copie <code>/etc/network/interfaces</code> vers <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Le chemin exact de sauvegarde est affiché avant la copie et à nouveau après, avec la commande rollback.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Examiner la configuration actuelle",
|
||||
"body": "Ouvre le fichier actuel <code>/etc/network/interfaces</code> dans une boîte de dialogue avec défilement pour voir exactement ce qui va être modifié.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Aperçu des modifications proposées",
|
||||
"body": "Liste précisément les ponts concernés et les remplacements de ports prévus. Si aucune réparation n’est plus nécessaire parce que le port est réapparu entre les vérifications, la procédure se termine avec <em>« Aucune modification nécessaire. »</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer les modifications",
|
||||
"body": "Pour chaque pont touché, exécute <code>sed -i \"/iface $bridge/,/bridge-ports/ s/bridge-ports.*/bridge-ports $new_ports/\"</code> contre <code>/etc/network/interfaces</code>. Si un pont n'avait pas de remplacement valide disponible, la substitution est ignorée et signalée à l'étape 5.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Vérification",
|
||||
"body": "Relit le fichier et confirme l’existence du nouveau port de chaque pont. Affiche la commande de retour en arrière (<code>cp <backup> /etc/network/interfaces</code>). Propose enfin <strong>Redémarrer le réseau</strong> : n’acceptez que si vous disposez d’un accès de secours à la console.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"restartTitle": "Redémarrer le réseau ≠ annuler sans risque",
|
||||
"restartBody": "La réparation est écrite sur le disque, même si vous ne redémarrez pas le service. <code>systemctl restart networking</code> applique la modification <em>maintenant</em>, ce qui peut interrompre votre session SSH si le nouveau port est incorrect. En cas de refus, la modification prendra quand même effet au prochain redémarrage : vérifiez d’abord la configuration ou revenez en arrière avec la commande affichée."
|
||||
},
|
||||
"edits": {
|
||||
"heading": "Ce qui est édité (exactement)",
|
||||
"body": "Uniquement la ligne <code>bridge-ports</code> de chaque pont concerné. Les autres directives (<code>address</code>, <code>netmask</code>, <code>gateway</code>, <code>bridge-stp</code>, …) restent intactes. Le script ne crée ni ne supprime de blocs <code>iface</code> dans cette procédure : c’est le rôle de <link>l’analyse de configuration & du nettoyage</link>."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"unsupportedTitle": "L’analyse s’arrête avec « Pile réseau non prise en charge »",
|
||||
"unsupportedBody": "L'hôte exécute netplan, systemd-networkd ou NetworkManager. L'outil ne prend en charge que <code>/etc/network/interfaces</code>. Passez d'abord l'hôte à la pile classique ou modifiez la configuration avec l'outil natif du gestionnaire (p. ex. <code>netplan apply</code>).",
|
||||
"noSuggestTitle": "Aucune suggestion n'est imprimée pour un port invalide",
|
||||
"noSuggestBody": "L'hôte a zéro interfaces physiques libres (tout est déjà dans un autre pont ou n'existe pas). L'analyse revient à suggérer <code>bridge-ports none</code> afin que le pont puisse au moins monter sans port. Ajouter un NIC ou migrer les ports entre les ponts manuellement avant de recommencer.",
|
||||
"stillDownTitle": "La réparation s'achève mais le pont est toujours DOWN",
|
||||
"stillDownBody": "<code>sed</code> a mis à jour le fichier, mais <code>systemctl restart networking</code> a été refusé. Exécutez-le manuellement une fois que la nouvelle configuration est vérifiée, ou redémarrez. Si le redémarrage a été accepté et que le pont est toujours DOWN, exécutez <code>ip link show</code> pour confirmer l'existence du nouveau port, puis vérifiez <code>journalctl -u networking</code> pour l'erreur réelle (câble débranché, lien non négocié, port déjà membre d'un autre pont).",
|
||||
"lostSshTitle": "J'ai perdu l'accès SSH juste après le redémarrage du réseau",
|
||||
"lostSshIntro": "Utilisez console / IPMI / iKVM pour atteindre l'hôte. Restaurer la sauvegarde :",
|
||||
"lostSshOutro": "Relancez ensuite l’analyse depuis la console pour comprendre pourquoi la suggestion n’a pas fonctionné, généralement parce que le port de remplacement n’est pas branché."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Noms d'interface persistants",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": "— épingler les noms aux adresses MAC afin que ce scénario cesse de se produire."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— pour les blocs orphelins de <code>iface</code> (l'autre moitié du même problème)."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "— les instantanés manuels et le navigateur de restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,122 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Analyse de configuration et nettoyage guidé | Documentation ProxMenux",
|
||||
"description": "Détecte les blocs iface de /etc/network/interfaces qui font référence à des cartes réseau physiques absentes de l’hôte. Les signale et propose une suppression guidée en 5 étapes avec sauvegarde obligatoire et aperçu de chaque bloc.",
|
||||
"ogTitle": "Analyse de configuration et nettoyage guidé | Documentation ProxMenux",
|
||||
"ogDescription": "Trouver et supprimer les blocs d'interface orphelins laissés derrière par les changements matériels, avec prévisualisation complète et retour."
|
||||
},
|
||||
"header": {
|
||||
"title": "Analyse de configuration et nettoyage guidé",
|
||||
"description": "Examine chaque bloc iface de /etc/network/interfaces et vérifie que la carte réseau physique correspondante existe toujours. Signale les blocs orphelins laissés par des changements matériels et propose une suppression guidée avec sauvegarde, aperçu et confirmation de chaque bloc.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Identifie les déclarations <code>iface</code> dont le support NIC n'est plus présent sur l'hôte (typique après le remplacement ou la suppression d'une carte réseau). Ensuite, offre un nettoyage guidé qui supprime <em>seulement</em> les blocs orphelins, avec une sauvegarde, un aperçu par section et une confirmation finale explicite."
|
||||
},
|
||||
"differs": {
|
||||
"heading": "Comment il diffère de l'analyse de pont",
|
||||
"headerAspect": "Aspect",
|
||||
"headerBridge": "Analyse des ponts",
|
||||
"headerConfig": "Analyse de la configuration",
|
||||
"rows": [
|
||||
{
|
||||
"aspect": "Regarde",
|
||||
"bridge": "Ponts (<code>vmbrX</code>) et leur ligne <code>bridge-ports</code>",
|
||||
"config": "Chaque bloc <code>iface</code>, sauf loopback, ponts et agrégations"
|
||||
},
|
||||
{
|
||||
"aspect": "Détecte",
|
||||
"bridge": "Ponts faisant référence à un port inexistant",
|
||||
"config": "Blocs d'interface autonomes pour les NIC qui n'existent pas"
|
||||
},
|
||||
{
|
||||
"aspect": "Action de réparation",
|
||||
"bridge": "Remplace le nom du port dans <code>bridge-ports</code>",
|
||||
"config": "Supprime tout le bloc <code>iface</code>"
|
||||
},
|
||||
{
|
||||
"aspect": "Non compris",
|
||||
"bridge": "Rien — chaque pont est analysé",
|
||||
"config": "Les ponts (<code>vmbrX</code>) et agrégations (<code>bondX</code>) sont toujours conservés : ils sont virtuels et leur absence peut être normale au démarrage"
|
||||
}
|
||||
],
|
||||
"outro": "En pratique, on utilise souvent les deux dans cet ordre : <strong>analyse de configuration</strong> pour supprimer les blocs orphelins, puis <link>analyse des ponts</link> pour réaffecter tout pont qui dépendait de l’interface supprimée."
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Étape 1: analyse (lecture seule)",
|
||||
"intro": "Avorte immédiatement si l'hôte n'est pas sur la pile classique. Sinon, liste toutes les interfaces non loopback configurées et indique son état :",
|
||||
"virtTitle": "Les interfaces virtuelles sont protégées",
|
||||
"virtBody": "Les ponts (<code>vmbrX</code>) et agrégations (<code>bondX</code>) sont virtuels. Leur absence peut être normale au moment de l’inspection, par exemple pour un pont sans port. L’analyse ne propose donc jamais de les supprimer, seulement les cartes réseau physiques."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Étape 2 : nettoyage guidé (5 étapes)",
|
||||
"intro": "Accessible uniquement si vous acceptez la proposition à la fin de l’analyse. Chaque étape exige une confirmation ; annuler à tout moment quitte sans écrire.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sauvegarde de sécurité",
|
||||
"body": "Copie <code>/etc/network/interfaces</code> vers <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Chemin montré avant et après.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Confirmer la liste de suppression",
|
||||
"body": "Liste précisément les blocs d’interface physique à supprimer. Si les cartes réseau réapparaissent entre l’analyse et le nettoyage, par exemple après avoir réinséré une carte, la procédure se termine avec <em>« Aucun nettoyage nécessaire. »</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Aperçu du ou des blocs exacts",
|
||||
"body": "Ouvre une vue défilante de chaque bloc <code>iface</code> qui serait supprimé, mot à mot du fichier. C'est le moment de repérer par exemple un crochet <code>up</code> intéressant que vous voulez préserver.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer la suppression",
|
||||
"body": "Pour chaque interface orpheline, exécute <code>sed -i \"/^iface $iface/,/^$/d\" /etc/network/interfaces</code>. Cela supprime de la ligne correspondante <code>iface</code> jusqu'à la ligne blanche suivante.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Vérification",
|
||||
"body": "Relit le fichier, répertorie ce qui a été supprimé et revérifie les interfaces restantes. Imprime la commande de restauration. <strong>ne redémarre pas</strong> automatiquement le réseau : la suppression d'un bloc inutilisé peut être appliquée en toute sécurité au prochain redémarrage et évite de toucher à l'état actif.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"noRestartTitle": "Ne redémarre pas automatiquement le réseau",
|
||||
"noRestartBody": "Contrairement à la réparation de pont, le flux de nettoyage n'offre pas de redémarrer le service. L'élimination d'un bloc d'interface inutilisé n'a aucun effet immédiat sur la configuration en cours d'exécution, de sorte qu'un redémarrage est inutile et serait un risque inutile de connectivité. Le changement prend effet sur le prochain manuel <code>systemctl restart networking</code> ou au prochain redémarrage."
|
||||
},
|
||||
"caveats": {
|
||||
"heading": "Mises en garde importantes",
|
||||
"boundaryTitle": "La limite du bloc est la première ligne vide",
|
||||
"boundaryBody": "Le motif <code>sed</code> supprime de <code>iface <name></code> jusqu’à la ligne vide suivante. Si <code>/etc/network/interfaces</code> ne contient pas de ligne vide entre les blocs, ce qui est rare mais possible après une modification manuelle, le bloc suivant peut aussi être supprimé. C’est pourquoi <strong>l’étape 3 est obligatoire</strong> : examinez l’aperçu avant de confirmer.",
|
||||
"tandemTitle": "Un bloc iface orphelin utilisé par un pont est détecté ici, pas dans l’analyse des ponts",
|
||||
"tandemBody": "Si <code>vmbr0</code> déclare <code>bridge-ports enp3s0</code> et qu’<code>enp3s0</code> a aussi son propre bloc <code>iface enp3s0 inet manual</code>, supprimer <code>enp3s0</code> ici laisse une référence invalide dans <code>vmbr0</code>. Après le nettoyage, lancez <link>l’analyse des ponts</link> pour réaffecter ou retirer le port du pont. Les deux procédures sont conçues pour être utilisées ensemble."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"notFoundTitle": "L’analyse indique « INTROUVABLE » pour ma nouvelle carte réseau",
|
||||
"notFoundBody": "Le noyau voit le périphérique sous un autre nom que celui du fichier. Lancez <code>ip link show</code> pour connaître son nom réel. C’est précisément un cas où les <link>noms d’interface persistants</link> éviteraient le problème à l’avenir.",
|
||||
"tooMuchTitle": "Le nettoyage a trop supprimé, dont un bloc que je voulais garder",
|
||||
"tooMuchBody": "Restaurer à partir de la sauvegarde imprimée dans l'étape 5:",
|
||||
"tooMuchOutro": "Modifier le fichier à la main pour ajouter une ligne blanche claire entre les blocs avant de ré-exécuter le nettoyage, ou supprimer le bloc problématique manuellement.",
|
||||
"bridgeBreakTitle": "Un pont s'arrête après le nettoyage",
|
||||
"bridgeBreakBody": "Le pont utilisait un port dont le bloc <code>iface</code> vient d’être supprimé. Lancez <link>l’analyse des ponts</link> ; la suggestion associera le pont à une interface physique existante."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— le suivi naturel après un nettoyage."
|
||||
},
|
||||
{
|
||||
"label": "Noms d'interface persistants",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": "— empêche les blocs orphelins de s'accumuler après chaque changement matériel."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "— les instantanés manuels et le navigateur de restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Diagnostic | Documentation ProxMenux",
|
||||
"description": "Trois diagnostics ponctuels en lecture seule : Afficher la table de routage, Tester la connectivité et Diagnostic avancé. Inspection uniquement — n’écrit jamais dans /etc/network/interfaces et n’exécute aucune commande de modification, à une exception explicite près : la purge de NetworkManager, s’il est détecté, nécessite votre accord.",
|
||||
"ogTitle": "Diagnostic | Documentation ProxMenux",
|
||||
"ogDescription": "Diagnostic réseau en lecture seule pour l'hôte Proxmox : routage, accessibilité, statistiques avancées."
|
||||
},
|
||||
"header": {
|
||||
"title": "Diagnostic",
|
||||
"description": "Trois contrôles ponctuels en lecture seule de l’état actuel du réseau : table de routage, test de connectivité et statistiques avancées. Aucun n’écrit dans /etc/network/interfaces — utilisables en toute sécurité à tout moment, y compris via SSH. Pour la surveillance interactive en direct, consultez Outils de surveillance en direct.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Présente le routage, l’accessibilité et les statistiques agrégées <strong>sans rien modifier</strong>. Permet de vérifier le bon fonctionnement du réseau ou de repérer des adresses IP en double. Pour observer le trafic en continu, voir <monitoringLink>Outils de surveillance en direct</monitoringLink> ; pour consulter le fichier de configuration brut, voir <backupLink>Sauvegarde et redémarrage des interfaces</backupLink>."
|
||||
},
|
||||
"routing": {
|
||||
"heading": "Afficher la table de routage",
|
||||
"body": "Liste chaque route que le noyau utilise actuellement (<code>ip route show</code>) et souligne la passerelle par défaut. Utile pour confirmer que le trafic vers Internet passe par l'interface prévue et qu'aucune route restante n'a priorité."
|
||||
},
|
||||
"connectivity": {
|
||||
"heading": "Tester la connectivité",
|
||||
"intro": "Envoie deux sondes ICMP à trois cibles dans l'ordre et signale chacune. Ensuite, exécute un <code>nslookup google.com</code> pour vérifier la résolution DNS indépendamment de ICMP.",
|
||||
"headerTest": "Essai",
|
||||
"headerTarget": "Cible",
|
||||
"headerConfirms": "Ce qu'il confirme",
|
||||
"rows": [
|
||||
{
|
||||
"test": "Google DNS",
|
||||
"target": "8.8.8.8",
|
||||
"confirms": "Accessibilité externe via une adresse IP anycast connue"
|
||||
},
|
||||
{
|
||||
"test": "Cloudflare DNS",
|
||||
"target": "1.1.1.1",
|
||||
"confirms": "Deuxième avis indépendant si Google bloque ICMP"
|
||||
},
|
||||
{
|
||||
"test": "Passerelle",
|
||||
"target": "(route par défaut)",
|
||||
"confirms": "Connectivité L2 / L3 au routeur local"
|
||||
},
|
||||
{
|
||||
"test": "Résolution DNS",
|
||||
"target": "google.com",
|
||||
"confirms": "Le serveur DNS est accessible et répond"
|
||||
}
|
||||
],
|
||||
"readingTitle": "Lecture du résultat",
|
||||
"readingBody": "Si le test de la passerelle réussit mais que les cibles DNS publiques ne répondent pas, vous avez une connectivité locale mais pas d’accès Internet : vérifiez la connexion en amont de la passerelle. Si la résolution DNS échoue mais que les pings vers <code>8.8.8.8</code> réussissent, le problème vient du résolveur, pas du réseau : vérifiez <code>/etc/resolv.conf</code>."
|
||||
},
|
||||
"advanced": {
|
||||
"heading": "Diagnostic avancé",
|
||||
"intro": "Agrège les statistiques du réseau et effectue une série de vérifications des problèmes courants. Affiche le nombre de connexions actives, les ports en écoute et le nombre total d’interfaces, et signale explicitement deux configurations problématiques :",
|
||||
"items": [
|
||||
"<strong>NetworkManager fonctionne sur un hôte Proxmox.</strong> NetworkManager et <code>ifupdown</code> de Proxmox entrent en conflit : tous deux tentent de gérer les interfaces, ce qui rend les ponts instables ou les empêche de s’activer. Si NetworkManager est détecté, l’outil propose une confirmation interactive pour l’arrêter, le désactiver et le purger (c’est le <em>seul</em> diagnostic pouvant modifier le système, et uniquement après consentement explicite).",
|
||||
"<strong>Adresses IP en double sur différentes interfaces.</strong> Deux interfaces utilisant la même adresse IPv4 provoquent des problèmes de connexion intermittents très difficiles à diagnostiquer depuis la VM. Détection via <code>ip -4 addr show | sort | uniq -d</code>."
|
||||
],
|
||||
"nmTitle": "L'invite NetworkManager est la seule action de modification ici",
|
||||
"nmBody": "Toutes les autres vérifications du diagnostic avancé sont en lecture seule. La suppression de NetworkManager nécessite une confirmation oui/non et exécute <code>systemctl stop / disable</code> + <code>apt-get purge -y network-manager</code>. Si vous refusez, rien ne change."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"gwTitle": "Tester la connectivité signale un échec de la passerelle, mais l’hôte a accès à Internet",
|
||||
"gwBody": "Certains routeurs ne répondent pas aux requêtes ICMP sur leur interface interne même s’ils acheminent correctement le trafic. Testez avec <code>traceroute 8.8.8.8</code> depuis une console : si le deuxième saut correspond à votre FAI et que le test DNS public a réussi, la passerelle fonctionne malgré l’échec du ping.",
|
||||
"dupTitle": "Le diagnostic avancé signale toujours des adresses IP en double après que j’en ai supprimé une",
|
||||
"dupBody": "La vérification examine l'état du noyau en direct, et non le fichier de configuration. Exécutez <code>ip -4 addr show</code> pour confirmer ; si le duplicata est toujours présent, une interface le tient toujours. Utilisez <code>ip addr del <IP>/<mask> dev <iface></code> pour le supprimer de l'état en direct, puis modifiez <code>/etc/network/interfaces</code> si elle est aussi persistante."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Outils de surveillance en direct",
|
||||
"href": "/docs/network/monitoring",
|
||||
"tail": "— les lanceurs interactifs iftop / iptraf-ng / iperf3."
|
||||
},
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": " — lorsqu’un vmbrX n’a plus de port physique."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — lorsqu’une ancienne carte réseau est toujours déclarée mais n’est plus présente."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": " — pour créer un instantané de la configuration avant toute modification."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,107 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Gestion réseau Proxmox — Ponts, agrégations, diagnostic, réparation | ProxMenux",
|
||||
"description": "Diagnostics en lecture seule, analyses suivies de suggestions et réparations guidées pour la pile réseau Debian / Proxmox (/etc/network/interfaces). Inspectez les ponts et les agrégations, lancez des outils de surveillance en direct, rendez les noms d’interface persistants, sauvegardez et redémarrez le réseau en toute sécurité — avec sauvegardes obligatoires et aperçus étape par étape.",
|
||||
"ogTitle": "Gestion réseau Proxmox — Ponts, agrégations, diagnostic, réparation",
|
||||
"ogDescription": "Diagnostics, analyses et réparations guidées pour la pile réseau Proxmox avec sauvegardes obligatoires et prévisualisations étape par étape.",
|
||||
"twitterTitle": "Gestion réseau Proxmox | ProxMenux",
|
||||
"twitterDescription": "Ponts, agrégations, diagnostics et réparations guidées pour la pile réseau Proxmox avec sauvegardes obligatoires."
|
||||
},
|
||||
"header": {
|
||||
"title": "Gestion du réseau",
|
||||
"description": "Diagnostics en lecture seule, rapports d’analyse suivis de suggestions et réparations guidées pour la pile réseau classique Debian/Proxmox. Toute opération destructive crée d’abord une sauvegarde et affiche les modifications exactes avant de les appliquer.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "À quoi sert ce menu",
|
||||
"body": "Inspectez, diagnostiquez et, au besoin, réparez la configuration réseau de l’hôte Proxmox sans perdre l’accès à distance. Les outils suivent un principe : <strong>lire d’abord, proposer, puis appliquer uniquement avec un consentement explicite et une sauvegarde de sécurité</strong>. Il n’existe pas de bouton « Tout réparer automatiquement »."
|
||||
},
|
||||
"openingMenu": {
|
||||
"heading": "Ouverture du menu",
|
||||
"intro": "Dans le menu principal de ProxMenux, sélectionnez <strong>Réseau</strong>. Vous verrez ceci :",
|
||||
"imageAlt": "Menu de gestion de réseau avec diagnostic, suivi, analyse, réparation, noms persistants et options de sauvegarde"
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Le modèle de sécurité",
|
||||
"body": "Modifier la configuration réseau d’un hôte Proxmox distant est l’un des moyens les plus faciles de perdre son accès. ProxMenux en tient compte pour chaque action. Les outils se répartissent en trois niveaux de comportement : choisissez la carte correspondant à votre objectif :"
|
||||
},
|
||||
"tiers": {
|
||||
"readOnly": {
|
||||
"title": "Lecture seule",
|
||||
"body": "Contrôle pur. Impossible de modifier le système en aucune circonstance.",
|
||||
"items": [
|
||||
"Tableau d'acheminement, tests de connectivité, statistiques avancées",
|
||||
"Surveillance du trafic en temps réel (iftop, iptraf-ng)",
|
||||
"Test de bande passante (iperf3)"
|
||||
]
|
||||
},
|
||||
"analyze": {
|
||||
"title": "Analysez, puis suggérez",
|
||||
"body": "Détecte les problèmes, affiche un rapport avec les commandes shell proposées, puis s’arrête. Vous décidez ensuite de lancer ou non la réparation guidée.",
|
||||
"items": [
|
||||
"Analyse de la configuration des ponts",
|
||||
"Analyse de la configuration du réseau"
|
||||
]
|
||||
},
|
||||
"apply": {
|
||||
"title": "Appliquer avec sauvegarde",
|
||||
"body": "Modifie le système. Crée toujours d’abord une sauvegarde horodatée du fichier concerné et affiche un aperçu avant l’écriture.",
|
||||
"items": [
|
||||
"Noms d’interface persistants (fichiers .link)",
|
||||
"Sauvegarde manuelle, restauration et redémarrage du service"
|
||||
]
|
||||
}
|
||||
},
|
||||
"classicTitle": "Pile classique seulement",
|
||||
"classicBody": "Chaque fonction d'analyse et de réparation vérifie le gestionnaire de réseau actif avant de toucher quoi que ce soit. Si l'hôte exécute <strong>netplan</strong>, <strong>systemd-networkd</strong> ou <strong>NetworkManager</strong>, l'outil avorte immédiatement avec un message clair — le menu ne prend en charge que la pile classique Debian/Proxmox à <code>/etc/network/interfaces</code>. Ceci est intentionnel : l'édition d'un fichier netplan avec des règles écrites pour <code>ifupdown</code> corromprait silencieusement la configuration.",
|
||||
"backups": {
|
||||
"heading": "Où vont les sauvegardes",
|
||||
"intro": "Chaque réparation guidée, restauration ou sauvegarde manuelle écrit une copie horodatée de <code>/etc/network/interfaces</code> à <code>/var/backups/proxmenux/</code> :",
|
||||
"rollbackIntro": "Pour revenir manuellement à la configuration précédente depuis une console :"
|
||||
},
|
||||
"readOnlySection": {
|
||||
"heading": "Contrôle en lecture seule",
|
||||
"body": "Le point de départ lorsque quelque chose semble anormal. Inspection uniquement — n’écrit jamais dans <code>/etc/network/interfaces</code> et n’exécute aucune commande de modification, à une exception explicite près : la purge de NetworkManager, s’il est détecté, nécessite votre accord. Utilisable en toute sécurité via SSH à tout moment.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Diagnostic",
|
||||
"description": "Trois vérifications en lecture seule : Afficher la table d'acheminement, tester la connectivité et les diagnostics avancés. L'inspection pure n'écrit jamais au système."
|
||||
},
|
||||
{
|
||||
"title": "Outils de surveillance en direct",
|
||||
"description": "Trois lanceurs interactifs : iftop (bande passante en temps réel par paire d'hôtes), iptraf-ng (moniteur de trafic multimode) et iperf3 (test de bande passante, serveur / mode client)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"analyzeSection": {
|
||||
"heading": "Analysez, puis suggérez",
|
||||
"body": "À utiliser lorsqu’une inspection ou une panne réelle révèle un problème de configuration. Chaque outil examine la partie concernée de <code>/etc/network/interfaces</code>, affiche un rapport détaillé avec la commande shell exacte qui corrigerait chaque problème, puis <strong>s’arrête</strong>. Si vous acceptez ensuite la réparation guidée facultative, chaque modification est sauvegardée et prévisualisée avant d’être écrite.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Analyse des ponts et réparation guidée",
|
||||
"description": "Détecte les ponts vmbrX dont les ports sont absents ou invalides, par exemple après une réénumération PCI. Affiche d’abord un rapport et ne répare que si vous acceptez la procédure guidée en 5 étapes."
|
||||
},
|
||||
{
|
||||
"title": "Analyse de configuration et nettoyage guidé",
|
||||
"description": "Repère les interfaces physiques déclarées dans /etc/network/interfaces qui n’existent plus, c’est-à-dire les configurations orphelines laissées par des changements matériels. Les signale et propose une suppression guidée."
|
||||
}
|
||||
]
|
||||
},
|
||||
"applySection": {
|
||||
"heading": "Appliquer avec sauvegarde",
|
||||
"body": "Ces outils écrivent sur le disque par leur fonctionnement même. Chacun crée une sauvegarde horodatée du fichier concerné avant l’écriture, et les options destructives, comme la restauration et le redémarrage, exigent une confirmation explicite oui/non. Les <em>noms d’interface persistants</em> prennent effet au prochain redémarrage, pas immédiatement ; leur mise en place peut donc être planifiée en toute sécurité même sur un hôte distant.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Noms d'interface persistants",
|
||||
"description": "Associe les noms d’interface (eno1, enp3s0, …) aux adresses MAC au moyen de fichiers .link de systemd. Les noms restent stables après un changement d’emplacement PCI, une mise à niveau du noyau ou l’ajout ou le retrait d’autres cartes réseau."
|
||||
},
|
||||
{
|
||||
"title": "Sauvegarde et redémarrage des interfaces",
|
||||
"description": "Un instantané manuel de /etc/network/interfaces, parcourir et restaurer les sauvegardes précédentes, afficher la configuration en direct et redémarrer le service de réseautage au besoin."
|
||||
}
|
||||
]
|
||||
},
|
||||
"consoleTitle": "Préparez l'accès à la console",
|
||||
"consoleSubTitle": "Avant toute réparation sur un hôte distant",
|
||||
"consoleBody": "Si vous êtes connecté via SSH et ne disposez que d’un seul accès à l’hôte, prévoyez une solution de secours avant toute modification réseau : console physique / IPMI / iKVM ou autre machine sur le même réseau local. Les réparations guidées sont sûres et proposent toujours une commande de retour en arrière, mais un pont mal configuré ou une liaison interrompue peut tout de même vous priver d’accès jusqu’à ce que vous puissiez atteindre la console."
|
||||
}
|
||||
@@ -0,0 +1,136 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Outils de surveillance en direct | Documentation ProxMenux",
|
||||
"description": "Trois lanceurs interactifs de surveillance du réseau : iftop (bande passante en temps réel par paire d'hôtes), iptraf-ng (moniteur de trafic multimode) et iperf3 (test de bande passante, serveur / mode client). Chacun est installé lors de la première utilisation.",
|
||||
"ogTitle": "Outils de surveillance en direct | Documentation ProxMenux",
|
||||
"ogDescription": "Surveillance réseau interactive et test de bande passante pour l'hôte Proxmox : iftop, iptraf-ng, iperf3."
|
||||
},
|
||||
"header": {
|
||||
"title": "Outils de surveillance en direct",
|
||||
"description": "Trois lanceurs interactifs pour observer le réseau en temps réel et mesurer la bande passante : iftop, iptraf-ng et iperf3. Chaque outil est installé automatiquement via apt au premier usage, fonctionne au premier plan et se quitte avec la touche indiquée. Ils ne modifient pas la configuration réseau de l’hôte ; iperf3 génère du trafic de test.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Trois outils de suivi interactifs, chacun derrière sa propre entrée de menu. La première fois que vous en lancez un, le paquet est installé silencieusement via <code>apt-get</code>. Les lancements suivants commencent instantanément. Aucun de ces outils ne modifie la configuration du réseau hôte."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Quel outil utiliser selon le besoin",
|
||||
"headerQuestion": "Question",
|
||||
"headerUse": "Utiliser",
|
||||
"rows": [
|
||||
{
|
||||
"question": "Qui sature le lien <em> maintenant</em> ?",
|
||||
"use": "iftop"
|
||||
},
|
||||
{
|
||||
"question": "Quelle est la répartition par protocole, quelles tailles de paquets et quels flux TCP circulent ?",
|
||||
"use": "iptraf-ng"
|
||||
},
|
||||
{
|
||||
"question": "Combien de bande passante est disponible entre deux hôtes ?",
|
||||
"use": "iperf3"
|
||||
}
|
||||
]
|
||||
},
|
||||
"iftop": {
|
||||
"heading": "Utilisation du réseau en temps réel (iftop)",
|
||||
"body": "Bande passante en direct par paire d’hôtes (source ↔ destination) — comme <code>top</code> pour le trafic. Affiche les flux les plus importants en haut, avec des moyennes glissantes sur 2/10/40 secondes. L’outil idéal pour savoir <em>« pourquoi ma liaison montante est saturée »</em>.",
|
||||
"exit": "<strong>Quitter :</strong> appuyez sur <kbd>q</kbd>. ProxMenux affiche un rappel avant le lancement.",
|
||||
"keysTitle": "Touches utiles dans iftop",
|
||||
"keysBody": "<kbd>n</kbd> active ou désactive les recherches DNS, <kbd>p</kbd> affiche les numéros de port, <kbd>P</kbd> fige l’affichage, <kbd>t</kbd> change le sens des lignes (envoi / réception / les deux), <kbd>1</kbd>/<kbd>2</kbd>/<kbd>3</kbd> trie par moyenne sur 2 s / 10 s / 40 s. Liste complète dans <code>man iftop</code>."
|
||||
},
|
||||
"iptraf": {
|
||||
"heading": "Outil de surveillance du réseau (iptraf-ng)",
|
||||
"intro": "Un outil de surveillance du trafic à plusieurs modes, piloté par menu. iftop répond à <em>« qui »</em>, tandis qu’iptraf-ng répond à <em>« quoi »</em> : compteurs d’octets et de paquets par protocole, suivi de l’état des connexions TCP, histogrammes de taille des paquets et activité LAN par station.",
|
||||
"menuIntro": "Au lancement, vous obtenez un menu à cinq options :",
|
||||
"headerMode": "Mode",
|
||||
"headerUseFor": "Utilisez-le pour",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "IP traffic monitor",
|
||||
"useFor": "Liste de flux en direct TCP / UDP / ICMP / autre-IP avec compteurs d'octets et état de connexion"
|
||||
},
|
||||
{
|
||||
"mode": "General interface stats",
|
||||
"useFor": "Nombre total de paquets IPv4 / IPv6 / TCP / UDP / ICMP / non IP par carte réseau"
|
||||
},
|
||||
{
|
||||
"mode": "Detailed interface stats",
|
||||
"useFor": "Comme ci-dessus, mais pour une interface, avec la taille du paquet et le détail du taux"
|
||||
},
|
||||
{
|
||||
"mode": "Statistical breakdowns",
|
||||
"useFor": "Histogramme de distribution de la taille du paquet, par port TCP / UDP"
|
||||
},
|
||||
{
|
||||
"mode": "LAN station monitor",
|
||||
"useFor": "Statistiques du trafic par adresse MAC pour le domaine de diffusion local"
|
||||
}
|
||||
],
|
||||
"exit": "<strong>Quitter :</strong> appuyez sur <kbd>x</kbd> depuis n’importe quelle vue ou sur <kbd>Q</kbd> depuis le menu principal. ProxMenux affiche un rappel avant le lancement.",
|
||||
"logTitle": "Enregistrer les captures dans un fichier",
|
||||
"logBody": "Chaque mode propose d’enregistrer les statistiques capturées dans <code>/var/log/iptraf-ng/</code>. Pour conserver une trace d’un pic de trafic, laissez l’outil tourner, enregistrez dans un fichier et examinez-le ensuite plutôt que d’essayer de suivre l’écran en direct."
|
||||
},
|
||||
"iperf3": {
|
||||
"heading": "Test de bande passante (iperf3)",
|
||||
"intro1": "Mesure le débit TCP réel entre deux hôtes. Contrairement à iftop / iptraf-ng, qui observent le trafic existant, iperf3 génère du trafic synthétique pour tester la liaison en charge. Indispensable pour répondre à <em>« Ma liaison 10 GbE atteint-elle vraiment 10 GbE ? »</em> ou <em>« Le goulot d’étranglement vient-il de la carte réseau, du commutateur ou du stockage ? »</em>.",
|
||||
"intro2": "iperf3 est un <strong>outil à deux hôtes</strong> : l’un est le serveur, en écoute sur le port TCP 5201 ; l’autre est le client, qui se connecte, envoie les données et affiche le débit. Le lanceur ProxMenux demande le mode souhaité :",
|
||||
"headerMode": "Mode",
|
||||
"headerBehaviour": "Comportement",
|
||||
"headerCli": "Commande CLI équivalente",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Serveur",
|
||||
"behaviour": "Écoute sur TCP 5201 et imprime les résultats pour chaque test entrant. Arrête sur Ctrl+C.",
|
||||
"cli": "iperf3 -s"
|
||||
},
|
||||
{
|
||||
"mode": "Client",
|
||||
"behaviour": "Demande l’adresse IP ou le nom d’hôte du serveur, se connecte, lance le test par défaut de 10 secondes et affiche le rapport.",
|
||||
"cli": "iperf3 -c <target>"
|
||||
}
|
||||
],
|
||||
"workflowIntro": "Typiquement pour tester un lien 10 GbE entre deux hôtes Proxmox :",
|
||||
"workflow": [
|
||||
"Sur l’hôte A, ouvrez le menu Réseau → <em>Test de bande passante (iperf3)</em> → choisissez <strong>Serveur</strong>.",
|
||||
"Sur l'hôte B, ouvrez la même entrée de menu → choisissez <strong>Client</strong> → saisissez l'IP de l'hôte A.",
|
||||
"Attendez 10 secondes. Comparez le taux déclaré au maximum théorique du lien."
|
||||
],
|
||||
"sample": "Exemple de sortie client :",
|
||||
"flagsTitle": "Options utiles à utiliser manuellement depuis un shell",
|
||||
"flagsBody": "<code>-t 60</code> test plus long (60 s au lieu de 10 s), <code>-P 4</code> 4 flux parallèles (saturation plus rapide), <code>-R</code> sens inverse (serveur → client), <code>-u -b 100M</code> test UDP à 100 Mbit/s (mesure de la gigue et des pertes de paquets), <code>-p 5202</code> autre port (plusieurs tests en parallèle). Liste complète dans <code>man iperf3</code>.",
|
||||
"firewallTitle": "Ouvrez le port pare-feu sur le serveur",
|
||||
"firewallBody": "Le serveur écoute sur TCP <strong>5201</strong> par défaut. Si vous exécutez le serveur à l'intérieur d'un hôte Proxmox avec un pare-feu strict (datacenter ou niveau hôte), autorisez TCP 5201 entrant à partir de l'IP du client pour la durée du test, puis fermez-le à nouveau. Il en va de même pour <code>nftables</code> / <code>iptables</code> sur les hôtes nus."
|
||||
},
|
||||
"install": {
|
||||
"heading": "Le premier lancement installe le paquet",
|
||||
"body": "Les trois lanceurs vérifient le binaire et exécutent <code>apt-get update -qq && apt-get install -y <pkg></code> s'il manque. L'installation est silencieuse : le menu peut apparaître gelé pour 10–30 secondes la première fois. Les lancements suivants commencent instantanément."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"hangTitle": "L’installation reste bloquée au premier lancement",
|
||||
"hangBody": "L'hôte n'a pas d'internet ou les repos apt sont inaccessibles. Annuler avec <kbd>Ctrl</kbd>+<kbd>C</kbd>, exécuter <code>apt-get update</code> manuellement pour voir l'erreur réelle (DNS, repo signature, proxy ...), puis revenir au menu.",
|
||||
"refusedTitle": "Client iperf3 : « unable to connect to server: Connection refused »",
|
||||
"refusedBody": "Soit le serveur ne fonctionne pas, soit son pare-feu bloque TCP 5201. Confirmer sur le serveur: <code>ss -tlnp | grep 5201</code> — doit afficher l'écoute iperf3. Si l'écoute, mais que le client échoue, vérifiez le chemin du pare-feu entre les deux hôtes.",
|
||||
"slowTitle": "iperf3 indique un débit bien inférieur à la vitesse attendue de la liaison",
|
||||
"slowBody": "Causes courantes par ordre de probabilité : (1) le processeur d’un hôte limite le débit — essayez <code>iperf3 -c <target> -P 4</code> pour utiliser plusieurs cœurs ; (2) le trajet passe par une liaison plus lente, par exemple un commutateur gigabit entre deux cartes 10 GbE ; (3) MTU différents — vérifiez <code>ip link show</code> aux deux extrémités ; (4) offloading de la carte réseau désactivé — voir le script communautaire <em>Disable NIC Offloading</em> pour une carte Intel e1000e.",
|
||||
"noTrafficTitle": "iftop / iptraf-ng ne montre aucun trafic pour un hôte occupé",
|
||||
"noTrafficBody": "La capture par défaut est sur la première interface détectée. Spécifiez le bon explicitement depuis le shell : <code>iftop -i vmbr0</code> ou <code>iptraf-ng -i vmbr0</code>. Le lanceur de menu utilise la valeur par défaut; pour les interfaces non par défaut, exécuter à partir d'une console."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": "— les contrôles en lecture seule (routage, connectivité, statistiques avancées)."
|
||||
},
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— lorsque la surveillance révèle qu'une interface ou un pont ne fait pas ce qu'il faut."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,130 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Noms d’interface persistants | Documentation ProxMenux",
|
||||
"description": "Associez les noms d’interface Proxmox (eno1, enp3s0, …) aux adresses MAC via des fichiers .link de systemd pour les conserver après une réénumération PCI, une mise à niveau du noyau ou l’ajout ou le retrait d’autres cartes réseau.",
|
||||
"ogTitle": "Noms d’interface persistants | Documentation ProxMenux",
|
||||
"ogDescription": "Empêchez les noms d’interface Proxmox de changer lors des modifications matérielles. Utilise des fichiers .link de systemd associés aux adresses MAC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Noms d'interface persistants",
|
||||
"description": "Génère un fichier .link de systemd par carte réseau physique pour associer le nom attribué par le noyau à son adresse MAC. Après application au prochain redémarrage, les noms d’interface restent stables lorsque vous ajoutez, retirez ou déplacez des cartes PCIe.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Pour chaque NIC physique sur l'hôte, écrit un petit fichier sous <code>/etc/systemd/network/10-<iface>.link</code> qui dit : <em>\"le périphérique avec ce MAC doit toujours être appelé ce nom\"</em>. systemd-udevd applique la règle à chaque démarrage, avant que <code>ifupdown</code> ne lise <code>/etc/network/interfaces</code>."
|
||||
},
|
||||
"problem": {
|
||||
"heading": "Le problème que cela résout",
|
||||
"intro": "Linux déduit les noms d’interface par défaut de la topologie PCI — <code>eno1</code> = intégrée à la carte mère, <code>enp3s0</code> = carte sur le bus PCI 3, emplacement 0, etc. Le nommage est déterministe <em>pour une même disposition matérielle</em>. Si cette disposition change, les noms changent :",
|
||||
"items": [
|
||||
"Ajoutez un GPU devant un NIC existant → le numéro de bus NIC peut changer → changement de nom.",
|
||||
"Déplacer une carte vers une autre fente PCIe → nom change.",
|
||||
"BIOS / UEFI mise à jour qui réénumère les appareils → noms peuvent changer.",
|
||||
"Remplacer une carte défectueuse par le même modèle dans une autre fente → nom change."
|
||||
],
|
||||
"outro": "Après un tel changement, <code>/etc/network/interfaces</code> fait toujours référence à l’<em>ancien</em> nom ; le pont ne s’active pas et l’hôte perd le réseau. Les noms persistants évitent que cette situation se reproduise."
|
||||
},
|
||||
"howWorks": {
|
||||
"heading": "Comment ça marche",
|
||||
"arrowLabel": "par NIC",
|
||||
"nodes": {
|
||||
"detectLabel": "Détecter les cartes réseau physiques",
|
||||
"detectDetail": "ls /sys/class/net/\nexclure vmbr / bond /\ndocker / veth / wireguard …",
|
||||
"readLabel": "Lire chaque MAC",
|
||||
"readDetail": "cat /sys/class/net/\n '<'iface'>'/address",
|
||||
"writeLabel": "Écrivez le fichier .link",
|
||||
"writeDetail": "/etc/systemd/network/\n 10-'<'iface'>'.link"
|
||||
},
|
||||
"minimalIntro": "Chaque fichier généré est volontairement minimal :",
|
||||
"minimalOutro": "Au démarrage, systemd-udevd identifie le périphérique par son adresse MAC et lui attribue le nom demandé <em>avant</em> l’intervention d’autres composants (ifupdown, nommage par défaut du noyau). Le préfixe <code>10-</code> garantit le chargement précoce de ces règles, avant le fichier par défaut <code>99-default.link</code>."
|
||||
},
|
||||
"scope": {
|
||||
"heading": "Ce qui est écrit, ce qui est ignoré",
|
||||
"headerType": "Type",
|
||||
"headerBehaviour": "Comportement",
|
||||
"headerWhy": "Pourquoi",
|
||||
"rows": [
|
||||
{
|
||||
"type": "Carte réseau intégrée / PCIe",
|
||||
"behaviour": "fichier <code>.link</code> écrit",
|
||||
"why": "Repose sur un véritable périphérique PCI — le cas auquel l’outil est destiné"
|
||||
},
|
||||
{
|
||||
"type": "Wi-Fi (phy80211)",
|
||||
"behaviour": "fichier <code>.link</code> écrit",
|
||||
"why": "A une vraie MAC et bénéficie de la stabilité des noms"
|
||||
},
|
||||
{
|
||||
"type": "Ponts (vmbrX)",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Virtuel; le nom vient de <code>/etc/network/interfaces</code>"
|
||||
},
|
||||
{
|
||||
"type": "Agrégations (bondX)",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Virtuel ; le nom de l’agrégation est défini par ifupdown"
|
||||
},
|
||||
{
|
||||
"type": "veth / docker0 / br-XXXX",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Créé sur demande par Docker / LXC — matériel non persistant"
|
||||
},
|
||||
{
|
||||
"type": "tap / fwpr / fwln",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Créé sur demande par Proxmox par VM/CT"
|
||||
},
|
||||
{
|
||||
"type": "WireGuard / Cilium / Tailscale",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Interfaces logicielles gérées par leurs propres démons"
|
||||
}
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Filet de sécurité : les fichiers .link précédents sont sauvegardés",
|
||||
"intro": "Si <code>/etc/systemd/network/</code> contient déjà des fichiers <code>.link</code> (à partir d'une exécution précédente ou d'un autre outil), ils sont copiés dans un répertoire de sauvegarde horodaté avant que les nouveaux fichiers ne soient générés :",
|
||||
"outro": "Pour revenir en arrière : copiez les fichiers à partir du répertoire de sauvegarde et redémarrez.",
|
||||
"rebootTitle": "Prend effet sur le prochain redémarrage, pas immédiatement",
|
||||
"rebootBody": "Les modifications des fichiers <code>.link</code> ne s’appliquent qu’au démarrage, lorsque udev réénumère les périphériques. L’outil indique donc <em>« Les modifications s’appliqueront après le redémarrage »</em>. Renommer une interface en cours de fonctionnement est risqué et n’est pas tenté : un <code>vmbr0</code> actif avec des interfaces membres devrait être reconfiguré de manière atomique. L’opération est donc reportée au prochain démarrage propre."
|
||||
},
|
||||
"afterReboot": {
|
||||
"heading": "Après le redémarrage",
|
||||
"intro": "Une fois les noms épinglés, le flux de travail des futurs changements matériels est simple :",
|
||||
"items": [
|
||||
"Éteignez, modifiez le matériel (ajout de carte, changement d’emplacement, …), puis démarrez.",
|
||||
"Chaque NIC conserve son nom précédent car son MAC correspond à un fichier <code>.link</code>.",
|
||||
"Si un NIC est remplacé (différent MAC), il obtient un nom de noyau par défaut (<code>enp<bus>s<slot></code>); ré-exécutez ce menu pour ajouter une entrée <code>.link</code> pour le MAC de la nouvelle carte."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"emptyTitle": "\"Aucune interface physique trouvée\" après avoir lancé l'outil",
|
||||
"emptyBody": "Aucune interface reposant sur PCI ou phy80211 n’est visible par le noyau sur l’hôte. Vérifiez avec <code>ls -l /sys/class/net/</code> : chaque entrée doit avoir soit un lien symbolique <code>device</code> (PCI), soit une entrée <code>phy80211</code> (Wi-Fi). Si les deux sont absents pour une véritable carte réseau, le pilote n’est pas chargé.",
|
||||
"noChangeTitle": "Après le redémarrage, les noms n'ont pas changé comme prévu",
|
||||
"noChangeBody": "Vérifiez que le fichier est présent et correctement formé : <code>cat /etc/systemd/network/10-<iface>.link</code>. Consultez ensuite les journaux udev : <code>journalctl -u systemd-udevd -b | grep -i link</code>. Un ancien paramètre du noyau <code>net.ifnames=0</code> désactive entièrement le nommage prévisible : supprimez-le de <code>/etc/default/grub</code>, exécutez <code>update-grub</code>, puis redémarrez.",
|
||||
"undoTitle": "Je veux annuler les noms persistants",
|
||||
"undoBody": "Supprimez les fichiers <code>.link</code> (<code>rm /etc/systemd/network/10-*.link</code>) ou restaurez-les depuis le répertoire de sauvegarde créé lors de l’exécution précédente. Redémarrez pour appliquer les modifications."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tailRich": " — la solution de récupération lorsque les noms ont <em>déjà</em> changé."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — pour supprimer les blocs orphelins laissés par les changements de noms."
|
||||
},
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tailRich": "— confirmer les nouveaux noms avec <em>Afficher la table d'acheminement</em> après le redémarrage."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,171 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Comment une image OCI est adaptée | ProxMenux",
|
||||
"description": "Du dépôt de l’image et de son fichier Compose à un modèle vérifiable, un plan de déploiement et un LXC natif de Proxmox VE, sans Docker à l’intérieur."
|
||||
},
|
||||
"header": {
|
||||
"title": "Comment une image OCI est adaptée",
|
||||
"description": "Du dépôt de l’image et de son fichier Compose à un modèle vérifiable, un plan de déploiement et un LXC natif, sans installer Docker à l’intérieur.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "pipeline",
|
||||
"title": "Le processus d’adaptation",
|
||||
"blocks": [
|
||||
{
|
||||
"mermaid": {
|
||||
"chartCode": "flowchart LR\n A[\"{{repo}}\"] --> B[\"Compose + README\"]\n B --> C[\"{{converter}}\"]\n C --> D[\"{{template}}\"]\n D --> E{\"{{blockers}}\"}\n E -- \"{{no}}\" --> F[\"{{review}}\"]\n F --> D\n E -- \"{{yes}}\" --> G[\"{{plan}}\"]\n G --> H[\"pct create\"]\n H --> I[\"{{lxc}}\"]",
|
||||
"labels": {
|
||||
"repo": "Dépôt de l’image",
|
||||
"converter": "Convertisseur",
|
||||
"template": "Modèle JSON",
|
||||
"blockers": "Aucun point bloquant ?",
|
||||
"no": "Non",
|
||||
"yes": "Oui",
|
||||
"review": "Révision / overlay",
|
||||
"plan": "Plan de déploiement",
|
||||
"lxc": "LXC natif"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le convertisseur lit l’image et le fichier Compose publiés par le projet, puis produit un modèle JSON. Si des exigences n’ont pas pu être adaptées et bloquent l’installation, le modèle est révisé avant sa publication dans le catalogue. Un fichier d’ajustements vérifiés, appelé overlay, permet de résoudre ces points. Seuls les modèles sans point bloquant sont proposés à l’installation."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "template",
|
||||
"title": "Ce que conserve le modèle",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Identité de l’image",
|
||||
"body": "Dépôt, tag mis à jour en continu, architecture, digest résolu et révision de la source."
|
||||
},
|
||||
{
|
||||
"icon": "braces",
|
||||
"title": "Contrat du conteneur",
|
||||
"body": "Entrypoint, Cmd, environnement, utilisateur, répertoire de travail, signal d’arrêt, ports et volumes."
|
||||
},
|
||||
{
|
||||
"icon": "layers",
|
||||
"title": "Adaptation à Proxmox VE",
|
||||
"body": "Ressources, sécurité, points de montage, périphériques, sysctls, contrôles de bon fonctionnement et adaptations nécessaires pour chacun, avec leur justification."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Compatibilité",
|
||||
"body": "Clés prises en charge, exigences non adaptées qui bloquent l’installation et état de chaque validation."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "OCI fournit le processus ; Compose fournit l’environnement",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Source",
|
||||
"Exemple",
|
||||
"Résultat natif"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Métadonnées OCI",
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
|
||||
"Proxmox VE les importe à la création du CT"
|
||||
],
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
|
||||
"Entrées d’environnement LXC, <code>mpN</code> et <code>devN</code>"
|
||||
],
|
||||
[
|
||||
"Profil ProxMenux",
|
||||
"GPU, contrôle de bon fonctionnement, identifiants",
|
||||
"Questions et adaptations vérifiées"
|
||||
],
|
||||
[
|
||||
"Utilisateur",
|
||||
"VMID, stockage, réseau",
|
||||
"Le contrat de l’instance"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Ce qui se passe pendant l’installation",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Résoudre la référence",
|
||||
"body": "Le registre est interrogé, l’architecture de l’hôte est sélectionnée et le digest exact désigné par le tag mis à jour en continu est fixé."
|
||||
},
|
||||
{
|
||||
"title": "Télécharger et vérifier",
|
||||
"body": "Skopeo télécharge l’image sous forme d’archive OCI. Avant toute création, chaque couche est vérifiée à l’aide de son digest, puis décompressée. Si le téléchargement est endommagé, il est tenté une seconde fois avant l’arrêt de l’installation."
|
||||
},
|
||||
{
|
||||
"title": "Créer le système de fichiers",
|
||||
"body": "<code>pct create</code> crée le rootfs à partir de l’archive et conserve les métadonnées officielles du processus de l’image."
|
||||
},
|
||||
{
|
||||
"title": "Raccorder les ressources",
|
||||
"body": "Les volumes, le réseau, l’environnement, les périphériques et les profils de sécurité déclarés sont appliqués."
|
||||
},
|
||||
{
|
||||
"title": "Console",
|
||||
"body": "La sortie console du conteneur est conservée sur l’hôte. La console de Proxmox VE ouvre un shell si l’image en contient un."
|
||||
},
|
||||
{
|
||||
"title": "Vérifier",
|
||||
"body": "Au premier démarrage, l’installation attend l’attribution d’une adresse et la réponse du service. En cas d’échec, elle n’est pas signalée comme réussie."
|
||||
},
|
||||
{
|
||||
"title": "Enregistrer la configuration",
|
||||
"body": "La configuration effective est enregistrée dans le contrat de l’instance utilisé lors des mises à jour et des recréations."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Exemple : une image avec /config et /downloads",
|
||||
"intro": "Une définition Compose courante et la configuration Proxmox VE qui en résulte. Les chemins attendus par l’application ne changent pas.",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Docker Compose",
|
||||
"code": "image: lscr.io/linuxserver/example:latest\nenvironment:\n - PUID=1000\n - PGID=1000\nvolumes:\n - config:/config\n - /srv/downloads:/downloads\nports:\n - 8080:8080"
|
||||
},
|
||||
{
|
||||
"title": "/etc/pve/lxc/VMID.conf (extrait)",
|
||||
"code": "entrypoint: /init\nmp0: local-lvm:vm-VMID-disk-1,mp=/config,backup=1,size=8G\nmp1: /srv/downloads,mp=/downloads\nnet0: name=eth0,bridge=vmbr0,ip=dhcp,type=veth\nlxc.environment.runtime: PUID=1000\nlxc.environment.runtime: PGID=1000"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "<code>mp0</code> est un second disque appartenant au conteneur, nommé <code>vm-VMID-disk-N</code> sur le stockage sélectionné. Il est monté dans <code>/config</code> et, avec <code>backup=1</code>, inclus dans la sauvegarde du conteneur. <code>mp1</code> ne crée aucun disque : il monte le répertoire de l’hôte <code>/srv/downloads</code> dans <code>/downloads</code> à l’intérieur du LXC. Le port 8080 n’est pas redirigé : le LXC possède sa propre adresse et le service y répond."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,278 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Installer une image absente du catalogue | ProxMenux",
|
||||
"description": "Adaptez une image OCI à partir d’un fichier Compose, d’une URL, d’une commande docker run ou d’une référence d’image, puis vérifiez ce que ProxMenux peut reproduire avant l’installation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Installer une image absente du catalogue",
|
||||
"description": "Votre image est adaptée à partir de son fichier Compose, d’une commande docker run ou de sa seule référence. Le résultat est présenté pour vérification avant la création du moindre LXC.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Le même convertisseur et le même installateur",
|
||||
"body": "L’option <strong>Installer une image absente du catalogue</strong> utilise le même convertisseur et le même installateur que les modèles du catalogue. Le contrat est simplement généré à ce moment-là à partir de la définition fournie, puis validé avant toute création de LXC."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "Comment décrire l’image",
|
||||
"intro": "Le premier écran demande comment l’image est décrite. Quatre possibilités fournissent une définition à adapter, une cinquième utilise uniquement le nom de l’image et trois autres lisent un oci-compose déjà rédigé.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Contenu lu"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Coller son fichier Compose dans le terminal",
|
||||
"Collez le contenu YAML dans le terminal et terminez avec Ctrl+D."
|
||||
],
|
||||
[
|
||||
"Lire son fichier Compose depuis cet hôte",
|
||||
"Un chemin sur le nœud, <code>/root/docker-compose.yml</code> par défaut. Le fichier doit exister et ne pas dépasser 256 KiB."
|
||||
],
|
||||
[
|
||||
"Télécharger son fichier Compose depuis une adresse",
|
||||
"Une adresse <code>http://</code> ou <code>https://</code> qui fournit le YAML brut. Le téléchargement est limité à 256 KiB."
|
||||
],
|
||||
[
|
||||
"Coller sa commande docker run dans le terminal",
|
||||
"La commande publiée par le projet. Les ports, l’environnement, les volumes, les périphériques, les capabilities, l’utilisateur, la mémoire partagée et les autres options prises en charge sont adaptés."
|
||||
],
|
||||
[
|
||||
"Uniquement la référence de l’image, sans fichier Compose",
|
||||
"Une référence comme <code>ghcr.io/user/application:latest</code>. Le registre est interrogé et les métadonnées OCI de l’image sont conservées."
|
||||
],
|
||||
[
|
||||
"Coller un oci-compose dans le terminal",
|
||||
"Collez le JSON dans le terminal et terminez avec Ctrl+D. Il n’est pas converti : il est vérifié puis installé tel qu’il est rédigé."
|
||||
],
|
||||
[
|
||||
"Lire un oci-compose depuis cet hôte",
|
||||
"Un fichier JSON sur le nœud, <code>/root/oci-compose.json</code> par défaut, de 2 MiB au maximum."
|
||||
],
|
||||
[
|
||||
"Télécharger un oci-compose depuis une adresse",
|
||||
"Une adresse <code>http://</code> ou <code>https://</code> qui fournit le fichier JSON. Le téléchargement est limité à 2 MiB."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-source-menu.png",
|
||||
"alt": "Menu de choix de la description d’une image absente du catalogue",
|
||||
"caption": "Les façons de décrire une image absente du catalogue."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "reference-only",
|
||||
"title": "Ce que fournit la seule référence de l’image",
|
||||
"intro": "L’image contient les métadonnées de son processus, mais pas tout l’environnement habituellement ajouté par un fichier Compose.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Lu depuis l’image",
|
||||
"Absent de l’image",
|
||||
"Conséquence"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> et l’environnement intégré",
|
||||
"Variables présentes uniquement dans la documentation",
|
||||
"Ajoutées pendant l’installation ou avec Modifier"
|
||||
],
|
||||
[
|
||||
"Volumes déclarés par l’image",
|
||||
"Répertoires de l’hôte indiqués uniquement dans le fichier Compose",
|
||||
"Les chemins supplémentaires sont ajoutés avant l’installation"
|
||||
],
|
||||
[
|
||||
"Ports <code>EXPOSE</code>",
|
||||
"L’URL, le protocole ou le contrôle de bon fonctionnement",
|
||||
"Le port et la méthode de vérification du service sont confirmés"
|
||||
],
|
||||
[
|
||||
"Architectures et digest dans le registre",
|
||||
"Périphériques, privilèges ou dépendances externes",
|
||||
"Ils ne sont pas activés sans une définition qui les demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "review",
|
||||
"title": "Vérifier avant l’installation",
|
||||
"intro": "Après adaptation de la définition, ProxMenux présente ce qu’il en a compris avant de demander le VMID, les ressources ou le stockage.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Analyser",
|
||||
"body": "Les services, l’image, les ports, les chemins, l’environnement, les périphériques, la sécurité et le contrôle de bon fonctionnement sont lus."
|
||||
},
|
||||
{
|
||||
"title": "Interroger le registre",
|
||||
"body": "L’image doit exister dans le registre et les architectures publiées sont affichées. Un registre privé est consulté avec le compte enregistré pour celui-ci."
|
||||
},
|
||||
{
|
||||
"title": "Lister les options non appliquées",
|
||||
"body": "Les labels, réseaux Docker, paramètres Swarm et autres clés sans effet sur un LXC sont répertoriés."
|
||||
},
|
||||
{
|
||||
"title": "Bloquer les options sans équivalent sûr",
|
||||
"body": "Les clés sans équivalent sûr apparaissent sous <strong>Options sans équivalent</strong> et empêchent la poursuite de l’installation. Aucune n’est ignorée silencieusement."
|
||||
},
|
||||
{
|
||||
"title": "Demander les secrets",
|
||||
"body": "Les variables dont le nom évoque un mot de passe, un jeton ou une clé sont demandées comme données sensibles pendant l’installation."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-review.png",
|
||||
"alt": "Récapitulatif de l’interprétation du fichier Compose par ProxMenux",
|
||||
"caption": "Récapitulatif affiché avant la demande du VMID et des ressources."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Après validation du récapitulatif, le parcours est celui du catalogue : nom, mode par défaut ou avancé, VMID, CPU, mémoire, réseau, démarrage avec le nœud, chemins persistants et supplémentaires, périphériques compatibles et récapitulatif final."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "examples",
|
||||
"title": "Exemples de saisie",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Compose",
|
||||
"code": "services:\n app:\n image: ghcr.io/example/app:latest\n ports:\n - \"8080:8080\"\n volumes:\n - ./config:/config\n - /srv/media:/media\n environment:\n TZ: Europe/Madrid"
|
||||
},
|
||||
{
|
||||
"title": "docker run",
|
||||
"code": "docker run -d \\\n --name app \\\n -p 8080:8080 \\\n -e TZ=Europe/Madrid \\\n -v app-config:/config \\\n -v /srv/media:/media \\\n ghcr.io/example/app:latest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "oci-compose",
|
||||
"title": "Un oci-compose rédigé à la main",
|
||||
"intro": "Un oci-compose est le fichier JSON à partir duquel une application est installée. Le catalogue en conserve un par application. Le même format peut être rédigé à la main et installé avec cette option.",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Dans un fichier rédigé à la main, l’auteur définit l’image, les ports, les variables, les volumes et les questions de l’installation. ProxMenux complète le reste à la lecture. Le format permet d’exprimer ce que Compose ne prévoit pas : texte d’une question, mot de passe généré à l’installation, profil GPU, propriétaire de chaque volume, contrôle du premier démarrage ou identifiants affichés à la fin."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Vérifier",
|
||||
"body": "Un fichier contenant des erreurs n’est pas installé. Chaque erreur indique le champ concerné ; un JSON invalide signale la ligne et la colonne."
|
||||
},
|
||||
{
|
||||
"title": "Examiner",
|
||||
"body": "Un fichier valide affiche ce qu’il installe : image, adresse web, ports, chemins persistants, variables demandées et fichiers écrits pendant l’installation."
|
||||
},
|
||||
{
|
||||
"title": "Installer",
|
||||
"body": "L’installation suit le même parcours que pour toute application du catalogue, avec les paramètres par défaut ou avancés."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Un fichier qui détermine les privilèges",
|
||||
"body": "Un oci-compose détermine ce qui est monté dans le conteneur et avec quels privilèges. La vérification le précise avant l’installation : n’installez que des fichiers de sources fiables."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le <readmeLink>README du moteur OCI</readmeLink> décrit le format bloc par bloc avec deux exemples complets. Un enregistrement d’installation peut aussi être lu de cette façon : seul le modèle d’origine est utilisé, sans aucune des réponses de cette installation."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "private-registries",
|
||||
"title": "Images de registres privés",
|
||||
"intro": "Une image d’un registre privé, comme un paquet privé GitHub ou un dépôt privé Docker Hub, est lue avec un compte enregistré dans ProxMenux.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Le registre refuse l’accès à l’image",
|
||||
"body": "Si le registre indique que l’image nécessite un compte, la vérification propose de s’y connecter, puis lit à nouveau l’image."
|
||||
},
|
||||
{
|
||||
"title": "Se connecter",
|
||||
"body": "Un nom d’utilisateur et un mot de passe ou jeton autorisé à télécharger l’image. Le registre les vérifie ; ils ne sont enregistrés que s’il les accepte."
|
||||
},
|
||||
{
|
||||
"title": "Installer et maintenir à jour",
|
||||
"body": "Ce compte sert au téléchargement pendant l’installation, ainsi qu’aux mises à jour, à Modifier, à Recréer, au watchdog et à la recherche de mises à jour du Monitor, sur chaque nœud du cluster."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "<strong>Comptes de registres</strong>, dans le menu principal d’OCI manager Apps, affiche les comptes enregistrés par registre et utilisateur, jamais leurs secrets. Chaque compte permet de vérifier, télécharger ou installer une image, ainsi que de mettre à jour ou supprimer les identifiants."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"GitHub (<code>ghcr.io</code>) : l’utilisateur est le compte GitHub et le mot de passe un jeton d’accès personnel avec l’autorisation <code>read:packages</code>.",
|
||||
"Docker Hub (<code>docker.io</code>) : l’utilisateur est le compte Docker Hub et le mot de passe un jeton d’accès avec autorisation de lecture.",
|
||||
"Autres registres, y compris avec un port propre comme <code>registry.example.com:5000</code> : l’utilisateur et le mot de passe ou jeton fournis par ce registre."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Où les comptes sont conservés",
|
||||
"body": "Dans <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, lisible uniquement par root, dans le même dossier que les mots de passe de stockage de Proxmox. <code>/etc/pve</code> est partagé entre tous les nœuds du cluster : un compte ajouté sur un nœud est donc utilisé partout. La sauvegarde de l’hôte inclut ce fichier et la désinstallation de ProxMenux le supprime de tous les nœuds."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "limits",
|
||||
"title": "Définitions qui ne sont pas installées",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Un Dockerfile sans image publiée : l’image doit d’abord être construite et publiée dans un registre OCI.",
|
||||
"Un fichier Compose à plusieurs services : cette option installe un seul service par conteneur, même si plusieurs services utilisent la même image.",
|
||||
"<code>configs</code>, secrets externes ou formats de périphériques impossibles à adapter sans ambiguïté.",
|
||||
"Substitutions shell comme <code>$(command)</code> : il faut saisir directement la valeur résultante.",
|
||||
"Options <code>docker run</code> non reconnues et <code>--env-file</code> : utilisez plutôt un fichier Compose aux valeurs explicites."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,392 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Dispositifs et accélération ProxMenux",
|
||||
"description": "Comment OCI manager Apps rend les GPU, NVIDIA, Coral, USB, FUSE et autres périphériques accessibles à un conteneur OCI sous forme de ressources natives Proxmox VE validées."
|
||||
},
|
||||
"header": {
|
||||
"title": "Dispositifs et accélération",
|
||||
"description": "GPU, NVIDIA, Coral, USB, FUSE et les dispositifs de blocs deviennent des ressources natives validées Proxmox VE du conteneur.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "principle",
|
||||
"title": "L'appareil dont l'application a besoin, pas l'hôte entier",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Un appareil demandé par le fichier Compose ou par le profil d'application devient une entrée concrète <code>devN</code> ou un montage LXC. Demander un GPU, un périphérique USB ou un Coral ne rend pas le conteneur privilégié."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Inventaire des hôtes",
|
||||
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "fournisseur et\npermissions vérifiées"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "même périphérique\nGID effectif"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "origin",
|
||||
"title": "D'où vient la demande de l'appareil",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Source",
|
||||
"Ce qui est lu",
|
||||
"Ce que fait l'installateur"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Docker Compose",
|
||||
"Demandes <code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> et NVIDIA",
|
||||
"Chaque exigence devient une demande d'appareil présentée pour examen"
|
||||
],
|
||||
[
|
||||
"Profil du catalogue",
|
||||
"La prise en charge réelle des GPU, de Coral, d’OpenCL, d’USB ou de FUSE par l’application",
|
||||
"Seules les options validées pour cette image sont proposées"
|
||||
],
|
||||
[
|
||||
"métadonnées d'images et documentation",
|
||||
"VA-API, Selkies, LinuxServer mods ou le NVIDIA runtime",
|
||||
"Les variables documentées et la préparation sont ajoutées"
|
||||
],
|
||||
[
|
||||
"Sélection de l'utilisateur",
|
||||
"CPU uniquement, Intel/AMD, OpenCL, NVIDIA ou un appareil optionnel",
|
||||
"La sélection est stockée dans le contrat d'instance"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Les périphériques détectés ne sont pas ajoutés automatiquement",
|
||||
"body": "L'hôte est inventorié, mais seuls les appareils déclarés par le fichier Compose ou par un profil compatible sont proposés et attachés. Un GPU, un dongle USB ou un Coral présent sur l'hôte n'est pas exposé à tous les LXC."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "identify",
|
||||
"title": "Comment le périphérique hôte est identifié",
|
||||
"intro": "Avant que le LXC ne soit modifié, l'appareil est lu sur l'hôte et correspond au profil choisi.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Type",
|
||||
"Identité",
|
||||
"Validation"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD DRM",
|
||||
"<code>/dev/dri/renderD*</code> et <code>/sys/class/drm/NODE/device/vendor</code>",
|
||||
"Dispositif de caractères avec fournisseur <code>0x8086</code> (Intel) ou <code>0x1002</code> (AMD)"
|
||||
],
|
||||
[
|
||||
"AMD OpenCL",
|
||||
"Le nœud de rendu, plus <code>/dev/kfd</code> lorsque le profil en a besoin",
|
||||
"Existence, type, fournisseur, autorisations et compatibilité déclarée"
|
||||
],
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Le nœud de rendu, <code>/dev/kfd</code> et la génération indiquée par le pilote de calcul dans <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"Une génération pour laquelle l’image ROCm de l’application contient des noyaux de calcul — les GPU RDNA2 cités et les plus récents — est proposée telle quelle. Les autres GPU de ces familles, comme les Radeon 680M et 780M, sont proposés à titre expérimental et jamais présélectionnés : ROCm ne les prend pas officiellement en charge, l’application les présente comme la génération de leur famille (<code>HSA_OVERRIDE_GFX_VERSION</code>) et l’installateur demande confirmation avant de télécharger l’image plus volumineuse. Une GPU plus ancienne, telle que la partie graphique intégrée d’un Ryzen 5000U, n’est pas proposée et Immich conserve la reconnaissance sur le CPU."
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"<code>nvidia-smi</code> et <code>nvidia-container-cli</code>",
|
||||
"GPU, UUID, PCI bus, version pilote, Toolkit, <code>/dev/nvidia*</code> nœuds, binaires et bibliothèques"
|
||||
],
|
||||
[
|
||||
"Coral PCIe/M.2",
|
||||
"<code>/dev/apex_N</code> et son lien dans <code>/sys/dev/char/MAJOR:MINOR</code>",
|
||||
"Nœud de caractère, majeur/mineur, propriétaire, GID et permissions"
|
||||
],
|
||||
[
|
||||
"USB et série",
|
||||
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> ou <code>/dev/bus/usb/BBB/DDD</code>",
|
||||
"Nœud de caractère; pour USB aussi fournisseur, produit et série lorsque sysfs les publie"
|
||||
],
|
||||
[
|
||||
"KVM, TUN, FUSE, vidéo et SCSI générique",
|
||||
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> ou <code>/dev/sgN</code>",
|
||||
"Chemin pris en charge, type de nœud et permissions effectives"
|
||||
],
|
||||
[
|
||||
"Lecteur optique",
|
||||
"<code>/dev/srN</code>",
|
||||
"Un périphérique bloc"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Ce qui se passe pendant l'installation",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Le modèle offre ses profils",
|
||||
"body": "Par exemple CPU seulement, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL ou NVIDIA. Les options appartiennent à l'image, pas à un menu commun."
|
||||
},
|
||||
{
|
||||
"title": "Un profil est choisi",
|
||||
"body": "Il définit les nœuds de périphérique, l'environnement, les mods ou l'exécution dont l'application a besoin."
|
||||
},
|
||||
{
|
||||
"title": "Un chemin est proposé",
|
||||
"body": "Pour DRM, <code>/dev/dri/renderD128</code>, qui peut être modifié sur un hôte avec plusieurs nœuds de rendu. Pour USB ou série, le nœud précis est sélectionné."
|
||||
},
|
||||
{
|
||||
"title": "Validation",
|
||||
"body": "L'existence, le type, le fournisseur autorisé, les autorisations et le GID sont vérifiés. Une inadéquation arrête l'opération."
|
||||
},
|
||||
{
|
||||
"title": "Le contrat est écrit",
|
||||
"body": "Chemin, mode, GID, accès à l'écriture et profil sont enregistrés pour les mises à jour et les recréations de conteneurs."
|
||||
},
|
||||
{
|
||||
"title": "Ajout et vérification",
|
||||
"body": "<code>pct set</code> ajoute l'entrée <code>devN</code> et l'accès est ensuite vérifié à l'intérieur du LXC. Les images LinuxServer sont également vérifiées en tant qu'utilisateur <code>abc</code>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "config",
|
||||
"title": "Comment il apparaît dans la configuration LXC",
|
||||
"intro": "Valeurs indicatives : <code>dev0</code> et <code>dev1</code> sont les emplacements libres attribués par Proxmox VE ; <code>renderD128</code>, <code>apex_0</code> et le GID dépendent du matériel du nœud.",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Intel/AMD VA-API",
|
||||
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Coral PCIe/M.2",
|
||||
"code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Un périphérique USB spécifique",
|
||||
"code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "AMD OpenCL",
|
||||
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le GID est lu avec <code>stat</code> sur l'hôte et écrit à l'entrée <code>devN</code>; les groupes <code>render</code> et <code>video</code> ne sont pas supposés avoir un nombre fixe. L'appareil conserve le même chemin <code>/dev</code> à l'intérieur du LXC, où les propres mécanismes de l'application le recherchent."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "profiles",
|
||||
"title": "Profils qu'une image peut offrir",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Profil",
|
||||
"Configuration résultante",
|
||||
"Proposé quand"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD VA-API",
|
||||
"Le noeud de rendu <code>/dev/dri</code>",
|
||||
"L'application prend en charge l'accélération vidéo"
|
||||
],
|
||||
[
|
||||
"OpenCL",
|
||||
"Noeud Render, <code>/dev/kfd</code> au besoin et le mod officiel",
|
||||
"L'image ou le profil le documente"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"Dispositifs pilotes et bibliothèques de l'hôte",
|
||||
"L’hôte dispose d’un pilote fonctionnel et de NVIDIA Container Toolkit"
|
||||
],
|
||||
[
|
||||
"Coral",
|
||||
"<code>/dev/apex_0</code> ou le bus USB",
|
||||
"Le profil déclare la prise en charge de Coral (Frigate)"
|
||||
],
|
||||
[
|
||||
"USB, série, FUSE",
|
||||
"Un seul appareil, un arbre validé ou une fonction LXC",
|
||||
"Le contrat le demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "nvidia",
|
||||
"title": "NVIDIA",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Prérequis sur le nœud : NVIDIA Container Toolkit",
|
||||
"body": "Un pilote fonctionnel sur Proxmox VE ne suffit pas à donner une GPU NVIDIA à une image OCI. OCI Manager Apps utilise <code>nvidia-container-cli</code>, de NVIDIA Container Toolkit, pour identifier les appareils et obtenir les binaires et les bibliothèques qui correspondent au pilote chargé."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le <nvidiaLink>installateur NVIDIA de ProxMenux</nvidiaLink> installe NVIDIA Container Toolkit du dépôt officiel NVIDIA avec le pilote. Il vérifie ses quatre paquets, valide <code>nvidia-container-cli</code> et enregistre le résultat dans le journal de changement de <auditLink>Audit & Report</auditLink>."
|
||||
},
|
||||
{
|
||||
"p": "Ces deux commandes sur l'hôte montrent si le pilote et le Toolkit sont disponibles :"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-smi -L\nnvidia-container-cli --version"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Sur un hôte où le pilote a été installé par d'autres moyens, le Toolkit est installé à partir du dépôt stable officiel:"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "apt-get update\napt-get install -y --no-install-recommends ca-certificates curl gnupg2\n\ncurl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \\\n | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg\n\ncurl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \\\n | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \\\n > /etc/apt/sources.list.d/nvidia-container-toolkit.list\n\napt-get update\napt-get install -y nvidia-container-toolkit libnvidia-container-tools"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "L’inventaire utilisé par OCI manager Apps provient de la sortie de :"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "La configuration d'exécution Docker n'est pas impliquée",
|
||||
"body": "Les conteneurs sont des LXC natifs sans démon Docker : <code>nvidia-ctk runtime configure --runtime=docker</code> ne joue donc aucun rôle. ProxMenux interroge directement <code>nvidia-container-cli</code> et écrit les périphériques et montages LXC. Les commandes et plateformes prises en charge sont maintenues dans le <toolkitLink>guide d’installation de NVIDIA Container Toolkit</toolkitLink>."
|
||||
}
|
||||
},
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "cpu",
|
||||
"title": "Inventaire issu du pilote",
|
||||
"body": "<code>nvidia-container-cli</code> énumère les nœuds de périphérique, les binaires, les micrologiciels et les bibliothèques du pilote installé."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Pas de version fixe",
|
||||
"body": "Le modèle ne nomme pas les fichiers de bibliothèque. Le profil est généré à partir de l'hôte actuel."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Montages en lecture seule",
|
||||
"body": "Les bibliothèques hôtes sont montées en lecture seule au lieu d'être copiées dans le conteneur."
|
||||
},
|
||||
{
|
||||
"icon": "hardDrive",
|
||||
"title": "Changements de pilote",
|
||||
"body": "Après un changement de pilote, l'inventaire est généré à nouveau avant le démarrage des LXC touchés."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"code": {
|
||||
"title": "Résultat NVIDIA (simplifié)",
|
||||
"code": "devN: path=/dev/nvidia0,...\ndevN: path=/dev/nvidiactl,...\ndevN: path=/dev/nvidia-uvm,...\nlxc.mount.entry: HOST_LIBRARY CONTAINER_LIBRARY none ro,bind,create=file 0 0"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Passer uniquement <code>/dev/nvidia0</code> ne suffit pas. Les composants espace utilisateur du pilote chargé sont montés en lecture seule, et <code>nvidia-smi</code> fonctionne ensuite à l'intérieur du LXC pour comparer GPU, UUID, PCI bus et version avec l'inventaire hôte."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "usb",
|
||||
"title": "Coral USB, série et USB",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "La numérotation USB peut changer",
|
||||
"body": "Un chemin tel que <code>/dev/bus/usb/003/004</code> peut changer lorsque le périphérique est reconnecté ou que l'hôte redémarre. Le profil enregistre le fournisseur, le produit et la série lorsqu'ils sont disponibles, mais une nouvelle adresse de bus n'est pas automatiquement réaffectée."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Un périphérique est donné par son nœud concret : <code>/dev/ttyUSB0</code>, <code>/dev/ttyACM0</code>, <code>/dev/apex_0</code> ou <code>/dev/bus/usb/BBB/DDD</code>. Passer l'intégralité de <code>/dev</code> n'est pas accepté. Coral est proposé uniquement aux applications dont le profil le déclare."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "trees",
|
||||
"title": "Arbres de périphériques et fonctionnalités LXC",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Demande",
|
||||
"Configuration résultante",
|
||||
"Portée"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>/dev/dvb</code>, <code>/dev/snd</code> ou <code>/dev/bus/usb</code>",
|
||||
"Chaque noeud de caractère de l'arbre obtient sa propre entrée <code>devN</code> avec le mode hôte et GID",
|
||||
"Seulement l'arbre demandé, pas le reste de <code>/dev</code>"
|
||||
],
|
||||
[
|
||||
"<code>/dev/fuse</code>",
|
||||
"Le nœud et, lorsque le profil en a besoin, la fonction <code>fuse=1</code>",
|
||||
"FUSE seul ne publie pas de montages sur d'autres LXC"
|
||||
],
|
||||
[
|
||||
"<code>/dev/net/tun</code>",
|
||||
"Une entrée <code>devN</code> sur le même chemin à l'intérieur du LXC",
|
||||
"La configuration VPN ou réseau reste dans l'application"
|
||||
],
|
||||
[
|
||||
"<code>/dev/kvm</code>",
|
||||
"Une entrée <code>devN</code> validée",
|
||||
"Offert seulement lorsque le contrat le demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "security",
|
||||
"title": "Confirmations par niveau de risque",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Les périphériques concrets, les privilèges facultatifs, les privilèges requis, la relaxation AppArmor ou seccomp et l'accès à l'espace de noms PID hôte sont traités comme des cas distincts, et non sous une seule étiquette privilégiée générique. Chaque option présentant un risque est expliquée et confirmée lors de l'installation."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,213 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "OCI manager Apps | ProxMenux",
|
||||
"description": "Exécutez des images OCI officielles dans des conteneurs LXC natifs de Proxmox VE, avec des données persistantes, l’accès aux périphériques, des applications à plusieurs conteneurs et des mises à jour transactionnelles."
|
||||
},
|
||||
"header": {
|
||||
"title": "OCI manager Apps",
|
||||
"description": "Les images OCI officielles s’exécutent dans des conteneurs LXC natifs de Proxmox VE. L’image reste celle publiée par son mainteneur ; ProxMenux reproduit l’environnement que Docker Compose aurait créé autour d’elle.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "model",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Une image OCI, un LXC natif",
|
||||
"body": "Aucun moteur Docker ne s’exécute dans les conteneurs. Proxmox VE importe le système de fichiers de l’image et ses métadonnées OCI. L’application devient le processus principal d’un LXC natif, administré avec les mêmes outils que les autres conteneurs du nœud."
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Source",
|
||||
"detail": "Image OCI\nCompose et documentation"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "Contrat JSON\nvalidation et planification"
|
||||
},
|
||||
{
|
||||
"label": "Proxmox VE",
|
||||
"detail": "LXC natif\nvolumes et périphériques"
|
||||
}
|
||||
],
|
||||
"caption": "L’application d’origine est conservée : son environnement est décrit de façon déclarative, puis reproduit."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "where",
|
||||
"title": "Où le trouver",
|
||||
"intro": "Sur le nœud Proxmox, en tant que root, ouvrez <strong>OCI manager Apps (Technology Preview)</strong> dans le menu principal de ProxMenux. Le premier écran propose :",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"<strong>Rechercher des applications</strong> : rechercher par nom dans tout le catalogue.",
|
||||
"<strong>Toutes les applications</strong> : afficher le catalogue complet et le nombre d’applications.",
|
||||
"<strong>Gérer les applications OCI installées</strong> : mettre à jour, modifier, supprimer ou récupérer les applications déjà installées.",
|
||||
"<strong>Comptes de registres</strong> : gérer les comptes utilisés pour installer et mettre à jour des images provenant de registres privés.",
|
||||
"<strong>Installer une image absente du catalogue</strong> : adapter un fichier Compose, une commande <code>docker run</code> ou une référence d’image.",
|
||||
"Les catégories du catalogue, chacune avec son nombre d’applications."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/main-menu.png",
|
||||
"alt": "Écran principal d’OCI manager Apps avec recherche, catalogue complet, gestion des applications, images hors catalogue et catégories.",
|
||||
"caption": "Écran principal d’OCI manager Apps."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "La sélection d’une application affiche sa description, l’image utilisée et deux modes d’installation. <strong>Installer avec les paramètres par défaut</strong> ne application que les choix essentiels : stockage, emplacement des données, adresse et démarrage. <strong>Installer avec les paramètres avancés</strong> présente toutes les décisions dans l’ordre : VMID et ressources, stockage de chaque chemin, pont réseau et périphériques."
|
||||
},
|
||||
{
|
||||
"p": "Les applications effectivement testées affichent <strong>Vérifié</strong> dans cette vue et portent un ✓ dans les listes, que le test ait été effectué dans le laboratoire ProxMenux ou par la communauté."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "beta",
|
||||
"title": "Pourquoi le label Technology Preview est conservé",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "OCI manager Apps conserve le label <strong>Technology Preview</strong> que Proxmox VE attribue aux conteneurs d’applications créés à partir d’images OCI, dont la prise en charge a été introduite dans Proxmox VE 9.1. Ce label concerne la technologie sur laquelle repose OCI manager Apps, et non le moteur de ProxMenux : le comportement de ces conteneurs peut encore changer entre les versions de Proxmox VE. Le label restera en place jusqu’à ce que Proxmox VE considère cette prise en charge comme stable."
|
||||
},
|
||||
{
|
||||
"p": "Le moteur d’OCI manager Apps est testé dans le laboratoire ProxMenux : installation, mise à jour, modification, recréation, sauvegarde, restauration, migration et watchdog. Chaque application est vérifiée séparément. Celles qui ont été effectivement testées affichent <strong>Vérifié</strong> et portent un ✓ dans les listes."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "translation",
|
||||
"title": "Comment Docker décrit les besoins et comment OCI manager Apps les applique",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Besoin",
|
||||
"Expression dans Docker",
|
||||
"Mise en œuvre par OCI manager Apps"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Exécuter l’application",
|
||||
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
|
||||
"Le rootfs OCI et le processus principal du LXC"
|
||||
],
|
||||
[
|
||||
"Conserver la configuration",
|
||||
"<code>volumes: /config</code>",
|
||||
"Un volume persistant <code>mpN</code> inclus dans la sauvegarde, ou un répertoire de l’hôte."
|
||||
],
|
||||
[
|
||||
"Rendre le service accessible",
|
||||
"<code>ports</code>",
|
||||
"Une adresse propre au LXC et l’URL d’accès au service."
|
||||
],
|
||||
[
|
||||
"Utiliser du matériel",
|
||||
"<code>devices</code>, <code>group_add</code>",
|
||||
"Des entrées <code>devN</code> avec le GID effectif de l’hôte et un profil validé."
|
||||
],
|
||||
[
|
||||
"Relier les dépendances",
|
||||
"<code>networks</code>, <code>depends_on</code>",
|
||||
"Un pont réseau privé, des adresses fixes, un ordre de démarrage et des contrôles de bon fonctionnement."
|
||||
],
|
||||
[
|
||||
"Mettre à jour",
|
||||
"Télécharger avec <code>pull</code> et recréer",
|
||||
"Un nouveau rootfs avec le même contrat de persistance."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "kept",
|
||||
"title": "Ce qui est conservé et ce qui change",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Conservé",
|
||||
"body": "L’image officielle, ses chemins internes, son environnement, son processus de démarrage et sa documentation d’utilisation."
|
||||
},
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Adapté",
|
||||
"body": "L’environnement d’exécution : le réseau, la persistance, les périphériques, les permissions et les dépendances utilisent les mécanismes LXC natifs de Proxmox VE."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Sans équivalent",
|
||||
"body": "Une option Compose sans équivalent sûr est signalée comme un point bloquant. Les modèles comportant des points bloquants ne sont pas proposés à l’installation, et les options sensibles doivent être confirmées pendant l’assistant."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Enregistré",
|
||||
"body": "Le digest de l’image, les ressources, les chemins, le réseau, les périphériques et l’appartenance à une pile sont enregistrés dans le contrat de l’instance. Les mises à jour et les recréations reproduisent ce contrat."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "pages",
|
||||
"title": "Pages de cette section",
|
||||
"blocks": [
|
||||
{
|
||||
"next": {
|
||||
"items": [
|
||||
{
|
||||
"label": "Comment une image OCI est adaptée",
|
||||
"href": "/docs/oci-manager/architecture",
|
||||
"tail": "De l’image et de son fichier Compose à un LXC natif."
|
||||
},
|
||||
{
|
||||
"label": "Installer une image absente du catalogue",
|
||||
"href": "/docs/oci-manager/custom-image",
|
||||
"tail": "Un fichier Compose, une commande docker run ou une référence d’image."
|
||||
},
|
||||
{
|
||||
"label": "Données, chemins et réseau",
|
||||
"href": "/docs/oci-manager/storage-network",
|
||||
"tail": "Volumes du conteneur, répertoires de l’hôte, montages rclone et adresses."
|
||||
},
|
||||
{
|
||||
"label": "Périphériques et accélération",
|
||||
"href": "/docs/oci-manager/hardware",
|
||||
"tail": "GPU, NVIDIA, Coral, USB et autres périphériques."
|
||||
},
|
||||
{
|
||||
"label": "Applications à plusieurs conteneurs",
|
||||
"href": "/docs/oci-manager/stacks",
|
||||
"tail": "Application, base de données et cache dans des LXC coordonnés."
|
||||
},
|
||||
{
|
||||
"label": "Installer, mettre à jour et modifier",
|
||||
"href": "/docs/oci-manager/lifecycle",
|
||||
"tail": "Le contrat de l’instance et ses opérations."
|
||||
},
|
||||
{
|
||||
"label": "Dans ProxMenux Monitor",
|
||||
"href": "/docs/oci-manager/monitor",
|
||||
"tail": "Versions, mises à jour, sortie console et terminal."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,499 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Installer, mettre à jour et modifier | ProxMenux",
|
||||
"description": "Le contrat d'instance d'un conteneur OCI et les opérations qui s'appuient dessus : mise à jour, modification, suppression, reprise d'une opération interrompue et remise en service après une restauration sur cet hôte ou un autre."
|
||||
},
|
||||
"header": {
|
||||
"title": "Installer, mettre à jour et modifier",
|
||||
"description": "Chaque instance conserve un contrat reproductible, ce qui permet de remplacer son rootfs sans perdre sa configuration ni ses données persistantes.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "contract",
|
||||
"title": "Le contrat d'instance",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Après l'installation, la configuration effective est enregistrée dans <code>/usr/local/share/proxmenux/oci/instances/VMID/oci-compose.json</code>. Il ne s'agit pas d'une copie du fichier Compose d'origine : c'est le contrat reproductible du LXC présent sur cet hôte."
|
||||
},
|
||||
{
|
||||
"code": {
|
||||
"code": "instances/\n└── 105/\n └── oci-compose.json\n ├── image and resolved digest\n ├── resources and network\n ├── environment (secrets protected)\n ├── container disks and host directories\n ├── hardware profile and devices\n ├── console log and terminal mode\n └── stack membership and lifecycle"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Une copie du contrat est conservée dans le conteneur, dans <code>/.proxmenux/oci-record.json</code>, et seul l'utilisateur root du conteneur peut la lire. Une sauvegarde du conteneur emporte donc toujours le contrat en vigueur au moment de la sauvegarde. Une seconde copie est conservée dans <code>/etc/pve/priv/proxmenux/oci</code>, un emplacement partagé par tous les nœuds du cluster et lisible uniquement par root sur l'hôte. Les deux copies sont écrites après chaque installation, mise à jour et modification."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "manage",
|
||||
"title": "Gérer les applications OCI installées",
|
||||
"intro": "Cette option de l'écran principal liste les instances enregistrées avec leur application et image. Chacun d'eux est vérifié par rapport à son contrat avant toute action; un CT qui ne correspond plus à son enregistrement n'est ni modifié ni supprimé. La même mise à jour et le même éditeur sont proposés dans l'onglet Mises à jour de <monitorLink>ProxMenux Monitor</monitorLink>.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Ce qui change",
|
||||
"Ce qui est gardé"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Mettre à jour l'image avec la configuration enregistrée",
|
||||
"Le rootfs est remplacé par l'image actuellement publiée sur le canal enregistré",
|
||||
"Contrat, disques de conteneur, répertoires hôtes, réseau et appareils"
|
||||
],
|
||||
[
|
||||
"Modifier : éditer les ressources, le réseau, les chemins et le GPU",
|
||||
"L'éditeur s'ouvre avec le contrat actuel; le CT est reconstruit avec les modifications",
|
||||
"Les données des disques de conteneur et des répertoires hôtes"
|
||||
],
|
||||
[
|
||||
"Watchdog : redémarrer l'application lorsqu'elle plante",
|
||||
"Détermine si l'application est relancée lorsqu'elle s'arrête d'elle-même. Rien n'est reconstruit",
|
||||
"L'ensemble de l'installation ; seul le choix est sauvegardé dans le contrat"
|
||||
],
|
||||
[
|
||||
"Supprimer: supprimer l'application et ses conteneurs",
|
||||
"Le LXC, ou chaque membre d'une pile, et leurs contrats sont supprimés",
|
||||
"Répertoires hôtes, avec leur contenu"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Pour une application à plusieurs conteneurs, le menu propose <strong>Mettre à jour tous les conteneurs de l'application</strong>, <strong>Modifier les chemins et périphériques supplémentaires</strong>, <strong>Recréer tous les conteneurs avec leur configuration enregistrée</strong>, le watchdog et la suppression. Modifier ajoute ou supprime les chemins et périphériques supplémentaires du conteneur applicatif sans rien reconstruire et, pour Immich, change le composant qui exécute la reconnaissance. Recréer reconstruit chaque conteneur à partir de l'image utilisée lors de son installation, sans en chercher une plus récente."
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/manage-menu.png",
|
||||
"alt": "Liste des applications OCI installées, avec les options de mise à jour, de modification et de suppression",
|
||||
"caption": "Gérer les applications OCI installées."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "update",
|
||||
"title": "Une mise à jour transactionnelle",
|
||||
"blocks": [
|
||||
{
|
||||
"mermaid": {
|
||||
"chartCode": "sequenceDiagram\n participant U as {{user}}\n participant P as ProxMenux\n participant R as {{registry}}\n participant X as Proxmox VE\n U->>P: {{update}}\n P->>R: {{resolve}}\n R-->>P: digest\n P->>P: {{verify}}\n P->>X: {{backup}}\n P->>X: {{import}}\n P->>X: {{reapply}}\n X-->>P: healthcheck\n alt {{healthy}}\n P-->>U: {{commit}}\n else {{failure}}\n P->>X: Rollback\n P-->>U: {{restored}}\n end",
|
||||
"labels": {
|
||||
"user": "Utilisateur",
|
||||
"registry": "Registre OCI",
|
||||
"update": "Mettre à jour l'instance",
|
||||
"resolve": "Résoudre la balise",
|
||||
"verify": "Vérifier l’archive et effectuer les contrôles préalables",
|
||||
"backup": "Arrêter et sauvegarder le CT",
|
||||
"import": "Importer le nouveau rootfs",
|
||||
"reapply": "Appliquer à nouveau le contrat",
|
||||
"healthy": "sain",
|
||||
"failure": "défaillance",
|
||||
"commit": "Contrat publié avec le nouveau digest",
|
||||
"restored": "instance précédente restaurée"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Lorsque le registre sert encore le digest installé, rien n'est téléchargé et l'instance n'est pas touchée.",
|
||||
"La nouvelle image est vérifiée couche par couche avant l'arrêt du CT. Un téléchargement qui arrive endommagé est récupéré une deuxième fois ; une image déjà mise en cache qui échoue la vérification est à nouveau téléchargée.",
|
||||
"Les paramètres modifiés dans Proxmox VE après l'installation (mémoire, swap, cœurs, limite et priorité du CPU, démarrage avec le nœud) sont conservés et intégrés au nouveau contrat.",
|
||||
"L'interface LAN ajoutée par la suite Arr et les applications à plusieurs conteneurs (<code>net1</code>), ainsi que l'ordre de démarrage (<code>startup</code>), sont réappliqués tels quels au nouveau conteneur.",
|
||||
"Toute autre différence entre le CT et son contrat arrête la mise à jour avant que le CT ne soit arrêté."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Avant",
|
||||
"detail": "rootfs A\n/config mp0\n/media répertoire de l’hôte"
|
||||
},
|
||||
{
|
||||
"label": "Mise à jour",
|
||||
"detail": "remplace uniquement\nle rootfs"
|
||||
},
|
||||
{
|
||||
"label": "Après",
|
||||
"detail": "rootfs B\n/config mp0\n/media répertoire de l’hôte"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Avant tout arrêt, l'opération vérifie l'espace nécessaire à la sauvegarde : les données utilisées sur les volumes inclus, plus une marge. La sauvegarde est écrite à côté de l'enregistrement de l'application, sur le disque système de l'hôte. Si l'espace y est insuffisant, le menu demande un autre stockage de l'hôte acceptant les sauvegardes. La sauvegarde y est créée puis supprimée à la fin de l'opération. Ce choix est mémorisé pour l'application, y compris pour les mises à jour planifiées. Si aucun stockage n'a assez de place, l'opération est refusée et l'application reste inchangée. L'espace nécessaire à la nouvelle image est également vérifié avant son téléchargement."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "recovery",
|
||||
"title": "Récupération d'une opération interrompue",
|
||||
"intro": "Une mise à jour et un changement utilisent une transaction persistante. Si le processus, le terminal ou le nœud est interrompu après l'arrêt du CT, l'opération n'est pas prise comme terminée.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Marqueur en attente",
|
||||
"body": "À l'ouverture de Gérer les applications OCI installées, l'état enregistré indique que le remplacement n'a jamais été publié."
|
||||
},
|
||||
{
|
||||
"title": "Afficher l’état",
|
||||
"body": "Affiche la phase qui a été atteinte sans changer de conteneur ou de données."
|
||||
},
|
||||
{
|
||||
"title": "Récupérer l'installation précédente",
|
||||
"body": "Restaure la sauvegarde native vérifiée réalisée avant le remplacement, ainsi que le contrat précédent."
|
||||
},
|
||||
{
|
||||
"title": "Piles traitées comme une unité",
|
||||
"body": "Pour une application multi-conteneurs, chaque membre est récupéré du même point de transaction, pas seulement celui sélectionné."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Les répertoires de l’hôte sont exclus du retour arrière",
|
||||
"body": "La sauvegarde couvre le rootfs et les disques du conteneur qui y sont inclus. Un répertoire de l’hôte n’est pas rétabli à son état précédent, car d’autres LXC peuvent utiliser ses données."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "watchdog",
|
||||
"title": "Watchdog: redémarrer une application qui s'arrête",
|
||||
"intro": "Proxmox n'a pas de politique de redémarrage : quand le processus d'un conteneur applicatif se termine, le conteneur reste arrêté. Si le watchdog est activé, une application qui s'arrête d'elle-même est relancée. Il joue pour une application OCI le rôle de <code>restart: unless-stopped</code> dans un fichier Compose.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce qui se passe",
|
||||
"Avec le watchdog activé"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"L’application plante ou son processus se termine",
|
||||
"Le conteneur est relancé en quelques secondes"
|
||||
],
|
||||
[
|
||||
"Il est arrêté ou éteint depuis Proxmox, depuis le Monitor ou avec <code>pct</code>",
|
||||
"Il reste arrêté jusqu’à ce que quelqu’un le démarre"
|
||||
],
|
||||
[
|
||||
"Une sauvegarde, une migration ou une opération ProxMenux travaille dessus",
|
||||
"Rien n'est fait jusqu'à la fin"
|
||||
],
|
||||
[
|
||||
"Il était déjà arrêté au démarrage de l’hôte",
|
||||
"Il reste arrêté ; cela dépend de <strong>Démarrer avec Proxmox</strong>"
|
||||
],
|
||||
[
|
||||
"Il s’arrête systématiquement juste après son démarrage",
|
||||
"Pour une application qui s’arrête quelques secondes après son démarrage ou qui ne démarre pas, cinq tentatives sont effectuées, séparées par des délais de 30 secondes, 1, 2 et 5 minutes. Elle reste ensuite arrêtée et une notification est envoyée"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "L'installateur pose la question dans les deux modes d'installation et propose la valeur déclarée par la recette de l'application. Ce réglage peut ensuite être modifié dans <strong>Gérer les applications OCI installées</strong> ou avec le commutateur <strong>Watchdog</strong> du conteneur dans <monitorLink>ProxMenux Monitor</monitorLink>. Il s'applique à tous les conteneurs d'une application à plusieurs conteneurs. Un seul service de l'hôte, <code>proxmenux-oci-watchdog.service</code>, surveille les applications pour lesquelles il est activé ; son installation figure dans l'onglet Modifications d'Audit & Report."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Ce que l'hôte ne peut pas dire",
|
||||
"body": "Le code de sortie de l'application ne parvient pas à l'hôte. Un arrêt normal et un plantage sont donc indiscernables et entraînent tous deux un redémarrage, comme avec <code>always</code> et <code>unless-stopped</code> dans Docker. Un arrêt demandé en dehors de Proxmox, avec <code>lxc-stop</code> ou <code>systemctl</code>, ne laisse aucune tâche d'arrêt et est interprété comme un arrêt spontané."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Sauvegarde, restauration et un autre hôte",
|
||||
"intro": "Une sauvegarde réalisée avec vzdump ou Proxmox Backup Server contient le conteneur, les disques du conteneur sélectionnés pour la sauvegarde et la copie de son contrat. Les éléments conservés par l'installation sur l'hôte n'en font pas partie. <strong>Gérer les applications OCI installées</strong> détecte les conteneurs restaurés sur un hôte dépourvu de leur contrat, après une nouvelle installation de Proxmox ou sur un autre hôte, et propose de les enregistrer à nouveau.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Restaurer les conteneurs dans Proxmox",
|
||||
"body": "Depuis le stockage de sauvegarde, avec l’ID d’origine ou tout autre ID libre. Une application à plusieurs conteneurs nécessite tous ses conteneurs."
|
||||
},
|
||||
{
|
||||
"title": "Ouvrir la gestion des applications OCI installées",
|
||||
"body": "Les conteneurs restaurés sont listés et la récupération est proposée. Le bouton <strong>Récupérer</strong> de l’onglet Mises à jour de <monitorLink>ProxMenux Monitor</monitorLink> ouvre la même récupération."
|
||||
},
|
||||
{
|
||||
"title": "Vérifier avant de changer",
|
||||
"body": "La récupération vérifie que l'hôte a tout ce dont chaque application a besoin. Une application qui ne peut pas être récupérée entière est laissée comme elle a été trouvée, avec la raison."
|
||||
},
|
||||
{
|
||||
"title": "Enregistrer et démarrer",
|
||||
"body": "Le contrat est enregistré sur cet hôte et les éléments que l'installation y conservait sont réécrits. Le démarrage des applications fait l'objet d'une question distincte, à laquelle il faut répondre Non si les conteneurs d'origine fonctionnent encore sur un autre hôte."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-offer.png",
|
||||
"alt": "Boîte de dialogue qui énumère les conteneurs restaurés et propose de les récupérer",
|
||||
"caption": "La récupération offerte lors de l'ouverture de la gestion des applications OCI installées."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce que l'hôte a gardé",
|
||||
"Après la récupération"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Contrat d’instance",
|
||||
"Enregistré à partir de la copie conservée dans le conteneur et vérifié par rapport à la configuration restaurée par Proxmox"
|
||||
],
|
||||
[
|
||||
"Réseau privé d'une application multiconteneurs",
|
||||
"Recréé avec le même pont et sous-réseau ; les adresses fixes des conteneurs ne changent pas"
|
||||
],
|
||||
[
|
||||
"Ordre de démarrage d'une application multi-conteneurs",
|
||||
"Le hookscript de dépendance et son contrat sont à nouveau installés ; les extraits sont activés sur le stockage <code>local</code> quand aucun stockage ne les accepte"
|
||||
],
|
||||
[
|
||||
"Sysctls réseau et fichier host-monitor",
|
||||
"Ecrit à nouveau en <code>/etc/pve/proxmenux</code>"
|
||||
],
|
||||
[
|
||||
"Environnement d’exécution NVIDIA",
|
||||
"Le hook d’un conteneur non privilégié est réinstallé. Un conteneur privilégié reçoit les fichiers de pilote de cet hôte à la place de ceux de son hôte d’origine"
|
||||
],
|
||||
[
|
||||
"Rclone montage",
|
||||
"Le hookscript et les programmes qui publient le montage sont à nouveau écrits, avec les mêmes vues sur l'hôte"
|
||||
],
|
||||
[
|
||||
"Règle du pare-feu d'un moniteur hôte",
|
||||
"Une nouvelle confirmation est demandée pour son port web et le sous-réseau du pont sur cet hôte"
|
||||
],
|
||||
[
|
||||
"<code>lost+found</code> de chaque disque restauré",
|
||||
"Supprimé s’il est vide ; une restauration le crée et certaines applications ne démarrent pas s’il figure dans leurs données"
|
||||
],
|
||||
[
|
||||
"Disques restaurés sur un autre stockage",
|
||||
"Le contrat est mis à jour pour refléter le stockage sur lequel ils se trouvent maintenant"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Un conteneur restauré avec un autre ID conserve son application. Le contrat, son journal de console, ses paramètres sysctl réseau, le hookscript d'un montage Rclone et l'ordre de démarrage d'une application à plusieurs conteneurs sont enregistrés avec les ID des conteneurs sur cet hôte."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce qui empêche une récupération",
|
||||
"Que faire"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Il manque un conteneur d'une application multiconteneurs",
|
||||
"Restaurer aussi; l'application est récupérée entière"
|
||||
],
|
||||
[
|
||||
"Le sous-réseau privé est déjà utilisé sur cet hôte",
|
||||
"La récupération est annulée et rien n’est modifié : les adresses des conteneurs sont fixes et ne sont pas déplacées vers un autre sous-réseau"
|
||||
],
|
||||
[
|
||||
"Un répertoire hôte n'existe pas",
|
||||
"Monter ou créer avec ses données; une sauvegarde du conteneur n'inclut pas les répertoires hôtes"
|
||||
],
|
||||
[
|
||||
"Un périphérique n'existe pas sur cet hôte",
|
||||
"Connectez-le ou retirez-le du conteneur dans Proxmox"
|
||||
],
|
||||
[
|
||||
"Une application avec NVIDIA sur un hôte sans pilote",
|
||||
"Installez le pilote NVIDIA et le Container Toolkit"
|
||||
],
|
||||
[
|
||||
"La sauvegarde a été effectuée avant l'existence de la copie du contrat",
|
||||
"Le conteneur reste en tant que LXC ordinaire et n'est pas offert à nouveau"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Un conteneur qui revient",
|
||||
"body": "Un conteneur restauré sur lui-même à partir d'une ancienne sauvegarde, retourné à un instantané ou retourné d'un autre noeud porte le contrat de l'état dans lequel il est. Lorsqu'il est sélectionné pour une opération et que son contrat diffère de celui de cet hôte, l'opération ne démarre pas et le conteneur est offert pour récupération."
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-result.png",
|
||||
"alt": "Résultat de la récupération avec le réseau privé, l’ordre de démarrage et les conteneurs enregistrés",
|
||||
"caption": "Résultat d'une reprise, étape par étape."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "remove",
|
||||
"title": "Supprimer une application OCI",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Avant la confirmation, un résumé est établi à partir de la configuration réelle : les conteneurs supprimés, les données supprimées avec eux, le réseau privé libéré et les répertoires de l’hôte conservés. La réponse par défaut est <strong>Non</strong>, car les données des disques supprimés ne pourront pas être récupérées ensuite."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ressource",
|
||||
"À la suppression",
|
||||
"Motifs"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"rootfs et disques du conteneur",
|
||||
"Supprimés",
|
||||
"Ils appartiennent seulement au conteneur"
|
||||
],
|
||||
[
|
||||
"Répertoire de l'hôte",
|
||||
"Conservé, avec son contenu",
|
||||
"D'autres applications peuvent l'utiliser"
|
||||
],
|
||||
[
|
||||
"Fichiers hôtes du conteneur",
|
||||
"Supprimés",
|
||||
"Son journal de console, ses paramètres sysctl réseau, le hookscript du montage Rclone et son inscription dans l’onglet App de ProxMenux Monitor ne servent à aucun autre conteneur"
|
||||
],
|
||||
[
|
||||
"Fichiers partagés par plusieurs installations",
|
||||
"Supprimé avec la dernière installation qui les utilise",
|
||||
"Le fichier de surveillance de l’hôte et le hookscript des dépendances des applications à plusieurs conteneurs"
|
||||
],
|
||||
[
|
||||
"Contrat d’instance",
|
||||
"Supprimé après une suppression réussie",
|
||||
"Aucun CT ne lui est plus associé"
|
||||
],
|
||||
[
|
||||
"Pont privé d'une pile",
|
||||
"Relâché avec la pile",
|
||||
"Il n'y a plus de membres pour se connecter"
|
||||
],
|
||||
[
|
||||
"Réseau partagé par la suite Arr",
|
||||
"Libéré lors de la suppression de la dernière application de la suite",
|
||||
"Chaque application de la suite est indépendante et se supprime séparément"
|
||||
],
|
||||
[
|
||||
"Un seul membre d'une pile",
|
||||
"Non enlevé seul",
|
||||
"Toute l'application est retirée, donc aucune pile n'est laissée incomplète"
|
||||
],
|
||||
[
|
||||
"Un conteneur sur un autre noeud du cluster",
|
||||
"Non enlevé",
|
||||
"Son enregistrement et ses fichiers sur l’hôte se trouvent sur le nœud où il a été installé : il faut le supprimer là-bas, après l’y avoir remigré"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/remove-summary.png",
|
||||
"alt": "Résumé de suppression avec les conteneurs, les données et les répertoires hôtes touchés",
|
||||
"caption": "Le résumé de suppression, construit à partir de la configuration réelle."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "archives",
|
||||
"title": "Images téléchargées et espace hôte",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "L’archive OCI sert à construire le rootfs ; le CT en cours d’exécution ne la lit pas. Après une installation ou une mise à jour, les archives téléchargées pendant cette opération sont listées avec leur taille et leur suppression est proposée. Les supprimer libère de l’espace sans affecter le conteneur ni ses données."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Les mises à jour ne nécessitent pas l'archive",
|
||||
"body": "Sans l'archive, une mise à jour résout le canal enregistré et télécharge le nouveau digest. Avec elle, une archive n'est réutilisée que lorsque sa référence et son intégrité correspondent à ce qui est demandé."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "registry",
|
||||
"title": "Registre et nettoyage",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "À l'ouverture de <strong>Gérer les applications OCI installées</strong>, les restes des conteneurs absents de tous les nœuds du cluster sont d'abord supprimés : l'enregistrement conservé comme historique après une suppression depuis l'interface Proxmox, et les fichiers de l'hôte laissés par une suppression. Un enregistrement lié à une opération interrompue est conservé, car sa sauvegarde peut encore être nécessaire. Les volumes et répertoires de l'hôte ne sont jamais supprimés par déduction."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "cluster",
|
||||
"title": "Dans un cluster : migration et haute disponibilité",
|
||||
"intro": "Un conteneur OCI est un LXC Proxmox ordinaire : il peut être migré ou géré par HA comme les autres, avec les mêmes limites. Les éléments nécessaires à son démarrage sont conservés à un emplacement accessible à tous les nœuds du cluster.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Partie",
|
||||
"Sur un autre noeud du cluster"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Journal de console",
|
||||
"Le conteneur crée <code>/var/log/proxmenux/oci</code> avant de démarrer, quel que soit le nœud qui l’exécute. Chaque nœud conserve le journal des démarrages qu’il a effectués."
|
||||
],
|
||||
[
|
||||
"Paramètres sysctl réseau et surveillance de l’hôte",
|
||||
"Conservés dans <code>/etc/pve/proxmenux</code>, partagé par tous les nœuds du cluster, afin qu’un conteneur migré les retrouve."
|
||||
],
|
||||
[
|
||||
"Disques du conteneur",
|
||||
"Proxmox les déplace avec le conteneur. HA nécessite que leurs données soient disponibles sur le nœud cible, via un stockage partagé ou une configuration de réplication prise en charge."
|
||||
],
|
||||
[
|
||||
"Répertoires et périphériques de l'hôte",
|
||||
"Les mêmes règles que n'importe quel LXC : un répertoire hôte doit exister sur le nœud cible et être marqué comme partagé, et un GPU, Coral ou NPU doit y être présent."
|
||||
],
|
||||
[
|
||||
"Enregistrement ProxMenux",
|
||||
"Le contrat reste sur le nœud où l'application a été installée, et chaque nœud lit la copie conservée dans <code>/etc/pve/priv/proxmenux/oci</code>. Une application à un seul conteneur est enregistrée sur son nœud de destination après migration lors de l'ouverture de <strong>Gérer les applications OCI installées</strong> ou du lancement d'une opération la concernant. Une application à plusieurs conteneurs y est proposée à la récupération, car son réseau privé doit être créé sur ce nœud."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Pas pour une disponibilité élevée",
|
||||
"body": "Une application à plusieurs conteneurs relie ses membres par un pont privé du nœud sur lequel elle a été installée ; ses membres restent donc sur ce nœud. Un outil de surveillance de l’hôte, comme Glances en mode hôte ou Netdata, surveille le nœud qui l’exécute ; le déplacer reviendrait à surveiller un autre nœud."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Une sauvegarde restaurée à l'extérieur du cluster obtient les fichiers de <code>/etc/pve/proxmenux</code> que le conteneur utilise lorsque l'application est récupérée."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "channel",
|
||||
"title": "Une étiquette évolutive n’est pas une mise à jour sans surveillance",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Le catalogue installe l’étiquette évolutive publiée par son responsable, mais le digest effectif est résolu et enregistré, puis modifié uniquement lors d’une mise à jour explicite avec contrôles préalables et retour arrière. <monitorLink>ProxMenux Monitor</monitorLink> compare le digest installé à celui publié par le registre et affiche une indication et une notification lorsqu’une nouvelle image est disponible."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,213 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Conteneurs OCI dans ProxMenux Monitor | ProxMenux",
|
||||
"description": "Ce que ProxMenux Monitor montre pour un conteneur installé par OCI Manager Apps : versions d'applications et d'images, nouvelles images, sortie console et terminal Proxmox VE."
|
||||
},
|
||||
"header": {
|
||||
"title": "Dans ProxMenux Monitor",
|
||||
"description": "Un conteneur installé par OCI Manager Apps apparaît dans VMs & LXCs comme n'importe quel autre LXC. Sa fenêtre modale lit l'enregistrement d'installation : versions d'application et d'image, nouvelles images, sortie console et terminal.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "L'enregistrement est la source",
|
||||
"body": "OCI manager Apps connaît l’application installée et sa provenance. Le Monitor lit cet enregistrement d’installation au lieu de rechercher l’application dans le conteneur. Ces informations restent donc disponibles que le conteneur fonctionne ou soit arrêté."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"onglet",
|
||||
"Ce qui change pour un conteneur OCI"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"État",
|
||||
"Un commutateur <strong>Watchdog</strong> sous Démarrer au démarrage: l'application est redémarrée quand elle s'arrête seule"
|
||||
],
|
||||
[
|
||||
"Application",
|
||||
"L'application est identifiée à partir du dossier et les mises à jour sont suivies par l'image"
|
||||
],
|
||||
[
|
||||
"Mises à jour",
|
||||
"L'image est mise à jour ou l'application modifiée, avec le même flux que le menu OCI"
|
||||
],
|
||||
[
|
||||
"Montages",
|
||||
"Disques de conteneurs et répertoires hôtes, avec leur utilisation"
|
||||
],
|
||||
[
|
||||
"Journaux",
|
||||
"Uniquement pour les conteneurs OCI : la sortie console de l'application"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "app",
|
||||
"title": "Application",
|
||||
"intro": "L'onglet <appLink>App</appLink> offre l'application installée comme détection, avec le nom, le logo, le port et le schéma de l'enregistrement. L'enregistrer ouvre l'éditeur avec la méthode <strong>OCI image (installée par ProxMenux)</strong>, qui ne nécessite aucune configuration.",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Application",
|
||||
"body": "La version de l'application à l'intérieur de l'image, lue à partir de l'image elle-même : son environnement ou son étiquette <code>org.opencontainers.image.version</code>. Cette information est indicative."
|
||||
},
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Image",
|
||||
"body": "La date de construction et le digest de l'image installée. La mise à jour est décidée ici: le digest installé est comparé à celui que le registre publie aujourd'hui pour le même tag."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Lorsque le registre publie un nouveau digest, la carte affiche <strong>Nouvelle image</strong> avec sa date et son digest, même si la version de l'application à l'intérieur n'a pas changé: une reconstruction sur une base mise à jour est une mise à jour.",
|
||||
"Lorsque les digests correspondent, la carte lit <strong>Version</strong>.",
|
||||
"La carte relie au dépôt de l'image : son projet GitHub, ou sa page Docker Hub pour une image officielle.",
|
||||
"Le lien d'accès utilise l'adresse LAN du conteneur, également pour le membre principal d'une application multi-conteneurs, qui a une deuxième adresse sur son réseau privé.",
|
||||
"Le bouton <strong>Actualiser les données</strong> relit l’enregistrement et le registre des images. Les options de recherche ou d’enregistrement d’une autre application ne sont pas proposées : le conteneur contient exactement l’application de son enregistrement."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/monitor-app-tab.png",
|
||||
"alt": "Onglet App d'un conteneur OCI avec la version de l'application, l'image et le lien du dépôt",
|
||||
"caption": "Onglet Application d’un conteneur installé par OCI manager Apps."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "La vérification s'effectue une fois par jour avec les vérifications de mise à jour du moniteur, et <strong>Actualiser les données</strong> l'exécute immédiatement. Une nouvelle image est envoyée sous forme de notification via les canaux configurés dans <notificationsLink>Notifications</notificationsLink>. La mise à jour est appliquée depuis l'onglet Mises à jour."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "updates",
|
||||
"title": "Mises à jour",
|
||||
"intro": "Pour un conteneur installé par OCI manager Apps, l’onglet Mises à jour présente l’application avec son image installée et, si le registre en publie une, la nouvelle image, au même format que les autres applications. Les outils de mise à jour des paquets et applications d’un LXC ordinaire ne sont pas proposés.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Bouton",
|
||||
"Ce qu'il ouvre"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Mise à jour",
|
||||
"La mise à jour de <lifecycleLink>Gérer les applications OCI installées</lifecycleLink> pour ce conteneur, dans le terminal de Monitor. Elle peut être lancée avec ou sans nouvelle image ; sans nouvelle image, rien ne change. Pour une application multiconteneur, elle met à jour tous les membres."
|
||||
],
|
||||
[
|
||||
"Modifier",
|
||||
"L'éditeur de l'application (ressources, réseau, chemins et GPU). Dans une application multi-conteneurs, il ajoute ou supprime les chemins et périphériques supplémentaires du conteneur d'application et, dans Immich, modifie ce qui exécute la reconnaissance."
|
||||
],
|
||||
[
|
||||
"Récupérer",
|
||||
"Remplace Mise à jour quand une opération sur le conteneur a été interrompue, et ouvre sa récupération."
|
||||
],
|
||||
[
|
||||
"Récupérer (conteneur restauré)",
|
||||
"Affiché pour un conteneur restauré depuis une sauvegarde sans contrat sur cet hôte, sous <strong>Application OCI restaurée</strong>. Ouvre la <lifecycleLink>récupération</lifecycleLink> dans le terminal de Monitor ; Mettre à jour et Modifier apparaissent après son enregistrement."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Les modifications externes, les répertoires hôtes et les applications multiconteneurs sont traités comme dans le menu OCI. Dans une application multi-conteneurs, les boutons et les options apparaissent uniquement sur le conteneur principal; les autres membres montrent leur image, une note qu'ils sont mis à jour à partir du conteneur principal et un bouton qui l'ouvre. Lorsque le terminal se ferme, l'image, l'enregistrement et les montages sont à nouveau lus."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Comportement"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Conserver la sauvegarde prise avant la mise à jour",
|
||||
"Chaque mise à jour sauvegarde le conteneur pour le restaurer si la mise à jour échoue. Avec cette option, la même sauvegarde est conservée dans le stockage choisi et apparaît parmi les sauvegardes du CT; sur Proxmox Backup Server une sauvegarde est écrite avant la mise à jour."
|
||||
],
|
||||
[
|
||||
"Mises à jour programmées",
|
||||
"L’image n’est mise à jour à l’heure choisie que si le registre en publie une nouvelle, avec la possibilité d’attendre qu’elle ait 1, 3, 7 ou 14 jours. Un conteneur modifié en dehors de ProxMenux est ignoré et signalé."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "logs",
|
||||
"title": "Journaux",
|
||||
"intro": "L'onglet Logs n'apparaît que pour les conteneurs installés par l'OCI Manager Apps, entre Montages et Sauvegardes. Il montre la sortie standard et l'erreur du processus principal de l'image, la même sortie <code>docker logs</code> affiche pour un conteneur Docker.",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"La sortie est conservée sur l'hôte dans <code>/var/log/proxmenux/oci/VMID.console.log</code> (mode 0600), dès le premier démarrage et sur les redémarrages, de sorte qu'il peut être lu avec le conteneur arrêté.",
|
||||
"Le fichier est tourné à 10 MB, en conservant trois copies compressées (<code>/etc/logrotate.d/proxmenux-oci</code>).",
|
||||
"Chaque démarrage du conteneur est marqué dans la sortie. L'onglet affiche la sortie depuis le dernier démarrage par défaut; <strong>L'historique complet</strong> montre également les précédents.",
|
||||
"Lorsque l'application est supprimée, sa sortie est supprimée avec elle.",
|
||||
"Les 100, 500 ou 1000 dernières lignes sont affichées. Quand le conteneur fonctionne, les nouvelles lignes sont suivies en direct ; faire défiler vers le haut met le suivi en pause et <strong>Suivre</strong> le reprend.",
|
||||
"Un filtre n'indique que les lignes qui contiennent un texte, et <strong>Télécharger</strong> enregistre les lignes chargées.",
|
||||
"Les codes de couleur sont supprimés et une ligne qu'une barre de progression redessine est affichée dans son état final.",
|
||||
"L’onglet relit le fichier à chaque ouverture, sans mise en cache."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Identifiants du premier démarrage",
|
||||
"body": "Les images qui impriment un mot de passe généré sur leur premier démarrage le laissent dans cette sortie, comme le fait <code>docker logs</code>. L'installateur le lit à partir de là pour le montrer dans son résumé."
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/monitor-logs-tab.png",
|
||||
"alt": "Onglet Logs avec la sortie console d'un conteneur OCI, le sélecteur de ligne, le filtre et le bouton suivant",
|
||||
"caption": "Sortie de console d'un conteneur OCI."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "terminal",
|
||||
"title": "Console Proxmox VE",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Une image OCI exécute son propre processus comme PID 1 et aucun service de connexion, de sorte que la console par défaut d'un LXC ouvrirait un terminal où rien ne répond. Les conteneurs installés par OCI Manager Apps sont créés avec <code>cmode: shell</code> : la console Proxmox VE ouvre un shell avec <code>lxc-attach</code>, l'équivalent de <code>docker exec</code>, avec l'application en cours d'exécution intacte."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Le shell est celui attribué à root dans l’image par <code>/etc/passwd</code>. Si root n’a pas de shell ou si l’image n’en contient aucun, la console par défaut est conservée.",
|
||||
"Le shell s’exécute en tant que root dans le conteneur, sans mot de passe. Qui peut l'ouvrir est décidé par la permission <code>VM.Console</code> de Proxmox VE.",
|
||||
"Le terminal du moniteur entre dans le conteneur avec <code>pct enter</code>, qui fonctionne de la même manière."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "mounts",
|
||||
"title": "Montages",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "L'onglet <mountsLink>Mounts</mountsLink> énumère les disques de conteneur et les répertoires hôtes du conteneur. L'utilisation d'un disque de conteneur sur le stockage de blocs comme LVM-thin est lue à partir du système de fichiers du disque, qui est monté uniquement à l'intérieur du conteneur."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,404 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Applications multiconteneurs ProxMenux",
|
||||
"description": "Comment OCI manager Apps transforme une application avec sa base de données et cache en LXC natifs coordonnés: plan, réseau privé, crochet de dépendance, validation et mises à jour transactionnelles."
|
||||
},
|
||||
"header": {
|
||||
"title": "Applications à plusieurs conteneurs",
|
||||
"description": "Une application avec sa base de données, cache et d'autres services devient plusieurs LXC natifs coordonnés, installés et mis à jour comme un seul.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Une application pour l'utilisateur, plusieurs LXC pour Proxmox VE",
|
||||
"body": "Une définition multi-conteneurs est une entrée du catalogue. L'installateur crée un LXC natif par service et garde leurs dépendances explicites. Immich, Nextcloud, Paperless-ngx et Tandoor sont installés de cette façon."
|
||||
}
|
||||
},
|
||||
{
|
||||
"mermaid": {
|
||||
"chartCode": "flowchart LR\n C[\"Docker Compose\"] --> O[\"{{plan}}\"]\n O --> A[\"{{app}}<br/>{{appNet}}\"]\n O --> D[\"{{db}}<br/>{{private}}\"]\n O --> R[\"{{cache}}<br/>{{private}}\"]\n V1[(\"config\")] --> A\n V2[(\"database\")] --> D\n V3[(\"cache\")] --> R\n D --> A\n R --> A",
|
||||
"labels": {
|
||||
"plan": "Plan de la pile",
|
||||
"app": "Application LXC",
|
||||
"appNet": "LAN + privé",
|
||||
"db": "PostgreSQL LXC",
|
||||
"cache": "Valkey LXC",
|
||||
"private": "privé"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "plan",
|
||||
"title": "1. Le plan, avant l'existence d'un conteneur",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Aucun LXC n'est créé pendant que la définition Compose est interprétée. Un plan complet vient en premier, avec chaque membre, image, VMID, réseau, chemin, secret, ordre et bilan de santé. Si le plan n'est pas cohérent, l'installation ne démarre pas."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Élément du plan",
|
||||
"Contenu",
|
||||
"Vérification avant de créer quelque chose"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Membres",
|
||||
"Application principale, base de données, cache, apprentissage automatique et autres dépendances",
|
||||
"VMID uniques, rôles connus et exactement un membre principal"
|
||||
],
|
||||
[
|
||||
"Images",
|
||||
"Référence roulante, architecture et digest résolu de chaque service",
|
||||
"Toutes existent, prennent en charge l’architecture et réussissent la vérification d’intégrité OCI"
|
||||
],
|
||||
[
|
||||
"Réseau",
|
||||
"Pont privé, sous-net, une adresse fixe par service et accès au réseau local pour le membre principal",
|
||||
"Aucune collision avec des ponts ou sous-réseaux existants et aucune adresse répétée"
|
||||
],
|
||||
[
|
||||
"Persistance",
|
||||
"Disques de conteneur, répertoires hôtes, propriétaires et sauvegarde",
|
||||
"Aucun chemin de chevauchement, stockage disponible et autorisations déclarées"
|
||||
],
|
||||
[
|
||||
"Secrets",
|
||||
"Mot de passe de la base de données, clés d'application et identifiants initiaux",
|
||||
"Généré une fois et donné seulement aux membres qui les utilisent"
|
||||
],
|
||||
[
|
||||
"Cycle de vie",
|
||||
"Ordre de départ, ordre d'arrêt et bilan de santé par membre",
|
||||
"L'application principale démarre en dernier et s'arrête en premier"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "create",
|
||||
"title": "2. Création, membre par membre",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Réserve tous les VMID",
|
||||
"body": "L'inventaire Proxmox VE et le registre des instances sont vérifiés. Un CT existant n'est pas adopté et un contrat qui appartient encore à une autre instance n'est pas réutilisé."
|
||||
},
|
||||
{
|
||||
"title": "Préparer chaque image",
|
||||
"body": "Toutes les images sont résolues, téléchargées et vérifiées avant la création du premier conteneur."
|
||||
},
|
||||
{
|
||||
"title": "Créer chaque rootfs",
|
||||
"body": "Les métadonnées OCI officielles sont importées, puis l’identité de l’instance ProxMenux et le rôle du membre sont ajoutés."
|
||||
},
|
||||
{
|
||||
"title": "Réseau privé",
|
||||
"body": "Un bridge et un sous-net sont créés et chaque membre obtient son adresse fixe; seul le membre principal obtient également l'interface LAN."
|
||||
},
|
||||
{
|
||||
"title": "Persistance",
|
||||
"body": "Chaque base de données et configuration obtient son propre disque conteneur ; seules les données destinées à être partagées utilisent des répertoires hôtes."
|
||||
},
|
||||
{
|
||||
"title": "Environnement",
|
||||
"body": "Les points d’accès internes, les secrets partagés et les variables de service sont écrits. L’application accède à ses dépendances via leurs adresses privées réservées."
|
||||
},
|
||||
{
|
||||
"title": "Enregistrement",
|
||||
"body": "Chaque membre enregistre sa configuration native, les changements rootfs que les mises à jour doivent reproduire et sa relation avec la pile."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "checks",
|
||||
"title": "3. Démarrer et vérifier chaque conteneur",
|
||||
"intro": "Un LXC créé ne signifie pas un service prêt. Les dépendances commencent dans l'ordre et chacune passe un contrôle spécifique à son service.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Services",
|
||||
"Vérification",
|
||||
"Ce qu'il montre"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"PostgreSQL",
|
||||
"<code>pg_isready</code> dans le CT avec l'hôte, l'utilisateur et la base de données attendus",
|
||||
"Le serveur accepte les connexions pour la base de données configurée"
|
||||
],
|
||||
[
|
||||
"Redis / Valkey",
|
||||
"<code>redis-cli</code> ou <code>valkey-cli</code> <code>PING</code> contre son adresse privée",
|
||||
"Le broker écoute et répond"
|
||||
],
|
||||
[
|
||||
"Immich apprentissage automatique",
|
||||
"HTTP <code>GET /ping</code>, avec vérification de l’environnement d’exécution GPU sélectionné",
|
||||
"Le service répond et l’accélération demandée n’a pas basculé vers le CPU"
|
||||
],
|
||||
[
|
||||
"Nextcloud",
|
||||
"<code>GET /status.php</code> avec <code>installed=true</code>, <code>maintenance=false</code> et <code>needsDbUpgrade=false</code>",
|
||||
"Initialisation terminée sans aucune migration en attente"
|
||||
],
|
||||
[
|
||||
"Paperless-ngx / Tandoor",
|
||||
"HTTP sur l'adresse LAN et le port réel du service",
|
||||
"La façade et ses dépendances servent l’application"
|
||||
],
|
||||
[
|
||||
"Application principale",
|
||||
"L'extrémité de son modèle, par exemple <code>/api/server/ping</code> dans Immich",
|
||||
"La pile entière fonctionne à travers l'application qui utilise les dépendances"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "En cours d’exécution ne signifie pas opérationnel",
|
||||
"body": "L’état en cours d’exécution indique seulement que le processus LXC existe. Si le service propose une meilleure vérification, un contrôle exec ou HTTP avec délai maximal est utilisé. Si un membre s’arrête ou échoue à son contrôle, la pile n’est pas déclarée installée."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "hook",
|
||||
"title": "4. Le crochet de dépendance",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Le crochet est placé uniquement sur le conteneur principal d'une pile dépendante. Proxmox VE conserve le script comme un extrait et l'exécute comme le <code>hookscript</code> de ce CT. La recette de pile n'est pas écrite dans le script : elle vit dans un contrat privé séparé."
|
||||
},
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Configuration principale CT",
|
||||
"code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh"
|
||||
},
|
||||
{
|
||||
"title": "Contrat privé (exemple)",
|
||||
"code": "/etc/pve/priv/proxmenux-stack-VMID.json\n{\n \"schema\": 1,\n \"stack\": \"immich\",\n \"dependencies\": [\n {\"vmid\": 107, \"label\": \"PostgreSQL\", \"healthcheck\": {...}},\n {\"vmid\": 108, \"label\": \"Valkey\", \"healthcheck\": {...}},\n {\"vmid\": 106, \"label\": \"Machine Learning\", \"healthcheck\": {...}}\n ]\n}"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"snippet": {
|
||||
"summary": "Source complète de proxmenux-stack-dependencies.sh",
|
||||
"pathCode": "local:snippets/proxmenux-stack-dependencies.sh",
|
||||
"snippetCode": "stackDependencyHook"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le script est le même pour chaque pile. Les VMID, noms, types de vérifications et délais proviennent du contrat privé <code>/etc/pve/priv/proxmenux-stack-VMID.json</code> de chaque pile."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Proxmox VE appelle pre-start",
|
||||
"body": "Avant le démarrage du CT principal, le crochet fonctionne avec son VMID et la phase du cycle de vie."
|
||||
},
|
||||
{
|
||||
"title": "Un verrou par pile",
|
||||
"body": "<code>flock</code> sur <code>/run/lock/proxmenux-stack-VMID.lock</code> empêche deux séquences de démarrage en même temps."
|
||||
},
|
||||
{
|
||||
"title": "Le contrat est lu et validé",
|
||||
"body": "Un schéma connu, des dépendances numériques, des étiquettes, un contrôle exec, http ou running et un délai maximal positif sont requis."
|
||||
},
|
||||
{
|
||||
"title": "Dépendances dans l'ordre",
|
||||
"body": "Chaque CT doit exister ; un CT arrêté est démarré, tandis qu’un CT déjà actif n’est pas redémarré."
|
||||
},
|
||||
{
|
||||
"title": "Attendre que le service soit prêt",
|
||||
"body": "Le contrôle est effectué toutes les deux secondes, et le CT est également confirmé être toujours en cours d'exécution."
|
||||
},
|
||||
{
|
||||
"title": "Le principal CT démarre",
|
||||
"body": "Lorsque chaque dépendance est prête, prédémarrage se termine et Proxmox VE démarre l'application."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Le crochet n'arrête pas les dépendances",
|
||||
"body": "Les phases post-démarrage, pré-stop et post-stop ne font rien. L'arrêt du principal CT laisse tourner PostgreSQL, Redis, Valkey ou l'apprentissage automatique. Le crochet commande le démarrage; il ne transforme pas plusieurs LXC en un seul processus."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Type",
|
||||
"Exemple",
|
||||
"Démarrages suivants"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Pile dépendante",
|
||||
"Immich, Nextcloud, application avec PostgreSQL",
|
||||
"Le crochet du CT principal commence les dépendances et les attend"
|
||||
],
|
||||
[
|
||||
"Suite d'application",
|
||||
"Suite Arr",
|
||||
"Aucun membre principal: chaque LXC suit son propre <code>onboot</code>"
|
||||
],
|
||||
[
|
||||
"Application unique",
|
||||
"Jellyfin",
|
||||
"Proxmox VE commence directement ce LXC"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "stack-checks",
|
||||
"title": "5. Contrôle de la pile dans son ensemble",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Chaque VMID existe, est unique et conserve l'identité d'instance attendue.",
|
||||
"Chaque contrat appartient à la même pile, conserve son rôle et sa configuration native enregistrée.",
|
||||
"Le membre principal est le dernier en <code>start_order</code> et le premier en <code>stop_order</code>.",
|
||||
"Aucun membre, volume ou ajustement du rootfs ne manque.",
|
||||
"Le crochet pointe vers l'extrait officiel, son contenu est inchangé et son contrat correspond à la recette de la pile.",
|
||||
"Les images et les digests observés correspondent aux archives OCI préparées.",
|
||||
"Les appareils, les profils GPU, les montages, les secrets et les paramètres correspondent encore aux contrats.",
|
||||
"Une fois toutes les dépendances validées, le point d’accès de l’application principale vérifie l’intégration entre les membres."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "manage",
|
||||
"title": "Gestion d'une pile installée",
|
||||
"intro": "Dans <strong>Gérer les applications OCI installées</strong>, chaque membre mène à toute la pile. Le menu propose <strong>Mettre à jour tous les conteneurs de l’application</strong>, <strong>Modifier les chemins et périphériques supplémentaires</strong>, <strong>Recréer tous les conteneurs avec leur configuration enregistrée</strong> et <strong>Retirer : supprimer l’application et ses conteneurs</strong>. La recréation reconstruit chaque conteneur depuis son image d’origine, identifiée par le digest enregistré, sans chercher d’image plus récente. Elle suit les mêmes étapes qu’une mise à jour et est proposée pour les piles pouvant être mises à jour.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Tout membre",
|
||||
"body": "Le contrat du membre nomme le VMID principal et la liste complète des membres."
|
||||
},
|
||||
{
|
||||
"title": "La pile est reproductible",
|
||||
"body": "Les identités, les contrats, le crochet, les adaptations et un replay coordonné pour cette recette sont validés."
|
||||
},
|
||||
{
|
||||
"title": "Images d'abord",
|
||||
"body": "L'application n'est pas arrêtée avant que chaque digest ait été résolu, téléchargé et vérifié."
|
||||
},
|
||||
{
|
||||
"title": "Arrêter les membres et sauvegarder l’ensemble",
|
||||
"body": "Les sauvegardes natives vérifiées sont prises avec la pile arrêtée, de sorte que l'application et les bases de données appartiennent au même moment."
|
||||
},
|
||||
{
|
||||
"title": "Mettre à jour et vérifier chaque membre",
|
||||
"body": "Adaptation, réseau, montages, secrets et dispositifs sont appliqués à nouveau avant le contrôle de santé de chaque membre."
|
||||
},
|
||||
{
|
||||
"title": "Publier ou récupérer tout",
|
||||
"body": "Les nouveaux contrats ne sont publiés que lorsque chaque membre passe. Si on échoue, chaque membre est rétabli."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Modifier",
|
||||
"Ce qui change",
|
||||
"Ce qui est gardé"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Chemins et périphériques supplémentaires",
|
||||
"Ils sont ajoutés ou retirés du conteneur d'application, qui redémarre. Rien n'est reconstruit",
|
||||
"Les données de l'application, sa base de données et les autres conteneurs"
|
||||
],
|
||||
[
|
||||
"Ce qui exécute la reconnaissance (Immich)",
|
||||
"Le conteneur d'apprentissage de la machine prend l'image et les appareils du CPU ou d'un GPU de l'hôte. Toute l'application est arrêtée et mise à jour, comme dans une mise à jour",
|
||||
"Le cache modèle, la bibliothèque et la base de données. Si quelque chose échoue, les conteneurs précédents et le choix précédent sont restaurés"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Une pile sans replay coordonné n'est pas mise à jour",
|
||||
"body": "Si la préparation d'une pile ne peut pas être reproduite, la mise à jour est refusée avant l'arrêt de la pile. L'application continue à fonctionner comme elle est."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "failure",
|
||||
"title": "6. Quand quelque chose échoue",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Pendant une installation, une erreur s'arrête et enlève les conteneurs incomplets que l'opération a créés, et le pont privé si l'opération l'a créé. Une pile n'est pas publiée comme valide jusqu'à ce que la séquence entière se termine."
|
||||
},
|
||||
{
|
||||
"p": "Une mise à jour est transactionnelle: toutes les images sont préparées d'abord, puis la pile s'arrête, chaque membre est sauvegardé et la sauvegarde vérifiée, et seulement alors chaque rootfs est remplacé. Les membres commencent un par un avec leur bilan de santé; si on échoue, chaque membre est restauré à partir du même ensemble de sauvegardes, de sorte que la base de données et l'application n'appartiennent jamais à différents moments."
|
||||
},
|
||||
{
|
||||
"mermaid": {
|
||||
"chartCode": "flowchart LR\n P[\"{{prepare}}\"] --> S[\"{{stop}}\"]\n S --> B[\"{{backup}}\"]\n B --> R[\"{{replace}}\"]\n R --> H{\"{{healthy}}\"}\n H -- \"{{yes}}\" --> C[\"{{commit}}\"]\n H -- \"{{no}}\" --> X[\"{{rollback}}\"]",
|
||||
"labels": {
|
||||
"prepare": "Préparer chaque image",
|
||||
"stop": "Stop, membre principal d'abord",
|
||||
"backup": "Sauvegarde vérifiée de chaque CT",
|
||||
"replace": "Remplacer le rootfs",
|
||||
"healthy": "Tous opérationnels ?",
|
||||
"yes": "Oui",
|
||||
"no": "Non",
|
||||
"commit": "Publier les contrats",
|
||||
"rollback": "Restaurer chaque membre"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "not-assumed",
|
||||
"title": "Ce qu'une pile ne comprend pas",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Une suite installée dans un flux, comme la suite Arr, n'est pas une pile dépendante : ses conteneurs n'ont pas d'ordre de départ entre eux.",
|
||||
"Le réseau privé ne remplace pas l'authentification, TLS ou la configuration de chaque application.",
|
||||
"La sauvegarde d'un LXC ne contient pas le pont, le crochet ou les contrats du reste de la pile.",
|
||||
"Prowlarr, Sonarr ou Radarr ne reçoivent aucun indexeur, profil ou fournisseur de ProxMenux."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,305 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Données, chemins et réseau | ProxMenux",
|
||||
"description": "Comment OCI manager Apps conserve les données d’un conteneur OCI : disques du conteneur, répertoires de l’hôte, montages rclone, adresses et réseaux privés."
|
||||
},
|
||||
"header": {
|
||||
"title": "Données, chemins et réseau",
|
||||
"description": "Ce qui se trouve dans le rootfs, ce qui subsiste après son remplacement, comment les données sont partagées entre conteneurs et comment chacun obtient son adresse.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "La persistance se décide avant la création du LXC",
|
||||
"body": "Les volumes déclarés par l’image et son fichier Compose sont lus avant la création du conteneur. Chaque chemin à conserver après une mise à jour devient un point de montage indépendant du rootfs. Celui-ci ne contient donc que les fichiers appartenant à l’image et peut être remplacé."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "questions",
|
||||
"title": "Ce que demande l’installateur",
|
||||
"intro": "Le modèle fournit les chemins nécessaires à l’application. Chacun est placé sur un disque du conteneur ou dans un répertoire de l’hôte. D’autres chemins peuvent être ajoutés avant le récapitulatif.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Chemins nécessaires",
|
||||
"body": "<code>/config</code>, <code>/data</code>, les bibliothèques, les téléchargements et tous les volumes déclarés par l’application sont répertoriés."
|
||||
},
|
||||
{
|
||||
"title": "Emplacement",
|
||||
"body": "Chaque chemin est placé sur un disque du conteneur ou dans un répertoire existant de l’hôte."
|
||||
},
|
||||
{
|
||||
"title": "Stockage et taille",
|
||||
"body": "Un disque du conteneur est créé sur un stockage Proxmox VE avec la taille indiquée. L’installation par défaut utilise <code>local-lvm</code>. L’installation avancée demande le stockage de chaque chemin juste avant sa taille et propose celui du rootfs. Le disque apparaît sous le nom <code>vm-VMID-disk-N</code> et est rattaché comme <code>mpN</code>."
|
||||
},
|
||||
{
|
||||
"title": "Répertoire de l’hôte",
|
||||
"body": "Le répertoire de l’hôte est indiqué par son chemin. S’il n’existe pas, il est créé avec pour propriétaire l’utilisateur de l’hôte correspondant à celui du conteneur."
|
||||
},
|
||||
{
|
||||
"title": "Chemins supplémentaires",
|
||||
"body": "Avant l’installation, d’autres associations entre un chemin ou un volume de l’hôte et un chemin du conteneur peuvent être ajoutées."
|
||||
},
|
||||
{
|
||||
"title": "Récapitulatif",
|
||||
"body": "La correspondance complète des chemins est affichée avant la création du CT et enregistrée dans le contrat de l’instance."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "options",
|
||||
"title": "Les deux emplacements persistants",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Propriété",
|
||||
"Disque du conteneur",
|
||||
"Répertoire de l’hôte"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Dans la configuration",
|
||||
"<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>",
|
||||
"<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"
|
||||
],
|
||||
[
|
||||
"Sauvegarde du conteneur (vzdump)",
|
||||
"Inclus avec <code>backup=1</code>",
|
||||
"Non inclus"
|
||||
],
|
||||
[
|
||||
"Taille",
|
||||
"Fixe ; extensible en redimensionnant le point de montage",
|
||||
"L’espace libre du système de fichiers ou du dataset de l’hôte"
|
||||
],
|
||||
[
|
||||
"Autres conteneurs",
|
||||
"Monté uniquement par son propre conteneur",
|
||||
"Le même répertoire peut être monté dans plusieurs conteneurs"
|
||||
],
|
||||
[
|
||||
"Snapshots et restauration",
|
||||
"Gérés par Proxmox VE avec le CT",
|
||||
"Gérés sur le stockage de l’hôte"
|
||||
],
|
||||
[
|
||||
"Lors de la suppression de l’application",
|
||||
"Supprimé avec le conteneur",
|
||||
"Conservé avec son contenu"
|
||||
],
|
||||
[
|
||||
"Lors du déplacement du CT vers un autre nœud",
|
||||
"Déplacé avec le CT",
|
||||
"Le même chemin doit exister sur l’autre nœud"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le rootfs est réservé aux binaires et au contenu de l’image. Une mise à jour ou une recréation le remplace sans toucher à l’un ou l’autre type de point de montage."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Exemple : un conteneur avec les deux emplacements",
|
||||
"blocks": [
|
||||
{
|
||||
"code": {
|
||||
"title": "Jellyfin installé comme CT 151 sur local-lvm (extrait)",
|
||||
"code": "rootfs: local-lvm:vm-151-disk-0,size=8G\n# Container disk, part of the CT backup\nmp0: local-lvm:vm-151-disk-1,mp=/config,backup=1,size=16G\n\n# Host directory, outside the CT backup\nmp1: /mnt/oci-shared/media,mp=/data/media"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Une mise à jour ou une recréation remplace uniquement le rootfs : <code>mp0</code> conserve les utilisateurs, les bibliothèques et les paramètres, tandis que <code>mp1</code> donne toujours accès aux mêmes médias. Restaurer la sauvegarde du CT rétablit <code>/config</code>. Le répertoire des médias est restauré, si nécessaire, depuis la sauvegarde du stockage de l’hôte."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Contrat",
|
||||
"detail": "/config"
|
||||
},
|
||||
{
|
||||
"label": "Emplacement",
|
||||
"detail": "Disque du conteneur\nou répertoire de l’hôte"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "Toujours /config\npour l’application"
|
||||
}
|
||||
],
|
||||
"caption": "L’application voit le chemin déclaré par l’image ; seul son emplacement de stockage change."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "shared",
|
||||
"title": "Un répertoire de l’hôte, plusieurs conteneurs",
|
||||
"blocks": [
|
||||
{
|
||||
"mermaid": {
|
||||
"chartCode": "flowchart TB\n H[\"{{host}}<br/>/mnt/oci-shared/media\"]\n H --> Q[\"qBittorrent<br/>/data\"]\n H --> J[\"Jellyfin<br/>/data\"]\n H --> R[\"Radarr / Sonarr<br/>/data\"]\n Q -. \"{{config}}\" .-> QV[(\"/config mpN\")]\n J -. \"{{config}}\" .-> JV[(\"/config mpN\")]\n R -. \"{{config}}\" .-> RV[(\"/config mpN\")]",
|
||||
"labels": {
|
||||
"host": "Répertoire de l’hôte",
|
||||
"config": "Configuration propre"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Chaque conteneur conserve sa configuration sur son propre disque. La bibliothèque ou les téléchargements se trouvent dans un unique répertoire de l’hôte, monté au même chemin interne dans chaque conteneur. Ainsi, le chemin dans lequel une application écrit est celui depuis lequel une autre lit."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "rclone",
|
||||
"title": "Stockage cloud avec l’application rclone",
|
||||
"intro": "Outre son installation, la fiche rclone du catalogue propose <strong>Activer un montage dans un conteneur OCI rclone existant</strong>. Un stockage distant déjà créé et autorisé dans l’interface web de rclone est monté et rendu accessible sur l’hôte. D’autres conteneurs peuvent alors l’utiliser comme un répertoire de l’hôte.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Conteneur et stockage distant",
|
||||
"body": "Le VMID du conteneur rclone, le nom exact du stockage distant et, éventuellement, un chemin à l’intérieur de celui-ci."
|
||||
},
|
||||
{
|
||||
"title": "Nom du montage et cache",
|
||||
"body": "Le nom du montage et le mode du cache VFS : <code>off</code>, <code>minimal</code>, <code>writes</code> ou <code>full</code> (par défaut)."
|
||||
},
|
||||
{
|
||||
"title": "Vues exposées",
|
||||
"body": "Une racine commune, <code>/mnt/oci-shared</code> par défaut, contient une vue en lecture-écriture dans <code>/mnt/oci-shared/remotes/NAME</code> et une vue en lecture seule dans <code>/mnt/oci-shared/remotes-ro/NAME</code>."
|
||||
},
|
||||
{
|
||||
"title": "Activation",
|
||||
"body": "Après confirmation, le CT est arrêté, sa commande de démarrage et un hookscript Proxmox VE sont configurés, puis il est redémarré. L’opération attend que les deux vues soient montées sur l’hôte."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Si le montage ne s’active pas",
|
||||
"body": "La configuration précédente du conteneur est restaurée, puis celui-ci est redémarré. Ainsi, un échec d’activation laisse rclone dans son état initial."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "network",
|
||||
"title": "Adresses et réseaux",
|
||||
"intro": "Une application à un seul conteneur a besoin d’une adresse. Une application à plusieurs conteneurs nécessite aussi un réseau stable entre ses membres.",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "network",
|
||||
"title": "Application à un seul conteneur",
|
||||
"body": "Le pont réseau est choisi, ainsi que DHCP ou une adresse fixe au format CIDR. Le LXC possède sa propre adresse et le récapitulatif affiche les URL complètes des services."
|
||||
},
|
||||
{
|
||||
"icon": "waypoints",
|
||||
"title": "Application à plusieurs conteneurs",
|
||||
"body": "Un sous-réseau libre est recherché et un pont privé persistant est créé. Chaque membre — application, base de données et cache — y reçoit une adresse fixe."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "LAN",
|
||||
"detail": "Adresse accessible\nservice principal uniquement"
|
||||
},
|
||||
{
|
||||
"label": "LXC principal",
|
||||
"detail": "Web / API\nLAN + réseau privé"
|
||||
},
|
||||
{
|
||||
"label": "Réseau privé",
|
||||
"detail": "PostgreSQL · Valkey · ML\nadresses fixes"
|
||||
}
|
||||
],
|
||||
"caption": "Les dépendances communiquent sur le réseau privé et n’ont pas d’adresse sur le LAN."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le contrat de la pile enregistre le pont, le sous-réseau, les adresses et les relations entre services. La mise à jour de l’application réutilise la même topologie pour tous les membres. ProxMenux Monitor ouvre le conteneur principal à son adresse LAN, et non à celle du réseau privé."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "ownership",
|
||||
"title": "Propriétaires des fichiers et répertoires",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Les nouveaux répertoires sont créés avec les UID et GID auxquels le LXC non privilégié est mappé.",
|
||||
"Le propriétaire des répertoires existants n’est pas modifié récursivement.",
|
||||
"Les sockets, fichiers système et chemins sensibles ne sont pas proposés comme répertoires génériques de l’hôte."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "backup",
|
||||
"title": "Ce que contient une sauvegarde du conteneur",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Élément",
|
||||
"Dans la sauvegarde vzdump du CT",
|
||||
"Lieu de conservation"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Rootfs OCI",
|
||||
"Oui",
|
||||
"Dans la sauvegarde du CT ; il peut aussi être recréé à partir de l’image et du contrat"
|
||||
],
|
||||
[
|
||||
"Disque du conteneur avec <code>backup=1</code>",
|
||||
"Oui",
|
||||
"La sauvegarde du CT"
|
||||
],
|
||||
[
|
||||
"Répertoire de l’hôte",
|
||||
"Non",
|
||||
"La sauvegarde du stockage de l’hôte"
|
||||
],
|
||||
[
|
||||
"Contrat de l’instance",
|
||||
"Oui, la copie conservée dans le CT",
|
||||
"<code>/.proxmenux/oci-record.json</code> dans le CT ; les copies supplémentaires de l’hôte et du cluster sont conservées séparément"
|
||||
],
|
||||
[
|
||||
"Application à plusieurs conteneurs",
|
||||
"Chaque membre dans sa propre sauvegarde",
|
||||
"Les sauvegardes de tous les membres, ainsi que le contrat de la pile et son pont réseau sur l’hôte"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,172 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Script de post-installation automatisé | Documentation ProxMenux",
|
||||
"description": "Le script de post-installation automatisé ProxMenux exécute 14 optimisations prédéfinies adaptées au matériel sur un nouvel hôte Proxmox VE. Il n’a pas de liste de fonctions à sélectionner, mais peut demander confirmation pour la mise à jour du système, pour masquer l’avertissement d’abonnement, installer Log2RAM dans certains cas et redémarrer. Les changements réversibles sont enregistrés.",
|
||||
"ogTitle": "Script de post-installation automatisé | Documentation ProxMenux",
|
||||
"ogDescription": "14 optimisations prédéfinies adaptées au matériel pour un nouvel hôte Proxmox VE, avec confirmation de certaines actions et suivi des changements réversibles."
|
||||
},
|
||||
"header": {
|
||||
"title": "Script de post-installation automatisé",
|
||||
"description": "ProxMenux exécute 14 optimisations de base prédéfinies sans liste de fonctions à sélectionner. Certaines actions demandent confirmation. Les changements réversibles sont enregistrés pour Désinstaller les optimisations ; les mises à niveau de paquets ne sont pas présentées comme réversibles.",
|
||||
"section": "Post-installation · Automatisée"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Quand choisir Automatisé",
|
||||
"body": "Exécutez-le sur un hôte Proxmox fraîchement installé pour obtenir une configuration de base raisonnable sans choisir chaque fonction. Le script est idempotent : une deuxième exécution réapplique les mêmes paramètres. Les fonctions optionnelles (Fastfetch, IOMMU, dépôt Ceph, HA, correctifs AMD…) ne font volontairement <strong>pas</strong> partie de ce parcours ; choisissez-les dans <link>Personnalisable</link> au besoin."
|
||||
},
|
||||
"applies": {
|
||||
"heading": "Ce que le script applique",
|
||||
"intro": "Les optimisations sont appliquées dans cet ordre exact. La colonne <em>Catégorie</em> permet de consulter la documentation détaillée de chaque changement dans la référence personnalisable.",
|
||||
"headerNum": "#",
|
||||
"headerTool": "Outil",
|
||||
"headerWhat": "Ce qu'il fait",
|
||||
"headerCategory": "Catégorie"
|
||||
},
|
||||
"optimizations": [
|
||||
{
|
||||
"tool": "Dépôts APT + mise à jour complète",
|
||||
"what": "Désactive les dépôts Enterprise pve-enterprise.sources et ceph.sources, crée une source sans abonnement pour le nom de code Debian de l’hôte, puis lance apt update && apt full-upgrade -y (commande officielle de mise à niveau Proxmox).",
|
||||
"category": "Paramètres de base",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
{
|
||||
"tool": "Suppression de la bannière d'abonnement",
|
||||
"what": "Modifie l’interface web pour masquer l’avertissement « Aucun abonnement valide ». Demande confirmation avant application ; réversible via Désinstaller les optimisations.",
|
||||
"category": "Personnalisation",
|
||||
"categorySlug": "customization"
|
||||
},
|
||||
{
|
||||
"tool": "Forcer IPv4",
|
||||
"what": "Écrit /etc/apt/apt.conf.d/99-force-ipv4 pour que apt utilise uniquement IPv4 et contourne les liaisons IPv6 instables vers les miroirs.",
|
||||
"category": "Réseau",
|
||||
"categorySlug": "network"
|
||||
},
|
||||
{
|
||||
"tool": "Sauter les paquets de langue",
|
||||
"what": "Écrit /etc/apt/apt.conf.d/99-disable-translations pour ne plus télécharger les index de descriptions de paquets traduites et réduire les données des mises à jour apt.",
|
||||
"category": "Paramètres de base",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
{
|
||||
"tool": "Augmentation des limites du système",
|
||||
"what": "Augmente le nombre de surveillances inotify, les limites nofile/nproc, celles du trousseau du noyau et fs.file-max via sysctl.d, limits.d, pam et systemd, pour les hôtes avec de nombreux conteneurs.",
|
||||
"category": "Système",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Réglage de la mémoire",
|
||||
"what": "Définit vm.swappiness=10, des ratios équilibrés de pages modifiées non écrites, vm.max_map_count=262144 et la proactivité du compactage si disponible. La politique de surallocation mémoire du noyau reste celle de Proxmox par défaut.",
|
||||
"category": "Système",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Comportement en cas de panique du noyau",
|
||||
"what": "Configure l’hôte pour redémarrer 10 secondes après un panic / oops / hardlockup au lieu de rester bloqué indéfiniment.",
|
||||
"category": "Système",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Réglage de la pile réseau",
|
||||
"what": "Taille des tampons TCP, durcissement IPv4 (redirections désactivées, rp_filter=2, journalisation martian désactivée), ports locaux 1024-65535, détection MTU TCP, RFC 1337 et script /usr/local/sbin/proxmenux-fwbr-tune lié à une unité systemd à exécution unique et une règle udev. Ainsi, rp_filter=0 / log_martians=0 sont réappliqués aux interfaces fwbr*/fwln*/fwpr*/tap* à chaque recréation par Proxmox au démarrage/arrêt des VM, au redémarrage ou à la migration à chaud.",
|
||||
"category": "Réseau",
|
||||
"categorySlug": "network"
|
||||
},
|
||||
{
|
||||
"tool": "Personnalisation du bashrc (root)",
|
||||
"what": "PS1 coloré, alias courants (l/la/ll/ls/grep), historique horodaté et chargement de bash-completion, dans un bloc délimité PMX_CORE_BASHRC facile à retirer.",
|
||||
"category": "Personnalisation",
|
||||
"categorySlug": "customization"
|
||||
},
|
||||
{
|
||||
"tool": "Log2RAM (adapté aux SSD, automatique)",
|
||||
"what": "Réduit l’usure SSD/NVMe en déplaçant /var/log dans un disque RAM tmpfs synchronisé régulièrement vers le disque. Installation depuis le projet amont si le disque racine est SSD ou NVMe. Taille selon la RAM de l’hôte (128M / 256M / 512M), synchronisation périodique et protection automatique qui purge les anciens journaux à 80% et tronque les journaux très actifs à 92% avant écriture. Adapte les limites journald au disque RAM. Détails dans <link>Log2RAM</link>.",
|
||||
"category": "Stockage",
|
||||
"categorySlug": "storage"
|
||||
},
|
||||
{
|
||||
"tool": "ZFS autotrim (SSD seulement)",
|
||||
"what": "Active zpool autotrim=on sur chaque pool ZFS dont tous les vdevs sont des SSD ou NVMe compatibles TRIM, après vérification de /sys/block/[dev]/queue/rotational et discard_granularity. Les pools sur HDD sont ignorés. Seuls les pools effectivement modifiés par ProxMenux sont mémorisés pour la désinstallation ; ceux sur lesquels vous avez activé autotrim manuellement restent inchangés.",
|
||||
"category": "Stockage",
|
||||
"categorySlug": "storage"
|
||||
},
|
||||
{
|
||||
"tool": "Limites de taille de journald",
|
||||
"what": "Force le stockage persistant, limite SystemMaxUse=64M / RuntimeMaxUse=60M, active la compression et les journaux de niveau info requis par Monitor. Ignoré si Log2RAM est actif, car il effectue son propre réglage.",
|
||||
"category": "Système",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Réglage du logrotate",
|
||||
"what": "Définit globalement daily puis size 10M, conserve 7 rotations et active compression et copytruncate. Le critère de taille placé après prévaut ; les règles propres aux journaux peuvent le remplacer. Adapté à Log2RAM, mais la fréquence dépend des règles et du minuteur.",
|
||||
"category": "Système",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Noms d'interface persistants",
|
||||
"what": "Écrit un <code>/etc/systemd/network/10-proxmenux-<iface>.link</code> par NIC physique (chacun commençant par un en-tête 'Managed by ProxMenux') qui épingle le MAC au nom courant, de sorte que les noms <code>eth0</code> / <code>enp…</code> restent stables à travers les reboots et les nouveaux ajouts NIC.",
|
||||
"category": "Réseau",
|
||||
"categorySlug": "network"
|
||||
}
|
||||
],
|
||||
"hardwareTitle": "Valeurs par défaut adaptées au matériel",
|
||||
"hardwareBody": "Le script examine le matériel avant de configurer l’hôte. Par défaut, Log2RAM s’installe uniquement si le disque racine est SSD ou NVMe ; il demande confirmation sinon. La taille du disque RAM dépend de la RAM totale (<code>≤ 8 GB → 128M</code>, <code>≤ 16 GB → 256M</code>, <code>'>' 16 GB → 512M</code>). Quand Log2RAM est actif, les limites journald sont adaptées au disque RAM pour éviter de le remplir.",
|
||||
"upgrade": {
|
||||
"heading": "Mettre à jour les listes de paquets et le système",
|
||||
"intro": "La première étape du parcours automatisé est la mise à niveau Proxmox. Pour un hôte en fonctionnement au sein de la même version majeure, Proxmox recommande :",
|
||||
"after": "Cette ligne est la commande officielle des versions actuelles de Proxmox. Le script automatisé l’exécute <strong>exactement</strong> et ajoute le nettoyage des dépôts et les tâches après mise à niveau recommandés par le guide — comme l’utilitaire autonome <link>Mise à jour du système Proxmox</link> :",
|
||||
"items": [
|
||||
"Désactive les sources Enterprise <code>pve-enterprise.sources</code> / <code>ceph.sources</code>, supprime les anciens fichiers de dépôts et crée une source sans abonnement pour le nom de code de l’hôte.",
|
||||
"Exécute la mise à jour non interactive avec <code>DEBIAN_FRONTEND=noninteractive</code> et <code>--force-confdef --force-confold</code> — les fichiers de configuration que vous avez personnalisés restent les vôtres lorsque l'amont les a également modifiés.",
|
||||
"Installe les paquets Proxmox essentiels s’ils manquent (<code>zfsutils-linux</code>, <code>proxmox-backup-restore-image</code>, <code>chrony</code>).",
|
||||
"Vérification de cohérence des métadonnées LVM, <code>apt-get autoremove -y</code> + <code>apt-get autoclean -y</code> et demande de redémarrage seulement si le noyau a changé."
|
||||
],
|
||||
"sameTitle": "Même mise à jour, deux points d'entrée",
|
||||
"sameBody": "Le paquet automatisé et l'utilitaire autonome <link>Proxmox System Update</link> partagent les mêmes scripts sous-jacents (<code>update-pve8.sh</code> / <code>update-pve9_2.sh</code>). Utilisez l'utilitaire seul quand vous voulez seulement mettre à niveau l'hôte sans appliquer le reste des optimisations."
|
||||
},
|
||||
"endResult": {
|
||||
"heading": "Résultat final escompté",
|
||||
"body": "À la fin, un message de réussite et les sorties de chaque étape s’affichent, avec une demande de redémarrage pour les paramètres du noyau qui en ont besoin. Vous pouvez le reporter ; ces paramètres s’appliqueront au prochain démarrage.",
|
||||
"imageAlt": "script automatisé post-installation — sortie finale du terminal montrant chaque optimisation appliquée avec succès"
|
||||
},
|
||||
"notDoes": {
|
||||
"heading": "Ce que ce script ne fait PAS",
|
||||
"items": [
|
||||
"Détection automatique par fuseau horaire (commenté en amont; utiliser Personnalisable si vous le souhaitez).",
|
||||
"Désactiver portmapper / rpcbind (voir <secLink>Sécurité</secLink>).",
|
||||
"Activer IOMMU / VFIO (voir <virtLink>Virtualisation</virtLink>).",
|
||||
"Installer Fastfetch / Figurine / le dépôt Ceph / HA / les correctifs CPU AMD (voir <optLink>Options</optLink>).",
|
||||
"Installer pigz ou ajuster ZFS ARC (voir <perfLink>Performances</perfLink> / <storLink>Stockage</storLink>)."
|
||||
]
|
||||
},
|
||||
"xshokTitle": "détection xshok-proxmox",
|
||||
"xshokBody": "Si l'hôte a déjà lancé le script <code>xshok-proxmox</code>, ProxMenux détecte le fichier marqueur et vous avertit avant de continuer. Certains changements peuvent se chevaucher. Le script compagnon est déprécié — si vous décidez de continuer de toute façon, consultez <link>la vue d'ensemble</link> pour le contexte.",
|
||||
"revert": {
|
||||
"heading": "Annuler les changements",
|
||||
"body": "Chaque outil du tableau est enregistré dans <code>/usr/local/share/proxmenux/installed_tools.json</code>. Ouvrez <link>Désinstaller les optimisations</link> pour choisir les éléments à rétablir. Les sauvegardes des fichiers modifiés se trouvent à côté des originaux avec le suffixe <code>.bak</code>."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— choisissez exactement ce que vous voulez dans le même catalogue."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": "— de revenir sur tout sous-ensemble de ce qui a été appliqué ici."
|
||||
},
|
||||
{
|
||||
"label": "Commandes système utiles",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": "— vérifier les changements (uptime, free, journalctl, etc.)."
|
||||
},
|
||||
{
|
||||
"label": "Aperçu après l'installation",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,240 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Paramètres de base | Documentation ProxMenux",
|
||||
"description": "Options de base après installation : passer aux dépôts Proxmox sans abonnement et mettre à niveau le système, détecter le fuseau horaire et activer NTP, ignorer les traductions APT et choisir parmi 25 utilitaires courants à installer."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install: Paramètres de base",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Cinq options de base pour un hôte Proxmox neuf : passer aux dépôts communautaires sans abonnement, mettre à niveau tout le système, configurer automatiquement le fuseau horaire et NTP, supprimer les traductions APT pour économiser bande passante et espace disque et choisir parmi 25 utilitaires courants."
|
||||
},
|
||||
"upgrade": {
|
||||
"heading": "Mettre à jour les listes de paquets et le système",
|
||||
"intro": "Reconfigure APT pour utiliser le dépôt gratuit <em>pve-no-subscription</em> (au lieu de la repo d'entreprise qui nécessite un abonnement) et exécute une mise à niveau complète du système. Les étapes exactes dépendent de la version majeure de Proxmox VE : ProxMenux la détecte et envoie vers le bon script.",
|
||||
"headerVersion": "Version PVE",
|
||||
"headerScript": "Script de sélection par version",
|
||||
"headerCodename": "Nom de code Debian",
|
||||
"rows": [
|
||||
{
|
||||
"version": "9.x",
|
||||
"script": "update-pve9_2.sh",
|
||||
"codename": "trixie"
|
||||
},
|
||||
{
|
||||
"version": "8.x",
|
||||
"script": "update-pve8.sh",
|
||||
"codename": "bookworm"
|
||||
}
|
||||
],
|
||||
"officialTitle": "La recommandation officielle de Proxmox",
|
||||
"officialBody": "Le guide de mise à niveau de Proxmox est à exécuter, dans cet ordre exact:",
|
||||
"officialOutro": "C’est la commande habituelle pour les mises à jour au sein de la version majeure installée de Proxmox VE. Vérifiez les dépôts et les changements de paquets proposés <em>avant</em> de continuer. Un changement de version majeure exige la procédure officielle de migration.",
|
||||
"doesTitle": "Ce que fait l'option ProxMenux — vérifié par rapport au script",
|
||||
"doesIntro": "La mise à jour ProxMenux exécute les commandes apt ci-dessus et ajoute des étapes avant et après que vous devriez autrement gérer manuellement. Les éléments suivants correspondent au script de sélection ; voir <link>Mise à jour du système Proxmox</link> pour le détail complet.",
|
||||
"doesItems": [
|
||||
"<strong>D’abord, nettoyer les dépôts.</strong> Désactive les dépôts Enterprise <code>pve-enterprise.sources</code> / <code>ceph.sources</code>, supprime les anciens fichiers de dépôt laissés par les versions précédentes de PVE et écrit un fichier <code>proxmox.sources</code> propre pointant vers le canal gratuit <em>pve-no-subscription</em>, adapté au nom de code Debian de l’hôte : trixie pour PVE 9, bookworm pour PVE 8.",
|
||||
"<strong>Réécrit les dépôts Debian</strong> avec main / updates / security et <code>non-free-firmware</code>, pour éliminer l’avertissement du firmware pendant la mise à niveau.",
|
||||
"<strong>Exécute la mise à niveau officielle.</strong> <code>apt-get update</code> suivi de <code>apt full-upgrade -y</code> (PVE 9) ou <code>apt dist-upgrade -y</code> (PVE 8), sans interaction avec <code>--force-confdef --force-confold</code> pour conserver vos fichiers de configuration personnalisés.",
|
||||
"<strong>Installe les paquets essentiels</strong> s'ils manquent: <code>zfsutils-linux</code>, <code>proxmox-backup-restore-image</code>, <code>chrony</code>.",
|
||||
"<strong>Vérifie les métadonnées LVM.</strong> Recherche les VM avec accès direct aux disques qui ont pu laisser d’anciens en-têtes de volumes physiques sur les disques bruts. Signale les anomalies sans correction automatique.",
|
||||
"<strong>Nettoye ensuite :</strong> <code>apt-get autoremove -y</code> + <code>apt-get autoclean -y</code>, puis demande un redémarrage si le noyau a été mis à jour ou si <code>/var/run/reboot-required</code> est présent."
|
||||
],
|
||||
"shortTitle": "Bref",
|
||||
"shortBody": "L’option exécute <code>apt update && apt full-upgrade -y</code> comme recommandé par Proxmox, avec le nettoyage des dépôts et les étapes finales mentionnés dans le guide officiel, puis propose un redémarrage. Voir <link>Mise à jour du système Proxmox</link> pour le diagramme complet ; le même outil est disponible seul dans le menu principal.",
|
||||
"subTitle": "Ne pas appliquer à un hôte avec abonnement",
|
||||
"subBody": "Si vous avez un abonnement Proxmox et souhaitez garder les dépôts Enterprise, ignorez cette option. Elle désactive Enterprise et passe au canal communautaire. La mise à niveau des paquets et la réécriture des dépôts ne sont pas réversibles dans Désinstaller les optimisations ; reconfigurez explicitement les dépôts pour changer de canal plus tard.",
|
||||
"safetyTitle": "Contrôle de sécurité après mise à jour",
|
||||
"safetyBody": "Après la mise à niveau, le script cherche d’anciennes métadonnées de volume physique (PV) sur les disques. Cela peut arriver lorsqu’une VM avec accès direct écrit des en-têtes LVM sur un disque brut. Toute anomalie produit un avertissement suggérant <code>pvs</code> pour l’inspection. Aucune action automatique."
|
||||
},
|
||||
"time": {
|
||||
"heading": "Synchroniser l'heure automatiquement",
|
||||
"intro": "Détecte l'IP public du serveur via <code>dig myip.opendns.com @resolver1.opendns.com</code>, puis interroge <code>ipapi.co/'{'ip'}'/timezone</code> pour rechercher le fuseau horaire IANA correspondant, et l'applique avec <code>timedatectl set-timezone</code>. Enfin permet NTP avec <code>timedatectl set-ntp true</code>.",
|
||||
"depTitle": "Dépend de deux services externes",
|
||||
"depBody": "La recherche repose sur OpenDNS et <code>ipapi.co</code> étant accessibles, et leurs réponses étant correctes. Si vous exécutez Proxmox derrière un VPN ou sur un VLAN qui s'échappe d'une autre région, le fuseau horaire détecté automatiquement peut être erroné. Dans ce cas, sautez cette option et définissez le fuseau horaire à la main:",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "<link>Désinstaller les optimisations</link> remet le fuseau horaire à UTC, une valeur par défaut sûre. NTP reste actif : l’horloge continue de se synchroniser et affiche UTC jusqu’au réglage manuel d’un autre fuseau."
|
||||
},
|
||||
"languages": {
|
||||
"heading": "ignorer le téléchargement de langues supplémentaires",
|
||||
"intro": "Pendant <code>apt update</code>, APT peut télécharger des descriptions de paquets traduites en plus des métadonnées principales. Cette option les désactive pour économiser bande passante et espace. Avant cela, ProxMenux <strong>vérifie que les paramètres régionaux de l’hôte sont générés</strong> : lit <code>/etc/default/locale</code> ou <code>/etc/environment</code>, ajoute à <code>/etc/locale.gen</code> si nécessaire et lance <code>locale-gen</code>. Les paramètres régionaux du shell sont ainsi conservés.",
|
||||
"writtenTitle": "Ce qui est écrit",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "Suppression de <code>/etc/apt/apt.conf.d/99-disable-translations</code> (soit manuellement soit à partir du menu Désinstaller) restaure le comportement par défaut et APT télécharge à nouveau les fichiers linguistiques."
|
||||
},
|
||||
"utilities": {
|
||||
"heading": "Installer les utilitaires système courants",
|
||||
"intro": "Ouvre une liste groupée de <strong>25 utilitaires sélectionnés</strong>. Choisissez et confirmez ; ProxMenux les installe via <code>apt</code>, vérifie le résultat et affiche un résumé final.",
|
||||
"imageAlt": "Sélecteur des utilitaires ProxMenux : Espace pour sélectionner, Entrée pour confirmer",
|
||||
"reuseTitle": "La même liste est réutilisée ailleurs",
|
||||
"reuseBody": "Le catalogue des 25 utilitaires est défini à un seul endroit : <code>PROXMENUX_UTILS</code> dans <code>scripts/global/utils-install-functions.sh</code>. Le menu <em>Utilitaires et outils → Utilitaires système</em> présente la même liste pour en ajouter plus tard sans refaire la post-installation.",
|
||||
"listTitle": "Ce qui est dans la liste",
|
||||
"groups": [
|
||||
{
|
||||
"group": "Moniteurs système",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "htop",
|
||||
"desc": "Affichage interactif des processus"
|
||||
},
|
||||
{
|
||||
"pkg": "btop",
|
||||
"desc": "Moniteur de ressources modernes (CPU, RAM, disques, net, processus)"
|
||||
},
|
||||
{
|
||||
"pkg": "s-tui",
|
||||
"desc": "Interface terminal pour les tests de charge CPU et la surveillance"
|
||||
},
|
||||
{
|
||||
"pkg": "iftop",
|
||||
"desc": "Utilisation de bande passante par connexion en direct"
|
||||
},
|
||||
{
|
||||
"pkg": "iotop",
|
||||
"desc": "E/S disque par processus"
|
||||
},
|
||||
{
|
||||
"pkg": "iptraf-ng",
|
||||
"desc": "Moniteur IP LAN interactif"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Réseau",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "iperf3",
|
||||
"desc": "Mesurer la bande passante maximale réalisable entre les hôtes"
|
||||
},
|
||||
{
|
||||
"pkg": "net-tools",
|
||||
"desc": "Anciens outils (ifconfig, netstat, route). Toujours utiles pour les vérifications rapides"
|
||||
},
|
||||
{
|
||||
"pkg": "ipset",
|
||||
"desc": "Gérer les grands ensembles IP dans le noyau — utile avec les règles iptables/nftables."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Téléchargement et archive",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "axel",
|
||||
"desc": "accélérateur de téléchargement parallèle léger"
|
||||
},
|
||||
{
|
||||
"pkg": "aria2",
|
||||
"desc": "Téléchargeur multisource / multiprotocole (HTTP, FTP, BitTorrent, Metalink)"
|
||||
},
|
||||
{
|
||||
"pkg": "unzip",
|
||||
"desc": "Extraire les archives ZIP"
|
||||
},
|
||||
{
|
||||
"pkg": "zip",
|
||||
"desc": "Créer des archives ZIP"
|
||||
},
|
||||
{
|
||||
"pkg": "cabextract",
|
||||
"desc": "Extraire les archives Microsoft CAB (utile avec les ISO Windows)"
|
||||
},
|
||||
{
|
||||
"pkg": "wimtools",
|
||||
"desc": "Manipuler les images WIM Windows (extraire, fractionner, monter, appliquer)"
|
||||
},
|
||||
{
|
||||
"pkg": "genisoimage",
|
||||
"desc": "Construire des images ISO 9660 à partir d'un arbre de répertoires"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Texte et fichiers",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "dos2unix",
|
||||
"desc": "Convertir les fins de ligne CRLF (Windows) en LF (Unix)"
|
||||
},
|
||||
{
|
||||
"pkg": "grc",
|
||||
"desc": "Coloration générique : applique une coloration syntaxique aux sorties de ping, traceroute, dig, tail, etc."
|
||||
},
|
||||
{
|
||||
"pkg": "plocate",
|
||||
"desc": "Recherche rapide de fichiers (indexée). Exécutez `updatedb` après l'installation pour construire l'index."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Accès distant et sessions",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "sshpass",
|
||||
"desc": "Authentification SSH par mot de passe sans interaction (pour les scripts, pas pour l’usage quotidien)"
|
||||
},
|
||||
{
|
||||
"pkg": "tmux",
|
||||
"desc": "Multiplexeur de terminal : détacher les sessions, diviser les panneaux et conserver les sessions après une déconnexion"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Matériel et bas niveau",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "msr-tools",
|
||||
"desc": "Registres spécifiques au modèle CPU de lecture/écriture (rdmsr, wrmsr)"
|
||||
},
|
||||
{
|
||||
"pkg": "intel-gpu-tools",
|
||||
"desc": "utilitaires de diagnostic Intel GPU y compris `intel_gpu_top`"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Virtualisation",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "libguestfs-tools",
|
||||
"desc": "Inspecter et modifier les images de disque VM (virt-ls, virt-cat, guestmount...)"
|
||||
},
|
||||
{
|
||||
"pkg": "chntpw",
|
||||
"desc": "Modifier Windows SAM — utile pour la récupération de mot de passe sur Windows VMs que vous héritez"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"actionTitle": "Quelques-uns en action",
|
||||
"noBulkTitle": "Seuls les utilitaires installés par ProxMenux sont supprimés",
|
||||
"noBulkBody": "ProxMenux enregistre uniquement les paquets sélectionnés qui n’étaient pas déjà installés. Désinstaller les optimisations les supprime complètement et conserve les paquets présents auparavant. Une mise à niveau APT n’a pas de retour arrière atomique sûr : désinstaller les utilitaires n’annule pas la mise à niveau du système."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Mise à jour du système Proxmox",
|
||||
"href": "/docs/utils/system-update",
|
||||
"tail": "— relance le cycle apt update + dist-upgrade sur demande."
|
||||
},
|
||||
{
|
||||
"label": "Installateur des utilitaires système",
|
||||
"href": "/docs/utils/system-utils",
|
||||
"tail": "— installer (ou réinstaller) les utilitaires individuellement après l'installation."
|
||||
},
|
||||
{
|
||||
"label": "Commandes de mises à jour et de paquets",
|
||||
"href": "/docs/help-info/update-commands",
|
||||
"tail": " — Référence apt pour le shell."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Script post-installation personnalisable | Documentation ProxMenux",
|
||||
"description": "Choisissez précisément les optimisations à appliquer à un hôte Proxmox VE avec ProxMenux. 10 catégories, environ 35 outils et une interface à cases à cocher. Inclut tout le script Automatisé, plus des options à activer explicitement (IOMMU, Fastfetch, Figurine, Ceph, HA, correctifs AMD…).",
|
||||
"ogTitle": "Script post-installation personnalisable | Documentation ProxMenux",
|
||||
"ogDescription": "10 catégories, environ 35 optimisations individuelles. Choisissez précisément ce que vous voulez sur un hôte Proxmox VE. Les modifications réversibles sont suivies."
|
||||
},
|
||||
"header": {
|
||||
"title": "Script post-installation personnalisable",
|
||||
"description": "Choisissez précisément les optimisations à appliquer à un hôte Proxmox VE. ProxMenux regroupe environ 35 outils dans 10 catégories au sein d’une seule boîte de dialogue à cases à cocher. Même moteur qu’Automatisé, avec un contrôle complet.",
|
||||
"section": "Post-Installation · Personnalisable"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Quand choisir Personnalisable",
|
||||
"body": "Choisissez cette voie si vous connaissez déjà les réglages souhaités ou à éviter. Une liste à cases à cocher, groupée par catégorie, permet de sélectionner, désélectionner et combiner les optimisations. Vous pouvez les réappliquer plus tard ; les modifications réversibles sont suivies pour <link>Désinstaller les optimisations</link>. Les mises à niveau de paquets ne sont pas présentées comme réversibles."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "Comment il se compare à Automatisé",
|
||||
"body": "Personnalisable inclut tout le <link>script Automatisé</link> : les mêmes 14 optimisations de base et de nombreuses options volontairement omises par Automatisé, utiles à certains matériels (correctifs AMD), hébergeurs (OVH RTM) ou usages (IOMMU/VFIO, dépôt Ceph, haute disponibilité, Fastfetch, Figurine, réglage de l’ARC ZFS, pigz, instantanés ZFS automatiques, limites de vitesse vzdump, Open vSwitch, TCP BBR…)."
|
||||
},
|
||||
"categoriesSection": {
|
||||
"heading": "Les 10 catégories",
|
||||
"body": "Le script Personnalisable regroupe les optimisations en 10 catégories dans une seule boîte de dialogue à cases à cocher. Chaque catégorie a sa propre page de documentation : ouvrez une carte pour consulter la justification, les valeurs par défaut et les vérifications de chaque option."
|
||||
},
|
||||
"categories": [
|
||||
{
|
||||
"name": "Paramètres de base",
|
||||
"description": "Nettoyer les sources APT, lancer la mise à niveau officielle Proxmox et définir le fuseau horaire, les paramètres régionaux et les utilitaires courants. La base de toutes les autres catégories."
|
||||
},
|
||||
{
|
||||
"name": "Système",
|
||||
"description": "Règle la journalisation et les limites du noyau pour un hôte hébergeant de nombreuses VM et conteneurs. Couvre journald, logrotate, sysctl (mémoire, limites de fichiers), le comportement en cas de kernel panic et les redémarrages rapides."
|
||||
},
|
||||
{
|
||||
"name": "Virtualisation",
|
||||
"description": "Prépare l’hôte à la virtualisation avancée. Installe l’agent invité adapté lorsque Proxmox lui-même fonctionne dans une VM prise en charge et active IOMMU/VFIO pour l’accès direct PCI des GPU, contrôleurs et TPU."
|
||||
},
|
||||
{
|
||||
"name": "Réseau",
|
||||
"description": "Renforce et règle la pile réseau de l’hôte. Force APT sur IPv4, applique des réglages de sécurité sysctl et des tampons TCP, propose Open vSwitch, TCP BBR et TCP Fast Open et associe les noms d’interface persistants aux adresses MAC."
|
||||
},
|
||||
{
|
||||
"name": "Stockage",
|
||||
"description": "Configure les sous-systèmes de stockage courants de Proxmox : taille de l’ARC ZFS, instantanés ZFS automatiques, autotrim ZFS pour les pools SSD/NVMe et limites de vitesse vzdump pour éviter de saturer les disques pendant les sauvegardes."
|
||||
},
|
||||
{
|
||||
"name": "Sécurité",
|
||||
"description": "Réduit la surface d’attaque exposée par défaut. Désactive les services RPC portmapper/rpcbind dont Proxmox n’a pas besoin mais qu’il laisse en écoute."
|
||||
},
|
||||
{
|
||||
"name": "Personnalisation",
|
||||
"description": "Changer l'expérience visuelle et shell de l'hôte: couleurs et alias dans bashrc, bannière MOTD et suppression de l'avis d'abonnement dans l'interface utilisateur web."
|
||||
},
|
||||
{
|
||||
"name": "Surveillance",
|
||||
"description": "Intègre l’hôte à OVH Real-Time Monitoring. Installe RTM uniquement si ProxMenux détecte un serveur OVH ; l’option ne modifie rien sur les autres hôtes."
|
||||
},
|
||||
{
|
||||
"name": "Performances",
|
||||
"description": "Accélère la compression (sauvegardes, transferts) en remplaçant gzip par son équivalent parallèle pigz."
|
||||
},
|
||||
{
|
||||
"name": "Facultatif",
|
||||
"description": "Options spécialisées dont tous les hôtes n’ont pas besoin : correctifs CPU AMD, bannière Fastfetch, nom d’hôte 3D Figurine, actualisation de l’index PVE Appliance Manager, dépôt Ceph, services haute disponibilité, Log2RAM pour limiter l’usure des SSD et profil de swap ZRAM."
|
||||
}
|
||||
],
|
||||
"mixTip": {
|
||||
"title": "Combiner Automatisé et Personnalisable",
|
||||
"body": "Un usage courant : commencez par <strong>Automatisé</strong> pour établir une base raisonnable, puis ouvrez <strong>Personnalisable</strong> et choisissez seulement les options utiles, comme IOMMU pour l’accès direct à un GPU. Les modifications sont suivies séparément ; Désinstaller affiche tout ce qui a été appliqué, quelle que soit la voie utilisée."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Post-installation automatisée",
|
||||
"href": "/docs/post-install/automated",
|
||||
"tail": " — valeurs par défaut raisonnables appliquées sans question."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — annuler proprement les éléments sélectionnés."
|
||||
},
|
||||
{
|
||||
"label": "Paramètres de base",
|
||||
"href": "/docs/post-install/basic-settings",
|
||||
"tail": "— repos, temps, langue, utilitaires."
|
||||
},
|
||||
{
|
||||
"label": "Virtualisation",
|
||||
"href": "/docs/post-install/virtualization",
|
||||
"tail": "— IOMMU + VFIO pour transmission."
|
||||
},
|
||||
{
|
||||
"label": "Sécurité",
|
||||
"href": "/docs/post-install/security",
|
||||
"tailRich": " · <storageLink>Stockage</storageLink> · <networkLink>Réseau</networkLink> · <customLink>Personnalisation</customLink> — autres catégories."
|
||||
},
|
||||
{
|
||||
"label": "Aperçu après l'installation",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,74 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Personnalisation | Documentation ProxMenux",
|
||||
"description": "Options de personnalisation du script post-installation personnalisable de ProxMenux : invite bash colorée avec des alias utiles, bannière ProxMenux dans le MOTD et suppression du rappel d’abonnement de l’interface web Proxmox."
|
||||
},
|
||||
"header": {
|
||||
"title": "Après installation : personnalisation",
|
||||
"description": "Réglages visuels et pratiques de l’hôte Proxmox. Ils rendent le shell plus agréable et masquent le rappel d’abonnement de l’interface web. Bashrc, MOTD et la bannière sont suivis et réversibles depuis Désinstaller.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Trois petites options indépendantes : une <strong>invite bash colorée avec alias</strong> pour le shell root, une <strong>bannière MOTD</strong> d’une ligne à la connexion SSH et la suppression de la <strong>fenêtre « Aucun abonnement valide »</strong> affichée à chaque connexion web Proxmox."
|
||||
},
|
||||
"bashrc": {
|
||||
"heading": "Personnaliser bashrc",
|
||||
"intro": "Insère dans <code>/root/.bashrc</code> un bloc préparé avec une invite colorée, un historique horodaté, les alias habituels de <code>ls</code> / <code>grep</code> et un <code>source</code> pour l’autocomplétion bash. Rend le travail via SSH plus agréable et permet d’identifier facilement l’hôte lorsque plusieurs onglets sont ouverts.",
|
||||
"writesTitle": "Ce que ProxMenux ajoute à .bashrc",
|
||||
"writesOutro": "Le bloc est délimité par les marqueurs <code>PMX_CORE_BASHRC</code>. Exécuter le script remplace à nouveau le bloc précédent au lieu de le dupliquer. Le <code>.bashrc</code> original est sauvegardé une fois sur <code>/root/.bashrc.bak</code>, et une ligne <code>source /root/.bashrc</code> est annexée au <code>/root/.bash_profile</code> de sorte que l'invite s'applique également sur les shells de connexion (par exemple après <code>su -</code>).",
|
||||
"rootTitle": "S’applique uniquement à root",
|
||||
"rootBody": "La personnalisation concerne le shell du compte root. Les autres utilisateurs gardent leurs propres réglages par défaut. Si vous administrez Proxmox uniquement par l’interface web sans utiliser le shell, vous pouvez ignorer cette option purement esthétique."
|
||||
},
|
||||
"motd": {
|
||||
"heading": "Configurer une bannière MOTD personnalisée",
|
||||
"intro": "Ajoute <em>\"This system is optimised by: ProxMenux\"</em> au début de <code>/etc/motd</code>, le message après une connexion SSH réussie, au-dessus de l’invite et avant les scripts <code>update-motd</code>. Sans danger et purement informatif : confirme visuellement que ProxMenux a été appliqué sur l’hôte.",
|
||||
"writesTitle": "Ce que ProxMenux écrit",
|
||||
"writesOutro": "À la première application, ProxMenux enregistre si <code>/etc/motd</code> existait et conserve son contenu original sous <code>/usr/local/share/proxmenux</code>. L’opération est idempotente : si la ligne de repère existe déjà, rien n’est ajouté. Les anciennes installations avec <code>/etc/motd.bak</code> sont migrées vers le même état réversible."
|
||||
},
|
||||
"banner": {
|
||||
"heading": "Supprimer la bannière d'abonnement",
|
||||
"intro": "Supprime la fenêtre <em>« Vous n’avez pas d’abonnement valide pour ce serveur »</em> affichée à chaque connexion web Proxmox sans abonnement Enterprise. ProxMenux tient compte de la version et lance le script adapté aux différents fichiers d’interface des versions majeures.",
|
||||
"versionTitle": "Choix du script selon la version",
|
||||
"versionItems": [
|
||||
"<strong>PVE 9.x</strong> → exécute <code>remove-banner-pve-v3.sh</code>, qui modifie <code>proxmoxlib.js</code> pour le bureau et la nouvelle interface mobile basée sur Yew.",
|
||||
"<strong>PVE 8.x</strong> → exécute <code>remove-banner-pve8.sh</code>, uniquement pour l’interface de bureau."
|
||||
],
|
||||
"versionOutro": "Avant le patching, ProxMenux sauvegarde les fichiers JS/template originaux vers <code>/usr/local/share/proxmenux/backups/</code> avec un horodatage. Le flux Désinstaller utilise ces sauvegardes pour restaurer les fichiers originaux, et revient à réinstaller les paquets de l'interface utilisateur Proxmox si la sauvegarde est manquante ou corrompue.",
|
||||
"breakTitle": "Peut se casser après les mises à jour Proxmox",
|
||||
"breakBody": "Les mises à jour de l’interface Proxmox écrasent régulièrement <code>proxmoxlib.js</code>, ce qui peut faire revenir le rappel. Vous pouvez réappliquer l’option pour modifier le fichier ou garder le rappel jusque-là. ProxMenux installe aussi un hook APT qui réapplique la modification après les mises à niveau de paquets ; voir <link>Désinstaller les optimisations</link> pour sa suppression.",
|
||||
"legalTitle": "Note juridique (il vaut toujours la peine de répéter)",
|
||||
"legalBody": "Cette option masque seulement le rappel de l’interface. Elle ne donne <strong>pas</strong> droit au support Enterprise ni au dépôt Enterprise et ne change pas la licence du logiciel. Proxmox VE est publié sous GNU AGPLv3. Un abonnement soutient le projet et donne accès au canal de mises à jour Enterprise ; choisissez le niveau de support adapté à votre environnement."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Vérification",
|
||||
"intro": "Après avoir appliqué les trois :",
|
||||
"reversibleTitle": "Les trois changements de personnalisation sont suivis",
|
||||
"reversibleBody": "<link>Désinstaller les optimisations</link> restaure <code>/root/.bashrc</code>, remet MOTD dans son état exact d’avant ProxMenux ou supprime le fichier s’il n’existait pas, et restaure les fichiers d’interface modifiés depuis la sauvegarde ou réinstalle les paquets concernés si nécessaire."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Facultatif",
|
||||
"href": "/docs/post-install/optional",
|
||||
"tail": "— Fastfetch et Figurine (autres personnalisations visuelles)."
|
||||
},
|
||||
{
|
||||
"label": "Afficher les informations sur la version",
|
||||
"href": "/docs/settings/show-version-information",
|
||||
"tail": "— confirme que les personnalisations sont suivies comme installées."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — restaurer bashrc, motd et le rappel d’abonnement."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Script post-installation de Proxmox VE — Automatisé et personnalisable | ProxMenux",
|
||||
"description": "Présentation des scripts post-installation de ProxMenux pour Proxmox VE. Le script Automatisé applique des valeurs par défaut raisonnables sans question ; le script Personnalisable permet de choisir précisément parmi 10 catégories ; Désinstaller les optimisations restaure les modifications réversibles prises en charge.",
|
||||
"ogTitle": "Proxmox VE Script post-installation — automatisé et personnalisable",
|
||||
"ogDescription": "Appliquez les optimisations courantes après installation de Proxmox VE dans 10 catégories, automatiquement ou à la carte, avec des options réversibles.",
|
||||
"twitterTitle": "Script post-installation de Proxmox VE | ProxMenux",
|
||||
"twitterDescription": "Optimisations automatisées et personnalisables post-installation pour Proxmox VE — avec options réversibles."
|
||||
},
|
||||
"header": {
|
||||
"title": "Scripts post-installation",
|
||||
"description": "Configurez un hôte Proxmox VE fraîchement installé avec les optimisations post-installation de ProxMenux. Appliquez automatiquement la configuration de base, choisissez des options individuelles, mettez à jour les fonctions installées ou restaurez les modifications réversibles prises en charge. Les mises à niveau de paquets ne sont pas présentées comme réversibles.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "À quoi sert ce menu",
|
||||
"body": "Après l’installation de Proxmox VE, des dizaines de petites modifications rendent l’hôte plus rapide et plus facile à entretenir : dépôts sans abonnement, limites journald raisonnables, tampons TCP adaptés, stockage des journaux ménageant les SSD, améliorations de bashrc et plus encore. ProxMenux les automatise et suit les modifications de configuration réversibles prises en charge."
|
||||
},
|
||||
"openingMenu": {
|
||||
"heading": "Ouverture du menu",
|
||||
"body": "Dans le menu principal de ProxMenux, sélectionnez <strong>Paramètres après l'installation Proxmox</strong>. Vous verrez ceci :",
|
||||
"imageAlt": "Menu des scripts post-installation : Automatisé, Personnalisable, l’entrée conditionnelle Appliquer les mises à jour disponibles (uniquement si des mises à jour sont en attente) et Désinstaller, suivis de la section Scripts communautaires"
|
||||
},
|
||||
"threeWays": {
|
||||
"heading": "Quatre façons d'appliquer les optimisations",
|
||||
"body": "Les quatre entrées ProxMenux partagent le même code et le même registre d’outils installés, mais offrent différents niveaux de contrôle. <em>Appliquer les mises à jour disponibles</em> n’apparaît que si la version sur disque d’au moins une optimisation installée est plus récente que la version enregistrée ; l’entrée reste masquée juste après la configuration de l’hôte."
|
||||
},
|
||||
"routes": [
|
||||
{
|
||||
"title": "Automatisé",
|
||||
"description": "Une sélection de 14 optimisations sûres et toujours utiles, appliquées successivement sans question. Un bon choix par défaut pour la plupart des utilisateurs.",
|
||||
"bullets": [
|
||||
"Dépôts sans abonnement + mise à niveau du système",
|
||||
"Mémoire, noyau, réglage réseau",
|
||||
"Log2RAM (détecté automatiquement sur SSD/NVMe)",
|
||||
"Limites de taille pour journald + logrotate",
|
||||
"Noms d'interface persistants"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Personnalisable",
|
||||
"description": "Environ 35 optimisations individuelles dans 10 catégories. Vous choisissez précisément lesquelles appliquer. Même moteur qu’Automatisé, avec un contrôle complet.",
|
||||
"bullets": [
|
||||
"Interface à cases à cocher par catégorie",
|
||||
"Inclut tout ce que fait Automatisé, plus des options à activer explicitement (IOMMU, Fastfetch, Figurine, Ceph, HA, correctifs AMD…)",
|
||||
"Exécutez-le autant de fois que voulu : les modifications sont idempotentes"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Appliquer les mises à jour disponibles",
|
||||
"description": "Si une optimisation post-installation (Log2Ram, paramètres de mémoire, Logrotate…) a une version sur disque plus récente que celle enregistrée sur l’hôte, cette entrée affiche uniquement les optimisations concernées. Elle relance leur fonction et actualise le registre, sans rien toucher d’autre.",
|
||||
"bullets": [
|
||||
"Activation individuelle par optimisation, uniquement celles modifiées",
|
||||
"Même sélecteur disponible dans le tableau de bord Monitor",
|
||||
"Une seule notification groupée lorsque de nouvelles mises à jour sont disponibles"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Désinstaller les optimisations",
|
||||
"description": "Les modifications réversibles prises en charge sont suivies dans un registre JSON et associées à une fonction de restauration. Les actions sans retour en arrière sûr, comme une mise à niveau complète des paquets, sont volontairement exclues.",
|
||||
"bullets": [
|
||||
"Détecte automatiquement les optimisations précédemment appliquées",
|
||||
"Choisit le retour adapté à chaque élément : restaurer une sauvegarde .bak si elle existe, supprimer le fragment de configuration sysctl.d si rien ne nécessitait de sauvegarde, ou réinstaller le paquet d’origine avec --force-confnew (par exemple pour la bannière d’abonnement)",
|
||||
"Demande de redémarrage si nécessaire (VFIO, noms persistants, etc.)"
|
||||
]
|
||||
}
|
||||
],
|
||||
"whichTitle": "Lequel choisir ?",
|
||||
"whichBody": "Pour une nouvelle installation de Proxmox avec une configuration de base raisonnable sans décisions à prendre : <autoLink><strong>Automatisé</strong></autoLink>. Si vous connaissez déjà les réglages souhaités ou à éviter : <customLink><strong>Personnalisable</strong></customLink>. Pour ne mettre à jour qu’une optimisation déjà appliquée dont une version plus récente est sur disque : <updatesLink><strong>Appliquer les mises à jour disponibles</strong></updatesLink>. Pour annuler proprement une modification précédente : <uninstallLink><strong>Désinstaller les optimisations</strong></uninstallLink>. Vous pouvez combiner ces modes : commencez par Automatisé, ajoutez Fastfetch ou IOMMU avec Personnalisable, puis annulez des éléments individuels plus tard.",
|
||||
"mixing": {
|
||||
"heading": "Mélange avec d'autres scripts post-installation",
|
||||
"stackTitle": "Ne pas empiler plusieurs scripts post-installation",
|
||||
"stackBody": "Exécuter plusieurs scripts post-installation sur le même hôte peut créer des fichiers de configuration en double, des entrées sysctl contradictoires ou même casser le réseau après redémarrage. Si vous avez déjà appliqué <strong>Helper-Scripts Post Install</strong>, certaines optimisations ProxMenux peuvent recouper sa configuration. Utilisez un seul outil post-installation par hôte.",
|
||||
"xshokTitle": "xshok-proxmox: déprécié",
|
||||
"xshokBody": "Les anciennes versions de ProxMenux présentaient <a>xshok-proxmox</a> comme outil post-installation complémentaire. Ce projet est désormais obsolète et n’est plus proposé dans ProxMenux. Si une ancienne exécution a laissé des marqueurs sur l’hôte, ProxMenux les détecte toujours et vous avertit. Ce n’est toutefois plus un outil à installer aux côtés de ProxMenux."
|
||||
},
|
||||
"community": {
|
||||
"heading": "Scripts communautaires",
|
||||
"body": "Le menu propose aussi deux scripts tiers du projet <a>community-scripts</a> : <em>Proxmox VE Post Install</em> et <em>Proxmox VE Microcode</em>. Ces enveloppes téléchargent et exécutent les scripts originaux via <code>wget | bash</code>. ProxMenux ne les maintient pas. Consultez <link>Dépôts externes</link> pour les détails et les questions de confiance avant de les lancer."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Mise à jour du système Proxmox",
|
||||
"href": "/docs/utils/system-update",
|
||||
"tail": "— tient l'hôte à jour une fois qu'il a été installé."
|
||||
},
|
||||
{
|
||||
"label": "Sécurité",
|
||||
"href": "/docs/security",
|
||||
"tail": "— Fail2Ban + Lynis au-dessus du durcissement post-installation."
|
||||
},
|
||||
{
|
||||
"label": "Afficher les informations sur la version",
|
||||
"href": "/docs/settings/show-version-information",
|
||||
"tail": "— voir quels composants post-installation sont suivis comme installés."
|
||||
},
|
||||
{
|
||||
"label": "Commandes de mises à jour et de paquets",
|
||||
"href": "/docs/help-info/update-commands",
|
||||
"tail": "— référence pour apt / pveupgrade."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,56 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Surveillance | Documentation ProxMenux",
|
||||
"description": "Options de surveillance dans le script de post-installation personnalisable ProxMenux. Actuellement une seule option : installer OVH Real-Time Monitoring (RTM), qui ne s'active que si l'hôte est détecté comme serveur OVH."
|
||||
},
|
||||
"header": {
|
||||
"title": "Après installation : surveillance",
|
||||
"description": "Options de surveillance dans le script de post-installation personnalisable. Cette catégorie est petite et spécifique au fournisseur, elle installe l'agent de surveillance en temps réel OVH sur des serveurs OVH dédiés et ne fait rien ailleurs.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Un périmètre volontairement limité",
|
||||
"body": "La surveillance post-installation se limite à <strong>un agent propre à un fournisseur</strong>. Les outils généraux (Prometheus, Grafana, node_exporter) sont hors périmètre, car leurs choix d’architecture — hôte séparé, conservation des données, destinataires des alertes — dépassent une étape en un clic. ProxMenux Monitor, inclus dans ProxMenux, remplit l’essentiel de ce rôle sans agent externe."
|
||||
},
|
||||
"ovh": {
|
||||
"heading": "Installer la surveillance en temps réel OVH (RTM)",
|
||||
"intro": "Si votre hôte Proxmox est un serveur dédié loué à partir de <a>OVHcloud</a>, vous pouvez permettre à RTM d'exposer la télémétrie matérielle (température CPU, statut PSU, disque SMART, état contrôleur RAID, etc.) au panneau de contrôle OVH. C'est le même agent OVH utilise pour leur propre fonction \"Surveillance du serveur\".",
|
||||
"decisionsTitle": "La décision de ProxMenux",
|
||||
"decisionsItems": [
|
||||
"Obtenez l'IP public de l'hôte via <code>curl ipinfo.io/ip</code>.",
|
||||
"Examine le FAI propriétaire avec une requête <code>whois</code> sur <code>v4.whois.cymru.com</code>.",
|
||||
"Si le résultat mentionne OVH, télécharge <code>last-public-ovh-infra-yak.snap.mirrors.ovh.net/yak/archives/apply.sh</code> et le transmet à <code>bash</code> avec le manifeste Puppet de RTM v2.",
|
||||
"Si le résultat ne mentionne <em>pas</em> OVH, rien n'est installé. L'option est sans opération."
|
||||
],
|
||||
"remoteTitle": "Le script distant est passé à bash",
|
||||
"remoteBody": "L’installation exécute <code>wget -qO - https://…apply.sh | bash</code>. Si le miroir OVH est compromis, le script s’exécute en root sur votre hôte. Avant d’activer l’option, mettez en balance la confiance dans la chaîne de miroirs OVH et le bénéfice de surveillance. Pour la plupart des utilisateurs de laboratoires domestiques ou hors OVH, l’option devrait rester désactivée.",
|
||||
"noOpTitle": "Activer uniquement si l'hôte est effectivement à OVH",
|
||||
"noOpBody": "L'option est un non-op sur les serveurs non-OVH, donc cochez-le sur un Proxmox home-lab ne casse rien. Sur un hôte non-OVH le script imprime <em>\"Pas un serveur OVH, sauter l'installation RTM\"</em> et sortir proprement; aucun paquet n'est installé.",
|
||||
"runsTitle": "Ce que ProxMenux exécute",
|
||||
"verifyTitle": "Vérification",
|
||||
"verifyBody": "Sur un véritable hôte OVH, après un redémarrage, vous devriez voir le tableau de bord <a>RTM</a> dans votre gestionnaire OVH peuplé de données en direct pour l'hôte. Du côté Proxmox, le capteur RTM est un service systemd — vérifiez-le directement:",
|
||||
"troubleTitle": "Dépannage",
|
||||
"revertTitle": "Supprimer RTM depuis le menu Désinstaller",
|
||||
"revertBody": "Si RTM est enregistré comme installé, Désinstaller les optimisations propose une entrée OVH Real-Time Monitoring. Elle exécute <code>apt-get purge -y ''ovh-rtm*'' ''rtm'' ''rtm-*''</code>, supprime /etc/rtm et marque RTM comme désinstallé. Des éléments Puppet peuvent encore nécessiter un nettoyage manuel ; examinez les manifestes propres à RTM dans <code>/etc/puppet/</code>. Sur un hôte hors OVH, aucun paquet RTM n’a été installé, donc rien n’est à supprimer."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "ProxMenux Monitor",
|
||||
"href": "/docs/settings/proxmenux-monitor",
|
||||
"tail": "— tableau de bord web local pour l'hôte (travaille sur n'importe quel fournisseur, pas seulement OVH)."
|
||||
},
|
||||
{
|
||||
"label": "Commandes système utiles",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": "— référence de surveillance des hôtes locaux."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Réseau | Documentation ProxMenux",
|
||||
"description": "Options réseau du script de post-installation personnalisable ProxMenux : forcer APT sur IPv4, appliquer un profil sysctl sélectionné, installer Open vSwitch, activer TCP BBR + Fast Open et associer les noms d’interfaces aux adresses MAC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Installation: Réseau",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Cinq options réseau indépendantes. Deux sont simples (<strong>APT sur IPv4</strong>, <strong>installation d’Open vSwitch</strong>), deux règlent le comportement TCP (<strong>profil sysctl réseau</strong>, <strong>BBR + Fast Open</strong>) et une résout un problème courant : <strong>fixer les noms d’interfaces</strong> pour qu’une nouvelle carte réseau ou une mise à jour du BIOS ne renomme pas <code>enp3s0</code> en <code>enp4s0</code> et ne casse pas vos ponts."
|
||||
},
|
||||
"ipv4": {
|
||||
"heading": "Forcer APT à utiliser IPv4",
|
||||
"intro": "Écrit <code>Acquire::ForceIPv4 \"true\";</code> à <code>/etc/apt/apt.conf.d/99-force-ipv4</code>. APT refuse alors d'utiliser IPv6 pour les téléchargements de paquets, même si l'hôte a une connectivité IPv6.",
|
||||
"tipTitle": "Bénéficiaires",
|
||||
"tipBody": "Utile si la connexion IPv6 est instable, plus lente qu’IPv4 ou si le miroir Debian/Proxmox échoue parfois en IPv6. Sans effet indésirable sur les hôtes sans IPv6. Sur un réseau double pile sain, le comportement devient prévisible : apt ne vous surprendra pas avec un délai d’attente IPv6 dépassé."
|
||||
},
|
||||
"sysctl": {
|
||||
"heading": "Appliquer les optimisations réseau",
|
||||
"intro": "Écrit un profil sysctl sélectionné dans <code>/etc/sysctl.d/99-network.conf</code> : tampons de sockets du noyau, durcissement ICMP, protection de base contre l’usurpation d’adresse et tailles de tampons TCP adaptées à un hyperviseur avec de nombreux flux simultanés.",
|
||||
"tunedTitle": "Paramètres ajustés",
|
||||
"headerArea": "Domaine",
|
||||
"headerSettings": "Paramètres clés",
|
||||
"rows": [
|
||||
{
|
||||
"area": "Tampons de sockets du noyau",
|
||||
"settings": "<code>netdev_max_backlog=8192</code>, <code>rmem_max=16M</code>, <code>wmem_max=16M</code>, <code>somaxconn=8192</code>"
|
||||
},
|
||||
{
|
||||
"area": "durcissement ICMP",
|
||||
"settings": "<code>icmp_echo_ignore_broadcasts=1</code>, <code>icmp_ignore_bogus_error_responses=1</code>"
|
||||
},
|
||||
{
|
||||
"area": "Sécurité du routage",
|
||||
"settings": "<code>accept_redirects=0</code>, <code>accept_source_route=0</code>, <code>secure_redirects=0</code>, <code>send_redirects=0</code>, <code>log_martians=0</code>"
|
||||
},
|
||||
{
|
||||
"area": "Filtre de chemin inversé",
|
||||
"settings": "<code>rp_filter=2</code> (mode souple, voir la note ci-dessous)"
|
||||
},
|
||||
{
|
||||
"area": "TCP",
|
||||
"settings": "<code>tcp_mtu_probing=1</code>, <code>tcp_rfc1337=1</code>, <code>tcp_sack=1</code>, <code>tcp_rmem=8K/87K/16M</code>, <code>tcp_wmem=8K/64K/16M</code>"
|
||||
},
|
||||
{
|
||||
"area": "Ports",
|
||||
"settings": "<code>ip_local_port_range=1024 65535</code> (plage de ports éphémères)"
|
||||
},
|
||||
{
|
||||
"area": "Sockets Unix",
|
||||
"settings": "<code>net.unix.max_dgram_qlen=4096</code>"
|
||||
}
|
||||
],
|
||||
"sourceOutro": "Il ajoute également <code>source /etc/network/interfaces.d/*</code> à <code>/etc/network/interfaces</code> si ce n'est déjà présent — pratique standard pour que vous puissiez déposer des extraits d'interface modulaires sans modifier le fichier principal.",
|
||||
"fwbrTitle": "Réglage automatique des ponts pare-feu virtuels",
|
||||
"fwbrBody": "En plus du profil sysctl, ProxMenux installe le script auxiliaire <code>/usr/local/sbin/proxmenux-fwbr-tune</code>, qui applique <code>rp_filter=0</code> et <code>log_martians=0</code> aux interfaces <code>fwbr*</code> / <code>fwln*</code> / <code>fwpr*</code> / <code>tap*</code> créées par Proxmox pour les VM et conteneurs. L’unité à exécution unique <code>proxmenux-fwbr-tune.service</code> le lance au démarrage, et la règle <code>/etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules</code> à chaque événement <code>net add</code> correspondant à ces préfixes. Cela couvre les interfaces recréées au démarrage ou à l’arrêt des VM, au redémarrage et à la migration à chaud. Le script traite aussi les interfaces existantes immédiatement après l’installation.",
|
||||
"rpFilterTitle": "Pourquoi rp_filter=2 (souple) plutôt que 1 (strict)",
|
||||
"rpFilterBody": "Le filtrage strict du chemin inverse rejette les paquets dont l’adresse source serait accessible par une interface <em>différente</em>. C’est une valeur par défaut adaptée aux clients, mais problématique sur un hôte Proxmox où le trafic VM arrive souvent par un pont et repart par une liaison montante avec des routes asymétriques. <code>rp_filter=2</code> (souple) ne rejette que les paquets dont la source est réellement injoignable par routage. Le compromis réduit légèrement la détection de l’usurpation d’IP locale pour préserver le réseau des VM."
|
||||
},
|
||||
"ovs": {
|
||||
"heading": "Installer Open vSwitch",
|
||||
"intro": "Installe <code>openvswitch-switch</code> + <code>openvswitch-common</code>. Ces paquets ajoutent OVS comme alternative aux ponts Linux utilisés par défaut par Proxmox. L’installation seule ne modifie pas le réseau : les ponts <code>vmbrX</code> existants continuent de fonctionner. Lorsque vous <em>créez</em> un nouveau pont dans Proxmox, OVS devient disponible dans la liste des types.",
|
||||
"tipTitle": "Quand OVS a du sens",
|
||||
"tipBody": "Envisagez OVS pour <strong>des trunks VLAN avec des ID non contigus</strong>, <strong>LACP avec LLDP dans certains modes</strong>, <strong>la programmation fine des flux</strong> (OpenFlow) ou l’interopérabilité avec les contrôleurs SDN. Pour un laboratoire domestique avec quelques VLAN et une seule liaison montante LACP, les ponts Linux + <code>vmbrX.VID</code> sont plus simples et tout à fait adaptés.",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "OVS est enregistré. <link>Désinstaller les optimisations</link> lance <code>apt purge</code> pour <code>openvswitch-switch</code> et <code>openvswitch-common</code>. Migrez les ponts OVS vers des ponts Linux <em>avant</em> la désinstallation, sinon leurs VM perdront le réseau au prochain démarrage. Équivalent manuel :"
|
||||
},
|
||||
"bbr": {
|
||||
"heading": "Activer TCP BBR + TCP Fast Open",
|
||||
"intro": "Écrit deux fichiers sysctl et les recharge. BBR remplace CUBIC par l’algorithme de congestion de Google fondé sur la bande passante, qui gère mieux les liaisons à forte capacité et latence ou avec pertes. TCP Fast Open (TFO) économise un aller-retour sur les connexions TCP répétées en envoyant des données dans le SYN.",
|
||||
"verifyTitle": "Vérification",
|
||||
"impactTitle": "L'impact dépend de la charge de travail",
|
||||
"impactBody": "BBR brille sur des liaisons à haute latence ou à perte (réplication transcontinentale, tunnels VPN, clients mobiles). Sur un LAN entre deux machines sur le même commutateur, la différence est souvent dans le bruit. TFO aide les connexions courtes et répétées HTTP le plus.",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "BBR/TFO sont enregistrés. <link>Désinstaller les optimisations</link> supprime les deux fichiers sysctl (<code>/etc/sysctl.d/99-kernel-bbr.conf</code> et <code>99-tcp-fastopen.conf</code>) et recharge la configuration restante. Supprimer un fichier ne réinitialise pas ses valeurs actives dans le noyau. Les valeurs par défaut comme <code>cubic</code> et <code>tcp_fastopen=1</code> reviennent après un redémarrage, sauf si une autre configuration les remplace. Équivalent manuel :"
|
||||
},
|
||||
"names": {
|
||||
"heading": "Noms d’interfaces persistants",
|
||||
"intro": "Parcourt les cartes réseau physiques de l’hôte, en excluant loopback, les veth Docker, les ponts, les périphériques TAP, les bonds, Cilium, ZeroTier et WireGuard. Écrit un fichier systemd <code>.link</code> associant le nom actuel à l’adresse MAC actuelle. Cette association prend alors le pas sur le nommage automatique du noyau.",
|
||||
"whyTitle": "Pourquoi cela est important",
|
||||
"whyItems": [
|
||||
"L'ajout ou la suppression de périphériques PCIe peut déplacer la numérotation du bus, transformer <code>enp3s0</code> en <code>enp4s0</code>. Si votre <code>/etc/network/interfaces</code> fait référence à l'ancien nom, le pont disparaît sur le redémarrage.",
|
||||
"Les mises à jour du BIOS ou du firmware changent parfois l’énumération des périphériques, avec le même effet.",
|
||||
"Le script écrit des fichiers <code>.link</code> pour les cartes physiques, y compris les ports des bonds, avec la MAC indiquée par sysfs à ce moment ; pour les ports d’un bond, il peut s’agir de la MAC partagée du bond, vérifiez donc leurs noms après un redémarrage. Il ignore les interfaces virtuelles, comme les veth LXC et les bonds eux-mêmes ; il ne corrige pas les courses au nommage des cartes virtuelles <code>hotplug</code>."
|
||||
],
|
||||
"writtenTitle": "Ce qui est écrit",
|
||||
"writtenIntro": "Un fichier par NIC physique, au <code>/etc/systemd/network/10-proxmenux-<iface>.link</code>. Chaque fichier commence par l'en-tête <code># Managed by ProxMenux — do not edit</code> de sorte que ProxMenux puisse distinguer ses propres fichiers des fichiers <code>.link</code> fournis par l'utilisateur ou le paquet.",
|
||||
"writtenOutro": "Les fichiers <code>.link</code> d’autres paquets ou écrits par l’utilisateur sont conservés ; seuls ceux portant l’en-tête ProxMenux sont gérés. À chaque nouvelle exécution, la fonction vérifie ses fichiers : elle relit <code>MACAddress=</code> dans chaque <code>10-proxmenux-*.link</code> et supprime ceux dont la MAC n’apparaît plus sous <code>/sys/class/net/</code>. Les fichiers d’anciennes versions ProxMenux au format <code>10-<iface>.link</code> sont migrés automatiquement la première fois.",
|
||||
"pveTitle": "PVE 9 vs PVE 8",
|
||||
"pveBody": "Le script utilise des fichiers systemd <code>.link</code> pour les noms persistants. Sur Proxmox VE 9, il recharge aussi les règles udev après écriture afin qu’une carte déjà fixée qui est rebranchée ou redétectée applique sa règle sans redémarrage. Vérifiez les interfaces existantes après un redémarrage sur PVE 8 comme sur PVE 9. Cela ne remplace pas <code>ifupdown2</code> sur l’hôte. Le script demande un redémarrage dans les deux cas via la post-installation personnalisable.",
|
||||
"reviewTitle": "Examiner d'abord les /etc/network/interfaces existants",
|
||||
"reviewBody": "Si l’ancienne configuration dans <code>/etc/network/interfaces</code> utilise des noms de cartes générés par le noyau, fixer les noms <em>actuels</em> est le résultat souhaité. Si vous avez déjà adapté la configuration à des noms précis, vérifiez soigneusement que les noms fixés correspondent au fichier interfaces avant de redémarrer.",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "<link>Désinstaller les optimisations</link> supprime uniquement les fichiers <code>10-proxmenux-*.link</code> portant l’en-tête ProxMenux dans <code>/etc/systemd/network/</code>. Les fichiers <code>.link</code> de l’utilisateur ou d’autres paquets sont conservés. Le nommage par défaut de systemd revient au prochain redémarrage."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Gestion du réseau",
|
||||
"href": "/docs/network",
|
||||
"tail": "— diagnostic, analyse des ponts, réparations guidées."
|
||||
},
|
||||
{
|
||||
"label": "Noms d'interface persistants",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": " — la même fonction dans un menu distinct pour plus tard ; utilisez l’une ou l’autre option, pas les deux."
|
||||
},
|
||||
{
|
||||
"label": "Référence des commandes réseau",
|
||||
"href": "/docs/help-info/network-commands",
|
||||
"tail": " — ip, ss, ethtool, sysctl."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — annuler ces changements réseau."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,177 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Post-Installation: Paramètres optionnels",
|
||||
"description": "Guide des paramètres optionnels dans le script ProxMenux post-installation pour les fonctionnalités et optimisations supplémentaires de Proxmox VE.",
|
||||
"ogTitle": "ProxMenux Post-Installation: Paramètres optionnels",
|
||||
"ogDescription": "Guide des paramètres optionnels dans le script ProxMenux post-installation pour les fonctionnalités et optimisations supplémentaires de Proxmox VE.",
|
||||
"ogImageAlt": "Paramètres optionnels après l'installation de ProxMenux"
|
||||
},
|
||||
"title": "Paramètres optionnels",
|
||||
"intro": "La catégorie <strong>Paramètres optionnels</strong> fournit des fonctions et optimisations supplémentaires à appliquer à Proxmox VE. Elles ne sont pas essentielles, mais peuvent améliorer les possibilités du système dans certains cas.",
|
||||
"available": "Fonctions optionnelles disponibles",
|
||||
"stepLabel": "Étape",
|
||||
"ceph": {
|
||||
"title": "Ajouter le dernier support Ceph",
|
||||
"intro": "Cette option installe la dernière prise en charge du système de stockage Ceph pour Proxmox VE. Ceph est un système de stockage distribué qui offre des performances élevées, la fiabilité et l'évolutivité.",
|
||||
"doesIntro": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Ajoute le dépôt Ceph à votre système",
|
||||
"Mise à jour des listes de paquets",
|
||||
"Installe les paquets Ceph en utilisant la commande 'pveceph install'",
|
||||
"Vérification de l'installation"
|
||||
],
|
||||
"howUse": "Comment utiliser : Après l'installation, vous pouvez configurer et gérer le stockage Ceph en utilisant l'interface web ou les outils en ligne de commande Proxmox VE.",
|
||||
"automates": "Ce réglage automatise les commandes suivantes :"
|
||||
},
|
||||
"amd": {
|
||||
"title": "Appliquer les correctifs AMD CPU",
|
||||
"intro": "Cette option applique des corrections spécifiques pour les processeurs AMD EPYC et Ryzen pour améliorer la stabilité et la compatibilité.",
|
||||
"doesIntro": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Détecte si un AMD EPYC ou Ryzen CPU est présent",
|
||||
"Applique le paramètre du noyau idle=nomwait pour prévenir les plantages aléatoires (via /etc/kernel/cmdline sur les hôtes systemd-boot ou /etc/default/grub sur les hôtes GRUB, avec une copie .bak de l’original).",
|
||||
"Configure KVM pour ignorer certains MSR (Registres spécifiques au modèle) pour une meilleure compatibilité des clients Windows"
|
||||
],
|
||||
"howUse": "Comment utiliser: Ces corrections sont appliquées automatiquement et nécessitent un redémarrage du système pour prendre effet.",
|
||||
"automates": "Ce réglage automatise les commandes suivantes :"
|
||||
},
|
||||
"ha": {
|
||||
"title": "Activer les services à haute disponibilité",
|
||||
"intro": "Cette option active les services de haute disponibilité (HA) de Proxmox VE, permettant la reprise automatique des VM et conteneurs sur un autre nœud en cas de panne.",
|
||||
"doesIntro": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Active et démarre le service pve-ha-lrm (gestionnaire des ressources locales)",
|
||||
"Active et démarre le service pve-ha-crm (Gestionnaire des ressources de la grappe)",
|
||||
"Active et démarre le service Corosync pour la communication cluster"
|
||||
],
|
||||
"howUse": "Comment utiliser: Après avoir activé ces services, vous pouvez configurer des groupes et des ressources HA dans l'interface web Proxmox VE.",
|
||||
"automates": "Ce réglage automatise les commandes suivantes :"
|
||||
},
|
||||
"pveam": {
|
||||
"title": "Mettre à jour le gestionnaire d'appliances Proxmox VE",
|
||||
"intro": "Actualise l’index local des modèles de conteneurs exposé par <code>pveam</code> dans Proxmox, afin que les appliances logicielles disponibles soient à jour à la prochaine création d’un LXC.",
|
||||
"doesIntro": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Exécute <code>pveam update</code> sur les miroirs Proxmox pour récupérer le catalogue actuel des appliances logicielles",
|
||||
"Remplit la liste des appliances logicielles affichée lors de la création d’un conteneur"
|
||||
],
|
||||
"howUse": "Utilisation : exécutez-le si la liste des appliances logicielles semble ancienne ou après un changement de miroir. Il télécharge uniquement l’index du catalogue, pas les modèles eux-mêmes.",
|
||||
"automates": "Ce réglage automatise la commande suivante :"
|
||||
},
|
||||
"fastfetch": {
|
||||
"title": "Installer et configurer Fastfetch",
|
||||
"intro": "Cette option installe et configure en silence Fastfetch, un outil d'information système qui affiche les spécifications du système et un logo personnalisé lors de la connexion.",
|
||||
"doesLabel": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Télécharge et installe silencieusement la dernière version de Fastfetch",
|
||||
"Vous permet de choisir un logo personnalisé (<strong>ProxMenux, Proxmox, Helper-Scripts, Home-Labs-Club, Proxmology</strong>, ou un logo personnalisé)",
|
||||
"Configure Fastfetch pour afficher <em>\"Système optimisé par ProxMenux\"</em>",
|
||||
"Configure Fastfetch pour fonctionner automatiquement à la connexion de la console"
|
||||
],
|
||||
"importantLabel": "Important:",
|
||||
"importantBody": "Si vous vous connectez à Proxmox via SSH, sélectionnez le logo <strong>Proxmox</strong> ou créez un logo personnalisé en utilisant <code>jp2a</code> ou <code>img2txt</code>. Les autres logos sont générés en utilisant <code>chafa</code> et peuvent ne pas s'afficher correctement dans une session standard SSH.",
|
||||
"customLabel": "Logos personnalisés :",
|
||||
"customBody1": "Pour utiliser un logo personnalisé, placez votre fichier texte art ASCII dans : <code>/usr/local/share/fastfetch/logos/</code>",
|
||||
"customBody2": "Vous pouvez créer des logos personnalisés en utilisant des outils tels que <code>chafa</code>, <code>jp2a</code> ou <code>img2txt</code>.",
|
||||
"customBody3": "Pour de meilleurs résultats:",
|
||||
"customItems": [
|
||||
"Limitez la hauteur du logo à 35 lignes pour conserver les proportions et tenir dans le terminal",
|
||||
"Utilisez <code>chafa</code> pour les logos couleur (peut ne pas s'afficher correctement dans les sessions SSH)",
|
||||
"Utiliser <code>jp2a</code> ou <code>img2txt</code> pour les logos compatibles SSH"
|
||||
],
|
||||
"examplesLabel": "Exemple de logos :",
|
||||
"logos": [
|
||||
{
|
||||
"name": "ProxMenux",
|
||||
"alt": "Logo ProxMenux",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmenux.png"
|
||||
},
|
||||
{
|
||||
"name": "Proxmox",
|
||||
"alt": "Logo Proxmox",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmox.png"
|
||||
},
|
||||
{
|
||||
"name": "JC Channel",
|
||||
"alt": "Logo JC Channel",
|
||||
"src": "/fastfetch/jc-channel.png"
|
||||
},
|
||||
{
|
||||
"name": "Helper-Scripts",
|
||||
"alt": "Logo Helper-Scripts",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/helper-scripts.png"
|
||||
},
|
||||
{
|
||||
"name": "Home-Labs-Club",
|
||||
"alt": "Logo Home-Labs-Club",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/home-labs-club.png"
|
||||
},
|
||||
{
|
||||
"name": "Proxmology",
|
||||
"alt": "Logo Proxmology",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmology.png"
|
||||
}
|
||||
],
|
||||
"automates": "Ce réglage automatise les commandes suivantes :"
|
||||
},
|
||||
"figurine": {
|
||||
"title": "Installer et configurer Figurine",
|
||||
"intro": "Cette option installe et configure Figurine, un outil qui crée des bannières texte ASCII élégantes pour votre terminal, affichant votre nom d'hôte dans un format 3D attrayant visuellement.",
|
||||
"doesLabel": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Télécharge et installe Figurine v2.1.1 depuis GitHub pour l’architecture de l’hôte (AMD64, ARM64 ou ARMv7)",
|
||||
"Crée un message de bienvenue qui affiche votre nom d'hôte dans l'art 3D ASCII lorsque vous vous connectez",
|
||||
"Met à jour le binaire Figurine existant une fois le téléchargement et l’extraction terminés avec succès",
|
||||
"Configure le message de bienvenue à exécuter automatiquement à la connexion"
|
||||
],
|
||||
"practicalLabel": "Utilisation pratique:",
|
||||
"practicalBody": "Lors de la gestion de plusieurs nœuds Proxmox dans un cluster, Figurine fournit une indication visuelle immédiate du noeud dans lequel vous êtes actuellement connecté. Cela permet d'éviter les commandes accidentelles sur le mauvais noeud et améliore votre workflow lors de la gestion de plusieurs serveurs.",
|
||||
"exampleLabel": "Exemple de sortie :",
|
||||
"imageAlt": "Figurine Exemple de sortie",
|
||||
"automates": "Ce réglage automatise le processus suivant :",
|
||||
"outro": "Après l'installation, vous verrez votre nom d'hôte affiché dans l'art 3D ASCII chaque fois que vous vous connectez, rendant immédiatement clair sur quel noeud Proxmox vous travaillez."
|
||||
},
|
||||
"log2ram": {
|
||||
"title": "Installer Log2RAM (SSD/NVMe réduction de l'usure)",
|
||||
"intro": "Log2RAM monte <code>/var/log</code> sur un disque RAM tmpfs et le synchronise régulièrement vers le disque. Mettre en mémoire les écritures journald fréquentes peut réduire l’usure SSD et les E/S. La synchronisation et un arrêt propre sauvegardent les journaux ; une coupure brutale peut perdre les entrées depuis la dernière synchronisation.",
|
||||
"upstreamLabel": "Projet en amont:",
|
||||
"upstreamUrl": "https://github.com/azlux/log2ram",
|
||||
"upstreamLinkLabel": "azlux/log2ram sur GitHub",
|
||||
"doesLabel": "Que fait ProxMenux:",
|
||||
"doesItems": [
|
||||
"Détecte si le disque racine est SSD/NVMe en lisant <code>/sys/block/<dev>/queue/rotational</code>. Sur un disque rotatif, le flux automatisé demande d'abord avant d'installer.",
|
||||
"Clone le dépôt original (<code>azlux/log2ram</code>) dans <code>/tmp/log2ram</code> et modifie <code>install.sh</code> en remplaçant <code>rsync -aAXv</code> par <code>rsync -aXv --no-acls</code>. Cela évite l’erreur <em>set_acl: Operation not supported</em> avec code de sortie 23, déclenchée par le script original lors du déplacement de /var/log sur un système sans ACL. L’unité systemd <code>log2ram</code> est activée après installation.",
|
||||
"Dimensionne le disque RAM selon la mémoire de l’hôte : <code>≤ 8 GB → 128M</code>, <code>≤ 16 GB → 256M</code>, <code>> 16 GB → 512M</code>. Écrit la valeur dans <code>SIZE=</code> de <code>/etc/log2ram.conf</code>.",
|
||||
"Planifie une synchronisation périodique du disque via <code>/etc/cron.d/log2ram</code> : toutes les 1h / 3h / 6h selon le même niveau RAM.",
|
||||
"Installe <code>/usr/local/bin/log2ram-check.sh</code>, lancé toutes les 10 minutes par <code>/etc/cron.d/log2ram-auto-sync</code>. Quand <code>/var/log</code> atteint 80% du disque RAM, il purge les anciens journaux journald. À 92%, il lance d’abord <code>logrotate -f /etc/logrotate.d/proxmox-backup-api</code> si le fichier existe : les journaux API PBS occupent souvent le plus d’espace sur un hôte PBS. Il tronque ensuite <code>pveproxy access/error</code> et <code>pveam.log</code> avant synchronisation. <code>log2ram write</code> seul copie tmpfs sur disque sans le réduire. Cette protection aide à éviter un arrêt de PVE avec <em>No space left on device</em> lorsque les journaux grossissent sans contrôle.",
|
||||
"Détecte le service <code>proxmox-backup-server</code> sur l’hôte. S’il est présent, crée <code>/etc/logrotate.d/proxmox-backup-api</code> (20 Mo × 3 rotations) et <code>/etc/cron.hourly/proxmox-backup-logrotate</code> pour limiter les journaux API PBS, souvent à l’origine de la croissance, même entre les synchronisations Log2RAM. Sans PBS, cette étape ne change rien.",
|
||||
"Ajuste les limites systemd-journald (<code>SystemMaxUse</code>, <code>RuntimeMaxUse</code>) pour qu'elles s'adaptent au disque virtuel afin qu'une seule rafale ne puisse pas le remplir.",
|
||||
"S’enregistre dans <code>installed_tools.json</code> pour pouvoir être annulé via Désinstaller les optimisations."
|
||||
],
|
||||
"howUseLabel": "Comment utiliser:",
|
||||
"howUseBody": "Le parcours automatisé installe Log2RAM sans intervention si le disque racine est SSD/NVMe. Le parcours personnalisable demande taille, intervalle et activation de la protection. L’invite indique actuellement 90%, mais le script généré utilise les seuils de nettoyage à 80% et intensif à 92% décrits plus haut.",
|
||||
"verifyLabel": "Vérifier et gérer à partir du shell:",
|
||||
"verifyCode": "# Service state and configured timers\nsystemctl status log2ram\nsystemctl list-timers log2ram*\n\n# Current ramdisk usage — /var/log IS the tmpfs itself\ndf -h /var/log\n\n# Force a sync now (tmpfs → disk); does NOT shrink the tmpfs\nlog2ram write\n\n# Trigger the auto-sync guard on demand (vacuum + sync when usage is high)\n/usr/local/bin/log2ram-check.sh\n\n# Current config: SIZE, mail settings, path\ncat /etc/log2ram.conf\n\n# ProxMenux-specific cron jobs\ncat /etc/cron.d/log2ram /etc/cron.d/log2ram-auto-sync\n\n# Recent Log2RAM activity\njournalctl -u log2ram -n 50 --no-pager"
|
||||
},
|
||||
"zram": {
|
||||
"title": "Activer le profil d'échange ZRAM",
|
||||
"intro": "Crée un périphérique swap compressé en RAM, <code>/dev/zram0</code>, avec <code>systemd-zram-generator</code>. Les pages déplacées vers le swap sont compressées par zstd et conservées en mémoire avant l’utilisation du swap sur disque.",
|
||||
"doesLabel": "Ce qu'il fait:",
|
||||
"doesItems": [
|
||||
"Installe <code>systemd-zram-generator</code> s'il manque, et enregistre si ProxMenux l'a installé.",
|
||||
"Écrit <code>/etc/systemd/zram-generator.conf.d/90-proxmenux.conf</code> : un périphérique <code>zram0</code> d’un dixième de la RAM de l’hôte, compression zstd (<code>zstd(level=9)</code> avec systemd-zram-generator 1.2.0 ou ultérieur) et priorité swap 32767.",
|
||||
"Avec cette priorité, le noyau remplit d'abord ZRAM. Un swap existant sur disque conserve sa propre priorité et prend les pages qui ne correspondent plus à ZRAM.",
|
||||
"Avant de changer quoi que ce soit, recherche une autre configuration ZRAM: un swap zram actif, une ligne zram dans <code>/etc/fstab</code>, une unité systemd ou un autre fichier générateur. Si elle en trouve un, l'option s'arrête et laisse cette configuration telle qu'elle est.",
|
||||
"Démarre <code>dev-zram0.swap</code> et vérifie que l'appareil actif correspond au profil. Sinon, l'état précédent est rétabli.",
|
||||
"S’enregistre dans <code>installed_tools.json</code> pour pouvoir être annulé via Désinstaller les optimisations."
|
||||
],
|
||||
"howUseLabel": "Comment utiliser:",
|
||||
"howUseBody": "Cette option appartient uniquement au parcours personnalisable ; le parcours automatisé ne l’applique pas. Le périphérique est recréé à chaque démarrage. Lorsqu’il est actif, le panneau Mémoire de ProxMenux Monitor affiche capacité, swap utilisé, algorithme, taux de compression et mémoire physique occupée.",
|
||||
"verifyLabel": "Vérifier depuis le shell :",
|
||||
"verifyCode": "# Active swap devices and their priority\nswapon --show\n\n# ZRAM device: algorithm, size and compressed data\nzramctl\n\n# Profile written by ProxMenux\ncat /etc/systemd/zram-generator.conf.d/90-proxmenux.conf\n\n# State of the swap unit\nsystemctl status dev-zram0.swap"
|
||||
},
|
||||
"autoApplication": {
|
||||
"title": "Application automatique",
|
||||
"body": "Dans le parcours personnalisable, choisissez les fonctions selon vos besoins. Log2RAM appartient aussi au parcours automatisé avec détection matérielle ; ZRAM reste réservé au personnalisable. Consultez chaque section pour les confirmations et prérequis."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,61 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Performances | Documentation ProxMenux",
|
||||
"description": "Options de performance du script post-installation personnalisable de ProxMenux. Remplace gzip à un seul thread par pigz (gzip parallèle) pour accélérer les sauvegardes et la compression sur les hôtes multicœurs."
|
||||
},
|
||||
"header": {
|
||||
"title": "Après installation : performances",
|
||||
"description": "Options de performance du script post-installation personnalisable. Cette catégorie contient une seule optimisation : remplacer gzip par pigz pour que les sauvegardes et la compression utilisent tous les cœurs du processeur au lieu d’un seul.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "La seule option de performance ici redirige gzip vers une implémentation parallèle. Les autres réglages de performance (mémoire, ordonnancement des E/S, taille de l’ARC ZFS, limites du noyau) se trouvent dans leurs catégories (<em>Système</em>, <em>Stockage</em>), car ils concernent d’autres sous-systèmes."
|
||||
},
|
||||
"pigz": {
|
||||
"heading": "Utilisez pigz pour une compression gzip plus rapide",
|
||||
"intro": "<code>gzip</code> standard compresse avec <strong>un seul cœur de processeur</strong>. Sur les hôtes Proxmox modernes à 8, 16 ou 32 cœurs, cela limite fortement les sauvegardes VM/CT avec <code>vzdump</code>, la rotation des journaux et tout ce qui passe par <code>gzip</code>. <a>pigz</a> est un remplacement parallèle directement compatible : même sortie compatible gzip, mais travail réparti sur tous les cœurs.",
|
||||
"doesTitle": "Ce que fait ProxMenux",
|
||||
"doesIntro": "Cinq étapes, toutes idempotentes :",
|
||||
"doesItems": [
|
||||
"Définit <code>pigz: 1</code> dans <code>/etc/vzdump.conf</code> pour que l’outil de sauvegarde Proxmox utilise pigz nativement.",
|
||||
"Installe le paquet apt <code>pigz</code> s’il est absent.",
|
||||
"Écrit un script wrapper dans <code>/bin/pigzwrapper</code> qui transmet tous les arguments à <code>/usr/bin/pigz</code>.",
|
||||
"Enregistre un détournement dpkg du binaire système <code>gzip</code> (<code>/usr/bin/gzip</code> sur Proxmox VE 9, <code>/bin/gzip</code> sur Proxmox VE 8). Le binaire original est conservé à côté sous <code>gzip.distrib</code> et le wrapper prend sa place. Désormais, <em>tout</em> ce qui appelle <code>gzip</code> — logrotate, <code>tar czf</code>, scripts, vzdump — utilise pigz de façon transparente.",
|
||||
"Vérifie que le fichier conservé sous <code>gzip.distrib</code> est un gzip fonctionnel avant de placer le wrapper ; sinon, réinstalle d’abord le paquet <code>gzip</code>. Un hôte utilisant encore l’ancien remplacement <code>/bin/gzip.original</code> passe au détournement lors de la prochaine application."
|
||||
],
|
||||
"replacesTitle": "Cela remplace un binaire système",
|
||||
"replacesBody": "Placer un wrapper à la place de <code>gzip</code> est inhabituel. C’est sûr, car il produit une sortie compatible gzip, mais les scripts à chemins codés en dur, exécutés dans des chroots restrictifs ou vérifiant les empreintes des binaires peuvent se comporter différemment. Le binaire original reste sous <code>gzip.distrib</code>. Grâce au détournement dpkg, une mise à jour du paquet <code>gzip</code> ou le passage de Proxmox VE 8 à 9 met à jour ce fichier et laisse le wrapper en place.",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "Cette optimisation est suivie. <link>Désinstaller les optimisations</link> remet le binaire original de <code>gzip.distrib</code> à la place du wrapper, supprime le détournement et <code>pigzwrapper</code>, commente la ligne <code>pigz</code> dans <code>/etc/vzdump.conf</code>, puis exécute <code>apt purge pigz</code> après vérification du fonctionnement de gzip. Équivalent manuel sur Proxmox VE 9 :",
|
||||
"verifyTitle": "Vérification",
|
||||
"verifyBody": "Après application, <code>gzip --version</code> doit mentionner pigz. Un test rapide montre aussi la différence de vitesse sur un hôte multicœur :",
|
||||
"whenTitle": "Quand cela importe le plus",
|
||||
"whenBody": "Le gain dépend du <strong>nombre de cœurs de l’hôte</strong> et de la <strong>fréquence des sauvegardes</strong>. Sur un serveur de laboratoire domestique à 2 cœurs avec un vzdump quotidien, le gain est faible. Sur un hôte de production à 16 cœurs sauvegardant une douzaine de VM chaque nuit, pigz peut réduire la fenêtre de sauvegarde à une fraction du temps de gzip à un seul thread."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Commandes de sauvegarde et de restauration",
|
||||
"href": "/docs/help-info/backup-commands",
|
||||
"tailRich": " — référence CLI de vzdump, dont l’option de nombre de threads <code>--pigz</code>."
|
||||
},
|
||||
{
|
||||
"label": "Stockage",
|
||||
"href": "/docs/post-install/storage",
|
||||
"tail": "— limites de vitesse vzdump et réglage ARC ZFS."
|
||||
},
|
||||
{
|
||||
"label": "Système",
|
||||
"href": "/docs/post-install/system",
|
||||
"tail": "— descripteur de fichiers et réglage de mémoire."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,57 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Sécurité | Documentation ProxMenux",
|
||||
"description": "Options de sécurité disponibles dans le script de post-installation personnalisable ProxMenux. Actuellement une seule option : désactiver le service portmapper/rpcbind pour réduire la surface d'attaque de l'hôte."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Installation: Sécurité",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "La sécurité post-installation se limite au <strong>renforcement de l’hôte applicable sans surveillance en toute sécurité</strong> : désactiver des services rarement nécessaires et pouvoir l’annuler dans Désinstaller. Les outils actifs (Fail2Ban pour prévenir les intrusions, Lynis pour les audits) se trouvent dans <em>Sécurité</em> du menu principal de ProxMenux, hors de la post-installation."
|
||||
},
|
||||
"rpcbind": {
|
||||
"heading": "Désactiver le portmapper / rpcbind",
|
||||
"intro": "<code>rpcbind</code> (anciennement <code>portmap</code>) associe les numéros de programmes RPC aux ports réseau. NFS et certains anciens outils RPC en dépendent. Sur un hôte Proxmox typique qui ne sert pas de serveur NFS, <strong>rien ne l’utilise</strong> ; le laisser actif maintient le port <code>111/tcp</code> en écoute sur toutes les interfaces.",
|
||||
"whyTitle": "Pourquoi ça vaut la peine d'être désactivé",
|
||||
"whyItems": [
|
||||
"Réduit la surface d'attaque de l'hôte — un service d'écoute de moins pour s'inquiéter.",
|
||||
"Historiquement utilisé comme vecteur de réflexion/amplification dans les attaques DDoS. Désactiver <code>rpcbind</code> supprime ce facteur d'amplification pour votre hôte.",
|
||||
"Supprime le bruit qu’il génère dans les journaux et les sorties de <code>netstat</code> / <code>ss</code>, pour repérer plus facilement l’activité réelle."
|
||||
],
|
||||
"nfsTitle": "Ne pas désactiver cela si vous utilisez NFS",
|
||||
"nfsBody": "Le serveur NFS <strong>et</strong> le client NFS utilisent <code>rpcbind</code> pour négocier les ports de <code>mountd</code>, <code>statd</code>, <code>lockd</code>, etc. N’appliquez pas cette option si l’hôte Proxmox <em>exporte</em> des partages NFS vers d’autres machines ou <em>monte</em> des partages NFS d’un NAS. Les montages échoueront avec <code>mount.nfs: rpc.statd is not running</code> ou une erreur similaire.",
|
||||
"runsTitle": "Ce que ProxMenux exécute",
|
||||
"runsOutro": "Le paquet reste installé. ProxMenux enregistre les états d’activation et d’exécution d’origine de rpcbind.service et rpcbind.socket, puis désactive et arrête les deux unités pour empêcher la réactivation du service par le socket.",
|
||||
"verifyTitle": "Vérification",
|
||||
"verifyBody": "Après application, vérifiez que <code>rpcbind</code> est arrêté et que rien n’écoute sur le port 111 :",
|
||||
"reversibleTitle": "Restaurer l'état de service original",
|
||||
"reversibleBody": "Cette modification est enregistrée dans <code>installed_tools.json</code>. <link>Désinstaller les optimisations</link> restaure chaque unité rpcbind à ses états d’activation et d’exécution relevés avant la modification par ProxMenux. L’outil ne suppose pas que rpcbind était activé sur tous les hôtes."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Menu de sécurité",
|
||||
"href": "/docs/security",
|
||||
"tail": " — des outils plus poussés : Fail2Ban (prévention des intrusions) et Lynis (audit)."
|
||||
},
|
||||
{
|
||||
"label": "Lynis",
|
||||
"href": "/docs/security/lynis",
|
||||
"tail": " — pour auditer l’hôte et trouver d’autres possibilités de renforcer la sécurité."
|
||||
},
|
||||
{
|
||||
"label": "Commandes système utiles",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": "— état de service, journalctl, référence d'audit lynis."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,167 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Installation: Stockage - Documentation ProxMenux",
|
||||
"description": "Optimisations de stockage du script de post-installation personnalisable ProxMenux : taille ZFS ARC selon la RAM de l’hôte, instantanés périodiques avec zfs-auto-snapshot et suppression des limites de vitesse des sauvegardes vzdump."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Installation: Stockage",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Quatre optimisations de stockage : régler <strong>ZFS ARC</strong> sur une part raisonnable de la RAM, installer et programmer <strong>les instantanés ZFS automatiques</strong>, activer <strong>ZFS autotrim</strong> sur les pools SSD/NVMe et retirer les limitations de <strong>vzdump</strong> pour accélérer les sauvegardes. Choisissez chaque option indépendante selon votre configuration. Une cinquième option, <link>Log2RAM</link>, réduit l’usure SSD/NVMe en déplaçant <code>/var/log</code> en RAM. Elle figure dans Options car le menu personnalisable la classe ainsi."
|
||||
},
|
||||
"trackedTitle": "Les quatre sont suivis dans le menu Désinstaller",
|
||||
"trackedBody": "Chaque option s’enregistre dans <code>installed_tools.json</code> pour <link>Désinstaller les optimisations</link>. <code>zfs_arc</code> supprime <code>/etc/modprobe.d/99-zfsarc.conf</code> et reconstruit initramfs ; <code>zfs_auto_snapshot</code> annule le calendrier cron et propose de purger le paquet ; <code>zfs_autotrim</code> définit <code>autotrim=off</code> sur les pools activés ; <code>vzdump_speed</code> restaure <code>/etc/vzdump.conf</code> depuis le <code>.bak</code> créé à l’installation.",
|
||||
"arc": {
|
||||
"heading": "Optimiser la taille de ZFS ARC",
|
||||
"intro": "Le <strong>Adaptive Replacement Cache (ARC)</strong> est le cache de lecture ZFS en mémoire. Les installations Proxmox VE depuis 8.1 fixent 10% de RAM, au maximum 16 GiB ; les hôtes anciens ou mis à niveau peuvent différer. Cette option écrit explicitement cette même règle (RAM/10, au maximum 16 GiB, au minimum 64 MiB) dans son propre fichier, ce qui couvre aussi les hôtes anciens ou mis à niveau. Vérifiez les réglages et la charge : un cache plus petit n’est pas toujours plus rapide.",
|
||||
"sizingTitle": "Règles de calibrage",
|
||||
"headerRam": "RAM de l'hôte",
|
||||
"headerMax": "Plafond ARC",
|
||||
"rows": [
|
||||
{
|
||||
"ram": "Formule",
|
||||
"max": "RAM / 10, plafonné à 16 GiB, avec un plancher 64 MiB"
|
||||
},
|
||||
{
|
||||
"ram": "Hôte 8 GB",
|
||||
"max": "≈ 819 MiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "Hôte 16 GB",
|
||||
"max": "≈ 1.6 GiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "Hôte 64 GB",
|
||||
"max": "≈ 6.4 GiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "≥ 160 GB hôte",
|
||||
"max": "16 GiB (plafond)"
|
||||
}
|
||||
],
|
||||
"after": "Le fichier <code>/etc/modprobe.d/99-zfsarc.conf</code> contient uniquement <code>options zfs zfs_arc_max=…</code>. Les autres paramètres ZFS (<code>zfs_arc_min</code>, prélecture/limitation des écritures L2ARC, délai TXG) ne sont pas ajustés. Au préalable, une vérification recherche les autres <code>*.conf</code> de <code>/etc/modprobe.d/</code> définissant <code>zfs_arc_min</code> / <code>zfs_arc_max</code>, les sauvegarde avec manifeste dans <code>/usr/local/share/proxmenux/backups/zfs_arc/</code> et en retire les valeurs <code>zfs_arc_min</code> / <code>zfs_arc_max</code> conflictuelles (les autres options de ces lignes sont conservées), pour que seul le fichier ARC ProxMenux fixe la limite. Puis <code>update-initramfs -u -k all</code> et, si nécessaire, <code>proxmox-boot-tool refresh</code> intègrent la limite à l’initramfs des systèmes avec racine ZFS.",
|
||||
"rebootTitle": "Nécessite un redémarrage pour prendre effet",
|
||||
"rebootBody": "Les réglages ARC sont lus au chargement du module <code>zfs</code>. Pour les hôtes avec racine ZFS, ProxMenux régénère initramfs avec <code>update-initramfs -u -k all</code> et actualise si nécessaire le chargeur avec <code>proxmox-boot-tool refresh</code>. Le nouveau paramètre exige toujours un redémarrage, signalé automatiquement.",
|
||||
"safeTitle": "Sans effet indésirable sur les hôtes sans ZFS",
|
||||
"safeBody": "La fonction n’écrit la configuration que si <code>zpool list</code> signale au moins un pool ZFS importé. Sur un hôte Proxmox ext4/LVM uniquement, ou avec outils ZFS mais sans pool importé, cocher cette option ne fait rien : aucun fichier n’est écrit.",
|
||||
"verifyTitle": "Vérification et retour arrière manuel"
|
||||
},
|
||||
"autoSnap": {
|
||||
"heading": "Installer l'instantané automatique ZFS",
|
||||
"intro": "Installe le paquet <a>zfs-auto-snapshot</a> et réécrit ses horaires cron afin que les instantanés soient pris automatiquement à plusieurs intervalles. Un grand filet de sécurité sans effort en plus de vos sauvegardes Vzdump régulières.",
|
||||
"cadenceTitle": "Fréquence des instantanés configurée par ProxMenux",
|
||||
"headerLabel": "Étiquette",
|
||||
"headerRuns": "Exécution",
|
||||
"headerKept": "Captures instantanées conservées",
|
||||
"rows": [
|
||||
{
|
||||
"label": "fréquent",
|
||||
"runs": "chaque 15 min",
|
||||
"kept": "4"
|
||||
},
|
||||
{
|
||||
"label": "horaire",
|
||||
"runs": "toutes les heures",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "quotidiennement",
|
||||
"runs": "une fois par jour",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "hebdomadaire",
|
||||
"runs": "une fois par semaine",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "mensuel",
|
||||
"runs": "une fois par mois",
|
||||
"kept": "1"
|
||||
}
|
||||
],
|
||||
"conservativeTitle": "Rétention limitée",
|
||||
"conservativeBody": "ProxMenux est livré avec une rétention prudente (juste 4 fréquent + 1 de chaque intervalle plus long) de sorte que le stockage des instantanés ZFS ne ballonne pas. Si vous souhaitez une conservation plus longue, modifiez les numéros dans <code>/etc/cron.d/zfs-auto-snapshot</code>, <code>/etc/cron.hourly/zfs-auto-snapshot</code>, etc. après le script.",
|
||||
"onlyZfsTitle": "Utile uniquement sur les pools ZFS",
|
||||
"onlyZfsBody": "Installer le paquet sur un hôte ext4 seulement est inoffensif mais inutile — il n'y a pas d'ensembles de données ZFS pour qu'il snapshot. Passez cette option si vous n'utilisez pas ZFS.",
|
||||
"verifyTitle": "Vérification et retour arrière manuel"
|
||||
},
|
||||
"autotrim": {
|
||||
"heading": "Activer ZFS autotrim (pools SSD/NVMe)",
|
||||
"intro": "Active <code>autotrim</code> sur les pools ZFS composés uniquement de SSD ou NVMe compatibles TRIM. Le script ignore par précaution les pools avec un disque rotatif. Les pools déjà en <code>autotrim=on</code> restent inchangés.",
|
||||
"trimTitle": "Ce que TRIM fait, et pourquoi il importe sur ZFS",
|
||||
"trimBody1": "Les SSD et NVMe utilisent des blocs d’effacement internes plus grands que les secteurs logiques du système de fichiers. Après suppression d’un fichier, le disque ne sait pas encore que les secteurs sont libres ; son nettoyage interne peut donc recopier des données obsolètes pour libérer d’autres blocs. <strong>TRIM</strong> lui signale les secteurs libres pour permettre leur effacement anticipé.",
|
||||
"trimBody2": "Sans TRIM, les performances de SSD se dégradent au fil du temps car le lecteur n'a plus de blocs pré-effacés et doit faire effacer-à-écrire, et l'amplification de l'écriture augmente — les deux raccourcissant la vie utile du lecteur. Avec TRIM activé, le lecteur peut garder un bassin sain de blocs vides prêts à écrire.",
|
||||
"trimBody3": "Avec <code>autotrim=on</code>, ZFS traite en arrière-plan l’espace récemment libéré en regroupant les plages. Un <code>zpool trim <pool></code> périodique est une alternative. Autotrim évite un calendrier séparé, mais son impact dépend des disques ; le TRIM manuel périodique peut mieux convenir à certains modèles modestes.",
|
||||
"practicalTitle": "Pourquoi est-ce pratique?",
|
||||
"practicalItems": [
|
||||
"<strong>Performances d’écriture durables.</strong> TRIM peut aider le disque à récupérer efficacement les blocs inutilisés. Le bénéfice et l’impact sur la latence dépendent du matériel et de la charge.",
|
||||
"<strong>Longévité du disque.</strong> Éviter des copies internes inutiles peut réduire l’amplification d’écriture et l’usure NAND, sans garantir une durée de vie supplémentaire précise.",
|
||||
"<strong>Pas de tâche cron à prévoir.</strong> Contrairement à un <code>zpool trim</code> périodique, autotrim est géré automatiquement par le pool."
|
||||
],
|
||||
"whenTitle": "Quand est-ce nécessaire ?",
|
||||
"whenIntro1": "<strong>Envisagez de l’activer</strong> sur les pools ZFS uniquement en SSD/NVMe compatibles TRIM. Vérifiez le comportement et la latence ; un TRIM manuel planifié peut mieux convenir.",
|
||||
"whenIntro2": "<strong>Le script le saute automatiquement</strong> sur:",
|
||||
"whenSkipItems": [
|
||||
"Pools avec un vdev sur disque dur rotatif : filtre matériel prudent de ce script.",
|
||||
"Disques sans <code>discard_granularity</code> exposé dans sysfs : anciens SSD sans TRIM ou accès direct ne permettant pas au système de voir le périphérique sous-jacent.",
|
||||
"Pools où ZFS lui-même signale la propriété non supportée (rare; très vieux pools).",
|
||||
"Pools déjà mis à <code>autotrim=on</code> (non-op)."
|
||||
],
|
||||
"whenIntro3": "<strong>Non pertinent sur les hôtes ext4 seulement</strong> — il n'y a rien pour ZFS à découper. La fonction sort avec un message amical dans ce cas.",
|
||||
"recordedTitle": "Pourquoi seuls les pools ProxMenux modifiés sont enregistrés",
|
||||
"recordedBody": "La fonction n'écrit un pool à son fichier d'état interne (<code>/usr/local/share/proxmenux/zfs_autotrim_pools</code>) que lorsqu'elle a activement retourné ce pool de <code>off</code> à <code>on</code>. Les pools que vous aviez sur autotrim avant d'exécuter le script sont laissés en dehors de la liste, de sorte qu'un futur désinstallation ne désactive pas les paramètres que vous avez configurés vous-même — seuls les changements de ProxMenux sont retournés.",
|
||||
"manualTitle": "Équivalent manuel (exécutez sur votre serveur)",
|
||||
"manualIntro": "La séquence complète du script s'exécute contre chaque pool est reproductible à la main. C'est ce que vous taperiez si vous vouliez faire la même chose sur un seul pool sans ProxMenux:",
|
||||
"verifyTitle": "Vérification et retour arrière manuel",
|
||||
"oneShotTitle": "Besoin d’un TRIM ponctuel plutôt que continu ?",
|
||||
"oneShotBody": "Certains administrateurs préfèrent un TRIM manuel aux heures creuses. Désactivez autotrim et programmez une tâche cron exécutant <code>zpool trim <pool></code> : même objectif, fréquence différente."
|
||||
},
|
||||
"vzdump": {
|
||||
"heading": "Augmenter la vitesse de sauvegarde de vzdump",
|
||||
"intro": "Écrit bwlimit: 0 et ionice: 5 dans la configuration globale vzdump. Proxmox n’a déjà pas de limite de bande passante par défaut : seul un plafond configuré est retiré. Par rapport à ionice: 7, la valeur 5 augmente la priorité E/S best-effort si l’ordonnanceur la respecte. Cela peut affecter les invités sans garantir des sauvegardes plus rapides.",
|
||||
"changedTitle": "Ce qui est changé dans /etc/vzdump.conf",
|
||||
"backupTitle": "La première exécution crée un .bak de vzdump.conf",
|
||||
"backupBody": "Au premier passage, ProxMenux copie <code>/etc/vzdump.conf</code> vers <code>/etc/vzdump.conf.bak</code> avant modification. Les exécutions suivantes conservent cette sauvegarde pour récupérer la configuration antérieure. <code>bwlimit</code> et <code>ionice</code> sont modifiés par <code>sed</code> ; les autres options comme compress, pigz, tmpdir et exclude-path sont conservées.",
|
||||
"skipTitle": "Quand sauter ça",
|
||||
"skipBody": "Sur un hôte à stockage local lent avec des VM sensibles à la latence, retirer la limite de bande passante peut causer des ralentissements pendant les sauvegardes. Si vous avez défini un <code>bwlimit</code> pour cela, conservez-le et ignorez cette option.",
|
||||
"verifyTitle": "Vérification et retour arrière manuel"
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Commandes de gestion ZFS",
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"tail": " — référence zpool / zfs pour ARC, instantanés et scrub."
|
||||
},
|
||||
{
|
||||
"label": "Commandes de stockage et de disques",
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"tail": " — référence des périphériques de blocs et du stockage Proxmox."
|
||||
},
|
||||
{
|
||||
"label": "Commandes de sauvegarde et restauration",
|
||||
"href": "/docs/help-info/backup-commands",
|
||||
"tail": " — référence CLI vzdump pour la bande passante et la priorité E/S."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — annuler les modifications ARC / vzdump."
|
||||
},
|
||||
{
|
||||
"label": "Log2RAM",
|
||||
"href": "/docs/post-install/optional#log2ram",
|
||||
"tail": "— réduit l'usure du SSD/NVMe par le support de ramdisque /var/log; documenté sous Facultatif."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,133 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Système | Documentation ProxMenux",
|
||||
"description": "Optimisations système du script de post-installation personnalisable ProxMenux : limites de taille journald et logrotate, limites du noyau et des descripteurs de fichiers relevées, réglage équilibré de la mémoire, redémarrages rapides par kexec et récupération après panique du noyau."
|
||||
},
|
||||
"header": {
|
||||
"title": "Après installation : système",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Six optimisations système indépendantes. Elles règlent <strong>journald</strong> et <strong>logrotate</strong> pour éviter de remplir le disque, relèvent <strong>les limites du noyau et des descripteurs de fichiers</strong> pour les applications ouvrant beaucoup de fichiers, <strong>équilibrent la mémoire</strong> d’un hôte de virtualisation, ajoutent <strong>kexec</strong> pour redémarrer sans passer par le BIOS et configurent <strong>la récupération automatique</strong> après panique du noyau. Les six sont enregistrées et réversibles depuis le menu de désinstallation."
|
||||
},
|
||||
"journald": {
|
||||
"heading": "Optimiser journald",
|
||||
"intro": "Réécrit <code>/etc/systemd/journald.conf</code> avec des valeurs raisonnables pour éviter que le journal systemd remplisse progressivement la partition racine, puis redémarre <code>systemd-journald</code> et purge les anciens journaux.",
|
||||
"keyTitle": "Valeurs clés",
|
||||
"keyItems": [
|
||||
"<code>Storage=persistent</code> — tenir des journaux sur le disque à travers les reboots.",
|
||||
"<code>SystemMaxUse=64M</code> / <code>RuntimeMaxUse=60M</code> — plafonds d’utilisation du disque et de la mémoire par le journal.",
|
||||
"<code>Compress=yes</code>, <code>Seal=no</code> — compresser les journaux, désactiver le scellement à sécurité persistante (économise du CPU).",
|
||||
"<code>MaxLevelStore=info</code> — conserver les niveaux info et supérieurs, nécessaires au lecteur de journaux ProxMenux Monitor et à la détection des échecs d’authentification SSH/Proxmox par Fail2Ban dans le journal.",
|
||||
"Limite de débit : <code>1000 events / 30 s</code> pour éviter un afflux excessif de journaux.",
|
||||
"<code>ForwardToSyslog=no</code>, <code>ForwardToWall=no</code> — ne dupliquez pas les messages au syslog ou ne les diffusez pas sur des consoles."
|
||||
],
|
||||
"tipTitle": "Pourquoi MaxLevelStore=info compte",
|
||||
"tipBody": "Un seuil plus strict comme <code>warning</code> fait afficher presque les mêmes entrées à ProxMenux Monitor sur toutes les périodes, car la plupart des activités sont de niveau info, et empêche Fail2Ban de voir les échecs de connexion. Réduisez plutôt le volume avec <code>SystemMaxUse</code> et <code>RateLimitBurst</code> sans restreindre les niveaux conservés."
|
||||
},
|
||||
"logrotate": {
|
||||
"heading": "Optimiser logrotate",
|
||||
"intro": "Réécrit <code>/etc/logrotate.conf</code> avec des réglages globaux quotidiens et de taille, 7 rotations conservées, compression et <code>copytruncate</code> pour que les services continuent d’écrire sans rouvrir les fichiers. Le critère de taille, placé après le critère quotidien, prévaut sauf règle propre au journal. Le <code>logrotate.conf</code> original est sauvegardé en <code>.bak</code> à la première application.",
|
||||
"tipTitle": "Compatible avec Log2RAM",
|
||||
"tipBody": "La directive <code>size 10M</code> prévaut sur le réglage quotidien précédent ; elle ne signifie <em>pas</em> le premier des deux critères. Logrotate vérifie le seuil à son exécution, et les règles propres aux journaux peuvent remplacer les valeurs globales. Pour <code>/var/log</code> en RAM avec Log2RAM, vérifiez les règles et la fréquence du minuteur afin de contrôler l’espace."
|
||||
},
|
||||
"limits": {
|
||||
"heading": "Augmenter diverses limites du système",
|
||||
"intro": "Relève des limites du noyau, de systemd et de PAM dont les valeurs par défaut peuvent être trop faibles pour un hôte exécutant de nombreuses VM, conteneurs et services réseau.",
|
||||
"headerFile": "Fichier",
|
||||
"headerSets": "Ce qu'il définit",
|
||||
"rows": [
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-maxwatches.conf",
|
||||
"sets": "<code>fs.inotify.max_user_watches / max_user_instances / max_queued_events = 1048576</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-maxkeys.conf",
|
||||
"sets": "<code>kernel.keys.maxkeys / root_maxkeys = 1000000</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-swap.conf",
|
||||
"sets": "<code>vm.swappiness = 10</code>, <code>vm.vfs_cache_pressure = 100</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-fs.conf",
|
||||
"sets": "<code>fs.nr_open / file-max = 2097152</code>, <code>fs.aio-max-nr = 1048576</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/security/limits.d/99-limits.conf",
|
||||
"sets": "<code>nofile</code> et <code>nproc</code> à 1 048 576 (illimités pour root)"
|
||||
},
|
||||
{
|
||||
"file": "/etc/systemd/system.conf + user.conf",
|
||||
"sets": "<code>DefaultLimitNOFILE=1048576</code> pour les services systemd"
|
||||
},
|
||||
{
|
||||
"file": "/etc/pam.d/common-session + runuser-l",
|
||||
"sets": "<code>session required pam_limits.so</code> donc ce qui précède s'applique aux shells de connexion"
|
||||
},
|
||||
{
|
||||
"file": "/root/.profile",
|
||||
"sets": "<code>ulimit -n 1048576</code> pour le shell root"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Pourquoi inotify est important",
|
||||
"tipBody": "Docker, Syncthing, les surveillances de fichiers Node.js et les analyses Plex peuvent épuiser <code>max_user_watches</code>. La valeur par défaut dépend du noyau et de la mémoire ; elle n’est pas toujours 8192. Un plafond de 1M autorise davantage de surveillances sans les préallouer. Les surveillances actives consomment de la mémoire du noyau : vérifiez l’usage si la RAM est limitée."
|
||||
},
|
||||
"memory": {
|
||||
"heading": "Optimiser les paramètres de la mémoire",
|
||||
"intro": "Écrit un profil de sysctl équilibré à <code>/etc/sysctl.d/99-memory.conf</code>. Conçu pour un hôte hyperviseur — préfère garder les ensembles de travail VM dans RAM et libère les pages de manière proactive afin que les éclats d'allocation ne s'arrêtent pas.",
|
||||
"warnTitle": "swappiness=10 sur les hôtes avec peu de mémoire",
|
||||
"warnBody": "Sur un hôte de 16 Go de RAM exécutant de nombreuses VM, réduire swappiness peut conduire le noyau à tuer des processus par manque de mémoire plutôt qu’à utiliser le swap. Si les événements OOM sont fréquents, remontez swappiness à 30–60 dans <code>/etc/sysctl.d/99-memory.conf</code> après le script."
|
||||
},
|
||||
"kexec": {
|
||||
"heading": "Activer les redémarrages rapides (kexec)",
|
||||
"intro": "Installe <code>kexec-tools</code> et le branche pour que vous puissiez redémarrer l'hôte directement dans un nouveau noyau <em> sans passer par BIOS/UEFI firmware</em>. Sur les grands serveurs où POST prend 45 – 90 secondes, cela transforme un redémarrage d'une pause café en quelques secondes d'arrêt.",
|
||||
"installsTitle": "Ce que ProxMenux installe",
|
||||
"installsItems": [
|
||||
"Paquet <code>kexec-tools</code> (debconf pré-réponse avec <code>kexec-tools/load_kexec boolean false</code> donc apt n'invite pas et le chargement automatique à l'arrêt reste désactivé).",
|
||||
"Unité systemd <code>/etc/systemd/system/kexec-pve.service</code> — charge le noyau Proxmox et initrd en mémoire au démarrage en réutilisant la ligne de commande actuelle du noyau.",
|
||||
"Un alias dans <code>/root/.bash_profile</code>: <code>reboot-quick</code> → <code>systemctl kexec</code>."
|
||||
],
|
||||
"usageIntro": "Utilisation après le prochain redémarrage (ou manuel <code>systemctl start kexec-pve</code>):",
|
||||
"warnTitle": "Quand ne pas utiliser kexec",
|
||||
"warnBody": "kexec saute l’initialisation du firmware. Si vous dépendez de BIOS/UEFI pour réinitialiser le matériel, par exemple un GPU en passthrough nécessitant un POST complet ou un firmware HBA problématique, ces redémarrages peuvent laisser les appareils partiellement initialisés. Utilisez un <code>reboot</code> normal après une mise à niveau du noyau ou pour appliquer des changements BIOS/UEFI. <code>reboot-quick</code> sert aux redémarrages courants."
|
||||
},
|
||||
"panic": {
|
||||
"heading": "Activer le redémarrage en cas de panique du noyau",
|
||||
"intro": "Fait <strong>redémarrer automatiquement</strong> le noyau au lieu de rester bloqué sur l’écran de panique. Essentiel pour les hôtes Proxmox distants ou sans console locale : un noyau bloqué arrête toutes les VM jusqu’à ce que vous puissiez couper puis rétablir l’alimentation.",
|
||||
"tipTitle": "Combinez ceci avec l'accès à la console à distance",
|
||||
"tipBody": "Le redémarrage automatique sert à récupérer le système, pas à le déboguer. Pour <em>analyser</em> une panique plutôt que simplement redémarrer, utilisez <link>l’option kexec</link> ci-dessus avec kdump du noyau, non configuré par ProxMenux, ou enregistrez une console série sur un autre hôte avant d’activer le redémarrage automatique."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Vérification",
|
||||
"intro": "Après l'application des optimisations système:",
|
||||
"tipTitle": "Restauration et limites",
|
||||
"tipBody": "Les six options figurent dans <code>installed_tools.json</code> et <link>Désinstaller les optimisations</link>. La restauration retire les fichiers de configuration, l’unité et l’alias kexec, réécrit journald.conf avec les valeurs par défaut de systemd et rétablit logrotate.conf depuis sa sauvegarde. Certaines limites actives nécessitent une nouvelle session ou un redémarrage."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Commandes système utiles",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": " — vérifier les modifications (free -h, journalctl, ulimit -a)."
|
||||
},
|
||||
{
|
||||
"label": "Performances",
|
||||
"href": "/docs/post-install/performance",
|
||||
"tail": "— réglage supplémentaire au niveau du système (pigz)."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": "— revenir à l'un de ces changements."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,271 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Désinstaller les optimisations | Documentation ProxMenux",
|
||||
"description": "Restaurer les modifications de configuration réversibles après l'installation appliquées par ProxMenux. Les outils enregistrés utilisent des désinstallateurs dédiés qui préservent l'état d'hôte préexistant lorsque c'est possible."
|
||||
},
|
||||
"header": {
|
||||
"title": "Désinstaller les optimisations",
|
||||
"description": "Restaurer les modifications réversibles apportées par les scripts de post-installation automatisés ou personnalisables. ProxMenux enregistre chaque optimisation supportée avec sa fonction de restauration dédiée; les mises à jour de paquets sont intentionnellement exclues.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Pourquoi cela existe",
|
||||
"body": "Chaque réglage réversible pris en charge est <strong>enregistré</strong> dans <code>/usr/local/share/proxmenux/installed_tools.json</code>. Ce registre liste les optimisations actives et appelle la fonction de restauration correspondante. Les actions sans retour arrière sûr, comme une mise à niveau complète des paquets, ne sont pas ajoutées."
|
||||
},
|
||||
"openMenu": {
|
||||
"heading": "Comment l'ouvrir",
|
||||
"body": "Depuis le menu principal, ouvrez <strong>Paramètres post-installation Proxmox → Désinstaller les optimisations</strong>. La liste propose les optimisations <em>actuellement appliquées</em> ; celles non appliquées n’apparaissent pas.",
|
||||
"imageAlt": "Liste de désinstallation montrant les optimisations actives sur l’hôte, avec cases de sélection pour les annuler"
|
||||
},
|
||||
"howWorks": {
|
||||
"heading": "Comment fonctionne le retour arrière",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Registre et détection automatique",
|
||||
"body1": "Au premier passage, ProxMenux recherche des marqueurs sur l’hôte : <code>/etc/sysctl.d/99-memory.conf</code>, <code>/etc/apt/apt.conf.d/99-force-ipv4</code>, paquet <code>haveged</code> installé, service Log2RAM actif, etc. Les éléments reconnus sont enregistrés comme réversibles, même s’ils viennent d’une version antérieure au registre.",
|
||||
"body2": "Cette migration ne dure qu'une seule fois. Ensuite, chaque application/réversion met à jour le registre directement."
|
||||
},
|
||||
{
|
||||
"title": "Choisir les changements à annuler",
|
||||
"body1": "La liste de vérification présente une étiquette lisible par l'homme par article (p. ex. <em>Optimisation des paramètres de mémoire</em>, <em>IOMMU/VFIO PCI Passthrough</em>, <em>Log2RAM (SSD Protection)</em>). Cochez ceux que vous voulez inverser. Rien de ce que vous ne cochez ne sera touché."
|
||||
},
|
||||
{
|
||||
"title": "Exécution de la restauration",
|
||||
"body1": "Pour chaque élément sélectionné, ProxMenux appelle sa fonction de désinstallation correspondante. La plupart des renversements suivent l'un des trois modèles suivants :",
|
||||
"items": [
|
||||
"<strong>Basé sur la sauvegarde</strong> — restaurer un <code>.bak</code> capturé au moment de l'application (bashrc, logrotate.conf, journald.conf, GRUB/kernel cmdline).",
|
||||
"<strong>Suppression de configuration</strong> — retire les fichiers ProxMenux <code>/etc/sysctl.d/99-*.conf</code>, <code>/etc/apt/apt.conf.d/99-*</code> ou l’unité systemd, puis recharge.",
|
||||
"<strong>Réinstallation de paquets</strong> — pour les modifications d’interface comme l’avertissement d’abonnement, réinstalle les paquets originaux avec <code>--force-confnew</code> pour rétablir les réglages fournis."
|
||||
],
|
||||
"body2": "Chaque renversement enregistre ses progrès. Les éléments qui nécessitent un redémarrage (VFIO, noms d'interface persistants) définissent un drapeau qui déclenche l'invite de redémarrage à la fin."
|
||||
},
|
||||
{
|
||||
"title": "Demande de redémarrage à la fin",
|
||||
"body1": "Une fois l'inversion terminée, le menu affiche une invite de redémarrage. Les éléments qui ont modifié les paramètres du noyau, les modules du noyau ou le nom de réseau (VFIO, noms d'interface persistants) ont besoin du redémarrage pour prendre effet; d'autres éléments ne le font pas, et l'invite est une sécurité par défaut plutôt qu'une vérification par item."
|
||||
}
|
||||
]
|
||||
},
|
||||
"reversible": {
|
||||
"heading": "Ce qui est réversible",
|
||||
"intro": "Les optimisations réversibles enregistrées et leurs désinstallateurs correspondants sont regroupés ici par domaine:",
|
||||
"groups": [
|
||||
{
|
||||
"title": "Dépôts & APT",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Suppression de la bannière d'abonnement",
|
||||
"restores": "D'abord essayer de restaurer les fichiers d'interface utilisateur à partir des sauvegardes de ProxMenux (/usr/local/share/proxmenux/backups/proxmoxlib.js.backup.* et, lorsque l'interface utilisateur mobile est patchée, index.html.tpl.backup.*). Seulement si une sauvegarde est manquante ou corrompue, revient à réinstaller pve-manager, proxmox-widget-toolkit, libjs-extjs et libpve-http-server-perl avec force-confnew. Efface également les copies en cache .js / .gz."
|
||||
},
|
||||
{
|
||||
"tool": "Ignorer les langues APT",
|
||||
"restores": "Supprime /etc/apt/apt.conf.d/99-disable-translations pour permettre les index de descriptions de paquets traduites selon les autres réglages linguistiques APT."
|
||||
},
|
||||
{
|
||||
"tool": "Forcer IPv4 pour APT",
|
||||
"restores": "Supprime /etc/apt/apt.conf.d/99-force-ipv4."
|
||||
},
|
||||
{
|
||||
"tool": "Utilitaires système",
|
||||
"restores": "Purge seulement les paquets utilitaires sélectionnés que ProxMenux enregistré comme nouvellement installé. Les paquets déjà présents avant l'action ne sont jamais ajoutés à cette liste et restent intacts."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Limites du noyau, de la mémoire et du système",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Paramètres de la mémoire",
|
||||
"restores": "Supprime /etc/sysctl.d/99-memory.conf et recharge sysctl."
|
||||
},
|
||||
{
|
||||
"tool": "Configuration de la panique du noyau",
|
||||
"restores": "Supprime /etc/sysctl.d/99-kernelpanic.conf."
|
||||
},
|
||||
{
|
||||
"tool": "Augmentation des limites du système",
|
||||
"restores": "Supprime /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf et /etc/security/limits.d/99-limits.conf. Rétablit les limites PAM et DefaultLimitNOFILE systemd. Dans /root/.profile, seul l’ancien ulimit -n 256000 est retiré ; ulimit -n 1048576 de l’installateur actuel peut rester et nécessiter une suppression manuelle."
|
||||
},
|
||||
{
|
||||
"tool": "Profil d'échange ZRAM",
|
||||
"restores": "Désactive le swap /dev/zram0, arrête dev-zram0.swap et supprime /etc/systemd/zram-generator.conf.d/90-proxmenux.conf. Le paquet systemd-zram-generator n’est purgé que si ProxMenux l’a installé et qu’aucune autre configuration ZRAM n’existe. Si les pages ne peuvent pas être évacuées, le profil reste actif et rien n’est supprimé."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Réseautage",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Optimisations du réseau",
|
||||
"restores": "Supprime /etc/sysctl.d/99-network.conf, 97-proxmenux-fwbr.conf et 98-proxmenux-rpf.conf, l’unité proxmenux-fwbr-tune.service, le script /usr/local/sbin/proxmenux-fwbr-tune et la règle udev /etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules. Retire aussi la ligne source /etc/network/interfaces.d/* de /etc/network/interfaces. Recharge sysctl, systemd et les règles udev."
|
||||
},
|
||||
{
|
||||
"tool": "Open vSwitch",
|
||||
"restores": "Exécute apt purge pour openvswitch-switch et openvswitch-common. Migrez les ponts OVS vers Linux avant la désinstallation, sinon leurs VM perdront le réseau au prochain démarrage."
|
||||
},
|
||||
{
|
||||
"tool": "TCP BBR + TCP Fast Open",
|
||||
"restores": "Supprime /etc/sysctl.d/99-kernel-bbr.conf et 99-tcp-fastopen.conf, puis recharge le reste de sysctl. Supprimer les fichiers ne réinitialise pas les valeurs actives ; les valeurs par défaut comme cubic et tcp_fastopen=1 reviennent au redémarrage sauf autre configuration."
|
||||
},
|
||||
{
|
||||
"tool": "Noms d'interface persistants",
|
||||
"restores": "Supprime uniquement les fichiers 10-proxmenux-*.link contenant l'en-tête ProxMenux de /etc/systemd/network/. Tout fichier .link fourni par un autre paquet ou écrit par l'utilisateur est laissé en place. Les noms d'interface retournent au comportement par défaut de systemd lors du prochain redémarrage."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Journalisation",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Optimisation de journald",
|
||||
"restores": "Réécrit /etc/systemd/journald.conf par défaut et redémarre systemd-journald."
|
||||
},
|
||||
{
|
||||
"tool": "Optimisation du logrotate",
|
||||
"restores": "Restaurer /etc/logrotate.conf à partir du fichier .bak capturé avant le changement."
|
||||
},
|
||||
{
|
||||
"tool": "Log2RAM",
|
||||
"restores": "Arrête et désactive le service et le minuteur. Supprime tâches cron, unités systemd, binaires, configuration et /var/log.hdd. Désinstalle aussi le paquet apt si cette méthode a été utilisée."
|
||||
},
|
||||
{
|
||||
"tool": "TRIM automatique ZFS",
|
||||
"restores": "Lit /usr/local/share/proxmenux/zfs_autotrim_pools, la liste des pools réellement modifiés, et lance zpool set autotrim=off sur chacun. Les pools activés manuellement avant ProxMenux restent intacts."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Shell & apparence",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Personnalisation de Bashrc",
|
||||
"restores": "Restaurer /root/.bashrc à partir de la sauvegarde .bak. Si aucune sauvegarde n'existe, supprime le bloc PMX_CORE_BASHRC par des marqueurs."
|
||||
},
|
||||
{
|
||||
"tool": "Bannière MOTD personnalisée",
|
||||
"restores": "Restaurer le contenu original exact /etc/motd conservé sous /usr/local/share/proxmenux, supprime le fichier lorsqu'il n'existait pas avant, ou supprime en toute sécurité le marqueur existant lors de la migration d'une ancienne installation."
|
||||
},
|
||||
{
|
||||
"tool": "Fastfetch",
|
||||
"restores": "Supprime le binaire, le répertoire de configuration, le hook update-motd et le bloc délimité BEGIN FASTFETCH / END FASTFETCH de /root/.bashrc, ~/.profile, /etc/profile et /etc/profile.d/fastfetch.sh. Purge le paquet apt s’il est installé."
|
||||
},
|
||||
{
|
||||
"tool": "Figurine",
|
||||
"restores": "Supprime le binaire, l’entrée profile.d et le bloc d’alias de bashrc/profile."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Matériel & virtualisation",
|
||||
"items": [
|
||||
{
|
||||
"tool": "IOMMU / VFIO",
|
||||
"restores": "Supprime les modules vfio de /etc/modules, les entrées de blocage nouveau / radeon / nvidia et les paramètres intel_iommu=on / amd_iommu=on / iommu=pt / pcie_acs_override de /etc/kernel/cmdline (ZFS) ou GRUB. Reconstruit initramfs."
|
||||
},
|
||||
{
|
||||
"tool": "Corrections AMD CPU (Ryzen/EPYC)",
|
||||
"restores": "Supprime idle=nomwait de la ligne de commande du noyau (ZFS) ou GRUB, et les options ignore_msrs / report_ignored_msrs de /etc/modprobe.d/kvm.conf."
|
||||
},
|
||||
{
|
||||
"tool": "Agent invité pour un hôte Proxmox virtualisé",
|
||||
"restores": "Lit /usr/local/share/proxmenux/guest_agent.pkg et purge le paquet hôte enregistré. L’installateur choisit qemu-guest-agent, open-vm-tools ou virtualbox-guest-utils selon l’hyperviseur. Sans enregistrement, la désinstallation essaie ces trois paquets. Cela agit sur l’hôte Proxmox imbriqué, pas sur les modèles invités."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Stockage",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Dimensionnement de l'ARC ZFS",
|
||||
"restores": "Supprime /etc/modprobe.d/99-zfsarc.conf, restaure les *.conf externes en conflit sauvegardés dans /usr/local/share/proxmenux/backups/zfs_arc/, reconstruit initramfs et lance proxmox-boot-tool refresh sur les hôtes systemd-boot."
|
||||
},
|
||||
{
|
||||
"tool": "Instantanés automatiques ZFS",
|
||||
"restores": "Supprime les tâches cron écrites par le script et propose apt purge zfs-auto-snapshot. Les instantanés existants sur les pools restent intacts ; supprimez-les séparément si nécessaire."
|
||||
},
|
||||
{
|
||||
"tool": "Limites de vitesse vzdump",
|
||||
"restores": "Restaure /etc/vzdump.conf depuis le .bak créé à l’installation pour rétablir bwlimit et ionice à leurs valeurs avant ProxMenux."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Services et suppléments",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Synchronisation du temps",
|
||||
"restores": "Rétablit le fuseau UTC, valeur par défaut sûre, via timedatectl."
|
||||
},
|
||||
{
|
||||
"tool": "Génération d’entropie (haveged)",
|
||||
"restores": "Arrête, désactive et purge le paquet haveged."
|
||||
},
|
||||
{
|
||||
"tool": "kexec (redémarrages rapides)",
|
||||
"restores": "Désactive kexec-pve.service, supprime l’unité et l’alias reboot-quick de /root/.bash_profile, puis purge kexec-tools."
|
||||
},
|
||||
{
|
||||
"tool": "RPC / rpcbind Désactiver",
|
||||
"restores": "Rétablit séparément rpcbind.service et rpcbind.socket dans leurs états activé/désactivé et actif/inactif enregistrés avant ProxMenux."
|
||||
},
|
||||
{
|
||||
"tool": "pigz (parallèle gzip)",
|
||||
"restores": "Rétablit le vrai gzip depuis gzip.distrib, supprime le détournement dpkg et /bin/pigzwrapper, commente la ligne pigz de /etc/vzdump.conf puis lance apt purge pigz après vérification de gzip."
|
||||
},
|
||||
{
|
||||
"tool": "Services à haute disponibilité",
|
||||
"restores": "Arrête et désactive pve-ha-lrm, pve-ha-crm et corosync. Les groupes HA existants et les définitions de ressources ne sont pas supprimés — les supprimer de l'interface utilisateur Web si vous n'en avez plus besoin."
|
||||
},
|
||||
{
|
||||
"tool": "Dépôt Ceph",
|
||||
"restores": "Purge les paquets Ceph installés par cette option, supprime le deb822 /etc/apt/sources.list.d/ceph.sources sur PVE 9 (ou la liste de Ceph sur PVE 8), et rafraîchit le cache APT."
|
||||
},
|
||||
{
|
||||
"tool": "OVH RTM (surveillance)",
|
||||
"restores": "Purge les paquets correspondant à ovh-rtm*, rtm et rtm-*, supprime /etc/rtm et retire l’entrée RTM du registre. Les restes Puppet dans /etc/puppet/ peuvent nécessiter une vérification et un nettoyage manuels ; le répertoire n’est pas supprimé. Hors OVH, l’installateur ne change normalement rien."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"edge": {
|
||||
"heading": "Cas particuliers et précautions",
|
||||
"packageTitle": "La réinstallation touche des paquets Proxmox en cours d’utilisation",
|
||||
"packageBody": "Si les sauvegardes ProxMenux ne peuvent pas annuler <strong>Suppression de l’avertissement d’abonnement</strong>, la solution de repli réinstalle <code>pve-manager</code>, <code>proxmox-widget-toolkit</code>, <code>libjs-extjs</code> et <code>libpve-http-server-perl</code> avec <code>--force-confnew</code>. Cela touche l’interface active : actualisez le navigateur et attendez la reconnexion. Évitez les migrations et clonages en cours.",
|
||||
"rebootTitle": "Les noms persistants et VFIO ont besoin d'un redémarrage",
|
||||
"rebootBody": "Suppression ProxMenux's <code>10-proxmenux-*.link</code> fichiers (<em>Noms d'interface persistants</em>) et retour <em>IOMMU/VFIO</em> n'affectent pas le système d'exécution — ils ne comptent qu'après un redémarrage. ProxMenux définit le drapeau de redémarrage automatiquement pour ceux-ci.",
|
||||
"perItemTitle": "Vous pouvez annuler une modification et garder les autres",
|
||||
"perItemBody": "Le désinstallateur fonctionne par élément. Si vous voulez seulement supprimer Log2RAM mais garder le réglage réseau et les changements de bashrc, cochez uniquement <em>Log2RAM</em>. Rien d'autre n'est touché et le registre est mis à jour en conséquence."
|
||||
},
|
||||
"inspect": {
|
||||
"heading": "Inspection manuelle du registre",
|
||||
"intro": "Si vous voulez voir ce qui est suivi sans ouvrir le menu:",
|
||||
"outro": "Chaque entrée <code>\"tool\": true</code> correspond à quelque chose de ProxMenux appliqué et peut inverser. L'élimination manuelle d'une entrée n'est pas recommandée — utilisez toujours le menu, qui exécute également la fonction d'inversion au lieu de simplement oublier le changement.",
|
||||
"reinstallTitle": "Réinstaller après désinstallation",
|
||||
"reinstallBody": "La réversion d'une optimisation ne vous empêche pas de la réappliquer plus tard. Ouvrez <link>le menu Post-Installer</link> à nouveau et exécutez soit Automatique ou Personnalisable — le registre suivra le nouvel état."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Système automatisé de post-installation",
|
||||
"href": "/docs/post-install/automated",
|
||||
"tail": "— réappliquer le niveau de référence par défaut."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— choisir un sous-ensemble différent."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller ProxMenux",
|
||||
"href": "/docs/settings/uninstall-proxmenux",
|
||||
"tail": "— fonctionnement différent: supprime ProxMenux lui-même, et non ses optimisations appliquées."
|
||||
},
|
||||
{
|
||||
"label": "Aperçu après l'installation",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,112 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Appliquer les mises à jour disponibles — Optimisations post-installation | Documentation ProxMenux",
|
||||
"description": "Comment ProxMenux détecte lorsqu'une optimisation post-installation (Log2Ram, Paramètres de mémoire, Limites du système, Logrotate, réglage réseau...) a été mise à jour en amont, et comment appliquer la nouvelle version — depuis le menu Post-Install ou depuis le tableau de bord de Monitor."
|
||||
},
|
||||
"header": {
|
||||
"title": "Appliquer les mises à jour disponibles",
|
||||
"description": "Si une optimisation post-installation (Log2Ram, paramètres de mémoire, limites système, Logrotate…) a une version sur disque plus récente que celle enregistrée sur l’hôte, ProxMenux la signale comme mise à jour disponible. Vous pouvez l’appliquer depuis le menu post-installation des scripts ou le tableau de bord Monitor. Les deux relancent la même fonction et actualisent le registre.",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que c'est",
|
||||
"body": "Les optimisations post-installation ProxMenux ont des versions, par exemple <code>Log2ram SSD Protection v1.2</code>. L’hôte enregistre les optimisations actives et leurs versions dans <code>/usr/local/share/proxmenux/installed_tools.json</code>. Lorsqu’une version ProxMenux fournit une optimisation plus récente, l’écart est détecté et seule celle-ci est proposée à la réapplication, sans relancer toute la post-installation."
|
||||
},
|
||||
"why": {
|
||||
"heading": "Pourquoi cela existe",
|
||||
"body": "Les optimisations après installation peuvent être améliorées : meilleur réglage sysctl, limite Logrotate plus stricte, nouvelle méthode de dimensionnement de Log2RAM ou correction d’un cas particulier signalé par un testeur. Sans mécanisme de mise à jour, il fallait relancer manuellement le script après installation, qui réapplique <em>toutes</em> les optimisations, ou renoncer à l’amélioration. Appliquer les mises à jour disponibles permet de relancer volontairement chaque optimisation dont la version a changé."
|
||||
},
|
||||
"detection": {
|
||||
"heading": "Comment les mises à jour sont détectées",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Scripts versionnés sur disque",
|
||||
"body": "Chaque fonction post-installation déclare sa version dans le script (<code>scripts/post_install/auto_post_install.sh</code> et <code>scripts/post_install/customizable_post_install.sh</code>). Un scanner extrait ces versions de la source sur le disque."
|
||||
},
|
||||
{
|
||||
"title": "Registre des versions sur l’hôte",
|
||||
"body": "Lorsque l'opérateur a appliqué chaque optimisation, l'appel <code>register_tool</code> correspondant a écrit la version active dans <code>/usr/local/share/proxmenux/installed_tools.json</code>. Ce fichier est la source de la vérité pour \"ce qui est actif sur cet hôte en ce moment\"."
|
||||
},
|
||||
{
|
||||
"title": "Monitor compare les deux versions",
|
||||
"body": "Au démarrage et toutes les 24 h, Monitor compare les versions sur disque aux versions enregistrées. Chaque écart crée une entrée dans <code>/usr/local/share/proxmenux/updates_available.json</code>. Ce fichier alimente l’entrée du menu post-installation et la carte du tableau de bord Monitor."
|
||||
},
|
||||
{
|
||||
"title": "Une notification par nouvelle version",
|
||||
"body": "Dès qu’une optimisation a une mise à jour en attente, Monitor envoie une notification groupée, par exemple <em>« 4 mises à jour d’optimisations ProxMenux disponibles »</em>, avec une ligne par outil au format <code>name (vX → vY)</code>, comme pour les paquets Proxmox. Elle ne se répète pas chaque jour pour le même ensemble : seule une nouvelle version ou un nouvel outil dans la liste la déclenche à nouveau."
|
||||
}
|
||||
]
|
||||
},
|
||||
"pathA": {
|
||||
"heading": "Chemin A — À partir du menu Post-Installation",
|
||||
"intro": "À partir du menu principal de ProxMenux, ouvrez <strong>Paramètres après l'installation Proxmox</strong>. Lorsqu'il y a des mises à jour en attente, une nouvelle entrée <strong>Appliquer les mises à jour disponibles (N)</strong> apparaît juste au-dessus de <em>Désinstaller les optimisations</em>. Le nombre reflète combien d'optimisations ont une version plus récente sur disque que ce que l'hôte a actuellement enregistré. Lorsque tout est à jour, l'entrée n'apparaît tout simplement pas, donc le menu reste propre.",
|
||||
"menuAlt": "Menu des scripts post-installation montrant Appliquer les mises à jour disponibles (N) au-dessus de Désinstaller les optimisations ; le compteur indique les optimisations dont une version plus récente est sur disque",
|
||||
"menuCaption": "<em>Appliquer les mises à jour disponibles (N)</em> apparaît seulement si une optimisation a une mise à jour en attente ; l’entrée est masquée quand l’hôte est à jour.",
|
||||
"checklistBody": "Sélectionner l'entrée ouvre une liste de contrôle avec chaque mise à jour en attente, chaque ligne formatée en <code>name (vX → vY)</code>. Toutes les lignes sont pré-cochées par défaut; décochez toutes les lignes que vous ne voulez pas appliquer ce tour.",
|
||||
"checklistAlt": "Sélecteur Appliquer les mises à jour disponibles avec une ligne par optimisation en attente, son nom et le changement de version (actuelle → disponible). Toutes les lignes sont cochées.",
|
||||
"checklistCaption": "Sélection individuelle des optimisations à mettre à jour. Le même moteur qu’Automatisé et Personnalisable réapplique chaque fonction en arrière-plan et actualise sa version enregistrée."
|
||||
},
|
||||
"pathB": {
|
||||
"heading": "Voie B — Depuis le tableau de bord Monitor",
|
||||
"intro": "Les mêmes mises à jour apparaissent dans Monitor sous <link>Paramètres → Optimisations ProxMenux</link>. La carte affiche un <strong>compteur des mises à jour</strong> en attente qui ouvre le sélecteur par optimisation. Chaque outil propose aussi sa propre action de mise à jour.",
|
||||
"imageAlt": "Carte Optimisations ProxMenux dans les paramètres Monitor avec un compteur ouvrant le sélecteur par optimisation et des actions de mise à jour par outil",
|
||||
"imageCaption": "La carte Optimisations de Monitor donne accès aux mises à jour via son compteur dès qu’une version plus récente est sur disque, sans accès au shell."
|
||||
},
|
||||
"applying": {
|
||||
"heading": "Ce qui se passe lors de l’application",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Réexécute la fonction post-installation",
|
||||
"body": "La fonction de l’optimisation sélectionnée est réexécutée sur l’hôte. Comme chaque fonction après installation est <strong>idempotente</strong>, la relancer ne duplique pas la configuration : elle remplace la version précédente par la nouvelle, notamment les fichiers sysctl, les fichiers complémentaires et les unités de service."
|
||||
},
|
||||
{
|
||||
"title": "Actualise le registre",
|
||||
"body": "L'appel <code>register_tool</code> à l'intérieur de la fonction écrit la nouvelle version dans <code>installed_tools.json</code>. Le scan suivant ne voit plus d'inadéquation et l'entrée mise à jour disparaît du menu et de la carte Monitor."
|
||||
},
|
||||
{
|
||||
"title": "Pas de redémarrage sauf si la fonction le dit",
|
||||
"body": "La plupart des mises à jour prennent effet immédiatement. Les mises à jour qui touchent les modules du noyau, les noms d'interface persistants ou VFIO affichent la même invitation de redémarrage qu'une nouvelle installation."
|
||||
},
|
||||
{
|
||||
"title": "Mise à jour du registre envoyée au moniteur",
|
||||
"body": "Après le lot, le menu envoie une requête POST à <code>http://127.0.0.1:8008/api/updates/post-install/scan</code> pour reconstruire <code>/usr/local/share/proxmenux/updates_available.json</code>. Une fois toutes les mises à jour appliquées, leur compteur et l’entrée conditionnelle du menu shell disparaissent sans attendre le prochain scan. La carte Optimisations reste disponible."
|
||||
}
|
||||
],
|
||||
"jqTitle": "jq est nécessaire",
|
||||
"jqBody": "La liste de contrôle Path A repose sur <code>jq</code> pour analyser les mises à jour en attente JSON. Si le <code>jq</code> manque, le flux s'éteint silencieusement — vous verrez l'entrée du menu avec un nombre mais rien ne se produirait après avoir sélectionné les lignes. Sur n'importe quelle installation Proxmox moderne <code>jq</code> est présente; si dans le doute exécuter <code>apt install -y jq</code>."
|
||||
},
|
||||
"differs": {
|
||||
"heading": "Comment il diffère des autres chemins",
|
||||
"headerPath": "Path",
|
||||
"headerScope": "Portée",
|
||||
"headerWhen": "Quand ça a du sens",
|
||||
"rows": [
|
||||
{
|
||||
"pathLabel": "Automatisé",
|
||||
"pathHref": "/docs/post-install/automated",
|
||||
"scope": "Ré-applique <em> chaque optimisation </em> dans le paquet.",
|
||||
"when": "Hôte neuf ou réapplication complète de la configuration de base d’un nœud entièrement géré."
|
||||
},
|
||||
{
|
||||
"pathLabel": "Personnalisable",
|
||||
"pathHref": "/docs/post-install/customizable",
|
||||
"scope": "Choisissez parmi le catalogue complet.",
|
||||
"when": "Choisir précisément les optimisations actives sur l’hôte."
|
||||
},
|
||||
{
|
||||
"pathLabel": "appliquer les mises à jour disponibles",
|
||||
"pathHref": null,
|
||||
"scope": "Uniquement les optimisations dont la version sur disque a augmenté.",
|
||||
"when": "Garder les optimisations installées à jour sans toucher au reste."
|
||||
},
|
||||
{
|
||||
"pathLabel": "Désinstaller les optimisations",
|
||||
"pathHref": "/docs/post-install/uninstall",
|
||||
"scope": "Inverser l'optimisation et supprimer son entrée de registre.",
|
||||
"when": "Annuler une modification précise."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifTitle": "Contrôle de la notification",
|
||||
"notifBody": "L’événement <em>Mises à jour d’optimisations ProxMenux disponibles</em> annonce les mises à jour en attente. Activé par défaut sur chaque canal, il peut être désactivé par canal dans <link>Paramètres → Notifications</link>. Il ne se déclenche qu’une fois par ensemble distinct de mises à jour, pas à chaque scan de 24 h."
|
||||
}
|
||||
@@ -0,0 +1,116 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-installation : Virtualisation | Documentation ProxMenux",
|
||||
"description": "Options de virtualisation dans le script post-installation personnalisable ProxMenux : installer automatiquement le bon agent invité si Proxmox fonctionne à l'intérieur d'un VM, et activer IOMMU / VFIO afin que vous puissiez passer les périphériques PCI (GPU, NIC, HBAs) à vos propres VM."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Installation : Virtualisation",
|
||||
"section": "Paramètres post-installation de Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette catégorie couvre",
|
||||
"body": "Deux options indépendantes. <strong>Installer l’agent invité adapté</strong> aide lorsque Proxmox fonctionne lui-même dans un autre hyperviseur. <strong>Activer la prise en charge de VFIO IOMMU</strong> intéresse la plupart des utilisateurs : active les fonctions du noyau pour attribuer directement un GPU, HBA ou une carte réseau à une VM avec des performances quasi natives."
|
||||
},
|
||||
"guestAgent": {
|
||||
"heading": "installer l'agent invité approprié",
|
||||
"intro": "Détecte l'environnement de virtualisation sur lequel s'exécute l'hôte Proxmox (en utilisant <code>systemd-detect-virt</code> et <code>dmidecode</code>) et installe le paquet d'outils invités correspondant afin que l'hyperviseur externe puisse communiquer avec Proxmox de manière propre (arrêt progressif, synchronisation d'horloge, reportage IP, etc.).",
|
||||
"headerDetected": "Hôte détecté",
|
||||
"headerPackage": "Paquet installé",
|
||||
"rows": [
|
||||
{
|
||||
"detected": "QEMU / KVM",
|
||||
"package": "qemu-guest-agent"
|
||||
},
|
||||
{
|
||||
"detected": "VMware (ESXi, Workstation)",
|
||||
"package": "open-vm-tools"
|
||||
},
|
||||
{
|
||||
"detected": "VirtualBox",
|
||||
"package": "virtualbox-guest-utils"
|
||||
},
|
||||
{
|
||||
"detected": "Matériel physique (aucun)",
|
||||
"package": "— non-op, rien installé"
|
||||
}
|
||||
],
|
||||
"skipTitle": "Ignorez cette option si Proxmox fonctionne sur du matériel physique",
|
||||
"skipBody": "Si Proxmox fonctionne directement sur le matériel, le cas habituel, cocher cette option ne change rien : le détecteur retourne <code>none</code> et le script quitte sans modification. L’option concerne seulement les installations où Proxmox fonctionne <em>en tant qu’invité</em> pour des tests ou des laboratoires."
|
||||
},
|
||||
"vfio": {
|
||||
"heading": "Activer la prise en charge de VFIO IOMMU",
|
||||
"intro": "Active IOMMU sur l’hôte et charge les modules permettant l’accès direct PCI (<code>vfio</code>, <code>vfio_iommu_type1</code>, <code>vfio_pci</code>). Vous pouvez alors attribuer un périphérique physique à une VM, qui y accède directement avec des performances proches du matériel natif.",
|
||||
"whoTitle": "Qui en a besoin ?",
|
||||
"whoItems": [
|
||||
"Vous voulez attribuer directement un GPU à une VM Windows de jeu ou à une VM macOS.",
|
||||
"Vous avez un 10G NIC dédié pour un pare-feu/routeur VM (OPNsense, pfSense).",
|
||||
"Vous souhaitez passer un HBA directement à un TrueNAS/Unraid VM pour ZFS sur disques nus.",
|
||||
"Vous prévoyez utiliser <em>Coral TPU</em>, une carte de capture, ou un dongle SDR dans un VM."
|
||||
],
|
||||
"whoOutro": "Si aucun de ces éléments ne s'applique, vous pouvez ignorer cette option en toute sécurité. Pour le relais vers un <strong>LXC</strong> (et non un VM), IOMMU n'est <em>pas</em> requis.",
|
||||
"doesTitle": "Ce que fait ProxMenux",
|
||||
"doesIntro": "La fonction tient compte du chargeur de démarrage : elle détecte ZFS (systemd-boot) ou LVM/ext4 (GRUB) et écrit dans le bon fichier. Elle est idempotente : les paramètres déjà présents ne sont pas ajoutés une seconde fois.",
|
||||
"headerBoot": "Type de démarrage",
|
||||
"headerFile": "Fichier touché",
|
||||
"headerPost": "Étape postérieure à la mise à jour",
|
||||
"bootRows": [
|
||||
{
|
||||
"boot": "systemd-boot (ZFS)",
|
||||
"file": "/etc/kernel/cmdline",
|
||||
"post": "proxmox-boot-tool refresh"
|
||||
},
|
||||
{
|
||||
"boot": "GRUB (LVM/ext4)",
|
||||
"file": "/etc/default/grub",
|
||||
"post": "update-grub"
|
||||
}
|
||||
],
|
||||
"kernelIntro": "Paramètres du noyau ajoutés:",
|
||||
"modulesIntro": "Modules de noyau ajoutés au <code>/etc/modules</code>:",
|
||||
"blacklistIntro": "Pilotes en conflit bloqués dans <code>/etc/modprobe.d/blacklist.conf</code> :",
|
||||
"blacklistTitle": "Bloquer les pilotes GPU empêche l’utilisation du GPU par l’hôte",
|
||||
"blacklistBody": "La liste de blocage empêche le noyau hôte de lier <em>tout</em> pilote GPU, pour que VFIO puisse prendre le contrôle du GPU. C’est souhaitable pour l’attribution directe à une VM, mais c’est l’<strong>opposé</strong> de ce qu’il faut pour <link>installer les pilotes NVIDIA sur l’hôte</link>, par exemple pour le transcodage LXC. Choisissez une voie par GPU :",
|
||||
"pathItems": [
|
||||
"<strong>GPU → VM:</strong> activez VFIO/IOMMU ici, laissez les pilotes GPU sur la liste noire.",
|
||||
"<strong>GPU → LXC (ou hôte) :</strong> ignorez cette option, utilisez l’installation NVIDIA sur l’hôte et ne bloquez pas nvidia/nouveau.",
|
||||
"<strong>Deux GPU :</strong> l’un peut aller à une VM, l’autre à un LXC, mais une configuration plus précise est nécessaire : lier une seule carte à <code>vfio-pci</code> par son identifiant PCI. La liste de blocage par défaut est trop large ; modifiez ensuite <code>blacklist.conf</code>."
|
||||
],
|
||||
"acsTitle": "À propos de pcie_acs_override — comprenez ce que vous activez",
|
||||
"acsBody": "<code>pcie_acs_override=downstream,multifunction</code> assouplit la vérification PCIe Access Control Services. Le noyau peut alors séparer des groupes IOMMU signalés comme indivisibles par le firmware, parfois seul moyen d’attribuer un périphérique sans tout le groupe. En contrepartie, <strong>l’isolation entre périphériques est réduite</strong> : une VM malveillante ou compromise avec accès direct dispose d’une plus grande surface d’attaque via DMA. Acceptable en laboratoire domestique, à bien évaluer pour des charges non fiables. Si inutile, retirez le paramètre de <code>/etc/kernel/cmdline</code> ou <code>/etc/default/grub</code> après le script et relancez la mise à jour du chargeur de démarrage.",
|
||||
"rebootTitle": "Redémarrage nécessaire",
|
||||
"rebootBody": "IOMMU, les modules VFIO et la liste de blocage prennent effet après régénération d’initramfs et redémarrage. Le script exécute <code>update-initramfs -u -k all</code>, actualise le chargeur de démarrage et indique qu’un redémarrage est nécessaire pour que Personnalisable le propose à la fin.",
|
||||
"verifyTitle": "Vérification après redémarrage",
|
||||
"revertTitle": "Réversible depuis le menu Désinstaller",
|
||||
"revertBody": "<link>Désinstaller les optimisations</link> annule toutes les modifications : retire les paramètres IOMMU de <code>/etc/kernel/cmdline</code> ou GRUB, les modules VFIO de <code>/etc/modules</code> et les entrées de blocage des pilotes, puis reconstruit initramfs. Un redémarrage applique le retour en arrière."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Ajouter GPU à VM (Passthrough)",
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"tail": "— l'étape suivante naturelle une fois IOMMU + VFIO activé."
|
||||
},
|
||||
{
|
||||
"label": "Ajouter le contrôleur ou NVMe au VM",
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"tail": "— la même infrastructure de transmission pour les contrôleurs de stockage."
|
||||
},
|
||||
{
|
||||
"label": "commandes GPU Passthrough",
|
||||
"href": "/docs/help-info/gpu-commands",
|
||||
"tail": "— Référence de vérification IOMMU."
|
||||
},
|
||||
{
|
||||
"label": "Désinstaller les optimisations",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — annuler proprement IOMMU / VFIO."
|
||||
},
|
||||
{
|
||||
"label": "Post-installation personnalisable",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": "— retour au menu parent."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Fail2Ban | Documentation ProxMenux",
|
||||
"description": "Installez Fail2Ban avec trois jails optimisés pour Proxmox (SSH agressif, Proxmox UI 8006, ProxMenux Monitor 8008). Inclut le correctif journald MaxLevelStore, des services de journalisation personnalisés pour plus de fiabilité, un backend nftables/iptables détecté automatiquement et le renforcement SSH MaxAuthTries.",
|
||||
"ogTitle": "Fail2Ban | Documentation ProxMenux",
|
||||
"ogDescription": "Protection contre la force brute pour SSH et les interfaces web Proxmox, avec des correctifs journald et backend propres à Proxmox."
|
||||
},
|
||||
"header": {
|
||||
"title": "Fail2Ban",
|
||||
"description": "Installe Fail2Ban pour Proxmox : trois jails (SSH agressif, interface Proxmox sur 8006, ProxMenux Monitor sur 8008 et proxy inverse), correction du niveau journald pour conserver les événements SSH, deux services copiant le journal vers des fichiers afin de contourner un problème connu du backend systemd, détection du backend de pare-feu et durcissement SSH avec MaxAuthTries.",
|
||||
"section": "Sécurité"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Installe Fail2Ban depuis les dépôts Debian et écrit une configuration Proxmox protégeant immédiatement SSH, l'interface web Proxmox et ProxMenux Monitor. Une installation existante est détectée et un menu de gestion propose de réinstaller ou de supprimer."
|
||||
},
|
||||
"firstLaunch": {
|
||||
"heading": "Boîte de dialogue Premier lancement",
|
||||
"body": "Sans Fail2Ban installé, le script résume dans un dialogue ce qu'il va installer et configurer. Annuler quitte sans modification ; confirmer lance l'installation.",
|
||||
"imageAlt": "Confirmation de Fail2Ban avec les trois jails, correction de journald et durcissement SSH"
|
||||
},
|
||||
"jails": {
|
||||
"heading": "Les trois jails",
|
||||
"headerJail": "Jail",
|
||||
"headerProtects": "Protège",
|
||||
"headerRetries": "Tentatives / Fenêtre",
|
||||
"headerBan": "Durée de blocage",
|
||||
"rows": [
|
||||
{
|
||||
"jail": "[sshd]",
|
||||
"protects": "SSH (mode agressif — couvre ddos, mode, normal)",
|
||||
"retries": "2 / 60 min",
|
||||
"ban": "9 heures"
|
||||
},
|
||||
{
|
||||
"jail": "[proxmox]",
|
||||
"protects": "UI web Proxmox (port 8006)",
|
||||
"retries": "3 / 10 min",
|
||||
"ban": "1 heure"
|
||||
},
|
||||
{
|
||||
"jail": "[proxmenux]",
|
||||
"protects": "ProxMenux Monitor (port 8008 + http/https proxy inverse)",
|
||||
"retries": "3 / 10 min",
|
||||
"ban": "1 heure"
|
||||
}
|
||||
],
|
||||
"outro": "Par défaut mondial à partir de <code>jail.local</code>: <code>ignoreip = 127.0.0.1/8 ::1</code>, <code>ignoreself = true</code>,<code> bantime = 86400</code> (24h pour les prisons qui ne le remplacent pas), <code>maxretry = 2</code>, <code>findtime = 1800</code>."
|
||||
},
|
||||
"journald": {
|
||||
"heading": "Pourquoi la correction de journald est importante",
|
||||
"intro": "Proxmox fournit <code>/etc/systemd/journald.conf</code> avec <codeNw>MaxLevelStore=warning</codeNw>. journald supprime les messages de niveau <em>inférieur</em> à warning avant de les stocker. SSH et PAM signalent les échecs d'authentification aux niveaux <em>info</em> / <em>notice</em>, donc :",
|
||||
"diagram": {
|
||||
"sshLabel": "SSH / PAM",
|
||||
"sshDetail": "échec d'authentification\n(niveau info / notice)",
|
||||
"journaldLabel": "journald",
|
||||
"journaldDetail": "MaxLevelStore=warning\n→ événement ignoré sans avertissement",
|
||||
"fail2banLabel": "Fail2Ban",
|
||||
"fail2banDetail": "ne voit rien\n→ n'interdit jamais rien",
|
||||
"arrowLabel": "Proxmox par défaut"
|
||||
},
|
||||
"afterDiagram": "L'installateur détecte cela et écrit un drop-in à <codeXs>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</codeXs> élevant à la fois <code>MaxLevelStore</code> et <code>MaxLevelSyslog</code> à <code>info</code>:",
|
||||
"code": "[Journal]\nMaxLevelStore=info\nMaxLevelSyslog=info",
|
||||
"outro": "Puis redémarre <code>systemd-journald</code>. Le drop-in est supprimé lors de la désinstallation, ce qui restaure le Proxmox original par défaut."
|
||||
},
|
||||
"loggers": {
|
||||
"heading": "Pourquoi deux services d'enregistreur personnalisé",
|
||||
"intro1": "Fail2Ban peut lire directement le journal systemd (<code>backend = systemd</code>), mais ce backend présente sur Proxmox des problèmes connus avec les processus de travail de <code>pvedaemon</code> : les événements d'authentification apparaissent dans le journal sans être toujours détectés. Le problème concerne aussi parfois <code>sshd</code>.",
|
||||
"intro2": "ProxMenux crée deux petits services systemd qui suivent les unités concernées avec <code>journalctl -f</code> et ajoutent chaque ligne à un fichier. Fail2Ban lit ces fichiers avec le fiable <code>backend = auto</code> (mode fichier) :",
|
||||
"headerService": "Services",
|
||||
"headerSource": "Unité source",
|
||||
"headerOutput": "Fichier de sortie",
|
||||
"rows": [
|
||||
{
|
||||
"service": "proxmox-auth-logger.service",
|
||||
"source": "pvedaemon.service",
|
||||
"output": "/var/log/proxmox-auth.log"
|
||||
},
|
||||
{
|
||||
"service": "ssh-auth-logger.service",
|
||||
"source": "ssh.service",
|
||||
"output": "/var/log/ssh-auth.log"
|
||||
}
|
||||
],
|
||||
"outro": "Les deux services sont déclarés <code>PartOf=fail2ban.service</code> donc ils redémarrent avec Fail2Ban et s'arrêtent avec elle. Mode 640 appartenant à <code>root:adm</code> dans les fichiers journaux. Le troisième journal utilisé par la prison <code>[proxmenux]</code> (<code>/var/log/proxmenux-auth.log</code>) est écrit directement par l'application ProxMenux Monitor Flask — aucun service d'enregistreur nécessaire pour celui-ci."
|
||||
},
|
||||
"backend": {
|
||||
"heading": "Détection du backend de pare-feu",
|
||||
"intro": "L'installateur sonde l'hôte : si <code>nft list ruleset</code> fonctionne, il choisit <code>nftables</code> comme mesure d'interdiction. Sinon, il revient à <code>iptables-multiport</code> / <code>iptables-allports</code>. Le choix est écrit dans <code>jail.local</code> :",
|
||||
"code": "# nftables host\nbanaction = nftables\nbanaction_allports = nftables[type=allports]\n\n# iptables host (fallback)\nbanaction = iptables-multiport\nbanaction_allports = iptables-allports"
|
||||
},
|
||||
"hardening": {
|
||||
"heading": "Durcissement SSH : MaxAuthTries",
|
||||
"intro": "Le contrôle Lynis <strong>SSH-7408</strong> recommande <code>MaxAuthTries 3</code> dans <code>sshd_config</code>. La jail SSH utilise <code>maxretry = 2</code> pour bloquer après des échecs répétés ; MaxAuthTries limite les tentatives dans une connexion. Ce réglage SSH ajoute une défense en profondeur, y compris lorsque Fail2Ban est arrêté pour maintenance.",
|
||||
"installerIntro": "L'installateur:",
|
||||
"items": [
|
||||
"Lit la valeur actuelle <code>MaxAuthTries</code> (ou par défaut 6 si elle est absente).",
|
||||
"Enregistre-le dans <code>/usr/local/share/proxmenux/sshd_maxauthtries_backup</code>.",
|
||||
"Modifie <code>sshd_config</code> sur place : remplace la ligne existante, décommente une ligne commentée ou ajoute une nouvelle ligne.",
|
||||
"Recharge <code>sshd</code> (recharger, pas redémarrer, pour garder les sessions existantes en vie)."
|
||||
],
|
||||
"outro": "Lors de la désinstallation, la valeur originale enregistrée est restaurée et <code>sshd</code> est rechargée."
|
||||
},
|
||||
"manage": {
|
||||
"heading": "Gérer une installation existante",
|
||||
"intro": "Si Fail2Ban est déjà installé lorsque vous ouvrez le menu, le script le détecte et affiche un menu de gestion au lieu de ré-exécuter l'installateur:",
|
||||
"headerAction": "Décision",
|
||||
"headerWhat": "Ce qu'il fait",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Réinstaller",
|
||||
"what": "Relance l'installation complète et réécrit toutes les jails avec les valeurs actuelles de ProxMenux. À utiliser lorsqu'une mise à jour modifie les recommandations."
|
||||
},
|
||||
{
|
||||
"action": "Supprimer",
|
||||
"what": "Arrête fail2ban et les deux services d'enregistrement, purge le package apt, supprime tous les fichiers jail/filtre, supprime le drop-in journald (restauration de la valeur par défaut de Proxmox) et restaure l'original SSH MaxAuthTries."
|
||||
}
|
||||
]
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Vérifiez que ça marche.",
|
||||
"intro": "Après l'installation, commandes utiles de l'hôte:",
|
||||
"code": "# Service status and version\nsystemctl status fail2ban\nfail2ban-client --version\n\n# All active jails\nfail2ban-client status\n\n# Detail on one jail\nfail2ban-client status sshd\nfail2ban-client status proxmox\nfail2ban-client status proxmenux\n\n# Currently banned IPs in a jail\nfail2ban-client status sshd | grep \"Banned IP\"\n\n# Manually unban an IP (use this if you ban yourself)\nfail2ban-client unban 192.0.2.10\n\n# Tail the auth logs Fail2Ban watches\ntail -f /var/log/ssh-auth.log\ntail -f /var/log/proxmox-auth.log\ntail -f /var/log/fail2ban.log"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"neverBansTitle": "Fail2Ban fonctionne mais n'interdit jamais rien",
|
||||
"neverBansBody": "Vérifiez que <code>tail -f /var/log/ssh-auth.log</code> reçoit une entrée après une tentative SSH avec un mauvais mot de passe depuis une autre machine. Sinon, examinez <code>systemctl status ssh-auth-logger.service</code>. Si le service est actif, consultez les événements récents avec <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> et vérifiez que le complément journald autorise le niveau <em>info</em>.",
|
||||
"monitorEmptyTitle": "La jail ProxMenux Monitor ne contient aucune entrée malgré des connexions échouées",
|
||||
"monitorEmptyBody": "Le <code>[proxmenux]</code> jail lit <code>/var/log/proxmenux-auth.log</code>, qui est écrit par l'application ProxMenux Monitor Flask — et non par un enregistreur journald. Si vous n'exécutez pas le moniteur, le fichier reste vide et le jail ne se déclenche jamais. C'est prévu ; la configuration jail est inoffensive. Si vous exécutez le moniteur et que le journal est vide, vérifiez la configuration de journalisation Flask.",
|
||||
"selfBanTitle": "Je me suis bloqué moi-même",
|
||||
"selfBanIntro": "À partir d'une console / IPMI / iKVM (ou d'une autre IP sur liste blanche):",
|
||||
"selfBanCode": "fail2ban-client unban '<'YOUR_IP'>'\n\n# To prevent it next time, edit /etc/fail2ban/jail.local and add your IP:\nignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 203.0.113.42\n\n# Then reload\nfail2ban-client reload",
|
||||
"aptFailTitle": "Échec d'apt-get : ''Unable to locate package fail2ban''",
|
||||
"aptFailBody": "Les dépôts Debian manquent sur l'hôte (fréquent sur les installations Proxmox minimales). L'installateur crée <code>/etc/apt/sources.list.d/debian.sources</code> avec le bon nom de code (<code>bookworm</code> / <code>trixie</code>), puis réessaie. Si cela échoue encore, vérifiez <code>VERSION_CODENAME</code> dans <code>/etc/os-release</code> et l'accessibilité du dépôt.",
|
||||
"lockoutTitle": "SSH me verrouille après l'installation",
|
||||
"lockoutBody": "L'installateur définit <code>MaxAuthTries=3</code>. Si votre gestionnaire de mot de passe / agent récupère plusieurs clés, vous pouvez dépasser cela sur une seule tentative de connexion. Limiter les clés offertes : <code>ssh -o IdentitiesOnly=yes -i ~/.ssh/specific_key user@host</code>. Ou augmenter temporairement <code>MaxAuthTries</code> en <code>sshd_config</code> pendant le débogage."
|
||||
},
|
||||
"files": {
|
||||
"heading": "Fichiers écrits",
|
||||
"code": "/etc/fail2ban/jail.local # global defaults + [sshd]\n/etc/fail2ban/jail.d/proxmox.conf # [proxmox]\n/etc/fail2ban/jail.d/proxmenux.conf # [proxmenux]\n/etc/fail2ban/filter.d/proxmox.conf # auth-failure regex for pvedaemon\n/etc/fail2ban/filter.d/proxmenux.conf # auth-failure regex for Monitor\n/etc/systemd/system/proxmox-auth-logger.service # journal → file (pvedaemon)\n/etc/systemd/system/ssh-auth-logger.service # journal → file (sshd)\n/etc/systemd/journald.conf.d/proxmenux-loglevel.conf # MaxLevelStore=info\n/etc/ssh/sshd_config # MaxAuthTries=3 (in-place edit)\n/var/log/proxmox-auth.log # written by logger service\n/var/log/ssh-auth.log # written by logger service\n/var/log/proxmenux-auth.log # written by Monitor Flask app\n/usr/local/share/proxmenux/sshd_maxauthtries_backup # for restore on uninstall"
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"monitorLabel": "ProxMenux Monitor → Onglet Sécurité",
|
||||
"monitorTail": " — installation depuis le tableau de bord, état des jails en direct, IP bloquées et réglage des tentatives et de la durée de blocage par jail dans le navigateur.",
|
||||
"lynisLabel": "Lynis",
|
||||
"lynisTail": " — lancer un audit avant et après pour vérifier que le contrôle SSH-7408 est satisfait.",
|
||||
"securityLabel": "Aperçu de la sécurité",
|
||||
"securityTail": "— retour à l'aperçu de la section."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,70 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Sécurité Proxmox — Fail2Ban et audit de durcissement Lynis | ProxMenux",
|
||||
"description": "Deux outils de sécurité installables pour Proxmox VE : Fail2Ban (prévention des intrusions pour SSH, l'interface web Proxmox et ProxMenux Monitor) et Lynis (audit de sécurité et de durcissement installé depuis le dépôt officiel GitHub).",
|
||||
"ogTitle": "Sécurité Proxmox — Fail2Ban et audit de durcissement Lynis",
|
||||
"ogDescription": "Fail2Ban et Lynis pour Proxmox VE : prévention des intrusions et audit de durcissement, installés et gérés par ProxMenux.",
|
||||
"twitterTitle": "Sécurité Proxmox | ProxMenux",
|
||||
"twitterDescription": "Fail2Ban et Lynis pour Proxmox VE : prévention des intrusions et audit de durcissement."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sécurité",
|
||||
"description": "Deux outils complémentaires pour Proxmox VE : défense active (Fail2Ban bloque les IP attaquant SSH ou les interfaces web) et audit local (Lynis cherche les lacunes de durcissement et donne un score de 0 à 100). Chaque outil possède son menu d'installation et de gestion, qui détecte une installation existante avant toute action.",
|
||||
"section": "Sécurité"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Défense active et audit local",
|
||||
"body": "Ils répondent à des questions différentes. <strong>Fail2Ban</strong> répond à <em>« Sommes-nous attaqués en ce moment ? »</em> en surveillant les journaux d'authentification et en bloquant les IP responsables. <strong>Lynis</strong> répond à <em>« Quel est le niveau de durcissement de cet hôte ? »</em> par un audit ponctuel avec des recommandations concrètes. Utilisez les deux : Lynis indique les améliorations, Fail2Ban réagit aux attaques en cours."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture du menu",
|
||||
"body": "Dans le menu principal ProxMenux, sélectionnez <strong>Sécurité</strong>. Voici ce qui apparaît :",
|
||||
"imageAlt": "Menu de sécurité avec options Fail2Ban et Lynis"
|
||||
},
|
||||
"pick": {
|
||||
"heading": "Choisissez votre outil",
|
||||
"body": "Les deux outils sont indépendants : installez-en un, les deux ou aucun. Chaque carte ci-dessous mène à la section détaillant cet outil."
|
||||
},
|
||||
"cards": {
|
||||
"fail2ban": {
|
||||
"title": "Fail2Ban",
|
||||
"body": "Prévention active des intrusions. Surveille les journaux d'authentification SSH et web et bloque les IP après des échecs répétés.",
|
||||
"bullets": [
|
||||
"Trois jails : SSH, interface Proxmox (8006), ProxMenux Monitor (8008)",
|
||||
"Corrige les paramètres journald de Proxmox qui bloquent les journaux d'authentification",
|
||||
"Auto-détecte nftables / iptables",
|
||||
"SSH durcissement: MaxAuthTries=3 (recommandation Lynis)"
|
||||
]
|
||||
},
|
||||
"lynis": {
|
||||
"title": "Lynis",
|
||||
"body": "Auditeur de sécurité local. Analyse l'hôte et affiche un score de durcissement et des conseils concrets pour corriger les problèmes.",
|
||||
"bullets": [
|
||||
"Installé depuis le dépôt officiel CISOfy sur GitHub (dernière version)",
|
||||
"Score de durcissement 0–100 et liste des avertissements et suggestions",
|
||||
"Audit et mise à jour depuis le menu",
|
||||
"Conçu en lecture seule : ne modifie jamais le système"
|
||||
]
|
||||
}
|
||||
},
|
||||
"workflowTip": {
|
||||
"title": "Flux de travail qui utilise les deux",
|
||||
"body": "Lancez d'abord Lynis pour connaître le score initial et les recommandations principales. Appliquez les corrections souhaitées. Installez ensuite Fail2Ban : il met automatiquement en place la protection SSH contre la force brute et ajuste <code>MaxAuthTries</code> dans <code>sshd_config</code> pour satisfaire le contrôle SSH-7408. Relancez Lynis pour vérifier l'amélioration."
|
||||
},
|
||||
"fail2banSection": {
|
||||
"heading": "Fail2Ban",
|
||||
"body": "ProxMenux installe Fail2Ban avec une configuration adaptée à Proxmox. En plus de la jail SSH standard, il protège l'interface web Proxmox et ProxMenux Monitor. Il contourne deux problèmes spécifiques : un paramètre journald supprimant les événements d'authentification et un problème du backend systemd empêchant la lecture fiable de certaines sources du journal. La page détaillée explique l'installation, les trois jails, la correction de journald, le durcissement SSH et le dépannage.",
|
||||
"optionTitle": "Fail2Ban — installer et gérer",
|
||||
"optionDescription": "Trois jails préconfigurées (sshd agressif, interface Proxmox sur 8006, ProxMenux Monitor sur 8008 et proxy inverse), détection de nftables/iptables, correction de journald et durcissement SSH avec MaxAuthTries."
|
||||
},
|
||||
"lynisSection": {
|
||||
"heading": "Lynis",
|
||||
"body": "ProxMenux clone Lynis depuis <code>github.com/CISOfy/lynis</code> dans <code>/opt/lynis</code> et le rend accessible par <code>/usr/local/bin/lynis</code>. Le paquet Debian est volontairement évité car il accuse plusieurs versions majeures de retard sur le projet original. La page détaillée explique installation, audit, mise à jour, désinstallation, lecture du rapport et traitement des résultats.",
|
||||
"optionTitle": "Lynis — installation, audit et gestion",
|
||||
"optionDescription": "Installe le dernier Lynis de la repo officielle CISOfy GitHub (pas l'ancien paquet Debian), exécute des audits système avec score de durcissement, et des mises à jour via git pull."
|
||||
},
|
||||
"componentStatus": {
|
||||
"heading": "État des composantes",
|
||||
"body": "Les deux installateurs enregistrent leur état en <code>/usr/local/share/proxmenux/components_status.json</code> dans la catégorie <code>security</code>. ProxMenux utilise ce fichier pour décider s'il faut afficher l'installation ou le menu de gestion lors d'exécutions ultérieures, et les mêmes données alimentent les tableaux de bord dans le ProxMenux Monitor lorsqu'elles sont présentes."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Lynis | Documentation ProxMenux",
|
||||
"description": "Installez la dernière version de Lynis depuis le dépôt officiel CISOfy sur GitHub, lancez un audit avec score de durcissement de 0 à 100 et mettez à jour par git pull. Auditeur en lecture seule, sans modification du système.",
|
||||
"ogTitle": "Lynis | Documentation ProxMenux",
|
||||
"ogDescription": "Installez et exécutez Lynis sur Proxmox VE. Installation depuis le dépôt GitHub officiel, audit et mise à jour."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lynis",
|
||||
"description": "Clone la dernière version de Lynis depuis le dépôt officiel CISOfy sur GitHub, la rend disponible par /usr/local/bin/lynis et propose audit, mise à jour, réinstallation et désinstallation dans le menu. L'auditeur est en lecture seule : il rapporte sans modifier le système.",
|
||||
"section": "Sécurité"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Installe Lynis, l'auditeur de sécurité libre de CISOfy, depuis son dépôt GitHub dans <code>/opt/lynis</code> et crée un script de lancement dans <code>/usr/local/bin/lynis</code> pour le rendre accessible dans <code>PATH</code>. Une installation existante ouvre un menu d'audit, mise à jour, réinstallation ou suppression."
|
||||
},
|
||||
"manageMenu": {
|
||||
"heading": "Menu de gestion (après installation)",
|
||||
"intro": "Une fois que Lynis est installé, chaque invocation subséquente ouvre le menu de gestion au lieu de relancer l'installateur. De là vous lancez un audit, mise à jour via git pull, réinstaller ou désinstaller:",
|
||||
"imageAlt": "Lynis menu de gestion avec audit, mise à jour, réinstaller et supprimer les options"
|
||||
},
|
||||
"whyUpstream": {
|
||||
"heading": "Pourquoi le dépôt officiel GitHub plutôt qu'apt",
|
||||
"intro": "Debian fournit Lynis via apt, mais le paquet accuse généralement plusieurs versions majeures de retard. Les nouveaux contrôles, correctifs pour de nouveaux vecteurs d'attaque et recommandations améliorées arrivent d'abord sur GitHub. Lynis est un script shell autonome, sans compilation ni dépendance d'installation au-delà de <code>git</code> ; cloner le dépôt est donc la méthode recommandée par CISOfy.",
|
||||
"headerSource": "Source",
|
||||
"headerPath": "Install path",
|
||||
"headerUpdate": "Méthode de mise à jour",
|
||||
"headerFresh": "Actualité de la version",
|
||||
"rows": [
|
||||
{
|
||||
"sourceRich": "<strong>ProxMenux (ce script)</strong>",
|
||||
"path": "/opt/lynis/",
|
||||
"update": "git pull (depuis le menu)",
|
||||
"fresh": "Dernière version du projet original"
|
||||
},
|
||||
{
|
||||
"sourceRich": "<strong>Debian apt</strong>",
|
||||
"path": "/usr/bin/lynis",
|
||||
"update": "apt upgrade",
|
||||
"fresh": "Souvent mois / années de retard"
|
||||
}
|
||||
]
|
||||
},
|
||||
"install": {
|
||||
"heading": "Comment fonctionne l'installation",
|
||||
"node1Label": "github.com/CISOfy/lynis",
|
||||
"node1Detail": "git clone\n(installer git d'abord si nécessaire)",
|
||||
"node2Label": "/opt/lynis/",
|
||||
"node2Detail": "dépôt complet\ny compris le script ./lynis",
|
||||
"node3Label": "/usr/local/bin/lynis",
|
||||
"node3Detail": "script de lancement :\ncd /opt/lynis && ./lynis $@",
|
||||
"outro": "Le lanceur est nécessaire : Lynis doit être exécuté depuis son propre répertoire pour charger les chemins relatifs des plugins et des profils. Le lanceur masque ce détail et permet à <code>lynis audit system</code> de fonctionner depuis n'importe quel répertoire."
|
||||
},
|
||||
"detection": {
|
||||
"heading": "Voies de détection",
|
||||
"intro": "Avant d'afficher le menu, le script vérifie trois emplacements pour déterminer si Lynis est déjà présent :",
|
||||
"items": [
|
||||
"<code>/usr/local/bin/lynis</code> — enveloppe installée par ProxMenux",
|
||||
"<code>/opt/lynis/lynis</code> — chemin direct (au cas où l'emballage serait enlevé)",
|
||||
"<code>/usr/bin/lynis</code> — version apt-installée, si l'utilisateur l'a installé de cette façon précédemment"
|
||||
],
|
||||
"outro": "Si un de ces chemins existe, le menu de gestion s'ouvre. Le script ne désinstalle <strong>pas</strong> un Lynis installé par apt, uniquement celui qu'il gère dans <code>/opt/lynis</code> et son lanceur."
|
||||
},
|
||||
"audit": {
|
||||
"heading": "Exécuter un audit",
|
||||
"intro": "Dans le menu de gestion, choisissez <strong>Lancer l'audit de sécurité maintenant</strong>. Cela revient à exécuter :",
|
||||
"code": "lynis audit system --no-colors",
|
||||
"outro": "L'audit prend de 30 secondes à quelques minutes selon la taille de l'hôte. La sortie apparaît directement dans le terminal, sans animation d'attente. Lynis classe les contrôles par catégorie et marque chaque test <ok>[ OK ]</ok>, <warn>[ WARNING ]</warn> ou <sugg>[ SUGGESTION ]</sugg>. Le résumé final affiche les chiffres principaux :",
|
||||
"summary": "================================================================================\n\n Lynis security scan details:\n\n Hardening index : 76 [############ ]\n Tests performed : 247\n Plugins enabled : 0\n\n Components:\n - Firewall [V]\n - Malware scanner [X]\n\n Lynis modules:\n - Compliance status [?]\n - Security audit [V]\n - Vulnerability scan [V]\n\n================================================================================"
|
||||
},
|
||||
"report": {
|
||||
"heading": "Lire le rapport",
|
||||
"intro": "Les deux sections importantes sont <strong>Avertissements</strong> (les choses que vous devriez fixer bientôt) et <strong>Suggestions</strong> (recommandations pour améliorer le durcissement). Chaque élément porte un ID de contrôle comme <code>SSH-7408</code> — utile lors de la recherche des documents Lynis pour la justification et la correction.",
|
||||
"headerMarker": "Marqueur",
|
||||
"headerMeaning": "Signification",
|
||||
"headerAction": "Décision",
|
||||
"rows": [
|
||||
{
|
||||
"markerRich": "<strong>OK</strong>",
|
||||
"meaning": "Essai réussi",
|
||||
"action": "Rien"
|
||||
},
|
||||
{
|
||||
"markerRich": "<strong>WARNING</strong>",
|
||||
"meaning": "Problème réel, correction recommandée",
|
||||
"action": "Lire la description du contrôle, planifier une correction"
|
||||
},
|
||||
{
|
||||
"markerRich": "<strong>SUGGESTION</strong>",
|
||||
"meaning": "Amélioration du durcissement disponible",
|
||||
"action": "Appliquer si elle correspond à votre modèle de menace"
|
||||
}
|
||||
],
|
||||
"outro": "Le rapport complet et les données lisibles par machine sont écrits à <code>/var/log/lynis.log</code> et <code>/var/log/lynis-report.dat</code> par Lynis lui-même."
|
||||
},
|
||||
"pairFail2ban": {
|
||||
"title": "À combiner avec Fail2Ban",
|
||||
"body": "SSH-7408 (MaxAuthTries) est l'un des avertissements les plus courants. L'installation de <link>Fail2Ban</link> à partir de ProxMenux l'élimine automatiquement parce que l'installateur définit <code>MaxAuthTries=3</code> dans le cadre de son processus de durcissement SSH. Lancez Lynis pour confirmer que l'avertissement a disparu."
|
||||
},
|
||||
"update": {
|
||||
"heading": "Mettre à jour Lynis",
|
||||
"body": "Dans le menu, <strong>Mettre Lynis à jour vers la dernière version</strong> exécute <code>git pull --quiet</code> dans <code>/opt/lynis</code>. Si le répertoire n'est pas une copie de travail Git, par exemple après une copie manuelle des fichiers, le script réinstalle entièrement."
|
||||
},
|
||||
"reinstall": {
|
||||
"heading": "Réinstaller / désinstaller",
|
||||
"headerAction": "Décision",
|
||||
"headerWhat": "Ce qu'il fait",
|
||||
"rows": [
|
||||
{
|
||||
"actionRich": "<strong>Réinstaller</strong>",
|
||||
"whatRich": "Supprime <code>/opt/lynis</code>, clone à nouveau depuis GitHub et recrée le lanceur. À utiliser si la copie locale est endommagée."
|
||||
},
|
||||
{
|
||||
"actionRich": "<strong>Supprimer</strong>",
|
||||
"whatRich": "Supprime <code>/opt/lynis</code> et <code>/usr/local/bin/lynis</code>. Conserve les journaux <code>/var/log/lynis*</code> comme historique des audits. Un Lynis installé par apt dans <code>/usr/bin/lynis</code> reste intact."
|
||||
}
|
||||
]
|
||||
},
|
||||
"cli": {
|
||||
"heading": "Options utiles CLI",
|
||||
"intro": "Une fois installé, Lynis peut être invoqué directement à partir d'un shell avec des options supplémentaires non exposées par le menu:",
|
||||
"code": "lynis show version # version + build date\nlynis show commands # list every available command\nlynis show details TEST-ID # explain a specific control\nlynis audit system --quick # skip slow tests (e.g. malware scan)\nlynis audit system --pentest # treat host as untrusted (more aggressive)\nlynis update info # check if a newer Lynis is available\n\n# Filter the report log for just the warnings\ngrep \"Warning\" /var/log/lynis.log\n\n# Same, for suggestions only\ngrep \"Suggestion\" /var/log/lynis.log"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"cloneTitle": "git clone échoue lors de l'installation",
|
||||
"cloneBody": "L'hôte a besoin d'un accès réseau et DNS pour atteindre <code>github.com</code>. Depuis une console : <code>curl -sI https://github.com</code> et <code>git ls-remote https://github.com/CISOfy/lynis.git</code> révèlent l'erreur réelle (DNS, TLS, proxy, repo URL). Si un proxy est requis, définissez <code>https_proxy</code> dans l'environnement avant de ré-exécuter le menu.",
|
||||
"notFoundTitle": "lynis: commande introuvable après installation",
|
||||
"notFoundIntro": "Le lanceur <code>/usr/local/bin/lynis</code> n'a pas été créé ou a été supprimé. La solution la plus rapide est de réinstaller depuis le menu. Correction manuelle :",
|
||||
"notFoundCode": "cat > /usr/local/bin/lynis <<'EOF'\n#!/bin/bash\ncd /opt/lynis && ./lynis \"$@\"\nEOF\nchmod +x /usr/local/bin/lynis",
|
||||
"sshTitle": "L'audit affiche \"Warning: Test SSH-7408 — MaxAuthTries set incorrectly\"",
|
||||
"sshIntro": "Le démon SSH permet trop de tentatives d'auth par connexion. Soit installer <link>Fail2Ban</link> à partir de ProxMenux (qui définit <code>MaxAuthTries=3</code> automatiquement) soit éditer <code>/etc/ssh/sshd_config</code> à la main:",
|
||||
"sshCode": "sed -i 's/^#?MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config\nsystemctl reload sshd",
|
||||
"scoreTitle": "Le score a baissé après une mise à niveau Proxmox",
|
||||
"scoreBody": "Exécutez <code>lynis update info</code> d'abord — une mise à jour de Lynis peut avoir ajouté de nouvelles commandes qui annoncent la configuration existante. Mettre à jour Lynis dans le menu, revérifier et traiter des nouvelles constatations."
|
||||
},
|
||||
"files": {
|
||||
"heading": "Fichiers écrits",
|
||||
"code": "/opt/lynis/ # full Lynis git checkout\n/usr/local/bin/lynis # wrapper script (cd + exec)\n/var/log/lynis.log # human-readable audit log (Lynis itself)\n/var/log/lynis-report.dat # machine-readable report (Lynis itself)"
|
||||
},
|
||||
"sample": {
|
||||
"heading": "Exemple de rapport",
|
||||
"intro": "ProxMenux Monitor produit pour chaque exécution de Lynis un PDF de plusieurs pages depuis l'<link>onglet Sécurité</link>. La première page résume score de durcissement, informations système et état de sécurité. Les suivantes détaillent les avertissements, les suggestions classées par impact et l'inventaire des paquets utilisé lors de l'audit.",
|
||||
"imageAlt": "Première page du rapport d'audit de sécurité de Lynis PDF — résumé avec l'index de durcissement 71/100, bloc d'information système, et vue d'ensemble de la posture de sécurité avec pare-feu, scanner de malware et les paquets installés",
|
||||
"captionPrefix": "Première page d'un exemple de rapport. Le PDF complet (",
|
||||
"captionLink": "échantillon",
|
||||
"captionSuffix": ") continue avec des avertissements détaillés, des suggestions et la liste des paquets installés.",
|
||||
"cli": "Sur le côté CLI les mêmes données sont dans <code>/var/log/lynis-report.dat</code> (fichier plat lisible par machine) et <code>/var/log/lynis.log</code> (le journal d'exécution lisible par l'homme). Le PDF est généré sur demande par ProxMenux Monitor — l'exécution de <code>lynis</code> à partir de la ligne de commande n'en produit pas."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/security",
|
||||
"label": "ProxMenux Monitor → Onglet Sécurité",
|
||||
"tail": "— exécuter l'audit, parcourir les rapports historiques et télécharger le PDF directement à partir du tableau de bord."
|
||||
},
|
||||
{
|
||||
"href": "/docs/security/fail2ban",
|
||||
"label": "Fail2Ban",
|
||||
"tailRich": "— met en œuvre la protection de la force brute SSH que recommande Lynis."
|
||||
},
|
||||
{
|
||||
"href": "/docs/security",
|
||||
"label": "Aperçu de la sécurité",
|
||||
"tail": "— retour à l'aperçu de la section."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,169 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "HTTPS pour ProxMenux Monitor — certificat de l'hôte Proxmox ou chemins personnalisés | ProxMenux",
|
||||
"description": "Servez ProxMenux Monitor en HTTPS avec le certificat de l'hôte Proxmox (détecté automatiquement, y compris le certificat Let’s Encrypt installé via ACME de Proxmox) ou un certificat personnalisé à un emplacement quelconque sur disque.",
|
||||
"ogTitle": "HTTPS pour ProxMenux Monitor — Hôte Proxmox ou certificat personnalisé",
|
||||
"ogDescription": "Activer HTTPS sur le port 8008 avec le certificat hôte Proxmox ou toute paire de .pem / .key personnalisée."
|
||||
},
|
||||
"header": {
|
||||
"title": "HTTPS pour ProxMenux Monitor",
|
||||
"description": "Activez HTTPS pour Monitor sur le port 8008 avec le certificat de l'hôte Proxmox détecté automatiquement ou un certificat personnalisé sur disque. L'option Proxmox privilégie le certificat ACME, s'il existe, et réutilise Let’s Encrypt géré par Proxmox sans tâche de renouvellement supplémentaire.",
|
||||
"section": "Sécurité"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que cette page couvre",
|
||||
"body": "Comment changer le moniteur de HTTP à HTTPS dans le panneau Paramètres → Sécurité, ce que chaque source de certificat pointe en fait sur le disque, comment l'option Proxmox se comporte quand l'hôte a un cert Let's Encrypt et comment définir des chemins personnalisés si vous gérez des certs en dehors de Proxmox."
|
||||
},
|
||||
"wheresetting": {
|
||||
"heading": "Emplacement du réglage",
|
||||
"body": "Ouvrez Monitor et allez dans <strong>Paramètres → Sécurité → HTTPS / SSL</strong>. Le panneau affiche HTTP ou HTTPS et, si HTTPS est désactivé, les sources de certificats détectées.",
|
||||
"imageAlt": "Paramètres → Sécurité → Panneau HTTPS / SSL dans le moniteur montrant l'état HTTPS-off, le certificat Proxmox détecté automatiquement (sujet, émetteur, expiration) et l'option Utiliser un certificat personnalisé",
|
||||
"caption": "Panneau Paramètres → Sécurité → HTTPS / SSL avant activation. Monitor affiche le certificat utilisé par Proxmox et permet de le choisir en un clic."
|
||||
},
|
||||
"twoways": {
|
||||
"heading": "Deux façons d'activer HTTPS",
|
||||
"proxmox": {
|
||||
"title": "Utiliser le certificat Proxmox",
|
||||
"summary": "Un clic : Monitor réutilise le certificat présenté par Proxmox VE sur le port 8006.",
|
||||
"items": [
|
||||
"Détecté automatiquement, aucun chemin à saisir",
|
||||
"Privilégie le certificat ACME s'il existe, sinon le certificat autosigné par défaut",
|
||||
"Proxmox renouvelle ; Monitor valide et charge le certificat à la prochaine nouvelle connexion TLS"
|
||||
]
|
||||
},
|
||||
"custom": {
|
||||
"title": "Utiliser un certificat personnalisé",
|
||||
"summaryRich": "Pointez le moniteur sur une paire <code>.pem</code> / <code>.key</code> n'importe où sur le disque.",
|
||||
"items": [
|
||||
"Chemins absolus seulement (le processus Monitor doit pouvoir lire les deux)",
|
||||
"Utile lorsque les certificats proviennent de <code>certbot</code>, <code>acme.sh</code> ou d'un wildcard",
|
||||
"Vous gérez le renouvellement : redémarrez Monitor après modification des fichiers"
|
||||
]
|
||||
}
|
||||
},
|
||||
"proxmoxCert": {
|
||||
"heading": "Certificat Proxmox — ce qu'il indique en réalité à",
|
||||
"intro": "Proxmox VE conserve deux paires de certificats dans <code>/etc/pve/local/</code> :",
|
||||
"table": {
|
||||
"headers": {
|
||||
"file": "Fichier",
|
||||
"origin": "Origine",
|
||||
"when": "Lorsque le moniteur l'utilise"
|
||||
},
|
||||
"rows": [
|
||||
{
|
||||
"fileRich": "<code>pveproxy-ssl.pem</code><br /><code>pveproxy-ssl.key</code>",
|
||||
"originRich": "Certificat personnalisé téléchargé via l'interface utilisateur Proxmox — y compris le certificat Let's Encrypt émis sous <em>Datacenter → Node → Certificats → ACME</em>.",
|
||||
"when": "Préféré si les deux fichiers existent ; Monitor utilise le certificat présenté par Proxmox."
|
||||
},
|
||||
{
|
||||
"fileRich": "<code>pve-ssl.pem</code><br /><code>pve-ssl.key</code>",
|
||||
"originRich": "Certificat autosigné généré au moment de l'installation par l'ICP Proxmox.",
|
||||
"whenRich": "Certificat de repli en l'absence de <code>pveproxy-ssl.pem</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"title": "Même priorité que Proxmox",
|
||||
"bodyRich": "<code>pveproxy</code> applique la même sélection. Avec l'option Proxmox, Monitor utilise le certificat présenté par l'interface Proxmox sur 8006, sans copie ni processus de renouvellement séparé."
|
||||
}
|
||||
},
|
||||
"letsencrypt": {
|
||||
"heading": "Obtenir un certificat Let's Encrypt via Proxmox ACME",
|
||||
"intro": "Proxmox VE inclut son client ACME. <em>« Order Certificate Now »</em> enregistre le résultat dans <code>/etc/pve/local/pveproxy-ssl.pem</code>, lu par Monitor. Les cinq étapes suivantes résument le <extlink1>guide officiel Proxmox</extlink1> avec les commandes nécessaires.",
|
||||
"prereqs": {
|
||||
"title": "Préalables",
|
||||
"items": [
|
||||
"Le noeud a un vrai nom DNS (pas seulement un IP) pointant dessus.",
|
||||
"<strong>Soit</strong> le port 80 accessible depuis Internet (validation HTTP-01, la plus simple), <strong>soit</strong> un fournisseur DNS avec identifiants API (DNS-01, fonctionne derrière NAT et accepte les certificats génériques).",
|
||||
"Une adresse email pour le compte ACME."
|
||||
]
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Étape 1 — Enregistrer le compte ACME",
|
||||
"introRich": "Remplacer le courriel par le vôtre. Le nom de compte <code>default</code> n'est qu'une étiquette — vous pouvez utiliser n'importe quelle chaîne.",
|
||||
"code": "pvenode acme account register default you@example.com",
|
||||
"afterRich": "Proxmox vous invite à accepter les termes de service Let's Encrypt. Après cela, le compte est maintenu sous <code>/etc/pve/priv/acme/</code> et l'onglet ACME dans l'interface graphique l'affichera."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Étape 2 — Choisir un type de défi",
|
||||
"http01Rich": "<strong>HTTP-01</strong> est le plus facile : il est intégré, pas de plugin supplémentaire. Let's Encrypt se connecte à <code>http://<your-host>/.well-known/acme-challenge/...</code> sur le port 80, de sorte que le port 80 doit être ouvert de l'Internet public à votre noeud — généralement un port vers l'avant sur votre routeur.",
|
||||
"dns01Rich": "<strong>DNS-01</strong> fonctionne sans exposer le port 80 (bon pour les homelabs derrière CG-NAT) et est la seule option pour les certificats wildcard. Vous ajoutez un plugin DNS une fois avec le jeton API de votre fournisseur. Exemple Cloudflare:",
|
||||
"code": "pvenode acme plugin add dns cf \\\n --api cloudflare \\\n --data CF_Token=YOUR_CLOUDFLARE_API_TOKEN",
|
||||
"outroRich": "Pour d'autres fournisseurs (Gandi, OVH, AWS Route 53, etc.), consultez <code>pvenode acme plugin add dns --help</code>. Proxmox inclut <extlink2>tous les plugins DNS acme.sh</extlink2>."
|
||||
},
|
||||
"step3": {
|
||||
"heading": "Étape 3 — Relier le domaine à votre nœud",
|
||||
"http01Rich": "Pour HTTP-01 (utilise le plugin <code>standalone</code> intégré):",
|
||||
"code1": "pvenode config set --acme domains=host.example.com,account=default",
|
||||
"dns01": "Pour DNS-01 avec le plugin Cloudflare de l'étape 2 :",
|
||||
"code2": "pvenode config set --acmedomain0 domain=host.example.com,plugin=cf\npvenode config set --acme account=default",
|
||||
"wildcardRich": "Certificat générique ? Ajoutez <code>domain=*.example.com</code> dans une entrée séparée <code>--acmedomainN</code>. Les certificats génériques nécessitent DNS-01."
|
||||
},
|
||||
"step4": {
|
||||
"heading": "Étape 4 — Commander le certificat",
|
||||
"code": "pvenode acme cert order",
|
||||
"afterRich": "Le premier tour prend généralement 30–60 secondes pendant que le défi se propage. Sur succès Proxmox écrit <code>/etc/pve/local/pveproxy-ssl.pem</code> + <code>.key</code>, redémarre <code>pveproxy</code>, et une cron de renouvellement est programmée automatiquement (Let's Encrypt certs sont valides 90 jours; Proxmox renouvelle à 60)."
|
||||
},
|
||||
"step5": {
|
||||
"heading": "Étape 5 — Vérifier l'émetteur",
|
||||
"code": "openssl x509 -in /etc/pve/local/pveproxy-ssl.pem -noout -issuer",
|
||||
"afterRich": "devrait imprimer un émetteur commençant par <code>O = Let's Encrypt</code>. S'il lit plutôt <code>CN = Proxmox Virtual Environment</code> l'ordre a échoué et le fichier est toujours le certificat PVE autosigné — re-exécuter <code>pvenode acme cert order --debug 1</code> pour voir pourquoi."
|
||||
},
|
||||
"gui": {
|
||||
"title": "Vous préférez l'interface utilisateur ? Mêmes cinq étapes",
|
||||
"bodyRich": "<em>Datacenter → ACME</em> enregistre le compte ; <em>Datacenter → ACME → Plugins</em> ajoute le plugin DNS ; <em>Node → Certificates → ACME</em> associe le domaine ; <em>Order Certificates Now</em> exécute l'étape 4. Les commandes précédentes servent à automatiser et à travailler sans interface graphique."
|
||||
}
|
||||
},
|
||||
"switchToHttps": {
|
||||
"heading": "Changez le moniteur en HTTPS",
|
||||
"bodyRich": "Une fois <code>/etc/pve/local/pveproxy-ssl.pem</code> signé par Let's Encrypt, ouvrez <strong>Paramètres → Sécurité → HTTPS / SSL</strong>, vérifiez que l'émetteur est <em>Let's Encrypt</em> et non l'AC locale de Proxmox, puis cliquez sur <strong>Utiliser le certificat Proxmox</strong>. Monitor redémarre et le prochain chargement utilise HTTPS sur 8008 avec une chaîne de confiance publique. Les renouvellements ACME suivants sont validés et sélectionnés à la prochaine nouvelle connexion TLS, sans interrogation périodique ni redémarrage à chaque renouvellement. <strong>Actualiser le certificat</strong> reste disponible dans Sécurité pour le diagnostic et la récupération."
|
||||
},
|
||||
"custom": {
|
||||
"heading": "Certificat personnalisé — quand l'utiliser",
|
||||
"intro": "Cliquez sur <strong>Utiliser un certificat personnalisé</strong> et saisissez deux chemins absolus :",
|
||||
"items": [
|
||||
"<strong>Certificat</strong> — chaîne complète en PEM (<code>.pem</code> ou <code>.crt</code>).",
|
||||
"<strong>Clé privée</strong> : clé correspondante en PEM (<code>.key</code>)."
|
||||
],
|
||||
"outro": "Les deux fichiers sont lus par le processus Monitor au démarrage. Assurez-vous qu'ils restent lisibles par l'utilisateur que l'unité systemd fonctionne comme (root par défaut). Emplacements communs lorsque l'ACME est géré à l'extérieur de Proxmox:",
|
||||
"code": "# certbot\n/etc/letsencrypt/live/<your-host>/fullchain.pem\n/etc/letsencrypt/live/<your-host>/privkey.pem\n\n# acme.sh\n~/.acme.sh/<your-host>_ecc/fullchain.cer\n~/.acme.sh/<your-host>_ecc/<your-host>.key",
|
||||
"symlinkCallout": {
|
||||
"title": "Symlink cibles vs fichiers",
|
||||
"bodyRich": "<code>certbot</code> stocke les fichiers réels dans <code>/etc/letsencrypt/archive/</code> et le chemin <code>live/</code> est un lien symbolique. Pointez le moniteur sur le lien symbolique <code>live/</code> et non sur le fichier <code>archive/</code> — de cette façon, chaque cycle de renouvellement réécrit simplement la cible de lien symbolique et le moniteur récupère le nouveau certificat au début du service suivant."
|
||||
}
|
||||
},
|
||||
"afterHttps": {
|
||||
"heading": "Après avoir activé HTTPS",
|
||||
"bodyRich": "Enregistrer le changement écrit <code>/etc/proxmenux/ssl_config.json</code> et déclenche un redémarrage de l'unité <code>proxmenux-monitor</code> systemd. L'onglet navigateur perdra sa connexion actuelle — rechargez-la sur <code>https://<host>:8008/</code>. La première charge avec un certificat Let's Encrypt ne doit montrer aucun avertissement; avec le certificat Proxmox autosigné, le navigateur aura besoin d'une exception, la même que pour le port 8006.",
|
||||
"reverse": {
|
||||
"heading": "Proxies inverses et webhooks",
|
||||
"bodyRich": "Lorsque le moniteur passe à HTTPS, les URL Proxmox VE webhook enregistrées pour les notifications retournent automatiquement de <code>http://</code> à <code>https://</code>. Les entrées existantes de webhook sont réécrites la prochaine fois qu'une règle de notification est enregistrée ou redétectée, de sorte qu'aucune modification manuelle de la configuration de notification Proxmox n'est nécessaire."
|
||||
}
|
||||
},
|
||||
"trustCa": {
|
||||
"heading": "Faites confiance à l'AC autosignée Proxmox",
|
||||
"intro1Rich": "Pour conserver le certificat Proxmox par défaut sans ACME, importez l'AC racine du cluster dans le magasin de confiance du système ou du navigateur. Monitor détecte <code>/etc/pve/local/pve-ssl.pem</code> comme certificat de repli. Le client fait alors confiance à l'émetteur ; l'URL doit toujours correspondre à un nom du certificat.",
|
||||
"intro2Rich": "Le fichier CA vit à <code>/etc/pve/pve-root-ca.pem</code> sur chaque nœud. Dans un cluster, le chemin est sur le système de fichiers partagé <code>pmxcfs</code> de sorte que tous les nœuds partagent la même racine, et une seule importation couvre l'ensemble du datacenter. Copiez-le sur votre machine :",
|
||||
"code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
|
||||
"thenImport": "Importez-le du côté client :",
|
||||
"items": [
|
||||
"<strong>Linux (tout le système) :</strong> exécutez <code>sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt</code>, puis <code>sudo update-ca-certificates</code>. Les navigateurs utilisant le magasin système (Chromium, Edge) la reconnaissent après redémarrage ; Firefox utilise son propre magasin et nécessite l'importation manuelle ci-dessous.",
|
||||
"<strong>macOS :</strong> ouvrez le fichier <code>.pem</code> par double-clic dans Trousseaux d'accès, ajoutez-le au trousseau <em>Système</em>, puis choisissez <em>Se fier → Toujours approuver</em>.",
|
||||
"<strong>Windows :</strong> clic droit sur le fichier → <em>Installer le certificat</em> → placez-le dans <em>Autorités de certification racines de confiance</em>.",
|
||||
"<strong>Firefox (tout OS) :</strong> <em>Paramètres → Vie privée et sécurité → Certificats → Afficher les certificats → Autorités → Importer</em> ; cochez <em>Faire confiance à cette AC pour identifier les sites web</em>."
|
||||
],
|
||||
"standalone": {
|
||||
"title": "Nœuds autonomes en dehors d'un cluster",
|
||||
"bodyRich": "Chaque hôte Proxmox non clustered possède son propre <code>pve-root-ca.pem</code>. Si vous gérez plusieurs hôtes autonomes, répétez la copie/import pour chacun, ou rejoignez-les à un cluster afin qu'ils partagent une seule racine."
|
||||
}
|
||||
},
|
||||
"disable": {
|
||||
"heading": "Désactivation de HTTPS",
|
||||
"bodyRich": "Cliquez sur <strong>Désactiver HTTPS</strong> dans le même panneau. Monitor redémarre en HTTP non chiffré, utile si un certificat personnalisé illisible empêche le démarrage. Aucune désinstallation supplémentaire n'est nécessaire ; les fichiers de certificats restent intacts.",
|
||||
"stateCallout": {
|
||||
"title": "Emplacement de l'état",
|
||||
"bodyRich": "<code>/etc/proxmenux/ssl_config.json</code> stocke les chemins de cert actif et la source (<code>none</code>, <code>proxmox</code>, <code>custom</code>). La suppression du fichier équivaut à la désactivation de HTTPS — le prochain démarrage du moniteur revient à HTTP."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,123 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hôte : ajouter une cible iSCSI comme stockage Proxmox | Documentation ProxMenux",
|
||||
"description": "Enregistrez une cible iSCSI comme stockage Proxmox avec ProxMenux. L’outil installe open-iscsi, découvre le portail via sendtargets, permet de choisir la cible et exécute pvesm add iscsi. Il fournit des périphériques bloc bruts pour les images disque des VM.",
|
||||
"ogTitle": "Hôte : ajouter une cible iSCSI comme stockage Proxmox | Documentation ProxMenux",
|
||||
"ogDescription": "Enregistrer une cible iSCSI comme stockage Proxmox avec découverte guidée. Utilise pvesm add iscsi et fournit des périphériques de blocs bruts pour les disques VM."
|
||||
},
|
||||
"header": {
|
||||
"title": "Hôte : Ajouter une cible iSCSI comme stockage Proxmox",
|
||||
"description": "Enregistrez une cible iSCSI (à partir d'un SAN, TrueNAS / FreeNAS, Synology, une cible Windows Server, n'importe quel baie compatible avec iSCSI) comme stockage Proxmox. Les LUN exportés apparaissent comme des périphériques de blocs et peuvent héberger des images de disque VM à des performances quasi locales sur le réseau.",
|
||||
"section": "Stockage et partage · Hôte"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "ProxMenux enveloppe <code>pvesm add iscsi</code> avec un flux guidé: il installe <code>open-iscsi</code> si nécessaire, demande le portail iSCSI (IP:port), exécute <code>iscsiadm --mode discovery --type sendtargets</code> contre lui, vous permet de choisir une cible IQN, et enregistre le stockage iSCSI dans Proxmox. Le service <code>iscsid</code> maintient ensuite la session iSCSI en vie à travers les reboots."
|
||||
},
|
||||
"vocab": {
|
||||
"heading": "vocabulaire iSCSI (référence rapide)",
|
||||
"headerTerm": "Terme",
|
||||
"headerMeaning": "Signification",
|
||||
"rows": [
|
||||
{
|
||||
"term": "Portail",
|
||||
"meaningRich": "Le point d’accès du service iSCSI sur le serveur cible : une adresse IP (ou un nom d’hôte) et un port TCP. Le port par défaut est <code>3260</code> ; ProxMenux l’utilise si aucun autre n’est indiqué."
|
||||
},
|
||||
{
|
||||
"term": "Cible",
|
||||
"meaningRich": "Un seul \"serveur\" exporté à l'intérieur du portail, identifié par son IQN (<em>iSCSI Nom qualifié</em>). Un portail peut accueillir de nombreuses cibles."
|
||||
},
|
||||
{
|
||||
"term": "IQN",
|
||||
"meaningRich": "La forme canonique est <code>iqn.YYYY-MM.reverse.domain:identifier</code>, par exemple <code>iqn.2024-08.com.truenas:proxmox-pool</code>. La cible et l'initiateur ont leur propre IQN."
|
||||
},
|
||||
{
|
||||
"term": "LUN",
|
||||
"meaningRich": "Un périphérique bloc à l'intérieur d'une cible (numéro d'unité logique). Une seule cible peut exposer plusieurs LUN ; chaque LUN apparaît comme son propre disque dans Proxmox et peut devenir un disque VM."
|
||||
},
|
||||
{
|
||||
"term": "Initiateur",
|
||||
"meaningRich": "Le client qui se connecte à une cible — dans ce cas, votre hôte Proxmox. L'initiateur a son propre IQN stocké dans <code>/etc/iscsi/initiatorname.iscsi</code>. Les cibles n'acceptent généralement que les sessions des IQN des initiateurs préautorisés."
|
||||
}
|
||||
]
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Depuis le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Ajouter iSCSI Target comme Proxmox Storage</strong>. Vous verrez ce menu sub avec quatre options :",
|
||||
"imageAlt": "Menu du gestionnaire d'hôtes iSCSI — Ajouter / Afficher / Supprimer / Tester la connectivité"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (Ajouter le flux)",
|
||||
"body": "Le flux a deux phases avec une séparation claire entre \"la mise en place de l'initiateur, la découverte des cibles\" et \"l'enregistrement effectif du stockage dans Proxmox\". Contrairement à NFS / Samba, il n'y a pas d'auto-découverte sur le sous-réseau — vous devez connaître l'adresse du portail (iSCSI n'est pas convivial pour la diffusion)."
|
||||
},
|
||||
"add": {
|
||||
"heading": "Ajouter la cible iSCSI comme stockage Proxmox",
|
||||
"items": [
|
||||
"<strong>Saisie du portail</strong> — tapez l'IP ou le nom d'hôte du serveur cible iSCSI. Port <code>3260</code> est supposé sauf si vous tapez <code>host:port</code>.",
|
||||
"<strong>Découverte des cibles</strong> — ProxMenux appelle <code>iscsiadm --mode discovery --type sendtargets --portal <ip:port></code>. Le serveur répond avec chaque IQN qu'il permet à cet initiateur de voir. Si la découverte échoue, le script affiche l'erreur exacte de <code>iscsiadm</code> et énumère les causes courantes (mauvaise IP, pare-feu, initiateur IQN non autorisé).",
|
||||
"<strong>Sélection des cibles</strong> — une seule cible est sélectionnée automatiquement; plusieurs cibles affichent un menu.",
|
||||
"<strong>Storage ID</strong> — par défaut <code>iscsi-<last IQN segment, 20 chars max></code>. Seulement lettres, chiffres, <code>-</code> et <code>_</code>.",
|
||||
"<strong>Type de contenu</strong> — contrairement à NFS / Samba, le contenu iSCSI est <strong>fixé à <code>images</code></strong>. iSCSI expose les périphériques de blocs bruts, pas un système de fichiers, donc Proxmox vous permet seulement d'héberger des disques VM sur lui."
|
||||
],
|
||||
"authTitle": "Autoriser l'initiateur Proxmox sur la cible",
|
||||
"authBody1": "Avant que le flux Add ne fonctionne de bout en bout, la cible iSCSI doit connaître votre hôte Proxmox. Obtenez votre initiateur IQN:",
|
||||
"authBody2": "Ajoutez cet IQN à la liste d’accès de la cible (TrueNAS : <em>Sharing → Block → Initiators Groups</em> ; Synology : <em>SAN Manager → iSCSI → Target → Edit → Initiators</em> ; etc.). Si l’initiateur n’est pas autorisé, la découverte avec <code>iscsiadm</code> renvoie une liste vide ou une erreur d’authentification."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "La procédure complète correspond aux commandes suivantes :"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Affichage des stockages iSCSI configurés",
|
||||
"body": "Liste toutes les entrées iSCSI dans Proxmox (<code>pvesm status | awk ''$2 == \"iscsi\"''</code>) avec portail, cible IQN, type de contenu et statut en direct."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Supprimer le stockage iSCSI",
|
||||
"body": "Exécute <code>pvesm remove <storage-id></code> après avoir confirmé portail, cible et contenu. Seul l’enregistrement Proxmox est supprimé — <strong>la cible iSCSI elle-même n'est pas touchée</strong> et les sessions existantes du côté noyau peuvent durer jusqu'au prochain redémarrage.",
|
||||
"warnTitle": "Vérifiez d’abord les disques VM existants sur cet iSCSI",
|
||||
"warnBody": "Supprimer un stockage iSCSI alors que des VM y possèdent encore des disques laisse ces VM pointer vers un stockage absent. Proxmox signale l’erreur, mais les données LUN restent intactes sur la cible : vous pouvez réenregistrer le stockage pour retrouver les disques. Déplacez ou sauvegardez toutefois les VM au préalable par précaution."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Tester la connectivité iSCSI",
|
||||
"body": "Exécute une passe de diagnostic : vérifie que <code>iscsiadm</code> est installé, imprime votre initiateur IQN, confirme que <code>iscsid</code> fonctionne, pinge chaque portail enregistré, sonde son port, et signale <code>pvesm status</code> plus si une session iSCSI est actuellement active (<code>iscsiadm --mode session</code>). Session active plus portail accessible, mais \"inactive\" dans Proxmox signifie généralement un état obsolète — essayez <code>pvesm set <id> --disable 0</code>."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"portalTitle": "\"Impossible d'atteindre le portail\" mais l'IP du serveur répond ailleurs",
|
||||
"portalBody": "Ping a échoué sur l'adresse du portail. Vérifiez que vous atteignez l'interface <em>réseau de stockage</em> (iSCSI vit souvent sur un réseau VLAN / sous-net séparé du réseau de gestion). Vérifiez également DNS si vous avez tapé un nom d'hôte.",
|
||||
"discoverTitle": "\"la découverte iSCSI a échoué\" de l'iscsiadm",
|
||||
"discoverIntro": "Le script montre l'erreur exacte. Causes les plus courantes:",
|
||||
"discoverItems": [
|
||||
"Portal IP / port incorrect (double vérification, par défaut est 3260).",
|
||||
"Le service iSCSI ne fonctionne pas sur le serveur cible.",
|
||||
"Pare-feu bloque 3260 entre Proxmox et la cible.",
|
||||
"<strong>L’IQN de l’initiateur n’est pas autorisé sur la cible.</strong> Cause la plus fréquente sur les baies professionnelles. Ajoutez d’abord l’IQN Proxmox à l’ACL des initiateurs de la cible."
|
||||
],
|
||||
"noTargetTitle": "Aucune cible trouvée mais la découverte a réussi",
|
||||
"noTargetBody": "Le serveur a accepté votre initiateur mais ne lui expose aucune cible. Vérifiez les contrôles d’authentification et d’accès : certaines baies autorisent la découverte pour tous les IQN mais filtrent les cibles visibles par chacun.",
|
||||
"noLunTitle": "Les LUNs n'apparaissent pas dans /dev/disk/by-path après enregistrement",
|
||||
"noLunBody": "<code>pvesm add iscsi</code> a réussi mais le noyau ne voit pas les périphériques de blocs. Vérifiez <code>iscsiadm --mode session</code> — Si aucune session n'est active, démarrez manuellement avec <code>iscsiadm --mode node --login</code>. Si une session existe mais qu'aucun LUN n'apparaît, forcez un rescan : <code>iscsiadm --mode session --rescan</code>. Si rien n'est encore fait, la cible n'a probablement pas encore de LUN assigné à cet IQN (configurer la cartographie LUN sur la cible).",
|
||||
"chapTitle": "Authentification CHAP",
|
||||
"chapBody": "ProxMenux ne propose pas de champs utilisateur/mot de passe CHAP dans le processus interactif. Si la découverte échoue, le script s’arrête avant <code>pvesm add</code> ; le stockage n’est pas enregistré malgré l’échec. Configurez séparément les exigences CHAP de la cible dans <code>open-iscsi</code>, y compris l’authentification de découverte si nécessaire, puis réessayez. Vérifiez la configuration avec <code>iscsiadm</code> et les sessions actives avec <code>iscsiadm --mode session</code>."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "Partage NFS comme stockage Proxmox",
|
||||
"tail": "— alternative au niveau des fichiers. Plus simple à configurer, plus flexible (backup / ISO / tmpl / images), légèrement plus lent pour les disques en direct VM."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS comme stockage Proxmox",
|
||||
"tail": " — une autre option au niveau des fichiers ; à éviter pour les disques des VM actives en raison de la sémantique des verrous."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Ajouter le disque local comme stockage Proxmox",
|
||||
"tail": "— lorsque le disque est local à l'hôte Proxmox, pas sur une autre boîte sur le réseau."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,186 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hôte : Ajouter le disque local comme stockage Proxmox ProxMenux Documentation",
|
||||
"description": "Formatez un disque SATA, SAS ou NVMe local sur un hôte Proxmox et enregistrez-le comme stockage de type répertoire ou pool ZFS. L’outil vérifie les disques, exige une confirmation avant les opérations destructives, configure fstab par UUID, crée les pools ZFS et utilise pvesm add dir / zfspool.",
|
||||
"ogTitle": "Hôte : Ajouter le disque local comme stockage Proxmox ProxMenux Documentation",
|
||||
"ogDescription": "Formatez un disque local et enregistrez-le comme stockage répertoire ou pool ZFS dans Proxmox avec une procédure guidée et des filtres de sécurité."
|
||||
},
|
||||
"header": {
|
||||
"title": "Hôte : Ajouter un disque local comme stockage Proxmox",
|
||||
"description": "Choisissez un disque physique sur l’hôte Proxmox, formatez-le si nécessaire en ext4, xfs, btrfs ou zfs, puis enregistrez-le comme stockage répertoire avec pvesm add dir ou comme pool ZFS avec pvesm add zfspool. ProxMenux écarte le disque système et les disques utilisés, et annonce chaque opération destructive avant de l’exécuter.",
|
||||
"section": "Stockage et partage · Hôte"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "D'autres outils <em>Host</em> dans cette section traitent du stockage <strong>réseau</strong> (NFS / Samba / iSCSI). Celui-ci traite des disques <strong>locaux</strong> — disques de rechange physiquement attachés à votre hôte Proxmox que vous souhaitez utiliser pour les disques, sauvegardes, ISO ou modèles VM. ProxMenux prépare le disque (partitionnement + formatage + montage) et l'enregistre dans Proxmox afin que l'interface utilisateur puisse y placer du contenu."
|
||||
},
|
||||
"destructive": {
|
||||
"title": "Outil destructif pour le chemin 'format'",
|
||||
"body": "L’option <em>Formater</em> <strong>détruit les partitions et données existantes du disque sélectionné</strong>. ProxMenux affiche un avertissement, filtre les disques utilisés et exige une confirmation avant <code>wipefs</code> / <code>sgdisk</code> / <code>mkfs</code>. Ce n’est pas un écrasement sécurisé de chaque octet. Vérifiez deux fois le chemin du périphérique avant de confirmer."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "Répertoire ou pool ZFS — que choisir ?",
|
||||
"headerDir": "Répertoire (ext4 / xfs / btrfs)",
|
||||
"headerZfs": "Pool ZFS",
|
||||
"rows": [
|
||||
{
|
||||
"label": "Type de stockage Proxmox",
|
||||
"dirRich": "<code>dir</code>",
|
||||
"zfsRich": "<code>zfspool</code>"
|
||||
},
|
||||
{
|
||||
"label": "Format du disque VM",
|
||||
"dir": "Fichier qcow2 / raw dans un système de fichiers",
|
||||
"zfs": "Ensemble de données Native ZFS (zvol) par disque"
|
||||
},
|
||||
{
|
||||
"label": "Instantanés",
|
||||
"dir": "qcow2 snapshots; btrfs snapshots si fs=btrfs",
|
||||
"zfs": "Natif, instantané, copie à l'écriture"
|
||||
},
|
||||
{
|
||||
"label": "Allocation fine",
|
||||
"dir": "Oui (par défaut qcow2)",
|
||||
"zfs": "Oui (ZFS par défaut)"
|
||||
},
|
||||
{
|
||||
"label": "Besoins en RAM",
|
||||
"dir": "Faible",
|
||||
"zfs": "Élevés — ZFS utilise la RAM disponible comme cache ARC"
|
||||
},
|
||||
{
|
||||
"label": "Prend en charge les types de contenu",
|
||||
"dir": "images, backup, iso, vztmpl, snippets, rootdir",
|
||||
"zfs": "images et rootdir uniquement (stockage en blocs)"
|
||||
},
|
||||
{
|
||||
"label": "Meilleur pour",
|
||||
"dir": "Disque à usage général: mélange de disques VM, sauvegardes, ISO",
|
||||
"zfs": "Pure disque de données VM / LXC avec instantané + besoins d'intégrité"
|
||||
}
|
||||
]
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Add Local Disk as Proxmox Storage</strong>. Le sous-menu comporte quatre options :",
|
||||
"imageAlt": "Menu Local Disk Manager — Ajouter / Afficher / Supprimer / Liste des disques disponibles"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (Ajouter le flux)",
|
||||
"body": "La procédure comporte deux phases avec un filtre de sécurité à trois vérifications. Phase 1 découvre les disques sûrs, décide ce qu'il faut faire avec celui choisi et recueille les paramètres de stockage; Phase 2 fait le travail destructeur. Jusqu'à la confirmation finale, le disque est intact."
|
||||
},
|
||||
"format": {
|
||||
"heading": "Formater un disque vide",
|
||||
"intro": "Le chemin pour un disque frais ou un disque dont le contenu ne vous intéresse pas.",
|
||||
"items": [
|
||||
"Choisissez le disque (système / disques en usage sont cachés).",
|
||||
"Choisissez \"Format disque (ERASE toutes les données)\".",
|
||||
"Choisissez le système de fichiers — voir le tableau ci-dessus pour les compromis.",
|
||||
"ID de stockage (<code>disk-<device></code> par défaut), chemin de montage, préréglage de type contenu.",
|
||||
"Confirmez dans le dialogue <strong>CONFIRMATION FINALE — LES DONNÉES SERONT EFFACÉES</strong>.",
|
||||
"ProxMenux efface la table de partitions et crée une partition sur tout le disque. Il exécute <code>mkfs.<fs></code> ou <code>zpool create</code>, puis monte le résultat. Les systèmes de fichiers classiques reçoivent une entrée UUID dans <code>/etc/fstab</code> avec <code>defaults,nofail</code> ; ZFS utilise la configuration de montage du pool. Si <em>Comme stockage Proxmox</em> est coché (toujours le cas pour ZFS), il est ensuite enregistré avec <code>pvesm add dir</code> ou <code>pvesm add zfspool</code> ; sinon, il reste un simple montage de l’hôte."
|
||||
],
|
||||
"tipTitle": "Pourquoi UUID + nofail dans /etc/fstab",
|
||||
"tipBody": "Le script écrit <code>UUID=… /mnt/<id> <fs> defaults,nofail 0 2</code>. UUID survit à la réorganisation de l'appareil à travers les reboots (ainsi <code>/dev/sdc</code> devenir <code>/dev/sdd</code> ne casse pas le démarrage). <code>nofail</code> signifie que si le disque disparaît un jour (défaut de matériel, débranché), Proxmox démarre quand même — le stockage se montrera comme inactif jusqu'à ce que le disque revienne."
|
||||
},
|
||||
"reuse": {
|
||||
"heading": "Réutiliser un système de fichiers existant",
|
||||
"intro": "Le chemin pour un disque sur lequel vous souhaitez conserver les données — peut-être l'avez-vous déplacé d'un autre hôte Proxmox, ou le disque a déjà des sauvegardes / ISO que vous voulez garder accessible.",
|
||||
"items": [
|
||||
"Choisissez le disque.",
|
||||
"Choisir « Utiliser le système de fichiers existant ».",
|
||||
"ID de stockage, chemin de montage, préréglage de type contenu.",
|
||||
"ProxMenux ne touche <strong>pas</strong> aux données : il crée le point de montage, monte le disque, ajoute une entrée UUID à <code>/etc/fstab</code> et l'enregistre en tant que stockage Proxmox <code>dir</code>."
|
||||
],
|
||||
"warnTitle": "Le chemin de réutilisation ne gère pas ZFS pools",
|
||||
"warnBody": "Si le disque contient déjà un pool ZFS, le chemin <em>reuse</em> essaie ici de le monter en tant que système de fichiers régulier — qui échoue. Pour importer un pool ZFS existant, utilisez <code>zpool import <name></code> sur la ligne de commande, puis enregistrez-le manuellement avec <code>pvesm add zfspool</code>."
|
||||
},
|
||||
"presets": {
|
||||
"heading": "Préréglages de type contenu",
|
||||
"intro": "ProxMenux propose trois préréglages et une option personnalisée. La liste de contenu choisie est transmise à <code>pvesm add … --content <csv></code> :",
|
||||
"headerPreset": "Préréglage",
|
||||
"headerContent": "Chaîne de contenu",
|
||||
"headerUse": "Cas d'utilisation",
|
||||
"rows": [
|
||||
{
|
||||
"preset": "Stockage VM",
|
||||
"content": "images,backup",
|
||||
"use": "Un magasin de disques VM dédié qui conserve également les sauvegardes de ces VMs à proximité."
|
||||
},
|
||||
{
|
||||
"preset": "NAS standard",
|
||||
"content": "backup,iso,vztmpl",
|
||||
"use": "Une archive / disque multimédia — sauvegardes, ISOs et modèles LXC. Pas de disques VM en direct ici."
|
||||
},
|
||||
{
|
||||
"preset": "Tous types",
|
||||
"content": "images,backup,iso,vztmpl,snippets",
|
||||
"use": "Ce préréglage étendu active images, sauvegardes, ISO, modèles LXC et snippets. Ajoutez d’autres types pris en charge, comme rootdir, via Personnalisé si nécessaire."
|
||||
},
|
||||
{
|
||||
"preset": "Personnalisé",
|
||||
"content": "(saisie libre)",
|
||||
"useRich": "Tapez le CSV exact vous-même, par exemple. <code>images</code> seul ou <code>rootdir,images</code>."
|
||||
}
|
||||
],
|
||||
"zfsTitle": "ZFS pool le contenu est plus étroit",
|
||||
"zfsBody": "Avec <strong>zfs</strong>, un <code>zfspool</code> accepte uniquement <code>images</code> et <code>rootdir</code>, pas les fichiers ISO ou de sauvegarde. Saisissez une liste compatible via Personnalisé. Le script la transmet sans modification ; des types non pris en charge peuvent faire échouer l’enregistrement. Vérifiez ensuite <code>pvesm status</code>."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"extIntro": "Format + enregistrer un disque comme stockage de répertoire ext4 :",
|
||||
"zfsIntro": "Ou comme un pool ZFS:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Afficher les stockages de disques",
|
||||
"body": "Liste tous les stockages Proxmox soutenus par un disque (les deux <code>dir</code> et <code>zfspool</code> qui sont créés par l'utilisateur — système pools comme <code>rpool</code> sont cachés). Affiche le chemin de montage / pool nom, types de contenu et statut en direct."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Supprimer le stockage du disque",
|
||||
"body": "Désenregistre le stockage de Proxmox (<code>pvesm remove</code>) et propose de nettoyer l'entrée correspondante dans <code>/etc/fstab</code>. Pour ZFS pools, le script <strong>ne détruit pas</strong> automatiquement le pool — il s'agit d'une étape <code>zpool destroy <name></code> distincte que vous effectuez manuellement lorsque vous êtes sûr.",
|
||||
"warnTitle": "Données et dépendances existantes VM",
|
||||
"warnBody": "La suppression du stockage ne touche pas le système de fichiers ou le pool — les données restent sur le disque. Mais VMs / CTs qui font référence à ce stockage par ID échouera à démarrer après la suppression. Déplacez ces disques VM vers un autre stockage (ou prenez une sauvegarde) avant de les supprimer."
|
||||
},
|
||||
"list": {
|
||||
"heading": "Liste des disques disponibles",
|
||||
"body": "Une vue diagnostique en lecture seule : imprime la sortie de <code>lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL</code> suivie des stockages <code>dir</code> / <code>zfspool</code> Proxmox en est déjà au courant. Bon premier arrêt lorsque vous ouvrez l'outil et que vous voulez voir \"ce qui est sur cet hôte?\" avant d'ajouter quelque chose."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noDisksTitle": "\"Aucun disque disponible trouvé\"",
|
||||
"noDisksIntro": "Le filtre de sécurité a caché chaque disque. Raisons communes:",
|
||||
"noDisksItems": [
|
||||
"Seul le disque racine est présent.",
|
||||
"Tous les autres disques font partie d'un tableau actif ZFS / LVM / RAID.",
|
||||
"Chaque disque est référencé par une config VM ou LXC (passthrough).",
|
||||
"Le disque est en lecture seule (défaillance matérielle ou dispositif de blocage des écritures)."
|
||||
],
|
||||
"noDisksOutro": "Utiliser <em>List Disques disponibles</em> dans le menu pour voir la sortie brute <code>lsblk</code> et comprendre ce qui se passe.",
|
||||
"mountedTitle": "Le format échoue avec \"le dispositif est monté\"",
|
||||
"mountedBody": "Quelque chose a monté automatiquement le disque (udisksd, un gestionnaire de bureau, une unité de systemd persistante). Démonter : <code>umount /dev/sdX?*</code> ou <code>systemctl stop <whatever-mounts-it></code>, puis réessayer. Le filtre de sécurité du script devrait avoir des disques cachés montés, donc si vous avez atteint cette erreur, le montage s'est produit entre le menu montrant et vous confirmant.",
|
||||
"zpoolTitle": "Échec de zpool create : « invalid vdev specification »",
|
||||
"zpoolBody": "En général, le disque a encore des signatures GPT/LVM/ZFS que <code>zpool</code> refuse d'écraser sans force. Le script exécute <code>wipefs</code> et <code>sgdisk --zap-all</code> avant le format, mais un disque très têtu peut encore avoir une étiquette obstinée. Forcez un nettoyage manuellement : <code>zpool labelclear -f /dev/sdX</code> ou <code>dd if=/dev/zero of=/dev/sdX bs=1M count=10</code> et réessayez.",
|
||||
"inactiveTitle": "Le stockage s'affiche comme inactif après redémarrage",
|
||||
"inactiveBody": "Vérifiez <code>findmnt <mount-path></code> — si le montage est manquant, quelque chose dans <code>/etc/fstab</code> a échoué. <code>dmesg | tail</code> pointe habituellement à la raison (inadéquation UUID, corruption du système de fichiers, <code>nofail</code> a abandonné la réessayer). Un <code>mount -a</code> réactive habituellement le stockage une fois la cause réglée."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"label": "Gestionnaire de disques : formater / effacer un disque physique",
|
||||
"tail": "— alternative de bas niveau lorsque vous voulez simplement préparer un disque sans l'enregistrer comme stockage Proxmox."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-iscsi",
|
||||
"label": "Ajouter la cible iSCSI comme stockage Proxmox",
|
||||
"tail": " — équivalent réseau lorsque le périphérique bloc se trouve sur une autre machine."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"label": "Ajouter un répertoire partagé sur l'hôte",
|
||||
"tail": " — prépare un répertoire sur l’hôte pour les bind mounts LXC, sans l’enregistrer comme stockage Proxmox."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,103 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hôte : ajouter un répertoire partagé | Documentation ProxMenux",
|
||||
"description": "Créez un répertoire hôte prêt pour les bind mounts LXC, avec des permissions adaptées aux conteneurs privilégiés et non privilégiés. Sticky bit, rwx pour tous et ACL par défaut pour l’héritage.",
|
||||
"ogTitle": "Hôte : ajouter un répertoire partagé | Documentation ProxMenux",
|
||||
"ogDescription": "Préparer un répertoire hôte pour les bind mounts LXC avec des permissions compatibles avec des CT privilégiés et non privilégiés."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host : Ajouter un répertoire partagé sur Host",
|
||||
"description": "Créer un répertoire hôte conçu pour être monté sur un ou plusieurs conteneurs LXC. ProxMenux applique un ensemble de permissions qui fonctionne à la fois pour les CT privilégiés et non privilégiés à la fois — pas de maux de tête UID décalés, pas de chowns par conteneur — et enregistre le répertoire afin que le gestionnaire de montage LXC puisse le récupérer plus tard.",
|
||||
"section": "Stockage et partage · Hôte"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que c'est (et n'est PAS)",
|
||||
"body": "Cet outil n'enregistre <strong>pas</strong> quoi que ce soit dans Proxmox (pas de <code>pvesm add</code> ici). Il prépare simplement un répertoire sur l'hôte — <code>/mnt/shared</code>, par défaut — avec des autorisations que tout conteneur LXC peut lire et écrire, que le CT soit privilégié ou non. L'étape suivante habituelle consiste à le monter en liaison dans chaque CT avec le <mountLink>LXC Mount Manager</mountLink>."
|
||||
},
|
||||
"why": {
|
||||
"heading": "Pourquoi un outil dédié à cette tâche",
|
||||
"intro": "Lorsque vous liez un répertoire hôte dans un conteneur LXC, les permissions dépendent de :",
|
||||
"items": [
|
||||
"Si le CT est <strong>privilégié</strong> (UID 0 du CT = UID 0 de l’hôte) ou <strong>non privilégié</strong> (UID 0 du CT = UID 100000 de l’hôte — tout est décalé de +100000).",
|
||||
"Le propriétaire du répertoire hôte (un fichier appartenant à l’UID 1000 sur l’hôte relève des permissions « autres » pour un CT non privilégié, car aucun utilisateur du CT ne correspond à cet UID hôte).",
|
||||
"Indique si plusieurs CT partagent le même répertoire (différents CT peuvent avoir des plages UID différentes)."
|
||||
],
|
||||
"outro": "ProxMenux choisit ici une solution pratique : <strong>donner accès à tout le monde</strong> au niveau du système de fichiers, avec rwx pour tous, le sticky bit et des ACL pour l’héritage des permissions. Tout UID mappé peut lire et écrire ; aucun alignement des UID/GID n’est nécessaire."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le script n'a pas de menu principal — il exécute une seule action, <strong>Créer répertoire partagé</strong>. Phase 1 recueille le chemin cible; Phase 2 crée le répertoire et applique les permissions."
|
||||
},
|
||||
"bits": {
|
||||
"heading": "Ce que chaque bit de permission fait",
|
||||
"intro": "Le numéro <strong>1777</strong> n'est pas arbitraire — c'est le même mode que Linux utilise pour <code>/tmp</code>. Trois propriétés combinées:",
|
||||
"headerBit": "Bit",
|
||||
"headerEffect": "Effet",
|
||||
"headerWhy": "Pourquoi c'est important ici",
|
||||
"rows": [
|
||||
{
|
||||
"bit": "1 (sticky bit)",
|
||||
"effect": "Seuls le propriétaire du fichier, celui du répertoire ou un processus suffisamment privilégié peuvent supprimer ou renommer le fichier.",
|
||||
"why": "Limite la suppression des fichiers d’autres utilisateurs ayant des UID mappés différents. N’isole pas les CT partageant un UID mappé ou un accès root privilégié."
|
||||
},
|
||||
{
|
||||
"bit": "777 (rwx-rwx-rwx)",
|
||||
"effect": "Tout le monde peut lire, écrire et traverser.",
|
||||
"why": "Les UIDs CT non privilégiés (100000+) apparaissent comme des \"autres\" de l'hôte, de sorte que world-rwx leur donne accès."
|
||||
},
|
||||
{
|
||||
"bit": "ACL (par défaut)",
|
||||
"effect": "Hérité sur chaque fichier / sous-dir nouvellement créé.",
|
||||
"why": "Le nouveau contenu hérite des ACL par défaut sans réexécuter le script. Les applications peuvent toutefois demander des modes restrictifs ou modifier les permissions ensuite."
|
||||
}
|
||||
],
|
||||
"privTitle": "Les CT privilégiés voient la même chose, juste sans le changement",
|
||||
"privBody": "Pour un CT privilégié, UID 0 dans le CT est UID 0 sur l'hôte, de sorte que <code>root</code> à l'intérieur du CT peut lire / écrire le répertoire hôte directement. Le <code>1777</code> est toujours bien — cela signifie simplement que les utilisateurs non root à l'intérieur du CT peuvent également utiliser le répertoire. Les mêmes autorisations couvrent les deux cas."
|
||||
},
|
||||
"where": {
|
||||
"heading": "Où mettre le répertoire partagé",
|
||||
"intro": "Le localisateur offre quatre options :",
|
||||
"opt1Title": "1. Créer un nouveau dossier dans /mnt",
|
||||
"opt1Body": "Le choix habituel. Le ProxMenux suggère automatiquement la première dénomination libre (<code>shared</code>, <code>shared2</code>, <code>shared3</code>, ...). Il suffit de confirmer ou de taper un nom différent.",
|
||||
"opt2Title": "2. Saisissez le chemin personnalisé",
|
||||
"opt2Body": "Pour les répertoires hors <code>/mnt</code>. Tout chemin absolu fonctionne (par exemple : <code>/srv/media</code>, <code>/data/family</code>). Le script applique les mêmes permissions.",
|
||||
"opt3Title": "3. Afficher les dossiers existants dans /mnt",
|
||||
"opt3Body": "Diagnostic en lecture seule : liste chaque répertoire sous <code>/mnt</code> avec ses permissions, son propriétaire et son espace disponible. Utile avant de créer un nouveau pour éviter les collisions de noms.",
|
||||
"opt4Title": "4. Annuler",
|
||||
"opt4Body": "Quitte sans rien créer, comme la touche <kbd>Esc</kbd>.",
|
||||
"tipTitle": "Où vit /mnt ?",
|
||||
"tipBody": "Par défaut, <code>/mnt</code> se trouve sur le système de fichiers racine Proxmox. Si vous voulez le répertoire partagé sur un disque différent (un disque de données, un pool ZFS), montez ce disque sous <code>/mnt/<name></code> d'abord (Disk Manager ou <diskLink>Ajouter le disque local comme stockage Proxmox</diskLink>), puis créez le répertoire partagé comme sous-dossier à l'intérieur — ou choisissez \"Entrer le chemin personnalisé\" ici et pointez sur le disque monté."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Tout le flux peut être rejoué à la main:"
|
||||
},
|
||||
"next": {
|
||||
"heading": "Étape suivante : bind mount dans les conteneurs",
|
||||
"body": "La création du répertoire ne fait que le préparer — aucun conteneur ne le voit encore. Pour le rendre visible à l'intérieur d'un ou plusieurs LXC, utilisez le <mountLink>LXC Mount Manager</mountLink> pour lier le montage de <code>/mnt/<name></code> dans les CT. Étant donné que les autorisations sont déjà ouvertes, Mount Manager <strong>ne proposera pas</strong> de les modifier : le répertoire est prêt à être utilisé tel quel."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"mkdirTitle": "\"Failed to create directory\"",
|
||||
"mkdirBody": "Habituellement un problème de système de fichiers: <code>/mnt</code> est sur un système de fichiers en lecture seule, le chemin contient un composant qui n'est pas un répertoire (par exemple, vous avez tapé <code>/etc/passwd/sub</code>), ou le disque est plein. Vérifiez avec <code>df -h /mnt</code> et <code>mount | grep /mnt</code>.",
|
||||
"writeTitle": "Conteneur ne peut pas écrire malgré les autorisations ouvertes",
|
||||
"writeBody": "Vérifiez que le CT utilise bien le bind mount (<code>pct config <ctid> | grep ^mp</code>). À l'intérieur du CT, exécutez <code>touch /mnt/data/test-$(date +%s)</code> — si cela échoue avec la permission refusée, le montage peut être sur un système de fichiers hôte qui n'honore pas les ACL (certaines anciennes <code>ext3</code> ou <code>vfat</code> montures). Déplacez le répertoire partagé vers un support ext4 / xfs / btrfs / zfs.",
|
||||
"aclTitle": "ACL commande silencieusement indisponible",
|
||||
"aclBody": "Sur une installation Proxmox minimale <code>setfacl</code> / <code>getfacl</code> peuvent ne pas être installés. Le script tombe gracieusement (contrôle <code>command -v setfacl</code>) et n'applique que les permissions POSIX — ce qui est souvent suffisant, mais les nouveaux fichiers n'hériteront pas automatiquement du profil permissif. Installez <code>acl</code> avec <code>apt-get install -y acl</code> et réexécutez le script dans le répertoire."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Gestionnaire de montage LXC",
|
||||
"tail": "— l'étape suivante naturelle: lier ce répertoire dans un ou plusieurs conteneurs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Ajouter le disque local comme stockage Proxmox",
|
||||
"tailRich": "— si vous voulez le répertoire partagé sur un disque dédié, préparez le disque d'abord, montez-le sous <code>/mnt</code>, puis créez le sous-dossier partagé ici."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,174 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hôte : monter un partage NFS | Documentation ProxMenux",
|
||||
"description": "Montez une exportation externe de NFS sur l'hôte Proxmox — soit sous forme de stockage Proxmox (pvesm add nfs), soit sous forme de montage fstab (NON visible dans Datacenter > Storage), ou les deux. La méthode fstab est idéale pour lier le partage dans les conteneurs LXC sans l'exposer comme stockage Proxmox.",
|
||||
"ogTitle": "Hôte : monter un partage NFS | Documentation ProxMenux",
|
||||
"ogDescription": "Montez un export NFS externe sur l’hôte Proxmox via pvesm, fstab ou les deux. La méthode fstab convient aux bind mounts LXC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Hôte : monter un partage NFS sur l’hôte",
|
||||
"description": "Montez une exportation externe de NFS (à partir d'un NAS, d'un autre serveur, d’un partage homelab...) sur l'hôte Proxmox. Choisissez une ou les deux méthodes : enregistrez-la en tant que stockage Proxmox (visible dans Datacenter > Storage) et/ou ajoutez un montage simple /etc/fstab sur un chemin que vous choisissez (utile pour lier le partage dans des conteneurs LXC sans l'exposer comme stockage Proxmox).",
|
||||
"section": "Stockage et partage · Hôte"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "ProxMenux propose deux méthodes de montage pour toute exportation de NFS : <strong>(1) Stockage Proxmox</strong> via <code>pvesm add nfs</code> — le partage apparaît dans Datacenter > Stockage et Proxmox gère le montage à <code>/mnt/pve/<id></code>; <strong>(2) Montage fstab sur l’hôte</strong> sur un chemin que vous choisissez — persistant via <code>/etc/fstab</code>, NON visible comme stockage Proxmox, idéal pour le montage au niveau des conteneurs LXC (l'UI Proxmox reste propre). Vous pouvez exécuter une méthode, l'autre, ou les deux."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Mount NFS Share on Host</strong>. Le sous-menu comporte quatre options :",
|
||||
"imageAlt": "Menu NFS Host Manager — Monter / Afficher / Supprimer / Tester la connectivité"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le flux a deux phases avec une séparation claire entre \"découvrir, valider et choisir\" et \"en fait monter / écrire config\". Après avoir sélectionné une exportation, vous choisissez les méthodes de montage via une liste de contrôle; le reste des dialogues ne demandent que des paramètres pour les méthodes que vous avez sélectionnées. Jusqu'à la confirmation finale, ni <code>/etc/pve/storage.cfg</code> ni <code>/etc/fstab</code> ne sont touchés."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Choix de la méthode de montage (une ou deux options)",
|
||||
"intro": "Après avoir sélectionné et validé l'exportation, ProxMenux affiche une liste de contrôle avec les deux méthodes de montage. Vous pouvez marquer l'un ou l'autre, ou les deux. Si vous appuyez sur OK sans marquer quoi que ce soit, la boîte de dialogue réapparaît jusqu'à ce que vous choisissiez au moins une option ou appuyez sur Annuler pour quitter le flux.",
|
||||
"imageAlt": "Liste de contrôle des méthodes de montage avec options pvesm et fstab",
|
||||
"headerMethod": "Méthode",
|
||||
"headerMount": "Chemin de montage",
|
||||
"headerUi": "Visible dans Datacenter > Stockage",
|
||||
"headerUseCase": "Cas d'utilisation typique",
|
||||
"rows": [
|
||||
{
|
||||
"method": "<strong>Comme stockage Proxmox (pvesm)</strong>",
|
||||
"mountRich": "<code>/mnt/pve/<storage-id></code> (géré par Proxmox)",
|
||||
"ui": "Oui",
|
||||
"useCase": "VM images de disque, sauvegardes, ISOs, modèles LXC — tout ce qui doit apparaître dans l'interface utilisateur Proxmox."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Uniquement le fstab de l'hôte</strong>",
|
||||
"mountRich": "<code>/mnt/<path></code> (vous choisissez le chemin)",
|
||||
"ui": "Non",
|
||||
"useCaseRich": "Rendre le partage accessible dans un ou plusieurs LXC par bind mount <em>sans</em> l’enregistrer comme stockage Proxmox. Garde l’interface Datacenter claire."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Les deux</strong>",
|
||||
"mount": "Les deux chemins ci-dessus (deux points de montage du même export NFS)",
|
||||
"ui": "Oui",
|
||||
"useCase": "Intégration à l’interface et chemin stable séparé sur l’hôte avec permissions ouvertes pour les bind mounts LXC."
|
||||
}
|
||||
],
|
||||
"bothTitle": "\"Les deux\" crée deux supports indépendants NFS",
|
||||
"bothBody": "Les deux méthodes sont exécutées séparément : pvesm monte sur <code>/mnt/pve/<id></code> et fstab sur <code>/mnt/<path></code>. Cela fournit un montage géré par Proxmox avec ses options par défaut et un montage hôte séparé pour les bind mounts LXC. Deux points de montage ne garantissent pas deux connexions TCP ; le client NFS peut réutiliser les connexions de transport."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Méthode A — En tant que stockage Proxmox (pvesm)",
|
||||
"intro": "Si <em>Comme stockage Proxmox</em> est marqué, ProxMenux exécute le flux pvesm d'origine:",
|
||||
"items": [
|
||||
"<strong>Storage ID</strong> — ce que Proxmox appellera ce stockage. La valeur par défaut est <code>nfs-<server-ip-with-dashes></code>. Seules les lettres, chiffres, <code>-</code> et <code>_</code> sont acceptés.",
|
||||
"<strong>Types de contenu</strong> — Proxmox relie les catégories de contenu aux volumes de stockage; choisissez ce que ce NFS peut contenir:"
|
||||
],
|
||||
"headerType": "Type de contenu",
|
||||
"headerAllows": "Ce qu'il permet",
|
||||
"rows": [
|
||||
{
|
||||
"type": "import",
|
||||
"allowsRich": "Importations d'images de disque (sélectionnées par défaut). Nécessaire pour <em>Importer l'image disque vers VM</em>."
|
||||
},
|
||||
{
|
||||
"type": "backup",
|
||||
"allowsRich": "Fichiers de sauvegarde VM et CT (<code>vzdump</code>)."
|
||||
},
|
||||
{
|
||||
"type": "iso",
|
||||
"allows": "Installation des images ISO."
|
||||
},
|
||||
{
|
||||
"type": "vztmpl",
|
||||
"allows": "Modèles LXC."
|
||||
},
|
||||
{
|
||||
"type": "images",
|
||||
"allows": "Images disque des VM en cours d’utilisation (ce NFS sert alors au stockage des disques VM)."
|
||||
},
|
||||
{
|
||||
"type": "rootdir",
|
||||
"allows": "Systèmes de fichiers racine LXC (rare pour NFS – lire la note ci-dessous)."
|
||||
},
|
||||
{
|
||||
"type": "snippets",
|
||||
"allows": "Scripts de hook et snippets cloud-init."
|
||||
}
|
||||
],
|
||||
"warnTitle": "images et rootdir sur NFS",
|
||||
"warnBody": "Sélectionner <code>images</code> permet de stocker les disques VM sur NFS. Les performances dépendent du réseau, du serveur et de la charge ; une panne peut bloquer les E/S dépendant du montage. <code>rootdir</code> place les systèmes de fichiers racine LXC sur NFS, où les conteneurs non privilégiés peuvent rencontrer des limites de mappage UID, d’overlay et de propriété. Évaluez ces besoins avant d’y placer <code>images</code> / <code>rootdir</code> ; NFS convient aussi à <code>backup</code> / <code>iso</code> / <code>vztmpl</code>.",
|
||||
"result": "Le résultat est <code>pvesm add nfs <id> --server <srv> --export <path> --content <csv></code> et Proxmox se monte automatiquement à <code>/mnt/pve/<id></code>."
|
||||
},
|
||||
"fstabBranch": {
|
||||
"heading": "Méthode B — Montage fstab de l'hôte uniquement",
|
||||
"intro": "Si <em>En tant que montage hôte fstab seulement</em> est marqué, ProxMenux demande un chemin de montage hôte et des options persistantes, puis monte et écrit l'entrée à <code>/etc/fstab</code>:",
|
||||
"items": [
|
||||
"<strong>Chemin de montage sur l’hôte</strong> — par défaut <code>/mnt/<export-basename></code>. Ça doit être un chemin absolu. Si quelque chose y est déjà monté, ou si une entrée fstab existe pour le même chemin, ProxMenux vous avertit et vous propose de la remplacer.",
|
||||
"<strong>Options de montage</strong> — <em>Lecture/écriture</em> (par défaut: <code>rw,hard,nofail,_netdev,rsize=131072,wsize=131072,timeo=600,retrans=2</code>), <em>Lecture seule</em>, <em>Personnalisé</em> (saisissez vos propres options)."
|
||||
],
|
||||
"appliesIntro": "Une fois que vous avez confirmé, le script :",
|
||||
"applies": [
|
||||
"<code>mkdir -p</code> le chemin de montage.",
|
||||
"<code>mount -t nfs -o <opts> <srv>:<export> <path></code>.",
|
||||
"Écrit une entrée d'une ligne à <code>/etc/fstab</code>: <code><srv>:<export> <path> nfs <opts> 0 0</code>.",
|
||||
"Exécute <code>systemctl daemon-reload</code> donc systemd prend la nouvelle entrée fstab.",
|
||||
"Tente <code>chmod 1777</code> et <code>setfacl o::rwx</code> sur le point de montage, sans signaler l’échec éventuel. Ne réussit que si le serveur NFS le permet ; beaucoup d’exports NAS permettent déjà l’écriture à tous les utilisateurs."
|
||||
],
|
||||
"lxcTitle": "Utilisation du montage fstab d'un LXC",
|
||||
"lxcBody": "Le script affiche une commande <code>pct set</code> pour un bind mount, par exemple <code>pct set <ctid> -mp0 /mnt/<path>,mp=/mnt/<ct-path>,shared=1,backup=0</code>. Vous pouvez aussi utiliser le <mountLink>LXC Mount Manager</mountLink>, qui détecte les montages fstab. <strong>Rien n’est modifié dans le conteneur</strong>. L’accès depuis un CT non privilégié dépend des permissions serveur pour ses UID/GID mappés. Le script tente seulement des changements de permissions depuis l’hôte ; il ne garantit ni export accessible en écriture ni réglages par défaut des fabricants. En cas d’échec, consultez Dépannage.",
|
||||
"noUiTitle": "Le montage fstab n'est PAS un stockage Proxmox",
|
||||
"noUiBody": "Le support fstab hôte est invisible à l'interface web Proxmox — par conception. Il n'apparaît pas dans <em>Datacenter > Storage</em>, vous ne pouvez pas le sélectionner dans le créateur VM / CT et les tâches de sauvegarde Proxmox ne peuvent pas le cibler. C'est simplement un chemin du système de fichiers hôte. Si vous voulez aussi intégrer l'interface utilisateur, marquez les méthodes <em>les deux</em> dans le sélecteur."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"pvesmIntro": "Méthode A (pvesm) :",
|
||||
"fstabIntro": "Méthode B (fstab) :"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Affichage configuré NFS stockages",
|
||||
"body": "Liste toutes les entrées NFS dans Proxmox (<code>pvesm status | awk ''$2 == \"nfs\"''</code>) avec serveur, exportation, types de contenu, chemin de montage et statut en direct. <strong>Note:</strong> cette vue affiche uniquement les stockages enregistrés par pvesm — les montages uniquement par fstab ne sont pas listés ici. Vérifiez ceux avec <code>findmnt -t nfs</code> ou <code>grep nfs /etc/fstab</code>."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Supprimer le stockage NFS",
|
||||
"body": "Exécute <code>pvesm remove <storage-id></code> après une confirmation qui affiche le serveur / export / contenu. Seul l'enregistrement côté Proxmox est supprimé — <strong>le serveur NFS distant lui-même n'est jamais touché</strong>, aucun fichier n'est supprimé. Pour supprimer un montage uniquement fstab, modifiez <code>/etc/fstab</code> à la main et exécutez <code>umount <path></code>.",
|
||||
"warnTitle": "Sauvegarder les dépendances d'abord",
|
||||
"warnBody": "Si les VM, les CT ou les tâches de sauvegarde renvoient encore à ce stockage (par ID), l'enlever les laisse pointer vers un magasin disparu. Proxmox va signaler l'erreur mais pas nettoyer. Déplacez ou supprimez ces références d'abord, puis supprimez le stockage."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Tester la connectivité NFS",
|
||||
"body": "Exécute une passe diagnostique sur chaque stockage NFS enregistré dans Proxmox : vérifie que <code>showmount</code> est disponible, que <code>rpcbind</code> est en cours d'exécution, pinge chaque serveur, sonde le port 2049, appelle <code>showmount -e</code>, et enfin rapporte la propre vue de Proxmox (<code>pvesm status</code>). Bon premier arrêt quand un stockage affiche comme <em>inactive</em> dans l'interface utilisateur Proxmox."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noServersTitle": "\"Aucun serveur NFS trouvé sur le réseau\"",
|
||||
"noServersBody": "Auto-découverte utilise <code>nmap -p 2049 --open <subnet>/24</code>. Le serveur peut ne pas répondre si : il est sur un sous-réseau VLAN /, ses pare-feu bloquent les sondes nmap (beaucoup font) ou le port 2049 est intentionnellement fermé sur cette interface. Utilisez l'option <em>Manual</em> avec l'IP ou le nom d'hôte du serveur.",
|
||||
"portTitle": "« Le port NFS (2049) est inaccessible »",
|
||||
"portBody": "Ping a réussi, mais <code>nc -z -w 3 <server> 2049</code> a échoué. Vérifiez que le service NFS fonctionne sur le serveur (<code>systemctl status nfs-server</code> sous Linux, Panneau de configuration → Services de fichiers sur Synology, plugin NFS sur OMV / TrueNAS), et que le pare-feu permet 2049 depuis l'hôte Proxmox.",
|
||||
"showmountTitle": "« Impossible de se connecter » depuis showmount",
|
||||
"showmountBody": "Le serveur a refusé la requête de la liste d'exportation. Causes communes : le serveur fait respecter les CLA du client (votre IP Proxmox n'est pas sur la liste autorisée), <code>rpcbind</code> ne fonctionne pas sur le serveur, ou le serveur n'expose que NFSv4 avec <code>showmount</code> désactivé. Le chemin d'exportation peut encore être ajouté manuellement si vous le connaissez.",
|
||||
"inactiveTitle": "Le stockage est inactif dans l'UI Proxmox",
|
||||
"inactiveBody": "Lancez d’abord <em>Tester la connectivité NFS</em> : il vérifie que le serveur répond au ping, que le port 2049 est ouvert et que la liste des exports (<code>showmount -e</code>) est disponible. Si la connexion fonctionne mais que le stockage reste inactif, consultez <code>journalctl -u pvestatd</code> et la configuration serveur/export. Rétablissez d’abord connexion ou permissions. <code>pvesm set <id> --disable 0</code> active un stockage désactivé ; ce n’est pas une réparation générale de NFS.",
|
||||
"lxcNoWriteTitle": "Le montage fstab fonctionne mais le LXC non privilégié ne peut pas écrire à travers un montage de liaison",
|
||||
"lxcNoWriteBody": "L’accès NFS dépend des propriétaires, ACL et réglages de squash du serveur. Les options CIFS <code>uid=</code> et <code>file_mode=</code> ne s’appliquent <strong>pas</strong> à NFS. Avec le mappage LXC par défaut, root dans le CT devient l’UID 100000 de l’hôte, pas l’UID distant 0. Autorisez l’UID/GID réellement mappé ou l’identité anonyme du serveur. <code>no_root_squash</code> concerne seulement l’UID distant 0 et ne résout pas tous les cas d’UID 100000. Le script tente <code>chmod 1777</code> sans pouvoir contourner les permissions serveur.",
|
||||
"fstabBootTitle": "fstab mount ne vient pas après le redémarrage",
|
||||
"fstabBootBody": "Le script ajoute <code>nofail,_netdev</code> de sorte qu'une part manquante au démarrage ne bloque pas le démarrage. Si le montage n'arrive jamais : confirmez que le réseau est accessible (<code>ping <server></code>), vérifiez <code>journalctl -u remote-fs.target</code>, et vérifiez que l'entrée est valide avec <code>mount -fav | grep nfs</code>. <code>mount -a</code> après le démarrage monte tout ce qui manque actuellement."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS comme stockage Proxmox",
|
||||
"tail": "— même schéma de flux (méthode A pvesm + méthode B fstab) pour les partages SMB/CIFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Gestionnaire de montage LXC",
|
||||
"tailRich": "— lier le chemin <code>/mnt/<path></code> dans un ou plusieurs conteneurs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "Client NFS dans LXC",
|
||||
"tail": "— alternative: monter NFS directement de l'intérieur d'un conteneur privilégié (sans passer par l’hôte)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,172 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hôte : monter un partage Samba | Documentation ProxMenux",
|
||||
"description": "Monter un partage externe de Samba / CIFS sur l'hôte Proxmox — soit sous forme de stockage Proxmox (pvesm add cifs), soit sous forme de montage fstab d'hôte uni avec uid/gid/file_mode ouvert (NON visible dans Datacenter > Storage), ou les deux. La méthode fstab ouvre les permissions afin qu'un montage non privilégié LXC liant le chemin puisse lire/écrire sans aucun changement à l'intérieur du conteneur.",
|
||||
"ogTitle": "Hôte : monter un partage Samba | Documentation ProxMenux",
|
||||
"ogDescription": "Montez un partage Samba / CIFS externe sur l’hôte Proxmox via pvesm, fstab avec permissions ouvertes pour les bind mounts LXC, ou les deux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Hôte : monter un partage Samba sur l’hôte",
|
||||
"description": "Monter un partage externe de Samba (SMB / CIFS) — depuis un NAS, une boîte Windows, une exportation de TrueNAS SMB — sur l'hôte Proxmox. Choisissez une ou les deux méthodes : enregistrez-la en tant que stockage Proxmox (visible dans Datacenter > Storage) et/ou ajoutez un montage simple /etc/fstab sur un chemin que vous choisissez, avec ouvert uid/gid/file_mode afin que les LXC non privilégiés puissent fixer et écrire sans aucun changement à l'intérieur du conteneur.",
|
||||
"section": "Stockage et partage · Hôte"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "ProxMenux propose deux méthodes pour un partage Samba : <strong>(1) Stockage Proxmox</strong> via <code>pvesm add cifs</code>, visible dans Datacenter > Storage et monté sur <code>/mnt/pve/<id></code>. Le mot de passe est conservé en clair dans <code>/etc/pve/priv/storage/<id>.pw</code>, protégé par le répertoire privé accessible uniquement à root : il s’agit d’un contrôle d’accès, pas d’un chiffrement. <strong>(2) Montage fstab de l’hôte</strong> à un chemin choisi, persistant via <code>/etc/fstab</code> avec <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> pour permettre l’écriture depuis les montages liés des LXC non privilégiés. Les identifiants se trouvent dans un fichier réservé à root sous <code>/etc/samba/credentials/</code>, jamais directement dans <code>fstab</code>. Vous pouvez utiliser l’une des méthodes ou les deux."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Mount Samba Share on Host</strong>. Le sous-menu comporte quatre options :",
|
||||
"imageAlt": "Menu Samba Host Manager — Monter / Afficher / Supprimer / Tester la connectivité"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script",
|
||||
"body": "Le flux a deux phases. Phase 1: découvrez le serveur, validez les identifiants, choisissez le partage, puis choisissez les méthodes de montage via une liste de contrôle. Phase 2 : seules les méthodes que vous avez marquées sont exécutées. Les identifiants sont nécessaires dès le départ parce que <code>smbclient</code> a besoin de ceux-ci pour lister les partages. Jusqu'à la confirmation finale, ni <code>/etc/pve/storage.cfg</code> ni <code>/etc/fstab</code> ne sont touchés."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Choix de la méthode de montage (une ou deux options)",
|
||||
"intro": "Après avoir sélectionné le partage et validé les identifiants, ProxMenux affiche une liste de contrôle avec les deux méthodes de montage. Vous pouvez marquer l'un ou l'autre, ou les deux. Si vous appuyez sur OK sans marquer quoi que ce soit, la boîte de dialogue réapparaît jusqu'à ce que vous choisissiez au moins une option ou appuyez sur Annuler pour quitter le flux.",
|
||||
"headerMethod": "Méthode",
|
||||
"headerMount": "Chemin de montage",
|
||||
"headerUi": "Visible dans Datacenter > Stockage",
|
||||
"headerUseCase": "Cas d'utilisation typique",
|
||||
"rows": [
|
||||
{
|
||||
"method": "<strong>Comme stockage Proxmox (pvesm)</strong>",
|
||||
"mountRich": "<code>/mnt/pve/<storage-id></code> (géré par Proxmox)",
|
||||
"ui": "Oui",
|
||||
"useCase": "Sauvegardes, ISOs, modèles LXC — tout ce qui doit apparaître dans l'interface utilisateur Proxmox. Les disques en direct VM sont techniquement pris en charge mais découragés sur CIFS (blocage sémantique)."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Uniquement le fstab de l'hôte</strong>",
|
||||
"mountRich": "<code>/mnt/<path></code> avec uid/gid/file_mode ouverts",
|
||||
"ui": "Non",
|
||||
"useCaseRich": "Montez le partage dans des LXC par bind mount <em>sans</em> enregistrer de stockage Proxmox. Les permissions locales ouvertes facilitent l’accès des CT non privilégiés, mais le serveur SMB doit toujours autoriser l’utilisateur authentifié à écrire."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Les deux</strong>",
|
||||
"mount": "Les deux chemins ci-dessus (deux points de montage du même export CIFS)",
|
||||
"ui": "Oui",
|
||||
"useCase": "Vous voulez l'intégration de l'interface utilisateur ET un chemin stable côté hôte avec des permissions ouvertes pour les montants de liaison LXC. Le montage pvesm utilise les valeurs par défaut de Proxmox; le montage fstab applique séparément l'uid/gid/file_mode."
|
||||
}
|
||||
],
|
||||
"bothTitle": "« Les deux » crée deux points de montage CIFS",
|
||||
"bothBody": "pvesm monte sur <code>/mnt/pve/<id></code> avec les options Proxmox par défaut. fstab monte sur <code>/mnt/<path></code> avec <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> pour l’accès local par bind mounts LXC. Le serveur SMB applique toujours les permissions de l’utilisateur du montage. Deux points de montage ne garantissent pas deux connexions TCP distinctes."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Méthode A — En tant que stockage Proxmox (pvesm)",
|
||||
"intro": "Si <em>Comme stockage Proxmox</em> est marqué, ProxMenux exécute le flux pvesm d'origine:",
|
||||
"items": [
|
||||
"<strong>Storage ID</strong> — par défaut <code>cifs-<server-ip-with-dashes></code>. Seulement lettres, chiffres, <code>-</code> et <code>_</code>.",
|
||||
"<strong>Types de contenu</strong> — ce sélecteur ProxMenux propose <strong>6</strong> choix. Il omet <code>rootdir</code> par rapport à NFS ; c’est un choix du script, pas une interdiction des systèmes de fichiers racine LXC dans toutes les versions du backend CIFS Proxmox :"
|
||||
],
|
||||
"headerType": "Type de contenu",
|
||||
"headerAllows": "Ce qu'il permet",
|
||||
"rows": [
|
||||
{
|
||||
"type": "import",
|
||||
"allows": "Importations d'images de disque (sélectionnées par défaut)."
|
||||
},
|
||||
{
|
||||
"type": "backup",
|
||||
"allowsRich": "Fichiers de sauvegarde VM et CT (<code>vzdump</code>)."
|
||||
},
|
||||
{
|
||||
"type": "iso",
|
||||
"allows": "Installation des images ISO."
|
||||
},
|
||||
{
|
||||
"type": "vztmpl",
|
||||
"allows": "Modèles LXC."
|
||||
},
|
||||
{
|
||||
"type": "images",
|
||||
"allowsRich": "Images disque des VM en cours d’utilisation — <strong>avertissement dans le dialogue</strong>, voir ci-dessous."
|
||||
},
|
||||
{
|
||||
"type": "snippets",
|
||||
"allows": "Scripts de hook et snippets cloud-init."
|
||||
}
|
||||
],
|
||||
"warnTitle": "Live VM disques sur CIFS",
|
||||
"warnBody": "Sélectionner <code>images</code> déclenche un avertissement ProxMenux : CIFS/SMB peut poser des problèmes de verrouillage lors des opérations sur disques VM. Le script recommande NFS mais permet de continuer. Sauvegardes et ISO sont des usages courants de CIFS. Évaluez verrouillage, instantanés, migration et charge avant d’utiliser CIFS pour <code>images</code>.",
|
||||
"credsTitle": "Où pvesm stocke les identifiants",
|
||||
"credsBody": "Le mot de passe n’est pas écrit dans <code>/etc/pve/storage.cfg</code>. Proxmox écrit les identifiants en clair dans <code>/etc/pve/priv/storage/<storage-id>.pw</code>, dans la zone privée du système de fichiers du cluster, lisible uniquement par <code>root</code> (mode <code>0600</code>) ; ils sont protégés par les droits d’accès, pas par un chiffrement. Après un changement de mot de passe serveur, utilisez <code>pvesm set <id> --password <new></code> ou supprimez puis ajoutez le stockage via ProxMenux."
|
||||
},
|
||||
"fstabBranch": {
|
||||
"heading": "Méthode B — Montage fstab de l'hôte uniquement",
|
||||
"intro": "Si <em>Montage fstab sur l’hôte uniquement</em> est sélectionné, ProxMenux demande le chemin et les options persistantes, crée un fichier d’identifiants réservé à root en mode utilisateur, puis monte le partage et écrit l’entrée dans <code>/etc/fstab</code> :",
|
||||
"items": [
|
||||
"<strong>Chemin de montage sur l’hôte</strong> — par défaut <code>/mnt/<share-name></code>. Ça doit être un chemin absolu. Si quelque chose y est déjà monté, ou si une entrée fstab existe, ProxMenux propose de la remplacer.",
|
||||
"<strong>Options de montage</strong> — <em>Lecture/écriture</em> (par défaut: <code>rw,uid=0,gid=0,file_mode=0777,dir_mode=0777,iocharset=utf8,nofail,_netdev</code>), <em>Lecture seule</em> (<code>file_mode=0555,dir_mode=0555</code>), <em>Personnalisé</em> (saisissez vos options). Le script recommande des uid/gid/file_mode ouverts pour les écritures via bind mounts LXC."
|
||||
],
|
||||
"credsTitle": "Fichier d’identifiants (mode utilisateur)",
|
||||
"credsBody": "En mode utilisateur, ProxMenux crée un fichier d’identifiants réservé à root dans <code>/etc/samba/credentials/<server>_<share>.cred</code> (mode <code>0600</code>) avec des lignes <code>username=</code> et <code>password=</code>. L’entrée fstab le référence par l’option <code>credentials=</code> : le mot de passe en clair ne figure pas dans <code>/etc/fstab</code>. En mode invité, l’option <code>guest</code> remplace ce fichier, qui n’est pas créé.",
|
||||
"appliesIntro": "Une fois que vous avez confirmé, le script :",
|
||||
"applies": [
|
||||
"<code>mkdir -p</code> le chemin de montage.",
|
||||
"<code>mount -t cifs -o <opts>,credentials=<file></code> (ou <code>guest</code>) <code>//<srv>/<share> <path></code>.",
|
||||
"Écrit une entrée d'une ligne à <code>/etc/fstab</code>: <code>//<srv>/<share> <path> cifs <opts> 0 0</code>.",
|
||||
"Exécute <code>systemctl daemon-reload</code> donc systemd prend la nouvelle entrée fstab."
|
||||
],
|
||||
"lxcTitle": "Utilisation du montage fstab d'un LXC non privilégié",
|
||||
"lxcBody": "Les options CIFS <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> ouvrent les permissions locales pour les bind mounts LXC. Les ACL serveur et la sémantique Unix/POSIX négociée peuvent encore limiter l’accès. <strong>Rien n’est modifié dans le conteneur</strong> : ni <code>chown</code> dans le CT, ni groupes, ni édition de <code>/etc/lxc</code>. La ligne <code>mp</code> est gérée dans la configuration Proxmox du CT. Utilisez la commande <code>pct set</code> affichée ou le <mountLink>LXC Mount Manager</mountLink>.",
|
||||
"noUiTitle": "Le montage fstab n'est PAS un stockage Proxmox",
|
||||
"noUiBody": "Le support fstab hôte est invisible à l'interface web Proxmox — par conception. Il n'apparaît pas dans <em>Datacenter > Storage</em>, vous ne pouvez pas le sélectionner dans le créateur VM / CT et les tâches de sauvegarde Proxmox ne peuvent pas le cibler. C'est simplement un chemin du système de fichiers hôte. Si vous voulez aussi intégrer l'interface utilisateur, marquez les méthodes <em>les deux</em> dans le sélecteur."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"pvesmIntro": "Méthode A (pvesm) :",
|
||||
"fstabUserIntro": "Méthode B (fstab, auth utilisateur) — fichier d'identification + montage:",
|
||||
"fstabGuestIntro": "Méthode B (fstab, guest auth) — pas de dossier d'identification:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Voir les stockages CIFS et montages de l’hôte",
|
||||
"body": "Affiche les stockages CIFS enregistrés (<code>pvesm status | awk ''$2 == \"cifs\"''</code>) avec serveur, partage, contenu, utilisateur ou <em>Invité</em>, chemin et état. Les mots de passe ne sont <strong>jamais affichés</strong>. <strong>Note :</strong> une seconde section liste les montages fstab de l’hôte, leurs options, le chemin du fichier d’identifiants et leur état actif/inactif. Vérification manuelle avec <code>findmnt -t cifs</code> ou <code>grep cifs /etc/fstab</code>."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Supprimer un stockage CIFS ou un montage hôte",
|
||||
"body": "Le sélecteur propose les stockages pvesm et les montages fstab de l’hôte. Pour pvesm, il exécute <code>pvesm remove <storage-id></code> et Proxmox retire les identifiants associés. Pour fstab, il tente <code>umount <path></code>, retire l’entrée de <code>/etc/fstab</code> et les identifiants sous <code>/etc/samba/credentials/</code>, puis le répertoire vide si possible. Un échec du démontage exige un démontage manuel ou un redémarrage. <strong>Le serveur Samba distant et ses fichiers restent inchangés</strong>.",
|
||||
"warnTitle": "Sauvegarder les dépendances d'abord",
|
||||
"warnBody": "VMs, CTs ou tâches de sauvegarde qui renvoient à ce stockage par ID échoueront après la suppression. Déplacer / laisser tomber ces références avant de supprimer le stockage."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Tester la connectivité Samba",
|
||||
"body": "Diagnostic de chaque stockage CIFS enregistré dans Proxmox : vérifie la présence de <code>smbclient</code>, teste ping et les ports 445/139, tente de lister les partages en invité et affiche l’état selon Proxmox (<code>pvesm status</code>). « Authentification requise » lors du test invité signifie que le serveur réserve les partages aux utilisateurs authentifiés, ce qui est normal pour la plupart des NAS."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noServersTitle": "\"Aucun serveur Samba trouvé sur le réseau\"",
|
||||
"noServersBody": "Auto-découverte utilise <code>nmap -p 139,445</code>. Le serveur peut être sur un sous-réseau différent, pare-feu, ou seulement accessible par hostname (mDNS / WINS). Utilisez l'option <em>Manual</em> avec l'IP ou le nom d'hôte à la place.",
|
||||
"noSharesTitle": "« Aucun partage accessible trouvé »",
|
||||
"noSharesBody": "<code>smbclient -L</code> n'a rien retourné pour ces références. Causes : l'utilisateur n'a pas la permission de lister des partages (essayez avec les identifiants d'administrateur une fois, ou entrez le nom du partage manuellement), le serveur a désactivé la visibilité du partage, ou les identifiants sont erronés. Le script vous permet de saisir le nom du partage à la main dans ce cas.",
|
||||
"denyTitle": "Le montage Proxmox échoue avec NT_STATUS_ACCESS_DENIED",
|
||||
"denyBody": "Les identifiants pvesm stockés sont hors de synchronisation avec le serveur Samba (mot de passe modifié, compte désactivé, domaine / groupe de travail incorrect). Rentrer les identifiants avec <code>pvesm set <id> --username <u> --password <p></code> ou supprimer et réajouter de ProxMenux. Si le serveur est dans un domaine AD, ajoutez <code>--domain <DOMAIN></code> à l'appel <code>pvesm set</code>.",
|
||||
"sleepTitle": "\"l'hôte est en panne\" ou le statut de stockage est inactif la nuit",
|
||||
"sleepBody": "Certains appareils NAS mettent SMB à dormir agressivement. <code>pvestatd</code> voit alors le stockage comme inactif jusqu'à ce que le premier accès réveille le NAS. Si c'est cosmétique, rien n'est cassé. Si cela provoque des défaillances de sauvegarde, désactivez la déconnexion au ralenti de SMB sur le NAS ou planifiez des sauvegardes à l'extérieur de la fenêtre de veille.",
|
||||
"lxcNoWriteTitle": "Le bind mount du LXC non privilégié ne permet pas d’écrire dans le chemin fstab",
|
||||
"lxcNoWriteBody": "Vérifiez les options voulues avec <code>findmnt /mnt/<path></code>, par exemple <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>. Des permissions locales insuffisantes peuvent bloquer les UID LXC mappés. Réappliquez le profil RW ou adaptez les options personnalisées. Vérifiez aussi les droits serveur de l’utilisateur SMB et si les extensions Unix/POSIX fournissent les modes serveur ; les modes locaux ouverts ne contournent pas les ACL serveur.",
|
||||
"fstabBootTitle": "fstab mount ne vient pas après le redémarrage",
|
||||
"fstabBootBody": "Le script ajoute <code>nofail,_netdev</code> de sorte qu'un partage manquant au démarrage ne bloque pas le démarrage. Si le montage n'arrive jamais : confirmez que le réseau est accessible (<code>ping <server></code>), vérifiez <code>journalctl -u remote-fs.target</code>, vérifiez que le fichier d'identification existe toujours (<code>ls -l /etc/samba/credentials/</code>) et est lisible, et essayez <code>mount -a</code> manuellement."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "Partage NFS comme stockage Proxmox",
|
||||
"tail": "— page soeur avec le même schéma de flux (méthode A pvesm + méthode B fstab) et compromis côte à côte."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Gestionnaire de montage LXC",
|
||||
"tailRich": "— lier le chemin <code>/mnt/<path></code> dans un ou plusieurs conteneurs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Client Samba en LXC",
|
||||
"tail": "— alternative: monter Samba directement de l'intérieur d'un conteneur privilégié (sans passer par l’hôte)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,135 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "NFS, Samba, iSCSI et points de montage LXC dans Proxmox — Stockage et partage | ProxMenux",
|
||||
"description": "Intégrez le stockage externe et local dans Proxmox VE et partagez des dossiers entre l’hôte et les conteneurs LXC. Ajoutez des partages NFS, Samba (CIFS) et des cibles iSCSI comme stockage Proxmox, configurez les bind mounts LXC avec Mount Manager et exécutez des clients et serveurs NFS ou Samba dans les conteneurs.",
|
||||
"ogTitle": "Proxmox NFS, Samba, iSCSI et LXC Points de montage — Stockage et partage",
|
||||
"ogDescription": "Intégrez le stockage externe / local dans Proxmox VE — NFS, Samba, enregistrement iSCSI plus les bind mounts LXC et le partage de réseau.",
|
||||
"twitterTitle": "Proxmox NFS, Samba, iSCSI | ProxMenux",
|
||||
"twitterDescription": "Ajouter NFS / Samba / iSCSI comme stockage Proxmox et partager des dossiers entre hôte et LXC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Gestionnaire de stockage et de partage",
|
||||
"description": "Intégrez le stockage externe ou local dans Proxmox VE et partagez des dossiers entre l’hôte et les conteneurs LXC. Trois groupes d’outils : intégration du stockage de l’hôte (enregistrement dans Proxmox), LXC Mount Manager (bind mounts avec gestion pratique des permissions) et partage réseau LXC (procédures client et serveur NFS ou Samba pour des besoins précis).",
|
||||
"section": "Stockage et partage"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce menu sert à",
|
||||
"body": "Le gestionnaire de disques agit au niveau des <em>disques physiques individuels</em>. Storage & Share Manager agit au niveau supérieur : il <strong>enregistre les pools de stockage et les partages réseau dans Proxmox</strong> (pour que l’interface et l’outil de création de VM puissent les utiliser) et <strong>configure le partage de fichiers entre l’hôte et vos conteneurs</strong>."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture du menu",
|
||||
"body": "Dans le menu principal de ProxMenux, sélectionnez <strong>Storage & Share Manager</strong>. Vous verrez ceci :",
|
||||
"imageAlt": "Menu Storage & Share Manager avec blocs HOST et LXC"
|
||||
},
|
||||
"groups": {
|
||||
"heading": "Trois groupes d'outils",
|
||||
"intro": "Le menu se divise en trois groupes. <strong>Intégration du stockage de l’hôte</strong> enregistre le stockage externe ou local dans Proxmox. Le <strong>LXC Mount Manager</strong> est l’outil principal pour partager des dossiers avec les conteneurs : une procédure de bind mount qui gère la correspondance des UID non privilégiés côté hôte. <strong>Partage réseau LXC</strong> couvre quatre scénarios supplémentaires dans lesquels un conteneur doit directement <em>utiliser</em> ou <em>exposer</em> des partages NFS ou Samba.",
|
||||
"hostTitle": "Stockage de l'hôte",
|
||||
"hostBody": "Enregistrer le stockage externe et local dans Proxmox via <code>pvesm add …</code>. Une fois enregistré, le stockage apparaît dans l'interface utilisateur Proxmox et est disponible pour les créateurs VM et CT.",
|
||||
"hostItems": [
|
||||
"NFS / Samba / iSCSI externes → stockage Proxmox",
|
||||
"Disque local → Répertoire Proxmox ou stockage ZFS",
|
||||
"Répertoire local partagé (pour les bind mounts entre CT)"
|
||||
],
|
||||
"lxcMountTitle": "Gestionnaire de montage LXC",
|
||||
"lxcMountBody": "L’outil principal de partage LXC. Il monte les répertoires de l’hôte dans les conteneurs par bind mount via <code>pct set -mpN</code> et gère les particularités des permissions des CT non privilégiés, sans créer de groupe ni d’utilisateur dans le conteneur.",
|
||||
"lxcMountItems": [
|
||||
"Fonctionne avec des CT privilégiés et non privilégiés",
|
||||
"Propose <code>o+rwx</code> sur le répertoire hôte pour les UID non privilégiés",
|
||||
"Correction des montages CIFS / NFS existants si nécessaire"
|
||||
],
|
||||
"lxcNetTitle": "Partage de réseau LXC",
|
||||
"lxcNetBody": "Quatre procédures supplémentaires pour les conteneurs qui doivent utiliser ou exposer directement des partages NFS ou Samba. Toutes exigent un conteneur <strong>privilégié</strong>.",
|
||||
"lxcNetItems": [
|
||||
"<strong>Client</strong> NFS / Samba (utiliser des partages externes)",
|
||||
"NFS / Samba <strong>serveur</strong> (exposer les dossiers CT)"
|
||||
]
|
||||
},
|
||||
"host": {
|
||||
"heading": "Intégration du stockage de l'hôte",
|
||||
"intro": "Enregistrer le stockage dans Proxmox. Chaque option appelle <code>pvesm add …</code> sous le capot, de sorte que le stockage apparaît dans <strong>Datacenter → Storage</strong> et devient disponible pour les créateurs VM / CT.",
|
||||
"options": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"icon": "Network",
|
||||
"title": "Ajouter un partage NFS comme stockage Proxmox",
|
||||
"description": "Enregistrez un export NFS externe comme stockage Proxmox avec pvesm add nfs. Proxmox gère le montage, sans ajout dans fstab."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"icon": "Share2",
|
||||
"title": "Ajouter un partage Samba comme stockage Proxmox",
|
||||
"description": "Enregistrez un partage Samba ou CIFS externe comme stockage Proxmox avec pvesm add cifs. Proxmox gère le montage et les identifiants."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-iscsi",
|
||||
"icon": "Database",
|
||||
"title": "Ajouter la cible iSCSI comme stockage Proxmox",
|
||||
"description": "Connectez-vous à une cible externe iSCSI et enregistrez-la en tant que stockage Proxmox (périphérique bloc) pour les images de disque VM."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"icon": "HardDrive",
|
||||
"title": "Ajouter le disque local comme stockage Proxmox",
|
||||
"description": "Formatez un disque local SATA / SAS / NVMe et enregistrez-le comme stockage de type répertoire ou pool ZFS dans Proxmox."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"icon": "FolderOpen",
|
||||
"title": "Ajouter un répertoire partagé sur Host",
|
||||
"description": "Créer un répertoire hôte destiné à être monté sur plusieurs CT. Pas un stockage Proxmox — purement une ressource côté hôte pour les bind mounts LXC."
|
||||
}
|
||||
]
|
||||
},
|
||||
"lxcMount": {
|
||||
"heading": "Gestionnaire de montage LXC",
|
||||
"intro": "L'outil principal pour le partage des dossiers entre l'hôte Proxmox et les conteneurs LXC. Il utilise <code>pct set -mpN</code> pour relier un répertoire hôte dans le conteneur, et gère les quirks de permission des CT non privilégiés du côté hôte (aucun groupe ou utilisateur ne sont créés à l'intérieur du conteneur).",
|
||||
"card": {
|
||||
"title": "Points de montage LXC (hôte ↔ CT)",
|
||||
"description": "Bind-mount n'importe quel répertoire hôte dans un conteneur LXC via pct set -mpN. Fonctionne avec des CT privilégiés et non privilégiés; offre chmod o+rwx / ACLs sur le répertoire hôte et corrige les montages CIFS / NFS existants au besoin."
|
||||
}
|
||||
},
|
||||
"lxcNet": {
|
||||
"heading": "Partage de réseau LXC",
|
||||
"intro": "Utilisez ces procédures quand le conteneur doit <em>être</em> un point d’accès NFS ou Samba : utiliser un partage externe (client) ou exposer ses propres dossiers (serveur). Pour la plupart des partages de fichiers (bind mounts hôte ↔ CT), le <mountLink>LXC Mount Manager</mountLink> est plus simple et ne nécessite pas de conteneurs privilégiés.",
|
||||
"options": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"icon": "Download",
|
||||
"title": "Client NFS dans LXC",
|
||||
"description": "Montez des partages NFS externes depuis un conteneur LXC privilégié. Détection automatique, persistance dans /etc/fstab et démontages propres pris en charge."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"icon": "Download",
|
||||
"title": "Client Samba en LXC",
|
||||
"description": "Montez des partages Samba / CIFS depuis un conteneur LXC privilégié. Identifiants stockés de manière protégée et détection automatique disponible."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"icon": "Upload",
|
||||
"title": "Serveur NFS dans LXC",
|
||||
"description": "Exporter des dossiers sur NFS à partir d'un conteneur LXC privilégié."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"icon": "Upload",
|
||||
"title": "Serveur Samba en LXC",
|
||||
"description": "Exposer les dossiers sur SMB / CIFS de l'intérieur d'un conteneur privilégié LXC."
|
||||
}
|
||||
]
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Exigences concernant les conteneurs privilégiés",
|
||||
"body": "Les quatre procédures de <strong>partage réseau LXC</strong> ci-dessus exigent un conteneur <strong>privilégié</strong>. Les scripts imposent ce mode pris en charge avant de configurer les services et outils de montage (<code>nfs-kernel-server</code>, <code>smbd</code>, <code>mount.nfs</code>, <code>mount.cifs</code>). Pour partager des fichiers entre l’hôte et un CT non privilégié, utilisez le <mountLink>LXC Mount Manager</mountLink> : il réalise les bind mounts et ajuste les permissions côté hôte pour permettre la lecture et l’écriture sans configurer ces services ou outils dans le conteneur."
|
||||
},
|
||||
"unprivExplain": {
|
||||
"title": "Comment ProxMenux gère les autorisations de CT non privilégiées",
|
||||
"body": "Les conteneurs LXC non privilégiés décalent leurs UID de <strong>+100000</strong> sur l’hôte (UID 0 du conteneur = UID 100000 de l’hôte, UID 1000 du conteneur = UID 101000 de l’hôte, …). Un fichier créé par un utilisateur du conteneur apparaît donc comme appartenant aux <em>autres</em> sur l’hôte, sans utilisateur ni groupe hôte ordinaire correspondant. LXC Mount Manager propose une solution pratique : plutôt que d’aligner les UID/GID entre hôte et CT, il propose <code>chmod o+rwx</code> et les ACL correspondantes sur le répertoire hôte pour que tout UID mappé puisse lire et écrire. Pour CIFS, il remonte avec <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> ; pour NFS, il configure un répertoire accessible en écriture à tous avec sticky bit et, si le serveur applique root squash, indique la correction à effectuer côté serveur."
|
||||
},
|
||||
"scripts": {
|
||||
"heading": "Scripts concernés",
|
||||
"intro": "Chaque page se connecte au script qui conduit son flux. Le fichier ci-dessous est un helper partagé qui n'est pas documenté comme sa propre page mais est utilisé par plusieurs flux de partage de réseau LXC:",
|
||||
"itemTail": "— validation CT, sélection de points de montage, contrôle privilégié et helpers de configuration de groupe universels partagés sur les flux client/serveur LXC."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,174 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Points de montage LXC (hôte ↔ conteneur) | Documentation ProxMenux",
|
||||
"description": "Le gestionnaire de montages LXC rend tout répertoire de l’hôte accessible dans un ou plusieurs conteneurs LXC par bind mount via pct set -mpN. Il gère les particularités des permissions des conteneurs non privilégiés, corrige les montages CIFS / NFS sur l’hôte et ne modifie rien dans le conteneur.",
|
||||
"ogTitle": "Points de montage LXC (hôte ↔ conteneur) | Documentation ProxMenux",
|
||||
"ogDescription": "Montez les répertoires de l’hôte dans les conteneurs LXC par bind mount. Gestion pratique du mappage UID non privilégié et correction des accès CIFS / NFS sur l’hôte."
|
||||
},
|
||||
"header": {
|
||||
"title": "Points de montage LXC (hôte ↔ conteneur)",
|
||||
"description": "L'outil principal pour le partage des dossiers entre l'hôte Proxmox et les conteneurs LXC. Bind-mount n'importe quel répertoire hôte dans un ou plusieurs conteneurs en utilisant la syntaxe native pct set -mpN de Proxmox. Le point fort : il résout les maux de tête d'autorisation des conteneurs non privilégiés du côté hôte – il ne modifie jamais rien à l'intérieur du conteneur.",
|
||||
"section": "Stockage et partage · LXC"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Prenez un répertoire qui vit sur l'hôte Proxmox (un dossier local, un NAS partagé, un stockage géré par Proxmox...) et faites-le apparaître à l'intérieur d'un conteneur LXC sur un chemin que vous choisissez, avec des permissions qui fonctionnent même pour des conteneurs non privilégiés — sans rien toucher à l'intérieur du conteneur."
|
||||
},
|
||||
"bigPicture": {
|
||||
"heading": "Comment ça marche (la grande image)",
|
||||
"intro": "Un bind mount demande au noyau de rendre le répertoire <code>X</code> de l’hôte également accessible au chemin <code>Y</code> du conteneur. Aucune copie, synchronisation ou transmission réseau : les deux côtés voient les <em>mêmes fichiers</em> en même temps.",
|
||||
"sourceLabel": "Hôte Proxmox",
|
||||
"sourceDetail": "/mnt/data\n(votre dossier)",
|
||||
"targetLabel": "Conteneur LXC",
|
||||
"targetDetail": "/mnt/data\n(apparaît ici)",
|
||||
"arrowLabel": "bind mount",
|
||||
"outro": "Le chemin de l'hôte à gauche et le chemin du conteneur à droite peuvent être différents — par exemple, <code>/mnt/nas-films</code> sur l'hôte peut devenir <code>/media/films</code> à l'intérieur du conteneur. Le script ajoute l'entrée à la configuration du conteneur (<code>/etc/pve/lxc/<ctid>.conf</code>) en utilisant le prochain index libre <code>mpN</code>, avec deux paramètres de sécurité par défaut:",
|
||||
"items": [
|
||||
"<code>shared=1</code> — indique à Proxmox que les données sont partagées et ne doivent pas être migrées avec le CT. Ce drapeau ne réplique rien : le même chemin et les mêmes données doivent déjà être disponibles sur le nœud cible.",
|
||||
"<code>backup=0</code> — exclut le montage de liaison des sauvegardes <code>vzdump</code> (les données vivent sur l'hôte, vous les sauvegardez séparément)."
|
||||
]
|
||||
},
|
||||
"perms": {
|
||||
"heading": "Gestion des autorisations — la partie smart",
|
||||
"intro": "Les bind mounts sont faciles en principe. La partie dure est permissions : un conteneur <strong>non privilégié</strong> LXC déplace chaque UID par <strong>+100000</strong>, donc un fichier créé à l'intérieur du conteneur par l'utilisateur 1000 apparaît sur l'hôte sous le nom d'UID 101000 — un UID que personne ne possède sur l'hôte. Pour que cela fonctionne sans aligner les UIDs sur les hôtes et les conteneurs, ProxMenux applique le bon \"ouvrir les permissions\" sur le côté <em>hôte</em>, selon le type de répertoire que vous avez choisi:",
|
||||
"headerType": "Type de répertoire hôte",
|
||||
"headerAction": "Ce que le script offre à faire",
|
||||
"localType": "Dossier local",
|
||||
"localTypeSub": "Par exemple /mnt/data",
|
||||
"localActionRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> dans le répertoire hôte. Seulement offert si le CT n'est pas privilégié et que les autorisations actuelles sont insuffisantes.",
|
||||
"cifsType": "CIFS monté / SMB",
|
||||
"cifsTypeSub": "Par exemple /mnt/pve/cifs-…",
|
||||
"cifsActionRich": "Remonter avec <code>uid=0, gid=0, file_mode=0777, dir_mode=0777</code> afin que le CT (tout UID) puisse lire et écrire le partage. <code>/etc/fstab</code> est mis à jour.",
|
||||
"nfsType": "NFS monté",
|
||||
"nfsTypeSub": "Par exemple /mnt/pve/nfs-…",
|
||||
"nfsActionRich": "<code>chmod 1777</code> + <code>setfacl o::rwx</code> sur le support NFS. Impossible de surcharger le squashing côté serveur — si même l'hôte root ne peut pas écrire, vous êtes guidé pour corriger l'exportation sur le serveur NFS.",
|
||||
"privTitle": "Les conteneurs privilégiés n'ont pas besoin de ça",
|
||||
"privBody": "Pour les conteneurs privilégiés, UID 0 dans le CT est UID 0 sur l'hôte — root à l’intérieur du CT peut lire et écrire le répertoire hôte directement sans aucun tour de permission. Le script détecte cela et saute l'étape \"ouvrir les permissions\" entièrement.",
|
||||
"noCtTitle": "Le script ne modifie jamais rien à l'intérieur du conteneur",
|
||||
"noCtBody": "Toutes les modifications d'autorisation se produisent sur le système de fichiers <strong>host</strong>. Pas de chowns <code>pct exec</code>, pas de groupes créés dans le CT, pas de fstab à l'intérieur du conteneur. Si vous réutilisez le répertoire relié dans un autre CT plus tard, les mêmes permissions s'appliquent automatiquement — pas de configuration par conteneur."
|
||||
},
|
||||
"writes": {
|
||||
"heading": "Ce que ProxMenux écrit — et ce qu'il ne fait pas",
|
||||
"intro": "Une confusion fréquente lors du montage de la liaison dans un CT non privilégié: les gens supposent que ProxMenux doit écrire des entrées <code>lxc.idmap</code> dans <code>/etc/pve/lxc/<CTID>.conf</code>. <strong>Il ne le fait pas.</strong> Une seule ligne est annexée à ce fichier — le montage de liaison lui-même:",
|
||||
"outro": "La ligne de sortie que vous voyez à la fin de l'exécution, <em>\"Conteneur non privilégié — Offset UID: 100000\"</em>, est purement informative — elle vous indique simplement que le CT utilise la cartographie non privilégiée par défaut de Proxmox (root dans CT = UID 100000 sur l'hôte). Le script ne configure rien autour.",
|
||||
"twoWaysHeading": "Les deux façons de faire fonctionner les permissions — et pourquoi ProxMenux en choisit une",
|
||||
"headerApproach": "Approche",
|
||||
"headerChanges": "Ce que ça change",
|
||||
"headerWhen": "Quand ça va",
|
||||
"hostType": "Permissions côté hôte",
|
||||
"hostTypeSub": "(ce que ce script fait)",
|
||||
"hostChangesRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> dans le répertoire hôte. Les UIDs cartographiés du CT (100000+) tombent dans le seau \"autres\", donc ouvrir le <em>autres</em> suffit.",
|
||||
"hostWhen": "Accès à dossier partagé générique depuis n'importe quel CT. Plusieurs CT partageant le même répertoire hôte. Simple et réutilisable.",
|
||||
"idmapTypeRich": "<code>lxc.idmap</code>",
|
||||
"idmapTypeSub": "(non utilisé par ce script)",
|
||||
"idmapChangesRich": "Carte UID/GID personnalisée dans <code>/etc/pve/lxc/<CTID>.conf</code> plus les entrées correspondantes <code>/etc/subuid</code> + <code>/etc/subgid</code> sur l'hôte. Le CT doit être redémarré sur chaque changement.",
|
||||
"idmapWhenRich": "Vous avez besoin d'un UID <em>spécifique</em> à l'intérieur du CT pour cartographier un UID <em>spécifique</em> sur l'hôte (p. ex. <code>media:1000</code> dans le CT doit posséder des fichiers comme <code>media:1000</code> sur l'hôte de sorte que NFS ne squash). Une configuration plus rigide, normalement ne vaut que pour ce scénario exact.",
|
||||
"idmapTipTitle": "Lorsque vous avez réellement besoin de lxc.idmap",
|
||||
"idmapTipBody": "Utilisez le mappage manuel si les fichiers écrits dans le CT doivent avoir un UID/GID numérique précis sur l’hôte, par exemple pour partager le propriétaire avec un utilisateur de l’hôte. Il ne contourne pas <code>all_squash</code> de NFS : le serveur décide toujours de l’identité anonyme et des permissions. Ajoutez au besoin des entrées <code>lxc.idmap</code> manuellement. La ligne de bind mount en est indépendante."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Configure LXC Mount Points (Host ↔ Container)</strong>. Le sous-menu comporte trois options :",
|
||||
"imageAlt": "Menu LXC Mount Manager — Ajouter / Afficher / Supprimer"
|
||||
},
|
||||
"addFlow": {
|
||||
"heading": "Ajouter un montage — procédure complète",
|
||||
"intro": "La vue technique, pour savoir exactement ce que fait chaque boîte de dialogue :"
|
||||
},
|
||||
"sources": {
|
||||
"heading": "Ce que vous pouvez choisir comme répertoire hôte",
|
||||
"intro": "Le sélectionneur de répertoire hôte est le plus complet de la section Stockage & Share. Il scanne quatre sources et présente une liste dédoublée :",
|
||||
"headerSource": "Source",
|
||||
"headerWhere": "D'où ça vient",
|
||||
"headerLabel": "Étiquette dans le menu",
|
||||
"rows": [
|
||||
{
|
||||
"source": "Montages en réseau actifs",
|
||||
"whereRich": "Partages CIFS / NFS actuellement montés, lus dans <code>/proc/mounts</code>.",
|
||||
"labelRich": "<code>NFS [used/size]</code> ou <code>CIFS/SMB [used/size]</code>"
|
||||
},
|
||||
{
|
||||
"source": "Montages fstab inactifs",
|
||||
"whereRich": "Défini dans <code>/etc/fstab</code> mais pas actuellement monté.",
|
||||
"labelRich": "<code>fstab(off)-NFS</code> / <code>fstab(off)-CIFS/SMB</code>"
|
||||
},
|
||||
{
|
||||
"source": "Répertoires locaux",
|
||||
"whereRich": "Les répertoires Sub sous <code>/mnt</code> qui ne sont pas des montages réseau.",
|
||||
"labelRich": "<code>Local [size]</code>"
|
||||
},
|
||||
{
|
||||
"source": "Stockages Proxmox",
|
||||
"whereRich": "Voies de stockage sous <code>/mnt/pve/*</code> (NFS / CIFS enregistrées via <code>pvesm</code>).",
|
||||
"labelRich": "<code>PVE-NFS</code> / <code>PVE-CIFS/SMB</code> / <code>Proxmox-Storage</code>"
|
||||
},
|
||||
{
|
||||
"source": "Entrée manuelle",
|
||||
"where": "N'importe quoi d'autre — tapez le chemin absolu vous-même.",
|
||||
"labelRich": "<em>Saisir le chemin manuellement</em>"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Les chemins internes Proxmox sont filtrés",
|
||||
"tipBody": "Le sélecteur saute explicitement les chemins Proxmox internes (<code>/mnt/pve/local</code>, <code>/mnt/pve/local-lvm</code>, <code>/mnt/pve/backup</code>, ...) — ceux-ci sont réservés aux internes Proxmox et vous ne devriez pas les fixer. Seuls les stockages ajoutés par l'utilisateur apparaissent."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"privIntro": "Pour un conteneur privilégié — le cas le plus simple, pas de tours de permission:",
|
||||
"unprivLocalIntro": "Pour un conteneur non privilégié avec un répertoire d'hôte local — ouvrir les permissions sur l'hôte d'abord:",
|
||||
"unprivCifsIntro": "Pour un conteneur non privilégié avec un partage CIFS déjà montée sur l'hôte:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Afficher les points de montage",
|
||||
"body": "Liste toutes les entrées <code>mpN</code> sur chaque conteneur de cet hôte Proxmox, regroupées par CT id et montrant le chemin hôte → chemin conteneur plus toutes les options supplémentaires. En lecture seule — utile comme vérification de cohérence avant d'ajouter ou de supprimer quoi que ce soit."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Supprimer un point de montage",
|
||||
"body": "Choisissez le contenant, choisissez l'entrée <code>mpN</code>, confirmez. Le script lance <code>pct set --delete mpN</code> pour supprimer l'entrée de la configuration CT et propose de redémarrer le conteneur s'il est en cours d'exécution. Le répertoire hôte et son contenu sont <strong>non touché</strong> — vous pouvez rajouter le montage plus tard (ou attacher le même répertoire à un autre CT).",
|
||||
"warnTitle": "Les conteneurs en cours d’exécution doivent redémarrer pour appliquer les changements",
|
||||
"warnBody": "L'ajout et la suppression de points de montage ne deviennent visibles à l'intérieur du conteneur qu'après un redémarrage. Le script offre un <code>pct reboot</code> en un clic à la fin de chaque opération ; vous pouvez décliner et redémarrer manuellement plus tard."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noMountTitle": "Mont apparaît en pct config mais pas dans le conteneur",
|
||||
"noMountBody": "Les bind mounts ne sont attachés que lorsque le conteneur démarre. Si vous avez ajouté le montage pendant que le CT était en cours d'exécution, redémarrez-le (<code>pct reboot <ctid></code>). Si elle est déjà redémarrée et manquante, vérifiez que <code>pct config <ctid></code> confirme que l'entrée existe et que le chemin hôte contient un répertoire.",
|
||||
"noWriteTitle": "Le conteneur peut voir le répertoire mais ne peut pas écrire",
|
||||
"noWriteBody": "Presque toujours un problème de permissions. Pour les conteneurs non privilégiés, lancez à nouveau la correction de l'autorisation du script — les ACL du répertoire hôte peuvent avoir été réinitialisés par un autre outil (rsync, restauration de sauvegarde, manuel <code>chmod</code>). Pour CIFS, double-vérifiez les options de montage sur l'hôte : <code>findmnt /mnt/pve/cifs-…</code>, recherchez les valeurs <code>uid=</code> / <code>gid=</code> / <code>file_mode=</code>.",
|
||||
"alreadyTitle": "\"Ce chemin est déjà utilisé comme point de montage dans ce conteneur\"",
|
||||
"alreadyBody": "Vous avez choisi le même chemin de conteneur qui est déjà connecté à un autre répertoire hôte. Soit choisir un chemin de conteneur différent, soit enlever le point de montage existant en premier.",
|
||||
"nfsTitle": "L'accès NFS est bloqué même après l'application de la correction hôte",
|
||||
"nfsIntro": "Votre serveur NFS est un squashing root ou toutes les connexions. Le script peut détecter cela (il essaie d'écrire un fichier de test à partir de l'hôte) et affiche des conseils côté serveur. Deux corrections communes côté serveur pour l'exportation:",
|
||||
"nfsItems": [
|
||||
"<code>no_root_squash</code> — les CT privilégiés peuvent écrire directement.",
|
||||
"<code>all_squash,anonuid=65534,anongid=65534</code> — pour les CT non privilégiés."
|
||||
],
|
||||
"nfsOutro": "Ces changements se produisent sur le serveur NFS (TrueNAS, Synology, votre exportation personnalisée, ...), pas sur Proxmox.",
|
||||
"fstabOffTitle": "Le montage des entrées \"fstab(off)\" ne fait rien",
|
||||
"fstabOffBody": "Le sélecteur affiche les entrées <code>fstab(off)-</code> lorsqu'un montage réseau est défini dans fstab mais pas actuellement monté. Le script vous permet de lier le chemin, mais le répertoire sera vide jusqu'à ce que vous montez réellement le partage (<code>mount <path></code> sur l'hôte). Montez-le d'abord, puis liez-le au CT."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"label": "Ajouter un répertoire partagé sur l'hôte",
|
||||
"tailRich": "— première étape typique: préparer un <code>/mnt/shared</code> sur l'hôte avant de le fixer dans un ou plusieurs CTs ici."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "Ajouter un partage NFS comme stockage Proxmox",
|
||||
"extraHref": "/docs/storage-share/host-samba",
|
||||
"extraLabel": "Ajouter un partage Samba comme stockage Proxmox",
|
||||
"joiner": " / ",
|
||||
"tailRich": "— enregistrer d'abord un partage externe dans Proxmox, puis fixer son chemin <code>/mnt/pve/<id></code> dans le CT ici."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "Client NFS dans LXC",
|
||||
"extraHref": "/docs/storage-share/lxc-samba-client",
|
||||
"extraLabel": "Client Samba en LXC",
|
||||
"joiner": " / ",
|
||||
"tail": "— l'alternative lorsque vous voulez que le CT lui-même monte le partage (exige un conteneur privilégié)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "NFS client en LXC | ProxMenux Documentation",
|
||||
"description": "Montez des partages NFS directement dans un conteneur LXC Proxmox avec ProxMenux. Installation automatique de nfs-common, découverte sur le LAN, montages persistants via /etc/fstab et paramètres de démarrage sûrs. Nécessite un conteneur privilégié.",
|
||||
"ogTitle": "NFS client en LXC | ProxMenux Documentation",
|
||||
"ogDescription": "Montez des partages NFS dans un conteneur LXC privilégié. Découverte automatique, persistance dans /etc/fstab et paramètres de démarrage sûrs."
|
||||
},
|
||||
"header": {
|
||||
"title": "Client NFS dans LXC",
|
||||
"description": "Montez des partages NFS directement dans un conteneur LXC Proxmox. Le conteneur devient un véritable client NFS : il communique avec le serveur par le réseau, exécute mount.nfs et écrit dans /etc/fstab. ProxMenux installe nfs-common, aide à trouver les serveurs et exports et applique des paramètres de démarrage sûrs.",
|
||||
"section": "Stockage et partage · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Conteneur privilégié requis",
|
||||
"body": "Le client du noyau <code>mount.nfs</code> a besoin de capacités (<code>SYS_ADMIN</code> au minimum) que les conteneurs non privilégiés LXC n'exposent pas. Le script force cela — il vous demande de choisir un CT et <strong>s’arrête s'il n'est pas privilégié</strong>. Si vous avez besoin du partage à l'intérieur d'un CT non privilégié, montez-la d'abord sur l'hôte Proxmox (avec <hostNfsLink>NFS en tant que stockage Proxmox</hostNfsLink>) et montez-la par bind mount dans le CT avec le <mountLink>LXC Mount Manager</mountLink>."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Ce que ça fait",
|
||||
"body": "Contrairement au gestionnaire de montage LXC — ce qui fait que le CT voit quelque chose <em>via</em> l'hôte Proxmox — ce script donne au conteneur son <strong>propre client NFS</strong>: il parle NFS sur le réseau, monte des partages directement du serveur NFS et stocke le montage dans le <code>/etc/fstab</code> du conteneur. L'hôte Proxmox n'est pas dans le chemin de données.",
|
||||
"diagramServerLabel": "Serveur NFS",
|
||||
"diagramServerDetail": "/export/data",
|
||||
"diagramHostLabel": "Hôte Proxmox",
|
||||
"diagramHostDetail": "(seulement un\npont réseau)",
|
||||
"diagramCtLabel": "LXC (privilégié)",
|
||||
"diagramCtDetail": "/mnt/data\nmount.nfs dans le CT",
|
||||
"diagramArrow": "NFS",
|
||||
"twoWaysTitle": "Deux façons de donner un accès CT NFS — choisissez une",
|
||||
"twoWaysBind": "<strong>Montage par host</strong> (<mountLink>LXC Mount Manager</mountLink>) : l'hôte monte le NFS une fois, chaque CT reçoit le même chemin par bind mount. Fonctionne avec des CT non privilégiés. Recommandé lorsque plusieurs CT ont besoin de le même partage.",
|
||||
"twoWaysDirect": "<strong>Montage NFS direct dans le CT</strong> (cette page) : le CT monte NFS lui-même. Exige un CT privilégié. Utile si le CT doit gérer sa propre connexion et ses identifiants ou si chaque CT utilise un serveur différent."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Configurer le client NFS dans LXC (privilégié uniquement)</strong>. Choisissez d’abord <strong>le CT cible</strong> ; ProxMenux le démarre s’il est arrêté et abandonne s’il n’est pas privilégié. Le sous-menu suivant s’affiche ensuite :",
|
||||
"imageAlt": "Menu NFS Client Manager — Montage / Vue / Démonter / Tester la connectivité"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (mount flow)"
|
||||
},
|
||||
"fstabFlags": {
|
||||
"heading": "Pourquoi ces drapeaux fstab",
|
||||
"intro": "Pour les montages permanents, le script ajoute trois drapeaux au-delà des options standard NFS : <code>_netdev,x-systemd.automount,noauto</code>. Chacun résout un vrai problème de démarrage :",
|
||||
"headerFlag": "Drapeau",
|
||||
"headerEffect": "Ce qu'il fait",
|
||||
"rows": [
|
||||
{
|
||||
"flag": "_netdev",
|
||||
"effect": "Indique au système d’initialisation que ce montage nécessite le réseau. Le démarrage n’attend pas ce montage avant que le réseau soit disponible."
|
||||
},
|
||||
{
|
||||
"flag": "x-systemd.automount",
|
||||
"effectRich": "Crée une unité de montage automatique systemd : le montage n'arrive que la première fois que quelque chose accède à <code>/mnt/<path></code>. Le serveur NFS inaccessible au démarrage ne bloque pas le CT."
|
||||
},
|
||||
{
|
||||
"flag": "noauto",
|
||||
"effect": "Évite le montage immédiat au démarrage. Avec l’unité automount ci-dessus, le montage n’a lieu qu’au premier accès."
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Effet net",
|
||||
"netEffectBody": "Le système de fichiers NFS est monté au <em>premier accès</em> plutôt qu’immédiatement au démarrage. Si le serveur est hors ligne, cet accès peut attendre ou échouer et affecter les services qui dépendent du chemin. Automount réduit la dépendance au démarrage, sans garantir que tous les services du CT restent épargnés."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Répliquez l'ensemble du flux à la main — chaque commande exécute <strong> à l'intérieur du CT</strong> via <code>pct exec <ctid> --</code> ou directement via <code>pct enter <ctid></code>:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Afficher les montages actuels",
|
||||
"body": "Liste tous les points de montage NFS actifs à l'intérieur du CT (<code>mount | grep nfs</code>) plus toutes les lignes NFS du CT du <code>/etc/fstab</code>. Pour chaque entrée fstab, l'état de montage en direct est affiché — utile pour repérer les montages permanents qui ne sont pas apparus au démarrage."
|
||||
},
|
||||
"unmount": {
|
||||
"heading": "Démonter le partage NFS",
|
||||
"body": "Combine les montages live et les entrées fstab dans une seule liste, vous permet d'en choisir une et <strong>supprime la ligne correspondante de <code>/etc/fstab</code></strong>. Le script <em>n'exécute pas</em> <code>umount</code> sur le montage en direct ; à la place, il vous indique qu'un redémarrage CT est nécessaire pour que le démontage prenne effet.",
|
||||
"warnTitle": "Le script supprime les entrées fstab, pas les montages en direct",
|
||||
"warnBody": "C'est un choix de conception délibéré : <code>umount</code> sur une monture occupée échoue avec \"appareil occupé\" quand quelque chose à l'intérieur du CT l'utilise encore. La suppression de l'entrée fstab garantit que le montage disparaît proprement lors du prochain démarrage CT. Si vous voulez que le montage soit parti <em>maintenant</em> et vous êtes sûr que rien ne l'utilise, exécutez <code>pct exec <ctid> -- umount /mnt/<path></code> à la main après la fin du script."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Tester la connectivité NFS",
|
||||
"body": "Pass diagnostique à l'intérieur du CT: confirme que le <code>nfs-common</code> est installé, <code>rpcbind</code> est en cours d'exécution, liste les montages NFS, puis itération sur chaque serveur NFS référencé dans fstab et vérifie ping → port 2049 → <code>showmount -e</code>. Bon premier arrêt quand une monture permanente n'arrive pas."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"privTitle": "Conteneur privilégié requis (le script s’arrête)",
|
||||
"privBody": "Le CT sélectionné n'est pas privilégié. Le client du noyau NFS a besoin de la capacité <code>SYS_ADMIN</code> que les CT non privilégiés n'exposent pas. Soit convertir le CT en privilège (la conversion du gestionnaire de disque & est documentée dans le disque <importLink>Importer en LXC</importLink> page) soit utiliser le chemin alternatif décrit dans l'avertissement en haut de cette page.",
|
||||
"aptTitle": "apt-get install nfs-common fails",
|
||||
"aptIntro": "Le script suppose une famille Debian CT (<code>apt-get</code>). Si le CT tourne Alpine / Arch / Rocky / Alma, l'étape d'installation échoue silencieusement. Installez le client NFS à la main pour cette distribution :",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add nfs-utils</code>",
|
||||
"Arch: <code>pacman -S nfs-utils</code>",
|
||||
"Rocky / Alma: <code>dnf install nfs-utils</code>"
|
||||
],
|
||||
"aptOutro": "Ensuite, lancez le script ProxMenux — l'étape d'installation saute lorsque les outils sont déjà présents.",
|
||||
"portTitle": "\"NFS port (2049) is not accessible\"",
|
||||
"portBody": "Ping a réussi, mais <code>nc -z <server> 2049</code> a échoué de l'intérieur du CT. Vérifiez que le service NFS fonctionne sur le serveur, que le pare-feu permet 2049 à partir du réseau de CT et que le CT a en fait une route réseau valide (essayez <code>pct exec <ctid> -- ip route</code>).",
|
||||
"bootTitle": "Le montage permanent réussit mais ne vient pas au démarrage",
|
||||
"bootBody": "Presque toujours : le réseau n'est pas prêt lorsque le CT monte (les drapeaux du script <code>_netdev,x-systemd.automount,noauto</code> corrigent cela – rajouter le montage via le script si vous avez écrit la ligne fstab à la main sans ces derniers), le serveur est inaccessible au démarrage (le montage automatique attend le premier accès, c'est normal), ou le DNS n'est pas résolu au démarrage (utiliser l'IP du serveur, pas son nom d'hôte).",
|
||||
"squashTitle": "Serveur squashes root, aucun accès d'écriture à partir de l'intérieur CT",
|
||||
"squashIntro": "L'exportation de NFS utilise <code>root_squash</code> (par défaut) et le CT écrit comme racine. Deux options :",
|
||||
"squashItems": [
|
||||
"Côté serveur : changez l'exportation en <code>no_root_squash</code> (seulement si vous faites confiance au CT).",
|
||||
"Côté CT : écrivez avec un utilisateur non root accepté par le serveur ou ajustez le propriétaire du partage avec chown."
|
||||
],
|
||||
"squashOutro": "ProxMenux ne peut pas corriger cela — c'est la politique du serveur."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Points de montage LXC (hôte ↔ conteneur)",
|
||||
"tail": "— l'alternative pour les CT non privilégiés: monter sur l'hôte, lier dans CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Client Samba en LXC",
|
||||
"tail": " — page associée avec la même approche pour les partages SMB / CIFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"label": "Serveur NFS dans LXC",
|
||||
"tailRich": "— l'inverse: exposer les dossiers <em>de</em> un CT sur NFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "Partage NFS comme stockage Proxmox",
|
||||
"tail": " — enregistrer le partage dans Proxmox lui-même plutôt que dans un seul CT."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,159 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "NFS serveur dans LXC | ProxMenux Documentation",
|
||||
"description": "Partagez des dossiers via NFS depuis un conteneur LXC Proxmox avec ProxMenux. Installation automatique de nfs-kernel-server, groupe commun sharedfiles, configuration de /etc/exports, ACL réseau et désinstallation complète. Nécessite un conteneur privilégié.",
|
||||
"ogTitle": "NFS serveur dans LXC | ProxMenux Documentation",
|
||||
"ogDescription": "Exécutez un serveur NFS dans un LXC privilégié avec le groupe commun sharedfiles, des ACL réseau et une désinstallation complète."
|
||||
},
|
||||
"header": {
|
||||
"title": "Serveur NFS dans LXC",
|
||||
"description": "Exécutez un serveur NFS du noyau dans un conteneur LXC Proxmox et exposez des dossiers aux autres machines du réseau. ProxMenux installe nfs-kernel-server, configure le groupe commun sharedfiles pour faciliter le partage entre plusieurs CT privilégiés, gère /etc/exports et propose une désinstallation complète.",
|
||||
"section": "Stockage et partage · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Conteneur privilégié requis",
|
||||
"body": "<code>nfs-kernel-server</code> doit monter le système de fichiers du noyau <code>nfsd</code> sur <code>/proc/fs/nfsd</code>. Cela exige <code>CAP_SYS_ADMIN</code> dans l’espace de noms du noyau hôte, pas seulement dans celui des utilisateurs du conteneur. Les LXC non privilégiés n’ont pas cette capacité : <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code> ; systemd signale un échec de dépendance pour <code>nfs-server.service</code>. Le script exige donc un CT privilégié et <strong>s’arrête si le CT n’est pas privilégié</strong>. Une autre possibilité consiste à placer le serveur NFS dans une VM."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Ce que ça fait",
|
||||
"body": "C’est l’inverse de la page <em>client NFS</em> : le CT devient un <strong>serveur NFS</strong> et expose son propre dossier à d’autres CT, à l’hôte Proxmox, à des VM ou à des machines physiques.",
|
||||
"diagramServerLabel": "LXC (privilégié) — Serveur NFS",
|
||||
"diagramServerDetail": "/mnt/data\n(dossier exposé)\n\nchown root:sharedfiles\nchmod 2775 (SGID)\n\nnfs-kernel-server\n+ rpcbind en cours d’exécution",
|
||||
"diagramClientLabel": "Tout client sur le réseau",
|
||||
"diagramClientDetail": "un autre CT, l'hôte,\nun VM, une machine physique...",
|
||||
"diagramArrow": "Exportation NFS"
|
||||
},
|
||||
"shared": {
|
||||
"heading": "Le groupe commun « sharedfiles »",
|
||||
"body": "Avant d'exporter le dossier, ProxMenux crée un groupe appelé <code>sharedfiles</code> avec <strong>GID 101000</strong> à l'intérieur du conteneur, y ajoute chaque utilisateur régulier, puis définit le répertoire d'exportation à <code>root:sharedfiles</code> avec le mode <code>2775</code>. Le <code>2</code> à l'avant est le bit SGID — chaque fichier ou dossier créé à l'intérieur hérite automatiquement du groupe <code>sharedfiles</code>.",
|
||||
"gidTitle": "Pourquoi GID 101000 spécifiquement",
|
||||
"gidBody": "Avec le mappage LXC par défaut (+100000), le GID 101000 de l’hôte apparaît comme GID <strong>1000</strong> dans un CT non privilégié. Ce serveur utilise un CT <strong>privilégié</strong>, sans décalage. Deux CT privilégiés utilisant <code>sharedfiles</code> avec le GID 101000 partagent donc le même identifiant numérique de groupe.",
|
||||
"remapTitle": "La création héritée des utilisateurs « remap_* » est ignorée pour les CT privilégiés",
|
||||
"remapBody": "L’ancienne branche pour les CT non privilégiés créerait des utilisateurs <code>remap_<uid></code> avec l’UID <code><uid> + 100000</code>, tous dans <code>sharedfiles</code>, pour les utilisateurs ordinaires et les UID courants (33, 1000, 1001, 1002). Ce décalage de <code>+100000</code> ne s’applique pas aux CT <strong>privilégiés</strong> exigés ici ; le script ignore donc cette branche. L’absence de comptes <code>remap_*</code> dans <code>getent passwd</code> est normale et n’indique pas une erreur."
|
||||
},
|
||||
"defaults": {
|
||||
"heading": "Options d'exportation par défaut — lire cette première",
|
||||
"warnTitle": "Les options par défaut incluent no_root_squash",
|
||||
"warnBody": "ProxMenux utilise par défaut <code>rw,sync,no_subtree_check,'<'strong'>'no_root_squash'<'/strong'>'</code>. <strong>Tout utilisateur root d’un client peut écrire comme root sur l’export.</strong> Réservez cette option à un réseau local de confiance. Si le CT est accessible depuis un réseau non fiable (VPS ou VLAN non fiable), <strong>remplacez l’option par <code>root_squash</code></strong> dans le dialogue des options personnalisées."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal, ouvrez <strong>Storage & Share Manager → Configure NFS Server in LXC</strong>. Seuls les CT privilégiés sont proposés. Choisissez le CT cible ; le script le démarre s’il est arrêté et refuse les CT non privilégiés. Le menu comporte cinq options.",
|
||||
"imageAlt": "Menu NFS Server Manager — Créer / Afficher / Supprimer / Statut / Désinstaller"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (Créer le flux)"
|
||||
},
|
||||
"network": {
|
||||
"heading": "Réseau ACL — qui peut monter le partage",
|
||||
"intro": "<code>/etc/exports</code> détermine quels clients peuvent monter l’export. Le dialogue propose trois modes :",
|
||||
"headerMode": "Mode",
|
||||
"headerValue": "Valeur écrite pour /etc/exports",
|
||||
"headerWhen": "Quand le choisir",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Réseau local",
|
||||
"value": "192.168.0.0/16",
|
||||
"whenRich": "Pour les réseaux domestiques ou de petite entreprise habituels. Couvre toutes les adresses <code>192.168.*.*</code>."
|
||||
},
|
||||
{
|
||||
"mode": "Sous-réseau personnalisé",
|
||||
"value": "votre CIDR (par exemple 10.0.0.0/24)",
|
||||
"when": "Lorsque votre LAN n'est pas dans 192.168.x.x ou que vous voulez une portée plus étroite."
|
||||
},
|
||||
{
|
||||
"mode": "Un seul hôte",
|
||||
"value": "votre IP (par exemple 10.0.0.42)",
|
||||
"when": "Seule une machine précise peut monter l’export. Option la plus restrictive."
|
||||
}
|
||||
]
|
||||
},
|
||||
"options": {
|
||||
"heading": "Options d'exportation expliquées",
|
||||
"headerOption": "Option",
|
||||
"headerEffect": "Ce qu'il fait",
|
||||
"rows": [
|
||||
{
|
||||
"option": "rw / ro",
|
||||
"effect": "Autoriser les clients à lire et écrire, ou à lire uniquement."
|
||||
},
|
||||
{
|
||||
"option": "sync",
|
||||
"effectRich": "Ne répond aux écritures qu’une fois les données sur disque. Plus sûr que <code>async</code>, au prix d’un débit réduit."
|
||||
},
|
||||
{
|
||||
"option": "no_subtree_check",
|
||||
"effect": "Évite de vérifier à chaque requête que le fichier appartient encore au sous-arbre exporté. Plus rapide et évite les problèmes si des fichiers sont renommés pendant l’opération."
|
||||
},
|
||||
{
|
||||
"option": "no_root_squash",
|
||||
"effectRich": "<strong>Faire confiance à root sur le client.</strong> Un client monté par root écrit comme root sur le serveur. Convient aux LAN de confiance, par exemple pour préserver les propriétaires lors des sauvegardes. Remplacez cette option par <code>root_squash</code> si vous ne faites pas entièrement confiance à chaque machine autorisée par l’ACL réseau."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Reproduisez toute la procédure manuellement. Chaque commande s’exécute <strong>dans le CT</strong> via <code>pct exec <ctid> --</code> ou <code>pct enter <ctid></code> :"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Voir les exportations actuelles",
|
||||
"body": "Affiche <code>/etc/exports</code> depuis le CT en ignorant commentaires et lignes vides, puis présente chaque export avec son ACL réseau et ses options. Utile pour vérifier les dossiers exposés avant de communiquer l’IP du CT."
|
||||
},
|
||||
"delete": {
|
||||
"heading": "Supprimer une exportation",
|
||||
"body": "Liste chaque ligne dans <code>/etc/exports</code> pour la sélection, supprime la ligne choisie (<code>sed -i</code>), exécute <code>exportfs -ra</code> et redémarre <code>nfs-kernel-server</code>. Le dossier lui-même et son contenu restent intacts."
|
||||
},
|
||||
"status": {
|
||||
"heading": "Vérifier l'état NFS",
|
||||
"body": "Pass diagnostique : confirme que <code>nfs-kernel-server</code> et <code>rpcbind</code> sont installés et actifs, imprime la sortie <code>exportfs -v</code>, liste les sessions NFS actives (<code>showmount -a</code>) et les connexions client actuelles."
|
||||
},
|
||||
"uninstall": {
|
||||
"heading": "Désinstaller le serveur NFS",
|
||||
"body": "Nettoyage complet après confirmation : arrête et désactive <code>nfs-kernel-server</code> et <code>rpcbind</code>, vide <code>/etc/exports</code>, supprime les paquets NFS avec <code>apt-get purge</code>, retire le groupe <code>sharedfiles</code> et les utilisateurs <code>remap_*</code>, puis termine les processus restants. Les <strong>dossiers exportés eux-mêmes ne sont pas supprimés</strong> ; seules la configuration NFS et les paquets le sont.",
|
||||
"warnTitle": "Le script s'arrête à la ligne d'exportation, pas aux données",
|
||||
"warnBody": "<em>Supprimer un export</em> et <em>Désinstaller le serveur NFS</em> retirent la configuration d’export. Les données du dossier sont conservées. Pour les supprimer aussi, utilisez explicitement <code>rm -rf</code> après la fin du script et sauvegardez-les d’abord si quelqu’un peut encore en avoir besoin."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"privTitle": "Conteneur privilégié requis (le script s’arrête)",
|
||||
"privBody": "Le CT sélectionné n'est pas privilégié. <code>nfs-kernel-server</code> ne peut pas démarrer là parce que le montage <code>/proc/fs/nfsd</code> nécessite <code>CAP_SYS_ADMIN</code> dans l'espace nominatif du noyau hôte, et le module <code>nfsd</code> n'est pas non plus exposé à l'espace nominatif du conteneur (<code>modprobe nfsd</code> de l'intérieur renvoie <code>FATAL: Module nfsd not found</code>). Si vous contournez le contrôle, vous verrez <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code> dans le journal et aucun port NFS n'ouvrira jamais. Les seules options utilisables sont : convertir le CT en privilégié, ou déplacer le serveur NFS vers une VM.",
|
||||
"aptTitle": "Échec de apt-get install",
|
||||
"aptIntro": "Le script suppose une famille Debian CT. Sur Alpine / Arch / Rocky / Alma, installez les paquets du serveur NFS à la main:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add nfs-utils</code>",
|
||||
"Arch: <code>pacman -S nfs-utils</code>",
|
||||
"Rocky / Alma: <code>dnf install nfs-utils</code>"
|
||||
],
|
||||
"aptOutro": "Relancez ensuite le script ProxMenux ; l’installation est ignorée si les outils sont déjà présents.",
|
||||
"aclTitle": "Le client ne peut pas monter : 'accès refusé par le serveur'",
|
||||
"aclBody": "L’IP du client n’est pas autorisée par l’ACL réseau. Recréez l’export avec un sous-réseau plus large ou ajoutez l’IP exacte du client. Attention : via un routeur NAT, le client peut apparaître avec l’IP WAN du routeur au lieu de son IP LAN. Vérifiez sur le serveur avec <code>tcpdump -n port 2049</code>.",
|
||||
"ownTitle": "Les fichiers écrits par le client apparaissent avec une propriété bizarre sur le serveur",
|
||||
"ownIntro": "Deux possibilités :",
|
||||
"ownItems": [
|
||||
"Avec <code>no_root_squash</code> (par défaut), le client root écrit comme root sur le serveur. Les fichiers sont détenus par <code>root:sharedfiles</code> grâce au SGID du dossier.",
|
||||
"Les utilisateurs non-racines de clients écrivent comme leur propre UID/GID. Si leur UID n'existe pas sur le serveur, les fichiers apparaissent avec des nombres bruts (par exemple : <code>1234:1234</code>). Utilisez également le groupe <code>sharedfiles</code> sur le client, ou alignez les UID sur les systèmes qui partagent des fichiers."
|
||||
],
|
||||
"noShowTitle": "Serveur accessible mais showmount ne renvoie rien",
|
||||
"noShowBody": "Après avoir édité <code>/etc/exports</code>, vous devez recharger la table d'exportation avec <code>exportfs -ra</code> et redémarrer <code>nfs-kernel-server</code> — le script fait les deux, mais si vous avez édité le fichier à la main, faites-le vous-même. Confirmez également le pare-feu sur le CT (et sur l'hôte Proxmox) permet TCP/UDP 2049 et le port rpcbind (111)."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "Client NFS dans LXC",
|
||||
"tail": " — l’inverse : monter des partages NFS externes dans un CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"label": "Serveur Samba en LXC",
|
||||
"tail": "— page soeur, même motif avec SMB / CIFS au lieu de NFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "Partage NFS comme stockage Proxmox",
|
||||
"tailRich": " — une fois que le CT expose un export, enregistrez ce partage NFS dans Proxmox pour le voir sous <em>Datacenter → Storage</em>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,155 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Client Samba en LXC | ProxMenux Documentation",
|
||||
"description": "Montez des partages Samba / CIFS dans un conteneur LXC Proxmox avec ProxMenux. Installation automatique de cifs-utils et smbclient, découverte des serveurs, stockage protégé des identifiants et montages persistants via /etc/fstab. Nécessite un conteneur privilégié.",
|
||||
"ogTitle": "Client Samba en LXC | ProxMenux Documentation",
|
||||
"ogDescription": "Montez des partages Samba / CIFS dans un conteneur LXC privilégié. Découverte automatique, fichier d’identifiants protégé et persistance dans /etc/fstab."
|
||||
},
|
||||
"header": {
|
||||
"title": "Client Samba en LXC",
|
||||
"description": "Le montage Samba (SMB / CIFS) se fait directement à l'intérieur d'un conteneur Proxmox LXC. Le conteneur devient un vrai client CIFS — parle au serveur Samba sur le réseau, exécute mount.cifs, stocke les identifiants en toute sécurité, et écrit à /etc/fstab. ProxMenux installe cifs-utils + smbclient pour vous et valide les identifiants sur le serveur avant le montage.",
|
||||
"section": "Stockage et partage · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Conteneur privilégié requis",
|
||||
"body": "Le client du noyau <code>mount.cifs</code> a besoin de capacités (<code>SYS_ADMIN</code> au minimum) que les conteneurs non privilégiés LXC n'exposent pas. Le script force cela — il vous demande de choisir un CT et <strong>s’arrête s'il n'est pas privilégié</strong>. Si vous avez besoin du partage à l'intérieur d'un CT non privilégié, montez-la d'abord sur l'hôte Proxmox (avec <hostSambaLink>Samba / CIFS en tant que stockage Proxmox</hostSambaLink>) et montez-la par bind mount dans le CT avec le <mountLink>LXC Mount Manager</mountLink>."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Ce que ça fait",
|
||||
"body": "Le conteneur parle CIFS sur le réseau et monte le partage lui-même. L'hôte Proxmox n'est que le pont réseau — il ne voit ni ne gère le montage.",
|
||||
"diagramServerLabel": "Serveur Samba",
|
||||
"diagramServerDetail": "//srv/share",
|
||||
"diagramHostLabel": "Hôte Proxmox",
|
||||
"diagramHostDetail": "(seulement un\npont réseau)",
|
||||
"diagramCtLabel": "LXC (privilégié)",
|
||||
"diagramCtDetail": "/mnt/share\nmount.cifs à l'intérieur de CT",
|
||||
"diagramArrow": "CIFS",
|
||||
"twoWaysTitle": "Deux façons de donner un CT une part de Samba — choisissez une",
|
||||
"twoWaysBind": "<strong>Montage par host</strong> (<mountLink>LXC Mount Manager</mountLink>) : l'hôte monte le CIFS une fois, chaque CT reçoit le même chemin par bind mount. Fonctionne avec des CT non privilégiés. Recommandé lorsque plusieurs CT ont besoin de le même partage.",
|
||||
"twoWaysDirect": "<strong>Montage CIFS direct dans le CT</strong> (cette page) : le CT monte CIFS lui-même. Exige un CT privilégié. Utile si chaque CT doit gérer ses identifiants ou accéder à un serveur différent."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal de ProxMenux, ouvrez <strong>Storage & Share Manager → Configurer le client Samba dans LXC (privilégié uniquement)</strong>. Choisissez d’abord <strong>le CT cible</strong> ; ProxMenux le démarre s’il est arrêté et abandonne s’il n’est pas privilégié. Le sous-menu suivant s’affiche ensuite :",
|
||||
"imageAlt": "Menu Samba Client Manager — Montage / Affichage / Démontage / Test de connectivité"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (mount flow)"
|
||||
},
|
||||
"creds": {
|
||||
"heading": "Où vit le mot de passe",
|
||||
"body": "ProxMenux <strong>ne place pas le mot de passe dans la commande de montage</strong> ni dans <code>/etc/fstab</code>. Il crée un fichier d’identifiants dans le CT. Ce fichier contient les identifiants en clair, protégés par des permissions réservées à root ; il n’est pas chiffré :",
|
||||
"whyTitle": "Pourquoi un fichier séparé plutôt que fstab",
|
||||
"whyBody": "Le module CIFS accepte les options <code>username=</code> / <code>password=</code> en ligne dans fstab, mais quiconque peut lire <code>/etc/fstab</code> voit le mot de passe en clair. Mettre des identifiants dans un fichier root-only et pointer fstab dessus (<code>credentials=</code>) maintient le mot de passe hors de config lisible dans le monde."
|
||||
},
|
||||
"options": {
|
||||
"heading": "Options de montage expliquées",
|
||||
"headerOption": "Option",
|
||||
"headerEffect": "Ce qu'il fait",
|
||||
"rows": [
|
||||
{
|
||||
"option": "rw / ro",
|
||||
"effect": "Mode lecture-écriture ou lecture seule pour l'ensemble du montage."
|
||||
},
|
||||
{
|
||||
"option": "file_mode=0664",
|
||||
"effect": "Permissions présentées pour les fichiers via CIFS. Par défaut, le propriétaire et le groupe peuvent écrire, les autres lire."
|
||||
},
|
||||
{
|
||||
"option": "dir_mode=0775",
|
||||
"effect": "Autorisations signalées pour les répertoires. Par défaut, le propriétaire+groupe entre et crée, d'autres traversent."
|
||||
},
|
||||
{
|
||||
"option": "iocharset=utf8",
|
||||
"effect": "Impose UTF-8 pour les noms de fichiers transmis par le réseau. Évite les caractères illisibles dans les noms non ASCII."
|
||||
},
|
||||
{
|
||||
"option": "credentials=file",
|
||||
"effect": "Lisez le nom d'utilisateur / mot de passe du fichier (ajouté automatiquement pour l'auth utilisateur)."
|
||||
},
|
||||
{
|
||||
"option": "guest",
|
||||
"effect": "Authentifier en tant qu'invité, aucune identification requise (ajoutée automatiquement lorsque l'invité est choisi)."
|
||||
},
|
||||
{
|
||||
"option": "_netdev",
|
||||
"effect": "Indique que le système d'initialisation de ce montage a besoin du réseau. Boot ne bloque pas l'attente."
|
||||
},
|
||||
{
|
||||
"option": "x-systemd.automount",
|
||||
"effect": "Montage paresseux : ne monte que sur le premier accès. Le serveur CIFS inaccessible au démarrage ne bloque pas le CT."
|
||||
},
|
||||
{
|
||||
"option": "noauto",
|
||||
"effect": "Évite le montage immédiat au démarrage. Avec l’unité automount, le montage n’a lieu qu’au premier accès."
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Effet net des drapeaux fstab",
|
||||
"netEffectBody": "Le système de fichiers CIFS est monté au <em>premier accès</em> plutôt qu’immédiatement au démarrage. Si le serveur est hors ligne, cet accès peut attendre ou échouer et affecter les services qui dépendent du chemin. Automount réduit la dépendance au démarrage, sans garantir que tous les services du CT restent épargnés."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Répliquez l'ensemble du flux à la main — chaque commande exécute <strong> à l'intérieur du CT</strong> via <code>pct exec <ctid> --</code> ou directement via <code>pct enter <ctid></code>:",
|
||||
"guestIntro": "Variante d'invité — aucun fichier d'identification nécessaire:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Afficher les montages actuels",
|
||||
"body": "Liste tous les points de montage CIFS actifs à l'intérieur du CT (<code>mount -t cifs</code>) plus toutes les lignes CIFS du CT <code>/etc/fstab</code>. Pour chaque entrée fstab, l'état de montage en direct est affiché — utile pour repérer les montages permanents qui ne sont pas apparus au démarrage."
|
||||
},
|
||||
"unmount": {
|
||||
"heading": "Démonter le partage Samba",
|
||||
"body": "Combine les montages live et les entrées fstab dans une seule liste, vous permet de choisir une, et <strong> retire la ligne correspondante de <code>/etc/fstab</code></strong> plus le fichier d'identification correspondant. Le script n'exécute pas <code>umount</code> sur le montage en direct — il vous indique plutôt qu'un redémarrage CT est nécessaire pour que le démontage prenne effet.",
|
||||
"warnTitle": "Le script supprime les entrées fstab, pas les montages en direct",
|
||||
"warnBody": "Même conception que le client NFS : <code>umount</code> sur une monture occupée échoue avec \"dispositif occupé\". La suppression de l'entrée fstab garantit que le montage disparaît proprement lors du prochain démarrage CT. Si vous voulez que le montage soit parti <em>maintenant</em>, exécutez <code>pct exec <ctid> -- umount /mnt/<path></code> à la main après la fin du script."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Tester la connectivité Samba",
|
||||
"body": "Diagnostic dans le CT : vérifie que <code>cifs-utils</code> est installé, liste les montages CIFS actifs puis teste, pour chaque serveur de fstab, ping → ports 139/445 → liste des partages en invité. « Authentification requise » lors du test invité est normal si le serveur ne propose pas de partage public."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"privTitle": "Conteneur privilégié requis (le script s’arrête)",
|
||||
"privBody": "Le CT sélectionné n'est pas privilégié. Le client du noyau CIFS a besoin de la capacité <code>SYS_ADMIN</code> que les CT non privilégiés n'exposent pas. Convertissez le CT en privilégié, ou utilisez le chemin alternatif décrit dans l'avertissement en haut de cette page.",
|
||||
"aptTitle": "apt-get install fails",
|
||||
"aptIntro": "Le script suppose une famille Debian CT (<code>apt-get</code>). Sur Alpine / Arch / Rocky / Alma, installez le client CIFS à la main:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add cifs-utils samba-client</code>",
|
||||
"Arch: <code>pacman -S cifs-utils smbclient</code>",
|
||||
"Rocky / Alma: <code>dnf install cifs-utils samba-client</code>"
|
||||
],
|
||||
"aptOutro": "Ensuite, lancez le script ProxMenux — l'étape d'installation saute lorsque les outils sont déjà présents.",
|
||||
"guestFallbackTitle": "\"Le serveur vous a connecté en tant qu'invité au lieu de l'utilisateur spécifié\"",
|
||||
"guestFallbackBody": "La validation active du script a attrapé un vrai problème d'auth. Le serveur a accepté la connexion mais l'a rétrogradée à invité parce que les identifiants sont erronés. Causes communes : faute de frappe dans le nom d'utilisateur / mot de passe, l'utilisateur n'existe pas sur le serveur, l'utilisateur est verrouillé, ou le groupe de travail / domaine est mal adapté. Réexécutez soigneusement le flux et entrez les identifiants (le mot de passe est caché dans la boîte de dialogue).",
|
||||
"denyTitle": "\"NT_STATUS_ACCESS_DENIED\" lors du montage",
|
||||
"denyBody": "Les identifiants sont valides mais le partage refuse l’accès. Vérifiez côté serveur les permissions de l’utilisateur pour ce partage précis : la validation confirme la connexion, pas les ACL de chaque partage. Vérifiez aussi si le serveur exige une version SMB particulière ; ajoutez <code>vers=3.0</code> (ou <code>2.1</code>, <code>2.0</code>) aux options de montage.",
|
||||
"utf8Title": "Noms de fichiers UTF-8 / non ASCII mal affichés",
|
||||
"utf8Body": "Les options par défaut incluent <code>iocharset=utf8</code>, mais certaines configurations de serveur signalent une page de code inattendue. Si les noms de fichiers avec des accents / symboles semblent mal, essayez également <code>nounix</code> (certains serveurs Linux Samba en ont besoin lorsque le client est également Linux) ou placez le côté serveur sur <code>unix extensions = no</code>.",
|
||||
"bootTitle": "Le montage permanent réussit mais ne vient pas au démarrage",
|
||||
"bootBody": "Presque toujours : le réseau n'est pas prêt lorsque le CT monte (les drapeaux du script <code>_netdev,x-systemd.automount,noauto</code> corrigent cela), le serveur est inaccessible au démarrage (le montage automatique attend le premier accès — c'est normal) ou le DNS n'est pas résolu au démarrage (utiliser l'IP du serveur, pas son nom d'hôte)."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "Points de montage LXC (hôte ↔ conteneur)",
|
||||
"tail": "— l'alternative pour les CT non privilégiés: monter sur l'hôte, lier dans CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "Client NFS dans LXC",
|
||||
"tail": " — page associée avec la même approche pour les partages NFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"label": "Serveur Samba en LXC",
|
||||
"tailRich": "— l'inverse: exposer les dossiers <em>de</em> un CT sur Samba."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS comme stockage Proxmox",
|
||||
"tail": " — enregistrer le partage dans Proxmox lui-même plutôt que dans un seul CT."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Serveur Samba en LXC | ProxMenux Documentation",
|
||||
"description": "Exécutez un serveur Samba (SMB / CIFS) dans un conteneur LXC Proxmox avec ProxMenux. Installation automatique de samba, gestion de /etc/samba/smb.conf, des utilisateurs smbpasswd et du groupe sharedfiles pour les dossiers montés par bind mount. Nécessite un conteneur privilégié.",
|
||||
"ogTitle": "Serveur Samba en LXC | ProxMenux Documentation",
|
||||
"ogDescription": "Exposez des dossiers via SMB/CIFS depuis un LXC privilégié. Installation automatique, utilisateur smbpasswd et permissions adaptées aux bind mounts."
|
||||
},
|
||||
"header": {
|
||||
"title": "Serveur Samba en LXC",
|
||||
"description": "Exécutez un serveur Samba (SMB / CIFS) à l'intérieur d'un conteneur Proxmox LXC et exposez des dossiers aux clients Windows / macOS / Linux sur le réseau. ProxMenux installe samba, crée un utilisateur Samba avec smbpasswd, gère /etc/samba/smb.conf et applique des permissions adaptées aux bind mounts lorsque le dossier partagé vient de l'hôte.",
|
||||
"section": "Stockage et partage · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Conteneur privilégié requis",
|
||||
"body": "Samba prend l’identité de l’utilisateur qui se connecte avec <code>setgroups()</code> sur chaque connexion arborescente (le moment où un client ouvre un partage). Dans un LXC non privilégié, le noyau rejette ce syscall parce que l'espace de nom d'utilisateur du conteneur est créé avec <code>setgroups=deny</code> — et <code>smbd</code> répond en arrêtant le processus de travail avec <code>PANIC: sys_setgroups failed</code>. Le résultat est que <code>smbd</code> démarre et lie les ports 139/445, mais chaque connexion client échoue avec <code>NT_STATUS_CONNECTION_DISCONNECTED</code>. Le script impose un CT privilégié pour cette raison et <strong>s’arrête si le CT n’est pas privilégié</strong>. Il n'y a pas de correctif propre du côté serveur; utilisez un CT privilégié ou lancez Samba à l'intérieur d’une VM."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Ce que ça fait",
|
||||
"body": "Le conteneur devient un serveur SMB/CIFS : il exécute <code>smbd</code>, expose un dossier via <code>/etc/samba/smb.conf</code> et accepte les connexions clientes sur les ports <code>139</code> / <code>445</code>. Les clients voient le partage à <code>\\\\<ct-ip>\\<share-name></code> dans Windows Explorer, <code>smb://<ct-ip>/<share-name></code> dans macOS Finder, ou via <code>mount.cifs</code> sur Linux.",
|
||||
"diagramServerLabel": "LXC (privilégié) — Serveur Samba",
|
||||
"diagramServerDetail": "/mnt/data\n(dossier exposé)\n\nsmbd + nmbd en cours d’exécution\n\nUtilisateur: <username>\n(via smbpasswd)\n\nGroupe imposé:\nsharedfiles",
|
||||
"diagramClientLabel": "Tout client sur le réseau",
|
||||
"diagramClientDetail": "Windows: \\\\<ip>\\<share>\nmacOS: smb://<ip>/<share>\nLinux: mount.cifs",
|
||||
"diagramArrow": "SMB / CIFS"
|
||||
},
|
||||
"perms": {
|
||||
"heading": "Deux chemins d'autorisation selon le type de dossier",
|
||||
"body": "Avant d'ajouter la part à <code>smb.conf</code>, le script vérifie si le dossier choisi est un montage <strong>bind de l'hôte</strong> ou un dossier local normal <strong> à l'intérieur du CT</strong> — et applique des droits de propriété différents en conséquence:",
|
||||
"headerType": "Type de dossier",
|
||||
"headerAction": "Ce que fait le script",
|
||||
"bindType": "Bind-mount de l'hôte",
|
||||
"bindTypeSubRich": "détecté par la sortie <code>mount</code>",
|
||||
"bindActionRich": "Crée le groupe <code>sharedfiles</code> (par défaut GID 999, dynamique si pris), y ajoute l'utilisateur Samba, puis <code>chown root:sharedfiles</code> + <code>chmod 2775</code> (SGID — nouveaux fichiers héritent du groupe). Si l'utilisateur ne peut toujours pas écrire, applique <code>setfacl -m u:<user>:rwx</code>.",
|
||||
"localType": "Dossier local à l'intérieur de CT",
|
||||
"localTypeSub": "aucun montage de liaison détecté",
|
||||
"localActionRich": "Propriété standard: <code>chown -R <user>:<user></code> + <code>chmod -R 755</code>. Aucun groupe partagé n'est nécessaire car aucun autre CT n'écrit dans ce dossier. Retourne à <code>setfacl</code> si l'accès à l'écriture est toujours manquant.",
|
||||
"gidTitle": "GID pour 'sharedfiles' diffère du flux du serveur NFS",
|
||||
"gidBody": "Le script serveur Samba utilise GID <strong>999</strong> pour <code>sharedfiles</code>, tandis que le flux du serveur <nfsLink>NFS</nfsLink> utilise GID <strong>101000</strong>. Si vous exécutez les deux serveurs dans le même CT et que vous voulez un seul groupe partagé dans les deux protocoles, modifiez l'un d'eux pour correspondre à l'autre après l'installation (p. ex. <code>groupmod -g 101000 sharedfiles</code>) et ré-appliquer la propriété sur les dossiers touchés. C'est une incohérence connue dans les scripts actuels."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Ouverture de l'outil",
|
||||
"body": "Dans le menu principal, ouvrez <strong>Storage & Share Manager → Configure Samba Server in LXC</strong>. Seuls les CT privilégiés sont proposés. Choisissez le CT cible ; le script le démarre s’il est arrêté et refuse les CT non privilégiés. Le menu comporte cinq options.",
|
||||
"imageAlt": "Menu Samba Server Manager — Créer / Afficher / Supprimer / Statut / Désinstaller"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Comment fonctionne le script (Créer le flux)"
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Les trois modes de partage",
|
||||
"intro": "Chaque mode écrit une stanza différente à <code>smb.conf</code>. Tous les trois comprennent le <code>valid users = <username></code> (pas d'anonymat), le <code>force group = sharedfiles</code> (ainsi les nouveaux fichiers appartiennent au groupe partagé) et le <code>veto files = /lost+found/</code> (le cache des clients).",
|
||||
"headerMode": "Mode",
|
||||
"headerBlock": "Bloc écrit en smb.conf",
|
||||
"rwMode": "Lecture et écriture",
|
||||
"roMode": "Lecture seule",
|
||||
"customMode": "Personnalisé",
|
||||
"customBodyRich": "Vous tapez vos propres directives dans une boîte en texte libre. Le ProxMenux les enveloppe toujours dans un bloc <code>[share]</code> avec les <code>path</code>, <code>valid users</code>, <code>force group</code> et <code>veto files</code>."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Équivalent manuel",
|
||||
"body": "Reproduisez toute la procédure manuellement. Chaque commande s’exécute <strong>dans le CT</strong> via <code>pct exec <ctid> --</code> ou <code>pct enter <ctid></code> :"
|
||||
},
|
||||
"connect": {
|
||||
"heading": "Connexion des clients",
|
||||
"headerOs": "Système d'exploitation du client",
|
||||
"headerHow": "Comment se connecter",
|
||||
"windowsOs": "Windows",
|
||||
"windowsHowRich": "Explorateur de fichiers → barre d’adresse : <code>\\\\<ct-ip>\\<share-name></code>. Ou <em>Connecter un lecteur réseau</em> → cocher « Se connecter à l’aide d’informations d’identification différentes ».",
|
||||
"macosOs": "macOS",
|
||||
"macosHowRich": "Finder → <em>Aller → Se connecter au serveur...</em> → <code>smb://<ct-ip>/<share-name></code>. Ou <code>mount_smbfs //user@<ct-ip>/<share> /mountpoint</code>.",
|
||||
"linuxOs": "Linux",
|
||||
"linuxHowRich": "<code>mount -t cifs //<ct-ip>/<share> /mnt/x -o username=<u>,password=<p>,iocharset=utf8</code>. Ou utilisez le client <clientLink>Samba dans la page LXC</clientLink> si le client est un autre client Proxmox CT."
|
||||
},
|
||||
"view": {
|
||||
"heading": "Voir les partages actuels",
|
||||
"body": "Analyse <code>/etc/samba/smb.conf</code> à l'intérieur du CT et liste tous les blocs <code>[share]</code> (en ignorant <code>[global]</code>, <code>[homes]</code>, <code>[printers]</code>) avec son chemin. Utile comme un inventaire rapide."
|
||||
},
|
||||
"delete": {
|
||||
"heading": "Supprimer un partage",
|
||||
"body": "Permet de choisir un partage par nom, supprime le bloc de <code>smb.conf</code> (<code>sed</code> supprime de <code>[share]</code> jusqu'à la prochaine ligne blanche), et redémarre <code>smbd</code>. Le dossier lui-même et son contenu restent intacts."
|
||||
},
|
||||
"status": {
|
||||
"heading": "Vérifier l'état de Samba",
|
||||
"body": "Indique si <code>smbd</code> et <code>nmbd</code> sont installés et actifs, liste les utilisateurs de Samba (<code>pdbedit -L</code>) et imprime les sessions actives (<code>smbstatus</code>)."
|
||||
},
|
||||
"uninstall": {
|
||||
"heading": "Désinstaller le serveur Samba",
|
||||
"body": "Nettoyage complet après confirmation : arrête et désactive <code>smbd</code> et <code>nmbd</code>, sauvegarde <code>smb.conf</code> dans <code>smb.conf.backup.YYYYMMDD_HHMMSS</code>, supprime les utilisateurs Samba avec <code>smbpasswd -x</code> et les paquets Samba avec <code>apt-get purge</code>. Les <strong>dossiers exportés eux-mêmes ne sont pas supprimés</strong>.",
|
||||
"warnTitle": "Les dossiers survivent — sauvegarde des données séparément",
|
||||
"warnBody": "<em>Supprimer un partage</em> et <em>Désinstaller le serveur Samba</em> retirent la configuration de partage. Les données des dossiers exportés sont conservées. Pour les supprimer aussi, utilisez explicitement <code>rm -rf</code> après la fin du script."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"privTitle": "Conteneur privilégié requis (le script s’arrête)",
|
||||
"privBody": "Le CT sélectionné n'est pas privilégié et <code>smbd</code> ne peut pas y servir de fichiers. Si vous contournez le contrôle et configurez Samba à la main, <code>smbd</code> démarre et les ports s'ouvrent, mais la première connexion client panique avec <code>PANIC: sys_setgroups failed</code> dans <code>/var/log/samba/log.<client></code> et le client voit <code>NT_STATUS_CONNECTION_DISCONNECTED</code>. La cause est l'espace de noms d'utilisateur non privilégié ayant <code>setgroups=deny</code>, qui bloque l’adoption de l’identité de l’utilisateur par Samba à chaque connexion. Ni le <code>features=keyctl=1</code> ni la suppression du <code>force user</code> / <code>force group</code> ne changent cela. Les seules options utilisables sont : convertir le CT en privilégié, ou déplacer Samba vers une VM.",
|
||||
"aptTitle": "Échec de apt-get install",
|
||||
"aptIntro": "Le script suppose une famille Debian CT. Sur Alpine / Arch / Rocky / Alma, installer Samba à la main:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add samba</code>",
|
||||
"Arch: <code>pacman -S samba</code>",
|
||||
"Rocky / Alma: <code>dnf install samba</code>"
|
||||
],
|
||||
"aptOutro": "Relancez ensuite le script ProxMenux ; l’installation est ignorée si les outils sont déjà présents.",
|
||||
"noShareTitle": "Le client se connecte mais ne voit pas le partage",
|
||||
"noShareBody": "Vérifiez que <code>browseable = yes</code> est défini dans le bloc de partage (par défaut pour les modes rw / ro; peut être manquant en mode personnalisé). Vérifiez également le pare-feu CT et le pare-feu hôte Proxmox permettent TCP 445 (SMB) et 139 (NetBIOS). Certains clients Windows nécessitent également une résolution de nom — essayez d'abord directement l'IP.",
|
||||
"authTitle": "Défauts d'authentification (NT_STATUS_LOGON_FAILURE)",
|
||||
"authBody": "Le mot de passe est incorrect (les mots de passe Samba sont <em>distincts</em> de ceux du système ; listez les utilisateurs Samba avec <code>pdbedit -L</code>) ou l’utilisateur ne figure pas dans <code>valid users</code> pour ce partage. Réinitialisez le mot de passe dans le CT avec <code>smbpasswd <user></code>.",
|
||||
"groupTitle": "Les fichiers écrits par le client apparaissent avec un mauvais groupe sur le serveur",
|
||||
"groupBody": "Le script définit <code>force group = sharedfiles</code> dans le bloc de partage, de sorte que les nouveaux fichiers doivent être du groupe <code>sharedfiles</code>. S'ils ne le sont pas, le bit SGID du répertoire parent peut avoir été perdu (quelqu'un a exécuté <code>chmod</code> à la main). Réappliquer : <code>chmod 2775 /mnt/<share></code>.",
|
||||
"bothTitle": "Partage du même dossier sur NFS et Samba",
|
||||
"bothBody": "Le ProxMenux utilise différents GID pour le <code>sharedfiles</code> dans chaque script (Samba: 999, NFS: 101000). Si vous servez le même dossier via les deux, choisissez un seul GID et alignez les deux. La correction la plus simple : après avoir exécuté les deux scripts, modifiez le GID plus petit :"
|
||||
},
|
||||
"related": {
|
||||
"heading": "Autres",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Client Samba en LXC",
|
||||
"tail": " — l’inverse : monter des partages Samba externes dans un CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"label": "Serveur NFS dans LXC",
|
||||
"tail": "— page soeur, même motif avec NFS au lieu de CIFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS comme stockage Proxmox",
|
||||
"tailRich": " — une fois que le CT expose un export, enregistrez ce partage Samba dans Proxmox pour le voir sous <em>Datacenter → Storage</em>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user