mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +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
@@ -118,7 +118,7 @@
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Notifica (start)",
|
||||
"detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
|
||||
"detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate nel Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "Il layout dell'archivio non cambia con la destinazione",
|
||||
"body": "All'interno di una delle tre destinazioni, lo stesso layout <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descritto in <em>Come funziona</em> è presente. Un <code>.tar.zst</code> estratto da un archivio locale, un <code>.pxar</code> restaurato da PBS, e un archivio Borg estratto con <code>borg extract</code> producono tutti un albero di directory identico. Il percorso del codice di ripristino (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano."
|
||||
"body": "Ovunque sia archiviato il backup, contiene sempre gli stessi tre blocchi descritti in <em>Come funziona</em>: il filesystem (<code>rootfs/</code>), i metadati (<code>metadata/</code>) e il manifesto (<code>manifest.json</code>). L’estrazione di un archivio locale <code>.tar.zst</code>, il ripristino di un <code>.pxar</code> da PBS o l’estrazione di un archivio Borg producono tutti un albero di directory identico. Il ripristino legge quindi sempre gli stessi file, qualunque sia la destinazione da cui proviene il backup."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Estrazione di un backup al di fuori di ProxMenux",
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Selezione dei repository",
|
||||
"intro": "ProxMenux scopre i repository PBS da due fonti su ogni backup. L'operatore sceglie uno da un menu unificato; la scelta determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> per l'esecuzione.",
|
||||
"intro": "ProxMenux individua i repository PBS da due fonti a ogni backup. L’utente ne sceglie uno da un menu unificato; per quell’esecuzione, la scelta determina il server e il datastore a cui viene inviato il backup, la password con cui si autentica e l’<em>impronta digitale</em> che convalida il certificato.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg di Proxmox (rilevamento automatico)",
|
||||
@@ -46,7 +46,7 @@
|
||||
"backupIdTitle": "Nome ID di backup",
|
||||
"backupIdBody": "L’ID di backup predefinito è <code>hostcfg-HOSTNAME</code>. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in <code>[A-Za-z0-9_-]</code> e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un <em>gruppo</em> e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.",
|
||||
"pxarTitle": "Perché la fonte è la radice di staging completa",
|
||||
"pxarBody": "La sorgente <code>.pxar</code> è l'intero <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> insieme. Le versioni precedenti hanno superato <code>$staging_root/rootfs</code> come fonte; che ha lasciato <code>metadata/</code> fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-<code>_rs_check_layout</code> di 3, che avvolge un albero <code>etc/var/root/usr</code> piatto di nuovo in una gerarchia <code>rootfs/</code>."
|
||||
"pxarBody": "L’archivio <code>.pxar</code> racchiude l’intera directory di lavoro: il filesystem dell’host (<code>rootfs/</code>), i metadati (<code>metadata/</code>) e il manifesto (<code>manifest.json</code>). Durante il ripristino, ProxMenux confronta il manifesto con l’host di destinazione per stabilire se sono equivalenti, se l’hardware è cambiato o se si tratta di una macchina diversa, e adatta il processo di conseguenza. I backup più vecchi, creati da versioni precedenti di ProxMenux che includevano solo il filesystem, si ripristinano ancora correttamente: il ripristino rileva quel formato precedente e lo riorganizza automaticamente."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Crittografia lato cliente",
|
||||
@@ -63,7 +63,7 @@
|
||||
"recoveryTitle": "Caricare la chiave su PBS: decide l’operatore",
|
||||
"recoveryBody": "Subito dopo la scelta del file di chiave, ProxMenux pone la domanda esplicita <em>Caricare la chiave su PBS?</em>, con due risposte. <strong>Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì.</strong> L’opzione predefinita è <em>No, conserva solo in locale</em>: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante <em>Scarica il file di chiave</em> del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo <em>Sì, carica</em>, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo <code>pbs-key.recovery.enc</code>. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.",
|
||||
"blobUploadTitle": "Gruppo di backup abbinato su PBS",
|
||||
"blobUploadBody1": "Quando la modalità escrow è <em>Sì, carica</em>, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in <code>-keyrecovery</code>. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. <strong>La busta non lascia mai l'host in plaintext</strong>: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
|
||||
"blobUploadBody1": "Quando la risposta è <em>Sì, carica</em>, ProxMenux carica la busta di recupero su PBS dopo ogni backup crittografato, come secondo gruppo di backup abbinato con lo stesso nome del gruppo dell’host ma che termina in <code>-keyrecovery</code>. I due gruppi compaiono uno accanto all’altro nell’elenco del datastore: uno per i backup dell’host, uno per le buste di recupero. <strong>La busta non lascia mai l’host in chiaro</strong>: la crittografia avviene sull’host stesso con AES-256-CBC e PBKDF2 prima che qualsiasi byte venga trasmesso (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
|
||||
"envelopeSecurityTitle": "Caricare il file keyrecovery a PBS è un rischio di sicurezza?",
|
||||
"envelopeSecurityBody": "Il file keyrecovery è crittografato in transito e a riposo. Il passphrase di recupero non lascia mai l'host: la crittografia avviene localmente prima del caricamento, e PBS vede solo il risultato già crittografato. Un amministratore PBS — o chiunque abbia accesso al datastore — può scaricare il file di keyrecovery, ma senza la passphrase di recupero non può leggere il keyfile all'interno: è un codice opaco. Ricostruire il keyfile richiede entrambi i pezzi contemporaneamente, il file keyrecovery e la passphrase, e solo l'operatore tiene entrambi.",
|
||||
"blobUploadConstraintTitle": "Perché servono due gruppi anziché un unico gruppo crittografato",
|
||||
@@ -73,7 +73,7 @@
|
||||
"recoverTitle": "Recupero su un host fresco",
|
||||
"recoverBody": "Quando il file di chiave manca nel percorso canonico, dopo una reinstallazione o una rimozione esplicita, il ripristino prova tre fonti in ordine e si ferma alla prima che fornisce una chiave utilizzabile. Prima, se il repository PBS selezionato ha una chiave corrispondente gestita da PVE in <code>/etc/pve/priv/storage/<NAME>.enc</code>, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo <code>-keyrecovery</code>, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce <code>wrong key — manifest's key XX does not match provided key YY</code>. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.",
|
||||
"monitorManagementTitle": "Gestione del keyfile dal Monitor",
|
||||
"monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: <em>Scarica</em> esporta il file attuale nel browser; <em>Carica</em> sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; <em>Elimina</em> rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce."
|
||||
"monitorManagementBody": "Il Monitor mostra i controlli del file di chiave in ogni riga di destinazione PBS della pagina di configurazione dei backup. La riga offre tre azioni: <em>Scarica</em> esporta il file di chiave attuale nel browser dell’utente, <em>Carica</em> sostituisce il file di chiave installato con uno fornito dall’utente (il file precedente viene sovrascritto solo dopo che il nuovo è arrivato correttamente nel suo percorso) ed <em>Elimina</em> rimuove il file di chiave dall’host. Subito accanto si trova l’interruttore della busta di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase che compare quando si seleziona Sì e un pulsante che segue lo stato attuale: <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. I controlli del Monitor e la finestra di dialogo della shell eseguono internamente le stesse operazioni, quindi il risultato su disco e su PBS è identico qualunque dei due si utilizzi."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperare sul lato del ripristino",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validazione schema",
|
||||
"schemaBody": "Il manifesto convalida contro <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'esecuzione di <code>build_manifest.sh --validate</code> attiva una validazione dello schema JSON (richiede <code>python3</code> + <code>jsonschema</code>). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime."
|
||||
"schemaBody": "ProxMenux include un modello che descrive quali campi deve contenere il manifesto e la forma di ciascuno. Quando viene generato un backup, il manifesto può essere verificato automaticamente rispetto a quel modello, così un collettore che ha prodotto un JSON malformato o un campo scritto in modo errato viene individuato subito. La verifica è pensata per lo sviluppo di ProxMenux stesso: su un sistema in cui non è installata, il backup funziona come di consueto e il manifesto viene generato comunque."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "inventario delle applicazioni",
|
||||
|
||||
@@ -105,7 +105,7 @@
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Il nodo di rendering, <code>/dev/kfd</code> e la generazione indicata dal driver di calcolo in <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"Una generazione per cui l’immagine ROCm dell’applicazione include kernel di calcolo — le GPU RDNA2 indicate e quelle più recenti — viene proposta così com’è. Le altre GPU di queste famiglie, come Radeon 680M e 780M, sono proposte come sperimentali e non sono mai preselezionate: ROCm non le supporta ufficialmente, l’applicazione le presenta come la generazione della rispettiva famiglia (<code>HSA_OVERRIDE_GFX_VERSION</code>) e l’installatore chiede conferma prima di scaricare l’immagine più grande. Una GPU precedente, come la grafica integrata di un Ryzen 5000U, non viene proposta e Immich mantiene il riconoscimento sulla CPU."
|
||||
"Una GPU di una generazione supportata dall’immagine ROCm dell’applicazione (le GPU RDNA2 che indica e quelle più recenti) viene proposta così com’è. Le altre GPU di queste famiglie, come Radeon 680M e 780M, sono proposte come sperimentali e non sono mai l’opzione suggerita. ROCm non le supporta ufficialmente: l’applicazione le presenta come la generazione della rispettiva famiglia (<code>HSA_OVERRIDE_GFX_VERSION</code>) e l’installatore chiede conferma prima di scaricare l’immagine più grande. Una GPU precedente, come la grafica integrata di un Ryzen 5000U, non viene proposta e Immich mantiene il riconoscimento sulla CPU"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
|
||||
@@ -104,6 +104,7 @@
|
||||
"La nuova immagine viene verificata livello per livello prima di arrestare il CT. Un download danneggiato viene ripetuto una seconda volta; un’immagine già nella cache che non supera la verifica viene scaricata di nuovo.",
|
||||
"Le impostazioni modificate in Proxmox VE dopo l’installazione (memoria, swap, core, limite e priorità della CPU, avvio con il nodo) vengono conservate e incluse nel nuovo contratto.",
|
||||
"L'interfaccia LAN che la suite Arr e le applicazioni multi-container aggiungono (<code>net1</code>) e l'ordine di avvio (<code>startup</code>) sono restituiti al nuovo contenitore come sono.",
|
||||
"Una directory dell’host viene riconosciuta dal suo percorso e dal filesystem su cui si trova, non dal nome di dispositivo che l’host assegna al suo disco, quindi un disco USB o di rete che ricompare con un altro nome resta la stessa directory. Quando il suo disco non è collegato, l’aggiornamento si interrompe prima che il CT venga arrestato e indica la directory mancante.",
|
||||
"Qualsiasi altra differenza tra il CT e il suo contratto interrompe l’aggiornamento prima che il CT venga arrestato."
|
||||
]
|
||||
}
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Storage e dimensione",
|
||||
"body": "Viene creato un disco del container su uno storage Proxmox VE con la dimensione indicata. L’installazione predefinita usa <code>local-lvm</code>; quella avanzata chiede lo storage di ogni percorso subito prima della dimensione e propone quello del rootfs. Il disco appare come <code>vm-VMID-disk-N</code> e viene collegato come <code>mpN</code>."
|
||||
"body": "Viene creato un disco del container su uno storage Proxmox VE con la dimensione indicata. L’installazione predefinita chiede una sola volta lo storage del container e dei suoi dati quando il nodo ne ha più di uno; quella avanzata chiede lo storage di ogni percorso subito prima della dimensione e propone quello del rootfs. Il disco appare come <code>vm-VMID-disk-N</code> e viene collegato come <code>mpN</code>."
|
||||
},
|
||||
{
|
||||
"title": "Directory dell’host",
|
||||
@@ -109,6 +109,9 @@
|
||||
},
|
||||
{
|
||||
"p": "Il rootfs è riservato ai binari e al contenuto dell’immagine. Un aggiornamento o una ricreazione lo sostituisce senza toccare nessuno dei due tipi di punto di mount."
|
||||
},
|
||||
{
|
||||
"p": "Una directory dell’host viene montata con tutto ciò che l’host vi ha montato all’interno. Una directory come <code>/mnt/pve</code> mostra nel container le sue condivisioni di rete, i dischi e i dataset, e ciò che l’host vi monta o smonta in seguito compare o scompare senza riavviare il container. Una directory aggiunta in sola lettura è in sola lettura insieme a ciò che vi è montato all’avvio del container. Un filesystem che l’host monta successivamente arriva con i permessi con cui l’host lo monta e diventa anch’esso di sola lettura al riavvio del container."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Script della community",
|
||||
"body": "Il menu offre anche due script di terze parti del progetto <a>community-scripts</a>: <em>Proxmox VE Post Install</em> e <em>Proxmox VE Microcode</em>. Sono wrapper che scaricano ed eseguono gli script originali tramite <code>wget | bash</code>. ProxMenux non li mantiene. Vedi <link>Repository esterni</link> per dettagli e valutazioni sull’affidabilità prima di eseguirli."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "Su Proxmox Backup Server",
|
||||
"body": "Su un host Proxmox Backup Server, lo stesso menu si apre da <strong>Impostazioni post-installazione Proxmox</strong> nel menu PBS. Automatizzato, Personalizzabile, Applica aggiornamenti disponibili e Disinstalla ottimizzazioni funzionano come su Proxmox VE, con queste differenze:",
|
||||
"items": [
|
||||
"<strong>Repository e aggiornamento:</strong> quando il server non ha un abbonamento ed è attivo solo il repository Enterprise di PBS, ProxMenux chiede conferma prima di passare al repository no-subscription di PBS. Il cambio passa per l'API dei repository del server stesso, la stessa usata da <em>Administration > Repositories</em>. Con un abbonamento attivo, o con un repository no-subscription o di test già configurato, le sorgenti restano invariate.",
|
||||
"<strong>Elenco personalizzabile:</strong> le opzioni valide solo per Proxmox VE non vengono mostrate: guest agent, VFIO IOMMU, Open vSwitch, velocità dei backup vzdump, pigz, Appliance Manager, Ceph, alta disponibilità e OVH Real Time Monitoring.",
|
||||
"<strong>Banner dell'abbonamento:</strong> la patch si applica all'interfaccia web di Proxmox Backup Server e Disinstalla ottimizzazioni la ripristina.",
|
||||
"<strong>Figurine:</strong> si installa senza gli alias di Proxmox VE.",
|
||||
"<strong>Script della community:</strong> la sezione offre <em>Proxmox Backup Server Post Install</em> e <em>Proxmox Backup Server Microcode</em> al posto degli script di Proxmox VE."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Correlati",
|
||||
"items": [
|
||||
|
||||
Reference in New Issue
Block a user