mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
Bring the web documentation in line with develop in every language
- English pages describe backups, the manifest, ROCm GPUs, OCI host directories and storage as develop does, and say user instead of operator - New paragraph on host directories mounted with everything the host has mounted inside them, and a new update rule for host directories - The Proxmox Backup Server section of the post-install page is translated into every language - Spanish and the other six languages follow the updated English
This commit is contained in:
MacRimi
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "La disposition des archives ne change pas avec la destination",
|
||||
"body": "A l'intérieur de l'une des trois destinations, la même disposition <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> décrite dans <em>Comment ça marche</em> est présente. Un <code>.tar.zst</code> extrait d'une archive locale, un <code>.pxar</code> restauré de PBS et une archive Borg extraite de <code>borg extract</code> donnent tous un arbre de répertoire identique. Le chemin du code de restauration (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
|
||||
"body": "Quel que soit l’endroit où la sauvegarde est stockée, elle contient toujours les trois mêmes blocs décrits dans <em>Comment ça marche</em> : le système de fichiers (<code>rootfs/</code>), les métadonnées (<code>metadata/</code>) et le manifeste (<code>manifest.json</code>). L’extraction d’une archive locale <code>.tar.zst</code>, la restauration d’un <code>.pxar</code> depuis PBS ou l’extraction d’une archive Borg produisent toutes une arborescence identique. La restauration lit donc toujours les mêmes fichiers, quelle que soit la destination d’où provient la sauvegarde."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extraire une sauvegarde à l'extérieur de ProxMenux",
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Sélection du dépôt",
|
||||
"intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> et <code>HB_PBS_FINGERPRINT</code> pour l'exécution.",
|
||||
"intro": "ProxMenux découvre les dépôts PBS à partir de deux sources à chaque sauvegarde. L’utilisateur en choisit un dans un menu unifié ; pour cette exécution, ce choix détermine le serveur et le datastore vers lesquels la sauvegarde est envoyée, le mot de passe avec lequel elle s’authentifie et l’<em>empreinte</em> qui valide le certificat.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg de Proxmox (détection automatique)",
|
||||
@@ -46,7 +46,7 @@
|
||||
"backupIdTitle": "Nom de l'ID de sauvegarde",
|
||||
"backupIdBody": "L’identifiant de sauvegarde par défaut est <code>hostcfg-HOSTNAME</code>. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de <code>[A-Za-z0-9_-]</code> et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un <em>groupe</em>. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
|
||||
"pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
|
||||
"pxarBody": "La source <code>.pxar</code> est la totalité du <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code> ensemble. Les versions antérieures ont passé le <code>$staging_root/rootfs</code> comme source; cela a laissé le <code>metadata/</code> hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-<code>_rs_check_layout</code> de 3, qui enveloppe un arbre plat <code>etc/var/root/usr</code> dans une hiérarchie <code>rootfs/</code>."
|
||||
"pxarBody": "L’archive <code>.pxar</code> regroupe l’ensemble du répertoire de travail : le système de fichiers de l’hôte (<code>rootfs/</code>), les métadonnées (<code>metadata/</code>) et le manifeste (<code>manifest.json</code>). Lors de la restauration, ProxMenux compare le manifeste avec l’hôte cible pour déterminer s’ils sont équivalents, si le matériel a changé ou s’il s’agit d’une autre machine, et adapte le processus en conséquence. Les sauvegardes plus anciennes, réalisées par des versions antérieures de ProxMenux qui n’empaquetaient que le système de fichiers, se restaurent toujours correctement : la restauration détecte cet ancien format et le réorganise automatiquement."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Chiffrement côté client",
|
||||
@@ -63,7 +63,7 @@
|
||||
"recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide",
|
||||
"recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, <em>Déposer la clé sur PBS ?</em>, avec deux réponses. <strong>Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui.</strong> Le choix par défaut est <em>Non, conserver uniquement en local</em> : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton <em>Télécharger le fichier clé</em> du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir <em>Oui, envoyer</em> demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant <code>pbs-key.recovery.enc</code>. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
|
||||
"blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
|
||||
"blobUploadBody1": "Lorsque le mode de dépôt est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
|
||||
"blobUploadBody1": "Lorsque la réponse est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe de sauvegarde associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans la liste du datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte lui-même avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
|
||||
"envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?",
|
||||
"envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.",
|
||||
"blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté",
|
||||
@@ -73,7 +73,7 @@
|
||||
"recoverTitle": "Récupération sur un hôte frais",
|
||||
"recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans <code>/etc/pve/priv/storage/<NAME>.enc</code>, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe <code>-keyrecovery</code> existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie <code>wrong key — manifest's key XX does not match provided key YY</code>. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
|
||||
"monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
|
||||
"monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : <em>Télécharger</em> exporte le fichier actuel vers le navigateur ; <em>Envoyer</em> remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; <em>Supprimer</em> retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
|
||||
"monitorManagementBody": "Monitor affiche les commandes du fichier clé dans chaque ligne de destination PBS de la page de configuration des sauvegardes. La ligne propose trois actions : <em>Télécharger</em> exporte le fichier clé actuel vers le navigateur de l’utilisateur, <em>Envoyer</em> remplace le fichier clé installé par celui fourni par l’utilisateur (l’ancien fichier n’est écrasé qu’une fois le nouveau arrivé correctement à son chemin) et <em>Supprimer</em> retire le fichier clé de l’hôte. Juste à côté se trouve l’interrupteur de l’enveloppe de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète qui apparaît lorsque Oui est sélectionné et un bouton qui suit l’état actuel : <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Les commandes de Monitor et la boîte de dialogue du shell font la même chose en arrière-plan : le résultat sur le disque et sur PBS est donc identique, quelle que soit l’interface utilisée."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Récupération du côté restauration",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validation du schéma",
|
||||
"schemaBody": "Le manifeste valide contre <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'exécution du <code>build_manifest.sh --validate</code> déclenche une validation de schéma côté Python JSON (exige <code>python3</code> + <code>jsonschema</code>). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
|
||||
"schemaBody": "ProxMenux fournit un modèle qui décrit les champs que le manifeste doit contenir et la forme de chacun. Lors de la génération d’une sauvegarde, le manifeste peut être vérifié automatiquement par rapport à ce modèle, de sorte qu’un collecteur ayant produit un JSON mal formé ou un champ mal orthographié est détecté immédiatement. Cette vérification est destinée au développement de ProxMenux lui-même : sur un système où elle n’est pas installée, la sauvegarde fonctionne normalement et le manifeste est généré de la même façon."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "L'inventaire des applications",
|
||||
|
||||
@@ -127,7 +127,7 @@
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Notifications",
|
||||
"body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
|
||||
"body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si des canaux de notification sont configurés dans Monitor, les tâches sans surveillance présentent leurs résultats de la même manière que les sauvegardes manuelles : un utilisateur n’a pas besoin de consulter le journal pour savoir si une tâche a réussi."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite?",
|
||||
|
||||
@@ -105,7 +105,7 @@
|
||||
[
|
||||
"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."
|
||||
"Un GPU d’une génération prise en charge par l’image ROCm de l’application (les GPU RDNA2 qu’elle cite et les plus récents) est proposé tel quel. Les autres GPU de ces familles, comme les Radeon 680M et 780M, sont proposés à titre expérimental et ne sont jamais l’option proposée par défaut. 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. Un GPU plus ancien, tel que la partie graphique intégrée d’un Ryzen 5000U, n’est pas proposé et Immich conserve la reconnaissance sur le CPU"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
|
||||
@@ -104,6 +104,7 @@
|
||||
"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.",
|
||||
"Un répertoire de l’hôte est reconnu par son chemin et par le système de fichiers sur lequel il se trouve, et non par le nom de périphérique que l’hôte donne à son disque : un disque USB ou réseau qui revient sous un autre nom reste donc le même répertoire. Lorsque son disque n’est pas connecté, la mise à jour s’arrête avant que le CT ne soit arrêté et indique le répertoire manquant.",
|
||||
"Toute autre différence entre le CT et son contrat arrête la mise à jour avant que le CT ne soit arrêté."
|
||||
]
|
||||
}
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
},
|
||||
{
|
||||
"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>."
|
||||
"body": "Un disque du conteneur est créé sur un stockage Proxmox VE avec la taille indiquée. L’installation par défaut demande une seule fois le stockage du conteneur et de ses données lorsque le nœud en possède plusieurs ; 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",
|
||||
@@ -109,6 +109,9 @@
|
||||
},
|
||||
{
|
||||
"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."
|
||||
},
|
||||
{
|
||||
"p": "Un répertoire de l’hôte est monté avec tout ce que l’hôte a monté à l’intérieur. Un répertoire tel que <code>/mnt/pve</code> affiche ses partages réseau, disques et datasets dans le conteneur, et ce que l’hôte y monte ou démonte par la suite apparaît ou disparaît sans redémarrer le conteneur. Un répertoire ajouté en lecture seule est en lecture seule avec ce qui y est monté au démarrage du conteneur. Un système de fichiers que l’hôte monte ensuite arrive avec les permissions avec lesquelles l’hôte le monte, et passe lui aussi en lecture seule au redémarrage du conteneur."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Scripts communautaires",
|
||||
"body": "Le menu propose aussi deux scripts tiers du projet <a>community-scripts</a> : <em>Proxmox VE Post Install</em> et <em>Proxmox VE Microcode</em>. Ces enveloppes téléchargent et exécutent les scripts originaux via <code>wget | bash</code>. ProxMenux ne les maintient pas. Consultez <link>Dépôts externes</link> pour les détails et les questions de confiance avant de les lancer."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "Sur Proxmox Backup Server",
|
||||
"body": "Sur un hôte Proxmox Backup Server, le même menu s'ouvre depuis <strong>Paramètres post-installation de Proxmox</strong> dans le menu PBS. Automatisé, Personnalisable, Appliquer les mises à jour disponibles et Désinstaller les optimisations fonctionnent comme sur Proxmox VE, avec ces différences :",
|
||||
"items": [
|
||||
"<strong>Dépôts et mise à niveau :</strong> lorsque le serveur n'a pas d'abonnement et que seul le dépôt Enterprise de PBS est actif, ProxMenux demande avant de passer au dépôt sans abonnement de PBS. Le changement passe par l'API des dépôts du serveur lui-même, celle utilisée par <em>Administration > Repositories</em>. Avec un abonnement actif, ou un dépôt sans abonnement ou de test déjà configuré, les sources restent telles quelles.",
|
||||
"<strong>Liste personnalisable :</strong> les options qui ne concernent que Proxmox VE ne sont pas proposées : agent invité, VFIO IOMMU, Open vSwitch, vitesse des sauvegardes vzdump, pigz, Appliance Manager, Ceph, haute disponibilité et OVH Real Time Monitoring.",
|
||||
"<strong>Bannière d'abonnement :</strong> le correctif s'applique à l'interface web de Proxmox Backup Server, et Désinstaller les optimisations la restaure.",
|
||||
"<strong>Figurine :</strong> s'installe sans les alias de Proxmox VE.",
|
||||
"<strong>Scripts communautaires :</strong> la section propose <em>Proxmox Backup Server Post Install</em> et <em>Proxmox Backup Server Microcode</em> à la place des scripts de Proxmox VE."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
|
||||
Reference in New Issue
Block a user