Merge remote-tracking branch 'origin/develop' into HEAD

# Conflicts:
#	web/messages/es/docs/backup-restore/cross-kernel.json
#	web/messages/es/docs/backup-restore/destinations/pbs.json
This commit is contained in:
MacRimi
2026-10-18 13:49:35 +02:00
315 changed files with 37740 additions and 1079 deletions
+254
View File
@@ -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&gt;&amp;1 &gt;/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."
}
}
+94
View File
@@ -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>."
}
}
+67
View File
@@ -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,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 &lt;port&gt;</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_&lt;TIMESTAMP&gt;</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 &lt;backup&gt; /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 &amp; 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_&lt;TIMESTAMP&gt;</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 &lt;name&gt;</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 &lt;IP&gt;/&lt;mask&gt; dev &lt;iface&gt;</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."
}
]
}
}
+107
View File
@@ -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 &amp;&amp; apt-get install -y &lt;pkg&gt;</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 &lt;target&gt; -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-&lt;iface&gt;.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&lt;bus&gt;s&lt;slot&gt;</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-&lt;iface&gt;.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."
}
]
}
]
}
+213
View File
@@ -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"
]
]
}
}
]
}
]
}
+152
View File
@@ -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."
}
}
+70
View File
@@ -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."
}
}
+170
View File
@@ -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://&lt;your-host&gt;/.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://&lt;host&gt;: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."
}
}
}