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

This commit is contained in:
MacRimi
2026-10-18 13:43:53 +02:00
320 changed files with 37750 additions and 1089 deletions
@@ -0,0 +1,13 @@
{
"meta": {
"title": "Codice di condotta | Documentazione ProxMenux",
"description": "Codice di condotta e buone pratiche di ProxMenux per collaboratori, tester e utenti.",
"ogTitle": "Codice di condotta | Documentazione ProxMenux",
"ogDescription": "Aspettative sulla responsabilità del codice, sulla segnalazione delle vulnerabilità e sull’ambito delle PR nel progetto ProxMenux."
},
"errors": {
"notFound": "Errore: file CODE_OF_CONDUCT.md non trovato.",
"loadFailed": "Errore: impossibile caricare il contenuto del codice di condotta."
},
"contentMarkdown": "# 📝 Codice di condotta e buone pratiche\n\nQuesto documento definisce i **principi e le linee guida** per l’uso di **ProxMenux**, promuovendo **rispetto, collaborazione e sicurezza** nello sviluppo.\n\n## 📌 1. Attribuzione del codice e riconoscimenti\n\n- Se si usano **script, frammenti di codice o idee** di altri repository o sviluppatori, l’autore originale verrà sempre citato.\n- Un commento nel codice o nella documentazione indicherà la fonte e, se possibile, un collegamento al repository originale.\n- Quando si utilizza codice con una **licenza** specifica, occorre rispettarne le condizioni.\n\n### ✅ Esempio di attribuzione corretta nel codice:\n\n```bash\n# Script basato sul lavoro di [Autore] in [Link al repository]\n```\n\n## 🔒 2. Sicurezza e responsabilità del codice\n\n- Tutto il codice di questo repository segue le buone pratiche di sviluppo sicuro.\n- Non sono ammessi contributi che introducano vulnerabilità intenzionali o pratiche non sicure.\n- Gli script non devono mai compromettere la sicurezza del sistema o i dati degli utenti.\n- Prima dell’implementazione, i contributi vanno revisionati per verificarne sicurezza e stabilità.\n\n### ⚠️ Divulgazione responsabile delle vulnerabilità\n\nSe scopri una vulnerabilità di sicurezza, NON segnalarla in issue o forum pubblici.\n\nComunicala invece in privato tramite e-mail:\n\n📧 proxmenux@macrimi.pro\n\nPer maggiori informazioni sulle vulnerabilità e su come segnalarle, consulta la nostra [politica di sicurezza](./SECURITY.md).\n\n## 🤝 3. Regole della comunità\n\nPer mantenere un ambiente rispettoso e professionale, tutti gli utenti devono seguire queste regole:\n\n- ✅ Mantieni un atteggiamento rispettoso e costruttivo nelle discussioni.\n- ❌ Non saranno tollerati molestie, discorsi d’odio o comportamenti offensivi.\n- ✅ Fornisci riscontri in modo professionale, evitando attacchi personali.\n- ❌ Le violazioni possono comportare avvertimenti o esclusioni, in base alla gravità.\n\n##\n\nQuesto documento promuove l’uso etico del codice, la consapevolezza della sicurezza e una comunità rispettosa.\n\n📢 Costruiamo insieme qualcosa di straordinario!\n"
}
@@ -0,0 +1,293 @@
{
"meta": {
"title": "Contributo a ProxMenux | Documentazione ProxMenux",
"description": "Come contribuire a ProxMenux: modello dei rami (main / develop / feature/*), procedura delle pull request, intestazione con autore e link di sostegno facoltativo, interfaccia in due fasi, funzioni dei messaggi e passaggio da un ramo di funzionalità a una versione stabile.",
"ogTitle": "Contributi a ProxMenux",
"ogDescription": "Modello dei rami, procedura, attribuzione nell’intestazione e regola dell’interfaccia in due fasi per chi contribuisce."
},
"header": {
"title": "Contributi a ProxMenux",
"description": "ProxMenux è aperto ai contributi comunitari — nuovi script, correzioni per quelli esistenti, miglioramenti di dialogo, traduzioni, integrazioni. Questa pagina è la porta formale: come il repository è strutturato, il modello di ramificazione e il flusso di lavoro di pull-request, l'intestazione dello script con attribuzione dell'autore e link di sponsor opzionale, e le convenzioni di progettazione ogni contributo deve seguire.",
"section": "Informazioni"
},
"twoPagesCallout": {
"title": "Due pagine correlate, un progetto",
"body": "Non confondere questa pagina con <contributorsLink>Collaboratori</contributorsLink>, che riconosce il lavoro di tester, revisori e sviluppatori già coinvolti. Questa pagina è per <em>te</em>, futuro collaboratore, e spiega come preparare una pull request da integrare."
},
"branching": {
"heading": "Modello di ramificazione",
"intro": "ProxMenux utilizza un modello di ramificazione a tre livelli:",
"headerBranch": "Ramo",
"headerPurpose": "Scopo",
"rows": [
{
"branch": "main",
"purposeRich": "Codice stabile, pronto per la produzione. Qui vengono integrate solo modifiche pronte per il rilascio. È la versione ricevuta con un’installazione normale di ProxMenux."
},
{
"branch": "develop",
"purposeRich": "Ramo di sviluppo attivo. Il nuovo lavoro viene integrato prima qui: è il canale beta. Quando una versione stabile è pronta, viene trasferita da qui a <code>main</code>."
},
{
"branch": "feature/*",
"purposeRich": "Rami temporanei per una funzionalità, una correzione o un miglioramento. Creati da <code>develop</code> e reintegrati in <code>develop</code> tramite pull request dopo la revisione."
}
],
"calloutTitle": "Ciò significa per gli utenti",
"calloutBody": "Chi segue <code>main</code> riceve versioni testate. Chi vuole prima le novità e accetta qualche imperfezione può seguire <code>develop</code>. Le nuove funzioni passano sempre prima da <code>develop</code>; nulla arriva in <code>main</code> senza questo ciclo."
},
"workflow": {
"heading": "Procedura delle pull request",
"intro": "Dall'idea alla fusione del rilascio in cinque fasi:",
"step1Lead": "<strong>Crea un ramo per la funzionalità da <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": "Utilizzare un nome di ramo descrittivo: <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
"step2Lead": "<strong>Lavora alle modifiche e pubblica il ramo:</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>Apri una pull request verso <code>develop</code></strong>, non verso <code>main</code>. Su GitHub verifica che il ramo di base sia <code>develop</code>. Descrivi cosa fa e modifica lo script e su quali versioni di Proxmox VE è stato testato.",
"step4": "<strong>Dopo la revisione le modifiche vengono integrate in <code>develop</code>.</strong> Un manutentore verifica codice, intestazione e interfaccia in due fasi. Se richiede modifiche, aggiungi commit allo stesso ramo: la PR si aggiorna automaticamente.",
"step5": "<strong>Le versioni stabili passano da <code>develop</code> a <code>main</code>.</strong> Al rilascio, <code>main</code> viene portato a <code>develop</code> con un fast-forward e riceve un tag. Il tuo contributo entra nella prossima versione stabile."
},
"scriptHeader": {
"heading": "Intestazione script — metadati & descrizione",
"intro": "Ogni script ProxMenux inizia con due blocchi di commenti adiacenti che formano l’intestazione. Sono <strong>entrambi obbligatori</strong>: indicano autore e scopo senza dover leggere il corpo del codice.",
"bullets": [
"<strong>Blocco superiore: metadati.</strong> Autore, link GitHub/di sostegno facoltativi, manutentore, copyright, licenza, versione e data di aggiornamento. Qui avviene il <em>riconoscimento dei collaboratori</em>: per un nuovo script inserisci il tuo nome e, facoltativamente, la pagina GitHub e un profilo come Ko-fi, GitHub Sponsors o Buy Me a Coffee.",
"<strong>Blocco inferiore: descrizione.</strong> Un breve paragrafo in inglese semplice spiega il compito dello script. Si legge <em>prima</em> del codice e deve chiarire da solo scopo, azioni principali, risorse coinvolte e prerequisiti."
],
"licenseCalloutTitle": "La linea di licenza è fissa — GPL-3.0",
"licenseCalloutBody": "ProxMenux è pubblicato sotto <strong>GNU General Public License v3.0</strong>. Tutti gli script usano la stessa licenza: la riga <code>License</code> nell’intestazione deve essere il riferimento GPL-3.0 dell’esempio seguente, non una scelta per singolo script. Contribuendo accetti il rilascio sotto GPL-3.0: chiunque può leggere, modificare e ridistribuire lo script e le modifiche mantenendo la stessa licenza. Testo completo: <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": "Le linee <code>GitHub</code> e <code>Sponsor</code> sono facoltative: lasciatele fuori se non volete pubblicarle. Tutto il resto è richiesto.",
"whyCalloutTitle": "Perché questo è importante",
"whyCalloutBody": "Contribuire all’open source è un lavoro volontario. Il nome e l’eventuale link di sostegno nel codice rendono visibile l’autore a ogni lettura, senza nasconderlo dietro il progetto. La descrizione ha un altro scopo: è la prima cosa letta da un futuro manutentore o utente curioso. La sua chiarezza spesso determina se ci si fida dello script o lo si evita."
},
"structure": {
"heading": "Struttura del progetto",
"intro": "Dove ogni tipo di script vive nel repository:",
"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": "Ogni script carica <code>utils.sh</code> all’avvio tramite source per avere funzioni dei messaggi, indicatore di attesa, colori e sistema di traduzione. Le librerie condivise in <code>scripts/global/</code> vengono caricate esplicitamente dagli script che ne hanno bisogno."
},
"twoPhase": {
"heading": "La politica di progettazione dell'interfaccia utente bifase",
"intro": "È la convenzione più importante di ProxMenux e quella per cui vengono richieste più spesso correzioni alle PR. Ogni script è diviso in <strong>esattamente due fasi</strong>:",
"headerPhase": "Fase",
"headerPurpose": "Scopo",
"headerScreen": "Stato dello schermo",
"rows": [
{
"phaseRich": "<strong>Phase 1 — Selezione</strong>",
"purposeRich": "Raccogliere ogni decisione dell'utente. Eseguire qualsiasi lavoro preparatorio necessario (sonde, scansioni, controlli).",
"screenRich": "Finestre <code>dialog</code>. Se una verifica tra due menu richiede più di uno o due secondi, mostra l’indicatore di attesa <code>msg_info</code> perché l’utente sappia che lo script non è bloccato, poi chiama <code>stop_spinner</code> subito prima del prossimo dialogo."
},
{
"phaseRich": "<strong>Phase 2 — Esecuzione</strong>",
"purposeRich": "Eseguire ogni operazione. Visualizza la storia del progresso completo che si accumula sullo schermo.",
"screenRich": "Messaggi <code>msg_info</code> / <code>msg_ok</code> visibili; mai <code>dialog</code>."
}
],
"principle": "Il principio è <strong>raccogliere prima tutte le scelte, poi eseguire tutto</strong>. L’utente vede prima menu ordinati con dialoghi (fase 1), poi una vista di esecuzione come un log (fase 2). Le fasi non si mescolano: niente dialoghi durante l’esecuzione né messaggi di avanzamento durante la selezione.",
"phase1Heading": "Fase 1 — modello tipico",
"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": "<strong>Regole per la fase 1:</strong>",
"phase1Rules": [
"Se è attivo un indicatore <code>msg_info</code> e devi aprire un menu <code>dialog</code> o <code>whiptail</code>, chiama prima <code>stop_spinner</code>: l’indicatore non può convivere con l’overlay dei due strumenti. Se nessun indicatore è attivo, la chiamata non serve.",
"Usa <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code> per dare un contesto visivo a un’operazione lunga nella fase 1, ad esempio una verifica di oltre cinque secondi. La funzione pulisce già lo schermo: non chiamare prima <code>clear</code>.",
"Non chiamare <code>show_proxmenux_logo</code> tra i menu di dialogo in cui non c'è nulla da mostrare — cancellare lo schermo per un terminale vuoto è solo rumore visivo.",
"Conservare tutte le decisioni e i risultati della sonda in variabili o array paralleli. Il recap visibile avviene all'inizio della fase 2, non in fase 1."
],
"phase2Heading": "Fase 2 — modello tipico",
"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>Regole per la fase 2:</strong> inizia con <code>show_proxmenux_logo + msg_title</code> e riepiloga subito la fase 1 con righe <code>msg_ok</code>. Non richiamare <code>show_proxmenux_logo</code>, perché cancellerebbe il progresso accumulato. Non usare <code>dialog</code>; se una scelta durante l’esecuzione è inevitabile, usa <code>whiptail</code> come spiegato nella sezione seguente."
},
"dialogVsWhiptail": {
"headingRich": "Quando utilizzare <code>dialog</code> vs <code>whiptail</code>",
"intro": "Entrambi gli strumenti disegnano interfacce utente in modalità testo, ma si comportano molto diversamente sullo schermo — e ProxMenux li utilizza in due fasi distinte per un motivo.",
"headerTool": "Strumento",
"headerWhen": "Quando usarlo",
"headerEffect": "Effetti sullo schermo",
"rows": [
{
"toolRich": "<strong><code>dialog</code></strong>",
"whenRich": "<strong> Sempre in Fase 1.</strong> Ogni selezione interattiva — raccogliendo un VM, un disco, un filesystem, confermando un'azione — utilizza <code>dialog</code>. Questo è lo strumento UI predefinito di ProxMenux.",
"effectRich": "Prende il controllo del terminale: pulisce lo schermo, disegna l’interfaccia e alla chiusura ripristina lo stato precedente. Va bene nella fase 1, quando non ci sono ancora risultati utili da mostrare."
},
{
"toolRich": "<strong><code>whiptail</code></strong>",
"whenRich": "<strong>Solo in Fase 2, solo quando inevitabile.</strong> Il caso tipico è un prompt di riavvio alla fine dell'esecuzione. Non raggiungere <code>whiptail</code> per chiedere “continua?” mid-execution — tale decisione dovrebbe essere presa in fase 1.",
"effectRich": "Overlay più leggero che <em>non cancella</em> il contesto del terminale. La cronologia <code>msg_ok</code>/<code>msg_info</code> della fase 2 resta visibile dietro il dialogo. È quindi adatto quando l’avanzamento è già sullo schermo."
}
],
"calloutTitle": "Perché la divisione conta",
"calloutBody": "Se si chiama <code>dialog</code> nel mezzo della fase 2, ogni linea <code>msg_ok</code> l'utente sta guardando scompare. Tu pulisci la pista di controllo. <code>whiptail</code> lo evita. Quindi la regola non è arbitraria — si tratta di preservare la vista dell'utente di ciò che lo script ha fatto finora.",
"rebootHeading": "Richiesta di riavvio: il caso tipico di whiptail nella fase 2",
"rebootIntro": "Quando uno script termina e un riavvio può essere richiesto (ad es. IOMMU abilitato, parametri del kernel modificati), il prompt alla fine della fase 2 utilizza <code>whiptail</code>. Sempre includere un ramo “No” che avverte l’utente di non utilizzare la risorsa interessata fino al riavvio:",
"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": "Funzioni di messaggio",
"intro": "Tutti definiti in <code>utils.sh</code>. Utilizzarli come predefinito per qualsiasi output visibile dall'utente — visuali coerenti tra gli script è l'intero punto. Se il tuo script ha bisogno di una nuova funzione che non si adatta al set esistente (un nuovo livello di gravità, un nuovo aiutante di layout, ecc.), proporlo nella tua richiesta di pull — sarà rivisto e aggiunto a <code>utils.sh</code> se è ampiamente utile.",
"headerFunction": "Funzione",
"headerWhen": "Quando usare",
"headerSpinner": "Indicatore di avanzamento",
"rows": [
{
"function": "msg_info \"text\"",
"whenRich": "Operazione in corso.",
"spinner": "Inizia"
},
{
"function": "stop_spinner",
"whenRich": "Fine del lavoro preparatorio silenzioso in Fase 1 — uccide spinner, cancella la linea.",
"spinner": "Arresta"
},
{
"function": "msg_ok \"text\"",
"whenRich": "L'operazione è riuscita. Utilizzare anche per “funzione abilitata” anche quando è richiesto un riavvio.",
"spinner": "Arresta"
},
{
"function": "msg_warn \"text\"",
"whenRich": "Avvertenza effettiva o stato degradato.",
"spinner": "Arresta"
},
{
"function": "msg_error \"text\"",
"whenRich": "Errore fatale.",
"spinner": "Arresta"
},
{
"function": "msg_info2 \"text\"",
"whenRich": "Avviso non bloccante, su una riga informativa ciano.",
"spinner": "Arresta"
},
{
"function": "msg_success \"text\"",
"whenRich": "Messaggio finale «Premi Invio per tornare» alla fine della fase 2.",
"spinner": "Arresta"
},
{
"function": "msg_title \"text\"",
"whenRich": "Titolo in grassetto con spaziatura integrata. Usato all’inizio della fase 2.",
"spinner": "—"
},
{
"function": "show_proxmenux_logo",
"whenRich": "Pulisce lo schermo e mostra il logo. Da chiamare <em>una sola volta</em> all’inizio della fase 2.",
"spinner": "—"
}
]
},
"dialogConventions": {
"heading": "convenzioni di dialogo",
"bullets": [
"Passa sempre <code>--backtitle \"$BACKTITLE\"</code> ad ogni chiamata <code>dialog</code> e <code>whiptail</code>. <code>$BACKTITLE</code> è sempre <code>\"ProxMenux\"</code> — impostato una volta all'intestazione dello script e mai sovrascritto. L'utente deve sempre vedere il nome del progetto come il contesto di inquadramento, mai il titolo dello script.",
"Avvolgi sempre titoli e messaggi con <code>$(translate \"...\")</code>.",
"Reindirizza sempre l'output <code>dialog</code> con <code>2&gt;&amp;1 &gt;/dev/tty</code> — lo stdout catturato diventa la selezione dell'utente, mentre la finestra di dialogo si disegna sul terminale.",
"Utilizzare le variabili standard di dimensione dell'interfaccia utente (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, ecc.) per un dimensionamento coerente tra gli script.",
"Controlla sempre le selezioni vuote o annullate e gestiscile correttamente."
],
"exampleIntro": "Esempio completo: creare un menu di selezione della VM e gestire l’annullamento.",
"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": "Politica di traduzione",
"intro": "Tutte le stringhe visualizzabili dall'utente devono essere avvolte con la funzione <code>translate</code>. ProxMenux li traduce automaticamente in tutte le lingue supportate — scrivi inglese, l'utente legge la loro lingua madre.",
"code": "msg_ok \"$(translate \"Operation completed successfully.\")\"\nmsg_error \"$(translate \"Failed to start container\") $CTID.\"\ndialog --title \"$(translate \"Select Storage\")\" ...",
"bullets": [
"Scrivere stringhe in inglese — la traduzione viene gestita automaticamente dalla build.",
"Mantieni concise le stringhe. Evita, se possibile, variabili all’interno di frasi lunghe.",
"<strong>non</strong> tradurre nomi di variabili, percorsi o identificatori tecnici."
]
},
"variableStyle": {
"heading": "Convenzioni variabili e di stile",
"bullets": [
"Utilizzare <code>UPPER_CASE</code> per le variabili a livello di script.",
"Utilizzare <code>lower_case</code> per le variabili di funzione locali (dichiarazione con <code>local</code>).",
"Quotare tutte le espansioni variabili: <code>\"$VAR\"</code> — non <code>$VAR</code>.",
"Utilizzare <code>[[ ]]</code> per condizionali, non <code>[ ]</code> (eccetto dove è richiesto il POSIX).",
"<code>show_proxmenux_logo</code> è il modo previsto per pulire lo schermo: lo cancella e mostra il logo del progetto per dare un contesto visivo. Chiamalo una volta all’inizio della fase 2, e facoltativamente prima di una lunga attesa nella fase 1."
],
"standardNamesIntro": "Nomi variabili standard nel progetto:",
"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": "Reindirizza l'output dello strumento durante la fase 2",
"redirectIntro": "La fase 2 mostra un log di righe <code>msg_info → msg_ok</code>. Se uno strumento chiamato, come apt, mkfs, qm, pct o dd, scrive su stdout/stderr, il suo output fa scorrere i messaggi e confonde la vista. L’utente non distingue più l’avanzamento dello script dai dettagli dello strumento.",
"withoutRedirectIntro": "<strong>Senza reindirizzare</strong> — ciò che l'utente vede se non si gestisce il rumore:",
"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>Con redirect</strong> — quale sia la stessa operazione quando il rumore viene inviato altrove:",
"withRedirectCode": "ℹ Installing kernel package...\n✓ Kernel installed.\nℹ Configuring kernel command line...\n✓ Configured.\nℹ Refreshing boot loader...\n✓ Boot loader updated.",
"twoPatternsIntro": "Due modelli tra cui scegliere:",
"discardLead": "<strong>Scarta l’output</strong> quando non serve: è la soluzione più semplice e rapida.",
"discardCode": "DEBIAN_FRONTEND=noninteractive apt-get install -y \"$package\" >/dev/null 2>&1",
"logLead": "<strong>Inviare l'output a un file di registro</strong> quando si può desiderare di ispezionare in seguito (debugging un'installazione fallita, controllando ciò che dpkg effettivamente fatto). Questo è il modello preferito per qualsiasi operazione apt:",
"logCode": "apt-get install -y \"$package\" >> \"$log_file\" 2>&1",
"referenceOutro": "Lo script <code>scripts/global/update-pve9_2.sh</code> è un'implementazione di riferimento — ogni chiamata <code>apt-get</code> invia l'output a un file di registro in modo che l'utente vede solo il flusso <code>msg_info → msg_ok</code> pulito, mentre il log su disco consente di ricostruire esattamente ciò che ha fatto apt se qualcosa va storto."
},
"dosAndDonts": {
"heading": "Cosa fare e cosa non fare",
"doHeading": "✅ Da fare",
"doBullets": [
"<code>stop_spinner</code> prima di un <code>dialog</code> in Fase 1 solo quando un girante <code>msg_info</code> è in esecuzione.",
"La fase 2 inizia con <code>show_proxmenux_logo + msg_title + msg_ok</code> per riepilogare i risultati della fase 1.",
"Utilizzare <code>msg_ok</code> per funzioni abilitate con successo, anche se è necessario un riavvio.",
"Utilizzare <code>whiptail</code> (non <code>dialog</code>) per qualsiasi prompt post-esecuzione che deve apparire in Fase 2.",
"Sempre includere un ramo “No” nelle finestre di dialogo di riavvio che avverte l’utente di non avviare la risorsa interessata fino al riavvio.",
"Limita la logica riservata alle VM verificando <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code>: controller e NVMe PCIe non possono essere assegnati a LXC con passthrough PCI.",
"Utilizzare <code>ensure_repositories</code> da <code>utils-install-functions.sh</code> invece di <code>apt-get update</code> incondizionato.",
"Utilizzare array paralleli in Fase 1 quando ogni elemento ha bisogno di finestre di dialogo multiple."
],
"dontHeading": "❌ Da evitare",
"dontBullets": [
"Chiama <code>dialog</code> mentre uno spinner è attivo.",
"Saltare la fase 1 recap all'inizio della fase 2.",
"Chiama <code>show_proxmenux_logo</code> una seconda volta — cancella tutto Fase 2 ha stampato.",
"Utilizzare <code>dialog</code> in Fase 2 (usare <code>whiptail</code> per il raro caso inevitabile).",
"Usare il solo <code>clear</code>.",
"Avvolgere <code>msg_title</code> in linee vuote <code>echo \"\"</code> — include già spaziatura.",
"Utilizzare <code>msg_warn</code> per segnalare una funzione abilitata con successo: è un <code>msg_ok</code>.",
"Eseguire <code>apt-get update</code> incondizionato — utilizzare <code>ensure_repositories</code>."
]
},
"submitting": {
"heading": "Inviare il tuo contributo",
"steps": [
"Crea un fork di <code>MacRimi/ProxMenux</code> su GitHub e clonalo.",
"Crea un ramo <code>feature/*</code> da <code>develop</code> (vedi <em>Modello dei rami</em> sopra).",
"Segui questa guida per qualsiasi script nuovo o modificato. Scrivi l'intestazione con il tuo nome; aggiungi la linea di sponsor opzionale se vuoi.",
"Prova lo script su una vera istanza Proxmox VE: fase 1 con tutti i rami dei dialoghi e fase 2 con ogni operazione e il ripristino pulito in caso di errore.",
"Apri una pull request <strong>verso <code>develop</code></strong> con una descrizione chiara: cosa fa lo script, cosa è cambiato e su quale versione di Proxmox VE è stato testato.",
"Assicurati che il contributo rispetti il <cocLink>Codice di condotta</cocLink>."
],
"securityOutro": "Per problemi di sicurezza sensibili, segui la procedura di divulgazione in <securityLink>SECURITY.md</securityLink> invece di aprire una segnalazione pubblica."
},
"whereNext": {
"heading": "Come proseguire",
"items": [
{
"kind": "external",
"url": "https://github.com/MacRimi/ProxMenux/blob/main/CONTRIBUTING.md",
"label": "CONTRIBUTING.md (guida completa)",
"tail": "— la fonte di verità per ogni convenzione, compresi i modelli hardware avanzati."
},
{
"kind": "internal",
"href": "/docs/about/contributors",
"label": "Contributori",
"tail": "— le persone il cui lavoro ha plasmato le versioni ProxMenux (pagina diversa da questa)."
},
{
"kind": "internal",
"href": "/docs/about/code-of-conduct",
"label": "Codice di condotta",
"tail": "— gli standard che ogni collaboratore accetta di seguire."
},
{
"kind": "external",
"url": "https://github.com/MacRimi/ProxMenux/discussions",
"label": "GitHub Discussions",
"tail": "— chiedere prima di costruire se non sei sicuro se un'idea si adatta, o trovare collaboratori su una caratteristica più grande."
}
]
}
}
@@ -0,0 +1,38 @@
{
"meta": {
"title": "Contributori | Documentazione ProxMenux",
"description": "Un riconoscimento alle persone che rendono possibile ProxMenux: tester, revisori e sviluppatori che contribuiscono a ogni versione.",
"ogTitle": "Contributori | Documentazione ProxMenux",
"ogDescription": "Incontra i contributori dietro ProxMenux."
},
"header": {
"title": "Contributori",
"description": "Il progetto ProxMenux cresce grazie ai suoi collaboratori. Questa pagina riconosce il loro lavoro: provare le versioni prima della pubblicazione, individuare regressioni, esaminare le PR e orientare le nuove funzionalità.",
"section": "Informazioni"
},
"beyond": {
"title": "Oltre questa lista",
"body": "Molte altre persone contribuiscono segnalando bug, proponendo funzionalità in Discussions, provando le versioni beta e traducendo il progetto. L’elenco completo dei collaboratori al codice si trova nel <extlink>grafico dei contributori di GitHub</extlink>. Questa pagina presenta chi partecipa più attivamente ai test e alla revisione delle versioni di ProxMenux."
},
"testers": {
"heading": "Tester e recensori",
"intro": "Queste persone sono state tra le prime a contribuire al progetto. I loro test, le segnalazioni di problemi e le proposte di miglioramento hanno aiutato ProxMenux a diventare ciò che è oggi.",
"roles": {
"testing": "Test",
"testingReviewer": "Test e revisione"
},
"youtube": "YouTube"
},
"contribute": {
"heading": "Vuoi contribuire?",
"intro": "Ogni contributo è benvenuto: codice, test, design, documentazione o anche solo la condivisione delle tue idee:",
"tester": "<strong>Tester</strong> — prova il canale <beta>beta</beta> e segnala ciò che funziona e ciò che non funziona prima delle versioni stabili.",
"developer": "<strong>Sviluppatore</strong> — Bash, Next.js (TypeScript) e un po’ di Python per l’ambiente virtuale di traduzione (venv). Le PR sono benvenute su <gh>GitHub</gh>.",
"designer": "<strong>Designer</strong> — Miglioramenti dell'interfaccia utente, icone, screenshot per la documentazione.",
"ideas": "<strong>Idee</strong> — apri una discussione in <disc>GitHub Discussions</disc> prima di creare una issue per richiedere una funzionalità."
},
"coc": {
"title": "Leggi prima il codice di condotta",
"body": "Prima di proporre codice o segnalare problemi, leggi il <coclink>Codice di condotta e le buone pratiche</coclink>. Descrive le aspettative sulla responsabilità del codice, sulla segnalazione delle vulnerabilità e sull’ambito delle PR."
}
}
+94
View File
@@ -0,0 +1,94 @@
{
"meta": {
"title": "FAQ | Documentazione ProxMenux",
"description": "Domande frequenti su ProxMenux: funzionalità, installazione, compatibilità da PVE 8, personalizzazione, aggiornamenti, sicurezza, uso in produzione, file di sistema, contributi e disinstallazione.",
"ogTitle": "FAQ | Documentazione ProxMenux",
"ogDescription": "Domande frequenti su installazione, compatibilità, sicurezza e modi per contribuire a ProxMenux."
},
"header": {
"title": "Domande frequenti",
"description": "Domande comuni su ProxMenux: che cos’è, a chi serve, installazione, aggiornamento, disinstallazione, compatibilità, personalizzazione, sicurezza e contributi. Se non trovi la tua domanda, consulta GitHub Discussions o apri una issue.",
"section": "Informazioni"
},
"quickLinks": {
"title": "Collegamenti rapidi",
"installationLabel": "Installazione",
"installationSuffix": " — il comando di installazione su una sola riga e le dipendenze.",
"introductionLabel": "Introduzione",
"introductionSuffix": " — cosa fa ProxMenux, in cinque minuti.",
"uninstallLabel": "Disinstalla",
"uninstallSuffix": "— rimozione pulita.",
"issuesLabel": "GitHub Issues",
"discussionsLabel": "Discussioni"
},
"q1": {
"question": "Che cosa è ProxMenux, e per cosa è usato?",
"p1Rich": "<strong>ProxMenux</strong> è uno strumento interattivo a menu che rende <strong>Proxmox VE</strong> accessibile a tutti, a prescindere dall’esperienza tecnica. Semplifica l’esecuzione dei comandi e consente di gestire il sistema senza conoscenze avanzate di Linux.",
"p2": "Gli utenti meno esperti possono eseguire comandi da menu strutturati, riducendo ciò che devono digitare nel terminale. Gli amministratori esperti risparmiano passaggi nelle attività ripetitive: protezione dopo l’installazione, passthrough GPU, importazione di VM OVF e rotazione degli snapshot ZFS.",
"p3": "Proxmox VE è ampiamente usato per:",
"items": [
"Virtualizzazione di livello aziendale",
"HomeLab e soluzioni cloud personali",
"Server multimediali, automazione e altro ancora"
]
},
"q2": {
"question": "Come posso installare ProxMenux?",
"p1Rich": "Segui la <installlink>guida all’installazione</installlink>. In breve:",
"stableInstall": "bash -c \"$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)\"",
"p2": "Una volta installato, basta avviarlo con:",
"menuCmd": "menu"
},
"q3": {
"question": "ProxMenux è compatibile con tutte le versioni Proxmox?",
"bodyRich": "<strong>No — ProxMenux richiede Proxmox VE 8 o successivo.</strong> PVE 7 e le versioni precedenti non sono supportati. Se usi ancora PVE 7, passa prima a 8.x seguendo la procedura ufficiale Proxmox. Puoi poi gestire il passaggio da 8 a 9 con ProxMenux da <upgradelink>Utilità → Aggiorna PVE 8 a PVE 9</upgradelink>."
},
"q4": {
"question": "Posso personalizzare ProxMenux?",
"p1Rich": "Gli aggiornamenti possono sovrascrivere le modifiche locali agli script principali: evita quindi di modificare direttamente questi file. Ecco cosa <em>puoi</em> personalizzare:",
"items": [
"Il banner della console tramite lo strumento <strong>FastFetch</strong> nelle opzioni Post-Install.",
"Quali componenti opzionali sono installati (Monitor, Fail2Ban, Lynis...) — scegliere durante l'installazione o tramite il menu pertinente in seguito."
]
},
"q5": {
"question": "Come posso aggiornare ProxMenux?",
"p1Rich": "Quando è disponibile una nuova versione, ProxMenux la rileva al successivo avvio di <code>menu</code> e propone l’aggiornamento. Se accetti, sostituisce i file e la configurazione dello strumento nell’installazione esistente, senza richiedere download manuali.",
"p2Rich": "Chi usa la versione stabile riceve aggiornamenti stabili; chi usa la beta riceve quelli beta. Quando viene pubblicata una versione stabile, la beta lo segnala alla successiva apertura del menu e propone il passaggio automatico. Consulta il <betalink>programma beta</betalink>."
},
"q6": {
"question": "Dove posso segnalare i problemi?",
"p1Rich": "Segnala i bug su <issueslink>GitHub Issues</issueslink>. Includi i passaggi per riprodurli, il messaggio di errore e, se pertinente, l’output di Monitor ottenuto con <code>journalctl -u proxmenux-monitor -n 50</code>.",
"p2Rich": "Per i problemi di <strong>sicurezza</strong>, <strong>non pubblicare i dettagli</strong>. Segui la procedura di segnalazione responsabile nel <coclink>codice di condotta e nelle buone pratiche</coclink>."
},
"q7": {
"question": "Posso contribuire a ProxMenux?",
"p1Rich": "<strong>Certamente.</strong> ProxMenux è un progetto collaborativo e open source. Puoi contribuire con codice (Bash, Next.js/TypeScript e strumenti di traduzione in Python), test, documentazione, design o idee.",
"item1Rich": "Discuti le idee in <discusslink>GitHub Discussions</discusslink> prima di aprire una richiesta di funzionalità.",
"item2Rich": "Prima di inviare una pull request, leggi il <coclink>codice di condotta e le buone pratiche</coclink>.",
"item3Rich": "Consulta la <contriblink>pagina dei collaboratori</contriblink> per conoscere chi si occupa attualmente di test e revisioni."
},
"q8": {
"question": "ProxMenux modifica i file di sistema critici?",
"p1Rich": "<strong>L’installazione di ProxMenux aggiunge i seguenti componenti.</strong>",
"item1Rich": "Dipendenze tramite apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> e <code>git</code>. Le traduzioni usano cataloghi JSON già generati; l’installazione non aggiunge all’host un ambiente virtuale per la traduzione.",
"item2Rich": "L'albero di script a <code>/usr/local/share/proxmenux/</code>.",
"item3Rich": "Il comando di avvio in <code>/usr/local/bin/menu</code>.",
"item4Rich": "Facoltativo: il servizio systemd di Monitor, <code>proxmenux-monitor.service</code>.",
"p2Rich": "ProxMenux <em>non</em> modifica la configurazione principale di Proxmox, a meno che tu non lo richieda esplicitamente da un menu dedicato. Per esempio, la riparazione della rete modifica <code>/etc/network/interfaces</code>, ma solo dopo la tua conferma e la creazione di un backup."
},
"q9": {
"question": "È sicuro usare ProxMenux in produzione?",
"bodyRich": "<strong>Sì.</strong> Poiché ProxMenux modifica i file principali di Proxmox solo su richiesta esplicita, può essere usato in produzione. Come per ogni automazione, provalo prima in un ambiente controllato e prepara i backup prima delle operazioni distruttive: aggiornamento da PVE 8 a 9, formattazione di dischi, eliminazione di VM e simili."
},
"q10": {
"question": "Come posso disinstallare ProxMenux?",
"p1Rich": "Da ProxMenux: <strong>Impostazioni → Disinstalla ProxMenux</strong>. La disinstallazione rimuove gli script, il comando di avvio e il servizio Monitor, oltre alle dipendenze selezionate se richiesto. Ripristina <code>/root/.bashrc</code> e <code>/etc/motd</code> dalle copie create all’installazione, se presenti.",
"p2Rich": "Procedura completa: <uninstalllink>Disinstallare ProxMenux</uninstalllink>."
},
"q11": {
"question": "VirusTotal contrassegna l'URL di installazione — è sicuro?",
"p1Rich": "Il risultato di 1/95 del motore <em>Chong Lua Dao</em>, riportato nella issue #162, è stato identificato dal manutentore come falso positivo. L’installazione usa il modello <code>curl | bash</code> e può scaricare <code>jq</code> dalla sua release ufficiale su GitHub. Questo <em>comportamento</em> può attivare gli scanner euristici; il rapporto storico non costituisce una valutazione di ogni download futuro.",
"p2Rich": "ProxMenux è completamente open source e puoi esaminare lo script di installazione riga per riga: <scriptlink>install_proxmenux.sh</scriptlink>. Altri dettagli nella <issuelink>issue #162</issuelink>."
}
}
+67
View File
@@ -0,0 +1,67 @@
{
"meta": {
"title": "Informazioni su | Documentazione ProxMenux",
"description": "Informazioni su ProxMenux: obiettivi del progetto, collaboratori, FAQ e codice di condotta. Uno strumento di gestione open source a menu per Proxmox VE 8+, sviluppato e mantenuto da MacRimi con un piccolo gruppo di tester e collaboratori.",
"ogTitle": "Informazioni su | Documentazione ProxMenux",
"ogDescription": "Informazioni su ProxMenux — strumento di gestione a menu open source per Proxmox VE 8+."
},
"header": {
"title": "Informazioni",
"description": "Informazioni sul progetto, FAQ, contributori e codice di condotta. ProxMenux è uno strumento di gestione a menu open source per Proxmox VE 8+, costruito e mantenuto da MacRimi con l'aiuto di un piccolo team di tester e collaboratori.",
"section": "Informazioni"
},
"callout": {
"title": "Open source, sviluppato dalla comunità",
"body": "ProxMenux è distribuito con licenza GPL-3.0 e sviluppato pubblicamente su GitHub. Ogni script può essere esaminato e ogni modifica tracciata. Sono benvenuti segnalazioni di bug, idee, codice e test."
},
"section": {
"heading": "In questa sezione",
"options": [
{
"icon": "HelpCircle",
"href": "/docs/about/faq",
"title": "FAQ",
"description": "Domande frequenti: che cos’è ProxMenux, installazione, compatibilità, personalizzazione, aggiornamenti, sicurezza, uso in produzione e disinstallazione."
},
{
"icon": "Users",
"href": "/docs/about/contributors",
"title": "Contributori",
"description": "Un riconoscimento alle persone che rendono possibile ProxMenux: tester, revisori e sviluppatori che contribuiscono a ogni versione."
},
{
"icon": "ScrollText",
"href": "/docs/about/code-of-conduct",
"title": "Codice di condotta",
"description": "Valori del progetto, responsabilità del codice e linee guida per contribuire. Da leggere prima di aprire una PR o segnalare un problema."
}
]
},
"involved": {
"heading": "Partecipa",
"intro": "Tre modi per partecipare al progetto:",
"cards": [
{
"href": "https://github.com/MacRimi/ProxMenux/issues/new",
"title": "🐛 Segnala un bug",
"description": "GitHub Issues — includi i log e i passaggi per riprodurre il problema."
},
{
"href": "https://github.com/MacRimi/ProxMenux/discussions",
"title": "💡 Suggerisci una funzionalità",
"description": "GitHub Discussions — condividi le tue idee prima di aprire una PR."
},
{
"href": "https://github.com/MacRimi/ProxMenux/pulls",
"title": "🔀 Invia una PR",
"description": "GitHub Pull Requests — leggere prima il codice di condotta."
}
]
},
"support": {
"heading": "Sostieni il progetto",
"introRich": "Se ProxMenux ti fa risparmiare tempo, il modo più semplice per farlo conoscere è <starlink>assegnare una ⭐ al repository su GitHub</starlink>. Se vuoi fare di più:",
"kofiLabel": "Supporto su Ko-fi",
"kofiOutro": " — offri un caffè al manutentore e contribuisci a portare avanti lo sviluppo."
}
}
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Backup e riavvio delle interfacce | Documentazione ProxMenux",
"description": "Crea istantanee manuali, sfoglia e ripristina i backup di /etc/network/interfaces salvati in /var/backups/proxmenux/. Include il riavvio del servizio di rete con conferma e una vista rapida della configurazione attuale.",
"ogTitle": "Backup e riavvio delle interfacce | Documentazione ProxMenux",
"ogDescription": "Crea un’istantanea e ripristina la configurazione di rete Proxmox; riavvia il servizio di rete con conferma."
},
"header": {
"title": "Backup e riavvio delle interfacce",
"description": "Quattro utility che ruotano intorno a /etc/network/interfaces: scattano un'istantanea manuale, visualizzano la configurazione live, ripristinano un backup precedente con un'anteprima facoltativa e riavviano il servizio di rete con esplicito consenso. Stessa directory di backup utilizzata dai flussi di riparazione guidati.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Gestisce la stessa directory di backup utilizzata dai flussi di riparazione guidati (<code>/var/backups/proxmenux/</code>). Consente di scattare un'istantanea aggiuntiva prima di qualsiasi cambiamento manuale, sfogliare tutti i backup esistenti e tornare a uno qualsiasi di essi — sempre con un backup pre-restore fresco preso automaticamente come una seconda rete di sicurezza."
},
"shared": {
"heading": "La directory di backup condivisa",
"intro": "Ogni backup preso ovunque nel menu di rete atterra nello stesso posto:",
"outro": "I nomi dei file contengono data e ora, sono ordinati per data e non vengono mai sovrascritti. La directory viene creata al primo utilizzo."
},
"show": {
"heading": "Mostra file di configurazione di rete",
"body": "Mostra il contenuto esatto di <code>/etc/network/interfaces</code> nel terminale. Sola lettura. Utile come controllo prima di un backup o dopo un ripristino. Non esiste uno strumento separato per confrontare il file con il backup precedente: esaminare il file attuale è quindi il modo più semplice per verificarne il contenuto."
},
"create": {
"heading": "Crea backup di rete",
"body": "Copia l'attuale <code>/etc/network/interfaces</code> nella directory di backup con un timestamp fresco. Questo è tutto — nessuna analisi, nessun prompt, solo un'istantanea.",
"whenTitle": "Quando creare un backup manuale",
"whenBody": "Prima di modificare <code>/etc/network/interfaces</code> a mano, di installare un pacchetto che può alterare lo stack di rete (ad esempio NetworkManager o Open vSwitch) o di cambiare l’hardware. Le riparazioni guidate creano già un’istantanea automaticamente: questa opzione serve per gli interventi <em>manuali</em>."
},
"restore": {
"heading": "Ripristina backup di rete",
"intro": "Elenca tutti i backup in <code>/var/backups/proxmenux/</code> dal più recente al più vecchio e guida un ripristino protetto:",
"steps": [
{
"title": "1. Scegli un backup",
"body": "Un menu elenca ogni backup dal suo timestamp. Se non esistono backup, il flusso esce con un messaggio chiaro.",
"tone": "blue"
},
{
"title": "2. Anteprima opzionale",
"body": "Propone di aprire il backup selezionato in una vista scorrevole prima di confermare il ripristino. Sì è l’opzione predefinita: non saltare questo passaggio su un host remoto.",
"tone": "blue"
},
{
"title": "3. Backup prima del ripristino",
"body": "Prima di sovrascrivere <code>/etc/network/interfaces</code>, crea <strong>un altro</strong> backup dello stato attuale. Il ripristino è esso stesso un’operazione distruttiva: la nuova istantanea precedente al ripristino permette di tornare indietro se il backup scelto era quello sbagliato.",
"tone": "amber"
},
{
"title": "4. Applicare il ripristino",
"body": "Copia il backup scelto su <code>/etc/network/interfaces</code>. La modifica del file è su disco; lo stato del kernel live riflette ancora la configurazione precedente.",
"tone": "amber"
},
{
"title": "5. Riavvio opzionale",
"body": "Chiede se eseguire <code>systemctl restart networking</code> ora. Rifiuta per rimandare l’applicazione al prossimo riavvio.",
"tone": "emerald"
}
],
"autoBackupTitle": "Il ripristino crea automaticamente un proprio backup",
"autoBackupBody": "Selezionare <em>Ripristina backup di rete</em> crea sempre una nuova istantanea della configurazione <em>attuale</em> prima di sovrascriverla. Se ripristini il backup sbagliato, il file più recente in <code>/var/backups/proxmenux/</code> contiene lo stato precedente."
},
"restart": {
"heading": "Riavvia servizio di rete",
"body": "Esegue <code>systemctl restart networking</code> dopo una conferma sì/no. Mostra il risultato con <code>msg_ok</code> / <code>msg_error</code>. La maggior parte delle procedure di questo menu propone già un riavvio finale: questa opzione serve dopo una modifica manuale o se hai rifiutato il riavvio proposto in precedenza.",
"warnTitle": "Breve disconnessione garantita; possibile disconnessione permanente",
"warnBody": "Riavviare <code>networking</code> disattiva e riconfigura tutte le interfacce dichiarate in <code>/etc/network/interfaces</code>. Le sessioni SSH su queste interfacce si interrompono. Se la nuova configurazione non è valida, la rete non torna disponibile. Esegui questa operazione solo quando:",
"warnItems": [
"Hai un accesso alla console / IPMI / iKVM pronto, <em>oppure</em>",
"Sei fisicamente accanto alla macchina, <em>oppure</em>",
"Hai appena ripristinato con successo una configurazione sicuramente funzionante e vuoi applicarla."
]
},
"manualRollback": {
"heading": "Ripristino manuale da una console",
"intro": "Se non riesci ad accedere al menu (SSH non disponibile, dialog che si arresta, …) ma puoi usare una console, il ripristino richiede due comandi:",
"outro": "È la <em>stessa</em> operazione eseguita dal menu, semplicemente digitata a mano. Se <code>networking</code> continua a non avviarsi, controlla <code>journalctl -u networking -b</code> per individuare l’errore di sintassi o del driver."
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"noneTitle": "\"Nessun backup trovato\" in Ripristino",
"noneBody": "La directory <code>/var/backups/proxmenux/</code> non esiste o non contiene file <code>interfaces_backup_*</code>. Esegui <em>Crea backup di rete</em> almeno una volta oppure una riparazione guidata, che ne crea uno automaticamente. Verifica con <code>ls /var/backups/proxmenux/</code>.",
"unreachTitle": "Riavviare la rete riesce, ma l'host è ancora irraggiungibile",
"unreachBody": "La nuova configurazione è errata oppure non assegna il tuo IP di gestione. Ripristina la configurazione dalla console (vedi sopra). Poi usa <bridgeLink>l’analisi dei bridge</bridgeLink> e <configLink>l’analisi della configurazione</configLink> per capire il problema prima di applicarla nuovamente.",
"emptyTitle": "L'anteprima del ripristino mostra un file vuoto",
"emptyBody": "Il file di backup è vuoto (0 byte). Succede se una copia è fallita senza segnalazioni in un’esecuzione precedente. Scegli un backup più vecchio oppure esegui di nuovo <em>Crea backup di rete</em> adesso, se la configurazione attuale funziona."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Analisi dei bridge e riparazione guidata",
"href": "/docs/network/bridge-analysis",
"tail": "— il motivo più comune per cui un backup finisce qui."
},
{
"label": "Analisi della configurazione e pulizia guidata",
"href": "/docs/network/config-analysis",
"tailRich": "— scrive anche a <code>/var/backups/proxmenux/</code> automaticamente."
},
{
"label": "Diagnostica",
"href": "/docs/network/diagnostics",
"tail": " — per verificare lo stato attuale dopo un ripristino."
}
]
}
}
@@ -0,0 +1,132 @@
{
"meta": {
"title": "Analisi dei bridge e riparazione guidata | Documentazione ProxMenux",
"description": "Rileva bridge vmbrX con porte fisiche mancanti o non valide, tipicamente dopo la rinumerazione PCI. Li segnala con comandi shell proposti e offre una riparazione guidata in 5 passaggi con backup obbligatorio.",
"ogTitle": "Analisi dei bridge e riparazione guidata | Documentazione ProxMenux",
"ogDescription": "Controlla e ripara le porte dei bridge Proxmox dopo modifiche hardware, con una procedura guidata che consente un ripristino sicuro."
},
"header": {
"title": "Analisi dei bridge e riparazione guidata",
"description": "Controlla ogni bridge vmbrX dichiarato in /etc/network/interfaces, verifica che le porte fisiche esistano e propone una riparazione passo passo se mancano. L’analisi è di sola lettura; la riparazione richiede conferma, mostra un’anteprima e crea un backup.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Legge ogni bridge in <code>/etc/network/interfaces</code>, esamina la riga <code>bridge-ports</code> e verifica che ogni porta dichiarata, ad esempio <code>enp3s0</code>, esista sull’host. Se una porta manca, propone una sostituzione e, con consenso esplicito, applica la modifica seguendo la procedura <strong>backup, anteprima, applicazione, verifica</strong>."
},
"when": {
"heading": "Quando hai bisogno di questo",
"intro": "Linux assegna nomi prevedibili alle interfacce in base alla topologia PCI e all’ordine degli slot. Diversi eventi possono modificarli, lasciando in <code>/etc/network/interfaces</code> riferimenti a nomi non più esistenti:",
"items": [
"Aggiungere o rimuovere una scheda PCIe (scheda di rete, GPU, HBA o adattatore NVMe).",
"Spostare una scheda esistente in un'altra slot PCIe.",
"Aggiornamenti BIOS / UEFI che rinumerano i dispositivi PCI.",
"Migrare il disco di avvio su hardware diverso."
],
"outro": "Dopo il prossimo avvio, il ponte cerca di attaccare a una porta che non esiste più, non riesce a salire, e l'host perde la sua rete. <link>Nomi di interfaccia persistenti</link> impedisce che questo accada di nuovo — ma se sei già bloccato fuori, questa pagina è il percorso di recupero."
},
"bigPicture": {
"heading": "Quadro generale",
"diagram1": {
"arrowLabel": "passo 1",
"nodes": {
"sourceLabel": "/etc/network/interfaces",
"sourceDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports enp3s0",
"bridgeLabel": "Analizzare (solo lettura)",
"bridgeDetail": "ip link show enp3s0\n→ non esiste",
"targetLabel": "Report + suggerimento",
"targetDetail": "❌ enp3s0: NON TROVATA\nSostituisci con: eno1\n(ancora nessuna modifica)"
}
},
"diagram2": {
"arrowLabel": "applicare con il backup",
"nodes": {
"sourceLabel": "Riparazione guidata",
"sourceDetail": "1. Backup\n2. Mostra configurazione attuale\n3. Anteprima delle modifiche\n4. Applica\n5. Verifica",
"targetLabel": "/etc/network/interfaces (nuovo)",
"targetDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports eno1"
}
}
},
"step1": {
"heading": "Passo 1: analisi (solo lettura)",
"intro": "Selezionando <strong>Analizza configurazione dei bridge</strong>, lo strumento si interrompe se l’host non usa lo stack classico Debian/Proxmox. Altrimenti esamina ogni bridge e mostra:",
"items": [
"Nome del ponte, stato corrente (UP / DOWN), IP assegnato.",
"Ogni porta dichiarata e la sua effettiva presenza (<code>ip link show &lt;port&gt;</code>).",
"Per ogni porta non valida: una sostituzione proposta (la prima interfaccia fisica disponibile) più il comando esatto <code>sed</code> per applicarla manualmente.",
"Bridge senza alcuna riga <code>bridge-ports</code> e voci <code>auto</code> orfane senza un blocco <code>iface</code> corrispondente."
],
"readonlyTitle": "Garanzia di sola lettura",
"readonlyBody": "Fino a questo punto lo script non ha eseguito un singolo comando di modifica. È possibile lasciare l'analisi aperta, copiare i comandi <code>sed</code> suggeriti e applicarli manualmente se si preferisce — o accettare il prompt successivo per inserire la riparazione guidata."
},
"step2": {
"heading": "Passo 2: riparazione guidata (5 passi)",
"intro": "Solo se accetti il prompt alla fine dell'analisi. Ogni passo mostra cosa accadrà e chiederà la conferma prima di continuare.",
"steps": [
{
"title": "1. Backup di sicurezza",
"body": "Copia <code>/etc/network/interfaces</code> in <code>/var/backups/proxmenux/interfaces_backup_&lt;TIMESTAMP&gt;</code>. Il percorso esatto del backup viene mostrato prima e dopo la copia, insieme al comando di ripristino.",
"tone": "blue"
},
{
"title": "2. Controlla la configurazione attuale",
"body": "Apre l’attuale <code>/etc/network/interfaces</code> in una finestra scorrevole per vedere esattamente cosa verrà modificato.",
"tone": "blue"
},
{
"title": "3. Anteprima delle modifiche proposte",
"body": "Elenca esattamente i bridge interessati e le sostituzioni delle porte previste. Se non serve più alcuna riparazione perché la porta è ricomparsa tra i controlli, la procedura termina con <em>«Nessuna modifica necessaria.»</em>",
"tone": "blue"
},
{
"title": "4. Applicare le modifiche",
"body": "Per ogni ponte interessato, viene eseguito <code>sed -i \"/iface $bridge/,/bridge-ports/ s/bridge-ports.*/bridge-ports $new_ports/\"</code> contro <code>/etc/network/interfaces</code>. Se un ponte non ha una sostituzione valida disponibile, la sostituzione è saltata e riportata nella fase 5.",
"tone": "amber"
},
{
"title": "5. Verifica",
"body": "Rilegge il file e verifica che la nuova porta di ogni bridge esista. Mostra il comando di ripristino (<code>cp &lt;backup&gt; /etc/network/interfaces</code>). Infine propone <strong>Riavvia la rete</strong>: accetta solo se hai un accesso di riserva alla console.",
"tone": "emerald"
}
],
"restartTitle": "Riavviare la rete ≠ annullare senza rischi",
"restartBody": "La riparazione viene scritta su disco anche se non riavvii il servizio. <code>systemctl restart networking</code> applica la modifica <em>ora</em> e può interrompere la sessione SSH se la nuova porta è errata. Se rifiuti, la modifica avrà comunque effetto al prossimo avvio: verifica prima la configurazione oppure annulla con il comando mostrato."
},
"edits": {
"heading": "Cosa viene modificato (esattamente)",
"body": "Solo la riga <code>bridge-ports</code> di ogni bridge interessato. Le altre direttive (<code>address</code>, <code>netmask</code>, <code>gateway</code>, <code>bridge-stp</code>, …) restano invariate. In questa procedura lo script non crea né rimuove blocchi <code>iface</code>: se ne occupa <link>Analisi della configurazione &amp; pulizia</link>."
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"unsupportedTitle": "L’analisi si interrompe con «Stack di rete non supportato»",
"unsupportedBody": "L'host esegue netplan, systemd-networkd o NetworkManager. Lo strumento supporta solo <code>/etc/network/interfaces</code>. Passare l'host al classico stack prima, o modificare la configurazione con il tooling nativo del manager (ad es. <code>netplan apply</code>).",
"noSuggestTitle": "Non viene mostrato alcun suggerimento per una porta non valida",
"noSuggestBody": "L’host non ha interfacce fisiche libere: sono già tutte in un altro bridge oppure non esistono. L’analisi suggerisce come alternativa <code>bridge-ports none</code>, così il bridge può almeno attivarsi senza una porta. Aggiungi una scheda di rete o sposta manualmente le porte tra i bridge prima di riprovare.",
"stillDownTitle": "La riparazione completa ma il ponte è ancora DOWN",
"stillDownBody": "<code>sed</code> ha aggiornato il file, ma <code>systemctl restart networking</code> è stato rifiutato. Eseguilo manualmente dopo aver verificato la nuova configurazione oppure riavvia. Se il riavvio è stato accettato e il bridge è ancora DOWN, esegui <code>ip link show</code> per verificare che la nuova porta esista e controlla <code>journalctl -u networking</code> per l’errore effettivo: cavo scollegato, collegamento non negoziato o porta già appartenente a un altro bridge.",
"lostSshTitle": "Ho perso l'accesso SSH subito dopo il riavvio della rete",
"lostSshIntro": "Utilizzare la console / IPMI / iKVM per raggiungere l'host. Ripristinare il backup:",
"lostSshOutro": "Esegui poi di nuovo l’analisi dalla console per capire perché il suggerimento non ha funzionato, in genere perché la porta sostitutiva non è collegata."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Nomi di interfaccia persistenti",
"href": "/docs/network/persistent-names",
"tail": " — associa i nomi agli indirizzi MAC per evitare che il problema si ripeta."
},
{
"label": "Analisi della configurazione e pulizia guidata",
"href": "/docs/network/config-analysis",
"tailRich": "— per i blocchi <code>iface</code> orfani (l'altra metà dello stesso problema)."
},
{
"label": "Backup e riavvio delle interfacce",
"href": "/docs/network/backup-restore",
"tail": "— snapshot manuali e browser di ripristino."
}
]
}
}
@@ -0,0 +1,122 @@
{
"meta": {
"title": "Analisi della configurazione e pulizia guidata | Documentazione ProxMenux",
"description": "Rileva i blocchi iface in /etc/network/interfaces che fanno riferimento a schede di rete fisiche non più presenti sull’host. Li segnala e offre una rimozione guidata in 5 passaggi con backup obbligatorio e anteprima di ogni blocco.",
"ogTitle": "Analisi della configurazione e pulizia guidata | Documentazione ProxMenux",
"ogDescription": "Trovare e rimuovere i blocchi di interfaccia orfano lasciati dietro da modifiche hardware, con anteprima completa e rollback."
},
"header": {
"title": "Analisi della configurazione e pulizia guidata",
"description": "Esamina ogni blocco iface in /etc/network/interfaces e verifica che la scheda di rete fisica corrispondente esista ancora. Segnala i blocchi orfani rimasti dopo modifiche hardware e offre una rimozione guidata con backup, anteprima e conferma per ogni blocco.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Identifica le dichiarazioni <code>iface</code> il cui supporto NIC non è più presente sull'host (tipico dopo aver sostituito o rimosso una scheda di rete). Poi offre una pulizia guidata che rimuove <em>solo</em> i blocchi orfani, con un backup, un'anteprima per sezione e una conferma finale esplicita."
},
"differs": {
"heading": "Come differisce dall'analisi del ponte",
"headerAspect": "Aspetto",
"headerBridge": "Analisi del ponte",
"headerConfig": "Analisi della configurazione",
"rows": [
{
"aspect": "Esamina",
"bridge": "Ponti (<code>vmbrX</code>) e la loro linea <code>bridge-ports</code>",
"config": "Ogni blocco <code>iface</code>, esclusi loopback, bridge e bond"
},
{
"aspect": "Rilevamento",
"bridge": "Bridge che fanno riferimento a una porta inesistente",
"config": "Blocchi di interfaccia standalone per NIC che non esistono"
},
{
"aspect": "Azione di riparazione",
"bridge": "Sostituisce il nome della porta in <code>bridge-ports</code>",
"config": "Rimuove l'intero blocco <code>iface</code>"
},
{
"aspect": "Esclusi",
"bridge": "Nulla — ogni ponte viene analizzato",
"config": "Bridge (<code>vmbrX</code>) e bond (<code>bondX</code>) vengono sempre mantenuti: sono virtuali e la loro assenza durante l’avvio può essere normale"
}
],
"outro": "In pratica si usano spesso entrambi in quest’ordine: prima <strong>analisi della configurazione</strong> per rimuovere i blocchi orfani, poi <link>analisi dei bridge</link> per riassegnare i bridge che dipendevano dall’interfaccia rimossa."
},
"step1": {
"heading": "Passo 1: analisi (solo lettura)",
"intro": "Interrompe immediatamente se l'host non è sulla pila classica. Altrimenti elenca ogni interfaccia non-loopback configurata e segnala il suo stato:",
"virtTitle": "Le interfacce virtuali sono protette",
"virtBody": "Bridge (<code>vmbrX</code>) e bond (<code>bondX</code>) sono strutture virtuali. È possibile che non esistano al momento dell’ispezione, ad esempio un bridge ancora senza porte. L’analisi non propone mai di rimuoverli, ma solo le schede di rete fisiche."
},
"step2": {
"heading": "Passo 2: pulizia guidata (5 passi)",
"intro": "Solo se accetti il prompt alla fine dell'analisi. Ogni passo richiede la conferma; la cancellazione in qualsiasi punto esce senza scrivere.",
"steps": [
{
"title": "1. Backup di sicurezza",
"body": "Copia <code>/etc/network/interfaces</code> in <code>/var/backups/proxmenux/interfaces_backup_&lt;TIMESTAMP&gt;</code>. Il percorso viene mostrato prima e dopo.",
"tone": "blue"
},
{
"title": "2. Confermare la lista di rimozione",
"body": "Elenca esattamente i blocchi delle interfacce fisiche da rimuovere. Se le schede di rete riappaiono tra analisi e pulizia, ad esempio dopo aver reinserito una scheda, la procedura termina con <em>«Nessuna pulizia necessaria.»</em>",
"tone": "blue"
},
{
"title": "3. Visualizza in anteprima i blocchi esatti",
"body": "Apre una vista scorrevole di ogni blocco <code>iface</code> che verrebbe eliminato, esattamente come appare nel file. È il momento di individuare, ad esempio, un hook <code>up</code> che vuoi conservare.",
"tone": "blue"
},
{
"title": "4. Applicare la rimozione",
"body": "Per ogni interfaccia orfano, funziona <code>sed -i \"/^iface $iface/,/^$/d\" /etc/network/interfaces</code>. Questo elimina dalla linea <code>iface</code> corrispondente fino alla riga vuota successiva.",
"tone": "amber"
},
{
"title": "5. Verifica",
"body": "Rilegge il file, elenca ciò che è stato rimosso e ricontrolla le restanti interfacce. Stampa il comando di rollback. <strong>non</strong> riavvia automaticamente la rete: la rimozione di un blocco inutilizzato è sicura da applicare al riavvio successivo ed evita di toccare lo stato live.",
"tone": "emerald"
}
],
"noRestartTitle": "Non riavvia automaticamente la rete",
"noRestartBody": "A differenza della riparazione del ponte, il flusso di pulizia non offre di riavviare il servizio. Rimuovere un blocco di interfaccia non utilizzato non ha alcun effetto immediato sulla configurazione in esecuzione, quindi un riavvio è inutile e sarebbe un rischio di connettività inutile. La modifica ha effetto sul successivo manuale <code>systemctl restart networking</code> o al successivo riavvio."
},
"caveats": {
"heading": "Osservazioni importanti",
"boundaryTitle": "Il confine del blocco è la prima linea vuota",
"boundaryBody": "Il pattern <code>sed</code> elimina da <code>iface &lt;name&gt;</code> fino alla riga vuota successiva. Se in <code>/etc/network/interfaces</code> manca una riga vuota tra i blocchi, cosa rara ma possibile dopo modifiche manuali, può essere eliminato anche il blocco successivo. Per questo <strong>il passaggio 3 è obbligatorio</strong>: controlla l’anteprima prima di confermare.",
"tandemTitle": "Un blocco iface orfano usato da un bridge viene rilevato qui, non nell’analisi dei bridge",
"tandemBody": "Se <code>vmbr0</code> dichiara <code>bridge-ports enp3s0</code> e <code>enp3s0</code> ha anche un blocco <code>iface enp3s0 inet manual</code>, rimuovere <code>enp3s0</code> qui lascia un riferimento non valido in <code>vmbr0</code>. Dopo la pulizia, esegui <link>l’analisi dei bridge</link> per riassegnare o rimuovere la porta del bridge. Le due procedure sono pensate per essere usate insieme."
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"notFoundTitle": "L’analisi indica «NON TROVATA» per la mia nuova scheda di rete",
"notFoundBody": "Il kernel vede il dispositivo con un nome diverso da quello nel file. Esegui <code>ip link show</code> per trovare il nome effettivo. È proprio il caso in cui i <link>nomi persistenti delle interfacce</link> eviterebbero il problema in futuro.",
"tooMuchTitle": "La pulizia ha rimosso troppo (un blocco che volevo mantenere)",
"tooMuchBody": "Ripristino dal backup stampato nella fase 5:",
"tooMuchOutro": "Modificare il file a mano per aggiungere una linea vuota chiara tra i blocchi prima di eseguire la pulizia, o rimuovere il blocco problematico manualmente.",
"bridgeBreakTitle": "Un ponte smette di funzionare dopo la pulizia",
"bridgeBreakBody": "Il bridge dipendeva da una porta il cui blocco <code>iface</code> è stato appena rimosso. Esegui <link>l’analisi dei bridge</link>: il suggerimento assegnerà al bridge un’interfaccia fisica esistente."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Analisi dei bridge e riparazione guidata",
"href": "/docs/network/bridge-analysis",
"tail": "— il follow-up naturale dopo una pulizia."
},
{
"label": "Nomi di interfaccia persistenti",
"href": "/docs/network/persistent-names",
"tail": "— blocca i blocchi orfani dall'accumulo dopo ogni cambio hardware."
},
{
"label": "Backup e riavvio delle interfacce",
"href": "/docs/network/backup-restore",
"tail": "— snapshot manuali e browser di ripristino."
}
]
}
}
@@ -0,0 +1,94 @@
{
"meta": {
"title": "Diagnostica | Documentazione ProxMenux",
"description": "Tre controlli diagnostici puntuali di sola lettura: Mostra tabella di routing, Test di connettività e Diagnostica avanzata. Semplice ispezione: non scrive mai in /etc/network/interfaces e non esegue comandi di modifica, con un’unica eccezione esplicita: la rimozione completa di NetworkManager, se rilevato, richiede il tuo consenso.",
"ogTitle": "Diagnostica | Documentazione ProxMenux",
"ogDescription": "Diagnostica di rete di sola lettura per l'host Proxmox: routing, raggiungibilità, statistiche avanzate."
},
"header": {
"title": "Diagnostica",
"description": "Tre controlli puntuali di sola lettura dello stato attuale della rete: tabella di routing, test di connettività e statistiche avanzate. Nessuno scrive in /etc/network/interfaces: sono utilizzabili in sicurezza in qualsiasi momento, anche via SSH. Per il monitoraggio interattivo in tempo reale, vedi Strumenti di monitoraggio in tempo reale.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Mostra informazioni su routing, raggiungibilità e statistiche aggregate <strong>senza modificare nulla</strong>. Usalo per verificare che la rete funzioni o individuare IP duplicati. Per osservare il traffico in modo continuo, vedi <monitoringLink>Strumenti di monitoraggio in tempo reale</monitoringLink>; per visualizzare il file di configurazione grezzo, vedi <backupLink>Backup e riavvio delle interfacce</backupLink>."
},
"routing": {
"heading": "Mostra tabella di routing",
"body": "Elenca tutte le rotte attualmente usate dal kernel (<code>ip route show</code>) ed evidenzia il gateway predefinito. Utile per verificare che il traffico verso Internet esca dall’interfaccia prevista e che nessuna vecchia rotta abbia la precedenza."
},
"connectivity": {
"heading": "Test connettività",
"intro": "Invia due sonde ICMP a tre obiettivi in sequenza e segnala ciascuno. Poi viene eseguito un <code>nslookup google.com</code> per verificare la risoluzione DNS indipendentemente da ICMP.",
"headerTest": "Test",
"headerTarget": "Destinazione",
"headerConfirms": "Cosa conferma",
"rows": [
{
"test": "DNS Google",
"target": "8.8.8.8",
"confirms": "Raggiungibilità esterna tramite un indirizzo IP anycast noto"
},
{
"test": "Cloudflare DNS",
"target": "1.1.1.1",
"confirms": "Seconda opzione indipendente se Google blocca ICMP"
},
{
"test": "Gateway",
"target": "(percorso di default)",
"confirms": "Connettività L2 / L3 al router locale"
},
{
"test": "Risoluzione DNS",
"target": "google.com",
"confirms": "Il server DNS è raggiungibile e risponde"
}
],
"readingTitle": "Leggere il risultato",
"readingBody": "Se il test del gateway riesce ma i server DNS pubblici non rispondono, la connettività locale funziona ma non hai accesso a Internet: controlla la connessione a monte del gateway. Se la risoluzione DNS fallisce ma i ping verso <code>8.8.8.8</code> riescono, il problema è il resolver, non la rete: controlla <code>/etc/resolv.conf</code>."
},
"advanced": {
"heading": "Diagnostica avanzata",
"intro": "Aggrega le statistiche dell’intera rete ed esegue una serie di controlli sui problemi comuni. Mostra il numero di connessioni attive, le porte in ascolto e il totale delle interfacce, e segnala esplicitamente due configurazioni problematiche:",
"items": [
"<strong>NetworkManager in esecuzione su un host Proxmox.</strong> NetworkManager e <code>ifupdown</code> di Proxmox entrano in conflitto: entrambi tentano di gestire le interfacce, rendendo i bridge instabili o impedendone l’attivazione. Se viene rilevato, lo strumento propone una conferma interattiva per arrestarlo, disabilitarlo e rimuoverlo completamente (è l’<em>unica</em> diagnostica che può modificare il sistema, e solo dopo un consenso esplicito).",
"<strong>Indirizzi IP duplicati su interfacce diverse.</strong> Due interfacce con lo stesso indirizzo IPv4 causano problemi di connettività intermittenti molto difficili da diagnosticare dall’interno della VM. Rilevamento tramite <code>ip -4 addr show | sort | uniq -d</code>."
],
"nmTitle": "Il prompt NetworkManager è l'unica azione di modifica qui",
"nmBody": "Tutti gli altri controlli della diagnostica avanzata sono di sola lettura. La rimozione di NetworkManager richiede una conferma sì/no ed esegue <code>systemctl stop / disable</code> + <code>apt-get purge -y network-manager</code>. Se rifiuti, non cambia nulla."
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"gwTitle": "Il test di connettività segnala un errore del gateway, ma l’host ha accesso a Internet",
"gwBody": "Alcuni router non rispondono a ICMP sulla loro interfaccia interna anche se inoltrano correttamente il traffico. Prova <code>traceroute 8.8.8.8</code> da una console: se il secondo hop è il tuo ISP e il test del DNS pubblico è riuscito, il gateway funziona nonostante il ping fallito.",
"dupTitle": "La diagnostica avanzata continua a segnalare IP duplicati dopo che ne ho rimosso uno",
"dupBody": "Il controllo guarda lo stato del kernel dal vivo, non il file di configurazione. Eseguire <code>ip -4 addr show</code> per confermare; se il duplicato è ancora presente, un'interfaccia lo tiene ancora. Utilizzare <code>ip addr del &lt;IP&gt;/&lt;mask&gt; dev &lt;iface&gt;</code> per rimuoverlo dallo stato in tempo reale, quindi modificare <code>/etc/network/interfaces</code> se è anche persistente."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Strumenti di monitoraggio dal vivo",
"href": "/docs/network/monitoring",
"tail": "— lanciatori interattivi iftop / iptraf-ng / iperf3."
},
{
"label": "Analisi dei bridge e riparazione guidata",
"href": "/docs/network/bridge-analysis",
"tail": " — quando a un vmbrX manca la porta fisica."
},
{
"label": "Analisi della configurazione e pulizia guidata",
"href": "/docs/network/config-analysis",
"tail": " — quando una vecchia scheda di rete è ancora dichiarata ma non è più presente."
},
{
"label": "Backup e riavvio delle interfacce",
"href": "/docs/network/backup-restore",
"tail": " — per creare un’istantanea della configurazione prima di qualsiasi modifica."
}
]
}
}
+107
View File
@@ -0,0 +1,107 @@
{
"meta": {
"title": "Gestione della rete Proxmox — Bridge, bond, diagnostica, riparazione | ProxMenux",
"description": "Diagnostica di sola lettura, analisi con suggerimenti e riparazioni guidate per lo stack di rete Debian / Proxmox (/etc/network/interfaces). Ispeziona bridge e bond, avvia strumenti di monitoraggio in tempo reale, rendi persistenti i nomi delle interfacce, crea backup e riavvia la rete in sicurezza, con backup obbligatori e anteprime passo passo.",
"ogTitle": "Gestione della rete Proxmox — Bridge, bond, diagnostica, riparazione",
"ogDescription": "Diagnostica, analisi e riparazioni guidate per lo stack di rete Proxmox con backup obbligatori e anteprime passo-passo.",
"twitterTitle": "Gestione della rete Proxmox | ProxMenux",
"twitterDescription": "Bridge, bond, diagnostica e riparazioni guidate per lo stack di rete Proxmox con backup obbligatori."
},
"header": {
"title": "Gestione rete",
"description": "Diagnostica di sola lettura, rapporti di analisi con suggerimenti e riparazioni guidate per il classico stack di rete Debian/Proxmox. Ogni operazione distruttiva crea prima un backup e mostra in anteprima le modifiche esatte prima di applicarle.",
"section": "Rete"
},
"intro": {
"title": "A cosa serve questo menu",
"body": "Ispeziona, diagnostica e, quando necessario, ripara la configurazione di rete dell’host Proxmox senza perdere l’accesso remoto. Gli strumenti seguono un principio: <strong>prima leggere, poi proporre e infine applicare solo con consenso esplicito e un backup di sicurezza</strong>. Non esiste un pulsante «Correggi tutto automaticamente»."
},
"openingMenu": {
"heading": "Apertura del menu",
"intro": "Dal menu principale di ProxMenux, seleziona <strong>Rete</strong>. Vedrai questo:",
"imageAlt": "Menù Gestione rete con diagnostica, monitoraggio, analisi, riparazione, nomi persistenti e opzioni di backup"
},
"safety": {
"heading": "Il modello di sicurezza",
"body": "Modificare la configurazione di rete di un host Proxmox remoto è uno dei modi più semplici per perdere l’accesso. ProxMenux ne tiene conto per ogni azione. Gli strumenti si dividono in tre livelli di comportamento: scegli la scheda che corrisponde al tuo obiettivo:"
},
"tiers": {
"readOnly": {
"title": "Sola lettura",
"body": "Ispezione pura. Non può modificare il sistema in nessuna circostanza.",
"items": [
"Tabella di routing, test di connettività, statistiche avanzate",
"Monitoraggio del traffico dal vivo (iftop, iptraf-ng)",
"Test della larghezza di banda (iperf3)"
]
},
"analyze": {
"title": "Analizzare, quindi suggerire",
"body": "Rileva i problemi, stampa un rapporto con i comandi di shell proposti e si ferma. Si decide se entrare nella riparazione guidata dopo.",
"items": [
"Analisi della configurazione del ponte",
"Analisi della configurazione di rete"
]
},
"apply": {
"title": "Applicare con backup",
"body": "Modifica il sistema. Crea sempre prima un backup del file interessato con data e ora e mostra un’anteprima prima di scrivere.",
"items": [
"Nomi persistenti delle interfacce (file .link)",
"Backup manuale, ripristino e riavvio del servizio"
]
}
},
"classicTitle": "Solo pila classica",
"classicBody": "Ogni funzione di analisi e riparazione controlla il gestore di rete attivo prima di toccare qualsiasi cosa. Se l'host esegue <strong>netplan</strong>, <strong>systemd-networkd</strong> o <strong>NetworkManager</strong>, lo strumento si interrompe immediatamente con un messaggio chiaro — il menu supporta solo il classico stack Debian/Proxmox a <code>/etc/network/interfaces</code>. Questo è intenzionale: la modifica di un file netplan con regole scritte per <code>ifupdown</code> avrebbe corrotto silenziosamente la configurazione.",
"backups": {
"heading": "Dove vengono salvati i backup",
"intro": "Ogni riparazione guidata, ripristino o backup manuale scrive una copia di <code>/etc/network/interfaces</code> con data e ora in <code>/var/backups/proxmenux/</code>:",
"rollbackIntro": "Per ripristinare manualmente la configurazione precedente da una console:"
},
"readOnlySection": {
"heading": "Ispezione di sola lettura",
"body": "Il punto di partenza quando qualcosa non va. Semplice ispezione: non scrive mai in <code>/etc/network/interfaces</code> e non esegue comandi che modificano il sistema, con un’unica eccezione esplicita: la rimozione completa di NetworkManager, se rilevato, richiede il tuo consenso. Utilizzabile in sicurezza via SSH in qualsiasi momento.",
"options": [
{
"title": "Diagnostica",
"description": "Tre controlli puntuali di sola lettura: Mostra tabella di routing, Test di connettività e Diagnostica avanzata. Semplice ispezione: non scrive mai nel sistema."
},
{
"title": "Strumenti di monitoraggio dal vivo",
"description": "Tre strumenti avviabili in modo interattivo: iftop (larghezza di banda in tempo reale per coppia di host), iptraf-ng (monitor del traffico con più modalità) e iperf3 (test della larghezza di banda, modalità server / client)."
}
]
},
"analyzeSection": {
"heading": "Analizzare, quindi suggerire",
"body": "Da usare quando un’ispezione o un’effettiva interruzione del servizio indica un problema di configurazione. Ogni strumento esamina la parte pertinente di <code>/etc/network/interfaces</code>, stampa un rapporto dettagliato con l’esatto comando shell che risolverebbe ogni problema e <strong>si ferma</strong>. Se in seguito accetti la riparazione guidata facoltativa, ogni modifica viene preceduta da un backup e mostrata in anteprima prima della scrittura.",
"options": [
{
"title": "Analisi dei bridge e riparazione guidata",
"description": "Rileva bridge vmbrX con porte mancanti o non valide, situazione tipica dopo la rinumerazione PCI. Mostra prima un rapporto e ripara solo se accetti la procedura guidata in 5 passaggi."
},
{
"title": "Analisi della configurazione e pulizia guidata",
"description": "Trova le interfacce fisiche dichiarate in /etc/network/interfaces che non esistono più, ossia configurazioni orfane rimaste dopo modifiche hardware. Le segnala e propone una rimozione guidata."
}
]
},
"applySection": {
"heading": "Applicare con backup",
"body": "Questi strumenti scrivono su disco per loro natura. Ciascuno crea un backup del file interessato con data e ora prima della scrittura e le opzioni distruttive, come ripristino e riavvio, richiedono una conferma esplicita sì/no. I <em>nomi persistenti delle interfacce</em> diventano effettivi al prossimo riavvio, non subito: puoi quindi pianificarne l’impostazione in sicurezza anche su un host remoto.",
"options": [
{
"title": "Nomi di interfaccia persistenti",
"description": "Associa i nomi delle interfacce (eno1, enp3s0, …) agli indirizzi MAC tramite file .link di systemd. I nomi restano invariati dopo cambi di slot PCI, aggiornamenti del kernel e aggiunta o rimozione di altre schede di rete."
},
{
"title": "Backup e riavvio delle interfacce",
"description": "snapshot manuale di /etc/network/interfaces, sfoglia e ripristina i backup precedenti, visualizza la configurazione live e riavvia il servizio di rete quando necessario."
}
]
},
"consoleTitle": "Prepara un accesso alla console",
"consoleSubTitle": "Prima di qualsiasi riparazione su un host remoto",
"consoleBody": "Se sei connesso via SSH e hai un solo percorso di accesso all’host, prepara un’alternativa prima di applicare modifiche alla rete: console fisica / IPMI / iKVM oppure un’altra macchina sulla stessa LAN. Le riparazioni guidate sono sicure e offrono sempre un comando per annullare le modifiche, ma un bridge configurato male o una connessione interrotta può comunque lasciarti senza accesso finché non raggiungi la console."
}
@@ -0,0 +1,136 @@
{
"meta": {
"title": "Strumenti di monitoraggio in tempo reale | Documentazione ProxMenux",
"description": "Tre strumenti interattivi di monitoraggio della rete: iftop (larghezza di banda in tempo reale per coppia di host), iptraf-ng (monitor del traffico con più modalità) e iperf3 (test della larghezza di banda, modalità server / client). Ciascuno viene installato al primo utilizzo.",
"ogTitle": "Strumenti di monitoraggio in tempo reale | Documentazione ProxMenux",
"ogDescription": "Monitoraggio interattivo della rete e test di larghezza di banda per l'host Proxmox: iftop, iptraf-ng, iperf3."
},
"header": {
"title": "Strumenti di monitoraggio dal vivo",
"description": "Tre strumenti avviabili in modo interattivo per osservare la rete in tempo reale e misurare la larghezza di banda: iftop, iptraf-ng e iperf3. Ogni strumento viene installato automaticamente tramite apt al primo utilizzo, viene eseguito in primo piano e si chiude con il tasto indicato. Non modificano la configurazione di rete dell’host; iperf3 genera traffico di prova.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Tre strumenti di monitoraggio interattivo, ciascuno dietro la propria voce menu. La prima volta che si lancia uno, il pacchetto viene installato silenziosamente tramite <code>apt-get</code>. I lanci successivi iniziano immediatamente. Nessuno di questi strumenti modifica la configurazione della rete host."
},
"when": {
"heading": "Quando usare quale",
"headerQuestion": "Domanda",
"headerUse": "Usa",
"rows": [
{
"question": "Chi sta saturando il collegamento <em>in questo momento</em>?",
"use": "iftop"
},
{
"question": "Qual è la ripartizione per protocollo e quali dimensioni dei pacchetti e flussi TCP sono presenti?",
"use": "iptraf-ng"
},
{
"question": "Quanta larghezza di banda è effettivamente disponibile tra due host?",
"use": "iperf3"
}
]
},
"iftop": {
"heading": "Utilizzo rete in tempo reale (iftop)",
"body": "Larghezza di banda in tempo reale per coppia di host (origine ↔ destinazione), come <code>top</code> per il traffico. Mostra in alto i flussi più intensi con medie mobili su 2/10/40 secondi. Lo strumento ideale per rispondere a <em>«perché il mio uplink è saturo?»</em>.",
"exit": "<strong>Esci:</strong> premi <kbd>q</kbd>. ProxMenux mostra un promemoria prima dell’avvio.",
"keysTitle": "Tasti utili dentro iftop",
"keysBody": "<kbd>n</kbd> attiva o disattiva le ricerche DNS, <kbd>p</kbd> mostra i numeri di porta, <kbd>P</kbd> mette in pausa la visualizzazione, <kbd>t</kbd> cambia la direzione delle righe (inviato / ricevuto / entrambi), <kbd>1</kbd>/<kbd>2</kbd>/<kbd>3</kbd> ordina per media su 2 s / 10 s / 40 s. Elenco completo in <code>man iftop</code>."
},
"iptraf": {
"heading": "Strumento monitoraggio rete (iptraf-ng)",
"intro": "Un monitor del traffico con più modalità, gestito tramite menu. iftop risponde a <em>«chi»</em>, mentre iptraf-ng risponde a <em>«cosa»</em>: contatori di byte e pacchetti per protocollo, monitoraggio dello stato delle connessioni TCP, istogrammi delle dimensioni dei pacchetti e attività LAN per stazione.",
"menuIntro": "Al lancio si ottiene un menu a cinque opzioni:",
"headerMode": "Modalità",
"headerUseFor": "Usalo per",
"rows": [
{
"mode": "IP traffic monitor",
"useFor": "Elenco in tempo reale dei flussi TCP / UDP / ICMP / altri protocolli IP con contatori di byte e stato della connessione"
},
{
"mode": "General interface stats",
"useFor": "Conteggi aggregati dei pacchetti IPv4 / IPv6 / TCP / UDP / ICMP / non IP per scheda di rete"
},
{
"mode": "Detailed interface stats",
"useFor": "Come sopra, ma per una sola interfaccia, con dettagli sulle dimensioni e sulla frequenza dei pacchetti"
},
{
"mode": "Statistical breakdowns",
"useFor": "Istogramma della distribuzione delle dimensioni dei pacchetti, per porta TCP / UDP"
},
{
"mode": "LAN station monitor",
"useFor": "Per-MAC statistiche del traffico per il dominio broadcast locale"
}
],
"exit": "<strong>Esci:</strong> premi <kbd>x</kbd> da qualsiasi vista oppure <kbd>Q</kbd> dal menu principale. ProxMenux mostra un promemoria prima dell’avvio.",
"logTitle": "Salvataggio delle acquisizioni su file",
"logBody": "Ogni modalità offre di registrare le statistiche catturate a <code>/var/log/iptraf-ng/</code>. Utile se avete bisogno di un record di un picco di traffico — lasciare in esecuzione, registrare a file, rivedere il file dopo invece di cercare di leggere lo schermo dal vivo."
},
"iperf3": {
"heading": "Test della larghezza di banda (iperf3)",
"intro1": "Misura la velocità TCP effettiva tra due host. A differenza di iftop / iptraf-ng, che osservano il traffico esistente, iperf3 genera traffico sintetico per una prova di carico del collegamento. Indispensabile per domande come <em>«la mia rete 10 GbE raggiunge davvero 10 GbE?»</em> oppure <em>«il collo di bottiglia è la scheda di rete, lo switch o lo storage?»</em>.",
"intro2": "iperf3 è uno <strong>strumento per due host</strong>: uno funge da server e ascolta sulla porta TCP 5201; l’altro funge da client, si connette, invia dati e mostra la velocità. Il lanciatore di ProxMenux chiede quale modalità vuoi:",
"headerMode": "Modalità",
"headerBehaviour": "Comportamento",
"headerCli": "Comando CLI equivalente",
"rows": [
{
"mode": "Server",
"behaviour": "Ascolta sulla porta TCP 5201 e mostra i risultati di ogni test in arrivo. Si arresta con Ctrl+C.",
"cli": "iperf3 -s"
},
{
"mode": "Cliente",
"behaviour": "Chiede l’indirizzo IP o il nome host del server, si connette, esegue il test predefinito di 10 secondi e mostra il rapporto.",
"cli": "iperf3 -c <target>"
}
],
"workflowIntro": "Flusso di lavoro tipico per testare un collegamento 10 GbE tra due host Proxmox:",
"workflow": [
"Sull’host A, apri il menu Rete → <em>Test della larghezza di banda (iperf3)</em> → scegli <strong>Server</strong>.",
"Su host B, apri la stessa voce del menu → scegli <strong>Client</strong> → inserisci l'IP dell'host A.",
"Attendere 10 secondi. Confrontare il tasso riportato al massimo teorico del link."
],
"sample": "Esempio di output del client:",
"flagsTitle": "Opzioni utili da usare manualmente dalla shell",
"flagsBody": "<code>-t 60</code> test più lungo (60 s invece di 10 s), <code>-P 4</code> 4 flussi paralleli (saturano prima il collegamento), <code>-R</code> direzione inversa (server → client), <code>-u -b 100M</code> test UDP a 100 Mbit/s (misurazione di jitter e perdita di pacchetti), <code>-p 5202</code> porta diversa (più test in parallelo). Elenco completo in <code>man iperf3</code>.",
"firewallTitle": "Aprire la porta firewall sul server",
"firewallBody": "Il server ascolta TCP <strong>5201</strong> per impostazione predefinita. Se si esegue il server all'interno di un host Proxmox con un firewall rigoroso (datacenter o livello host), consentire TCP 5201 in entrata dall'IP del client per la durata del test, quindi chiudere di nuovo. Lo stesso vale per <code>nftables</code> / <code>iptables</code> su host nudi."
},
"install": {
"heading": "Il primo lancio installa il pacchetto",
"body": "Tutti e tre i lanciatori controllano il binario ed eseguono <code>apt-get update -qq &amp;&amp; apt-get install -y &lt;pkg&gt;</code> se manca. L'installazione è silenziosa: il menu può apparire congelato per 10–30 secondi la prima volta. I lanci successivi iniziano immediatamente."
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"hangTitle": "L’installazione resta bloccata al primo avvio",
"hangBody": "L’host non ha accesso a Internet oppure i repository apt sono irraggiungibili. Annulla con <kbd>Ctrl</kbd>+<kbd>C</kbd>, esegui <code>apt-get update</code> manualmente per vedere l’errore effettivo (DNS, firma del repository, proxy, …), poi torna al menu.",
"refusedTitle": "Client iperf3: «unable to connect to server: Connection refused»",
"refusedBody": "Il server non è in esecuzione oppure il suo firewall blocca TCP 5201. Verifica sul server con <code>ss -tlnp | grep 5201</code>: dovrebbe mostrare iperf3 in ascolto. Se è in ascolto ma il client continua a fallire, controlla i firewall lungo il percorso tra i due host.",
"slowTitle": "iperf3 mostra una velocità molto inferiore a quella prevista per il collegamento",
"slowBody": "Cause comuni in ordine di probabilità: (1) la CPU di uno degli host limita la velocità: prova <code>iperf3 -c &lt;target&gt; -P 4</code> per usare più core; (2) il percorso passa per un collegamento più lento, come uno switch gigabit tra due schede 10 GbE; (3) MTU diversi: controlla <code>ip link show</code> su entrambi i lati; (4) offloading della scheda di rete disabilitato: vedi lo script della community <em>Disable NIC Offloading</em> se hai una scheda Intel e1000e.",
"noTrafficTitle": "iftop / iptraf-ng non mostrano traffico per un host occupato",
"noTrafficBody": "La cattura predefinita è sulla prima interfaccia rilevata. Specificare quello giusto esplicitamente dalla shell: <code>iftop -i vmbr0</code> o <code>iptraf-ng -i vmbr0</code>. Il menu launcher utilizza il default; per le interfacce non di default, viene eseguito da una console."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Diagnostica",
"href": "/docs/network/diagnostics",
"tail": "— i controlli di sola lettura (routing, connettività, statistiche avanzate)."
},
{
"label": "Analisi dei bridge e riparazione guidata",
"href": "/docs/network/bridge-analysis",
"tail": "— quando il monitoraggio rivela un'interfaccia o un ponte non sta facendo ciò che dovrebbe."
}
]
}
}
@@ -0,0 +1,130 @@
{
"meta": {
"title": "Nomi di interfaccia persistenti | Documentazione ProxMenux",
"description": "Associa i nomi delle interfacce Proxmox (eno1, enp3s0, …) agli indirizzi MAC tramite file .link di systemd per mantenerli dopo la rinumerazione PCI, aggiornamenti del kernel e aggiunta o rimozione di altre schede di rete.",
"ogTitle": "Nomi di interfaccia persistenti | Documentazione ProxMenux",
"ogDescription": "Evita che i nomi delle interfacce Proxmox cambino quando modifichi l’hardware. Usa file .link di systemd basati sull’indirizzo MAC."
},
"header": {
"title": "Nomi di interfaccia persistenti",
"description": "Genera un file .link di systemd per ogni scheda di rete fisica, associando il nome assegnato dal kernel all’indirizzo MAC della scheda. Dopo l’applicazione al prossimo riavvio, i nomi delle interfacce rimangono stabili quando aggiungi, rimuovi o sposti schede PCIe.",
"section": "Rete"
},
"intro": {
"title": "Cosa fa",
"body": "Per ogni NIC fisico sull'host, scrive un piccolo file sotto <code>/etc/systemd/network/10-&lt;iface&gt;.link</code> che dice: <em>\"il dispositivo con questo MAC deve sempre essere chiamato questo nome\"</em>. systemd-udevd applica la regola ad ogni avvio, prima che <code>ifupdown</code> legga <code>/etc/network/interfaces</code>."
},
"problem": {
"heading": "Il problema che risolve",
"intro": "Linux ricava i nomi predefiniti delle interfacce dalla topologia PCI: <code>eno1</code> = integrata, <code>enp3s0</code> = scheda sul bus PCI 3, slot 0, ecc. Lo schema dei nomi è deterministico <em>a parità di disposizione hardware</em>. Se la disposizione cambia, cambiano anche i nomi:",
"items": [
"Aggiungere un GPU di fronte a un NIC esistente → il numero di bus NIC può cambiare → cambi di nome.",
"Spostare una scheda in una diversa slot PCIe → cambia nome.",
"Aggiornamento BIOS / UEFI che rienumera i dispositivi → i nomi possono cambiare.",
"Sostituire una scheda difettosa con lo stesso modello in una slot diversa → cambia nome."
],
"outro": "Dopo una modifica simile, <code>/etc/network/interfaces</code> fa ancora riferimento al nome <em>precedente</em>; il bridge non si attiva e l’host perde la rete. Impostare nomi persistenti impedisce che la situazione si ripeta."
},
"howWorks": {
"heading": "Come funziona",
"arrowLabel": "per scheda di rete",
"nodes": {
"detectLabel": "Rileva le schede di rete fisiche",
"detectDetail": "ls /sys/class/net/\nescludi vmbr / bond /\ndocker / veth / wireguard …",
"readLabel": "Leggi ogni MAC",
"readDetail": "cat /sys/class/net/\n '<'iface'>'/address",
"writeLabel": "Scrivi file .link",
"writeDetail": "/etc/systemd/network/\n 10-'<'iface'>'.link"
},
"minimalIntro": "Ogni file generato è intenzionalmente minimo:",
"minimalOutro": "All’avvio, systemd-udevd identifica il dispositivo tramite MAC e assegna il nome richiesto <em>prima</em> che intervengano altri componenti (ifupdown, denominazione predefinita del kernel). Il prefisso <code>10-</code> fa caricare queste regole in anticipo, prima del file predefinito <code>99-default.link</code>."
},
"scope": {
"heading": "Quello che viene scritto, quello che viene saltato",
"headerType": "Tipo",
"headerBehaviour": "Comportamento",
"headerWhy": "Perché?",
"rows": [
{
"type": "Scheda di rete integrata / PCIe",
"behaviour": "File <code>.link</code> scritto",
"why": "Corrisponde a un dispositivo PCI reale: il caso per cui è pensato lo strumento"
},
{
"type": "Wi-Fi (phy80211)",
"behaviour": "File <code>.link</code> scritto",
"why": "Ha un MAC reale e benefici dalla stabilità dei nomi"
},
{
"type": "Ponti (vmbrX)",
"behaviour": "Ignorato",
"why": "Virtuale; il nome viene da <code>/etc/network/interfaces</code>"
},
{
"type": "Bond (bondX)",
"behaviour": "Ignorato",
"why": "Virtuale; il nome del bond è impostato da ifupdown"
},
{
"type": "veth / docker0 / br-XXXX",
"behaviour": "Ignorato",
"why": "Creato su richiesta da Docker / LXC — hardware non persistente"
},
{
"type": "tap / fwpr / fwln",
"behaviour": "Ignorato",
"why": "Creato su richiesta da Proxmox per VM/CT"
},
{
"type": "WireGuard / Cilium / Tailscale",
"behaviour": "Ignorato",
"why": "Interfacce software gestite dai propri demoni"
}
]
},
"safety": {
"heading": "Rete di sicurezza: backup dei file .link precedenti",
"intro": "Se <code>/etc/systemd/network/</code> contiene già file <code>.link</code> da un’esecuzione precedente o da altri strumenti, questi vengono copiati in una directory di backup con data e ora prima di generare i nuovi file:",
"outro": "Per tornare indietro: copiare i file dalla directory di backup e riavviare.",
"rebootTitle": "Prende effetto sul prossimo riavvio, non immediatamente",
"rebootBody": "Le modifiche ai file <code>.link</code> si applicano solo all’avvio, quando udev enumera nuovamente i dispositivi. Per questo lo strumento mostra <em>«Le modifiche saranno applicate dopo il riavvio»</em>. Rinominare un’interfaccia in uso è rischioso e non viene tentato: un <code>vmbr0</code> attivo con interfacce membro andrebbe riconfigurato atomicamente, quindi l’operazione è rimandata al prossimo avvio pulito."
},
"afterReboot": {
"heading": "Dopo il riavvio",
"intro": "Una volta che i nomi sono bloccati, il flusso di lavoro per le future modifiche hardware è semplice:",
"items": [
"Spegni, modifica l’hardware (aggiungi una scheda, cambia slot, …), poi avvia.",
"Ogni NIC mantiene il suo nome precedente perché il suo MAC corrisponde a un file <code>.link</code>.",
"Se una scheda di rete viene sostituita e ha un MAC diverso, riceve un nome predefinito del kernel (<code>enp&lt;bus&gt;s&lt;slot&gt;</code>); esegui di nuovo questo menu per aggiungere una voce <code>.link</code> per il MAC della nuova scheda."
]
},
"troubleshoot": {
"heading": "Risoluzione dei problemi",
"emptyTitle": "\"Nessuna interfaccia fisica trovata\" dopo aver eseguito lo strumento",
"emptyBody": "Il kernel non vede interfacce basate su PCI / phy80211 sull’host. Verifica con <code>ls -l /sys/class/net/</code>: ogni voce dovrebbe avere un collegamento simbolico <code>device</code> (PCI) oppure una voce <code>phy80211</code> (Wi-Fi). Se mancano entrambi per una scheda di rete reale, il driver non è caricato.",
"noChangeTitle": "Dopo il riavvio, i nomi non sono cambiati come previsto",
"noChangeBody": "Verifica che il file esista e sia ben formato: <code>cat /etc/systemd/network/10-&lt;iface&gt;.link</code>. Poi controlla i log di udev: <code>journalctl -u systemd-udevd -b | grep -i link</code>. Una causa comune è un vecchio parametro del kernel <code>net.ifnames=0</code> che disabilita del tutto i nomi prevedibili: rimuovilo da <code>/etc/default/grub</code>, esegui <code>update-grub</code> e riavvia.",
"undoTitle": "Voglio annullare la denominazione persistente",
"undoBody": "Elimina i file <code>.link</code> (<code>rm /etc/systemd/network/10-*.link</code>) oppure ripristinali dalla directory di backup creata nell’esecuzione precedente. Riavvia per applicare."
},
"related": {
"heading": "Correlati",
"items": [
{
"label": "Analisi dei bridge e riparazione guidata",
"href": "/docs/network/bridge-analysis",
"tailRich": " — il percorso di ripristino quando i nomi sono <em>già</em> cambiati."
},
{
"label": "Analisi della configurazione e pulizia guidata",
"href": "/docs/network/config-analysis",
"tail": "— rimuovere i blocchi orfani lasciati alle spalle con i cambi di nome."
},
{
"label": "Diagnostica",
"href": "/docs/network/diagnostics",
"tailRich": " — verifica i nuovi nomi con <em>Mostra tabella di routing</em> dopo il riavvio."
}
]
}
}
@@ -0,0 +1,171 @@
{
"meta": {
"title": "Come viene adattata un’immagine OCI | ProxMenux",
"description": "Dal repository dell’immagine e dal suo file Compose a un modello verificabile, un piano di distribuzione e un LXC nativo di Proxmox VE, senza Docker al suo interno."
},
"header": {
"title": "Come viene adattata un’immagine OCI",
"description": "Dal repository dell’immagine e dal suo file Compose a un modello verificabile, un piano di distribuzione e un LXC nativo, senza installare Docker al suo interno.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "pipeline",
"title": "Il processo di adattamento",
"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": "Repository dell’immagine",
"converter": "Convertitore",
"template": "Modello JSON",
"blockers": "Nessun requisito bloccante?",
"no": "No",
"yes": "Sì",
"review": "Revisione / overlay",
"plan": "Piano di distribuzione",
"lxc": "LXC nativo"
}
}
},
{
"p": "Il convertitore legge l’immagine e il file Compose pubblicati dal progetto e genera un modello JSON. Se alcuni requisiti non possono ancora essere adattati e impediscono l’installazione, il modello viene revisionato prima della pubblicazione nel catalogo. Un file di modifiche verificate, chiamato overlay, risolve questi problemi. Solo i modelli senza requisiti bloccanti vengono proposti per l’installazione."
}
]
},
{
"id": "template",
"title": "Cosa conserva il modello",
"blocks": [
{
"cards": {
"items": [
{
"icon": "archive",
"title": "Identità dell’immagine",
"body": "Repository, tag ad aggiornamento continuo, architettura, digest risolto e revisione di origine."
},
{
"icon": "braces",
"title": "Contratto del container",
"body": "Entrypoint, Cmd, ambiente, utente, directory di lavoro, segnale di arresto, porte e volumi."
},
{
"icon": "layers",
"title": "Adattamento a Proxmox VE",
"body": "Risorse, sicurezza, punti di mount, dispositivi, sysctls, controlli di stato e adattamenti necessari per ciascuno, con la relativa motivazione."
},
{
"icon": "shield",
"title": "Compatibilità",
"body": "Chiavi supportate, requisiti non adattati che impediscono l’installazione e stato di ogni verifica."
}
]
}
}
]
},
{
"id": "sources",
"title": "OCI fornisce il processo, Compose l’ambiente",
"blocks": [
{
"table": {
"headers": [
"Origine",
"Esempio",
"Risultato nativo"
],
"rows": [
[
"Metadati OCI",
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
"Proxmox VE li importa durante la creazione del CT"
],
[
"Docker Compose",
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
"Voci dell’ambiente LXC, <code>mpN</code> e <code>devN</code>"
],
[
"Profilo ProxMenux",
"GPU, controllo di stato, credenziali",
"Domande e adattamenti verificati"
],
[
"Utente",
"VMID, storage, rete",
"Il contratto dell’istanza"
]
]
}
}
]
},
{
"id": "install",
"title": "Cosa succede durante l’installazione",
"blocks": [
{
"steps": {
"items": [
{
"title": "Risolvere il riferimento",
"body": "Viene interrogato il registro, viene scelta l’architettura dell’host e viene fissato il digest esatto a cui punta il tag ad aggiornamento continuo."
},
{
"title": "Scaricare e verificare",
"body": "Skopeo scarica l’immagine come archivio OCI. Prima di creare qualsiasi risorsa, ogni livello viene verificato rispetto al suo digest e decompresso. Se il download è danneggiato, viene ripetuto una volta prima di interrompere l’installazione."
},
{
"title": "Creare il filesystem",
"body": "<code>pct create</code> crea il rootfs a partire dall’archivio e conserva i metadati ufficiali del processo dell’immagine."
},
{
"title": "Collegare le risorse",
"body": "Vengono applicati i volumi, la rete, l’ambiente, i dispositivi e i profili di sicurezza dichiarati."
},
{
"title": "Console",
"body": "L’output della console del container viene conservato sull’host. La console di Proxmox VE apre una shell se l’immagine ne include una."
},
{
"title": "Verificare",
"body": "Al primo avvio si attende che il container riceva un indirizzo e che il servizio risponda. In caso di errore, l’installazione non viene indicata come riuscita."
},
{
"title": "Registrare la configurazione",
"body": "La configurazione effettiva viene salvata nel contratto dell’istanza usato per gli aggiornamenti e le ricreazioni."
}
]
}
}
]
},
{
"id": "example",
"title": "Esempio: un’immagine con /config e /downloads",
"intro": "Una definizione Compose comune e la configurazione Proxmox VE che ne deriva. I percorsi attesi dall’applicazione non cambiano.",
"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 (estratto)",
"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> è un secondo disco appartenente al container, denominato <code>vm-VMID-disk-N</code> sullo storage selezionato. Viene montato in <code>/config</code> e, con <code>backup=1</code>, incluso nel backup del container. <code>mp1</code> non crea alcun disco: monta la directory dell’host <code>/srv/downloads</code> in <code>/downloads</code> all’interno dell’LXC. La porta 8080 non viene mappata: l’LXC ha un proprio indirizzo e il servizio risponde su quello."
}
]
}
]
}
@@ -0,0 +1,278 @@
{
"meta": {
"title": "Installare un’immagine non presente nel catalogo | ProxMenux",
"description": "Adatta un’immagine OCI da un file Compose, un URL, un comando docker run o un riferimento all’immagine e verifica cosa può riprodurre ProxMenux prima di installarla."
},
"header": {
"title": "Installa un’immagine non presente nel catalogo",
"description": "L’immagine viene adattata dal suo file Compose, da un comando docker run o dal solo riferimento. Il risultato viene mostrato per la revisione prima di creare qualsiasi LXC.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Lo stesso convertitore e lo stesso installer",
"body": "L’opzione <strong>Installa un’immagine non presente nel catalogo</strong> usa il convertitore e l’installer dei modelli del catalogo. La differenza è che il contratto viene generato al momento dalla definizione fornita e verificato prima di creare qualsiasi LXC."
}
}
]
},
{
"id": "sources",
"title": "Come viene descritta l’immagine",
"intro": "La prima schermata chiede come viene descritta l’immagine. Quattro opzioni forniscono una definizione da adattare, una quinta usa solo il nome dell’immagine e altre tre leggono un oci-compose già scritto.",
"blocks": [
{
"table": {
"headers": [
"Opzione",
"Cosa legge"
],
"rows": [
[
"Incolla il file Compose nel terminale",
"Incolla il contenuto YAML nel terminale e termina con Ctrl+D."
],
[
"Leggi il file Compose da questo host",
"Un percorso sul nodo, <code>/root/docker-compose.yml</code> per impostazione predefinita. Il file deve esistere e non superare 256 KiB."
],
[
"Scarica il file Compose da un indirizzo",
"Un indirizzo <code>http://</code> o <code>https://</code> che fornisce il contenuto YAML grezzo. Vengono scaricati al massimo 256 KiB."
],
[
"Incolla il comando docker run nel terminale",
"Il comando pubblicato dal progetto. Vengono adattati porte, ambiente, volumi, dispositivi, capability, utente, memoria condivisa e le altre opzioni supportate."
],
[
"Solo il riferimento all’immagine, senza file Compose",
"Un riferimento come <code>ghcr.io/user/application:latest</code>. Viene interrogato il registro e vengono conservati i metadati OCI dell’immagine."
],
[
"Incolla un oci-compose nel terminale",
"Incolla il JSON nel terminale e termina con Ctrl+D. Non viene convertito: viene verificato e installato così come è scritto."
],
[
"Leggi un oci-compose da questo host",
"Un file JSON sul nodo, <code>/root/oci-compose.json</code> per impostazione predefinita, di massimo 2 MiB."
],
[
"Scarica un oci-compose da un indirizzo",
"Un indirizzo <code>http://</code> o <code>https://</code> che fornisce il file JSON. Vengono scaricati al massimo 2 MiB."
]
]
}
},
{
"figure": {
"src": "/oci-manager/custom-source-menu.png",
"alt": "Menu per scegliere come descrivere un’immagine non presente nel catalogo",
"caption": "Modi per descrivere un’immagine non presente nel catalogo."
}
}
]
},
{
"id": "reference-only",
"title": "Cosa fornisce il solo riferimento all’immagine",
"intro": "L’immagine contiene i metadati del processo, ma non tutto l’ambiente che normalmente aggiunge un file Compose.",
"blocks": [
{
"table": {
"headers": [
"Letto dall’immagine",
"Non presente nell’immagine",
"Conseguenza"
],
"rows": [
[
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> e l’ambiente incorporato",
"Variabili presenti solo nella documentazione",
"Vengono aggiunte durante l’installazione o con Modifica"
],
[
"Volumi dichiarati dall’immagine",
"Directory dell’host indicate solo nel file Compose",
"I percorsi aggiuntivi vengono inseriti prima dell’installazione"
],
[
"Porte <code>EXPOSE</code>",
"L’URL, il protocollo o il controllo funzionale del servizio",
"Vengono confermati la porta e il metodo di verifica del servizio"
],
[
"Architetture e digest nel registro",
"Dispositivi, privilegi o dipendenze esterne",
"Non vengono abilitati senza una definizione che li richieda"
]
]
}
}
]
},
{
"id": "review",
"title": "Verifica prima di installare",
"intro": "Dopo aver adattato la definizione, ProxMenux mostra come l’ha interpretata prima di chiedere VMID, risorse o storage.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Analizza",
"body": "Vengono letti servizi, immagine, porte, percorsi, ambiente, dispositivi, sicurezza e controllo di stato."
},
{
"title": "Interroga il registro",
"body": "L’immagine deve esistere nel registro e vengono elencate le architetture pubblicate. Per un registro privato viene usato l’account salvato per quel registro."
},
{
"title": "Elenca ciò che non viene applicato",
"body": "Vengono elencati label, reti Docker, impostazioni Swarm e altre chiavi che non hanno effetto su un LXC."
},
{
"title": "Blocca le opzioni senza equivalente sicuro",
"body": "Le chiavi senza un equivalente sicuro compaiono in <strong>Opzioni senza equivalente</strong> e impediscono di proseguire con l’installazione. Non vengono ignorate senza avviso."
},
{
"title": "Richiedi i segreti",
"body": "Le variabili il cui nome indica una password, un token o una chiave vengono richieste come dati sensibili durante l’installazione."
}
]
}
},
{
"figure": {
"src": "/oci-manager/custom-review.png",
"alt": "Riepilogo di come ProxMenux ha interpretato il file Compose",
"caption": "Riepilogo mostrato prima che l’installer chieda VMID e risorse."
}
},
{
"p": "Dopo aver accettato il riepilogo, il flusso è quello del catalogo: nome, modalità predefinita o avanzata, VMID, CPU, memoria, rete, avvio con il nodo, percorsi persistenti e aggiuntivi, dispositivi compatibili e riepilogo finale."
}
]
},
{
"id": "examples",
"title": "Esempi di input",
"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 scritto a mano",
"intro": "Un oci-compose è il file JSON da cui viene installata un’applicazione. Il catalogo ne conserva uno per ogni applicazione. Lo stesso formato può essere scritto a mano e installato con questa opzione.",
"blocks": [
{
"p": "In un file scritto a mano l’autore decide immagine, porte, variabili, volumi e domande dell’installazione. ProxMenux completa il resto durante la lettura. Il formato può esprimere ciò che Compose non prevede: il testo di una domanda, una password generata all’installazione, un profilo GPU, il proprietario di ciascun volume, il controllo del primo avvio o le credenziali mostrate alla fine."
},
{
"steps": {
"items": [
{
"title": "Verifica",
"body": "I file con errori non vengono installati. Ogni errore indica il campo interessato; se il JSON non è valido, vengono segnalate riga e colonna."
},
{
"title": "Rivedi",
"body": "Un file valido mostra cosa installa: immagine, indirizzo web, porte, percorsi persistenti, variabili richieste dall’installer e file che verranno scritti."
},
{
"title": "Installa",
"body": "L’installazione è la stessa delle applicazioni del catalogo, con impostazioni predefinite o avanzate."
}
]
}
},
{
"calloutWarning": {
"title": "Un file che determina i privilegi",
"body": "Un oci-compose stabilisce cosa viene montato nel container e con quali privilegi. La revisione lo mostra prima dell’installazione: installa solo file provenienti da fonti attendibili."
}
},
{
"p": "Il <readmeLink>README del motore OCI</readmeLink> descrive il formato blocco per blocco con due esempi completi. Anche il record di un’installazione può essere letto nello stesso modo: viene usato solo il modello originale, senza alcuna delle risposte di quell’installazione."
}
]
},
{
"id": "private-registries",
"title": "Immagini in registri privati",
"intro": "Un’immagine in un registro privato, come un pacchetto privato su GitHub o un repository privato su Docker Hub, viene letta con un account salvato in ProxMenux.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Il registro nega l’accesso all’immagine",
"body": "Quando il registro indica che l’immagine richiede un account, la revisione propone di accedere a quel registro e legge di nuovo l’immagine."
},
{
"title": "Accedi",
"body": "Un nome utente e una password o un token autorizzato a scaricare l’immagine. Il registro li verifica e vengono salvati solo se accettati."
},
{
"title": "Installa e mantieni aggiornato",
"body": "L’account viene usato per scaricare l’immagine durante l’installazione e anche per aggiornamenti, Modifica, Ricrea, watchdog e ricerca degli aggiornamenti del Monitor, su qualsiasi nodo del cluster."
}
]
}
},
{
"p": "<strong>Account dei registri</strong>, nel menu principale di OCI manager Apps, elenca gli account salvati per registro e utente, senza mostrarne i segreti. Da ogni account puoi verificare, scaricare o installare un’immagine e aggiornare o rimuovere le credenziali."
},
{
"list": {
"items": [
"GitHub (<code>ghcr.io</code>): l’utente è l’account GitHub e la password è un token di accesso personale con il permesso <code>read:packages</code>.",
"Docker Hub (<code>docker.io</code>): l’utente è l’account Docker Hub e la password è un token di accesso con permesso di lettura.",
"Altri registri, anche con una porta propria come <code>registry.example.com:5000</code>: nome utente e password o token forniti da quel registro."
]
}
},
{
"calloutInfo": {
"title": "Dove vengono salvati gli account",
"body": "In <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, leggibile solo da root, nella stessa cartella in cui Proxmox conserva le password degli storage. <code>/etc/pve</code> è condiviso tra tutti i nodi del cluster, quindi un account aggiunto su un nodo viene usato su tutti. Il backup dell’host include il file e la disinstallazione di ProxMenux lo rimuove da tutti i nodi."
}
}
]
},
{
"id": "limits",
"title": "Definizioni che non vengono installate",
"blocks": [
{
"list": {
"items": [
"Un Dockerfile senza immagine pubblicata: prima occorre creare l’immagine e pubblicarla in un registro OCI.",
"Un file Compose con più servizi: viene bloccato perché questa opzione installa un solo servizio per container, anche se più servizi usano la stessa immagine.",
"<code>configs</code>, segreti esterni o formati di dispositivi che non possono essere adattati senza ambiguità.",
"Sostituzioni della shell come <code>$(command)</code>: occorre inserire direttamente il valore risultante.",
"Opzioni <code>docker run</code> non riconosciute e <code>--env-file</code>: usa invece un file Compose con valori espliciti."
]
}
}
]
}
]
}
@@ -0,0 +1,392 @@
{
"meta": {
"title": "Dispositivi e accelerazione | ProxMenux",
"description": "Come OCI manager Apps passa GPU, NVIDIA, Coral, USB, FUSE e altri dispositivi a un contenitore OCI come risorse native Proxmox VE convalidate."
},
"header": {
"title": "Dispositivi e accelerazione",
"description": "I dispositivi GPU, NVIDIA, Coral, USB, FUSE e a blocchi diventano risorse native convalidate Proxmox VE del contenitore.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "principle",
"title": "Il dispositivo di cui l'applicazione ha bisogno, non l'intero host",
"blocks": [
{
"p": "Un dispositivo richiesto dal file Compose o dal profilo dell’applicazione viene configurato come voce <code>devN</code> specifica o come montaggio LXC. Richiedere una GPU, un dispositivo USB o un acceleratore Coral non rende il container privilegiato."
},
{
"flow": {
"nodes": [
{
"label": "Inventario host",
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
},
{
"label": "ProxMenux",
"detail": "produttore e\npermessi verificati"
},
{
"label": "LXC",
"detail": "stesso dispositivo\nGID effettivo"
}
]
}
}
]
},
{
"id": "origin",
"title": "Da dove proviene la richiesta del dispositivo",
"blocks": [
{
"table": {
"headers": [
"Fonte",
"Cosa si legge",
"Cosa fa l'installatore"
],
"rows": [
[
"Docker Compose",
"<code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> e NVIDIA richieste",
"Ogni esigenza diventa una richiesta di dispositivo mostrata per la revisione"
],
[
"Profilo del catalogo",
"Il supporto effettivo dell’applicazione per GPU, Coral, OpenCL, USB o FUSE",
"Solo le opzioni convalidate per quell'immagine sono offerte"
],
[
"Metadati e documentazione dell’immagine",
"VA-API, Selkies, mod LinuxServer o runtime NVIDIA",
"Vengono aggiunte le variabili documentate e la preparazione"
],
[
"Selezione utente",
"CPU solo, Intel/AMD, OpenCL, NVIDIA o un dispositivo opzionale",
"La selezione viene memorizzata nel contratto di istanza"
]
]
}
},
{
"calloutWarning": {
"title": "I dispositivi rilevati non vengono collegati automaticamente",
"body": "Viene creato un inventario dell’host, ma solo i dispositivi dichiarati dal file Compose o da un profilo compatibile sono offerti e allegati. Una GPU, USB dongle o Coral presente sull'host non è esposto ad ogni LXC."
}
}
]
},
{
"id": "identify",
"title": "Come viene identificato il dispositivo host",
"intro": "Prima della modifica del LXC, il dispositivo viene letto sull'host e abbinato al profilo scelto.",
"blocks": [
{
"table": {
"headers": [
"Tipo",
"Identità",
"Validazione"
],
"rows": [
[
"Intel/AMD DRM",
"<code>/dev/dri/renderD*</code> e <code>/sys/class/drm/NODE/device/vendor</code>",
"Un dispositivo a caratteri con il fornitore <code>0x8086</code> (Intel) o <code>0x1002</code> (AMD)"
],
[
"AMD OpenCL",
"Il nodo di rendering, più <code>/dev/kfd</code> quando il profilo ne ha bisogno",
"Esistenza, tipo, fornitore, autorizzazioni e compatibilità dichiarata"
],
[
"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."
],
[
"NVIDIA",
"<code>nvidia-smi</code> e <code>nvidia-container-cli</code>",
"GPU, UUID, bus PCI, versione driver, Toolkit, nodi <code>/dev/nvidia*</code>, binari e librerie"
],
[
"Coral PCIe/M.2",
"<code>/dev/apex_N</code> e il suo collegamento in <code>/sys/dev/char/MAJOR:MINOR</code>",
"Nodo a caratteri, numeri major/minor, proprietario, GID e permessi"
],
[
"USB e seriale",
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> o <code>/dev/bus/usb/BBB/DDD</code>",
"Nodo di carattere; per USB anche produttore, prodotto e seriale quando sysfs li pubblica"
],
[
"KVM, TUN, FUSE, video e SCSI generici",
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> o <code>/dev/sgN</code>",
"Percorso supportato, tipo nodo e permessi effettivi"
],
[
"Unità ottica",
"<code>/dev/srN</code>",
"Un dispositivo a blocchi"
]
]
}
}
]
},
{
"id": "install",
"title": "Cosa succede durante l'installazione",
"blocks": [
{
"steps": {
"items": [
{
"title": "Il modello offre i suoi profili",
"body": "Ad esempio solo CPU, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL o NVIDIA. Le opzioni appartengono all'immagine, non a un menu comune."
},
{
"title": "Viene scelto un profilo",
"body": "Definisce i nodi del dispositivo, ambiente, mod o runtime di cui l'applicazione ha bisogno."
},
{
"title": "Si propone un percorso",
"body": "Per DRM, <code>/dev/dri/renderD128</code>, che può essere modificato su un host con diversi nodi di rendering. Per USB o seriale, viene selezionato il nodo specifico."
},
{
"title": "Validazione",
"body": "Esistenza, tipo, fornitore consentito, autorizzazioni e GID sono controllati. Un errore blocca l'operazione."
},
{
"title": "Il contratto è scritto",
"body": "Percorso, modalità, GID, accesso scrittura e profilo sono registrati per aggiornamenti e ricreazioni."
},
{
"title": "Collega e verifica",
"body": "<code>pct set</code> aggiunge l'ingresso <code>devN</code> e l'accesso viene quindi controllato all'interno del LXC. Le immagini LinuxServer vengono anche controllate come utente <code>abc</code>."
}
]
}
}
]
},
{
"id": "config",
"title": "Come appare nella configurazione LXC",
"intro": "Valori illustrativi: <code>dev0</code> e <code>dev1</code> sono gli slot liberi assegnati da Proxmox VE; <code>renderD128</code>, <code>apex_0</code> e il GID dipendono dall’hardware del nodo.",
"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 dispositivo USB specifico",
"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": "Il GID è letto con <code>stat</code> sull'host e scritto all'ingresso <code>devN</code>; i gruppi <code>render</code> e <code>video</code> non si presume abbiano un numero fisso. Il dispositivo mantiene lo stesso percorso <code>/dev</code> all'interno del LXC, dove i propri meccanismi dell'applicazione lo cercano."
}
]
},
{
"id": "profiles",
"title": "Profili che un’immagine può offrire",
"blocks": [
{
"table": {
"headers": [
"Profilo",
"Configurazione risultante",
"Offerto quando"
],
"rows": [
[
"Intel/AMD VA-API",
"Nodo di rendering <code>/dev/dri</code>",
"L'applicazione supporta l'accelerazione video"
],
[
"OpenCL",
"Nodo di rendering, <code>/dev/kfd</code> quando necessario e mod ufficiale",
"L'immagine o il profilo lo documentano"
],
[
"NVIDIA",
"Dispositivi driver e librerie dell'host",
"L’host dispone di un driver funzionante e di NVIDIA Container Toolkit"
],
[
"Coral",
"<code>/dev/apex_0</code> o il bus USB",
"Il profilo dichiara il supporto Coral (Frigate)"
],
[
"USB, seriale, FUSE",
"Un singolo dispositivo, un albero convalidato o una funzione LXC",
"Il contratto lo chiede"
]
]
}
}
]
},
{
"id": "nvidia",
"title": "NVIDIA",
"blocks": [
{
"calloutWarning": {
"title": "Requisito del nodo: NVIDIA Container Toolkit",
"body": "Un driver funzionante su Proxmox VE non è sufficiente per dare un NVIDIA GPU ad un'immagine OCI. OCI manager Apps utilizza <code>nvidia-container-cli</code>, dal NVIDIA Container Toolkit, per identificare i dispositivi e per ottenere i binari e le librerie che corrispondono al driver caricato."
}
},
{
"p": "L’<nvidiaLink>installatore NVIDIA di ProxMenux</nvidiaLink> installa NVIDIA Container Toolkit dal repository ufficiale NVIDIA insieme al driver. Controlla i quattro pacchetti, convalida <code>nvidia-container-cli</code> e registra il risultato nel registro delle modifiche di <auditLink>Audit & Report</auditLink>."
},
{
"p": "Questi due comandi sull'host mostrano se il driver e il Toolkit sono disponibili:"
},
{
"shell": {
"code": "nvidia-smi -L\nnvidia-container-cli --version"
}
},
{
"p": "Su un host dove il driver è stato installato con altri mezzi, il Toolkit è installato dal repository ufficiale stabile:"
},
{
"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’inventario utilizzato da OCI manager Apps è l'output di:"
},
{
"shell": {
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
}
},
{
"calloutInfo": {
"title": "La configurazione di runtime Docker non è coinvolta",
"body": "I container sono LXC nativi e non usano un demone Docker, quindi <code>nvidia-ctk runtime configure --runtime=docker</code> non interviene: ProxMenux interroga direttamente <code>nvidia-container-cli</code> e configura dispositivi e montaggi LXC. I comandi e le piattaforme supportate sono mantenuti nella <toolkitLink>guida di installazione di NVIDIA Container Toolkit</toolkitLink>."
}
},
{
"cards": {
"items": [
{
"icon": "cpu",
"title": "Inventario dal driver",
"body": "<code>nvidia-container-cli</code> elenca i nodi del dispositivo, i binari, il firmware e le librerie del driver installato."
},
{
"icon": "refresh",
"title": "Nessuna versione fissa",
"body": "Il modello non nomina i file della libreria. Il profilo viene generato dall'host corrente."
},
{
"icon": "shield",
"title": "Montaggi in sola lettura",
"body": "Le librerie ospitanti sono montate in sola lettura invece di essere copiate nel contenitore."
},
{
"icon": "hardDrive",
"title": "Modifiche dei driver",
"body": "Dopo che un driver cambia l'inventario viene generato nuovamente prima dell'avvio dei LXC colpiti."
}
]
}
},
{
"code": {
"title": "Risultati NVIDIA (semplificati)",
"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": "Passare solo <code>/dev/nvidia0</code> non è sufficiente. I componenti user-space del driver caricato sono montati in sola lettura e <code>nvidia-smi</code> poi funziona all'interno del LXC per confrontare GPU, UUID, PCI bus e versione con l'inventario host."
}
]
},
{
"id": "usb",
"title": "USB, seriale e USB Coral",
"blocks": [
{
"calloutWarning": {
"title": "Numerazione USB può cambiare",
"body": "Un percorso come <code>/dev/bus/usb/003/004</code> può cambiare quando il dispositivo viene ricollegato o l'host si riavvia. Il profilo registra il fornitore, il prodotto e la serie quando sono disponibili, ma un nuovo indirizzo del bus non viene rimappato automaticamente."
}
},
{
"p": "Una periferica è data dal suo nodo specifico: <code>/dev/ttyUSB0</code>, <code>/dev/ttyACM0</code>, <code>/dev/apex_0</code> o <code>/dev/bus/usb/BBB/DDD</code>. Passare l'intero <code>/dev</code> non è accettato. Coral è offerto solo a applicazioni il cui profilo lo dichiara."
}
]
},
{
"id": "trees",
"title": "Alberi dei dispositivi e funzionalità LXC",
"blocks": [
{
"table": {
"headers": [
"Richiesta",
"Configurazione risultante",
"Ambito"
],
"rows": [
[
"<code>/dev/dvb</code>, <code>/dev/snd</code> o <code>/dev/bus/usb</code>",
"Ogni nodo di carattere dell'albero ottiene il proprio ingresso <code>devN</code> con la modalità host e GID",
"Solo l'albero richiesto, non il resto di <code>/dev</code>"
],
[
"<code>/dev/fuse</code>",
"Il nodo e, quando il profilo ne ha bisogno, la funzione <code>fuse=1</code>",
"FUSE da solo non rende disponibili i montaggi agli altri LXC"
],
[
"<code>/dev/net/tun</code>",
"Un ingresso <code>devN</code> nello stesso percorso all'interno del LXC",
"La configurazione VPN o di rete rimane nell’applicazione"
],
[
"<code>/dev/kvm</code>",
"Una voce valida <code>devN</code>",
"Offerto solo quando il contratto lo chiede"
]
]
}
}
]
},
{
"id": "security",
"title": "Conferma per livello di rischio",
"blocks": [
{
"p": "Dispositivi concreti, privilegio facoltativo, privilegio richiesto, allentamento di AppArmor o seccomp e accesso al namespace PID host sono trattati come casi separati, non sotto una generica etichetta privilegiata. Ogni opzione con un rischio viene spiegata e confermata durante l'installazione."
}
]
}
]
}
+213
View File
@@ -0,0 +1,213 @@
{
"meta": {
"title": "OCI manager Apps | ProxMenux",
"description": "Esegui immagini OCI ufficiali come container LXC nativi di Proxmox VE, con dati persistenti, accesso ai dispositivi, applicazioni composte da più container e aggiornamenti transazionali."
},
"header": {
"title": "OCI manager Apps",
"description": "Le immagini OCI ufficiali vengono eseguite come container LXC nativi di Proxmox VE. L’immagine rimane quella pubblicata dal manutentore; ProxMenux ricrea l’ambiente che Docker Compose avrebbe predisposto intorno ad essa.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "model",
"blocks": [
{
"calloutInfo": {
"title": "Un’immagine OCI, un LXC nativo",
"body": "Nei container non viene eseguito Docker Engine. Proxmox VE importa il filesystem dell’immagine e i suoi metadati OCI. L’applicazione diventa il processo principale di un LXC nativo, gestito con gli stessi strumenti degli altri container del nodo."
}
},
{
"flow": {
"nodes": [
{
"label": "Origine",
"detail": "Immagine OCI\nCompose e documentazione"
},
{
"label": "ProxMenux",
"detail": "Contratto JSON\nvalidazione e pianificazione"
},
{
"label": "Proxmox VE",
"detail": "LXC nativo\nvolumi e dispositivi"
}
],
"caption": "Si usa l’applicazione originale: il suo ambiente viene descritto in modo dichiarativo e riprodotto."
}
}
]
},
{
"id": "where",
"title": "Dove si trova",
"intro": "Sul nodo Proxmox, come root, apri <strong>OCI manager Apps (Technology Preview)</strong> dal menu principale di ProxMenux. La prima schermata offre:",
"blocks": [
{
"list": {
"items": [
"<strong>Cerca applicazioni</strong>: cerca per nome nell’intero catalogo.",
"<strong>Tutte le applicazioni</strong>: mostra il catalogo completo e il numero di applicazioni.",
"<strong>Gestisci le applicazioni OCI installate</strong>: aggiorna, modifica, rimuovi o recupera le applicazioni già installate.",
"<strong>Account dei registri</strong>: gestisci gli account usati per installare e aggiornare immagini da registri privati.",
"<strong>Installa un’immagine non presente nel catalogo</strong>: adatta un file Compose, un comando <code>docker run</code> o un riferimento a un’immagine.",
"Le categorie del catalogo, ciascuna con il numero di applicazioni."
]
}
},
{
"figure": {
"src": "/oci-manager/main-menu.png",
"alt": "Schermata principale di OCI manager Apps con ricerca, catalogo completo, gestione delle applicazioni, immagini fuori catalogo e categorie.",
"caption": "Schermata principale di OCI manager Apps."
}
},
{
"p": "Selezionando un’applicazione vengono mostrati la descrizione, l’immagine usata e due modalità di installazione. <strong>Installa con le impostazioni predefinite</strong> chiede solo le scelte essenziali: storage, posizione dei dati, indirizzo e avvio. <strong>Installa con le impostazioni avanzate</strong> presenta tutte le decisioni in ordine: VMID e risorse, storage per ogni percorso, bridge di rete e dispositivi."
},
{
"p": "Le applicazioni provate sul campo mostrano <strong>Verificato</strong> in questa schermata e un ✓ negli elenchi, sia per i test del laboratorio ProxMenux sia per quelli della community."
}
]
},
{
"id": "beta",
"title": "Perché mantiene l’etichetta Technology Preview",
"blocks": [
{
"p": "OCI manager Apps mantiene l’etichetta <strong>Technology Preview</strong> assegnata da Proxmox VE ai container applicativi creati da immagini OCI, il cui supporto è stato introdotto in Proxmox VE 9.1. L’etichetta riguarda la tecnologia su cui si basa OCI manager Apps, non il motore di ProxMenux: il comportamento di questi container può ancora cambiare tra le versioni di Proxmox VE. Rimarrà finché Proxmox VE non considererà stabile tale supporto."
},
{
"p": "Il motore di OCI manager Apps viene testato nel laboratorio ProxMenux: installazione, aggiornamento, modifica, ricreazione, backup, ripristino, migrazione e watchdog. Ogni applicazione viene verificata separatamente. Quelle provate sul campo mostrano <strong>Verificato</strong> e un ✓ negli elenchi."
}
]
},
{
"id": "translation",
"title": "Come Docker descrive i requisiti e come li realizza OCI manager Apps",
"blocks": [
{
"table": {
"headers": [
"Requisito",
"Come lo esprime Docker",
"Come lo realizza OCI manager Apps"
],
"rows": [
[
"Eseguire l’applicazione",
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
"Il rootfs OCI e il processo principale dell’LXC"
],
[
"Conservare la configurazione",
"<code>volumes: /config</code>",
"Un volume persistente <code>mpN</code> incluso nel backup, oppure una directory dell’host."
],
[
"Rendere accessibile il servizio",
"<code>ports</code>",
"Un indirizzo proprio per l’LXC e l’URL di accesso al servizio."
],
[
"Usare l’hardware",
"<code>devices</code>, <code>group_add</code>",
"Voci <code>devN</code> con il GID effettivo dell’host e un profilo validato."
],
[
"Collegare le dipendenze",
"<code>networks</code>, <code>depends_on</code>",
"Un bridge di rete privato, indirizzi fissi, ordine di avvio e controlli di stato."
],
[
"Aggiornare",
"Scaricare con <code>pull</code> e ricreare",
"Un nuovo rootfs che mantiene lo stesso contratto di persistenza."
]
]
}
}
]
},
{
"id": "kept",
"title": "Cosa viene conservato e cosa cambia",
"blocks": [
{
"cards": {
"items": [
{
"icon": "archive",
"title": "Conservato",
"body": "L’immagine ufficiale, i percorsi interni, l’ambiente, il processo di avvio e la documentazione d’uso."
},
{
"icon": "boxes",
"title": "Adattato",
"body": "L’ambiente di esecuzione: rete, persistenza, dispositivi, permessi e dipendenze utilizzano i meccanismi LXC nativi di Proxmox VE."
},
{
"icon": "shield",
"title": "Senza equivalente",
"body": "Un’opzione Compose senza un equivalente sicuro viene segnalata come requisito bloccante. I modelli con requisiti bloccanti non vengono proposti per l’installazione e le opzioni sensibili richiedono conferma durante la procedura."
},
{
"icon": "refresh",
"title": "Registrato",
"body": "Il digest dell’immagine, le risorse, i percorsi, la rete, i dispositivi e l’appartenenza a uno stack vengono salvati nel contratto dell’istanza. Aggiornamenti e ricreazioni riproducono tale contratto."
}
]
}
}
]
},
{
"id": "pages",
"title": "Pagine di questa sezione",
"blocks": [
{
"next": {
"items": [
{
"label": "Come viene adattata un’immagine OCI",
"href": "/docs/oci-manager/architecture",
"tail": "Dall’immagine e dal suo file Compose a un LXC nativo."
},
{
"label": "Installare un’immagine non presente nel catalogo",
"href": "/docs/oci-manager/custom-image",
"tail": "Un file Compose, un comando docker run o un riferimento a un’immagine."
},
{
"label": "Dati, percorsi e rete",
"href": "/docs/oci-manager/storage-network",
"tail": "Volumi del container, directory dell’host, mount con rclone e indirizzi."
},
{
"label": "Dispositivi e accelerazione",
"href": "/docs/oci-manager/hardware",
"tail": "GPU, NVIDIA, Coral, USB e altri dispositivi."
},
{
"label": "Applicazioni con più container",
"href": "/docs/oci-manager/stacks",
"tail": "Applicazione, database e cache in LXC coordinati."
},
{
"label": "Installazione, aggiornamento e modifica",
"href": "/docs/oci-manager/lifecycle",
"tail": "Il contratto dell’istanza e le sue operazioni."
},
{
"label": "In ProxMenux Monitor",
"href": "/docs/oci-manager/monitor",
"tail": "Versioni, aggiornamenti, output della console e terminale."
}
]
}
}
]
}
]
}
@@ -0,0 +1,499 @@
{
"meta": {
"title": "Installare, aggiornare e modificare | ProxMenux",
"description": "Il contratto di istanza di un contenitore OCI e le operazioni che lo utilizzano: aggiornamento, modifica, rimozione, recupero di un'operazione interrotta e recupero dopo un ripristino su questo o un altro host."
},
"header": {
"title": "Installare, aggiornare e modificare",
"description": "Ogni istanza conserva un contratto riproducibile, così il suo rootfs può essere sostituito senza perdere la configurazione o i dati persistenti.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "contract",
"title": "Il contratto di istanza",
"blocks": [
{
"p": "Dopo l'installazione, la configurazione effettiva viene salvata in <code>/usr/local/share/proxmenux/oci/instances/VMID/oci-compose.json</code>. Non è una copia del file Compose originale: è il contratto riproducibile del LXC presente su questo host."
},
{
"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": "Una copia del contratto si trova nel contenitore, in <code>/.proxmenux/oci-record.json</code>, ed è leggibile solo dall'utente root del contenitore. Il backup del contenitore include quindi sempre il contratto in uso in quel momento. Una seconda copia si trova in <code>/etc/pve/priv/proxmenux/oci</code>, condiviso da tutti i nodi del cluster e leggibile solo da root dell'host. Entrambe le copie vengono scritte dopo ogni installazione, aggiornamento e modifica."
}
]
},
{
"id": "manage",
"title": "Gestisci le applicazioni OCI installate",
"intro": "Questa opzione della schermata principale elenca le istanze registrate con la relativa applicazione e immagine. Prima di ogni azione, ciascuna istanza viene confrontata con il proprio contratto; un CT che non corrisponde più al proprio record non viene né modificato né eliminato. Lo stesso aggiornamento e lo stesso editor sono disponibili nella scheda Aggiornamenti di <monitorLink>ProxMenux Monitor</monitorLink>.",
"blocks": [
{
"table": {
"headers": [
"Opzione",
"Che cosa cambia",
"Che cosa viene conservato"
],
"rows": [
[
"Aggiorna l’immagine mantenendo la configurazione salvata",
"Il rootfs viene sostituito dall'immagine attualmente pubblicata dal canale salvato",
"Contratto, dischi container, directory host, rete e dispositivi"
],
[
"Modifica risorse, rete, percorsi e GPU",
"L’editor si apre con il contratto attuale; il CT viene ricreato con le modifiche",
"I dati dei dischi container e delle directory host"
],
[
"Watchdog: riavviare l'applicazione quando si blocca",
"Determina se l'applicazione viene riavviata quando si arresta da sola. Non viene ricreato nulla",
"L'intera installazione; solo la scelta viene salvata nel contratto"
],
[
"Rimuovi: elimina l'applicazione e i suoi container",
"Il LXC, o ogni membro di uno stack, e i loro contratti vengono eliminati",
"Directory dell’host, con il loro contenuto"
]
]
}
},
{
"p": "Per un'applicazione con più contenitori, il menu offre <strong>Aggiorna tutti i contenitori dell'applicazione</strong>, <strong>Modifica percorsi e dispositivi aggiuntivi</strong>, <strong>Ricrea tutti i contenitori con la configurazione salvata</strong>, il watchdog e la rimozione. Modifica aggiunge o rimuove percorsi e dispositivi aggiuntivi del contenitore applicativo senza ricreare nulla e, in Immich, cambia il componente che esegue il riconoscimento. Ricrea ricostruisce ogni contenitore dall'immagine usata per installarlo, senza cercarne una più recente."
},
{
"figure": {
"src": "/oci-manager/manage-menu.png",
"alt": "Elenco delle applicazioni OCI installate e delle opzioni di aggiornamento, modifica e rimozione",
"caption": "Gestione delle applicazioni OCI installate."
}
}
]
},
{
"id": "update",
"title": "Un aggiornamento transazionale",
"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": "Utente",
"registry": "Registro OCI",
"update": "Aggiorna istanza",
"resolve": "Risolvere il tag",
"verify": "Verifica archivio e controlli preliminari",
"backup": "Arresta e salva un backup del CT",
"import": "Importa il nuovo rootfs",
"reapply": "Applicare nuovamente il contratto",
"healthy": "integro",
"failure": "guasto",
"commit": "Contratto pubblicato con il nuovo digest",
"restored": "Precedente istanza ripristinata"
}
}
},
{
"list": {
"items": [
"Se il registro restituisce ancora il digest installato, non viene scaricato nulla e l’istanza rimane invariata.",
"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.",
"Qualsiasi altra differenza tra il CT e il suo contratto interrompe l’aggiornamento prima che il CT venga arrestato."
]
}
},
{
"flow": {
"nodes": [
{
"label": "Prima",
"detail": "rootfs A\n/config mp0\ndirectory host /media"
},
{
"label": "Aggiornamento",
"detail": "sostituisce solo\nil rootfs"
},
{
"label": "Dopo",
"detail": "rootfs B\n/config mp0\ndirectory host /media"
}
]
}
},
{
"p": "Prima di arrestare qualsiasi cosa, l’operazione verifica lo spazio necessario al backup: i dati in uso nei volumi inclusi, più un margine. Il backup viene scritto accanto al record dell’applicazione, sul disco di sistema dell’host. Se lo spazio non basta, il menu richiede un altro storage dell’host che supporti i backup: il backup viene creato lì ed eliminato al termine dell’operazione. La scelta viene memorizzata per l’applicazione, anche per gli aggiornamenti pianificati. Se nessuno storage ha spazio sufficiente, l’operazione viene rifiutata e l’applicazione resta invariata. Anche lo spazio per la nuova immagine viene verificato prima del download."
}
]
},
{
"id": "recovery",
"title": "Recuperare un'operazione interrotta",
"intro": "L’aggiornamento e la modifica usano una transazione persistente. Se il processo, il terminale o il nodo subisce un’interruzione dopo l’arresto del CT, l’operazione non viene considerata conclusa.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Indicatore di operazione in sospeso",
"body": "Aprendo Gestisci le applicazioni OCI installate, lo stato salvato indica che la sostituzione non è mai stata pubblicata."
},
{
"title": "Visualizza stato",
"body": "Mostra la fase raggiunta senza cambiare contenitori o dati."
},
{
"title": "Ripristina l’installazione precedente",
"body": "Ripristina il backup nativo verificato eseguito prima della sostituzione e il contratto precedente."
},
{
"title": "Stacks come unità",
"body": "Per un'applicazione multicontainer, ogni membro viene recuperato dallo stesso punto di transazione, non solo quello selezionato."
}
]
}
},
{
"calloutWarning": {
"title": "Le directory dell’host sono escluse dal rollback",
"body": "Il backup comprende il rootfs e i dischi del contenitore inclusi nella copia. Una directory dell’host non viene riportata allo stato precedente, perché altri LXC potrebbero usarne i dati."
}
}
]
},
{
"id": "watchdog",
"title": "Watchdog: riavviare un’applicazione che si arresta",
"intro": "Proxmox non ha una politica di riavvio: quando termina il processo di un contenitore applicativo, il contenitore resta arrestato. Con il watchdog attivo, un’applicazione che si arresta da sola viene riavviata. Per un’applicazione OCI svolge il ruolo di <code>restart: unless-stopped</code> in un file Compose.",
"blocks": [
{
"table": {
"headers": [
"Cosa succede?",
"Con il watchdog attivo"
],
"rows": [
[
"L'applicazione si blocca o il suo processo termina",
"Il contenitore viene riavviato entro pochi secondi"
],
[
"Viene fermato o spento da Proxmox, dal Monitor o con <code>pct</code>",
"Resta arrestato finché qualcuno non lo avvia"
],
[
"Un backup, una migrazione o un'operazione ProxMenux sta lavorando su di esso",
"Niente è fatto fino a che non finisce"
],
[
"Era già arrestato all’avvio dell’host",
"Resta arrestato; lo decide <strong>Avvia con Proxmox</strong>"
],
[
"Continua ad arrestarsi subito dopo l’avvio",
"Per un’applicazione che si arresta pochi secondi dopo l’avvio o che non si avvia, vengono effettuati cinque tentativi, con attese di 30 secondi, 1, 2 e 5 minuti tra un tentativo e l’altro. Poi viene lasciata arrestata e viene inviata una notifica"
]
]
}
},
{
"p": "L’installatore lo chiede in entrambe le modalità e propone il valore dichiarato nella ricetta dell’applicazione. In seguito si può cambiare da <strong>Gestisci le applicazioni OCI installate</strong> o con l’interruttore <strong>Watchdog</strong> del contenitore in <monitorLink>ProxMenux Monitor</monitorLink>; vale per tutti i contenitori di un’applicazione con più contenitori. Un unico servizio dell’host, <code>proxmenux-oci-watchdog.service</code>, sorveglia tutte le applicazioni che lo hanno richiesto; la sua installazione compare nella scheda Modifiche di Audit & Report."
},
{
"calloutInfo": {
"title": "Ciò che l’host non può distinguere",
"body": "Il codice di uscita dell’applicazione non raggiunge l’host: un’uscita regolare e un arresto anomalo risultano quindi indistinguibili e in entrambi i casi l’applicazione viene riavviata, come con <code>always</code> e <code>unless-stopped</code> in Docker. Un arresto richiesto fuori da Proxmox, con <code>lxc-stop</code> o <code>systemctl</code>, non lascia un’attività di arresto e viene interpretato come un arresto spontaneo."
}
}
]
},
{
"id": "restore",
"title": "Backup, ripristino e un altro host",
"intro": "Un backup creato con vzdump o Proxmox Backup Server include il contenitore, i dischi del contenitore selezionati per il backup e la copia del suo contratto. Ciò che l’installazione conserva sull’host non vi è incluso. <strong>Gestisci le applicazioni OCI installate</strong> rileva i contenitori ripristinati su un host privo del loro contratto, dopo una nuova installazione di Proxmox o su un altro host, e propone di registrarli di nuovo.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Ripristinare i contenitori in Proxmox",
"body": "Dall'archivio di backup, con l'ID originale o con uno qualsiasi libero. Un'applicazione multi-container ha bisogno di tutti i suoi contenitori."
},
{
"title": "Apri Gestisci applicazioni OCI installate",
"body": "Vengono elencati i contenitori ripristinati e viene proposto il recupero. Il pulsante <strong>Recupera</strong> nella scheda Aggiornamenti di <monitorLink>ProxMenux Monitor</monitorLink> apre lo stesso recupero."
},
{
"title": "Controllare prima di cambiare",
"body": "Il recupero verifica che l’host disponga di tutto ciò che serve a ciascuna applicazione. Se un’applicazione non può essere recuperata interamente, viene lasciata invariata e viene indicato il motivo."
},
{
"title": "Registra e avvia",
"body": "Il contratto viene registrato su questo host e gli elementi che l’installazione vi conservava vengono riscritti. L’avvio delle applicazioni viene chiesto separatamente: rispondi No se i contenitori originali sono ancora in esecuzione su un altro host."
}
]
}
},
{
"figure": {
"src": "/oci-manager/restore-offer.png",
"alt": "Finestra di dialogo che elenca i contenitori ripristinati e ne propone il recupero",
"caption": "Il recupero offerto quando si apre Gestione applicazioni OCI installate."
}
},
{
"table": {
"headers": [
"Ciò che l’host conservava",
"Dopo il recupero"
],
"rows": [
[
"Contratto dell’istanza",
"Registrato dalla copia presente nel contenitore, verificata rispetto alla configurazione ripristinata da Proxmox"
],
[
"Rete privata di un'applicazione multicontainer",
"Creato nuovamente con lo stesso ponte e sottorete; gli indirizzi fissi dei contenitori non cambiano"
],
[
"Ordine di avvio di un’applicazione con più contenitori",
"L’hookscript delle dipendenze e il suo contratto vengono reinstallati; gli snippet vengono abilitati nello storage <code>local</code> se nessuno storage li supporta"
],
[
"Sysctl di rete e file del monitor dell’host",
"Scritto di nuovo in <code>/etc/pve/proxmenux</code>"
],
[
"Runtime NVIDIA",
"L’hook di un contenitore non privilegiato viene reinstallato. Un contenitore privilegiato riceve i file del driver di questo host al posto di quelli dell’host di origine"
],
[
"Montaggio Rclone",
"L’hookscript e i programmi che rendono disponibile il mount vengono riscritti, con le stesse viste sull’host"
],
[
"Regola del firewall host di un monitor host",
"Viene chiesto di nuovo, per la sua porta web e la sottorete del bridge su questo host"
],
[
"<code>lost+found</code> di ogni disco restaurato",
"Viene rimosso se vuoto; il ripristino lo crea e alcune applicazioni non si avviano se è presente tra i loro dati"
],
[
"Dischi ripristinati su un altro storage",
"Il contratto viene aggiornato con lo storage su cui si trovano ora"
]
]
}
},
{
"p": "Un container ripristinato con un ID diverso conserva la propria applicazione. Il contratto, il log della console, i parametri sysctl di rete, lo hookscript del montaggio Rclone e l’ordine di avvio di un’applicazione composta da più container vengono registrati usando gli ID assegnati ai container su questo host."
},
{
"table": {
"headers": [
"Cosa ferma un recupero",
"Cosa fare"
],
"rows": [
[
"Manca un contenitore di un'applicazione multi-container",
"Ripristina anche quello; l’applicazione viene recuperata per intero"
],
[
"La sottorete privata è già utilizzata su questo host",
"Il recupero è annullato e nulla è cambiato: gli indirizzi dei contenitori sono fissi e non vengono spostati in un'altra subnet"
],
[
"Una directory host non esiste",
"Montare o crearlo con i suoi dati; un backup del contenitore non include directory host"
],
[
"Un dispositivo non esiste su questo host",
"Collegarlo o rimuoverlo dal contenitore in Proxmox"
],
[
"Un'applicazione con NVIDIA su un host senza driver",
"Installa il driver NVIDIA e il Container Toolkit"
],
[
"Il backup è stato fatto prima che la copia del contratto esistesse",
"Il contenitore rimane come un normale LXC e non viene offerto di nuovo"
]
]
}
},
{
"calloutInfo": {
"title": "Un contenitore che ritorna",
"body": "Un contenitore ripristinato su se stesso da un backup precedente, riportato a uno snapshot o rientrato da un altro nodo porta il contratto dello stato in cui si trova. Se viene selezionato per un’operazione e il suo contratto differisce da quello dell’host, l’operazione non parte e viene proposto il recupero del contenitore."
}
},
{
"figure": {
"src": "/oci-manager/restore-result.png",
"alt": "Risultato del recupero con la rete privata, l’ordine di avvio e i contenitori registrati",
"caption": "Il risultato di un recupero, passo dopo passo."
}
}
]
},
{
"id": "remove",
"title": "Rimozione di un'applicazione OCI",
"blocks": [
{
"p": "Prima della conferma viene creato un riepilogo dalla configurazione effettiva: i contenitori da rimuovere, i dati eliminati insieme a loro, la rete privata liberata e le directory dell’host conservate. La conferma è impostata su <strong>No</strong> per impostazione predefinita, perché i dati dei dischi eliminati non possono essere recuperati in seguito."
},
{
"table": {
"headers": [
"Risorsa",
"Alla rimozione",
"Motivo"
],
"rows": [
[
"rootfs e dischi del contenitore",
"Eliminati",
"Essi appartengono solo al contenitore"
],
[
"Directory host",
"Tenuto, con il suo contenuto",
"Altre applicazioni possono utilizzarlo"
],
[
"File host del contenitore",
"Eliminati",
"Il log della console, i parametri sysctl di rete, l’hookscript del mount Rclone e la registrazione nella scheda App di ProxMenux Monitor non servono ad altri contenitori"
],
[
"File condivisi da più installazioni",
"Eliminato con l'ultima installazione che li utilizza",
"Il file del monitor dell’host e l’hookscript delle dipendenze delle applicazioni con più contenitori"
],
[
"Contratto dell’istanza",
"Eliminato dopo una rimozione di successo",
"Non vi è più associato alcun CT"
],
[
"Ponte privato di una pila",
"Rilasciato con lo stack",
"Non ha più membri da collegare"
],
[
"Rete condivisa dalla suite Arr",
"Rilasciato con l'ultima applicazione della suite",
"Ogni applicazione della suite è indipendente e viene rimossa da sola"
],
[
"Un singolo membro di una pila",
"Non rimosso da solo",
"L'intera applicazione viene rimossa, quindi nessun stack viene lasciato incompleto"
],
[
"Un contenitore su un altro nodo del cluster",
"Non rimosso",
"I suoi file di registrazione e host sono sul nodo dove è stato installato: viene rimosso lì, dopo la migrazione indietro"
]
]
}
},
{
"figure": {
"src": "/oci-manager/remove-summary.png",
"alt": "Riepilogo di rimozione con i container, i dati e le directory host interessate",
"caption": "Il sommario di rimozione, costruito dalla configurazione reale."
}
}
]
},
{
"id": "archives",
"title": "Immagini scaricate e spazio host",
"blocks": [
{
"p": "L’archivio OCI serve a costruire il rootfs; il CT in esecuzione non lo legge. Dopo un’installazione o un aggiornamento, gli archivi scaricati durante l’operazione vengono elencati con le loro dimensioni e ne viene proposta l’eliminazione. Eliminarli libera spazio senza influire sul contenitore o sui suoi dati."
},
{
"calloutInfo": {
"title": "Gli aggiornamenti non hanno bisogno dell'archivio",
"body": "Senza l'archivio, un aggiornamento risolve il canale salvato e scarica il nuovo digest. Con esso, un archivio viene riutilizzato solo quando il suo riferimento e l'integrità corrispondono a ciò che è richiesto."
}
}
]
},
{
"id": "registry",
"title": "Registro e pulizia",
"blocks": [
{
"p": "Aprendo <strong>Gestisci le applicazioni OCI installate</strong>, vengono prima rimossi i resti dei contenitori che non esistono su alcun nodo del cluster: il record conservato come cronologia dopo l’eliminazione dall’interfaccia Proxmox e i file sull’host lasciati da una rimozione. Un record con un’operazione incompleta viene conservato, perché il relativo backup potrebbe ancora servire. Volumi e directory dell’host non vengono mai eliminati per deduzione."
}
]
},
{
"id": "cluster",
"title": "In un cluster: migrazione e elevata disponibilità",
"intro": "Un contenitore OCI è un normale LXC Proxmox: può essere migrato o gestito da HA come gli altri, con gli stessi limiti. Ciò che gli serve per avviarsi viene conservato dove ogni nodo del cluster può trovarlo.",
"blocks": [
{
"table": {
"headers": [
"Parte",
"Su un altro nodo del cluster"
],
"rows": [
[
"Registro della console",
"Il contenitore crea <code>/var/log/proxmenux/oci</code> prima di avviarsi, su qualunque nodo lo esegua. Ogni nodo conserva il log degli avvii eseguiti su quel nodo."
],
[
"Sysctl di rete e monitor dell’host",
"Tenuto in <code>/etc/pve/proxmenux</code>, che ogni nodo del cluster condivide, quindi un contenitore migrato li trova."
],
[
"Dischi del contenitore",
"Proxmox li sposta con il contenitore. HA richiede che i dati siano disponibili sul nodo di destinazione tramite storage condiviso o una configurazione di replica supportata."
],
[
"directory e dispositivi host",
"Valgono le stesse regole degli altri LXC: una directory dell’host deve esistere sul nodo di destinazione ed essere contrassegnata come condivisa, e una GPU, un Coral o una NPU deve essere presente su quel nodo."
],
[
"Record ProxMenux",
"Il contratto resta sul nodo in cui l’applicazione è stata installata e ogni nodo legge la copia conservata in <code>/etc/pve/priv/proxmenux/oci</code>. Dopo la migrazione, un’applicazione con un solo contenitore viene registrata sul nodo di destinazione quando si apre <strong>Gestisci le applicazioni OCI installate</strong> o si avvia un’operazione su di essa. Per un’applicazione con più contenitori viene proposto il recupero, perché la rete privata deve essere creata su quel nodo."
]
]
}
},
{
"calloutWarning": {
"title": "Non per alta disponibilità",
"body": "Un'applicazione multicontainer raggiunge i suoi membri attraverso un ponte privato del nodo su cui è stato installato, quindi i suoi membri rimangono su quel nodo. Un monitor host, come Glances in modalità host o Netdata, monitora il nodo su cui corre; spostandolo monitorerebbe un altro nodo."
}
},
{
"p": "Quando si recupera l’applicazione, un backup ripristinato fuori dal cluster riceve i file di <code>/etc/pve/proxmenux</code> usati dal contenitore."
}
]
},
{
"id": "channel",
"title": "Un rolling tag non è un aggiornamento incustodito",
"blocks": [
{
"p": "Il catalogo installa il rolling tag pubblicato dal manutentore, ma il digest effettivo viene risolto e registrato e cambia solo con un aggiornamento esplicito, dotato di controlli preliminari e rollback. <monitorLink>ProxMenux Monitor</monitorLink> confronta il digest installato con quello pubblicato dal registro e segnala, anche con una notifica, la disponibilità di una nuova immagine."
}
]
}
]
}
@@ -0,0 +1,213 @@
{
"meta": {
"title": "Contenitori OCI in ProxMenux Monitor | ProxMenux",
"description": "Ciò che ProxMenux Monitor mostra per un contenitore installato da OCI manager Apps: versioni di applicazione e immagine, nuove immagini, uscita console e terminale Proxmox VE."
},
"header": {
"title": "In ProxMenux Monitor",
"description": "Un contenitore installato da OCI manager Apps appare in VMs & LXCs come qualsiasi altro LXC. Il suo modal legge il record di installazione: versioni di applicazione e immagine, nuove immagini, uscita console e terminale.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Il record è la fonte",
"body": "OCI manager Apps sa cosa ha installato e da dove viene. Il Monitor legge quel record di installazione invece di interrogare il container, quindi i dati sono gli stessi se il contenitore è in esecuzione o interrotto."
}
},
{
"table": {
"headers": [
"Scheda",
"Quali cambiamenti per un contenitore OCI"
],
"rows": [
[
"Stato",
"Un commutatore <strong>Watchdog</strong> sotto Start al boot: l'applicazione viene riavviata quando si ferma da sola"
],
[
"App",
"L'applicazione è identificata dal record, e gli aggiornamenti sono tracciati dall'immagine"
],
[
"Aggiornamenti",
"L'immagine viene aggiornata o l'applicazione modificata, con lo stesso flusso del menu OCI"
],
[
"Montaggi",
"Dischi del container e directory dell’host, con il relativo utilizzo"
],
[
"Log",
"Solo per contenitori OCI: l'uscita della console dell'applicazione"
]
]
}
}
]
},
{
"id": "app",
"title": "App",
"intro": "La scheda <appLink>App</appLink> offre l'applicazione installata come rilevamento, con il nome, il logo, la porta e lo schema del record. Registrandolo si apre l'editor con il metodo <strong>Immagine OCI (installata da ProxMenux)</strong>, che non ha bisogno di configurazione.",
"blocks": [
{
"cards": {
"items": [
{
"icon": "boxes",
"title": "Applicazione",
"body": "La versione dell'applicazione all'interno dell'immagine, letta dall'immagine stessa: il suo ambiente o la sua etichetta <code>org.opencontainers.image.version</code>. È informativo."
},
{
"icon": "archive",
"title": "Immagine",
"body": "La data di creazione e digest dell'immagine installata. L'aggiornamento si decide qui: il digest installato viene confrontato con quello che il registro pubblica oggi per lo stesso tag."
}
]
}
},
{
"list": {
"items": [
"Quando il registro pubblica un nuovo digest, la scheda mostra <strong>Nuova immagine</strong> con la sua data e digest, anche se la versione dell'applicazione al suo interno non è cambiata: una ricostruzione su una base aggiornata è un aggiornamento.",
"Quando i digest coincidono, la scheda mostra <strong>Versione</strong>.",
"La scheda si collega al repository dell'immagine: il suo progetto GitHub, o la sua pagina Hub Docker per un'immagine ufficiale.",
"Il collegamento di accesso utilizza l'indirizzo LAN del contenitore, anche per il membro principale di un'applicazione multi-container, che ha un secondo indirizzo sulla sua rete privata.",
"Il pulsante <strong>Aggiorna dati</strong> rilegge il record dell’installazione e il registro delle immagini. Non vengono proposte opzioni per cercare o registrare altre applicazioni: il container contiene esattamente l’applicazione descritta nel suo record."
]
}
},
{
"figure": {
"src": "/oci-manager/monitor-app-tab.png",
"alt": "Scheda App di un contenitore OCI con la versione dell'applicazione, l'immagine e il link del repository",
"caption": "Scheda app di un contenitore installato da OCI manager Apps."
}
},
{
"p": "Il controllo viene eseguito una volta al giorno con i controlli di aggiornamento del Monitor e <strong>Aggiorna dati</strong> lo esegue subito. Una nuova immagine viene inviata come notifica attraverso i canali configurati in <notificationsLink>Notifiche</notificationsLink>. L'aggiornamento viene applicato dalla scheda Aggiornamenti."
}
]
},
{
"id": "updates",
"title": "Aggiornamenti",
"intro": "Per un contenitore installato da OCI manager Apps la scheda Aggiornamenti mostra l'applicazione con la sua immagine installata e, quando il registro pubblica una, la nuova immagine, nello stesso formato di qualsiasi altra applicazione. Gli strumenti di aggiornamento di pacchetti e applicazioni di un normale LXC non appaiono.",
"blocks": [
{
"table": {
"headers": [
"Pulsante",
"Che cosa si apre"
],
"rows": [
[
"Aggiornamento",
"L’aggiornamento di <lifecycleLink>Gestisci applicazioni OCI installate</lifecycleLink> per questo container, nel terminale di Monitor. Può essere eseguito anche senza una nuova immagine; in quel caso non cambia nulla. In un’applicazione composta da più container aggiorna tutti i membri."
],
[
"Modifica",
"L'editor dell'applicazione (risorse, rete, percorsi e GPU). In un'applicazione multi-container aggiunge o rimuove i percorsi e i dispositivi aggiuntivi del contenitore di applicazione e, in Immich, cambia ciò che esegue il riconoscimento."
],
[
"Recupera",
"Sostituisce l'aggiornamento quando un'operazione sul contenitore è stata interrotta e apre il suo recupero."
],
[
"Recupera (container ripristinato)",
"Mostrato per un container ripristinato da un backup che non ha un contratto su questo host, sotto <strong>Applicazione OCI ripristinata</strong>. Apre il <lifecycleLink>recupero</lifecycleLink> nel terminale di Monitor; Aggiorna e Modifica compaiono dopo la registrazione."
]
]
}
},
{
"p": "Modifiche esterne, directory dell’host e applicazioni composte da più container vengono gestite come nel menu OCI. Per queste applicazioni, pulsanti e opzioni compaiono solo nel container principale. Gli altri membri mostrano la propria immagine, una nota che rimanda al principale per gli aggiornamenti e un pulsante per aprirlo. Alla chiusura del terminale vengono riletti l’immagine, il record e i montaggi."
},
{
"table": {
"headers": [
"Opzione",
"Comportamento"
],
"rows": [
[
"Conserva il backup eseguito prima dell'aggiornamento",
"Ogni aggiornamento esegue il backup del container per ripristinarlo se l'aggiornamento non riesce. Con questa opzione, lo stesso backup viene mantenuto nello storage scelto e compare tra i backup del CT; su Proxmox Backup Server viene scritto un backup prima dell'aggiornamento."
],
[
"Aggiornamenti pianificati",
"L’immagine viene aggiornata all’ora scelta solo se il registro ne pubblica una nuova, con la possibilità di attendere che abbia 1, 3, 7 o 14 giorni. Un container modificato al di fuori di ProxMenux viene saltato e segnalato."
]
]
}
}
]
},
{
"id": "logs",
"title": "Log",
"intro": "La scheda Logs appare solo per i contenitori installati da OCI manager Apps, tra Mounts e Backups. Mostra l'uscita standard e l'errore del processo principale dell'immagine, la stessa uscita mostra <code>docker logs</code> per un contenitore Docker.",
"blocks": [
{
"list": {
"items": [
"L'output viene mantenuto sull'host in <code>/var/log/proxmenux/oci/VMID.console.log</code> (mode 0600), dal primo avvio e attraverso riavviamenti, in modo da poter essere letto con il contenitore fermato.",
"Il file viene ruotato a 10 MB, mantenendo tre copie compresse (<code>/etc/logrotate.d/proxmenux-oci</code>).",
"Ogni avvio del contenitore è contrassegnato nell'uscita. La scheda mostra l'output dall'ultimo avvio per impostazione predefinita; <strong>Cronologia completa</strong> mostra anche quelli precedenti.",
"Quando l'applicazione viene rimossa, la sua uscita viene rimossa con essa.",
"Vengono mostrate le ultime 100, 500 o 1000 righe. Mentre il container è in esecuzione, le nuove righe sono seguite in tempo reale; scorrere verso l’alto mette in pausa il seguito e <strong>Segui</strong> lo riprende.",
"Un filtro mostra solo le linee che contengono un testo e <strong>Scarica</strong> salva le linee caricate.",
"I codici a colori sono rimossi e una linea che una barra di avanzamento ridisegna è mostrata nel suo stato finale.",
"La scheda legge il file a ogni apertura; non usa una copia in cache."
]
}
},
{
"calloutInfo": {
"title": "credenziali di primo avviamento",
"body": "Le immagini che stampano una password generata sul loro primo inizio lo lasciano in questa uscita, come fa <code>docker logs</code>. L'installatore lo legge da lì per mostrarlo nel suo riassunto."
}
},
{
"figure": {
"src": "/oci-manager/monitor-logs-tab.png",
"alt": "Scheda di log con l'uscita della console di un contenitore OCI, il selettore della linea, il filtro e il pulsante seguente",
"caption": "Uscita console di un contenitore OCI."
}
}
]
},
{
"id": "terminal",
"title": "Console Proxmox VE",
"blocks": [
{
"p": "Un'immagine OCI esegue il proprio processo come PID 1 e nessun servizio di login, quindi la console predefinita di un LXC aprirebbe un terminale in cui nulla risponde. I contenitori installati da OCI manager Apps sono creati con <code>cmode: shell</code>: la console Proxmox VE apre una shell con <code>lxc-attach</code>, l'equivalente di <code>docker exec</code>, con l'applicazione in esecuzione intatta."
},
{
"list": {
"items": [
"La shell è quella assegnata a root nell’immagine da <code>/etc/passwd</code>. Se root non ha una shell o l’immagine non ne include alcuna, viene mantenuta la console predefinita.",
"La shell viene eseguita come root all'interno del contenitore, senza una password. Chi può aprirlo è deciso dal permesso <code>VM.Console</code> di Proxmox VE.",
"Il terminale del Monitor entra nel contenitore con <code>pct enter</code>, che funziona allo stesso modo."
]
}
}
]
},
{
"id": "mounts",
"title": "Montaggi",
"blocks": [
{
"p": "La scheda <mountsLink>Mounts</mountsLink> elenca i dischi container e le directory host del contenitore. L'uso di un disco contenitore su blocco di archiviazione come LVM-thin è letto dal filesystem del disco, che è montato solo all'interno del contenitore."
}
]
}
]
}
@@ -0,0 +1,404 @@
{
"meta": {
"title": "Applicazioni multicontainer | ProxMenux",
"description": "Come OCI manager Apps trasforma un'applicazione con il suo database e la cache in LXCs nativi coordinati: piano, rete privata, gancio di dipendenza, convalida e aggiornamenti transazionali."
},
"header": {
"title": "Applicazioni con più container",
"description": "Un'applicazione con il suo database, la cache e altri servizi diventa diversi LXC nativi coordinati, installati e aggiornati come uno.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "Un'applicazione per l'utente, diversi LXC per Proxmox VE",
"body": "Una definizione multi-container è una voce del catalogo. L'installatore crea un LXC nativo per servizio e mantiene esplicite le proprie dipendenze. Immich, Nextcloud, Paperless-ngx e Tandoor sono installati in questo modo."
}
},
{
"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": "Piano di stack",
"app": "Applicazione LXC",
"appNet": "LAN + privato",
"db": "PostgreSQL LXC",
"cache": "Valkey LXC",
"private": "privato"
}
}
}
]
},
{
"id": "plan",
"title": "1. Il piano, prima che esista un contenitore",
"blocks": [
{
"p": "Nessun LXC viene creato mentre la definizione Compose viene interpretata. Un piano completo arriva prima, con ogni membro, immagine, VMID, rete, percorso, segreto, ordine e controllo sanitario. Se il piano non è coerente, l'installazione non inizia."
},
{
"table": {
"headers": [
"Elemento di piano",
"Contenuto",
"Controllato prima di creare qualcosa"
],
"rows": [
[
"Membri",
"Applicazione principale, database, cache, machine learning e altre dipendenze",
"VMID unici, ruoli noti e esattamente un membro principale"
],
[
"Immagini",
"Riferimento rolling, architettura e digest risolto di ogni servizio",
"Tutte esistono, supportano l’architettura e superano il controllo di integrità OCI"
],
[
"Rete",
"Ponte privato, subnet, indirizzo fisso per servizio e accesso LAN per il membro principale",
"Nessuna collisione con ponti o sottorete esistenti e nessun indirizzo ripetuto"
],
[
"Persistenza",
"Dischi dei container, directory dell’host, proprietari e backup",
"Nessun percorso sovrapposto, deposito disponibile e permessi dichiarati"
],
[
"Segreti",
"password del database, chiavi dell'applicazione e credenziali iniziali",
"Generati una volta e forniti solo ai membri che li usano"
],
[
"Ciclo di vita",
"Ordine di inizio, ordine di arresto e un controllo sanitario per membro",
"L'applicazione principale inizia l'ultima e si ferma prima"
]
]
}
}
]
},
{
"id": "create",
"title": "2. Creazione, membro per membro",
"blocks": [
{
"steps": {
"items": [
{
"title": "Prenota ogni VMID",
"body": "L'inventario Proxmox VE e il registro delle istanze sono controllati. Un CT esistente non è adottato e un contratto che appartiene ancora ad un'altra istanza non viene riutilizzato."
},
{
"title": "Preparare ogni immagine",
"body": "Tutte le immagini vengono risolte, scaricate e verificate prima che venga creato il primo contenitore."
},
{
"title": "Creare ogni rootfs",
"body": "I metadati OCI ufficiali sono importati, e l'identità di istanza ProxMenux e il ruolo membro sono aggiunti."
},
{
"title": "Rete privata",
"body": "Viene creato un ponte e una subnet e ogni membro riceve il suo indirizzo fisso; solo il membro principale riceve anche l'interfaccia LAN."
},
{
"title": "Persistenza",
"body": "Ogni database e configurazione ottiene il proprio disco contenitore; solo i dati destinati ad essere condivisi utilizzano directory host."
},
{
"title": "Ambiente",
"body": "Vengono scritti endpoint interni, segreti condivisi e variabili di servizio. L'applicazione raggiunge le sue dipendenze nei loro indirizzi privati riservati."
},
{
"title": "Registrazione",
"body": "Ogni membro registra la sua configurazione nativa, le modifiche rootfs che gli aggiornamenti devono riprodurre e la sua relazione con lo stack."
}
]
}
}
]
},
{
"id": "checks",
"title": "3. Avviare e controllare ogni contenitore",
"intro": "Un LXC creato non significa un servizio pronto. Le dipendenze iniziano in ordine e ognuno passa un controllo specifico al suo servizio.",
"blocks": [
{
"table": {
"headers": [
"Servizio",
"Controllo",
"Cosa mostra"
],
"rows": [
[
"PostgreSQL",
"<code>pg_isready</code> nel CT con l'host previsto, l'utente e il database",
"Il server accetta le connessioni per il database configurato"
],
[
"Redis / Valkey",
"<code>redis-cli</code> o <code>valkey-cli</code> <code>PING</code> contro il suo indirizzo privato",
"Il broker ascolta e risponde"
],
[
"Machine learning Immich",
"HTTP <code>GET /ping</code>, oltre a un controllo del runtime GPU selezionato",
"Il servizio risponde e l’accelerazione richiesta non è passata alla CPU"
],
[
"Nextcloud",
"<code>GET /status.php</code> con <code>installed=true</code>, <code>maintenance=false</code> e <code>needsDbUpgrade=false</code>",
"Inizializzazione terminata senza migrazione in sospeso"
],
[
"Paperless-ngx / Tandoor",
"HTTP sull'indirizzo LAN e vera porta del servizio",
"Il frontend e le sue dipendenze servono l'applicazione"
],
[
"Applicazione principale",
"Il punto finale del suo modello, ad esempio <code>/api/server/ping</code> in Immich",
"L'intero stack funziona attraverso l'applicazione che utilizza le dipendenze"
]
]
}
},
{
"calloutWarning": {
"title": "In esecuzione non significa funzionante",
"body": "Lo stato in esecuzione dice solo che esiste il processo LXC. Se il servizio offre un controllo migliore, viene utilizzato un controllo exec o HTTP con un timeout. Se un membro si ferma o non supera la verifica, lo stack non viene dichiarato installato."
}
}
]
},
{
"id": "hook",
"title": "4. Il gancio di dipendenza",
"blocks": [
{
"p": "Il gancio è impostato solo sul contenitore principale di uno stack dipendente. Proxmox VE mantiene lo script come snippet e lo gestisce come <code>hookscript</code> di quel CT. La ricetta dello stack non è scritta nello script: vive in un contratto privato separato."
},
{
"codeGrid": {
"items": [
{
"title": "Configurazione principale CT",
"code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh"
},
{
"title": "Contratto privato (esempio)",
"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": "Fonte completa di proxmenux-stack-dependencies.sh",
"pathCode": "local:snippets/proxmenux-stack-dependencies.sh",
"snippetCode": "stackDependencyHook"
}
},
{
"p": "Lo script è lo stesso per ogni stack. VMID, nomi, tipi di controllo e timeout provengono dal contratto privato <code>/etc/pve/priv/proxmenux-stack-VMID.json</code> di ogni stack."
},
{
"steps": {
"items": [
{
"title": "Proxmox VE chiama pre-start",
"body": "Prima dell'avvio principale di CT, il gancio viene eseguito con il VMID e la fase del ciclo di vita."
},
{
"title": "Un blocco per stack",
"body": "<code>flock</code> su <code>/run/lock/proxmenux-stack-VMID.lock</code> previene due sequenze di avvio contemporaneamente."
},
{
"title": "Il contratto viene letto e convalidato",
"body": "Uno schema noto, dipendenze numeriche, etichette, un exec, http o controllo in esecuzione e un timeout positivo sono necessari."
},
{
"title": "Dipendenze in ordine",
"body": "Ogni CT deve esistere; se è fermo viene avviato, se è già in esecuzione non viene riavviato."
},
{
"title": "Attendi che il servizio sia pronto",
"body": "Il controllo viene eseguito ogni due secondi, e il CT è confermato anche di essere ancora in esecuzione."
},
{
"title": "Il principale CT inizia",
"body": "Quando ogni dipendenza è pronta, pre-start termina e Proxmox VE avvia l'applicazione."
}
]
}
},
{
"calloutInfo": {
"title": "Il gancio non ferma le dipendenze",
"body": "Le fasi post-start, pre-stop e post-stop non fanno nulla. Arrestare il CT principale lascia in esecuzione PostgreSQL, Redis, Valkey o il machine learning. L’hook ordina l’avvio; non trasforma diversi LXC in un unico processo."
}
},
{
"table": {
"headers": [
"Tipo",
"Esempio",
"Avvii successivi"
],
"rows": [
[
"stack dipendente",
"Immich, Nextcloud, applicazione con PostgreSQL",
"L’hook del CT principale avvia le dipendenze e attende che siano pronte."
],
[
"Suite di applicazione",
"Suite Arr",
"Nessun membro principale: ogni LXC segue il proprio <code>onboot</code>"
],
[
"Applicazione singola",
"Jellyfin",
"Proxmox VE avvia direttamente LXC"
]
]
}
}
]
},
{
"id": "stack-checks",
"title": "5. Controlla sullo stack nel suo complesso",
"blocks": [
{
"list": {
"items": [
"Ogni VMID esiste, è unico e mantiene l'identità di istanza prevista.",
"Ogni contratto appartiene allo stesso stack, mantiene il suo ruolo e la sua configurazione nativa registrata.",
"Il membro principale è l’ultimo in <code>start_order</code> e il primo in <code>stop_order</code>.",
"Nessun membro, volume o adattamento rootfs manca.",
"Il gancio punta al snippet ufficiale, il suo contenuto è invariato e il suo contratto corrisponde alla ricetta stack.",
"Le immagini e i digest osservati corrispondono agli archivi OCI preparati.",
"Dispositivi, profili GPU, montaggi, segreti ed endpoint corrispondono ancora ai contratti.",
"Quando tutte le dipendenze superano i controlli, l’endpoint dell’applicazione principale verifica l’integrazione fra i membri."
]
}
}
]
},
{
"id": "manage",
"title": "Gestione di uno stack installato",
"intro": "In <strong>Gestisci applicazioni OCI installate</strong>, qualsiasi membro porta all’intero stack. Il menu offre <strong>Aggiorna tutti i container dell’applicazione</strong>, <strong>Modifica percorsi e dispositivi aggiuntivi</strong>, <strong>Ricrea tutti i container con la configurazione salvata</strong> e <strong>Rimuovi: elimina l’applicazione e i suoi container</strong>. Ricrea ricostruisce ogni container dall’immagine originale tramite il digest salvato, senza cercarne una più recente, seguendo gli stessi passaggi di un aggiornamento. È disponibile per gli stack aggiornabili.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Qualsiasi membro",
"body": "Il contratto dei membri nomina il VMID principale e l'elenco completo dei membri."
},
{
"title": "Lo stack è riproducibile",
"body": "Identità, contratti, gancio, adattamenti e una ripetizione coordinata per quella ricetta sono convalidati."
},
{
"title": "Immagini prima",
"body": "L'applicazione non viene fermata fino a quando ogni digest è stato risolto, scaricato e verificato."
},
{
"title": "Arresta i componenti e crea un backup dell'insieme",
"body": "I backup nativi verificati sono presi con lo stack fermato, quindi l'applicazione e i database appartengono allo stesso momento."
},
{
"title": "Aggiornare e controllare ogni membro",
"body": "Adattamento, rete, montaggi, segreti e dispositivi vengono applicati nuovamente prima del controllo di integrità di ciascun membro."
},
{
"title": "Pubblica o recupera tutto",
"body": "I nuovi contratti sono pubblicati solo quando ogni membro passa. Se uno fallisce, ogni membro viene ripristinato."
}
]
}
},
{
"table": {
"headers": [
"Modifica",
"Quali cambiamenti",
"Cosa viene conservato"
],
"rows": [
[
"Percorsi e dispositivi aggiuntivi",
"Vengono aggiunti o rimossi dal contenitore di applicazione, che si riavvia. Nulla è ricostruito",
"I dati dell'applicazione, il suo database e gli altri contenitori"
],
[
"Che cosa esegue il riconoscimento (Immich)",
"Il contenitore di apprendimento automatico prende l'immagine e i dispositivi del CPU o di un GPU dell'host. L'intera applicazione viene interrotta e aggiornata, come in un aggiornamento",
"La cache del modello, la libreria e il database. Se qualcosa fallisce, i contenitori precedenti e la scelta precedente vengono ripristinati"
]
]
}
},
{
"calloutWarning": {
"title": "Una pila senza un replay coordinato non è aggiornata",
"body": "Se la preparazione di uno stack non può essere riprodotta, l'aggiornamento viene rifiutato prima che lo stack venga interrotto. L'applicazione continua a funzionare come è."
}
}
]
},
{
"id": "failure",
"title": "6. Quando qualcosa fallisce",
"blocks": [
{
"p": "Durante un'installazione, un errore si ferma e rimuove i contenitori incompleti che l'operazione ha creato, e il ponte privato se l'operazione l'ha creata. Una pila non viene pubblicata come valida fino al termine dell'intera sequenza."
},
{
"p": "Un aggiornamento è transazionale: tutte le immagini sono preparate prima, poi lo stack si ferma, viene eseguito e verificato il backup di ogni membro, e solo allora è sostituito ogni rootfs. I membri iniziano uno per uno con il loro controllo sanitario; se uno fallisce, ogni membro viene ripristinato dalla stessa serie di backup, quindi il database e l'applicazione non appartengono mai a momenti diversi."
},
{
"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": "Preparare ogni immagine",
"stop": "Stop, primo membro principale",
"backup": "Backup verificato di ogni CT",
"replace": "Sostituisci il rootfs",
"healthy": "Tutti funzionanti?",
"yes": "Sì",
"no": "No",
"commit": "Pubblica i contratti",
"rollback": "Ripristinare ogni membro"
}
}
}
]
},
{
"id": "not-assumed",
"title": "Che cosa uno stack non include",
"blocks": [
{
"list": {
"items": [
"Una suite installata in un unico flusso, come la suite Arr, non è uno stack dipendente: i suoi contenitori non hanno ordine di partenza tra di loro.",
"La rete privata non sostituisce l'autenticazione, TLS o la configurazione di ogni applicazione.",
"Il backup di un LXC non contiene il ponte, il gancio o i contratti del resto dello stack.",
"Prowlarr, Sonarr o Radarr non ricevono indici, profili o fornitori da ProxMenux."
]
}
}
]
}
]
}
@@ -0,0 +1,305 @@
{
"meta": {
"title": "Dati, percorsi e rete | ProxMenux",
"description": "Come OCI manager Apps conserva i dati di un container OCI: dischi del container, directory dell’host, mount con rclone, indirizzi e reti private."
},
"header": {
"title": "Dati, percorsi e rete",
"description": "Cosa risiede nel rootfs, cosa viene conservato quando lo si sostituisce, come si condividono i dati tra container e come ciascuno ottiene il proprio indirizzo.",
"section": "OCI manager Apps"
},
"sections": [
{
"id": "intro",
"blocks": [
{
"calloutInfo": {
"title": "La persistenza si decide prima di creare l’LXC",
"body": "I volumi dichiarati dall’immagine e dal suo file Compose vengono letti prima di creare il container. Ogni percorso da conservare dopo un aggiornamento diventa un punto di mount indipendente dal rootfs. In questo modo, il rootfs contiene solo ciò che appartiene all’immagine e può essere sostituito."
}
}
]
},
{
"id": "questions",
"title": "Cosa chiede l’installer",
"intro": "Il modello fornisce i percorsi necessari all’applicazione. Ciascuno viene collocato su un disco del container o in una directory dell’host; prima del riepilogo si possono aggiungere altri percorsi.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Percorsi necessari",
"body": "Vengono elencati <code>/config</code>, <code>/data</code>, librerie, download e tutti i volumi dichiarati dall’applicazione."
},
{
"title": "Posizione",
"body": "Ogni percorso viene collocato su un disco del container o in una directory già esistente sull’host."
},
{
"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>."
},
{
"title": "Directory dell’host",
"body": "La directory dell’host viene indicata tramite il suo percorso. Se non esiste, viene creata e assegnata all’utente dell’host a cui viene mappato quello del container."
},
{
"title": "Percorsi aggiuntivi",
"body": "Prima dell’installazione si possono aggiungere altre coppie formate da un percorso o volume dell’host e dal relativo percorso nel container."
},
{
"title": "Riepilogo",
"body": "La mappatura completa viene mostrata prima della creazione del CT e salvata nel contratto dell’istanza."
}
]
}
}
]
},
{
"id": "options",
"title": "Le due posizioni persistenti",
"blocks": [
{
"table": {
"headers": [
"Proprietà",
"Disco del container",
"Directory dell’host"
],
"rows": [
[
"Nella configurazione",
"<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>",
"<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"
],
[
"Backup del container (vzdump)",
"Incluso con <code>backup=1</code>",
"Non incluso"
],
[
"Dimensione",
"Fissa; si aumenta ridimensionando il punto di mount",
"Lo spazio libero del filesystem o del dataset dell’host"
],
[
"Altri container",
"Montato solo dal container a cui appartiene",
"La stessa directory può essere montata in più container"
],
[
"Snapshot e ripristino",
"Gestiti da Proxmox VE insieme al CT",
"Gestiti sullo storage dell’host"
],
[
"Rimozione dell’applicazione",
"Eliminato con il container",
"Conservato con il suo contenuto"
],
[
"Spostamento del CT su un altro nodo",
"Si sposta con il CT",
"Lo stesso percorso deve esistere sull’altro nodo"
]
]
}
},
{
"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."
}
]
},
{
"id": "example",
"title": "Esempio: un container con entrambe le posizioni",
"blocks": [
{
"code": {
"title": "Jellyfin installato come CT 151 su local-lvm (estratto)",
"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": "Un aggiornamento o una ricreazione sostituisce solo il rootfs: <code>mp0</code> conserva utenti, librerie e impostazioni, mentre <code>mp1</code> continua a mostrare gli stessi contenuti multimediali. Il ripristino del backup del CT recupera <code>/config</code>; se necessario, la directory dei contenuti multimediali viene ripristinata dal backup dello storage dell’host."
},
{
"flow": {
"nodes": [
{
"label": "Contratto",
"detail": "/config"
},
{
"label": "Posizione",
"detail": "Disco del container\no directory dell’host"
},
{
"label": "LXC",
"detail": "Sempre /config\nper l’applicazione"
}
],
"caption": "L’applicazione vede il percorso dichiarato dall’immagine; cambia solo dove viene memorizzato."
}
}
]
},
{
"id": "shared",
"title": "Una directory dell’host, più container",
"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": "Directory dell’host",
"config": "Configurazione propria"
}
}
},
{
"p": "Ogni container conserva la propria configurazione sul suo disco. La libreria o i download si trovano in un’unica directory dell’host, montata nello stesso percorso interno in tutti i container. Così il percorso in cui scrive un’applicazione è lo stesso da cui legge un’altra."
}
]
},
{
"id": "rclone",
"title": "Storage cloud tramite l’applicazione rclone",
"intro": "Oltre all’installazione, la scheda di rclone nel catalogo offre <strong>Abilita un mount in un container OCI rclone esistente</strong>. Viene montato un remote già creato e autorizzato nell’interfaccia web di rclone, che viene poi reso disponibile sull’host. Gli altri container possono usarlo come una directory dell’host.",
"blocks": [
{
"steps": {
"items": [
{
"title": "Container e remote",
"body": "Il VMID del container rclone, il nome esatto del remote e, facoltativamente, un percorso al suo interno."
},
{
"title": "Nome del mount e cache",
"body": "Il nome del mount e la modalità della cache VFS: <code>off</code>, <code>minimal</code>, <code>writes</code> o <code>full</code> (predefinita)."
},
{
"title": "Viste pubblicate",
"body": "Una radice comune, <code>/mnt/oci-shared</code> per impostazione predefinita, contiene una vista in lettura e scrittura in <code>/mnt/oci-shared/remotes/NAME</code> e una in sola lettura in <code>/mnt/oci-shared/remotes-ro/NAME</code>."
},
{
"title": "Attivazione",
"body": "Dopo la conferma, il CT viene arrestato, vengono configurati il suo comando di avvio e un hookscript di Proxmox VE, quindi viene riavviato. L’operazione attende che entrambe le viste siano montate sull’host."
}
]
}
},
{
"calloutInfo": {
"title": "Se il mount non viene attivato",
"body": "Viene ripristinata la configurazione precedente del container, che viene quindi riavviato. In questo modo, se l’attivazione fallisce, rclone resta com’era."
}
}
]
},
{
"id": "network",
"title": "Indirizzi e reti",
"intro": "Un’applicazione con un solo container ha bisogno di un indirizzo. Un’applicazione con più container richiede anche una rete stabile tra i suoi componenti.",
"blocks": [
{
"cards": {
"items": [
{
"icon": "network",
"title": "Applicazione con un solo container",
"body": "Si sceglie il bridge di rete e si imposta DHCP oppure un indirizzo fisso in formato CIDR. L’LXC ha un proprio indirizzo e il riepilogo mostra gli URL completi dei servizi."
},
{
"icon": "waypoints",
"title": "Applicazione con più container",
"body": "Viene individuata una sottorete libera e creato un bridge privato persistente. Ogni componente — applicazione, database e cache — riceve un indirizzo fisso su quella rete."
}
]
}
},
{
"flow": {
"nodes": [
{
"label": "LAN",
"detail": "Indirizzo raggiungibile\nsolo per il servizio principale"
},
{
"label": "LXC principale",
"detail": "Web / API\nLAN + rete privata"
},
{
"label": "Rete privata",
"detail": "PostgreSQL · Valkey · ML\nindirizzi fissi"
}
],
"caption": "Le dipendenze comunicano sulla rete privata e non hanno un indirizzo sulla LAN."
}
},
{
"p": "Il contratto dello stack conserva bridge, sottorete, indirizzi e relazioni tra i servizi. L’aggiornamento dell’applicazione riutilizza la stessa topologia per tutti i componenti. ProxMenux Monitor apre il container principale al suo indirizzo LAN, non a quello della rete privata."
}
]
},
{
"id": "ownership",
"title": "Proprietà di file e directory",
"blocks": [
{
"list": {
"items": [
"Le nuove directory vengono create con UID e GID a cui viene mappato l’LXC non privilegiato.",
"Il proprietario delle directory esistenti non viene modificato ricorsivamente.",
"Socket, file di sistema e percorsi sensibili non vengono proposti come directory generiche dell’host."
]
}
}
]
},
{
"id": "backup",
"title": "Cosa contiene un backup del container",
"blocks": [
{
"table": {
"headers": [
"Elemento",
"Nel backup vzdump del CT",
"Dove viene conservato"
],
"rows": [
[
"Rootfs OCI",
"Sì",
"Nel backup del CT; può anche essere ricreato dall’immagine e dal contratto"
],
[
"Disco del container con <code>backup=1</code>",
"Sì",
"Il backup del CT"
],
[
"Directory dell’host",
"No",
"Il backup dello storage dell’host"
],
[
"Contratto dell’istanza",
"Sì, la copia conservata nel CT",
"<code>/.proxmenux/oci-record.json</code> nel CT; le copie aggiuntive dell’host e del cluster sono conservate separatamente"
],
[
"Applicazione con più container",
"Ogni componente nel proprio backup",
"I backup di tutti i componenti, più il contratto dello stack e il suo bridge di rete sull’host"
]
]
}
}
]
}
]
}
+152
View File
@@ -0,0 +1,152 @@
{
"meta": {
"title": "Fail2Ban | Documentazione ProxMenux",
"description": "Installa Fail2Ban con tre jails ottimizzati per Proxmox (SSH aggressivo, Proxmox UI 8006, ProxMenux Monitor 8008). Include la correzione journald MaxLevelStore, servizi di registro personalizzati per l'affidabilità, backend nftables/iptables rilevati automaticamente e SSH MaxAuthTries rafforzamento.",
"ogTitle": "Fail2Ban | Documentazione ProxMenux",
"ogDescription": "Protezione contro la forza bruta per SSH e le interfacce web Proxmox, con correzioni di journald e del backend specifiche per Proxmox."
},
"header": {
"title": "Fail2Ban",
"description": "Installa Fail2Ban per Proxmox: tre jail (SSH aggressivo, interfaccia Proxmox su 8006, ProxMenux Monitor su 8008 e proxy inverso), correzione del livello journald per salvare gli eventi SSH, due servizi che copiano il journal in file per aggirare un problema del backend systemd, rilevamento del backend firewall e rafforzamento SSH con MaxAuthTries.",
"section": "Sicurezza"
},
"intro": {
"title": "Cosa fa",
"body": "Installa Fail2Ban dai repository Debian e scrive una configurazione Proxmox che protegge subito SSH, interfaccia web Proxmox e ProxMenux Monitor. Se rileva una installazione esistente, offre invece un menu per reinstallare o rimuovere."
},
"firstLaunch": {
"heading": "dialogo di primo lancio",
"body": "Se Fail2Ban non è installato, lo script mostra una conferma con ciò che installerà e configurerà. Annulla termina senza modifiche; confermare avvia l'installazione.",
"imageAlt": "Conferma di installazione di Fail2Ban con tre jail, correzione di journald e rafforzamento SSH"
},
"jails": {
"heading": "Le tre jail",
"headerJail": "Jail",
"headerProtects": "Protegge",
"headerRetries": "Tentativi / Finestra",
"headerBan": "Durata del blocco",
"rows": [
{
"jail": "[sshd]",
"protects": "SSH (modalità aggressive — include ddos, mode, normal)",
"retries": "2 / 60 min",
"ban": "9 ore"
},
{
"jail": "[proxmox]",
"protects": "Proxmox web UI (porta 8006)",
"retries": "3 / 10 min",
"ban": "1 ora"
},
{
"jail": "[proxmenux]",
"protects": "ProxMenux Monitor (porta 8008 + proxy inverso http/https)",
"retries": "3 / 10 min",
"ban": "1 ora"
}
],
"outro": "Impostazioni predefinite globali da <code>jail.local</code>: <code>ignoreip = 127.0.0.1/8 ::1</code>, <code>ignoreself = true</code>,<code> bantime = 86400</code> (fallback di 24 ore per jails che non lo sovrascrivono), <code>maxretry = 2</code>, <code>findtime = 1800</code>."
},
"journald": {
"heading": "Perché la correzione journald è importante",
"intro": "Proxmox fornisce <code>/etc/systemd/journald.conf</code> con <codeNw>MaxLevelStore=warning</codeNw>. journald scarta i messaggi di livello <em>inferiore</em> a warning prima di salvarli. SSH e PAM segnalano gli errori di autenticazione ai livelli <em>info</em> / <em>notice</em>, quindi:",
"diagram": {
"sshLabel": "SSH / PAM",
"sshDetail": "errore di autenticazione\n(livello info / notice)",
"journaldLabel": "journald",
"journaldDetail": "MaxLevelStore=warning\n→ evento scartato senza avviso",
"fail2banLabel": "Fail2Ban",
"fail2banDetail": "non vede niente\n→ non vieta mai nulla",
"arrowLabel": "Proxmox predefinito"
},
"afterDiagram": "L'installatore rileva questo e scrive un drop-in a <codeXs>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</codeXs> aumentando sia <code>MaxLevelStore</code> che <code>MaxLevelSyslog</code> a <code>info</code>:",
"code": "[Journal]\nMaxLevelStore=info\nMaxLevelSyslog=info",
"outro": "Poi riavvia <code>systemd-journald</code>. Il drop-in viene rimosso su disinstallazione, ripristinando il default Proxmox originale."
},
"loggers": {
"heading": "Perché due servizi logger personalizzati",
"intro1": "Fail2Ban può leggere direttamente il journal systemd (<code>backend = systemd</code>), ma su Proxmox questo backend ha problemi noti con i processi worker di <code>pvedaemon</code>: gli eventi di autenticazione compaiono nel journal ma non sempre vengono rilevati. Il problema riguarda occasionalmente anche <code>sshd</code>.",
"intro2": "ProxMenux crea due piccoli servizi systemd che seguono le unità interessate con <code>journalctl -f</code> e aggiungono ogni riga a un file. Fail2Ban legge questi file con il backend affidabile <code>backend = auto</code> (modalità file):",
"headerService": "Servizio",
"headerSource": "Unità di origine",
"headerOutput": "File di uscita",
"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": "Entrambi i servizi sono dichiarati <code>PartOf=fail2ban.service</code> in modo da riavviare con Fail2Ban e fermarsi con esso. Modalità 640 di proprietà di <code>root:adm</code> sui file di registro. Il terzo registro utilizzato dalla prigione <code>[proxmenux]</code> (<code>/var/log/proxmenux-auth.log</code>) è scritto direttamente dall'app ProxMenux Monitor Flask — nessun servizio logger necessario per questo."
},
"backend": {
"heading": "Auto-detezione backend Firewall",
"intro": "L'installatore sonda l'host: se <code>nft list ruleset</code> funziona, sceglie <code>nftables</code> come l'azione di divieto. In caso contrario torna a <code>iptables-multiport</code> / <code>iptables-allports</code>. La scelta è scritta in <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": "Rafforzamento SSH: MaxAuthTries",
"intro": "Il controllo Lynis <strong>SSH-7408</strong> raccomanda <code>MaxAuthTries 3</code> in <code>sshd_config</code>. La jail SSH usa <code>maxretry = 2</code> per bloccare dopo errori ripetuti; MaxAuthTries limita i tentativi nella stessa connessione. Questa impostazione aggiunge protezione anche quando Fail2Ban è fermo per manutenzione.",
"installerIntro": "L'installatore:",
"items": [
"Legge il valore attuale di <code>MaxAuthTries</code> (o di default a 6 se assente).",
"Lo salva a <code>/usr/local/share/proxmenux/sshd_maxauthtries_backup</code>.",
"Modifica <code>sshd_config</code> direttamente: sostituisce la riga esistente, rimuove il commento dalla riga commentata o ne aggiunge una nuova.",
"Ricarica <code>sshd</code> senza riavviarlo, mantenendo attive le sessioni esistenti."
],
"outro": "Su disinstallazione, il valore originale salvato viene ripristinato e <code>sshd</code> viene ricaricato di nuovo."
},
"manage": {
"heading": "Gestire un'installazione esistente",
"intro": "Se Fail2Ban è già installato, lo script lo rileva e mostra un menu di gestione invece di ripetere l'installazione.",
"headerAction": "Azione",
"headerWhat": "Che cosa fa",
"rows": [
{
"action": "Reinstallare",
"what": "Esegue nuovamente l'installazione completa e riscrive tutte le jail con i valori attuali di ProxMenux. Usalo quando un aggiornamento modifica le raccomandazioni."
},
{
"action": "Rimuovi",
"what": "Arresta fail2ban e i due servizi di logger, elimina il pacchetto apt, rimuove tutti i jail / file filtro, elimina il drop-in journald (ripristinando le impostazioni predefinite di Proxmox) e ripristina il SSH originale MaxAuthTries."
}
]
},
"verify": {
"heading": "Verifica che funzioni.",
"intro": "Dopo l'installazione, comandi utili dall'host:",
"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": "Risoluzione dei problemi",
"neverBansTitle": "Fail2Ban corre ma non vieta mai nulla",
"neverBansBody": "Verifica che <code>tail -f /var/log/ssh-auth.log</code> riceva una voce dopo un tentativo SSH con password errata da un'altra macchina. Se rimane vuoto, controlla <code>systemctl status ssh-auth-logger.service</code>. Se il logger è attivo, consulta gli eventi recenti con <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> e verifica che il drop-in journald consenta il livello <em>info</em>.",
"monitorEmptyTitle": "ProxMenux Monitor jail non ha voci anche dopo accessi non riusciti",
"monitorEmptyBody": "Il <code>[proxmenux]</code> jail legge <code>/var/log/proxmenux-auth.log</code>, che è scritto dall'app ProxMenux Monitor Flask - non da un logger journald. Se non esegui il Monitor, il file rimane vuoto e il jail non si attiva mai. Questo è previsto; la configurazione jail è innocua. Se esegui il Monitor e il registro è vuoto, controlla la configurazione di registrazione Flask.",
"selfBanTitle": "Ho bloccato il mio stesso accesso",
"selfBanIntro": "Da una console / IPMI / iKVM (o da un altro IP whitelist):",
"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": "apt-get non riesce: ''Unable to locate package fail2ban''",
"aptFailBody": "L'host manca il repos Debian (comune sulle installazioni di Barebones Proxmox). L'installatore rileva questo e scrive <code>/etc/apt/sources.list.d/debian.sources</code> con il nome giusto in codice (<code>bookworm</code> / <code>trixie</code>) prima di riprovare. Se non riesce ancora, controllare <code>/etc/os-release</code> per <code>VERSION_CODENAME</code> e confermare che l'URL repo è raggiungibile.",
"lockoutTitle": "SSH mi blocca dopo l'installazione",
"lockoutBody": "L'installatore imposta <code>MaxAuthTries=3</code>. Se il tuo password manager / agente richiama più chiavi, puoi superarlo su un singolo tentativo di connessione. Limitare le chiavi offerte: <code>ssh -o IdentitiesOnly=yes -i ~/.ssh/specific_key user@host</code>. O sollevare temporaneamente <code>MaxAuthTries</code> in <code>sshd_config</code> mentre si debug."
},
"files": {
"heading": "File scritti",
"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": "Correlati",
"monitorLabel": "ProxMenux Monitor → Scheda di sicurezza",
"monitorTail": " — installazione dal pannello, stato delle jail in tempo reale, IP bloccati e regolazione di tentativi e durata del blocco per ogni jail dal browser.",
"lynisLabel": "Lynis",
"lynisTail": " — esegui un audit prima e dopo per verificare che il controllo SSH-7408 sia soddisfatto.",
"securityLabel": "Panoramica della sicurezza",
"securityTail": "— di nuovo alla panoramica della sezione."
}
}
+70
View File
@@ -0,0 +1,70 @@
{
"meta": {
"title": "Sicurezza Proxmox — Fail2Ban e audit di rafforzamento Lynis | ProxMenux",
"description": "Due strumenti di sicurezza installabili per Proxmox VE: Fail2Ban (prevenzione delle intrusioni per SSH, interfaccia web Proxmox e ProxMenux Monitor) e Lynis (analisi della sicurezza e del rafforzamento del sistema, installato dal repository ufficiale GitHub).",
"ogTitle": "Sicurezza Proxmox — Fail2Ban e audit di rafforzamento Lynis",
"ogDescription": "Fail2Ban e Lynis per Proxmox VE: prevenzione delle intrusioni e audit di rafforzamento, installati e gestiti da ProxMenux.",
"twitterTitle": "Sicurezza Proxmox | ProxMenux",
"twitterDescription": "Fail2Ban e Lynis per Proxmox VE: prevenzione delle intrusioni e audit di rafforzamento."
},
"header": {
"title": "Sicurezza",
"description": "Due strumenti complementari per Proxmox VE: difesa attiva (Fail2Ban blocca gli IP che attaccano SSH o le interfacce web) e audit locale (Lynis cerca lacune nel rafforzamento e assegna un punteggio da 0 a 100). Ognuno ha un menu di installazione e gestione che rileva installazioni esistenti prima di ogni azione.",
"section": "Sicurezza"
},
"intro": {
"title": "Difesa attiva e audit locale",
"body": "Rispondono a domande diverse. <strong>Fail2Ban</strong> risponde a <em>«Ci stanno attaccando ora?»</em> monitorando i log di autenticazione e bloccando gli IP responsabili. <strong>Lynis</strong> risponde a <em>«Quanto è rafforzata la sicurezza di questo host?»</em> con un audit singolo e raccomandazioni concrete. Usali insieme: Lynis indica cosa migliorare e Fail2Ban reagisce agli attacchi in corso."
},
"opening": {
"heading": "Apertura del menu",
"body": "Dal menu principale di ProxMenux seleziona <strong>Sicurezza</strong>. Vedrai questo:",
"imageAlt": "Menu di sicurezza con opzioni Fail2Ban e Lynis"
},
"pick": {
"heading": "Scegli il tuo strumento",
"body": "I due strumenti di sicurezza sono indipendenti — installare uno, entrambi, o nessuno. Ogni scheda qui sotto salta alla sezione che spiega lo strumento in dettaglio."
},
"cards": {
"fail2ban": {
"title": "Fail2Ban",
"body": "Prevenzione attiva delle intrusioni. Controlla i log di autenticazione SSH e web e blocca gli IP dopo errori ripetuti.",
"bullets": [
"Tre jails: SSH, Proxmox UI (8006), ProxMenux Monitor (8008)",
"Corregge le impostazioni predefinite di Proxmox journald che bloccano i registri di autenticazione",
"Rilevamento automatico nftables / iptables",
"Indurimento SSH: MaxAuthTries=3 (Consiglio di Lynis)"
]
},
"lynis": {
"title": "Lynis",
"body": "Auditor locale di sicurezza. Analizza l'host e mostra un punteggio di rafforzamento e suggerimenti concreti per correggere i problemi.",
"bullets": [
"Installato dal repository ufficiale CISOfy su GitHub (versione più recente)",
"Punteggio di rafforzamento 0–100 ed elenco di avvisi e suggerimenti",
"Audit e aggiornamento dal menu",
"Progettato in sola lettura: non modifica mai il sistema"
]
}
},
"workflowTip": {
"title": "Flusso di lavoro che utilizza entrambi",
"body": "Esegui prima Lynis per vedere il punteggio iniziale e le raccomandazioni principali. Applica le correzioni desiderate. Poi installa Fail2Ban: implementa automaticamente la protezione SSH contro la forza bruta e regola <code>MaxAuthTries</code> in <code>sshd_config</code> per soddisfare il controllo SSH-7408. Esegui di nuovo Lynis per verificare il miglioramento."
},
"fail2banSection": {
"heading": "Fail2Ban",
"body": "ProxMenux installa Fail2Ban con una configurazione specifica per Proxmox. Oltre alla jail SSH standard protegge l'interfaccia web Proxmox e ProxMenux Monitor. Aggira due problemi specifici: un'impostazione journald che scarta gli eventi di autenticazione e un problema del backend systemd che impedisce la lettura affidabile di alcune fonti del registro. La pagina dettagliata spiega installazione, tre jail, correzione di journald, rafforzamento SSH e risoluzione dei problemi.",
"optionTitle": "Fail2Ban — installazione e gestione",
"optionDescription": "Tre jail preconfigurate (sshd aggressivo, interfaccia Proxmox su 8006, ProxMenux Monitor su 8008 e proxy inverso), rilevamento di nftables/iptables, correzione di journald e rafforzamento SSH con MaxAuthTries."
},
"lynisSection": {
"heading": "Lynis",
"body": "ProxMenux clona Lynis da <code>github.com/CISOfy/lynis</code> in <code>/opt/lynis</code> e lo rende disponibile come <code>/usr/local/bin/lynis</code>. Evita il pacchetto Debian perché è indietro di diverse versioni principali rispetto al progetto originale. La pagina dettagliata spiega installazione, audit, aggiornamento, disinstallazione, lettura del rapporto e azioni sui risultati.",
"optionTitle": "Lynis — installazione, audit e gestione",
"optionDescription": "Installa l'ultimo Lynis dal repo ufficiale CISOfy GitHub (non il vecchio pacchetto Debian), esegue controlli di sistema con punteggio di indurimento e aggiornamenti tramite git pull."
},
"componentStatus": {
"heading": "Stato del componente",
"body": "Entrambi gli installatori registrano il loro stato in <code>/usr/local/share/proxmenux/components_status.json</code> sotto la categoria <code>security</code>. ProxMenux utilizza questo file per decidere se mostrare l'installazione o il menu di gestione delle operazioni successive, e gli stessi dati alimentano le dashboard nel ProxMenux Monitor quando presente."
}
}
+170
View File
@@ -0,0 +1,170 @@
{
"meta": {
"title": "Lynis | Documentazione ProxMenux",
"description": "Installa la versione più recente di Lynis dal repository ufficiale CISOfy su GitHub, esegui un audit con punteggio di rafforzamento 0–100 e aggiorna tramite git pull. Auditor in sola lettura: non modifica il sistema.",
"ogTitle": "Lynis | Documentazione ProxMenux",
"ogDescription": "Installa ed esegui Lynis su Proxmox VE. Installazione dal repository originale GitHub, audit e aggiornamento."
},
"header": {
"title": "Lynis",
"description": "Clona la versione più recente di Lynis dal repository ufficiale CISOfy su GitHub, la rende disponibile come /usr/local/bin/lynis e offre audit, aggiornamento, reinstallazione e disinstallazione dal menu. L'analisi è in sola lettura: produce rapporti senza modificare il sistema.",
"section": "Sicurezza"
},
"intro": {
"title": "Cosa fa",
"body": "Installa Lynis, auditor di sicurezza open source di CISOfy, dal repository GitHub in <code>/opt/lynis</code> e crea un lanciatore in <code>/usr/local/bin/lynis</code> per renderlo disponibile nel <code>PATH</code>. Se rileva una installazione esistente, mostra un menu per audit, aggiornamento, reinstallazione o rimozione."
},
"manageMenu": {
"heading": "Menu di gestione (dopo l'installazione)",
"intro": "Una volta che Lynis è installato, ogni successiva invocazione apre il menu di gestione invece di rifare l'installatore. Da qui si avvia un audit, si aggiorna tramite git pull, reinstalla o disinstalla:",
"imageAlt": "Menù di gestione Lynis con controllo, aggiornamento, reinstallare e rimuovere le opzioni"
},
"whyUpstream": {
"heading": "Perché il repository ufficiale GitHub invece di apt",
"intro": "Debian distribuisce Lynis tramite apt, ma il pacchetto è spesso indietro di diverse versioni principali. Nuovi controlli, correzioni per nuovi vettori di attacco e raccomandazioni migliorate arrivano prima su GitHub. Lynis è uno script shell autonomo, senza compilazione e senza dipendenze di installazione oltre a <code>git</code>; clonare il repository è quindi il metodo raccomandato da CISOfy.",
"headerSource": "Fonte",
"headerPath": "Install path",
"headerUpdate": "Metodo di aggiornamento",
"headerFresh": "Aggiornamento della versione",
"rows": [
{
"sourceRich": "<strong>ProxMenux (questo script)</strong>",
"path": "/opt/lynis/",
"update": "git pull (dal menu)",
"fresh": "Ultima versione del progetto originale"
},
{
"sourceRich": "<strong>Debian apt</strong>",
"path": "/usr/bin/lynis",
"update": "apt upgrade",
"fresh": "Spesso mesi / anni dietro"
}
]
},
"install": {
"heading": "Come funziona l'installazione",
"node1Label": "github.com/CISOfy/lynis",
"node1Detail": "git clone\n(installa prima git se manca)",
"node2Label": "/opt/lynis/",
"node2Detail": "repository completo\nincluso lo script ./lynis",
"node3Label": "/usr/local/bin/lynis",
"node3Detail": "wrapper:\ncd /opt/lynis && ./lynis $@",
"outro": "Il wrapper è obbligatorio — Lynis insiste per essere eseguito dalla propria directory perché carica percorsi relativi per plugin e dati del profilo. L'involucro nasconde quel dettaglio così <code>lynis audit system</code> funziona da qualsiasi luogo."
},
"detection": {
"heading": "Sentieri di rilevamento",
"intro": "Prima di mostrare il menu, lo script controlla tre posizioni per decidere se Lynis è già presente:",
"items": [
"<code>/usr/local/bin/lynis</code> — wrapper installato da ProxMenux",
"<code>/opt/lynis/lynis</code> — percorso diretto (nel caso in cui l'involucro sia stato rimosso)",
"<code>/usr/bin/lynis</code> — versione apt-installata, se l'utente l'ha installato in quel modo prima"
],
"outro": "Se trova uno di questi percorsi apre il menu di gestione. Lo script <strong>non</strong> disinstalla Lynis installato con apt; rimuove solo quello gestito in <code>/opt/lynis</code> e il relativo lanciatore."
},
"audit": {
"heading": "Eseguire un audit",
"intro": "Dal menu di gestione scegli <strong>Esegui audit di sicurezza ora</strong>. Equivale a eseguire:",
"code": "lynis audit system --no-colors",
"outro": "L'audit richiede da 30 secondi ad alcuni minuti secondo le dimensioni dell'host. Lo output viene mostrato direttamente nel terminale, senza animazione di attesa. Lynis organizza i controlli per categoria e marca ogni test come <ok>[ OK ]</ok>, <warn>[ WARNING ]</warn> o <sugg>[ SUGGESTION ]</sugg>. Il riepilogo finale mostra i dati principali:",
"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": "Leggere il rapporto",
"intro": "Le due sezioni importanti sono <strong>Warnings</strong> (le cose che si devono risolvere presto) e <strong>Suggestions</strong> (raccomandazioni per migliorare l'indurimento). Ogni elemento porta un ID di controllo come <code>SSH-7408</code> — utile quando si cerca i documenti Lynis per la razionalità e la correzione.",
"headerMarker": "Marcatore",
"headerMeaning": "Significato",
"headerAction": "Azione",
"rows": [
{
"markerRich": "<strong>OK</strong>",
"meaning": "Test superato",
"action": "Niente."
},
{
"markerRich": "<strong>WARNING</strong>",
"meaning": "Problema reale, fix consigliato",
"action": "Leggi la descrizione del controllo, pianifica una correzione"
},
{
"markerRich": "<strong>SUGGESTION</strong>",
"meaning": "Miglioramento dell'indurimento disponibile",
"action": "Applica se adatto al modello di minaccia"
}
],
"outro": "Il rapporto completo e i dati leggibili dalla macchina sono scritti a <code>/var/log/lynis.log</code> e <code>/var/log/lynis-report.dat</code> da Lynis stesso."
},
"pairFail2ban": {
"title": "Combina con Fail2Ban",
"body": "SSH-7408 (MaxAuthTries) è uno degli avvisi più comuni. Installazione di <link>Fail2Ban</link> da ProxMenux lo sgombera automaticamente perché l'installatore imposta <code>MaxAuthTries=3</code> come parte della sua fase di indurimento SSH. Eseguire Lynis di nuovo dopo per confermare che l'avvertimento è andato."
},
"update": {
"heading": "Aggiornamento Lynis",
"body": "Nel menu, <strong>Aggiorna Lynis all'ultima versione</strong> esegue <code>git pull --quiet</code> in <code>/opt/lynis</code>. Se la directory esiste ma non è una copia di lavoro Git, per esempio dopo una copia manuale dei file, lo script esegue una reinstallazione completa."
},
"reinstall": {
"heading": "Reinstallare / disinstallare",
"headerAction": "Azione",
"headerWhat": "Che cosa fa",
"rows": [
{
"actionRich": "<strong>Reinstalla</strong>",
"whatRich": "Rimuove <code>/opt/lynis</code>, clona nuovamente da GitHub e ricrea il lanciatore. Usalo se la copia locale è danneggiata."
},
{
"actionRich": "<strong>Rimuovi</strong>",
"whatRich": "Elimina <code>/opt/lynis</code> e <code>/usr/local/bin/lynis</code>. I registri a <code>/var/log/lynis*</code> sono mantenuti (sono storia dell'audit). Un Lynis apt-installed a <code>/usr/bin/lynis</code> è lasciato intatto."
}
]
},
"cli": {
"heading": "Opzioni utili CLI",
"intro": "Una volta installato, Lynis può essere invocata direttamente da una shell con opzioni extra non esposte dal 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": "Risoluzione dei problemi",
"cloneTitle": "git clone non riesce durante l'installazione",
"cloneBody": "L'host ha bisogno di accesso alla rete e DNS per raggiungere <code>github.com</code>. Da una console: <code>curl -sI https://github.com</code> e <code>git ls-remote https://github.com/CISOfy/lynis.git</code> riveleranno l'errore effettivo (DNS, TLS, proxy, repo URL). Se è richiesto un proxy, impostare <code>https_proxy</code> nell'ambiente prima di ri-inviare il menu.",
"notFoundTitle": "lynis: comando non trovato dopo l'installazione",
"notFoundIntro": "L'involucro a <code>/usr/local/bin/lynis</code> non è stato creato o rimosso. Correzione più rapida: reinstallare dal menu. Correzione manuale:",
"notFoundCode": "cat > /usr/local/bin/lynis <<'EOF'\n#!/bin/bash\ncd /opt/lynis && ./lynis \"$@\"\nEOF\nchmod +x /usr/local/bin/lynis",
"sshTitle": "L'audit mostra \"Warning: Test SSH-7408 — MaxAuthTries set incorrectly\"",
"sshIntro": "Il daemon SSH consente troppi tentativi auth per connessione. Installare <link>Fail2Ban</link> da ProxMenux (che imposta automaticamente <code>MaxAuthTries=3</code>) o modificare <code>/etc/ssh/sshd_config</code> a mano:",
"sshCode": "sed -i 's/^#?MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config\nsystemctl reload sshd",
"scoreTitle": "Score è andato giù dopo un aggiornamento Proxmox",
"scoreBody": "Eseguire <code>lynis update info</code> prima — un aggiornamento Lynis potrebbe aver aggiunto nuovi controlli che contrassegnano la configurazione esistente. Aggiornare Lynis dal menu, ri-audit e affrontare i nuovi risultati."
},
"files": {
"heading": "File scritti",
"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": "Rapporto di esempio",
"intro": "ProxMenux Monitor genera per ogni esecuzione di Lynis un PDF multipagina dalla <link>scheda Sicurezza</link>. La prima pagina riepiloga punteggio di rafforzamento, informazioni di sistema e stato della sicurezza. Le successive spiegano ogni avviso, elencano i suggerimenti per impatto e includono l'inventario dei pacchetti usato nell'audit.",
"imageAlt": "Prima pagina del Lynis Security Audit Report PDF — Riepilogo esecutivo con Hardening Index 71/100, blocco informazioni di sistema e panoramica della postura di sicurezza con firewall, malware scanner e pacchetti installati conteggio",
"captionPrefix": "Prima pagina di un rapporto campione. Il PDF completo (",
"captionLink": "campione",
"captionSuffix": ") continua con avvisi dettagliati, suggerimenti e la lista dei pacchetti installati.",
"cli": "Sul lato CLI gli stessi dati sono in <code>/var/log/lynis-report.dat</code> (file piatto leggibile dalla macchina) e <code>/var/log/lynis.log</code> (il registro di esecuzione leggibile dall'uomo). Il PDF viene generato su richiesta da ProxMenux Monitor — l'esecuzione di <code>lynis</code> dalla riga di comando non ne produce uno."
},
"related": {
"heading": "Correlati",
"items": [
{
"href": "/docs/monitor/dashboard/security",
"label": "ProxMenux Monitor → Scheda di sicurezza",
"tail": "— eseguire l'audit, sfogliare i rapporti storici e scaricare il PDF direttamente dal cruscotto."
},
{
"href": "/docs/security/fail2ban",
"label": "Fail2Ban",
"tailRich": " — attua il SSH protezione brute-force che Lynis raccomanda."
},
{
"href": "/docs/security",
"label": "Panoramica della sicurezza",
"tail": "— di nuovo alla panoramica della sezione."
}
]
}
}
@@ -0,0 +1,169 @@
{
"meta": {
"title": "HTTPS per ProxMenux Monitor — certificato dell'host Proxmox o percorsi personalizzati | ProxMenux",
"description": "Fornisce ProxMenux Monitor via HTTPS con il certificato dell'host Proxmox (rilevato automaticamente, incluso quello Let’s Encrypt installato tramite ACME di Proxmox) o con un certificato personalizzato in qualsiasi percorso sul disco.",
"ogTitle": "HTTPS per ProxMenux Monitor — Host Proxmox o certificato personalizzato",
"ogDescription": "Abilitare HTTPS sulla porta 8008 con il certificato host Proxmox o qualsiasi coppia di .pem / .key personalizzata."
},
"header": {
"title": "HTTPS per ProxMenux Monitor",
"description": "Attiva HTTPS per Monitor sulla porta 8008 con il certificato dell'host Proxmox rilevato automaticamente o uno personalizzato sul disco. L'opzione Proxmox preferisce il certificato ACME, se presente, e riutilizza Let’s Encrypt gestito da Proxmox senza un'ulteriore attività di rinnovo.",
"section": "Sicurezza"
},
"intro": {
"title": "Che cosa questa pagina copre",
"body": "Come cambiare il Monitor da HTTP a HTTPS nel pannello Impostazioni → Sicurezza, ciò che ogni fonte di certificato indica effettivamente sul disco, come l'opzione Proxmox si comporta quando l'host ha un cert Let's Encrypt e come impostare percorsi personalizzati se si gestisce certs al di fuori di Proxmox."
},
"wheresetting": {
"heading": "Dove si trova l'impostazione",
"body": "Apri Monitor e vai in <strong>Impostazioni → Sicurezza → HTTPS / SSL</strong>. Il pannello mostra HTTP o HTTPS e, se HTTPS non è attivo, le fonti di certificato rilevate.",
"imageAlt": "Impostazioni → Sicurezza → HTTPS / Pannello SSL nel Monitor che mostra lo stato HTTPS-off, il certificato Proxmox auto-determinato (soggetto, emittente, scadenza) e l'opzione Usa Certificato personalizzato",
"caption": "Pannello Impostazioni → Sicurezza → HTTPS / SSL prima dell'attivazione. Monitor mostra il certificato usato da Proxmox e permette di sceglierlo con un clic."
},
"twoways": {
"heading": "Due modi per abilitare HTTPS",
"proxmox": {
"title": "Usa certificato Proxmox",
"summary": "Un clic: Monitor riutilizza il certificato presentato da Proxmox VE sulla porta 8006.",
"items": [
"Rilevato automaticamente, nessun percorso da digitare",
"Preferisce il certificato ACME se presente, altrimenti quello autofirmato predefinito",
"Proxmox gestisce il rinnovo; Monitor convalida e carica il certificato alla prossima nuova connessione TLS"
]
},
"custom": {
"title": "Usa certificato personalizzato",
"summaryRich": "Puntare il Monitor su una coppia <code>.pem</code> / <code>.key</code> ovunque sul disco.",
"items": [
"Solo percorsi assoluti (il processo Monitor deve essere in grado di leggere entrambi)",
"Utile quando i cert vengono da <code>certbot</code>, <code>acme.sh</code> o una wildcard",
"Gestisci tu il rinnovo: riavvia Monitor quando cambiano i file"
]
}
},
"proxmoxCert": {
"heading": "Certificato di Proxmox — ciò che effettivamente indica",
"intro": "Proxmox VE mantiene due coppie di certificati in <code>/etc/pve/local/</code>:",
"table": {
"headers": {
"file": "File",
"origin": "Origine",
"when": "Quando il Monitor lo usa"
},
"rows": [
{
"fileRich": "<code>pveproxy-ssl.pem</code><br /><code>pveproxy-ssl.key</code>",
"originRich": "Certificato personalizzato caricato tramite l'UI Proxmox — compreso il certificato Let's Encrypt rilasciato sotto <em>Datacenter → Nodo → Certificati → ACME</em>.",
"when": "Preferito se entrambi i file esistono; Monitor usa il certificato presentato da Proxmox."
},
{
"fileRich": "<code>pve-ssl.pem</code><br /><code>pve-ssl.key</code>",
"originRich": "Certificato autofirmato generato al momento di installazione dal Proxmox PKI.",
"whenRich": "Fallback quando non è presente nessun <code>pveproxy-ssl.pem</code>."
}
]
},
"callout": {
"title": "Stessa priorità di Proxmox stesso",
"bodyRich": "<code>pveproxy</code> applica la stessa selezione: scegliendo Proxmox, Monitor usa il certificato presentato dall'interfaccia Proxmox su 8006, senza copie né un processo di rinnovo separato."
}
},
"letsencrypt": {
"heading": "Ottenere un certificato Let's Encrypt tramite Proxmox ACME",
"intro": "Proxmox VE include un client ACME. <em>«Order Certificate Now»</em> salva il risultato in <code>/etc/pve/local/pveproxy-ssl.pem</code>, letto da Monitor. I cinque passi seguenti riassumono la <extlink1>guida ufficiale Proxmox</extlink1> nei comandi necessari.",
"prereqs": {
"title": "Prerequisiti",
"items": [
"Il nodo ha un vero nome DNS (non solo un IP) che indica.",
"<strong>O</strong> porta 80 raggiungibile da Internet (verifica HTTP-01, la più semplice), <strong>oppure</strong> un provider DNS con credenziali API (DNS-01, funziona dietro NAT e supporta wildcard).",
"Un indirizzo email per l'account ACME."
]
},
"step1": {
"heading": "Passo 1 — Registrare l'account ACME",
"introRich": "Sostituisci l'email con il tuo. Il nome dell'account <code>default</code> è solo un'etichetta — è possibile utilizzare qualsiasi stringa.",
"code": "pvenode acme account register default you@example.com",
"afterRich": "Proxmox chiede di accettare i termini di servizio Let's Encrypt. Dopo di che l'account è persistito sotto <code>/etc/pve/priv/acme/</code> e la scheda ACME nella GUI lo mostrerà."
},
"step2": {
"heading": "Passo 2 — Scegli un tipo di sfida",
"http01Rich": "<strong>HTTP-01</strong> è il più semplice: è costruito in, nessun plugin aggiuntivo. Let's Encrypt si collega a <code>http://&lt;your-host&gt;/.well-known/acme-challenge/...</code> sulla porta 80, quindi la porta 80 deve essere aperta da internet pubblico al nodo — tipicamente una porta avanti sul router.",
"dns01Rich": "<strong>DNS-01</strong> funziona senza esporre la porta 80 (buona per le homelab dietro CG-NAT) ed è l'unica opzione per i certificati jolly. Aggiungi un plugin DNS una volta con il token API del tuo fornitore. Esempio Cloudflare:",
"code": "pvenode acme plugin add dns cf \\\n --api cloudflare \\\n --data CF_Token=YOUR_CLOUDFLARE_API_TOKEN",
"outroRich": "Per altri provider (Gandi, OVH, AWS Route 53, ecc.) consulta <code>pvenode acme plugin add dns --help</code>. Proxmox include <extlink2>tutti i plugin DNS di acme.sh</extlink2>."
},
"step3": {
"heading": "Passo 3 — Legare il dominio al nodo",
"http01Rich": "Per HTTP-01 (utilizza il plugin <code>standalone</code> integrato):",
"code1": "pvenode config set --acme domains=host.example.com,account=default",
"dns01": "Per DNS-01 con il plugin Cloudflare di Step 2:",
"code2": "pvenode config set --acmedomain0 domain=host.example.com,plugin=cf\npvenode config set --acme account=default",
"wildcardRich": "Certificato wildcard? Aggiungi <code>domain=*.example.com</code> in una voce separata <code>--acmedomainN</code>. I certificati wildcard richiedono DNS-01."
},
"step4": {
"heading": "Passo 4 — Ordinare il certificato",
"code": "pvenode acme cert order",
"afterRich": "La prima esecuzione richiede tipicamente 30–60 secondi mentre la sfida si propaga. Su successo Proxmox scrive <code>/etc/pve/local/pveproxy-ssl.pem</code> + <code>.key</code>, riavvia <code>pveproxy</code>, e un cron di rinnovo è programmato automaticamente (Let's Encrypt certs sono validi 90 giorni; Proxmox rinnova a 60)."
},
"step5": {
"heading": "Passo 5 — Verificare l'emittente",
"code": "openssl x509 -in /etc/pve/local/pveproxy-ssl.pem -noout -issuer",
"afterRich": "Dovrebbe stampare un emittente a partire da <code>O = Let's Encrypt</code>. Se invece legge <code>CN = Proxmox Virtual Environment</code> l'ordine non è riuscito e il file è ancora l'auto-firmato PVE cert — eseguire <code>pvenode acme cert order --debug 1</code> per vedere perché."
},
"gui": {
"title": "Preferisci la GUI? Stessi cinque passi",
"bodyRich": "<em>Datacenter → ACME</em> registra l'account; <em>Datacenter → ACME → Plugins</em> aggiunge il plugin DNS; <em>Node → Certificates → ACME</em> associa il dominio; <em>Order Certificates Now</em> esegue il passo 4. I comandi precedenti sono utili per script e sistemi senza interfaccia grafica."
}
},
"switchToHttps": {
"heading": "Passare il Monitor a HTTPS",
"bodyRich": "Quando <code>/etc/pve/local/pveproxy-ssl.pem</code> è firmato da Let's Encrypt, apri <strong>Impostazioni → Sicurezza → HTTPS / SSL</strong>, verifica che l'emittente sia <em>Let's Encrypt</em> e non la CA locale Proxmox, poi fai clic su <strong>Usa certificato Proxmox</strong>. Monitor si riavvia e il caricamento successivo usa HTTPS su 8008 con una catena pubblicamente attendibile. I rinnovi ACME successivi sono convalidati e selezionati alla prossima nuova connessione TLS, senza controlli periodici né riavvio al rinnovo. <strong>Aggiorna certificato</strong> rimane disponibile in Sicurezza per diagnosi e recupero."
},
"custom": {
"heading": "Certificato personalizzato — quando utilizzarlo",
"intro": "Fai clic su <strong>Usa certificato personalizzato</strong> e inserisci due percorsi assoluti:",
"items": [
"<strong>Certificato</strong>: catena completa in PEM (<code>.pem</code> o <code>.crt</code>).",
"<strong>Chiave privata</strong>: chiave corrispondente in PEM (<code>.key</code>)."
],
"outro": "Entrambi i file sono letti dal processo Monitor all'avvio. Assicurarsi che rimangano leggibili dall'utente l'unità systemd viene eseguita come (root per impostazione predefinita). Località comuni quando ACME è gestito fuori 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": "Obiettivi Symlink vs. file",
"bodyRich": "<code>certbot</code> memorizza i file reali in <code>/etc/letsencrypt/archive/</code> e il percorso <code>live/</code> è un symlink. Indirizzi il Monitor al simlink <code>live/</code>, non il file <code>archive/</code> — in questo modo ogni ciclo di rinnovo semplicemente riscrive l'obiettivo di symlink e il Monitor raccoglie il nuovo cert all'inizio del servizio successivo."
}
},
"afterHttps": {
"heading": "Dopo aver attivato HTTPS",
"bodyRich": "Salvataggio del cambiamento scrive <code>/etc/proxmenux/ssl_config.json</code> e attiva un riavvio dell'unità <code>proxmenux-monitor</code> systemd. La scheda del browser perderà la sua connessione corrente — ricaricarla su <code>https://&lt;host&gt;:8008/</code>. Il primo carico con un cert Let's Encrypt non dovrebbe mostrare alcun avvertimento; con il Proxmox auto-firmato cert il browser richiederà un'eccezione, la stessa che per la porta 8006.",
"reverse": {
"heading": "Proxy inversi e webhook",
"bodyRich": "Quando il Monitor passa a HTTPS, gli URL Proxmox VE webhook registrati per le notifiche girano automaticamente da <code>http://</code> a <code>https://</code>. Le voci webhook esistenti vengono riscritte la prossima volta che viene salvata o ri-detetta una regola di notifica, quindi non è necessaria alcuna modifica manuale della configurazione di notifica Proxmox."
}
},
"trustCa": {
"heading": "Considerare attendibile la CA autofirmata di Proxmox",
"intro1Rich": "Per mantenere il certificato predefinito Proxmox senza ACME, importa la CA radice del cluster nell'archivio di fiducia del sistema o del browser. Monitor rileva <code>/etc/pve/local/pve-ssl.pem</code> come certificato alternativo. Il client considera attendibile l'emittente; l'URL deve comunque corrispondere a un nome del certificato.",
"intro2Rich": "Il file CA vive a <code>/etc/pve/pve-root-ca.pem</code> su ogni nodo. In un cluster il percorso è sul filesystem <code>pmxcfs</code> condiviso in modo che tutti i nodi condividono la stessa radice, e una singol'importazione copre l'intero datacenter. Copialo sulla tua macchina:",
"code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
"thenImport": "Poi importarlo sul lato cliente:",
"items": [
"<strong>Linux (intero sistema):</strong> esegui <code>sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt</code> e poi <code>sudo update-ca-certificates</code>. I browser che usano l'archivio di sistema (Chromium, Edge) riconoscono la CA dopo il riavvio; Firefox usa un archivio proprio e richiede l'importazione manuale seguente.",
"<strong>macOS:</strong> apri il file <code>.pem</code> con doppio clic in Accesso Portachiavi, aggiungilo al portachiavi <em>Sistema</em> e imposta <em>Attendibilità → Considera sempre attendibile</em>.",
"<strong>Windows:</strong> clic destro sul file → <em>Installa certificato</em> → inseriscilo in <em>Autorità di certificazione radice attendibili</em>.",
"<strong>Firefox (qualsiasi sistema operativo):</strong> <em>Impostazioni → Privacy e sicurezza → Certificati → Mostra certificati → Autorità → Importa</em>; seleziona <em>Considera attendibile questa CA per identificare siti web</em>."
],
"standalone": {
"title": "Nodi standalone fuori da un cluster",
"bodyRich": "Ogni host Proxmox non incluso ha il proprio <code>pve-root-ca.pem</code>. Se gestisci diversi host standalone, ripeti la copia/importazione per ciascuno, o unisciti a un cluster in modo da condividere una singola radice."
}
},
"disable": {
"heading": "Disabilitare HTTPS",
"bodyRich": "Fai clic su <strong>Disabilita HTTPS</strong> nello stesso pannello. Monitor si riavvia con HTTP non cifrato, utile se un certificato personalizzato non è leggibile e il servizio non parte. Non serve una disinstallazione separata e i file di certificato non vengono modificati.",
"stateCallout": {
"title": "Dove viene salvato lo stato",
"bodyRich": "<code>/etc/proxmenux/ssl_config.json</code> memorizza i percorsi di cert attivo e la fonte (<code>none</code>, <code>proxmox</code>, <code>custom</code>). Cancellare il file è equivalente a disabilitare HTTPS — il prossimo inizio il Monitor rientra a HTTP."
}
}
}