mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-01 10:22:08 +00:00
Merge remote-tracking branch 'origin/develop' into HEAD
This commit is contained in:
MacRimi
@@ -0,0 +1,254 @@
|
||||
{
|
||||
"site": {
|
||||
"name": "ProxMenux",
|
||||
"tagline": "Interaktives Menü und Web-Dashboard für Proxmox VE"
|
||||
},
|
||||
"nav": {
|
||||
"home": "Startseite",
|
||||
"docs": "Dokumentation",
|
||||
"documentation": "Dokumentation",
|
||||
"guides": "Anleitungen",
|
||||
"changelog": "Änderungsprotokoll",
|
||||
"github": "GitHub",
|
||||
"rss": "RSS",
|
||||
"rssTitle": "RSS-Feed",
|
||||
"menuOpen": "Menü öffnen"
|
||||
},
|
||||
"footer": {
|
||||
"sponsorHeading": "Projekt unterstützen",
|
||||
"sponsorBody": "Wenn Sie das Projekt unterstützen möchten.",
|
||||
"sponsorAlt": "Auf Ko-fi unterstützen",
|
||||
"connectHeading": "Community",
|
||||
"connectBody": "Beteiligen Sie sich an den Community-Diskussionen auf GitHub, um Hilfe zu erhalten, Ideen auszutauschen und zum Projekt beizutragen. Jede Idee ist willkommen!",
|
||||
"joinDiscussion": "An der Diskussion teilnehmen",
|
||||
"copyrightPrefix": "ProxMenux, ein gemeinschaftliches Open-Source-Projekt von",
|
||||
"copyrightSuffix": "."
|
||||
},
|
||||
"language": {
|
||||
"switcher": "Sprache",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
"title": "Dokumentation",
|
||||
"description": "Systembeschreibung und Benutzeranleitungen"
|
||||
},
|
||||
"changelog": {
|
||||
"title": "Änderungsprotokoll",
|
||||
"description": "Informationen zu den neuesten Aktualisierungen"
|
||||
},
|
||||
"guides": {
|
||||
"title": "Anleitungen",
|
||||
"description": "Schrittweise Anleitungen für häufige Aufgaben"
|
||||
},
|
||||
"github": {
|
||||
"title": "GitHub-Repository",
|
||||
"description": "Sehen Sie sich den Quellcode an."
|
||||
}
|
||||
},
|
||||
"docSidebar": {
|
||||
"documentation": "Dokumentation",
|
||||
"items": {
|
||||
"introduction": "Einführung",
|
||||
"installation": "Installation",
|
||||
"proxmenuxMonitor": "ProxMenux Monitor",
|
||||
"monitorOverview": "Übersicht",
|
||||
"architecture": "Architektur",
|
||||
"accessAuth": "Zugriff und Authentifizierung",
|
||||
"dashboard": "Dashboard",
|
||||
"dashboardSystemOverview": "Registerkarte Systemübersicht",
|
||||
"dashboardApps": "Registerkarte Apps",
|
||||
"dashboardStorage": "Registerkarte Speicher",
|
||||
"dashboardNetwork": "Registerkarte Netzwerk",
|
||||
"dashboardVmsLxcs": "Registerkarte VMs und LXCs",
|
||||
"dashboardVmsLxcsApp": "App",
|
||||
"dashboardVmsLxcsUpdates": "Aktualisierungen",
|
||||
"dashboardHardware": "Registerkarte Hardware",
|
||||
"dashboardSystemLogs": "Registerkarte Systemprotokolle",
|
||||
"dashboardTerminal": "Registerkarte Terminal",
|
||||
"dashboardSecurity": "Registerkarte Sicherheit",
|
||||
"dashboardSettings": "Registerkarte Einstellungen",
|
||||
"healthMonitor": "Zustandsüberwachung",
|
||||
"auditReport": "Prüfung und Berichte",
|
||||
"auditReportOverview": "Übersicht",
|
||||
"auditReportAssessment": "Bewertung und Inventar",
|
||||
"auditReportPolicy": "Richtlinie",
|
||||
"auditReportChanges": "Änderungen",
|
||||
"auditReportReports": "Berichte und Vergleiche",
|
||||
"auditReportScope": "Umfang und Garantien",
|
||||
"notifications": "Benachrichtigungen",
|
||||
"aiAssistant": "KI-Assistent",
|
||||
"apiReference": "API-Referenz",
|
||||
"integrations": "Integrationen",
|
||||
"ociManager": "OCI manager Apps",
|
||||
"ociOverview": "Übersicht",
|
||||
"ociArchitecture": "So wird ein OCI-Image umgesetzt",
|
||||
"ociCustomImage": "Image außerhalb des Katalogs",
|
||||
"ociStorageNetwork": "Daten, Pfade und Netzwerk",
|
||||
"ociHardware": "Geräte und Beschleunigung",
|
||||
"ociStacks": "Anwendungen mit mehreren Containern",
|
||||
"ociLifecycle": "Installieren, aktualisieren und ändern",
|
||||
"ociMonitor": "In ProxMenux Monitor",
|
||||
"proxmenuxScripts": "ProxMenux Scripts",
|
||||
"postInstallScript": "Skript zur Nachinstallation",
|
||||
"postInstallOverview": "Übersicht",
|
||||
"postInstallAutomated": "Automatisch",
|
||||
"postInstallCustomizable": "Anpassbar",
|
||||
"postInstallBasicSettings": "Grundeinstellungen",
|
||||
"postInstallSystem": "System",
|
||||
"postInstallVirtualization": "Virtualisierung",
|
||||
"postInstallNetwork": "Netzwerk",
|
||||
"postInstallStorage": "Speicher",
|
||||
"postInstallSecurity": "Sicherheit",
|
||||
"postInstallCustomization": "Anpassung",
|
||||
"postInstallMonitoring": "Überwachung",
|
||||
"postInstallPerformance": "Leistung",
|
||||
"postInstallOptional": "Optional",
|
||||
"postInstallUpdates": "Verfügbare Aktualisierungen installieren",
|
||||
"postInstallUninstall": "Optimierungen entfernen",
|
||||
"gpusCoralTpu": "GPUs und Coral TPU",
|
||||
"nvidiaHost": "NVIDIA-Treiber auf dem Host installieren",
|
||||
"coralHost": "Coral TPU auf dem Host installieren",
|
||||
"addGpuLxc": "GPU für einen LXC freigeben",
|
||||
"addCoralLxc": "Coral TPU für einen LXC freigeben",
|
||||
"addGpuVm": "GPU einer VM zuweisen (Passthrough)",
|
||||
"switchGpuMode": "GPU-Modus wechseln (VM ↔ LXC)",
|
||||
"createVm": "VM erstellen",
|
||||
"createVmOverview": "Übersicht",
|
||||
"createVmSystemNas": "NAS-Systeme",
|
||||
"createVmSynology": "Synology-VM",
|
||||
"createVmNasOthers": "Weitere NAS-Systeme",
|
||||
"createVmSystemWindows": "Windows-Systeme",
|
||||
"createVmSystemLinux": "Linux-Systeme",
|
||||
"diskManager": "Datenträgerverwaltung",
|
||||
"diskManagerOverview": "Übersicht",
|
||||
"diskImportVm": "Datenträger in eine VM importieren",
|
||||
"diskImportImageVm": "Datenträgerabbild in eine VM importieren",
|
||||
"diskAddController": "Controller oder NVMe-Gerät zu einer VM hinzufügen",
|
||||
"diskImportLxc": "Datenträger in einen LXC importieren",
|
||||
"diskFormat": "Physischen Datenträger formatieren oder löschen",
|
||||
"diskSmart": "SMART-Zustand und Datenträgertests",
|
||||
"storageShareManager": "Speicher und Freigaben verwalten",
|
||||
"storageShareOverview": "Übersicht",
|
||||
"hostStorage": "Speicher in den Host einbinden",
|
||||
"hostNfs": "NFS-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"hostSamba": "Samba-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"hostIscsi": "iSCSI-Ziel als Proxmox-Speicher hinzufügen",
|
||||
"hostLocalDisk": "Lokalen Datenträger als Proxmox-Speicher hinzufügen",
|
||||
"hostLocalShared": "Freigegebenes Verzeichnis auf dem Host anlegen",
|
||||
"lxcMountPoints": "LXC-Mountpoints (Host ↔ CT)",
|
||||
"lxcNetworkSharing": "Netzwerkfreigaben in LXC",
|
||||
"lxcNfsClient": "NFS-Client in LXC",
|
||||
"lxcSambaClient": "Samba-Client in LXC",
|
||||
"lxcNfsServer": "NFS-Server in LXC",
|
||||
"lxcSambaServer": "Samba-Server in LXC",
|
||||
"network": "Netzwerk",
|
||||
"networkOverview": "Übersicht",
|
||||
"networkDiagnostics": "Diagnose",
|
||||
"networkMonitoring": "Werkzeuge zur Echtzeitüberwachung",
|
||||
"networkBridge": "Netzwerk-Bridges prüfen und reparieren",
|
||||
"networkConfig": "Konfiguration prüfen und bereinigen",
|
||||
"networkPersistent": "Dauerhafte Schnittstellennamen",
|
||||
"networkBackup": "Schnittstellen sichern und neu starten",
|
||||
"security": "Sicherheit",
|
||||
"securityOverview": "Übersicht",
|
||||
"securityFail2ban": "Fail2Ban",
|
||||
"securityLynis": "Lynis",
|
||||
"utilities": "Dienstprogramme",
|
||||
"utilsOverview": "Übersicht",
|
||||
"utilsUupDump": "ISO-Erstellung mit UUP Dump",
|
||||
"utilsSystemUtils": "Systemwerkzeuge installieren",
|
||||
"utilsSystemUpdate": "Proxmox-System aktualisieren",
|
||||
"utilsUpgradePve": "Von PVE 8 auf PVE 9 aktualisieren",
|
||||
"utilsExportVm": "VM als OVA/OVF exportieren",
|
||||
"utilsImportVm": "VM aus OVA/OVF importieren",
|
||||
"settingsProxmenux": "ProxMenux-Einstellungen",
|
||||
"settingsOverview": "Übersicht",
|
||||
"settingsMonitor": "ProxMenux Monitor",
|
||||
"settingsBeta": "Release-Kanal wechseln",
|
||||
"settingsVersion": "Versionsinformationen anzeigen",
|
||||
"settingsUninstall": "ProxMenux deinstallieren",
|
||||
"commandsReference": "Befehlsreferenz",
|
||||
"commandsOverview": "Übersicht",
|
||||
"commandsSystem": "Nützliche Systembefehle",
|
||||
"commandsVmCt": "VMs und CTs verwalten",
|
||||
"commandsStorage": "Speicher und Datenträger",
|
||||
"commandsNetwork": "Netzwerkbefehle",
|
||||
"commandsUpdates": "Aktualisierungen und Pakete",
|
||||
"commandsGpu": "GPU-Passthrough",
|
||||
"commandsZfs": "ZFS verwalten",
|
||||
"commandsBackup": "Sichern und Wiederherstellen",
|
||||
"commandsTools": "Systemwerkzeuge für die Befehlszeile",
|
||||
"glossary": "Glossar",
|
||||
"about": "Über das Projekt",
|
||||
"aboutOverview": "Übersicht",
|
||||
"aboutFaq": "FAQ",
|
||||
"aboutContributors": "Mitwirkende",
|
||||
"aboutContributing": "Mitwirken",
|
||||
"aboutCodeOfConduct": "Verhaltenskodex",
|
||||
"externalRepositories": "Externe Repositorys",
|
||||
"backupRestore": "Sichern und Wiederherstellen",
|
||||
"backupRestoreOverview": "Übersicht",
|
||||
"backupRestoreHowItWorks": "Funktionsweise",
|
||||
"backupRestoreDestinations": "Ziele",
|
||||
"backupRestoreDestOverview": "Übersicht",
|
||||
"backupRestoreDestLocal": "Lokales Archiv",
|
||||
"backupRestoreDestPbs": "Proxmox Backup Server",
|
||||
"backupRestoreDestBorg": "Borg",
|
||||
"backupRestoreCreating": "Sicherungen erstellen",
|
||||
"backupRestoreJobs": "Geplante Aufträge",
|
||||
"backupRestoreRestoring": "Wiederherstellen",
|
||||
"backupRestoreCrossKernel": "Wiederherstellung mit anderer Kernel-Version",
|
||||
"backupRestoreGlossary": "Glossar"
|
||||
}
|
||||
},
|
||||
"hero": {
|
||||
"title": "ProxMenux",
|
||||
"tagline": "Ein interaktives Menü und Web-Dashboard für Proxmox VE",
|
||||
"description": "ProxMenux verbindet ein interaktives Menü mit einem Web-Dashboard für Proxmox VE. Führen Sie Befehle, Skripte und geführte Assistenten über das Terminalmenü aus oder verfolgen Sie Host-Zustand, Messwerte und Benachrichtigungen im Browser.",
|
||||
"installButton": "Jetzt installieren",
|
||||
"whatIsButton": "Was ist ProxMenux?",
|
||||
"logoAlt": "ProxMenux-Logo"
|
||||
},
|
||||
"docNav": {
|
||||
"previous": "Zurück",
|
||||
"next": "Weiter"
|
||||
},
|
||||
"tocPanel": {
|
||||
"onThisPage": "Auf dieser Seite"
|
||||
},
|
||||
"supportProject": {
|
||||
"heading": "Unterstützen Sie das Projekt!",
|
||||
"body": "Wenn Sie <strong>ProxMenux</strong> hilfreich finden, geben Sie dem Projekt eine ⭐ auf GitHub, damit auch andere darauf aufmerksam werden.",
|
||||
"button": "Stern auf GitHub vergeben"
|
||||
},
|
||||
"rssLink": {
|
||||
"heading": "Bleiben Sie auf dem Laufenden!",
|
||||
"body": "Abonnieren Sie unseren RSS-Feed, um über neue Änderungen informiert zu werden.",
|
||||
"copy": "Kopieren",
|
||||
"copied": "Kopiert!",
|
||||
"copyTitle": "RSS-URL kopieren",
|
||||
"openFeed": "RSS-Feed öffnen",
|
||||
"openTitle": "RSS-Feed öffnen"
|
||||
},
|
||||
"changelog": {
|
||||
"pageTitle": "Änderungsprotokoll",
|
||||
"meta": {
|
||||
"title": "ProxMenux-Änderungsprotokoll",
|
||||
"titleSuffix": "Versionshinweise",
|
||||
"latest": "Aktuell",
|
||||
"mostRecent": "Neueste Version",
|
||||
"description": "Versionshinweise und Aktualisierungsverlauf für ProxMenux, das menügesteuerte Skript zur Verwaltung von Proxmox VE.",
|
||||
"descriptionTail": "Neue Funktionen, Fehlerbehebungen, Sicherheitsupdates, Verbesserungen an ProxMenux Monitor, Kompatibilität mit KI-Anbietern, zusätzliche Absicherung beim GPU-Passthrough und mehr.",
|
||||
"ogDescription": "Versionshinweise für ProxMenux.",
|
||||
"ogTail": "Abonnieren Sie den RSS-Feed oder besuchen Sie diese Seite erneut, um neue Versionen zu finden."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Verhaltenskodex | ProxMenux-Dokumentation",
|
||||
"description": "ProxMenux Verhaltenskodex und Best Practices für Mitwirkende, Tester und Nutzer.",
|
||||
"ogTitle": "Verhaltenskodex | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Erwartungen an die Verantwortung für eingereichten Code, die Meldung von Sicherheitslücken und den Umfang von Pull Requests im ProxMenux-Projekt."
|
||||
},
|
||||
"errors": {
|
||||
"notFound": "Fehler: Die Datei CODE_OF_CONDUCT.md wurde nicht gefunden.",
|
||||
"loadFailed": "Fehler: Der Inhalt des Verhaltenskodex kann nicht geladen werden."
|
||||
},
|
||||
"contentMarkdown": "# 📝 Verhaltenskodex und bewährte Vorgehensweisen\n\nDieses Dokument legt die **Grundsätze und Richtlinien** für die Nutzung von **ProxMenux** fest. Es soll **Respekt, Zusammenarbeit und Sicherheit** bei der Entwicklung fördern.\n\n## 📌 1. Urheberangaben und Anerkennung\n\n- Werden **Skripte, Codeausschnitte oder Ideen** anderer Repositorys oder Entwickler verwendet, wird der ursprüngliche Urheber immer genannt.\n- Ein Kommentar im Code oder in der Dokumentation nennt die Quelle und verlinkt möglichst auf das ursprüngliche Repository.\n- Bei Code mit einer bestimmten **Lizenz** müssen deren Bedingungen eingehalten werden.\n\n### ✅ Beispiel für eine korrekte Quellenangabe im Code:\n\n```bash\n# Skript auf Grundlage der Arbeit von [Autor] unter [Repository-Link]\n```\n\n## 🔒 2. Sicherheit und Verantwortung für den Code\n\n- Der gesamte Code in diesem Repository folgt bewährten Vorgehensweisen für sichere Entwicklung.\n- Beiträge mit absichtlich eingebauten Schwachstellen oder unsicheren Vorgehensweisen sind nicht erlaubt.\n- Skripte dürfen niemals die Systemsicherheit oder Benutzerdaten gefährden.\n- Beiträge sollen vor der Implementierung auf Sicherheit und Stabilität geprüft werden.\n\n### ⚠️ Verantwortungsvolle Meldung von Sicherheitslücken\n\nEntdecken Sie eine Sicherheitslücke, melden Sie diese NICHT in öffentlichen Issues oder Foren.\n\nMelden Sie sie stattdessen vertraulich per E-Mail:\n\n📧 proxmenux@macrimi.pro\n\nWeitere Informationen zu Sicherheitslücken und deren Meldung finden Sie in unserer [Sicherheitsrichtlinie](./SECURITY.md).\n\n## 🤝 3. Regeln für die Community\n\nFür ein respektvolles und professionelles Umfeld müssen alle Benutzer diese Regeln beachten:\n\n- ✅ Bleiben Sie in Diskussionen respektvoll und konstruktiv.\n- ❌ Belästigung, Hassrede und beleidigendes Verhalten werden nicht toleriert.\n- ✅ Geben Sie Rückmeldungen sachlich und ohne persönliche Angriffe.\n- ❌ Verstöße können je nach Schwere zu Verwarnungen oder Ausschlüssen führen.\n\n##\n\nDieses Dokument fördert den ethischen Umgang mit Code, Sicherheitsbewusstsein und eine respektvolle Community.\n\n📢 Lassen Sie uns gemeinsam etwas Großartiges schaffen!\n"
|
||||
}
|
||||
@@ -0,0 +1,293 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Zu ProxMenux beitragen | ProxMenux-Dokumentation",
|
||||
"description": "Zu ProxMenux beitragen: Branch-Modell (main / develop / feature/*), Pull-Request-Ablauf, Skript-Header mit Autorenangabe und optionalem Sponsoring-Link, zweiphasige UI-Richtlinie, Nachrichtenfunktionen und der Weg vom Feature-Branch zur stabilen Version.",
|
||||
"ogTitle": "Zu ProxMenux beitragen",
|
||||
"ogDescription": "Branch-Modell, Arbeitsablauf, Autorenangabe im Skript-Header und zweiphasige UI-Richtlinie für Mitwirkende."
|
||||
},
|
||||
"header": {
|
||||
"title": "Zu ProxMenux beitragen",
|
||||
"description": "ProxMenux ist offen für Community-Beiträge - neue Skripte, Fixes für bestehende, Dialogverbesserungen, Übersetzungen, Integrationen. Diese Seite ist die formale Tür: wie das Repository strukturiert ist, das Verzweigungsmodell und der Pull-Request-Workflow, der Skript-Header mit Autorzuweisung und optionalem Sponsor-Link und die Design-Konventionen, denen jeder Beitrag folgen muss.",
|
||||
"section": "Über"
|
||||
},
|
||||
"twoPagesCallout": {
|
||||
"title": "Zwei verwandte Seiten, ein Projekt",
|
||||
"body": "Verwechseln Sie diese Seite nicht mit <contributorsLink>Mitwirkende</contributorsLink>, die bisherige Beiträge von Testern, Reviewern und Entwicklern würdigt. Diese Seite richtet sich an <em>Sie</em> als künftigen Mitwirkenden und erklärt, wie Sie einen Pull Request zur Aufnahme vorbereiten."
|
||||
},
|
||||
"branching": {
|
||||
"heading": "Verzweigungsmodell",
|
||||
"intro": "ProxMenux verwendet ein dreistufiges Verzweigungsmodell:",
|
||||
"headerBranch": "Branch",
|
||||
"headerPurpose": "Zweck",
|
||||
"rows": [
|
||||
{
|
||||
"branch": "main",
|
||||
"purposeRich": "Stabiler, produktionsreifer Code. Hier werden nur veröffentlichungsreife Änderungen aufgenommen. Diese Version erhalten Endnutzer bei einer normalen ProxMenux-Installation."
|
||||
},
|
||||
{
|
||||
"branch": "develop",
|
||||
"purposeRich": "Aktiver Entwicklungsbranch. Neue Arbeiten werden zuerst hier aufgenommen; dies ist der Beta-Kanal. Ist eine stabile Version bereit, wird sie von hier nach <code>main</code> übernommen."
|
||||
},
|
||||
{
|
||||
"branch": "feature/*",
|
||||
"purposeRich": "Kurzlebige Branchs pro Feature, Fix oder Verbesserung. Erstellt aus <code>develop</code>, nach Überprüfung über einen Pull Request wieder in <code>develop</code> zusammengeführt."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Was das für die Nutzer bedeutet",
|
||||
"calloutBody": "Endbenutzer, die <code>main</code> verfolgen, erhalten getestete Releases. Benutzer, die die neuesten Funktionen frühzeitig wünschen - und gelegentliche raue Kanten nicht stören - können <code>develop</code> folgen. Neue Funktionen passieren immer zuerst <code>develop</code>; nichts erreicht <code>main</code>, ohne diesen Zyklus zu durchlaufen."
|
||||
},
|
||||
"workflow": {
|
||||
"heading": "Pull Request Workflow",
|
||||
"intro": "Von der Idee zum fusionierten Release in fünf Schritten:",
|
||||
"step1Lead": "<strong>Erstellen Sie einen Feature Branch aus <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": "Verwenden Sie einen beschreibenden Zweignamen: <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
|
||||
"step2Lead": "<strong>Arbeiten Sie an Ihren Änderungen und schieben Sie den Branch: </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>Öffnen Sie einen Pull Request für <code>develop</code></strong>, nicht für <code>main</code>. Prüfen Sie auf GitHub, dass der Basisbranch auf <code>develop</code> steht. Beschreiben Sie, was das Skript tut und ändert und auf welchen Proxmox-VE-Versionen es getestet wurde.",
|
||||
"step4": "<strong>Nach der Prüfung werden Änderungen in <code>develop</code> zusammengeführt.</strong> Ein Maintainer prüft Codequalität, Header-Konventionen und die zweiphasige UI-Richtlinie. Falls Änderungen nötig sind, pushen Sie weitere Commits in denselben Branch; der PR aktualisiert sich automatisch.",
|
||||
"step5": "<strong>Stabile Versionen werden von <code>develop</code> nach <code>main</code> übernommen.</strong> Bei der Veröffentlichung wird <code>main</code> per Fast-Forward auf <code>develop</code> gebracht und mit einem Tag versehen. Ihr Beitrag wird Teil der nächsten stabilen Version."
|
||||
},
|
||||
"scriptHeader": {
|
||||
"heading": "Skript-Header — Metadaten und Beschreibung",
|
||||
"intro": "Jedes Skript in ProxMenux wird mit zwei benachbarten Kommentarblöcken geöffnet, die zusammen den Header bilden. Sie sind <strong>beide erforderlich</strong> - zusammen lassen sie jeden Leser wissen, wer das Skript geschrieben hat und was es tut, alles ohne den Code selbst zu öffnen.",
|
||||
"bullets": [
|
||||
"<strong>Oberer Block: Metadaten.</strong> Autor, optionale GitHub-/Sponsoring-Links, Maintainer, Copyright, Lizenz, Version und Aktualisierungsdatum. Hier erfolgt auch die <em>Würdigung der Mitwirkenden</em>: Bei einem neuen Skript tragen Sie Ihren Namen und optional Links zur persönlichen GitHub-Seite und einem Unterstützungsprofil ein, etwa Ko-fi, GitHub Sponsors oder Buy Me a Coffee.",
|
||||
"<strong>Unterer Block: Beschreibung.</strong> Ein kurzer Absatz in einfachem Englisch erklärt die Funktion. Nutzer lesen ihn <em>vor</em> dem Code. Er muss für sich allein Zweck, Hauptaktionen, betroffene Ressourcen und Voraussetzungen verständlich machen."
|
||||
],
|
||||
"licenseCalloutTitle": "Die Lizenzlinie ist festgelegt — GPL-3.0",
|
||||
"licenseCalloutBody": "ProxMenux wird unter der <strong>GNU General Public License v3.0</strong> veröffentlicht. Jedes Skript im Projekt wird unter derselben Lizenz ausgeliefert; die <code>License</code>-Zeile im Header ist immer die GPL-3.0-Referenz, die im folgenden Beispiel gezeigt wird - es ist keine Per-Script-Wahl. Indem Sie ein Skript beisteuern, erklären Sie sich damit einverstanden, es unter GPL-3.0 zu veröffentlichen, was bedeutet, dass jeder es lesen, ändern und weiterverteilen kann (einschließlich Änderungen), solange er es unter der gleichen Lizenz behält. Der vollständige Text befindet sich unter <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": "Die Linien <code>GitHub</code> und <code>Sponsor</code> sind optional - lassen Sie sie aus, wenn Sie sie nicht veröffentlichen möchten. Alles andere ist erforderlich.",
|
||||
"whyCalloutTitle": "Warum das wichtig ist",
|
||||
"whyCalloutBody": "Open-Source-Beiträge sind freiwillige Arbeit. Name und optionaler Sponsoring-Link im Quellcode machen die Urheberschaft bei jedem Lesen sichtbar, statt sie hinter dem Projektnamen zu verbergen. Der Beschreibungsblock ist aus einem anderen Grund wichtig: Er ist der erste Anlaufpunkt künftiger Maintainer und neugieriger Nutzer. Eine klare Erklärung entscheidet oft darüber, ob sie einem Skript vertrauen oder es meiden."
|
||||
},
|
||||
"structure": {
|
||||
"heading": "Projektstruktur",
|
||||
"intro": "Wo jede Art von Skript im Repository lebt:",
|
||||
"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": "Jedes Skript lädt <code>utils.sh</code> beim Start per source, um Nachrichtenfunktionen, Spinner, Farbvariablen und Übersetzungssystem einzubinden. Gemeinsame Hilfsbibliotheken in <code>scripts/global/</code> werden ausdrücklich von den Skripten geladen, die sie benötigen."
|
||||
},
|
||||
"twoPhase": {
|
||||
"heading": "Die zweiphasige UI Design Policy",
|
||||
"intro": "Dies ist die wichtigste Konvention in ProxMenux und die PRs werden am häufigsten gebeten, sie zu beheben. Jedes Skript ist in <strong> genau zwei Phasen</strong> unterteilt:",
|
||||
"headerPhase": "Phase",
|
||||
"headerPurpose": "Zweck",
|
||||
"headerScreen": "Bildschirmzustand",
|
||||
"rows": [
|
||||
{
|
||||
"phaseRich": "<strong>Phase 1 — Auswahl</strong>",
|
||||
"purposeRich": "Sammeln Sie jede Benutzerentscheidung. Führen Sie alle erforderlichen Vorbereitungsarbeiten durch (Sonden, Scans, Überprüfungen).",
|
||||
"screenRich": "<code>dialog</code>-Overlays. Wenn eine Suche zwischen zwei Menüs länger als ein oder zwei Sekunden dauert, zeigen Sie einen <code>msg_info</code>-Spinner an, damit der Benutzer weiß, dass das Skript nicht eingefroren ist, und rufen Sie dann <code>stop_spinner</code> direkt vor dem nächsten Dialog auf."
|
||||
},
|
||||
{
|
||||
"phaseRich": "<strong>Phase 2 — Ausführung</strong>",
|
||||
"purposeRich": "Führen Sie jede Operation aus. Zeigen Sie den gesamten Fortschrittsverlauf an, der sich auf dem Bildschirm ansammelt.",
|
||||
"screenRich": "Sichtbare <code>msg_info</code> / <code>msg_ok</code> Nachrichten; niemals <code>dialog</code>."
|
||||
}
|
||||
],
|
||||
"principle": "Das Prinzip: <strong>Sammeln Sie zuerst alles und führen Sie dann alles</strong> aus. Der Benutzer sieht ein sauberes dialoggesteuertes Menü (Phase 1), dann eine saubere Ausführungsansicht im Protokollstil (Phase 2). Kein Mischen — kein Dialog erscheint mitten in der Ausführung, kein Fortschrittsrauschen während der Auswahl.",
|
||||
"phase1Heading": "Phase 1 — typisches Muster",
|
||||
"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>Regeln für Phase 1:</strong>",
|
||||
"phase1Rules": [
|
||||
"Läuft gerade ein <code>msg_info</code>-Spinner und soll ein Menü mit <code>dialog</code> oder <code>whiptail</code> geöffnet werden, rufen Sie zuerst <code>stop_spinner</code> auf. Der Spinner verträgt sich nicht mit deren Bildschirmüberlagerung. Ohne aktiven Spinner ist der Aufruf nicht nötig.",
|
||||
"Verwenden Sie <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code>, um in Phase 1 einen längeren Vorgang sichtbar einzuordnen, etwa eine Prüfung ab fünf Sekunden. Die Funktion leert bereits den Bildschirm; rufen Sie davor nicht <code>clear</code> auf.",
|
||||
"Rufen Sie <code>show_proxmenux_logo</code> nicht zwischen Dialogmenüs auf, in denen nichts angezeigt werden kann - das Löschen des Bildschirms für ein leeres Terminal ist nur visuelles Rauschen.",
|
||||
"Speichern Sie alle Entscheidungen und Sondenergebnisse in Variablen oder parallelen Arrays. Die sichtbare Zusammenfassung erfolgt zu Beginn der Phase 2, nicht in Phase 1."
|
||||
],
|
||||
"phase2Heading": "Phase 2 — typisches Muster",
|
||||
"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>Regeln für Phase 2:</strong> Beginnen Sie mit <code>show_proxmenux_logo + msg_title</code> und fassen Sie Phase 1 sofort in <code>msg_ok</code>-Zeilen zusammen. Rufen Sie <code>show_proxmenux_logo</code> nicht erneut auf, da dies den bisherigen Verlauf löscht. Verwenden Sie kein <code>dialog</code>; ist eine Entscheidung zur Laufzeit unvermeidbar, nutzen Sie <code>whiptail</code> wie im nächsten Abschnitt."
|
||||
},
|
||||
"dialogVsWhiptail": {
|
||||
"headingRich": "Wann <code>dialog</code> vs <code>whiptail</code> zu verwenden",
|
||||
"intro": "Beide Tools zeichnen Benutzeroberflächen im Textmodus, aber sie verhalten sich auf dem Bildschirm sehr unterschiedlich - und ProxMenux verwendet sie aus einem bestimmten Grund in zwei verschiedenen Phasen.",
|
||||
"headerTool": "Werkzeug",
|
||||
"headerWhen": "Wann man es benutzt",
|
||||
"headerEffect": "Wirkung auf den Bildschirm",
|
||||
"rows": [
|
||||
{
|
||||
"toolRich": "<strong><code>dialog</code></strong>",
|
||||
"whenRich": "<strong>Immer in Phase 1.</strong> Jede interaktive Auswahl – Auswahl einer VM, einer Festplatte, eines Dateisystems, das eine Aktion bestätigt – verwendet <code>dialog</code>. Dies ist das Standard-UI-Tool von ProxMenux.",
|
||||
"effectRich": "Übernimmt das Terminal: löscht den Bildschirm, zieht sein Overlay und bringt das Terminal beim Schließen in seinen vorherigen Zustand zurück. Fein in Phase 1, weil sich noch nichts Nützliches zeigt."
|
||||
},
|
||||
{
|
||||
"toolRich": "<strong><code>whiptail</code></strong>",
|
||||
"whenRich": "<strong>Nur in Phase 2, nur wenn unvermeidlich.</strong> Der typische Fall ist eine Neustartaufforderung am Ende der Ausführung. Greifen Sie nicht zu <code>whiptail</code>, um \"Weiter?\" mitten in der Ausführung zu fragen - diese Entscheidung hätte in Phase 1 getroffen werden sollen.",
|
||||
"effectRich": "Leichteres Overlay, das den Terminalkontext <em>nicht</em> löscht. Der akkumulierte <code>msg_ok</code> / <code>msg_info</code>-Verlauf der Phase 2 bleibt hinter dem Dialogfeld sichtbar. Deshalb ist es die richtige Wahl, wenn der Fortschritt bereits auf dem Bildschirm zu sehen ist."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Warum die Trennung wichtig ist",
|
||||
"calloutBody": "Wenn Sie <code>dialog</code> in der Mitte der Phase 2 anrufen, verschwindet jede <code>msg_ok</code>-Zeile, die der Benutzer beobachtet hat. Sie wischen den Audit-Trail. <code>whiptail</code> vermeidet das. Die Regel ist also nicht willkürlich - es geht darum, die Sicht des Benutzers auf das, was das Skript bisher getan hat, zu bewahren.",
|
||||
"rebootHeading": "Neustartabfrage: das typische whiptail in Phase 2",
|
||||
"rebootIntro": "Wenn ein Skript endet und ein Neustart erforderlich ist (z.B.) IOMMU aktiviert, Kernelparameter geändert), die Aufforderung am Ende der Phase 2 verwendet <code>whiptail</code>. Fügen Sie immer einen \"Nein\"-Zweig hinzu, der den Benutzer warnt, die betroffene Ressource nicht zu verwenden, bis er neu startet:",
|
||||
"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": "Referenz der Nachrichtenfunktionen",
|
||||
"intro": "Alle definiert in <code>utils.sh</code>. Verwenden Sie sie als Standard für jede benutzersichtliche Ausgabe - konsistente Visuals über Skripte hinweg ist der springende Punkt. Wenn Ihr Skript eine neue Funktion benötigt, die nicht zum vorhandenen Set passt (ein neuer Schweregrad, ein neuer Layout-Helfer usw.), schlagen Sie es in Ihrem Pull Request vor - es wird überprüft und zu <code>utils.sh</code> hinzugefügt, wenn es allgemein nützlich ist.",
|
||||
"headerFunction": "Funktion",
|
||||
"headerWhen": "Wann zu verwenden",
|
||||
"headerSpinner": "Fortschrittsanzeige",
|
||||
"rows": [
|
||||
{
|
||||
"function": "msg_info \"text\"",
|
||||
"whenRich": "Operation in Arbeit.",
|
||||
"spinner": "Startet"
|
||||
},
|
||||
{
|
||||
"function": "stop_spinner",
|
||||
"whenRich": "Ende der stillen Vorbereitungsarbeiten in Phase 1 — tötet Spinner, löscht die Linie.",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_ok \"text\"",
|
||||
"whenRich": "Vorgang erfolgreich. Auch für „Funktion aktiviert“ verwenden, wenn noch ein Neustart erforderlich ist.",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_warn \"text\"",
|
||||
"whenRich": "Tatsächliche Warnung oder gestörter Zustand.",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_error \"text\"",
|
||||
"whenRich": "Schwerwiegender Fehler.",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_info2 \"text\"",
|
||||
"whenRich": "Nicht blockierender Hinweis (türkisfarbene Infozeile).",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_success \"text\"",
|
||||
"whenRich": "Abschließende Aufforderung „Enter zum Zurückkehren“ am Ende von Phase 2.",
|
||||
"spinner": "Stoppt"
|
||||
},
|
||||
{
|
||||
"function": "msg_title \"text\"",
|
||||
"whenRich": "Fetter Titel mit eingebautem Abstand. Wird zu Beginn der Phase 2 verwendet.",
|
||||
"spinner": "—"
|
||||
},
|
||||
{
|
||||
"function": "show_proxmenux_logo",
|
||||
"whenRich": "Leert den Bildschirm und zeigt das Logo. Zu Beginn von Phase 2 <em>einmal</em> aufrufen.",
|
||||
"spinner": "—"
|
||||
}
|
||||
]
|
||||
},
|
||||
"dialogConventions": {
|
||||
"heading": "Dialogkonventionen",
|
||||
"bullets": [
|
||||
"Geben Sie <code>--backtitle \"$BACKTITLE\"</code> immer an jeden <code>dialog</code>- und <code>whiptail</code>-Aufruf weiter. <code>$BACKTITLE</code> ist immer <code>\"ProxMenux\"</code> - einmal im Skript-Header gesetzt und nie außer Kraft gesetzt. Der Benutzer muss den Projektnamen immer als Framing-Kontext sehen, niemals den eigenen Titel des Skripts.",
|
||||
"Verpacken Sie Titel und Nachrichten immer mit <code>$(translate \"...\")</code>.",
|
||||
"Immer <code>dialog</code> Ausgabe mit <code>2>&1 >/dev/tty</code> umleiten — die erfasste stdout wird die Auswahl des Benutzers, während der Dialog selbst auf das Terminal zieht.",
|
||||
"Verwenden Sie die Standard-UI-Dimensionsvariablen (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, usw.) für eine konsistente Dimensionierung über Skripte hinweg.",
|
||||
"Prüfen Sie immer auf leere oder abgebrochene Auswahlen und behandeln Sie diese sauber."
|
||||
],
|
||||
"exampleIntro": "Vollständiges Beispiel — Erstellung eines VM-Auswahlmenüs und Bearbeitung der Stornierung:",
|
||||
"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": "Übersetzungspolitik",
|
||||
"intro": "Alle vom Benutzer sichtbaren Zeichenfolgen müssen mit der <code>translate</code>-Funktion gewickelt sein. ProxMenux übersetzt sie automatisch in alle unterstützten Sprachen - Sie schreiben Englisch, der Benutzer liest seine Muttersprache.",
|
||||
"code": "msg_ok \"$(translate \"Operation completed successfully.\")\"\nmsg_error \"$(translate \"Failed to start container\") $CTID.\"\ndialog --title \"$(translate \"Select Storage\")\" ...",
|
||||
"bullets": [
|
||||
"Schreibe Strings in Englisch – die Übersetzung wird automatisch vom Build bearbeitet.",
|
||||
"Halten Sie Strings kurz. Vermeiden Sie das Einbetten von Variablen in lange Sätze, wenn möglich.",
|
||||
"Variablennamen, Pfade oder technische Bezeichner <strong>nicht</strong>übersetzen."
|
||||
]
|
||||
},
|
||||
"variableStyle": {
|
||||
"heading": "Variable und Stilkonventionen",
|
||||
"bullets": [
|
||||
"Verwenden Sie <code>UPPER_CASE</code> für Variablen auf Skriptebene.",
|
||||
"Verwenden Sie <code>lower_case</code> für lokale Funktionsvariablen (mit <code>local</code> deklarieren).",
|
||||
"Setzen Sie alle Variablenexpansionen in Anführungszeichen: <code>\"$VAR\"</code> statt <code>$VAR</code>.",
|
||||
"Verwenden Sie <code>[[ ]]</code> für Konditionale, nicht <code>[ ]</code> (außer wenn POSIX erforderlich ist).",
|
||||
"<code>show_proxmenux_logo</code> ist der geeignete Weg, um den Bildschirm zu löschen - er enthält das Clear und zeigt das Projektlogo, so dass der Benutzer immer einen visuellen Kontext hat. Rufen Sie es einmal zu Beginn der Phase 2 (und optional vor einem langen Phase 1-Spinnerblock) auf."
|
||||
],
|
||||
"standardNamesIntro": "Standardvariablennamen im gesamten Projekt:",
|
||||
"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": "Umleitung der Werkzeugausgabe während der Phase 2",
|
||||
"redirectIntro": "Phase 2 zeigt ein sauberes Protokoll der <code>msg_info → msg_ok</code>-Zeilen an, die sich auf dem Bildschirm ansammeln. Wenn ein Tool, das Sie aufrufen (apt, mkfs, qm, pct, dd, etc.), seine eigene Ausgabe in stdout/stderr schreibt, scrollt es an Ihren Nachrichten vorbei und unterbricht den visuellen Fluss - Sie haben ein chaotisches Terminal, in dem der Benutzer die eigenen Fortschrittslinien des Skripts nicht vom Rauschen des zugrunde liegenden Tools unterscheiden kann.",
|
||||
"withoutRedirectIntro": "<strong>Ohne Umleitung</strong>: die Ausgabe für Nutzer, wenn zusätzliche Werkzeugausgaben nicht abgefangen werden.",
|
||||
"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>Mit Umleitung</strong>: dieselbe Aktion, wenn zusätzliche Ausgaben an anderer Stelle landen.",
|
||||
"withRedirectCode": "ℹ Installing kernel package...\n✓ Kernel installed.\nℹ Configuring kernel command line...\n✓ Configured.\nℹ Refreshing boot loader...\n✓ Boot loader updated.",
|
||||
"twoPatternsIntro": "Zwei Muster zur Auswahl:",
|
||||
"discardLead": "<strong>Ausgabe verwerfen</strong>, wenn sie nicht benötigt wird: die einfachste und schnellste Variante.",
|
||||
"discardCode": "DEBIAN_FRONTEND=noninteractive apt-get install -y \"$package\" >/dev/null 2>&1",
|
||||
"logLead": "<strong>Ausgabe in eine Protokolldatei schreiben</strong>, wenn Sie sie später prüfen möchten, etwa zur Fehlersuche bei einer Installation oder um dpkg-Aktionen nachzuvollziehen. Dies ist das bevorzugte Muster für apt-Aufrufe:",
|
||||
"logCode": "apt-get install -y \"$package\" >> \"$log_file\" 2>&1",
|
||||
"referenceOutro": "<code>scripts/global/update-pve9_2.sh</code> dient als Referenz: Jeder <code>apt-get</code>-Aufruf schreibt in eine Protokolldatei. Nutzer sehen nur den Ablauf <code>msg_info → msg_ok</code>, während die Datei bei Fehlern genau zeigt, was apt getan hat."
|
||||
},
|
||||
"dosAndDonts": {
|
||||
"heading": "Do's und Don'ts",
|
||||
"doHeading": "✅ Empfohlen",
|
||||
"doBullets": [
|
||||
"<code>stop_spinner</code> vor einem <code>dialog</code> in Phase 1 nur dann, wenn ein <code>msg_info</code> Spinner gerade läuft.",
|
||||
"Phase 2 beginnt mit <code>show_proxmenux_logo + msg_title + msg_ok</code> als Zusammenfassung der Ergebnisse von Phase 1.",
|
||||
"Verwenden Sie <code>msg_ok</code> für erfolgreich aktivierte Funktionen – auch wenn ein Neustart erforderlich ist.",
|
||||
"Verwenden Sie <code>whiptail</code> (nicht <code>dialog</code>) für jede Aufforderung nach der Ausführung, die in Phase 2 erscheinen muss.",
|
||||
"Fügen Sie immer einen \"Nein\" -Zweig in Reboot-Dialoge ein, der den Benutzer warnt, die betroffene Ressource bis zum Neustart nicht zu starten.",
|
||||
"Schützen Sie die reine VM-Logik, indem Sie <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code> überprüfen - Controller und NVMe PCIe können nicht zu LXC-Containern hinzugefügt werden.",
|
||||
"Verwenden Sie <code>ensure_repositories</code> von <code>utils-install-functions.sh</code> anstelle von bedingungslosem <code>apt-get update</code>.",
|
||||
"Verwenden Sie parallele Arrays in Phase 1, wenn jedes Element mehrere Dialoge benötigt."
|
||||
],
|
||||
"dontHeading": "❌ Vermeiden",
|
||||
"dontBullets": [
|
||||
"Rufen Sie <code>dialog</code> an, während ein Spinner aktiv ist.",
|
||||
"Überspringen Sie die Phase 1 Zusammenfassung zu Beginn der Phase 2.",
|
||||
"Rufen Sie <code>show_proxmenux_logo</code> ein zweites Mal an - es löscht alles, was Phase 2 gedruckt hat.",
|
||||
"Verwenden Sie <code>dialog</code> in Phase 2 (verwenden Sie <code>whiptail</code> für den seltenen unvermeidlichen Fall).",
|
||||
"Verwenden Sie reine <code>clear</code>.",
|
||||
"<code>msg_title</code> mit Leerzeilen aus <code>echo \"\"</code> umgeben; die Abstände sind bereits enthalten.",
|
||||
"Verwenden Sie <code>msg_warn</code>, um eine erfolgreich aktivierte Funktion zu melden - das ist ein <code>msg_ok</code>.",
|
||||
"Führen Sie bedingungslos <code>apt-get update</code> aus - verwenden Sie <code>ensure_repositories</code>."
|
||||
]
|
||||
},
|
||||
"submitting": {
|
||||
"heading": "Einreichen Ihres Beitrags",
|
||||
"steps": [
|
||||
"Fork <code>MacRimi/ProxMenux</code> auf GitHub und klonen Sie Ihre Fork.",
|
||||
"Erstellen Sie einen <code>feature/*</code>-Zweig aus <code>develop</code> (siehe <em>Branching-Modell</em> oben).",
|
||||
"Befolgen Sie diese Anleitung für neue oder geänderte Skripte. Schreiben Sie den Header mit Ihrem Namen; fügen Sie die optionale Sponsorenzeile hinzu, wenn Sie möchten.",
|
||||
"Testen Sie Ihr Skript auf einer echten Proxmox VE-Instanz - sowohl Phase 1 (jeder Dialogzweig) als auch Phase 2 (jede Operation ist erfolgreich und wird bei Fehlern sauber zurückgesetzt).",
|
||||
"Öffnen Sie eine Pull Request <strong> gegen <code>develop</code></strong> mit einer klaren Beschreibung: was das Skript macht, was sich geändert hat, auf welcher Proxmox VE-Version es getestet wurde.",
|
||||
"Stellen Sie sicher, dass Ihr Beitrag den <cocLink>Code of Conduct</cocLink> respektiert."
|
||||
],
|
||||
"securityOutro": "Befolgen Sie bei sicherheitsrelevanten Problemen den Offenlegungsfluss in <securityLink>SECURITY.md</securityLink>, anstatt ein öffentliches Problem zu öffnen."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin als nächstes",
|
||||
"items": [
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/blob/main/CONTRIBUTING.md",
|
||||
"label": "CONTRIBUTING.md (vollständige Anleitung)",
|
||||
"tail": "— die Quelle der Wahrheit für jede Konvention, einschließlich der fortgeschrittenen Hardware-Muster."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/contributors",
|
||||
"label": "Beitragende",
|
||||
"tail": " — die Menschen, deren Arbeit ProxMenux-Versionen geprägt hat. Eine andere Seite als diese hier."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"label": "Verhaltenskodex",
|
||||
"tail": "- die Standards, die jeder Mitwirkende zu befolgen bereit ist."
|
||||
},
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"label": "GitHub Discussions",
|
||||
"tail": "Fragen Sie, bevor Sie bauen, ob Sie nicht sicher sind, ob eine Idee passt, oder um Mitarbeiter für ein größeres Feature zu finden."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Mitwirkende | ProxMenux-Dokumentation",
|
||||
"description": "Anerkennung für die Menschen, die ProxMenux möglich machen: Tester, Reviewer und Entwickler, die jede Version mitgestalten.",
|
||||
"ogTitle": "Mitwirkende | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Treffen Sie die Mitwirkenden hinter ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Mitwirkende",
|
||||
"description": "Das ProxMenux-Projekt wächst dank seiner Mitwirkenden. Diese Seite würdigt ihre Arbeit: Versionen vor der Veröffentlichung testen, Regressionen erkennen, PRs prüfen und die Entwicklung neuer Funktionen mitgestalten.",
|
||||
"section": "Über"
|
||||
},
|
||||
"beyond": {
|
||||
"title": "Weitere Mitwirkende",
|
||||
"body": "Viele weitere Menschen helfen mit Fehlermeldungen, Funktionsideen in Discussions, Beta-Tests und Übersetzungen. Die vollständige Liste der Code-Mitwirkenden steht im <extlink>GitHub-Mitwirkendendiagramm</extlink>. Diese Seite hebt diejenigen hervor, die besonders aktiv ProxMenux-Versionen testen und prüfen."
|
||||
},
|
||||
"testers": {
|
||||
"heading": "Tester & Reviewer",
|
||||
"intro": "Diese Personen gehörten zu den ersten Mitwirkenden. Mit Tests, Fehlermeldungen und Verbesserungsvorschlägen halfen sie ProxMenux dabei, zu dem zu werden, was es heute ist.",
|
||||
"roles": {
|
||||
"testing": "Testen",
|
||||
"testingReviewer": "Tests und Review"
|
||||
},
|
||||
"youtube": "YouTube"
|
||||
},
|
||||
"contribute": {
|
||||
"heading": "Möchten Sie dazu beitragen?",
|
||||
"intro": "Jeder Beitrag ist willkommen - Code, Testen, Design, Dokumentation oder einfach nur das Teilen Ihrer Ideen:",
|
||||
"tester": "<strong>Tester</strong> — probieren Sie den <beta>Beta-Kanal</beta> aus und melden Sie vor der stabilen Veröffentlichung, was funktioniert und was nicht.",
|
||||
"developer": "<strong>Entwickler</strong> — Bash, Next.js (TypeScript) und etwas Python für die virtuelle Übersetzungsumgebung (venv). PRs auf <gh>GitHub</gh> sind willkommen.",
|
||||
"designer": "<strong>Designer</strong> — Verbesserungen der Benutzeroberfläche, Icons, Screenshots zur Dokumentation.",
|
||||
"ideas": "<strong>Ideen</strong> — eröffnen Sie zuerst ein Thema in <disc>GitHub Discussions</disc>, bevor Sie einen Funktionswunsch als Issue einreichen."
|
||||
},
|
||||
"coc": {
|
||||
"title": "Lesen Sie zuerst den Verhaltenskodex",
|
||||
"body": "Lesen Sie vor dem Einreichen von Code oder Fehlermeldungen kurz den <coclink>Verhaltenskodex und die bewährten Vorgehensweisen</coclink>. Darin werden die Verantwortung für Code, die Meldung von Sicherheitslücken und der Umfang von PRs erläutert."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Häufige Fragen | ProxMenux-Dokumentation",
|
||||
"description": "Häufige Fragen zu ProxMenux: Funktionsumfang, Installation, Kompatibilität ab PVE 8, Anpassung, Updates, Sicherheit, Produktionseinsatz, Systemdateien, Beiträge und Deinstallation.",
|
||||
"ogTitle": "Häufige Fragen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Häufige Fragen zu Installation, Kompatibilität, Sicherheit und Beiträgen zu ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Häufig gestellte Fragen",
|
||||
"description": "Häufige Fragen zu ProxMenux: Funktionsumfang, Zielgruppe, Installation, Updates, Deinstallation, Kompatibilität, Anpassung, Sicherheit und Beiträge. Fehlt Ihre Frage, sehen Sie in GitHub Discussions nach oder erstellen Sie ein Issue.",
|
||||
"section": "Über"
|
||||
},
|
||||
"quickLinks": {
|
||||
"title": "Schnelle Links",
|
||||
"installationLabel": "Installation",
|
||||
"installationSuffix": "— der One-Line-Installationsbefehl + Abhängigkeiten.",
|
||||
"introductionLabel": "Einleitung",
|
||||
"introductionSuffix": "— was ProxMenux tut, in 5 Minuten.",
|
||||
"uninstallLabel": "Deinstallieren",
|
||||
"uninstallSuffix": "— sauberes Entfernen.",
|
||||
"issuesLabel": "GitHub Issues",
|
||||
"discussionsLabel": "Diskussionen"
|
||||
},
|
||||
"q1": {
|
||||
"question": "Was ist ProxMenux und wofür wird es verwendet?",
|
||||
"p1Rich": "<strong>ProxMenux</strong> ist ein interaktives menügesteuertes Tool, das <strong>Proxmox VE</strong> für alle Benutzer unabhängig von ihrer technischen Erfahrung zugänglich macht. Es vereinfacht die Befehlsausführung und ermöglicht es Benutzern, Aktionen auf ihrem System durchzuführen, ohne dass fortgeschrittene Linux-Kenntnisse erforderlich sind.",
|
||||
"p2": "Weniger erfahrene Benutzer können Befehle über übersichtliche Menüs ausführen und müssen seltener selbst im Terminal tippen. Erfahrenen Administratoren erspart ProxMenux Eingaben bei wiederkehrenden Aufgaben wie der Absicherung nach der Installation, GPU-Passthrough, OVF-VM-Importen und der Rotation von ZFS-Snapshots.",
|
||||
"p3": "Proxmox VE ist weit verbreitet für:",
|
||||
"items": [
|
||||
"Virtualisierung auf Unternehmensebene",
|
||||
"HomeLab und persönliche Cloud-Lösungen",
|
||||
"Multimedia-Server, Automatisierung und mehr"
|
||||
]
|
||||
},
|
||||
"q2": {
|
||||
"question": "Wie installiere ich ProxMenux?",
|
||||
"p1Rich": "Folgen Sie der <installlink>Installationsanleitung</installlink>. Kurz zusammengefasst:",
|
||||
"stableInstall": "bash -c \"$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)\"",
|
||||
"p2": "Einmal installiert, starten Sie es einfach mit:",
|
||||
"menuCmd": "menu"
|
||||
},
|
||||
"q3": {
|
||||
"question": "Ist ProxMenux mit allen Proxmox-Versionen kompatibel?",
|
||||
"bodyRich": "<strong>Nein — ProxMenux benötigt Proxmox VE 8 oder neuer.</strong> PVE 7 und ältere Versionen werden nicht unterstützt. Aktualisieren Sie PVE 7 zunächst nach der offiziellen Proxmox-Anleitung auf 8.x. Den anschließenden Wechsel von 8 auf 9 können Sie über <upgradelink>Werkzeuge → PVE 8 auf PVE 9 aktualisieren</upgradelink> in ProxMenux durchführen."
|
||||
},
|
||||
"q4": {
|
||||
"question": "Kann ich ProxMenux anpassen?",
|
||||
"p1Rich": "Lokale Änderungen an den Hauptskripten können beim Aktualisieren überschrieben werden. Bearbeiten Sie diese Dateien daher möglichst nicht direkt. Folgendes <em>können</em> Sie anpassen:",
|
||||
"items": [
|
||||
"Das Konsolenbanner über das <strong>FastFetch</strong> Tool in den Post-Install-Optionen.",
|
||||
"Welche optionalen Komponenten installiert werden (Monitor, Fail2Ban, Lynis...) – wählen Sie während der Installation oder später über das entsprechende Menü aus."
|
||||
]
|
||||
},
|
||||
"q5": {
|
||||
"question": "Wie aktualisiere ich ProxMenux?",
|
||||
"p1Rich": "Wenn eine neue Version verfügbar ist, erkennt ProxMenux sie beim nächsten Aufruf von <code>menu</code> und bietet ein Update an. Stimmen Sie zu, werden die Dateien und die Konfiguration des Werkzeugs in der bestehenden Installation ersetzt. Ein manueller Download ist nicht nötig.",
|
||||
"p2Rich": "Benutzer der stabilen Version erhalten stabile Updates, Beta-Benutzer die Beta-Updates. Sobald eine stabile Version erscheint, informiert die Beta beim nächsten Menüstart darüber und bietet den automatischen Wechsel an. Weitere Informationen finden Sie im <betalink>Beta-Programm</betalink>."
|
||||
},
|
||||
"q6": {
|
||||
"question": "Wo kann ich Probleme melden?",
|
||||
"p1Rich": "Melden Sie Fehler über <issueslink>GitHub Issues</issueslink>. Beschreiben Sie die Schritte zum Reproduzieren, den Fehlertext und gegebenenfalls die Monitor-Ausgabe von <code>journalctl -u proxmenux-monitor -n 50</code>.",
|
||||
"p2Rich": "Bei <strong>Sicherheitsproblemen</strong>: <strong>Veröffentlichen Sie keine Details</strong>. Folgen Sie dem Verfahren zur verantwortungsvollen Meldung im <coclink>Verhaltenskodex und den bewährten Vorgehensweisen</coclink>."
|
||||
},
|
||||
"q7": {
|
||||
"question": "Kann ich zu ProxMenux beitragen?",
|
||||
"p1Rich": "<strong>Unbedingt.</strong> ProxMenux ist ein gemeinschaftliches Open-Source-Projekt. Beiträge sind als Code (Bash, Next.js/TypeScript und Python-Übersetzungswerkzeuge), Tests, Dokumentation, Design oder Ideen willkommen.",
|
||||
"item1Rich": "Besprechen Sie Ideen in <discusslink>GitHub Discussions</discusslink>, bevor Sie eine Feature Request öffnen.",
|
||||
"item2Rich": "Lesen Sie vor einem Pull Request den <coclink>Verhaltenskodex und die bewährten Vorgehensweisen</coclink>.",
|
||||
"item3Rich": "Auf der <contriblink>Mitwirkendenseite</contriblink> finden Sie die aktuellen Tester und Reviewer."
|
||||
},
|
||||
"q8": {
|
||||
"question": "Ändert ProxMenux kritische Systemdateien?",
|
||||
"p1Rich": "<strong>Bei der Installation von ProxMenux werden folgende Komponenten hinzugefügt.</strong>",
|
||||
"item1Rich": "Abhängigkeiten über apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> und <code>git</code>. Die Übersetzungen verwenden vorgefertigte JSON-Kataloge. Der Installer legt auf dem Host keine virtuelle Python-Umgebung für Übersetzungen an.",
|
||||
"item2Rich": "Der Skriptbaum bei <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "Das Startskript unter <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "Optional: der systemd-Dienst von Monitor unter <code>proxmenux-monitor.service</code>.",
|
||||
"p2Rich": "ProxMenux verändert die zentrale Proxmox-Konfiguration <em>nicht</em>, es sei denn, Sie fordern dies ausdrücklich über ein entsprechendes Menü an. Die Netzwerkreparatur bearbeitet beispielsweise <code>/etc/network/interfaces</code>, jedoch erst nach Ihrer Bestätigung und dem Anlegen einer Sicherung."
|
||||
},
|
||||
"q9": {
|
||||
"question": "Ist es sicher, ProxMenux in der Produktion zu verwenden?",
|
||||
"bodyRich": "<strong>Ja.</strong> Da ProxMenux die zentralen Proxmox-Dateien nur auf ausdrücklichen Wunsch verändert, kann es in Produktionsumgebungen eingesetzt werden. Testen Sie automatisierte Abläufe zunächst in einer kontrollierten Umgebung und erstellen Sie Sicherungen, bevor Sie destruktive Vorgänge ausführen, etwa das Upgrade von PVE 8 auf 9, das Formatieren eines Datenträgers oder das Löschen einer VM."
|
||||
},
|
||||
"q10": {
|
||||
"question": "Wie deinstalliere ich ProxMenux?",
|
||||
"p1Rich": "In ProxMenux: <strong>Einstellungen → ProxMenux deinstallieren</strong>. Die Deinstallation entfernt den Skriptbaum, das Startskript und den Monitor-Dienst sowie auf Wunsch ausgewählte Abhängigkeiten. <code>/root/.bashrc</code> und <code>/etc/motd</code> werden aus den bei der Installation angelegten Sicherungen wiederhergestellt, sofern diese vorhanden sind.",
|
||||
"p2Rich": "Die vollständige Anleitung finden Sie unter <uninstalllink>ProxMenux deinstallieren</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal markiert die Installations-URL - ist es sicher?",
|
||||
"p1Rich": "Der in Issue #162 gemeldete Treffer von <em>Chong Lua Dao</em> bei 1 von 95 Prüfungen wurde vom Maintainer als Fehlalarm eingestuft. Der Installer verwendet das Muster <code>curl | bash</code> und kann <code>jq</code> aus dessen offizieller GitHub-Veröffentlichung herunterladen. Dieses <em>Verhalten</em> kann heuristische Scanner auslösen. Der damalige Bericht ist keine Bewertung aller künftigen Downloads.",
|
||||
"p2Rich": "ProxMenux ist vollständig quelloffen. Sie können das Installationsskript Zeile für Zeile prüfen: <scriptlink>install_proxmenux.sh</scriptlink>. Weitere Hintergründe finden Sie in <issuelink>Issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,67 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Über das Projekt | ProxMenux-Dokumentation",
|
||||
"description": "Über ProxMenux: Projektziele, Mitwirkende, FAQ und Verhaltenskodex. Open-Source-Menümanagement-Tool für Proxmox VE 8+, erstellt und gepflegt von MacRimi mit einem kleinen Team von Testern und Mitwirkenden.",
|
||||
"ogTitle": "Über das Projekt | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Über ProxMenux — ein menügesteuertes Open-Source-Werkzeug zur Verwaltung von Proxmox VE 8+."
|
||||
},
|
||||
"header": {
|
||||
"title": "Über",
|
||||
"description": "Projektinformationen, FAQ, Mitwirkende und Verhaltenskodex. ProxMenux ist ein Open-Source-Menümanagement-Tool für Proxmox VE 8+, das von MacRimi mit Hilfe eines kleinen Teams von Testern und Mitwirkenden entwickelt und gewartet wird.",
|
||||
"section": "Über"
|
||||
},
|
||||
"callout": {
|
||||
"title": "Open Source, von der Community getragen",
|
||||
"body": "ProxMenux steht unter der GPL-3.0-Lizenz und wird öffentlich auf GitHub entwickelt. Jedes Skript lässt sich prüfen, jede Änderung nachvollziehen. Beiträge in Form von Fehlermeldungen, Ideen, Code und Tests sind willkommen."
|
||||
},
|
||||
"section": {
|
||||
"heading": "In diesem Abschnitt",
|
||||
"options": [
|
||||
{
|
||||
"icon": "HelpCircle",
|
||||
"href": "/docs/about/faq",
|
||||
"title": "FAQ",
|
||||
"description": "Häufig gestellte Fragen: Was ist ProxMenux, Installation, Kompatibilität, Anpassung, Updates, Sicherheit, Produktionsnutzung, Deinstallation."
|
||||
},
|
||||
{
|
||||
"icon": "Users",
|
||||
"href": "/docs/about/contributors",
|
||||
"title": "Mitwirkende",
|
||||
"description": "Anerkennung für die Menschen, die ProxMenux möglich machen: Tester, Reviewer und Entwickler, die jede Version mitgestalten."
|
||||
},
|
||||
{
|
||||
"icon": "ScrollText",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"title": "Verhaltenskodex",
|
||||
"description": "Projektwerte, Verantwortung für eingereichten Code und Beitragsrichtlinien. Pflichtlektüre vor dem Einreichen eines PR oder einer Fehlermeldung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"involved": {
|
||||
"heading": "Beteiligen Sie sich",
|
||||
"intro": "Drei Orte, um sich mit dem Projekt zu beschäftigen:",
|
||||
"cards": [
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/issues/new",
|
||||
"title": "🐛 Einen Bug melden",
|
||||
"description": "GitHub Issues — fügen Sie Protokolle und Schritte zum Nachstellen bei."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"title": "💡 Schlagen Sie ein Feature vor",
|
||||
"description": "GitHub Discussions — teilen Sie Ideen, bevor Sie eine PR öffnen."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/pulls",
|
||||
"title": "🔀 Einen PR einreichen",
|
||||
"description": "GitHub Pull Requests – lesen Sie zuerst den Verhaltenskodex."
|
||||
}
|
||||
]
|
||||
},
|
||||
"support": {
|
||||
"heading": "Unterstützung des Projekts",
|
||||
"introRich": "Wenn ProxMenux Ihnen Zeit spart, ist der einfachste Weg, anderen zu helfen, es zu entdecken, <starlink> dem Repo ein ⭐ auf GitHub</starlink> zu geben. Wenn Sie weiter gehen wollen:",
|
||||
"kofiLabel": "Auf Ko-fi unterstützen",
|
||||
"kofiOutro": "- kauft dem Betreuer einen Kaffee und hält die Entwicklung am Laufen."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,220 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Backups erstellen – interaktiver Backup-Flow | ProxMenux",
|
||||
"description": "Der interaktive Backup-Ablauf in ProxMenux: zwei Einstiegspunkte (das TUI-Menü von Scripts und die Weboberfläche von Monitor), drei Ziele, zwei Profilmodi, ein gemeinsamer Vorbereitungsschritt und ein Bestätigungsdialog. Beschrieben werden die Matrix mit sechs Optionen, das Standardprofil und das benutzerdefinierte Profil sowie die Schritte von der Auswahl eines Backups bis zum Speichern des Archivs am Ziel.",
|
||||
"ogTitle": "ProxMenux Backup — Erstellen von Backups",
|
||||
"ogDescription": "Der interaktive Backup-Flow mit drei Destinationen, zwei Profilen und einem gemeinsamen Staging-Schritt.",
|
||||
"twitterTitle": "Backups erstellen | ProxMenux",
|
||||
"twitterDescription": "Interaktiver Backup-Flow mit drei Zielen und zwei Profilmodi."
|
||||
},
|
||||
"header": {
|
||||
"title": "Backups erstellen",
|
||||
"description": "Der interaktive Backup-Ablauf: Wählen Sie ein Ziel und ein Profil, prüfen Sie die Zusammenfassung und verfolgen Sie, wie das Archiv gespeichert wird. Beide Einstiegspunkte verwenden dasselbe Backend und erzeugen identische Archive.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Zwei Einstiegspunkte, identische Funktionalität",
|
||||
"body": "Die TUI von Scripts und die Weboberfläche von Monitor bieten <strong>genau dieselben Funktionen</strong>. Jedes Backup — manuell oder geplant — durchläuft dieselbe Auswahlmatrix (drei Ziele × zwei Profile) und ruft pro Zelle dieselbe Backend-Funktion auf (<code>_bk_pbs</code>, <code>_bk_borg</code> oder <code>_bk_local</code>). Die über beide Einstiegspunkte erzeugten Archive sind nicht zu unterscheiden. Die Wahl ist Geschmackssache: Die TUI eignet sich für SSH und Skripte; Monitor bietet Mausbedienung sowie Ansichten für Benachrichtigungen und laufende Protokollausgaben."
|
||||
},
|
||||
"entryPoints": {
|
||||
"heading": "Die beiden Eingangspunkte",
|
||||
"rows": [
|
||||
{
|
||||
"entry": "ProxMenux Scripts (TUI)",
|
||||
"path": "menu → Utilities → Host Config Backup",
|
||||
"detail": "Dialogbasierter Flow, SSH-freundlich. Das Hauptmenü präsentiert die sechs Optionen direkt. Verwendet <code>backup_menu</code> in <code>backup_host.sh</code>."
|
||||
},
|
||||
{
|
||||
"entry": "ProxMenux Monitor (Weboberfläche)",
|
||||
"path": "Backups tab → Create backup",
|
||||
"detail": "Assistentengestützter Ablauf. Dieselben sechs Optionen erscheinen als zweistufiges Formular (Ziel → Profil). Über die Flask-API werden dieselben Backend-Funktionen aufgerufen."
|
||||
}
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Manuelle vs. geplante Backups",
|
||||
"body": "Backups können in zwei Modi erstellt werden: <strong>manuell</strong> (der interaktive Fluss, den diese Seite dokumentiert - der Benutzer wählt ein Ziel und ein Profil aus einem Menü aus und verfolgt das Speichern des Archivs) oder <strong>geplant</strong> (ein unbeaufsichtigter Job, der auf einem Cron-Timer läuft und die für den Job konfigurierte Aufbewahrung anwendet). Beide Modi unterstützen die gleichen drei Ziele und die gleichen zwei Profile, und beide sind von beiden Einstiegspunkten verfügbar - dem Scripts TUI-Menü und der Registerkarte Monitor-Backups. Geplante Jobs verwenden die gleichen Backend-Funktionen wie der manuelle Ablauf durch <code>run_scheduled_backup.sh</code>; die produzierten Archive sind nicht zu unterscheiden.",
|
||||
"seeAlso": "Die Seite mit geplanten Aufträgen deckt den gesamten Ablauf ab, einschließlich der Art und Weise, wie Sie einen Auftrag erstellen, ihn an einen vorhandenen PVE vzdump-Timer anhängen und die Retentionswerte konfigurieren.",
|
||||
"monitorAlt": "ProxMenux Monitor Backups Registerkarte zeigt den Neuen geplanten Backup-Dialog mit Ziel, Profil, Zeitplan und Aufbewahrungsfelder.",
|
||||
"monitorCaption": "Geplantes Backup — ProxMenux Monitor. Derselbe Wizard-Dialog, der ein manuelles Backup erstellt, trägt die Zeitplan- und Aufbewahrungsfelder unten für den unbeaufsichtigten Pfad."
|
||||
},
|
||||
"matrix": {
|
||||
"heading": "Die Matrix mit sechs Optionen",
|
||||
"intro": "Die Auswahl bestimmt sowohl das ausgeführte Backend als auch die Strategie zur Pfadauswahl. Die zielspezifischen Seiten erläutern die Konfiguration jeder Zelle.",
|
||||
"rows": [
|
||||
{
|
||||
"combo": "1",
|
||||
"destination": "PBS",
|
||||
"profile": "Standard",
|
||||
"action": "Lädt das Standardprofil plus persistente Extras in ein konfiguriertes PBS-Repository hoch."
|
||||
},
|
||||
{
|
||||
"combo": "2",
|
||||
"destination": "Borg",
|
||||
"profile": "Standard",
|
||||
"action": "Erstellt ein Archiv mit dem Standardprofil plus persistenten Extras im ausgewählten Borg-Repository."
|
||||
},
|
||||
{
|
||||
"combo": "3",
|
||||
"destination": "Lokal",
|
||||
"profile": "Standard",
|
||||
"action": "Schreibt ein <code>.tar.zst</code>-Archiv mit dem Standardprofil plus persistenten Extras an das konfigurierte lokale Ziel."
|
||||
},
|
||||
{
|
||||
"combo": "4",
|
||||
"destination": "PBS",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet vor dem PBS-Upload die Pfadauswahl; der Benutzer markiert die gewünschten Pfade und kann neue hinzufügen."
|
||||
},
|
||||
{
|
||||
"combo": "5",
|
||||
"destination": "Borg",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet den Pfadwähler, bevor das Borg-Archiv erstellt wird."
|
||||
},
|
||||
{
|
||||
"combo": "6",
|
||||
"destination": "Lokal",
|
||||
"profile": "Benutzerdefiniert",
|
||||
"action": "Öffnet den Pfadwähler vor dem Schreiben des lokalen <code>.tar.zst</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"profiles": {
|
||||
"heading": "Standardprofil und benutzerdefiniertes Profil",
|
||||
"defaultTitle": "Standardprofil",
|
||||
"defaultBody": "Das Standardprofil ist die kuratierte Liste aus <code>hb_default_profile_paths</code> (dokumentiert in <em>Funktionsweise</em> unter <em>Pfadkategorien</em>) sowie jeder Eintrag in der persistenten Extras-Datei <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. Der Benutzer bestätigt die Ziel- und Verschlüsselungsoptionen und das Backup verläuft ohne weitere Pfadauswahl.",
|
||||
"customTitle": "Benutzerdefiniertes Profil",
|
||||
"customBody": "Das benutzerdefinierte Profil öffnet eine Checkliste mit allen Pfaden des Standardprofils (nicht markiert) und allen persistenten Extras (vormarkiert, mit dem Präfix <code>[+]</code>). Der Benutzer markiert die Pfade für diesen Durchlauf und kann über <em>Benutzerdefinierten Pfad hinzufügen</em> einen neuen absoluten Pfad ergänzen. Jeder dabei hinzugefügte Pfad wird in <code>backup-extra-paths.txt</code> gespeichert, damit künftige Backups ihn automatisch berücksichtigen. Das Abwählen eines persistenten Extras gilt nur für diesen Durchlauf und löscht es nicht aus der Datei — dafür gibt es außerhalb des Backup-Ablaufs die separate Aktion <em>Benutzerdefinierte Pfade verwalten</em>.",
|
||||
"customPickerAlt": "Benutzerdefinierte Profil-Checkliste mit den Standard-Profilpfaden (nicht markiert) und persistenten Extras (vormarkiert mit einem [+]-Präfix) sowie Schaltflächen, um einen neuen Pfad hinzuzufügen oder die Auswahl zu bestätigen.",
|
||||
"customPickerCaption": "Benutzerdefiniertes Profil — die Pfadauswahl. Die Pfade des Standardprofils sind nicht markiert; persistente Extras sind mit dem Präfix [+] vormarkiert. Der Benutzer markiert die Pfade für diesen Durchlauf.",
|
||||
"manageCustomAlt": "Menü zur Verwaltung benutzerdefinierter Pfade mit der Liste persistenter Extras und Optionen zum Hinzufügen, Entfernen und Bearbeiten.",
|
||||
"manageCustomCaption": "Benutzerdefinierte Pfade verwalten - der Einstiegspunkt, an dem persistente Extras hinzugefügt oder entfernt werden. Jeder hier aufgeführte Pfad wird automatisch in Backups im Standardmodus aufgenommen, ohne dass die benutzerdefinierte Pfadauswahl geöffnet werden muss."
|
||||
},
|
||||
"commonPipeline": {
|
||||
"heading": "Was läuft unabhängig vom Ziel",
|
||||
"intro": "Nachdem das Profil aufgelöst wurde, führt jedes Backend die gleiche Staging-Pipeline aus, bevor es in seinen eigenen Upload-Pfad divergiert. <code>hb_prepare_staging</code> stellt den Archivbaum in <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> zusammen und füllt jede der drei Nutzlasten aus.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"name": "rootfs zusammenstellen",
|
||||
"detail": "Führt <code>rsync -a</code> für jeden ausgewählten Pfad in <code>staging_root/rootfs/</code> aus. Die pmxcfs-Datenbank bei <code>/var/lib/pve-cluster/config.db</code> wird separat über <code>sqlite3 .backup</code> erfasst, um einen konsistenten Snapshot zu erstellen, ohne den Cluster zu stoppen, und die <code>.db-wal</code> / <code>.db-shm</code> Sidecars sind vom rsync ausgeschlossen; Wenn <code>sqlite3</code> nicht verfügbar ist, wird stattdessen eine Datei <code>config.db.raw-fallback</code> abgelegt, die bei der Wiederherstellung während des Imports als Datenbank übernommen wird. Flüchtige Subpfade (Bash-Historie, Caches, Trash) sind von <code>/root/</code> ausgeschlossen. Pfade, die in der Quelle fehlen, werden in <code>metadata/missing_paths.txt</code> aufgezeichnet, ohne das Backup zu stoppen."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"name": "Manifest erstellen",
|
||||
"detail": "<code>build_manifest.sh</code> steuert die sechs Datensammler und schreibt <code>manifest.json</code> in das Hauptverzeichnis des Staging-Bereichs. Fällt ein Datensammler aus, erhält der betroffene Abschnitt einen dokumentierten leeren Standardwert; das Manifest bleibt gültig."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"name": "Paketbestand",
|
||||
"detail": "<code>apt-mark showmanual</code> wird wortwörtlich in <code>metadata/packages.manual.list</code> erfasst. Der Komponentenzustand befindet sich bereits innerhalb der wiederhergestellten Rootfs (<code>components_status.json</code>), da <code>/usr/local/share/proxmenux/</code> Teil des Standardprofils ist."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"name": "Informationen zum Durchlauf",
|
||||
"detail": "<code>metadata/run_info.env</code> zeichnet die Backup-Laufidentität (Hostname, Zeitstempel, Kernelversion) auf, die von der Kompatibilitätsprüfung der Wiederherstellung zur Bestimmung der kernübergreifenden Richtung verwendet wird."
|
||||
},
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Mitteilung (Beginn)",
|
||||
"detail": "<code>hb_notify_lifecycle \"start\"</code> wird ausgelöst. Sind im Monitor Benachrichtigungen konfiguriert, wird das Ereignis <em>Host-Backup gestartet</em> für den Benutzer ausgegeben. Ohne konfigurierte Kanäle erfolgt keine Benachrichtigung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"included": {
|
||||
"heading": "Was reingeht und was draußen bleibt",
|
||||
"intro": "Jeder Pfad im aufgelösten Profil (Standard + persistente Extras + Custom-Mode-Auswahl) wird mit <code>rsync -aAXH --numeric-ids</code> kopiert. Eine gemeinsame Ausschlussliste gilt für jeden Pfad, und zwei Verzeichnisse tragen zusätzliche pfadspezifische Ausschlüsse.",
|
||||
"globalTitle": "Globale Ausschlüsse (auf jeden Pfad angewendet)",
|
||||
"globalItems": [
|
||||
"<code>images/</code> — Image Dumps.",
|
||||
"<code>dump/</code> — Ausgaben von vzdump.",
|
||||
"<code>tmp/</code> — temporäre Dateien.",
|
||||
"<code>*.log</code> — Protokolldateien."
|
||||
],
|
||||
"rootTitle": "<code>/root/</code> Ausschlüsse",
|
||||
"rootBody": "<code>/root/</code> ist Teil des Standardprofils, sodass Benutzerskripte und Konfigurationen im Archiv landen. Flüchtige Subpfade werden fallen gelassen:",
|
||||
"rootItems": [
|
||||
"<code>.bash_history</code>",
|
||||
"<code>.cache/</code>",
|
||||
"<code>tmp/</code>",
|
||||
"<code>.local/share/Trash/</code>"
|
||||
],
|
||||
"proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code> Ausschlüsse",
|
||||
"proxmenuxBody": "Dieses Verzeichnis liefert nur Benutzerstatus - <code>components_status.json</code>, Einstellungen, Cache nach der Installation. Code, den das Ziel bereits von seiner eigenen ProxMenux-Installation haben wird, ist ausgeschlossen, so dass eine Wiederherstellung die aktuellen Binärdateien des Ziels nicht mit älteren überschreibt:",
|
||||
"proxmenuxItems": [
|
||||
"<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
|
||||
"<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
|
||||
"<code>images/</code>, <code>json/</code>",
|
||||
"<code>utils.sh</code>, <code>helpers_cache.json</code>",
|
||||
"<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
|
||||
],
|
||||
"notInProfileTitle": "Pfade außerhalb des Profils",
|
||||
"notInProfileBody": "Alles, was nicht in <code>hb_default_profile_paths</code> aufgeführt ist und nicht als benutzerdefiniertes oder persistentes Extra hinzugefügt wurde, ist nicht Teil des Backups. Bemerkenswerte Beispiele:",
|
||||
"notInProfileItems": [
|
||||
"<strong>VM und LXC Festplatten</strong> — werden von <code>vzdump</code> behandelt, nicht von dieser Funktion. Gastkonfigurationsdateien unter <code>/etc/pve/nodes/*/qemu-server/*.conf</code> und <code>lxc/*.conf</code> werden erfasst (sie leben unter <code>/etc/pve</code>), so dass die Wiederherstellung das Inventar reproduziert; die Festplatten selbst werden von einem vorhandenen vzdump / PBS-Backup neu angehängt.",
|
||||
"<strong><code>/boot</code> und <code>/boot/efi</code></strong> — Kernel-Binärdateien, Initramfs und die UEFI-ESP-Partition werden nach der Wiederherstellung durch die eigenen <code>update-initramfs</code>, <code>update-grub</code> oder <code>proxmox-boot-tool refresh</code> des Ziels regeneriert. Der Bootloader wird niemals wörtlich kopiert.",
|
||||
"<strong>Kernel und Systemlaufzeit-Dateisysteme</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> und <code>/run</code> sind Pseudo-Dateisysteme, die vom Kernel und von udev erzeugt werden; sie werden nirgendwo persistent.",
|
||||
"<strong>Paket-Binärdateien unter <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — vom APT des Ziels aus <code>packages.manual.list</code> neu installiert.",
|
||||
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — Laufzeitzustand pro Host, nicht wiederhergestellt.",
|
||||
"<strong><code>/home/USER</code></strong> — nicht im Standardprofil. Fügen Sie es als benutzerdefinierten Pfad hinzu, wenn ein System Heimverzeichnisse des Benutzers trägt, die eine Wiederherstellung überleben müssen."
|
||||
],
|
||||
"customPathsTitle": "Wie benutzerdefinierte Pfade gehandhabt werden",
|
||||
"customPathsBody": "Ein benutzerdefinierter Pfad, der im benutzerdefinierten Modus hinzugefügt wurde oder in <code>backup-extra-paths.txt</code> persistiert wurde, durchläuft dieselbe <code>rsync</code>-Pipeline wie Standardprofilpfade. Globale Ausschlüsse gelten. Wenn der benutzerdefinierte Pfad unter <code>/root/</code> oder <code>/usr/local/share/proxmenux/</code> liegt, gelten die oben genannten pfadspezifischen Ausschlüsse weiterhin. Jeder archivierte Pfad – standardmäßig oder benutzerdefiniert – wird in <code>metadata/paths_archived.txt</code> aufgezeichnet. Pfade, die in der Quelle nicht vorhanden sind, werden in <code>metadata/missing_paths.txt</code> aufgezeichnet, ohne das Backup zu stoppen."
|
||||
},
|
||||
"archiveStructure": {
|
||||
"heading": "Archivstruktur",
|
||||
"intro": "Das von jedem Backend erstellte Staging-Verzeichnis folgt unabhängig vom Ziel dem gleichen Layout. Das Tarball-, PBS <code>.pxar</code> oder Borg-Archiv speichert diesen Baum wortwörtlich.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│ ├── packages.manual.list # output of apt-mark showmanual\n│ ├── run_info.env # hostname, timestamp, kernel version, pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n ├── root/ # /root without volatile subpaths\n ├── usr/local/ # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
|
||||
},
|
||||
"confirmation": {
|
||||
"heading": "Bestätigungszusammenfassung",
|
||||
"body": "Bevor das Backend etwas an das Ziel schreibt, zeigt ProxMenux einen zusammenfassenden Dialog mit dem Ziel, der Backup-ID oder dem Archivnamen, dem Verschlüsselungsstatus und der Liste der zu kopierenden Pfade an. Das Abbrechen hier bricht das Backup sauber ab - das Staging-Verzeichnis wird durch den <code>trap</code>-Hook entfernt, der auf der Backend-Funktion eingestellt ist, und keine Teildaten erreichen das Ziel."
|
||||
},
|
||||
"writing": {
|
||||
"heading": "Schreiben an den Bestimmungsort",
|
||||
"intro": "Sobald der Benutzer bestätigt, führt jedes Backend seinen eigenen Schreibschritt aus. Die Mechanik wird auf den Zielseiten behandelt; die gemeinsame Oberfläche ist das Protokoll, das Sidecar und die Abschlussbenachrichtigung.",
|
||||
"rows": [
|
||||
{
|
||||
"topic": "Protokolldatei",
|
||||
"detail": "Jedes Backend schreibt seine vollständige Ausgabe in <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> und bietet bei Ausfall an, sie in einem scrollbaren Dialog zu öffnen. Der Protokollpfad wird in der Abschlusszusammenfassung nur dann gedruckt, wenn die Datei Inhalt hat."
|
||||
},
|
||||
{
|
||||
"topic": "Begleitdatei (nur lokal)",
|
||||
"detail": "<code>hb_write_archive_sidecar</code> legt einen <code>*.proxmenux.json</code> neben das lokale Archiv, so dass der Monitor ihn als ProxMenux-Host-Backup auch nach Umzügen oder Umbenennungen identifiziert."
|
||||
},
|
||||
{
|
||||
"topic": "Benachrichtigung (Abschluss/Fehler)",
|
||||
"detail": "<code>hb_notify_lifecycle \"complete\"</code> oder <code>\"fail\"</code> wird mit Dauer, Archivgröße und — bei Fehlern — der letzten nach einem Fehler aussehenden Protokollzeile ausgelöst."
|
||||
}
|
||||
]
|
||||
},
|
||||
"finishedScreens": {
|
||||
"heading": "Wie ein fertiges Backup aussieht",
|
||||
"intro": "Das gleiche Abschlussereignis wird an beiden Einstiegspunkten angezeigt. Die TUI schreibt einen Zusammenfassungsblock in das Terminal; die Registerkarte Backups des Monitors zeigt den Ablauf in der Archivliste mit Größe, Dauer und Statusabzeichen an.",
|
||||
"scriptsAlt": "ProxMenux Scripts TUI zeigt ein fertiges Host-Backup an - Ziel, Backup-ID, Snapshot-Pfad, Datengröße, Dauer und Verschlüsselungszustand.",
|
||||
"scriptsCaption": "Abgeschlossenes Backup — ProxMenux Scripts (TUI). Der Vervollständigungsblock druckt das Ziel, die Backup-ID, den resultierenden Snapshot- oder Archivnamen, die Datengröße, die Dauer und den Verschlüsselungszustand.",
|
||||
"monitorAlt": "Die Registerkarte ProxMenux Monitor Backups zeigt einen fertigen Host-Backup-Eintrag mit Größe, Dauer, Methodenabzeichen und Verschlüsselungsindikator.",
|
||||
"monitorCaption": "Abgeschlossenes Backup — ProxMenux Monitor Backups Registerkarte. Das neue Backup erscheint in der Archivliste mit dem Zielmethode-Badge, der Größe, der Dauer und gegebenenfalls dem Verschlüsselungssperrindikator."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "— Konfigurationsdetails für Local, PBS und Borg."
|
||||
},
|
||||
{
|
||||
"label": "Geplante Aufträge",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "- das gleiche Backup unbeaufsichtigt nach einem Zeitplan anstatt interaktiv auszuführen."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— der Fluss, der verbraucht, was diese Seite produziert."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Wiederherstellung zwischen Kernel-Versionen — Richtungserkennung, Sicherheitsfilter und Ergänzung | ProxMenux",
|
||||
"description": "Wie ProxMenux ein Host-Backup auf einem Ziel mit einer anderen Hauptkernelversion wiederherstellt. Dokumentiert, wie die Richtung der Fehlanpassung erkannt wird, den Safe-Subset-Filter, der bootkritische Pfade überspringt, wenn das Ziel einen neueren Kernel als das Backup ausführt, und die vierphasige Kernel-agnostische Hydratation, die Benutzertuning wie IOMMU, VFIO IDs und benutzerdefinierte Cmdline-Token erneut anwendet, ohne Kernel-gebundene Dateien wörtlich zu kopieren.",
|
||||
"ogTitle": "ProxMenux Backup — kernübergreifende Wiederherstellung und Hydratation",
|
||||
"ogDescription": "Wiederherstellung zwischen Kernel-Versionen mit Richtungserkennung, sicherer Pfadauswahl und kernelunabhängiger Ergänzung.",
|
||||
"twitterTitle": "Cross-Kernel-Wiederherstellung | ProxMenux",
|
||||
"twitterDescription": "Wie ProxMenux eine Wiederherstellung durchführt, wenn sich der Zielkernel vom Backup unterscheidet."
|
||||
},
|
||||
"header": {
|
||||
"title": "Kernübergreifende Wiederherstellung",
|
||||
"description": "Wie ProxMenux eine Wiederherstellung durchführt, wenn der Zielhost einen anderen Kernel als den im Backup aufgezeichneten ausführt - insbesondere wenn das Ziel einen neueren Kernel ausführt. Dokumentiert, wie der Unterschied erkannt wird, wie bootkritische Pfade, die das Ziel unterbrechen könnten, gefiltert werden und wie die eigene Konfiguration des Benutzers erneut angewendet wird, ohne Kernel-gebundene Dateien wörtlich zu kopieren.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Jeder Kernelsprung wird anders gehandhabt",
|
||||
"body": "Der Kernel eines Proxmox-Hosts wird durch eine Versionszeichenfolge wie <code>6.17.13-2-pve</code> identifiziert. Die ersten beiden Zahlen (<strong>6.17</strong> in diesem Beispiel) definieren die Hauptversion: Wenn sie sich ändern, sind einige Konfigurationsdateien, die für den vorherigen Kernel geschrieben wurden, möglicherweise nicht für den neuen gültig. Wenn die Wiederherstellung erkennt, dass das Backup und das Ziel unterschiedliche Hauptkernelversionen haben, verzweigt sich der Fluss basierend auf der Richtung des Sprungs - ob das Backup älter oder neuer als das Ziel ist - weil die beiden Fälle entgegengesetzte Fehlermodi haben. Backups, die neuer sind als das Ziel, stellen sauber wieder her, wie sie sind (bench-verifiziert über mehrere Kernelsprünge). Backups, die älter als das Ziel sind, benötigen einen Filter, um zu vermeiden, dass der Boot des Ziels mit einer Konfiguration unterbrochen wird, die für einen Kernel geschrieben wurde, der sich seitdem geändert hat."
|
||||
},
|
||||
"directionCheck": {
|
||||
"heading": "Die Richtungskontrolle",
|
||||
"intro": "Während der Kompatibilitätsprüfung vergleicht <code>hb_compat_check</code> den im Backup-Manifest aufgezeichneten Kernel mit dem aktuellen Kernel des Ziels (<code>uname -r</code>) und klassifiziert die Wiederherstellung in einen von drei Fällen, die in der internen Variable <code>HB_COMPAT_KERNEL_DIRECTION</code> gespeichert sind:",
|
||||
"rows": [
|
||||
{
|
||||
"direction": "same",
|
||||
"condition": "Die Hauptkernelversion stimmt zwischen Backup und Target überein.",
|
||||
"behavior": "Der vollständige Restaurationsfluss läuft unverändert. Kein extra Filter, keine Hydratation, kein besonderer Hinweis in der UI."
|
||||
},
|
||||
{
|
||||
"direction": "bk_newer",
|
||||
"condition": "Der Backup-Kernel ist NEUER als der des Ziels (zum Beispiel: Das Backup wurde auf dem Kernel 7.0 erstellt und das Ziel führt den Kernel 6.17 aus).",
|
||||
"behavior": "Der vollständige Wiederherstellungsfluss läuft unverändert, genau wie <code>same</code>. Es wird kein Filter angewendet. Empirisch verifiziert: Treiber werden automatisch gegen den Zielkernel neu installiert, IOMMU config wird sauber angewendet, VMs mit GPU-Durchgang kommen ohne Probleme auf."
|
||||
},
|
||||
{
|
||||
"direction": "bk_older",
|
||||
"condition": "Der Backup-Kernel ist älter als der des Ziels (zum Beispiel: Das Backup wurde auf dem Kernel 6.17 erstellt und das Ziel führt den Kernel 7.0 aus).",
|
||||
"behavior": "Der Safe-Subset-Filter und die folgende vierphasige Hydratation werden aktiviert. Die Wiederherstellung geht weiter - das Ziel reproduziert die Quelle, aber bootkritische Dateien werden nicht wörtlich kopiert."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyBkNewerIsSafe": {
|
||||
"heading": "Warum ein Backup mit einem neueren Kernel als das Ziel unverändert wiederherstellt",
|
||||
"body": "Wenn die Wiederherstellung gegen ein Ziel mit einem <em>älteren</em>-Kernel als dem im Backup aufgezeichneten läuft, ist jeder Mechanismus, von dem die Wiederherstellung abhängt, unabhängig von der Kernelversion. GPU-Treiberinstallateure und andere PCI-Geräteinstallateure erkennen den laufenden Kernel mit <code>uname -r</code> und kompilieren DKMS mit dem, was das Ziel hat. Die APT-Paketinstallation zieht Binärdateien, die für die Verteilung des Ziels erstellt wurden. IOMMU-Cmdline-Token wie <code>intel_iommu=on</code> sind in den wichtigsten Kernelversionen stabil. Das Backup trägt Pfade, die unter einem neueren Kernel geschrieben wurden, aber diese Pfade (Module Blacklists, GRUB Defaults, Initramfs Config) sind immer noch gültige Syntax auf dem älteren - Kernel ignorieren Token, die sie nicht erkennen, anstatt zu scheitern. Dieser Fall entspricht in der Praxis einer Wiederherstellung des gleichen Kerns, und ProxMenux behandelt ihn als solchen."
|
||||
},
|
||||
"safeSubsetFilter": {
|
||||
"heading": "Der Safe-Subset-Filter (nur wenn der Zielkernel neuer ist)",
|
||||
"intro": "Wenn der Zielkernel neuer ist als das Backup, fügt die Kompatibilitätsprüfung 16 bootkritische Pfade von <code>hb_unsafe_paths_cross_version</code> zu <code>RS_SKIP_PATHS</code> hinzu. Diese Pfade sind von der Wiederherstellung ausgeschlossen, da das Schreiben einer Version von ihnen aus einem älteren Kernel über ein Ziel mit einem neueren Kernelpanik in Bench-Tests verursacht hat. Die Pfade umfassen fünf Kategorien:",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "Bootloader",
|
||||
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
|
||||
"reason": "GRUB-Standards, die an die vorherige Kernel-Order gebunden sind, und proxmox-boot-tool-Status (cmdline, ESP-UUIDs, Hooks), der auf Pfade und Identifikatoren aus der älteren Installation verweist."
|
||||
},
|
||||
{
|
||||
"category": "Kernelmodule und Bootartefakte",
|
||||
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
|
||||
"reason": "Autoload-Listen, die möglicherweise auf Module verweisen, die zwischen Kernel-Majors umbenannt wurden, Moduloptionen, die möglicherweise nicht gelten, Initramfs-Hooks, die für den älteren Kernel geschrieben wurden."
|
||||
},
|
||||
{
|
||||
"category": "Storage Stack und Filesystem Identität",
|
||||
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
|
||||
"reason": "UUIDs, die in dieser Installation möglicherweise nicht vorhanden sind, Multipath-Treiber, die zwischen Kerneln wechseln, iSCSI-Parameter, die sich entwickeln, udev-Regeln, die an nicht vorhandene Subsysteme binden können, ZFS-Zustand (<code>zpool.cache</code> + <code>hostid</code>), der den Pool als fremd sperren kann."
|
||||
},
|
||||
{
|
||||
"category": "APT-Quellen",
|
||||
"paths": "<code>/etc/apt</code>",
|
||||
"reason": "APT-Source-Suiten können beim nächsten Upgrade ein Downgrade kritischer Pakete auslösen."
|
||||
},
|
||||
{
|
||||
"category": "systemd",
|
||||
"paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
|
||||
"reason": "Unit overrides und .wants, die an den älteren systemd Major gebunden sind; Konfigurationsschlüssel, die möglicherweise nicht auf einem neueren systemd analysiert werden."
|
||||
}
|
||||
],
|
||||
"outroBody": "Der Filter läuft VOR dem Bestätigungsdialog, so dass der Benutzer die genaue Liste der Pfade sieht, die nach dem Grund kategorisiert übersprungen werden. Die Wiederherstellung geht weiter - alles andere (VM-/LXC-Konfiguration, Netzwerk, /etc/pve, Benutzer, cron, ProxMenux-Zustand, Pakete, Treiber, /root) wird normal wiederhergestellt."
|
||||
},
|
||||
"hydration": {
|
||||
"heading": "Kern-agnostische Hydratation",
|
||||
"intro": "Der Filter überspringt bootkritische Dateien; die Ergänzung übernimmt ausgewählte Benutzereinstellungen wie IOMMU-Parameter, VFIO-IDs, eigenes <code>GRUB_TIMEOUT</code> und nvidia-Sperrlisten. Sie läuft bei neuerem Zielkernel. Cmdline-Schlüssel des Ziels bleiben erhalten und fehlende Module werden ergänzt. Freigegebene GRUB-Werte und Benutzerdateien können abweichende Zielinhalte ersetzen. Gleiche Eingaben sind bei Wiederholung idempotent.",
|
||||
"phaseRows": [
|
||||
{
|
||||
"phase": "1a — GRUB-Trasse",
|
||||
"detail": "Für Hosts mit GRUB (ext4/lvm-Installationen). <code>_rs_hyd_grub</code> führt jedes Token aus dem <code>manifest.kernel_params.cmdline_extra</code> des Backups in das <code>GRUB_CMDLINE_LINUX_DEFAULT</code> des Ziels ein und überspringt Token, deren Schlüssel das Ziel bereits trägt. Dann werden die <code>GRUB_*</code>-Schlüssel auf der weißen Liste (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) aus dem <code>/etc/default/grub</code> des Backups zusammengeführt, wenn sie sich von denen des Ziels unterscheiden."
|
||||
},
|
||||
{
|
||||
"phase": "1b — systemd-boot / ZFS",
|
||||
"detail": "Für Hosts mit systemd-Boot (normalerweise ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> verschmilzt Benutzer-Token von <code>cmdline_extra</code> in <code>/etc/kernel/cmdline</code> des Ziels, wobei die eigene <code>root=</code>, <code>boot=</code> und <code>rootflags=</code> Boilerplate des Ziels intakt bleibt."
|
||||
},
|
||||
{
|
||||
"phase": "2 — /etc/modules-Merge",
|
||||
"detail": "<code>_rs_hyd_modules</code> fügt Module aus <code>manifest.kernel_params.modules_loaded_at_boot</code> hinzu, die sich in der Whitelist befinden (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) UND nicht bereits im <code>/etc/modules</code> des Ziels vorhanden sind."
|
||||
},
|
||||
{
|
||||
"phase": "3 — Kopie von Dateien auf der weißen Liste",
|
||||
"detail": "<code>_rs_hyd_files</code> kopiert vom Benutzer verfasste Dateien von den Staging-Rootfs zum Live-Ziel, wenn sich der Inhalt unterscheidet. Whitelist umfasst VFIO/nvidia / Blacklist-Dateien unter <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code> und die ProxMenux VFIO Binderegel + nvidia udev Regeln unter <code>/etc/udev/rules.d</code>. Distro-eigene Dateien (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) werden absichtlich ausgeschlossen - ihre Inhalte entwickeln sich zwischen den Releases."
|
||||
},
|
||||
{
|
||||
"phase": "4 — Neubildung nach dem Booten erzwingen",
|
||||
"detail": "Die vier Phasen schreiben direkt an das Live-Ziel außerhalb der normalen Wiederherstellungspipeline. Damit die zusammengeführten Token/Module/Dateien beim nächsten Booten wirksam werden, breitet sich <code>HB_HYDRATION_APPLIED=1</code> durch <code>plan.env</code> bis <code>apply_pending_restore.sh</code> aus, was <code>NEEDS_INITRAMFS=1</code> und <code>NEEDS_GRUB=1</code> unabhängig davon erzwingt, was in der Anwendungsliste war. Der Post-Boot-Dispatcher regeneriert dann Initramfs und aktualisiert den Bootloader."
|
||||
}
|
||||
]
|
||||
},
|
||||
"planCommit": {
|
||||
"heading": "Plan vs Commit - der Benutzer sieht zuerst eine Vorschau",
|
||||
"body": "Die Hydratation läuft in zwei Modi. Vor dem Bestätigungsdialog führt ProxMenux <code>_rs_apply_bk_older_hydration</code> im <code>plan</code>-Modus aus: Es berechnet genau, was zusammengeführt werden würde, füllt <code>RS_HYDRATION_SUMMARY</code> mit einem grünen Block, der jede Aktion auflistet, und gibt ohne zu schreiben zurück. Der Bestätigungsdialog zeigt den grünen Block neben der gelben Liste der durch den Sicherheitsfilter übersprungenen Pfade an, sodass der Benutzer VORAB sieht, was automatisch erneut angewendet wird. Nachdem der Benutzer bestätigt hat, führt ProxMenux den gleichen Helfer im <code>commit</code>-Modus erneut aus - gleiche Phasen, gleiche Logik, aber dieses Mal schreibt jede Phase an das Live-Ziel. Das Abbrechen des Bestätigungsdialogs lässt das Ziel unberührt."
|
||||
},
|
||||
"flowDiagram": {
|
||||
"heading": "Der Flow, wenn der Zielkernel neuer ist als das Backup",
|
||||
"intro": "Die Schritte, die hinzugefügt werden, wenn der Zielkernel neuer ist, befinden sich innerhalb des normalen Wiederherstellungsflusses. Alles andere - heißes Aufbringen, ausstehende Vorbereitung, Paketinstallation, Post-Boot-Dispatcher - läuft identisch mit einer Wiederherstellung mit dem gleichen Kern.",
|
||||
"diagram": " ┌────────────────────────────────────────────────────────────┐\n │ hb_compat_check │\n │ HB_COMPAT_KERNEL_DIRECTION = bk_older │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Add 16 boot-critical paths to RS_SKIP_PATHS │\n │ /etc/default/grub, /etc/kernel, /etc/modules-load.d, ... │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"plan\" │\n │ Compute what would be merged │\n │ Populate RS_HYDRATION_SUMMARY (green block) │\n │ No writes │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Confirmation dialog │\n │ Amber: paths skipped by safe-subset filter │\n │ Green: tokens/files reapplied by hydration │\n │ User accepts or cancels │\n └───────────────────────────┬────────────────────────────────┘\n │ (accepted)\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ _rs_apply_bk_older_hydration \"commit\" │\n │ Phase 1a/1b: merge cmdline tokens + GRUB keys │\n │ Phase 2: append modules to /etc/modules │\n │ Phase 3: copy whitelisted vfio/nvidia files │\n │ Set HB_HYDRATION_APPLIED=1 │\n └───────────────────────────┬────────────────────────────────┘\n │\n ▼\n ┌────────────────────────────────────────────────────────────┐\n │ Rest of the restore runs normally │\n │ _rs_apply hot (skips RS_SKIP_PATHS) │\n │ _rs_prepare_pending_restore (writes plan.env with │\n │ HB_HYDRATION_APPLIED=1) │\n │ packages.manual.list install │\n │ Reboot │\n │ apply_pending_restore.sh (forces NEEDS_INITRAMFS=1, │\n │ NEEDS_GRUB=1 because of the hydration flag) │\n │ apply_cluster_postboot.sh │\n │ update-initramfs -u -k all │\n │ update-grub / proxmox-boot-tool refresh │\n │ component --auto-reinstall │\n └────────────────────────────────────────────────────────────┘"
|
||||
},
|
||||
"concreteExamples": {
|
||||
"heading": "Konkrete Beispiele",
|
||||
"intro": "Der Hydratationspass ist nicht abstrakt - er erzeugt beobachtbare, korrekte Ergebnisse für gängige Szenarien. Zwei Beispiele, die Hydratation automatisch handhaben:",
|
||||
"rows": [
|
||||
{
|
||||
"scenario": "GPU-Durchgang (VFIO)",
|
||||
"detail": "Quelle hatte <code>intel_iommu=on iommu=pt</code> in der cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, ein <code>/etc/modprobe.d/vfio.conf</code> mit <code>options vfio-pci ids=10de:2216</code> und ein <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration führt die Cmdline-Token in die GRUB- oder Kernel-Cmdline des Ziels ein, fügt die vfio-Module an <code>/etc/modules</code> an und kopiert die beiden vom Benutzer verfassten Modprobe-Dateien. Beim nächsten Booten ist IOMMU aktiv, VFIO-Module laden, der GPU ist an vfio-pci gebunden und der VM hat Passthrough-Funktionen."
|
||||
},
|
||||
{
|
||||
"scenario": "Custom GRUB-Standards",
|
||||
"detail": "Quelle hatte <code>GRUB_TIMEOUT=1</code> und <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration liest beide Schlüssel aus dem <code>/etc/default/grub</code> des Backups und sieht, dass sie sich von den Standardeinstellungen der Neuinstallation unterscheiden, und schreibt diese beiden Zeilen in der Zieldatei um (alles andere, einschließlich <code>GRUB_DISTRIBUTOR</code>, bleibt unberührt)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"warningTitle": "Was bei neuerem Zielkernel nicht erneut angewendet wird",
|
||||
"warningBody": "Hydration wendet nur die Konfiguration ProxMenux an, von der bekannt ist, dass sie in Kernelversionen sicher ist: IOMMU-Token, VFIO-IDs, GRUB-Schlüssel auf der weißen Liste und Module aus einer festen Liste (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Alles außerhalb dieses Sets - benutzerdefinierte Initramfs-Hooks unter <code>/etc/initramfs-tools/hooks/</code>, nicht auf der weißen Liste stehende Dateien unter <code>/etc/modprobe.d/</code>, vom Benutzer verfasste systemd-Unit-Overrides - bleibt ausgeschlossen. Der Grund dafür ist konkret: Diese Dateien können Kernel-interne Schnittstellen (Modul-APIs, <code>/sys</code>-Layout, <code>udev</code>-Hooks) aufrufen, die zwischen den Hauptversionen wechseln, und ihre wörtliche Anwendung auf den neueren Kernel kann das Booten des Ziels verhindern. Wenn eine exakte Reproduktion der Bootkette erforderlich ist, muss die Wiederherstellung auf einem Host mit der gleichen Hauptkernelversion wie das Backup ausgeführt werden."
|
||||
},
|
||||
"codeReference": {
|
||||
"heading": "Wo die Mechanismen leben",
|
||||
"intro": "Für Entwickler, die das Cross-Kernel-Verhalten verfolgen oder erweitern möchten:",
|
||||
"rows": [
|
||||
{
|
||||
"component": "Richtungserkennung",
|
||||
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Setzt <code>HB_COMPAT_KERNEL_DIRECTION</code>."
|
||||
},
|
||||
{
|
||||
"component": "Liste sicherer Teilstrecken",
|
||||
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Sendet <code>path\\treason</code>-Linien aus, die sowohl vom CLI-Filter als auch vom Web-Endpunkt <code>/api/host-backups/restore/prepare</code> verwendet werden."
|
||||
},
|
||||
{
|
||||
"component": "Hydratationsphasen",
|
||||
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> in <code>backup_host.sh</code>. Orchestriert von <code>_rs_apply_bk_older_hydration</code>."
|
||||
},
|
||||
{
|
||||
"component": "Neubildung nach dem Booten erzwingen",
|
||||
"location": "<code>apply_pending_restore.sh</code> liest <code>HB_HYDRATION_APPLIED</code> von <code>plan.env</code> und zwingt <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
|
||||
},
|
||||
{
|
||||
"component": "Web Preview",
|
||||
"location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Lädt die Hilfsbibliothek, führt <code>_rs_apply_bk_older_hydration</code> im Planmodus aus und gibt die Aktionen an den Webmodal zurück."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "— die vollständige Wiederherstellungspipeline der Mechanismen dieser Seite."
|
||||
},
|
||||
{
|
||||
"label": "Wie es funktioniert",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — Manifest und Erfassungsroutinen, die den von der Ergänzung gelesenen Block <code>kernel_params</code> erzeugen."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,234 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Borg-Ziel — Repository-Typen, SSH-Authentifizierung, Verschlüsselung | ProxMenux",
|
||||
"description": "Das Borg-Ziel speichert ProxMenux-Host-Backups in einem Borg-Repository: lokal, auf einem eingehängten externen Datenträger oder auf einem per SSH erreichbaren Server. Beschrieben werden die Suche nach der ausführbaren borg-Datei, die vier anfänglichen SSH-Schlüsseloptionen, repokey-Verschlüsselung, gespeicherte Ziele und Aufbewahrungsregeln je geplantem Auftrag.",
|
||||
"ogTitle": "ProxMenux Backup — Zielort Borg",
|
||||
"ogDescription": "So speichert ProxMenux Host-Backups in Borg-Repositories mit SSH-Authentifizierung und repokey-Verschlüsselung.",
|
||||
"twitterTitle": "Borg Backup Ziel | ProxMenux",
|
||||
"twitterDescription": "Lokale, USB- und SSH-gestützte Borg-Repositories für Host-Backups."
|
||||
},
|
||||
"header": {
|
||||
"title": "Borg",
|
||||
"description": "Das Borg-Ziel schreibt Host-Backups in ein Borg-Repository. Es werden drei Repository-Typen unterstützt: lokaler Dateisystempfad, eingehängte externe Festplatte oder Remote-Server über SSH. Chunk-Level-Deduplizierung über alle Archive im Repository und optionale Repokey-Verschlüsselung.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"aboutBorg": {
|
||||
"heading": "Was Borg ist",
|
||||
"body": "Borg (auch BorgBackup geschrieben) ist ein Open-Source-Deduplizierungs-Backup-Tool, das von der Borg Backup-Community verwaltet wird. Es speichert jedes Archiv als eine Reihe von Blöcken variabler Länge in einem Repository; Blöcke werden über Archive hinweg geteilt, so dass das erneute Sichern unveränderter Daten nahezu Null Speicherkosten verursacht. Borg ist nicht an Proxmox gebunden - es ist ein universelles Backup-Tool, das in vielen Umgebungen verwendet wird. ProxMenux verwendet es als eines der drei Ziele für Host-Backups; jeder auf dieser Seite beschriebene Borg-spezifische Mechanismus (Repository-Typen, borg-serve über SSH, Repokey-Verschlüsselung, prune) ist Standard-Borg-Verhalten."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Chunk-basierte Deduplizierung mit lokalen oder SSH-servierten Repositorys",
|
||||
"body": "Ein Borg-Repository speichert Brocken, die in jedem enthaltenen Archiv geteilt werden, so dass das erneute Sichern einer unveränderten Datei nichts Neues überträgt und speichert. ProxMenux ruft <code>borg create</code> zum Backup-Zeitpunkt und <code>borg extract</code> zum Wiederherstellungszeitpunkt gegen ein Repository auf. Das Repository kann auf demselben Dateisystem wie die Quelle, auf einer montierten externen Festplatte oder auf einem Remote-Host, auf den über SSH zugegriffen wird, leben."
|
||||
},
|
||||
"binarySourcing": {
|
||||
"heading": "Die ausführbare borg-Datei",
|
||||
"intro": "Borg ist keine Basisabhängigkeit des ProxMenux-Installationsprogramms. Wenn ein Backup ausgeführt wird, löst <code>hb_ensure_borg</code> die Binärdatei in der Reihenfolge aus vier Quellen auf und gibt die erste zurück, die funktioniert:",
|
||||
"rows": [
|
||||
{
|
||||
"priority": "1",
|
||||
"source": "Systemweites <code>borg</code>",
|
||||
"detail": "Wenn der Host bereits <code>borg</code> über APT installiert hat (<code>which borg</code> löst auf), wird diese Binärdatei verwendet."
|
||||
},
|
||||
{
|
||||
"priority": "2",
|
||||
"source": "State-Dir-Cache",
|
||||
"detail": "<code>/usr/local/share/proxmenux/borg</code> — aus einem früheren GitHub-Download auf diesem Host aufbewahrt."
|
||||
},
|
||||
{
|
||||
"priority": "3",
|
||||
"source": "AppImage-Paket des Monitors",
|
||||
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — der AppImage bündelt einen signierten borg-linux64. Dies ist der offline-sichere Pfad: Ein Host ohne Internet hat immer noch einen funktionierenden <code>borg</code>."
|
||||
},
|
||||
{
|
||||
"priority": "4",
|
||||
"source": "GitHub Download",
|
||||
"detail": "<code>wget</code> gegen die angepinnte <code>borg-linux64</code>-URL unter <code>github.com/borgbackup/borg/releases/</code>, verifiziert gegen eine Konstante SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). Bei Checksummenfehlanpassung wird die Binärdatei verworfen und das Backup abgebrochen. Die heruntergeladene Datei wird im State Dir zwischengespeichert, so dass nachfolgende Backups den Pfad 2 verwenden."
|
||||
}
|
||||
]
|
||||
},
|
||||
"repoTypes": {
|
||||
"heading": "Repository-Typen",
|
||||
"intro": "Der Repository-Typ wird ausgewählt, wenn ein Ziel hinzugefügt wird. Jeder Typ löst sich in einer anderen Repository-URL auf, die Borg versteht.",
|
||||
"rows": [
|
||||
{
|
||||
"type": "remote",
|
||||
"url": "ssh://USER@HOST/RPATH",
|
||||
"detail": "Repository lebt auf einem Remote-Server, auf dem <code>borg serve</code> ausgeführt wird. Erfordert eine SSH-Verbindung zu diesem Server."
|
||||
},
|
||||
{
|
||||
"type": "usb",
|
||||
"url": "/mnt/MOUNTPOINT/borgbackup",
|
||||
"detail": "Repository lebt auf einer montierten externen Festplatte (normalerweise USB). Die Mount wird über <code>hb_prompt_mounted_path</code> aufgelöst, das USB-Partitionen nach Bedarf erkennt, einhängt oder formatiert."
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "Repository lebt in einem lokalen Verzeichnis. Bedeutsam nur, wenn sich das Zielverzeichnis auf einer separaten physischen Festplatte befindet – ein Repository auf derselben Festplatte wie die Quelle schützt vor Operatorfehlern, aber nicht vor Festplattenausfällen."
|
||||
}
|
||||
]
|
||||
},
|
||||
"serverSetup": {
|
||||
"heading": "Vorbereitung des Borg-Servers (Serverseite)",
|
||||
"intro": "Der Repository-Typ <code>remote</code> setzt einen funktionierenden, per SSH erreichbaren Borg-Server voraus. ProxMenux richtet den Server nicht selbst ein; es autorisiert nur einen Schlüssel für ein vorhandenes Konto. Dieser Abschnitt beschreibt, was der Server vor der Verbindung benötigt.",
|
||||
"hostChoicesTitle": "Wo der Server leben kann",
|
||||
"hostChoicesBody": "Jeder Linux-Host mit SSH-Zugang ist qualifiziert. Gemeinsame Setups:",
|
||||
"hostChoicesItems": [
|
||||
"Eine dedizierte NAS- oder Backup-Box (Debian, Ubuntu, TrueNAS SCALE mit einer Shell).",
|
||||
"Ein LXC Container in einem Proxmox Knoten. Kleiner Footprint, isoliert vom Host, der die Backups ausführt.",
|
||||
"Ein anderer Proxmox-Host im selben LAN oder ein VM, der über SSH erreichbar ist."
|
||||
],
|
||||
"lxcWarningTitle": "LXC als Borg-Server",
|
||||
"lxcWarningBody": "Läuft der Borg-Server in einem LXC, benötigt generate-auto zur Schlüsselinstallation ein Konto, das SSH-Passwortanmeldung erlaubt. Ist diese nicht verfügbar, verwenden Sie die manuelle Installation oder generate-pct über den PVE-Host.",
|
||||
"requirementsTitle": "Anforderungen an den Server",
|
||||
"requirementsRows": [
|
||||
{
|
||||
"requirement": "Ausführbare borg-Datei unter <code>/usr/bin/borg</code>",
|
||||
"detail": "Die Zeile <code>command=\"/usr/bin/borg serve ...\"</code>, die ProxMenux in <code>authorized_keys</code> einträgt, verwendet diesen festen Pfad. APT (<code>apt install borgbackup</code>) installiert das Programm dort. Für eine separat installierte Binärdatei ist ein symbolischer Link unter <code>/usr/bin/borg</code> nötig."
|
||||
},
|
||||
{
|
||||
"requirement": "Ein dediziertes Benutzerkonto (normalerweise <code>borg</code>)",
|
||||
"detail": "Besitzt das Repository-Verzeichnis und empfängt eingehende SSH-Verbindungen. Benötigt keinen sudo- oder shell-zugriff - die authorized_keys-linie deaktiviert interaktive shells sowieso."
|
||||
},
|
||||
{
|
||||
"requirement": "Ein beschreibbares Repository Verzeichnis",
|
||||
"detail": "Der vom Betreiber angegebene Pfad ProxMenux (z. B. <code>/backup/borgbackup</code>) muss auf dem Server vorhanden sein und im Besitz des borg-Benutzers sein."
|
||||
},
|
||||
{
|
||||
"requirement": "SSH Daemon akzeptiert den Borg-Benutzer",
|
||||
"detail": "<code>PubkeyAuthentication yes</code> (Standard). Die Passwort-Authentifizierung wird nur für den One-Shot <em>generate-auto</em>-Flow benötigt – nachdem der Schlüssel installiert wurde, kann der Server das Passwort auth vollständig deaktivieren."
|
||||
}
|
||||
],
|
||||
"minimalSetupTitle": "Minimale Server-Einrichtung",
|
||||
"minimalSetupBody": "Auf einem Debian- oder Ubuntu-Borg-Server besteht eine Arbeitsbasislinie aus vier Befehlen als root:",
|
||||
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
|
||||
"minimalSetupNote": "Sind Server und SSH-Passwortanmeldung vorbereitet, installiert <code>generate-auto</code> den Schlüssel über ein Konto mit Schreibzugriff auf die authorized_keys-Datei des borg-Benutzers. Spätere Backups verwenden diesen auf <code>borg serve</code> am konfigurierten Pfad beschränkten Schlüssel. Ohne Passwortanmeldung wird er manuell oder über den PVE-Host installiert."
|
||||
},
|
||||
"sshAuth": {
|
||||
"heading": "SSH-Authentifizierung (Clientseite)",
|
||||
"intro": "Remote-Borg-Repositories sind über SSH zugänglich. Die Verbindung läuft vom ProxMenux-Host zu einem Benutzerkonto auf dem Borg-Server, auf dem <code>borg serve</code> ausgeführt wird. Dieser Benutzer heißt normalerweise <code>borg</code>, NICHT der Admin / Root-Benutzer des Servers - die Befehlszeile borg-serve sperrt die Verbindung zu diesem spezifischen Repository-Pfad (siehe die wichtigsten Strategien unten).",
|
||||
"strategiesTitle": "SSH-Schlüsselstrategien",
|
||||
"strategiesIntro": "Beim Hinzufügen eines entfernten Ziels fragt ProxMenux nach SSH-Benutzer, Host, Port und entferntem Pfad und bietet vier Anmeldeoptionen. Wird die Passwortanmeldung abgewiesen, steht zusätzlich generate-pct zur Wahl. Die Modi sind unten beschrieben:",
|
||||
"strategyRows": [
|
||||
{
|
||||
"mode": "generate-auto",
|
||||
"label": "Empfohlen",
|
||||
"detail": "ProxMenux erzeugt oder verwendet ein ed25519-Schlüsselpaar unter <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>. Mit <code>sshpass</code> prüft es die Anmeldung und installiert den öffentlichen Schlüssel in <code>~borg/.ssh/authorized_keys</code>. Das Passwort gehört zu einem Konto mit Schreibzugriff auf diese Datei, meist root oder borg. Es wird nur bei der Einrichtung verwendet und nicht gespeichert."
|
||||
},
|
||||
{
|
||||
"mode": "generate-manual",
|
||||
"label": "Kein Admin-Passwort auf diesem Host",
|
||||
"detail": "ProxMenux generiert das Keypair wie oben, zeigt aber die vollständige <code>authorized_keys</code>-Zeile an, die der Betreiber manuell in den Server einfügen kann. Das Admin-Passwort verlässt niemals den ProxMenux-Host, weil es nie angefordert wird."
|
||||
},
|
||||
{
|
||||
"mode": "generate-pct",
|
||||
"label": "Borg Server ist ein PVE LXC",
|
||||
"detail": "Der Borg-Server läuft innerhalb eines LXC auf einem PVE-Knoten. ProxMenux autorisiert den Schlüssel über <code>pct exec</code> vom PVE-Host - root auf dem PVE-Host schreibt in den <code>~borg/.ssh/authorized_keys</code> des LXC, ohne dass SSH selbst in den LXC benötigt wird."
|
||||
},
|
||||
{
|
||||
"mode": "existing",
|
||||
"label": "Verwenden Sie einen vorhandenen Schlüssel",
|
||||
"detail": "ProxMenux scannt <code>/root/.ssh/</code> und <code>$HOME/.ssh/</code> nach Parseable ed25519/RSA Private Keys und listet diese auf. Der Bediener wählt einen oder durchsucht manuell einen nicht standardmäßigen Pfad."
|
||||
},
|
||||
{
|
||||
"mode": "none",
|
||||
"label": "Standard SSH-Konfiguration",
|
||||
"detail": "Kein benutzerdefinierter Schlüssel - Borg stützt sich auf die standardmäßige SSH-Konfiguration des Hosts (normalerweise <code>~/.ssh/id_rsa</code> oder ein SSH-Agent)."
|
||||
}
|
||||
],
|
||||
"restrictTitle": "Die authorized_keys Linie",
|
||||
"restrictBody": "Für jeden erzeugten Schlüssel beschränkt die von ProxMenux auf dem Server eingetragene <code>authorized_keys</code>-Zeile den Zugriff auf den folgenden borg-serve-Aufruf für den konfigurierten Repository-Pfad:",
|
||||
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
|
||||
"restrictNote": "Der <code>command=</code> zwingt jede SSH-Sitzung mit diesem Schlüssel, nur den Befehl borg-serve auszuführen; <code>restrict</code> deaktiviert die Portweiterleitung, die Agentenweiterleitung, die X11-Weiterleitung und die PTY-Zuweisung. Der Schlüssel kann nicht verwendet werden, um eine interaktive Shell auf dem Server zu öffnen oder auf einen anderen Repository-Pfad zuzugreifen, selbst wenn das Konto über breitere Privilegien verfügt."
|
||||
},
|
||||
"savedTargets": {
|
||||
"heading": "Gespeicherte Ziele",
|
||||
"intro": "Ein gespeichertes Ziel hält die Repository-Konfiguration unter einem verständlichen Namen fest, damit die Angaben nicht erneut eingegeben werden müssen. Dateien im ProxMenux-Zustandsverzeichnis:",
|
||||
"rows": [
|
||||
{
|
||||
"file": "borg-targets.txt",
|
||||
"content": "Eine Zeile je Ziel: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> liest sie ein, um das Zielauswahlmenü zu füllen."
|
||||
},
|
||||
{
|
||||
"file": "borg-pass-NAME.txt",
|
||||
"content": "Passphrase des oben mit NAME benannten Ziels (<code>chmod 600</code>). Nur bei gewählter repokey-Verschlüsselung vorhanden."
|
||||
}
|
||||
],
|
||||
"outro": "Das Speichern des Ziels ist optional. Bei Ablehnung wird keine benannte Zielkonfiguration gespeichert; ein erzeugter SSH-Schlüssel wird jedoch nicht entfernt. Bei repokey-Verschlüsselung ohne gespeichertes Ziel legt ProxMenux die Passphrase weiterhin in der älteren Datei borg-pass.txt ab."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Verschlüsselung",
|
||||
"body": "Repositories werden mit einem Verschlüsselungsmodus über <code>hb_borg_init_if_needed</code> initialisiert: das moderne <code>borg repo-create -e MODE</code>, wenn verfügbar, oder das alte <code>borg init --encryption=MODE</code>. ProxMenux zeigt zwei Modi: <code>repokey</code> (Standard) und <code>none</code>. Im <code>repokey</code>-Modus speichert Borg den Verschlüsselungsschlüssel im Repository selbst; der Zugriff erfordert eine Passphrase, die ProxMenux zweimal mit Übereinstimmungsvalidierung anfordert und für gespeicherte Ziele unter <code>borg-pass-NAME.txt</code> speichert, sonst in der oben beschriebenen älteren Datei. Ein obligatorischer Bestätigungsdialog wird angezeigt, nachdem die Passphrase gespeichert wurde: Die Passphrase ist die einzige Möglichkeit, auf die verschlüsselten Archive zuzugreifen, und wenn sie verloren geht, ist jedes Archiv im Repository nicht wiederherstellbar."
|
||||
},
|
||||
"runtimeEnv": {
|
||||
"heading": "Laufzeitumgebung",
|
||||
"intro": "ProxMenux exportiert die folgenden Umgebungsvariablen, bevor <code>borg</code> aufgerufen wird. Sie konfigurieren die Verbindung und entsperren das Repository, ohne Geheimnisse in die Kommandozeile einzubetten.",
|
||||
"rows": [
|
||||
{
|
||||
"var": "BORG_RSH",
|
||||
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
|
||||
"purpose": "Remote-Shell-Befehl für Borg-Repositories über SSH. Ein gewählter Schlüssel ergänzt die Identitätsoptionen. Wird ein Ziel erstmals mit einem abweichenden Port hinzugefügt, ergänzt ProxMenux zusätzlich -p PORT; gespeicherte Ziele, geplante Aufträge und der Monitor verwenden stattdessen den Port aus der ssh://-URL. Ohne eigenen Schlüssel und bei einem neuen Ziel mit Standardport bleibt die Variable ungesetzt; Borg nutzt dann die SSH-Vorgaben des Hosts."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
"value": "(Passphrase von borg-pass-NAME.txt)",
|
||||
"purpose": "Entsperrt den Repokey. Setzen Sie nur, wenn das Ziel <code>repokey</code>-Verschlüsselung verwendet. Erscheint nie in der Prozessargumentenliste."
|
||||
},
|
||||
{
|
||||
"var": "BORG_ENCRYPT_MODE",
|
||||
"value": "repokey | none",
|
||||
"purpose": "Wird von <code>hb_borg_init_if_needed</code> bei der Initialisierung eines noch nicht vorhandenen Repositorys verwendet. Ignoriert von <code>borg create</code> auf bestehenden Repositories."
|
||||
},
|
||||
{
|
||||
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Unterdrückt die interaktive Eingabeaufforderung, die Borg aufruft, wenn die Repository-URL von der URL abweicht, von der sie ursprünglich erreicht wurde (üblich nach einem Rename für einen Mount-Point oder SSH-Host, der über eine neue Adresse erreichbar ist)."
|
||||
},
|
||||
{
|
||||
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Unterdrückt die interaktive Eingabeaufforderung, die Borg beim ersten Zugriff auf ein unverschlüsseltes Repository von einem neuen Client aus erstellt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Bezeichnung und Aufbewahrung des Archivs",
|
||||
"intro": "Jedes Backup erstellt ein neues Archiv im Repository.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
|
||||
"retentionBody": "Für geplante Aufträge führt <code>run_scheduled_backup.sh</code> <code>borg prune</code> nach jedem erfolgreichen Backup mit den für den Auftrag konfigurierten Retentionswerten (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>) gegen das Repository aus. Interaktive Backups beschneiden nicht."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Abruf auf der Wiederherstellungsseite",
|
||||
"body": "Die Wiederherstellung listet Archive mit <code>borg list REPO</code> auf und entpackt das gewählte Archiv mit <code>borg extract REPO::ARCHIVE-NAME</code> in ein Vorbereitungsverzeichnis. <code>_rs_check_layout</code> übergibt dieses an den normalen Wiederherstellungsablauf. Dieselben Befehle funktionieren auch manuell außerhalb von ProxMenux. Der entpackte Verzeichnisbaum entspricht der in <em>So funktioniert es</em> beschriebenen Struktur aus drei Datenblöcken."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenzen",
|
||||
"intro": "Offizielle Borg-Dokumentation zu den Komponenten, auf die ProxMenux aufbaut.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Borg-Dokumentation",
|
||||
"href": "https://borgbackup.readthedocs.io/",
|
||||
"tail": "— Haupteinstiegspunkt für Konzepte, Bereitstellung, Schnellstart und jeden Befehl."
|
||||
},
|
||||
{
|
||||
"label": "borg create",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
|
||||
"tail": " — der Befehl, den ProxMenux für jedes Backup aufruft, mit allen unterstützten Optionen."
|
||||
},
|
||||
{
|
||||
"label": "Datenspeicherverschlüsselung",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
|
||||
"tail": "- die Verschlüsselungsmodi, die Borg unterstützt, einschließlich Repokey, den ProxMenux standardmäßig verwendet."
|
||||
},
|
||||
{
|
||||
"label": "borg serve und Bereitstellung über SSH",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
|
||||
"tail": " - wie man einen zentralen Borg-Server einrichtet, auf den über SSH zugegriffen wird, einschließlich des borg-serve-Befehls und des restrict-to-path-Flags ProxMenux schreibt in authorized_keys."
|
||||
},
|
||||
{
|
||||
"label": "borg prune",
|
||||
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
|
||||
"tail": "— das Retentionsmodell hinter --keep-last / --keep-daily / --keep-weekly, das ProxMenux pro geplantem Auftrag anwendet."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Backup-Ziele — Lokal, Proxmox Backup Server, Borg | ProxMenux",
|
||||
"description": "Drei Storage-Backends erhalten die gleiche ProxMenux Backup-Nutzlast: ein lokales .tar.zst-Archiv auf jedem beschreibbaren Dateisystem, ein PBS-Backup in einem Proxmox Backup Server-Datenspeicher oder ein Borg-Archiv in einem lokalen oder entfernten Borg-Repository. Jedes Backend hat seine eigenen Kompressions-, Deduplizierungs-, Verschlüsselungs- und Netzwerkeigenschaften.",
|
||||
"ogTitle": "ProxMenux Backup-Ziele",
|
||||
"ogDescription": "Local, Proxmox Backup Server und Borg – drei Storage-Backends für die gleiche Host-Backup-Nutzlast.",
|
||||
"twitterTitle": "ProxMenux Backup Ziele | ProxMenux",
|
||||
"twitterDescription": "Lokales Archiv, Proxmox Backup Server und Borg Backends für Host-Backups."
|
||||
},
|
||||
"header": {
|
||||
"title": "Ziele",
|
||||
"description": "Drei Storage Backends, die von ProxMenux Backup unterstützt werden: lokales Archiv, Proxmox Backup Server (empfohlen) und Borg. Jeder erhält das gleiche Drei-Nutzlast-Archiv; sie unterscheiden sich in Speicherformat, Deduplizierung, Verschlüsselungsmodell und Netzwerkanforderungen.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Gleiche Nutzlast, drei Backends",
|
||||
"body": "Jedes Backup erzeugt die gleichen drei Nutzlasten (Rootfs, Manifest, Anwendungen). Was sich zwischen Zielen ändert, ist, wie diese Nutzlasten gespeichert werden und wie der Betreiber sie für eine Wiederherstellung abruft. Jedes Backend wird als separate Funktion in <code>backup_host.sh</code> - <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> - implementiert, aber alle drei haben den gleichen Staging-Schritt (<code>hb_prepare_staging</code>) und den gleichen Wiederherstellungscodepfad. Die Wahl des Ziels betrifft nur das Schreiben und den Abruf; es ändert nicht, was eine Wiederherstellung tut oder wie sie das Archiv verbraucht."
|
||||
},
|
||||
"comparison": {
|
||||
"heading": "Merkmalsvergleich",
|
||||
"intro": "Die folgende Tabelle listet die konkreten Unterschiede zwischen den drei Backends auf, wie sie sich heute in ProxMenux verhalten. Alle Werte beschreiben das beobachtete Verhalten des Backends selbst, nicht redaktionelle Empfehlungen.",
|
||||
"rows": [
|
||||
{
|
||||
"feature": "Speicherformat",
|
||||
"local": "Einzelne <code>.tar.zst</code>-Datei (oder <code>.tar.gz</code>, wenn <code>zstd</code> fehlt).",
|
||||
"pbs": "PBS Backup (<code>.pxar</code> Chunks im Datenspeicher).",
|
||||
"borg": "Borg-Archiv in einem Borg-Repository (Segmentdateien)."
|
||||
},
|
||||
{
|
||||
"feature": "Kompression",
|
||||
"local": "zstd (Standardstufe) über <code>tar --zstd</code>. gzip Fallback.",
|
||||
"pbs": "Von proxmox-backup-client verwaltet. ProxMenux überschreibt die Kompressionseinstellungen nicht.",
|
||||
"borg": "In Borg integrierte Kompression. ProxMenux ruft borg create auf, ohne die Kompressionseinstellungen zu überschreiben."
|
||||
},
|
||||
{
|
||||
"feature": "Deduplizierung",
|
||||
"local": "Keine. Jedes Backup ist ein vollständiges unabhängiges Archiv.",
|
||||
"pbs": "Vollständige Chunk-Level-Deduplizierung über alle Backups im Datenspeicher.",
|
||||
"borg": "Vollständige Chunk-Level-Deduplizierung über alle Archive im Repository."
|
||||
},
|
||||
{
|
||||
"feature": "Verschlüsselung im Ruhezustand",
|
||||
"local": "Keine (Verlässt sich auf den Schutz auf Dateisystemebene).",
|
||||
"pbs": "Optionale clientseitige Keyfile-Verschlüsselung. Recovery-Blob als separate Backup-Gruppe hochgeladen, wenn aktiviert.",
|
||||
"borg": "Optionale Repokey-Verschlüsselung (Schlüssel im Repo gespeichert, durch eine Passphrase freigeschaltet)."
|
||||
},
|
||||
{
|
||||
"feature": "Aufbewahrung / Bereinigung",
|
||||
"local": "Wird pro geplantem Auftrag über <code>KEEP_LAST</code> angewendet. Alte Archive werden zusammen mit ihren Begleitdateien und Ausführungsprotokollen gelöscht. Interaktive Backups führen keine Bereinigung aus.",
|
||||
"pbs": "Angewendet pro geplanten Auftrag über <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktive Backups führen keine Bereinigung aus.",
|
||||
"borg": "Angewendet pro geplanten Auftrag über <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktive Backups führen keine Bereinigung aus."
|
||||
},
|
||||
{
|
||||
"feature": "Netzwerk",
|
||||
"local": "Keine. Schreibt auf einen lokalen Einhängepunkt (normalerweise eine interne Festplatte oder ein USB-Laufwerk).",
|
||||
"pbs": "TCP auf den PBS-Server (Standardport 8007). Erfordert PBS Anmeldeinformationen + Fingerabdruck.",
|
||||
"borg": "Lokaler Dateisystempfad oder SSH Tunnel zu einem entfernten Borg-Host."
|
||||
},
|
||||
{
|
||||
"feature": "Abhängigkeiten",
|
||||
"local": "<code>tar</code>, <code>zstd</code> (standardmäßig auf Proxmox vorhanden).",
|
||||
"pbs": "<code>proxmox-backup-client</code> Paket (gebündelt mit Proxmox VE 8+).",
|
||||
"borg": "<code>borg</code> binär. Automatische Bereitstellung durch ProxMenux aus dem Monitor AppImage-Bundle, wenn es fehlt."
|
||||
},
|
||||
{
|
||||
"feature": "Zugriff für die Wiederherstellung",
|
||||
"local": "Jeder Host mit tar+zstd kann das Archiv extrahieren. Keine PBS/Borg erforderlich.",
|
||||
"pbs": "Erfordert <code>proxmox-backup-client</code> + PBS Anmeldeinformationen + die Schlüsseldatei (falls verschlüsselt).",
|
||||
"borg": "Erfordert <code>borg</code> + den Repository-Pfad + die Passphrase (falls verschlüsselt)."
|
||||
}
|
||||
],
|
||||
"captionCode": "feature",
|
||||
"captionLocal": "Lokal",
|
||||
"captionPbs": "Proxmox Backup Server (empfohlen)",
|
||||
"captionBorg": "Borg"
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "Das Archivlayout ändert sich nicht mit dem Ziel",
|
||||
"body": "Innerhalb eines der drei Ziele ist das gleiche <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> Layout vorhanden, das in <em>Funktionsweise</em> beschrieben wird. Ein aus einem lokalen Archiv extrahierter <code>.tar.zst</code>, ein aus PBS wiederhergestellter <code>.pxar</code> und ein mit <code>borg extract</code> extrahiertes Borg-Archiv ergeben alle einen identischen Verzeichnisbaum. Der Wiederherstellungscodepfad (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) liest die gleichen drei Nutzlasten, ohne zu wissen, von welchem Ziel sie kamen."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extrahieren eines Backups außerhalb von ProxMenux",
|
||||
"intro": "Jedes der drei Archivformate kann mit Standardtools gelesen werden, ohne dass ProxMenux auf dem Lesehost installiert ist. Die folgenden Befehle erzeugen den gleichen Verzeichnisbaum, den eine Wiederherstellung intern verbraucht.",
|
||||
"localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
|
||||
"pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n --repository USER@REALM@HOST:DATASTORE \\\n host/hostcfg-HOST/BACKUP-TIME \\\n hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
|
||||
"borgCmd": "# Aus einem Borg-Archiv (benötigt borg und bei verschlüsselten Repositories die Passphrase):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Bei einem über SSH erreichbaren entfernten Repository:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
|
||||
"note": "Der extrahierte Baum kann dann manuell inspiziert oder einer manuellen Wiederherstellung zugeführt werden. Sehen Sie sich die einzelnen Zielseiten für den genauen Abruffluss an, den ProxMenux unter der Haube verwendet."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Details je Ziel",
|
||||
"intro": "Jedes Ziel hat eine eigene Seite, die den Konfigurationsfluss, das On-Disk-Format und den von der Wiederherstellung verwendeten Abrufbefehl abdeckt.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Lokales Archiv",
|
||||
"href": "/docs/backup-restore/destinations/local",
|
||||
"tail": " — Vorkonfiguration eines lokalen Ziels, Einhängen von USB-Laufwerken, Schutz vor dem Einschließen des Archivs in sich selbst und die JSON-Begleitdatei zur Erkennung im Monitor."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox Backup Server (empfohlen)",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "Datenspeicherauswahl, Anmeldeinformationen und Fingerabdruck, Verschlüsselungs-Keyfile-Lebenszyklus, Recovery-Passphrase, Hochladen des Recovery-Blobs zu PBS für die Wiederherstellung mit frischer Installation."
|
||||
},
|
||||
{
|
||||
"label": "Borg",
|
||||
"href": "/docs/backup-restore/destinations/borg",
|
||||
"tail": " — lokale und über SSH erreichbare Repositories, Bezugsquellen der Borg-Binärdatei (System / Cache / Monitor-AppImage-Bundle / GitHub-Download), Repository-Initialisierung, Umgang mit Passphrasen und SSH-Schlüssel für entfernte Repositories."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,75 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Lokales Archivziel — tar.zst auf einem Dateisystem oder USB-Laufwerk | ProxMenux",
|
||||
"description": "Das lokale Sicherungsziel schreibt ein einzelnes .tar.zst-Archiv in ein beliebiges beschreibbares Verzeichnis: auf eine interne Festplatte, einen Proxmox-Mountpoint, eine NFS-Freigabe oder ein USB-Laufwerk. Diese Seite beschreibt die Einrichtung, das Erkennen und Einbinden von USB-Laufwerken, den Schutz vor dem Speichern des Archivs in einem selbst gesicherten Pfad und die zugehörige JSON-Datei zur Identifizierung der Sicherung.",
|
||||
"ogTitle": "ProxMenux Backup — Ziel des lokalen Archivs",
|
||||
"ogDescription": "Wie ProxMenux lokale Backups als .tar.zst-Archive schreibt und wie man das Zielverzeichnis oder das USB-Laufwerk konfiguriert.",
|
||||
"twitterTitle": "Lokales Backup-Ziel | ProxMenux",
|
||||
"twitterDescription": "Wie ProxMenux lokale Backups als .tar.zst-Archive auf ein Dateisystem oder USB-Laufwerk schreibt."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lokales Archiv",
|
||||
"description": "Das lokale Sicherungsziel schreibt ein einzelnes komprimiertes tar-Archiv in ein beliebiges beschreibbares Verzeichnis auf dem Host: auf eine interne Festplatte, einen NFS- oder SMB-Mount oder ein USB-Laufwerk.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Eine Datei, in sich geschlossen",
|
||||
"body": "Ein lokales Backup erzeugt eine einzelne <code>hostcfg-HOST-TIMESTAMP.tar.zst</code>-Datei (oder <code>.tar.gz</code>, wenn <code>zstd</code> fehlt). Die Datei enthält den gesamten Archivbaum <code>manifest.json</code>, <code>metadata/</code> und <code>rootfs/</code> und kann auf jedem Proxmox-Host mit dem ProxMenux-Wiederherstellungsfluss wiederhergestellt oder manuell mit <code>tar --zstd -xf</code> auf jedem Linux-System extrahiert werden. Kein Server, kein Repository init, keine externe Abhängigkeit. Dies ist das Ziel mit dem kürzesten Wiederherstellungspfad, wenn weder PBS noch Borg verfügbar sind."
|
||||
},
|
||||
"targetConfig": {
|
||||
"heading": "Konfiguration des Zielverzeichnisses",
|
||||
"intro": "Das lokale Ziel ist ein <strong>einziges dauerhaft gespeichertes Zielverzeichnis</strong> – keine Liste. ProxMenux speichert die Auswahl des Betreibers bei <code>/usr/local/share/proxmenux/local-target.conf</code> und liest sie bei jedem Backup. Wenn kein Ziel konfiguriert wurde, wird der Standard-<code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> verwendet (das gleiche Verzeichnis, das Proxmox für seine eigenen <code>vzdump</code>-Ausgänge verwendet). Das Ziel wird unter <em>Backup-Ziele konfigurieren → Lokale Ziele</em> konfiguriert:",
|
||||
"options": [
|
||||
"<strong>Standard verwenden (<code>/var/lib/vz/dump</code>).</strong> Der lokale Proxmox-Speicher. Bei jeder Proxmox-Installation vorhanden; das Archiv befindet sich neben den vzdump-Ausgaben und wird automatisch von der Registerkarte Backups des Monitors aufgenommen.",
|
||||
"<strong>Benutzerdefinierten Pfad eingeben.</strong> Jeder absolute Dateisystempfad kann verwendet werden: ein NFS-Mount, eine über <code>fstab</code> eingebundene SMB-Freigabe, ein eigenes ZFS-Dataset oder eine zweite interne Festplatte. ProxMenux prüft vor dem Speichern, ob der Pfad existiert und ein Verzeichnis ist.",
|
||||
"<strong>Wählen Sie ein USB-Laufwerk.</strong> Öffnet das USB-Untermenü (unten), das Wechselgeräte erkennt und ein Gerät montieren oder formatieren kann."
|
||||
]
|
||||
},
|
||||
"usbFlow": {
|
||||
"heading": "USB-Laufwerkerkennung und -montage",
|
||||
"intro": "Das USB-Untermenü listet Partitionen auf Wechselgeräten auf, die von <code>lsblk</code> gemeldet werden. Jede Partition wird mit ihrer Größe, Dateisystem-Beschriftung und aktuellem Zustand dargestellt. Der Zustand bestimmt die Aktion, die ProxMenux anbietet.",
|
||||
"statesTitle": "Die drei Gerätezustände",
|
||||
"stateRows": [
|
||||
{
|
||||
"state": "eingehängt",
|
||||
"shown": "Größe · Etikett · [fstype] · → /mount/point",
|
||||
"action": "Die Partition ist bereits irgendwo montiert. Bei der Auswahl wird der aktuelle Einhängepunkt als lokales Ziel gespeichert. Es wird kein neuer Mount ausgeführt."
|
||||
},
|
||||
{
|
||||
"state": "nicht montiert",
|
||||
"shown": "Größe · Etikett · [fstype] · (nicht montiert — wird montiert)",
|
||||
"action": "Ein Dateisystem ist vorhanden, aber nicht montiert. Bei Bestätigung führt ProxMenux <code>hb_mount_usb_partition</code> aus: erstellt <code>/mnt/backup-LABEL</code> (oder einen UUID-basierten Pfad, wenn kein Label vorhanden ist), mountet die Partition und speichert den Einhängepunkt als lokales Ziel."
|
||||
},
|
||||
{
|
||||
"state": "leer",
|
||||
"shown": "Größe · unformatierter USB-Datenträger — kein Dateisystem (wird FORMATIERT)",
|
||||
"action": "Das Gerät hat kein Dateisystem. Dieser destruktive Vorgang ist durch zwei Bestätigungen geschützt. Zuerst erklärt ein Ja/Nein-Dialog, dass der Datenträger gelöscht wird. Anschließend muss der Benutzer in einem Eingabefeld <strong>den exakten Gerätepfad eingeben</strong> (z. B. <code>/dev/sdb</code>), bevor ProxMenux eine neue GPT mit ext4-Partition erstellt und diese einhängt."
|
||||
}
|
||||
],
|
||||
"notMountedFallback": "Wenn kein USB-Gerät erkannt wird, fällt das Untermenü auf eine einfache Eingabebox zurück. Der Bediener kann einen beliebigen Einhängepunktpfad eingeben; wenn der Pfad kein registrierter Einhängepunkt ist, warnt ein Bestätigungsdialog, bevor er fortfährt."
|
||||
},
|
||||
"safetyCheck": {
|
||||
"heading": "Sicherheitsprüfung — Ziel innerhalb eines gesicherten Pfads",
|
||||
"body": "Vor dem Schreiben des Archivs überprüft <code>_bk_local</code>, dass das Zielverzeichnis <strong>nicht</strong> ein Unterpfad eines zu sichernden Verzeichnisses ist. Ein häufiger Fehler wäre das Hinzufügen von <code>/root</code> zum Profil und die Auswahl von <code>/root/backups</code> als Ziel – das Archiv würde sich dann selbst einschließen und entweder ein beschädigtes Archiv erzeugen oder unbegrenzt wachsen, bis die Festplatte voll ist. Die Prüfung löst beide Pfade mit <code>readlink -m</code> auf, vergleicht sie und bricht bei einem Konflikt die Sicherung mit einem Dialogfeld ab, das den in Konflikt stehenden Pfad benennt und drei Möglichkeiten zur Lösung auflistet: Wählen Sie ein Ziel außerhalb des in Konflikt stehenden Pfads, entfernen Sie den benutzerdefinierten Eintrag, der das Ziel enthält, oder deaktivieren Sie den in Konflikt stehenden Pfad für diesen Lauf im benutzerdefinierten Modus."
|
||||
},
|
||||
"archiveFormat": {
|
||||
"heading": "Archivformat und Komprimierung",
|
||||
"intro": "Der Ausgabedateiname bettet den Quellhostnamen und den Backup-Zeitstempel ein, so dass ein Verzeichnis mit mehreren Archiven chronologisch sortiert und jede Datei sich selbst identifiziert.",
|
||||
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
|
||||
"compressionTitle": "Kompression",
|
||||
"compressionBody": "Der primäre Pfad verwendet <code>tar --zstd -cf</code> - eine Single-Command-Pipeline, die auf dem Standardniveau von zstd komprimiert wird. Wenn <code>zstd</code> nicht in der Quelle vorhanden ist (selten bei Proxmox, aber bei minimalen Installationen möglich), fällt ProxMenux auf <code>gzip</code> zurück. Im Fallback-Pfad wird, wenn <code>pv</code> verfügbar ist, ein Fortschrittsbalken zur Pipeline hinzugefügt, so dass der Betreiber die Archivgröße in Echtzeit wachsen sieht; ohne <code>pv</code> wird <code>tar -czf</code> still verwendet.",
|
||||
"sourceTitle": "Was geht ins Archiv",
|
||||
"sourceBody": "Der tar-Befehl wird mit <code>-C \"$staging_root\" .</code> aufgerufen und archiviert dadurch das <strong>gesamte Staging-Hauptverzeichnis</strong>: <code>rootfs/</code>, <code>metadata/</code> und <code>manifest.json</code>. Alle drei Datenblöcke liegen nebeneinander auf der obersten Ebene des tar-Archivs. Beim Entpacken entsteht genau der Baum, den der Wiederherstellungscode verwendet."
|
||||
},
|
||||
"sidecar": {
|
||||
"heading": "Die JSON-Begleitdatei",
|
||||
"intro": "Jedes erfolgreiche lokale Backup erzeugt eine Begleitdatei: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, geschrieben neben dem Archiv von <code>hb_write_archive_sidecar</code>. Diese kleine JSON-Datei ermöglicht es dem ProxMenux Monitor, das Archiv als ProxMenux-Host-Backup zu identifizieren, auch wenn es später an anderer Stelle verschoben, umbenannt oder archiviert wird.",
|
||||
"contentTitle": "Inhalt der Begleitdatei",
|
||||
"contentBody": "Das Sidecar speichert die Schemaversion, ob das Backup von einem interaktiven Lauf oder einem geplanten Job (<code>kind</code>) stammt, die Job-ID für geplante Läufe, den verwendeten Profilmodus (<code>default</code> oder <code>custom</code>), den Quellhostnamen, den ursprünglichen Archivbasisnamen, einen ISO-8601-Erstellungszeitstempel und die Archivgröße in Bytes.",
|
||||
"whyBody": "Die Registerkarte Backups des Monitors scannt konfigurierte lokale Verzeichnisse für <code>*.proxmenux.json</code>-Begleitdateien - nicht für <code>*.tar.zst</code>-Dateien -, da ein <code>.tar.zst</code> ohne Sidecar möglicherweise überhaupt kein ProxMenux-Backup ist. Der Scan ist schnell (JSON-Dateien sind winzig) und die Paarung ist stabil bei Umbenennungen des Archivs, solange das Sidecar entsprechend umbenannt wird."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Wiederherstellen aus einem lokalen Archiv",
|
||||
"body": "Der ProxMenux-Wiederherstellungsfluss entdeckt lokale Archive, indem er das konfigurierte lokale Ziel nach Begleitdateien durchsucht und in der Archivliste anzeigt. Die Auswahl eines Archivs löst <code>_rs_check_layout</code> aus, der den Tarball in ein Staging-Verzeichnis extrahiert und das Layout mit drei Nutzlasten bestätigt, bevor er fortfährt. Für die manuelle Extraktion außerhalb von ProxMenux liefert <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> den gleichen Baum, den der Wiederherstellungscode verbraucht."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Backup Server Zielort — Repository, Verschlüsselung, Wiederherstellung | ProxMenux",
|
||||
"description": "Das PBS-Ziel speichert ProxMenux-Host-Backups als PBS-Backups. Beschrieben werden die Repository-Erkennung aus /etc/pve/storage.cfg, die manuelle PBS-Konfiguration, der .pxar-Upload, die clientseitige Verschlüsselung mit einer Schlüsseldatei samt optionaler passphrasengeschützter Sicherungskopie sowie die Schlüsselwiederherstellung aus mehreren Quellen auf einem neu installierten Host.",
|
||||
"ogTitle": "ProxMenux Backup — Bestimmungsort Proxmox Backup Server",
|
||||
"ogDescription": "So speichert ProxMenux Host-Backups auf Proxmox Backup Server mit clientseitiger Schlüsseldateiverschlüsselung und einer hinterlegten Wiederherstellungskopie.",
|
||||
"twitterTitle": "PBS Backup Ziel | ProxMenux",
|
||||
"twitterDescription": "Proxmox Backup Server als Ziel mit Schlüsseldateiverschlüsselung und passphrasengeschützter Wiederherstellungskopie."
|
||||
},
|
||||
"header": {
|
||||
"title": "Proxmox Backup Server",
|
||||
"description": "Das PBS-Ziel lädt das gesamte Vorbereitungsverzeichnis als ein einzelnes .pxar-Backup in einen Proxmox-Backup-Server-Datenspeicher hoch. Optional wird es clientseitig mit einer Schlüsseldatei verschlüsselt; zusätzlich kann neben jedem Backup eine passphrasengeschützte Wiederherstellungskopie der Schlüsseldatei hinterlegt werden.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"recommendedBadge": "Empfohlenes Ziel",
|
||||
"aboutPbs": {
|
||||
"heading": "Was Proxmox Backup Server ist",
|
||||
"body": "Proxmox Backup Server (PBS) ist das eigene Backup-Server-Produkt von Proxmox, das von dem gleichen Team entwickelt und gewartet wird, das auch Proxmox VE entwickelt hat. Es ist ein dedizierter Backup-Server, der entwickelt wurde, um Backups von Proxmox VE-Hosts (VMs, LXCs und - über <code>proxmox-backup-client</code> - beliebige Host-Verzeichnisse) mit chunkbasierter Deduplizierung, clientseitiger Verschlüsselung und serverseitig angewendeten Aufbewahrungsrichtlinien zu erhalten. ProxMenux verwendet PBS als eines der drei Ziele für Host-Backups; jeder auf dieser Seite beschriebene PBS-spezifische Mechanismus (Backup-Gruppen, <code>.pxar</code>-Archive, <code>--backup-id</code>, Keyfile-Verschlüsselung) ist Standard-PBS-Verhalten."
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ein Backup pro Lauf, Chunk-Level-Dedup",
|
||||
"body": "Ein PBS-Backup erzeugt einen einzelnen Backup-Eintrag im Datenspeicher, der unter der Backup-ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code> gruppiert ist. Die Nutzlast ist ein <code>.pxar</code>-Archiv, das das gleiche dreiblockige Layout enthält, das in <em>How it works</em> beschrieben ist. PBS dedupliziert auf der Chunk-Ebene über alle Backups im Datenspeicher, so dass nachfolgende Backups desselben Hosts nur die geänderten Chunks übertragen und speichern. Die Retention wird von ProxMenux selbst für geplante Aufträge angewendet — <code>run_scheduled_backup.sh</code> führt <code>proxmox-backup-client prune</code> mit <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> nach jedem erfolgreichen Lauf mit den für den Auftrag konfigurierten Werten aus."
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Repository-Auswahl",
|
||||
"intro": "ProxMenux entdeckt PBS-Repositories aus zwei Quellen in jedem Backup. Der Bediener wählt einen aus einem einheitlichen Menü aus; die Auswahl bestimmt <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> und <code>HB_PBS_FINGERPRINT</code> für den Lauf.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "Proxmox storage.cfg (automatisch erkannt)",
|
||||
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
|
||||
"content": "Jede <code>pbs:</code> Strophe in der eigenen Speicherkonfiguration von Proxmox wird automatisch abgeholt. Server, Datenspeicher, Benutzername und Fingerabdruck stammen aus der Strophe. Das Passwort wird aus dem eigenen Anmeldeverzeichnis von Proxmox gelesen. Auf der ProxMenux-Seite ist kein erneuter Eintrag erforderlich – das Repository ist verfügbar, sobald es in Proxmox konfiguriert ist."
|
||||
},
|
||||
{
|
||||
"source": "ProxMenux manuelle Konfiguration",
|
||||
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
|
||||
"content": "Zusätzlich von <em> Backup-Ziele konfigurieren → PBS Ziele → PBS</em> hinzufügen. Prompts für einen Namen, Benutzernamen (<code>root@pam</code> oder <code>user@pbs!token</code>), Host oder IP, Datenspeicher und Passwort. Das Passwort wird bei leeren Eingaben erneut angezeigt - ein leeres Speichern würde ansonsten still bleiben und jedes nachfolgende Backup würde mit einem undurchsichtigen Authentifizierungsfehler fehlschlagen. Dieser Pfad wird verwendet, wenn das Ziel PBS nicht als Proxmox-Speicher registriert ist."
|
||||
}
|
||||
],
|
||||
"menuTitle": "Auswahlmenü",
|
||||
"menuBody": "Beide Quellen werden in einem einzigen Menü angezeigt, wobei jede Zeile mit ihrem Ursprung markiert ist (<code>[proxmox]</code> oder <code>[manual]</code>). Einträge, deren Passwort nicht aufgelöst werden konnte, werden mit einer <code>⚠ no password</code>-Warnung versehen – die Auswahl einer löst einen erneuten Passworteintrag aus, bevor das Backup startet. Der Fingerabdruck wird über die <code>PBS_FINGERPRINT</code>-Umgebungsvariable an <code>proxmox-backup-client</code> übergeben; bei Abwesenheit fordert der Client den Betreiber auf, das Serverzertifikat beim ersten Backup interaktiv zu akzeptieren."
|
||||
},
|
||||
"backupCommand": {
|
||||
"heading": "Der Backup-Befehl",
|
||||
"intro": "Der Upload erfolgt mit einem einzigen Aufruf von <code>proxmox-backup-client backup</code>. ProxMenux übergibt Passwort, Verschlüsselungspasswort und Fingerabdruck mit <code>env</code> als Umgebungsvariablen an den Client.",
|
||||
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
|
||||
"backupIdTitle": "Backup-ID-Bezeichnung",
|
||||
"backupIdBody": "Die Standard-Backup-ID ist <code>hostcfg-HOSTNAME</code>. Vor dem Upload wird sie bestätigt oder bearbeitet. Zeichen außerhalb von <code>[A-Za-z0-9_-]</code> sowie abschließende Bindestriche werden entfernt. Die Wiederverwendung derselben ID bei weiteren Läufen ist beabsichtigt: PBS behandelt die ID als <em>Gruppe</em>. Jedes weitere Backup erscheint als neuer Eintrag in dieser Gruppe und nutzt die Deduplizierung mit früheren Backups.",
|
||||
"pxarTitle": "Warum die Quelle die vollständige Staging-Wurzel ist",
|
||||
"pxarBody": "Die <code>.pxar</code>-Quelle ist die gesamte <code>staging_root</code> - <code>rootfs/</code>, <code>metadata/</code> und <code>manifest.json</code> zusammen. Frühere Versionen bestanden <code>$staging_root/rootfs</code> als Quelle; Das ließ <code>metadata/</code> aus dem Archiv und die Kompatibilitätsprüfung der Wiederherstellung hatte nichts zu lesen, was selbst bei Wiederherstellungen des gleichen Hosts zu Cross-Host-Warnungen führte. Alte Backups, die mit der Rootfs-only-Quelle erstellt wurden, werden immer noch korrekt über den <code>_rs_check_layout</code>-Fall-3-Zweig wiederhergestellt, der einen flachen <code>etc/var/root/usr</code>-Baum zurück in eine <code>rootfs/</code>-Hierarchie wickelt."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Clientseitige Verschlüsselung",
|
||||
"glossaryHint": "Dieser Abschnitt verwendet die Begriffe <em>Schlüsseldatei</em>, <em>Passphrase</em> und <em>Wiederherstellungshülle</em>. Das <glosarioLink>Glossar</glosarioLink> erklärt die Unterschiede mit einem Satz pro Begriff.",
|
||||
"intro": "Die clientseitige PBS-Verschlüsselung mit einer Schlüsseldatei verschlüsselt die Blöcke vor dem Upload auf dem Quellhost. In ProxMenux ist die Verschlüsselung optional. Wird sie aktiviert, entscheidet der Betreiber bei der Einrichtung ausdrücklich mit Ja oder Nein, ob zusätzlich eine passphrasengeschützte Wiederherstellungskopie der Schlüsseldatei auf PBS hinterlegt wird; diese Wahl lässt sich später im Monitor ändern. Die Schlüsseldatei selbst liegt immer unter dem kanonischen Pfad <code>/usr/local/share/proxmenux/pbs-key.conf</code> und wird für alle weiteren verschlüsselten Backups ohne erneute Nachfrage verwendet.",
|
||||
"keyfileTitle": "Einrichten der Keyfile",
|
||||
"keyfileBody": "Der Verschlüsselungsdialog erscheint beim ersten verschlüsselten Backup des Hosts. Zunächst wird gefragt, ob das Backup verschlüsselt werden soll: <em>Nein</em> fährt ohne Verschlüsselung fort, <em>Ja</em> führt zum zweiten Schritt. Dieser hängt davon ab, ob bereits eine Schlüsseldatei unter <code>/usr/local/share/proxmenux/pbs-key.conf</code> installiert ist. Falls ja, wird sie ohne Nachfrage wiederverwendet und das Backup fortgesetzt; auch spätere Backups fragen nicht erneut. Andernfalls bietet ein Menü zwei Möglichkeiten. <em>Neue Schlüsseldatei erzeugen</em> führt <code>proxmox-backup-client key create --kdf none</code> aus. <em>Vorhandene Schlüsseldatei verwenden</em> erkennt eine von PVE verwaltete Datei automatisch: Ist das gewählte PBS-Repository in Proxmox mit einem Verschlüsselungsschlüssel unter <code>/etc/pve/priv/storage/<NAME>.enc</code> registriert, wird diese Datei ohne Nachfrage an den kanonischen ProxMenux-Pfad kopiert. Gibt es keine passende PVE-Datei, wird nach dem absoluten Pfad gefragt, unter dem der Betreiber die Schlüsseldatei bereits auf diesem Host abgelegt hat. In beiden Fällen liegt sie danach am kanonischen Pfad mit <code>chmod 600</code>.",
|
||||
"modesTitle": "Schlüsseldatei je Host oder gemeinsam nutzen",
|
||||
"modesIntro": "Beide Betriebsmodelle werden unterstützt und keines wird durchgesetzt - die Wahl liegt beim Betreiber, je nachdem, wie seine Flotte organisiert ist.",
|
||||
"modesPerHostTitle": "Eigene Schlüsseldatei je Host (Standard)",
|
||||
"modesPerHostBody": "Jeder Host generiert seine eigene Schlüsseldatei, wenn er zum ersten Mal die PBS-Verschlüsselung aktiviert. Die Isolation ist maximal: Durch die Kompromittierung der Schlüsseldatei eines Hosts werden die Backups anderer Hosts nicht offengelegt. Empfohlen für Produktionsflotten und für Umgebungen, in denen Hosts unterschiedliche Eigentümer oder Compliance-Grenzen haben.",
|
||||
"modesSharedTitle": "Gemeinsame Keyfile (Import auf jedem Host)",
|
||||
"modesSharedBody": "Eine Hauptschlüsseldatei wird einmal generiert und auf jedem Host über die Option <em>Vorhandene Schlüsseldatei verwenden</em> installiert. Die Verwaltung ist einfacher: Ein einziges Geheimnis muss geschützt werden, und jeder Host kann die Archive jedes anderen entschlüsseln (nützlich für Konsolidierung, hostübergreifende Wiederherstellungsübungen oder zentralisierte Backup-Verifizierung). Der Nachteil besteht darin, dass ein Leck der gemeinsam genutzten Schlüsseldatei jeden Host auf einmal offenlegt. Empfohlen für Homelabs und Flotten, bei denen alle Hosts denselben Eigentümer und dieselbe Vertrauensgrenze haben.",
|
||||
"recoveryTitle": "Schlüssel auf PBS hinterlegen — der Betreiber entscheidet",
|
||||
"recoveryBody": "Direkt nach Auswahl der Schlüsseldatei fragt ProxMenux ausdrücklich <em>Schlüssel auf PBS hochladen?</em> und bietet zwei Antworten. <strong>Erst wenn der Betreiber Ja wählt, wird ein Wiederherstellungsartefakt auf PBS hochgeladen.</strong> Vorgabe ist <em>Nein, nur lokal behalten</em>: Die Schlüsseldatei bleibt am kanonischen lokalen Pfad, ProxMenux lädt kein Wiederherstellungsartefakt auf PBS hoch und der Betreiber sorgt selbst für eine externe Kopie. Die Schaltfläche <em>Schlüsseldatei herunterladen</em> in der PBS-Zielzeile des Monitors stellt sie bei Bedarf bereit. Bei <em>Ja, hochladen</em> wird zweimal eine Wiederherstellungspassphrase abgefragt und auf Übereinstimmung geprüft. ProxMenux schützt die Schlüsseldatei damit mittels AES-256-CBC und PBKDF2 (600.000 Iterationen, zufälliges Salt) und erzeugt <code>pbs-key.recovery.enc</code>. Jedes weitere verschlüsselte Backup lädt diese Hülle als zugehörige Backup-Gruppe auf PBS hoch. Dabei werden weder die Passphrase noch die Schlüsseldatei im Klartext an PBS gesendet. Die Entscheidung lässt sich jederzeit im Monitor ändern: Der Schalter in der PBS-Zielzeile wählt Ja oder Nein und übernimmt je nach Zustand sofort Upload starten, Upload stoppen oder Passphrase aktualisieren.",
|
||||
"blobUploadTitle": "Gepaarte Backup-Gruppe auf PBS",
|
||||
"blobUploadBody1": "Ist die Hinterlegung auf <em>Ja, hochladen</em> gesetzt, lädt ProxMenux nach jedem verschlüsselten Backup die Wiederherstellungshülle als zweite, zugehörige Backup-Gruppe auf PBS hoch. Sie heißt wie die Host-Gruppe, ergänzt um <code>-keyrecovery</code>. Beide Gruppen stehen in der Datenspeicherliste nebeneinander: eine für Host-Backups, eine für Wiederherstellungshüllen. <strong>Die Hülle verlässt den Host niemals im Klartext</strong>: Noch vor der Übertragung verschlüsselt der Host sie mit AES-256-CBC und PBKDF2 (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS erhält ausschließlich die bereits verschlüsselte Hülle.",
|
||||
"envelopeSecurityTitle": "Ist das Hochladen der keyrecovery-Datei in PBS ein Sicherheitsrisiko?",
|
||||
"envelopeSecurityBody": "Die keyrecovery-datei ist verschlüsselt in transit und in ruhe. Die Wiederherstellungspassphrase verlässt den Host nie: Verschlüsselung geschieht lokal vor dem Upload, und PBS sieht immer nur das bereits verschlüsselte Ergebnis. Ein PBS-Administrator - oder jeder, der Zugriff auf den Datenspeicher hat - kann die KeyRecovery-Datei herunterladen, aber ohne die Wiederherstellungspassphrase können sie die Keyfile nicht lesen: Es ist undurchsichtiger Geheimtext. Das Rekonstruieren der Keyfile erfordert beide Teile gleichzeitig, die KeyRecovery-Datei und die Passphrase, und nur der Operator hält beide.",
|
||||
"blobUploadConstraintTitle": "Warum zwei Gruppen statt einer einzigen verschlüsselten",
|
||||
"blobUploadConstraintBody": "Ein einzelner Aufruf von <code>proxmox-backup-client backup</code> verschlüsselt entweder alle enthaltenen Archive mit derselben Schlüsseldatei oder keines davon. Das Host-Backup muss mit der Host-Schlüsseldatei verschlüsselt werden. Die Wiederherstellungshülle darf aber nicht im selben Upload liegen, sonst würde sie mit genau der Schlüsseldatei verschlüsselt, die sie enthält. Auf einem neu installierten Host ließe sie sich nicht öffnen: Zum Entschlüsseln der Schlüsseldatei wäre diese selbst nötig. Deshalb werden die beiden Artefakte unabhängig hochgeladen und erscheinen als zwei Gruppen. Der PBS-Client verschlüsselt das Host-Backup mit der Schlüsseldatei; ProxMenux verschlüsselt die Wiederherstellungshülle vor dem Upload mit der Passphrase. Zwei verschiedene Verschlüsselungsschichten schützen zwei unterschiedliche Inhalte.",
|
||||
"blobUploadImageAlt": "PBS Benutzeroberfläche zeigt die Backup-Gruppen hostcfg-HOSTNAME und hostcfg-HOSTNAME-keyrecovery angrenzend im Datenspeicher.",
|
||||
"blobUploadImageCaption": "PBS UI — die gepaarten Backup-Gruppen. Die Hauptgruppe hält die Host-Backups; die -keyrecovery-Gruppe hält die passphrase-verpackte Schlüsseldatei.",
|
||||
"recoverTitle": "Wiederherstellung auf einem neu installierten Host",
|
||||
"recoverBody": "Fehlt die lokale Schlüsseldatei am kanonischen Pfad, etwa nach einer Neuinstallation oder ausdrücklichem Löschen, versucht die Wiederherstellung drei Quellen der Reihe nach und stoppt bei der ersten brauchbaren Schlüsseldatei. Erstens wird eine zum gewählten PBS-Repository passende, von PVE verwaltete Datei unter <code>/etc/pve/priv/storage/<NAME>.enc</code> ohne Nachfrage an den kanonischen Pfad kopiert. Zweitens wird, falls auf PBS eine Gruppe <code>-keyrecovery</code> vorhanden ist, deren neuester Snapshot heruntergeladen und die Wiederherstellungspassphrase zum Entschlüsseln abgefragt. Funktioniert beides nicht oder lehnt der Betreiber die Optionen ab, fragt der dritte Schritt nach dem absoluten Pfad der Schlüsseldatei auf diesem Host und kopiert sie an den kanonischen Pfad. Der Monitor bietet denselben Importablauf im Backup-Detaildialog. Oben erscheint ein gelbes Feld, wenn Wiederherstellen, Herunterladen oder Inhalt anzeigen eine nicht installierte Schlüsseldatei benötigen. Ist eine Datei installiert, passt aber nicht zum Backup, meldet PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Dieselben drei Aktionen zeigen dann ein strukturiertes gelbes Feld mit dem erforderlichen Manifest-Fingerabdruck an, damit der Betreiber die passende Schlüsseldatei für dieses Backup erkennen und importieren kann.",
|
||||
"monitorManagementTitle": "Schlüsseldatei im Monitor verwalten",
|
||||
"monitorManagementBody": "Der Monitor zeigt die Schlüsseldatei-Steuerung direkt in jeder PBS-Zielzeile der Backup-Konfigurationsseite. Es gibt drei Aktionen: <em>Herunterladen</em> exportiert die aktuelle Datei in den Browser des Betreibers; <em>Hochladen</em> ersetzt die installierte Datei durch eine bereitgestellte Datei, wobei die bisherige erst nach erfolgreicher Installation der neuen am kanonischen Pfad überschrieben wird; <em>Löschen</em> entfernt die Datei vom Host. Daneben befindet sich die Steuerung der Wiederherstellungskopie: eine Ja/Nein-Auswahl für <em>Schlüssel auf PBS hochladen?</em>, bei Ja ein Passphrase-Feld und eine passende Übernehmen-Schaltfläche mit <em>Upload starten</em>, <em>Upload stoppen</em> oder <em>Passphrase aktualisieren</em>. Jede Aktion nutzt dieselben Flask-Endpunkte wie die Terminaloberfläche. Die Wirkung auf Dateien und den PBS-Zustand ist deshalb bei beiden Oberflächen identisch."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Abruf auf der Wiederherstellungsseite",
|
||||
"body": "Der Wiederherstellungsfluss erkennt ProxMenux Host-Backups auf PBS, indem er Backup-Gruppen unter dem konfigurierten Repository auflistet und nach Backup-ID-Muster filtert. Die Registerkarte Backups des Monitors stellt dieselbe Liste dar. Durch das Auswählen eines Backups wird <code>proxmox-backup-client restore</code> mit demselben Repository + Passwort + Fingerabdruck (und <code>--keyfile</code>, als das Backup verschlüsselt wurde) ausgelöst, wodurch das <code>.pxar</code> in ein Staging-Verzeichnis extrahiert wird, das <code>_rs_check_layout</code> dann der Standardwiederherstellungspipeline zuführt. Für das manuelle Abrufen außerhalb von ProxMenux extrahiert derselbe Befehl das Archiv auf einen beliebigen Pfad - der resultierende Baum kann inspiziert oder einer handgesteuerten Wiederherstellung zugeführt werden."
|
||||
},
|
||||
"references": {
|
||||
"heading": "Referenzen",
|
||||
"intro": "Offizielle Dokumentation von Proxmox Backup Server zu den Komponenten, auf die ProxMenux aufbaut.",
|
||||
"items": [
|
||||
{
|
||||
"label": "Proxmox Backup Server Dokumentation",
|
||||
"href": "https://pbs.proxmox.com/docs/",
|
||||
"tail": "— Haupteinstiegspunkt für Installation, Verwaltung, Speicherung, Benutzer und Rollen."
|
||||
},
|
||||
{
|
||||
"label": "proxmox-backup-client",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html",
|
||||
"tail": " — das Befehlszeilenwerkzeug, das ProxMenux für jedes Backup und jede Wiederherstellung aufruft. Beschreibt Backup-IDs, Backup-Typen, Archive, Repository-Syntax und Umgebungsvariablen."
|
||||
},
|
||||
{
|
||||
"label": "Clientseitige Verschlüsselung",
|
||||
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
|
||||
"tail": " — Erzeugung der Schlüsseldatei, --kdf-Modi und das Verschlüsselungsmodell, das ProxMenux um eine passphrasengeschützte Wiederherstellungskopie erweitert."
|
||||
},
|
||||
{
|
||||
"label": "Datenspeicherverwaltung",
|
||||
"href": "https://pbs.proxmox.com/docs/storage.html",
|
||||
"tail": "Erstellen und Verwalten der Datenspeicher, die Host-Backups erhalten, einschließlich Chunk-Store-Layout und Berechtigungen."
|
||||
},
|
||||
{
|
||||
"label": "Aufbewahrungsregeln und Garbage Collection",
|
||||
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
|
||||
"tail": " — das Aufbewahrungsmodell hinter --keep-last / --keep-daily / --keep-weekly, das ProxMenux je geplantem Auftrag anwendet, sowie die Freigabe ungenutzter Blöcke durch PBS nach der Bereinigung."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Glossar - Backup & Restore | ProxMenux",
|
||||
"description": "Begriffe des ProxMenux-Sicherungs- und Wiederherstellungssystems: Verschlüsselung, Schlüsseldatei, Passphrase, Wiederherstellungsumschlag, PBS, Chunks, rootfs, Manifest, Ausführungsprozess und Ergänzung zwischen Kernel-Versionen.",
|
||||
"ogTitle": "Backup & Restore Glossar | ProxMenux",
|
||||
"ogDescription": "Klare Definitionen für das Vokabular, das in der ProxMenux-Backup- und Wiederherstellungsdokumentation verwendet wird.",
|
||||
"twitterTitle": "Backup & Restore Glossar | ProxMenux",
|
||||
"twitterDescription": "Passphrase, Keyfile, Recovery-Umschlag, Rootfs, Manifest, PBS, Brocken — alle an einer Stelle definiert."
|
||||
},
|
||||
"header": {
|
||||
"title": "Glossar",
|
||||
"description": "Begriffe, die in der Backup- und Wiederherstellungsdokumentation mit ihrer Definition verwendet werden.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"body": "Begriffe werden nach Themen gruppiert. Jeder Eintrag gibt den Begriff und eine kurze Definition."
|
||||
},
|
||||
"groups": [
|
||||
{
|
||||
"title": "Verschlüsselung und Key Recovery",
|
||||
"intro": "Vokabular für den PBS-Verschlüsselungsblock. Es beinhaltet zwei verschiedene Geheimnisse: eine binäre Schlüsseldatei und eine geschriebene Passphrase.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "passphrase-recuperacion",
|
||||
"term": "Wiederherstellungspassphrase",
|
||||
"def": "Textkennwort, das der Benutzer auswählt, um den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag </a> zu schützen. Es wird zweimal mit einer Übereinstimmungsprüfung aufgefordert und wird nur verwendet, um den Umschlag zu verschlüsseln und zu entschlüsseln, wenn die Schlüsseldatei jemals wiederhergestellt werden muss. <strong>Es ist nicht die Passphrase, die die Schlüsseldatei selbst entsperrt</strong> und wird niemals an PBS gesendet. Während eines normalen Backups verlässt es niemals den Host."
|
||||
},
|
||||
{
|
||||
"id": "clave-cifrado",
|
||||
"term": "Keyfile (Verschlüsselungsschlüssel)",
|
||||
"def": "Schlüsseldatei, mit der proxmox-backup-client die <a href=\"#chunk\">Chunks</a> vor dem Hochladen zu PBS verschlüsselt. Ohne passenden Schlüssel sind verschlüsselte Daten nicht lesbar. ProxMenux speichert sie unter <code>/usr/local/share/proxmenux/pbs-key.conf</code> mit Modus <code>600</code>. Schützen Sie sie; der <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a> dient ihrer Wiederherstellung bei Verlust."
|
||||
},
|
||||
{
|
||||
"id": "contrasena-keyfile",
|
||||
"term": "Keyfile Passphrase (KDF Passphrase)",
|
||||
"def": "Optionale Passphrase, die die Keyfile selbst tragen kann, im Unterschied zur <a href=\"#passphrase-recuperacion\">Recovery Passphrase</a>. Es existiert nur, wenn die Keyfile mit <code>--kdf scrypt</code> erstellt wurde (normalerweise eine importierte Keyfile). Ohne sie kann die Keyfile nicht für die Verwendung entsperrt werden. ProxMenux behält es in verschlüsselter Form auf dem Host, so dass geplante Backups ohne interaktive Eingabeaufforderung ausgeführt werden können."
|
||||
},
|
||||
{
|
||||
"id": "sobre-recuperacion",
|
||||
"term": "Wiederherstellungsumschlag",
|
||||
"def": "Das <a href=\"#clave-cifrado\">keyfile</a> ist in eine zusätzliche Schicht eingewickelt: Es ist mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> unter Verwendung von <a href=\"#aes-256-cbc\">AES-256-CBC</a> und <a href=\"#pbkdf2\">PBKDF2</a> verschlüsselt, bevor es den Host verlässt. Es wird auf PBS als <code>-keyrecovery</code>-Gruppe hochgeladen. Ohne die Passphrase ist der Umschlag undurchsichtig: Wenn Sie ihn von PBS herunterladen, wird die Schlüsseldatei nicht angezeigt."
|
||||
},
|
||||
{
|
||||
"id": "cifrado-cliente",
|
||||
"term": "Clientseitige Verschlüsselung",
|
||||
"def": "Verschlüsselungsmodell, bei dem Daten auf dem Quellhost verschlüsselt werden, bevor sie hochgeladen werden. PBS empfängt und speichert immer nur Geheimtext; nicht einmal ein PBS-Administrator mit Datenspeicherzugriff kann ihn ohne die Schlüsseldatei lesen. ProxMenux baut auf diesem Modell auf und fügt den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a> hinzu."
|
||||
},
|
||||
{
|
||||
"id": "kdf-none",
|
||||
"term": "--kdf none",
|
||||
"def": "Option auf <code>proxmox-backup-client key create</code>, die eine Schlüsseldatei ohne angehängte Passphrase erzeugt. Die Keyfile kann direkt ohne Aufforderung verwendet werden, was für geplante Aufträge, die unbeaufsichtigt ausgeführt werden, unerlässlich ist. Dies ist, was ProxMenux standardmäßig verwendet, wenn eine neue Keyfile erzeugt wird."
|
||||
},
|
||||
{
|
||||
"id": "kdf-scrypt",
|
||||
"term": "--kdf scrypt",
|
||||
"def": "Option auf <code>proxmox-backup-client key create</code>, die eine Schlüsseldatei erzeugt, die durch eine <a href=\"#contrasena-keyfile\">keyfile-Passphrase</a> geschützt ist. Jede Verwendung der Keyfile erfordert das Entsperren mit dieser Passphrase. ProxMenux akzeptiert diese Art von Keyfile beim Import und speichert die Passphrase verschlüsselt, so dass geplante Backups immer noch unbeaufsichtigt ausgeführt werden können."
|
||||
},
|
||||
{
|
||||
"id": "aes-256-cbc",
|
||||
"term": "AES-256-CBC",
|
||||
"def": "Standardsymmetrische Chiffre. ProxMenux verwendet es (über <code>openssl enc -aes-256-cbc</code>), um die <a href=\"#clave-cifrado\">Schlüsseldatei</a> mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> zu wickeln und die <a href=\"#sobre-recuperacion\">Umschlag</a> zu produzieren."
|
||||
},
|
||||
{
|
||||
"id": "pbkdf2",
|
||||
"term": "PBKDF2",
|
||||
"def": "Kryptografische Funktion, die eine vom Menschen typisierte Passphrase in einen für die Verschlüsselung geeigneten binären Schlüssel verwandelt. Es verlangsamt Brute-Force-Versuche, indem es viele Iterationen anwendet. ProxMenux verwendet es mit 600 000 Iterationen und einem Zufallssalz bei der Verschlüsselung des Recovery-Umschlags."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Backup-Struktur",
|
||||
"intro": "Begriffe, die beschreiben, was sich in einem Backup befindet, unabhängig vom Zielort.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "rootfs",
|
||||
"term": "rootfs / Root-Dateisystem",
|
||||
"def": "Dateibasierte Kopie des Dateisystems des Quellhosts, erstellt mit <code>rsync</code> nach dem <a href=\"#perfil-defecto\">Standardprofil</a> und zusätzlichen <a href=\"#rutas-personalizadas\">eigenen Pfaden</a>. Kein vollständiges Datenträgerabbild: Kopiert werden nur Pfade mit Konfiguration oder Zustand, die Proxmox nicht selbst wiederherstellen kann."
|
||||
},
|
||||
{
|
||||
"id": "manifiesto",
|
||||
"term": "Manifest (manifest.json)",
|
||||
"def": "Strukturiertes JSON-Dokument zur Beschreibung des Quell-Hosts zum Backup-Zeitpunkt: Hardware, Storage, Kernel, ProxMenux-installierte Komponenten und Inventar von VMs und LXCs. Es wird von sechs unabhängigen Erfassungsroutinen produziert. Der Wiederherstellungsfluss verwendet ihn, um Quelle und Ziel zu vergleichen."
|
||||
},
|
||||
{
|
||||
"id": "staging",
|
||||
"term": "Stagingverzeichnis",
|
||||
"def": "Temporäres Verzeichnis, in dem ProxMenux die drei Blöcke (rootfs, Metadaten und Manifest) zusammenstellt, bevor sie verpackt und zum Zielort hochgeladen werden. Es wird automatisch entfernt, wenn das Backup beendet ist, auch bei Abbruch."
|
||||
},
|
||||
{
|
||||
"id": "perfil-defecto",
|
||||
"term": "Standardprofil",
|
||||
"def": "Kuratierte Reihe von Pfaden, die ProxMenux standardmäßig in jedem Backup kopiert. Umfasst PVE-Konfiguration, Netzwerk, SSH, Kernel, apt, ProxMenux Tools und mehr. Es ist im Code definiert und auf der Seite <em>Wie es funktioniert</em> dokumentiert."
|
||||
},
|
||||
{
|
||||
"id": "rutas-personalizadas",
|
||||
"term": "Benutzerdefinierte Pfade",
|
||||
"def": "Zusätzliche Pfade, die der Benutzer zusätzlich zum <a href=\"#perfil-defecto\">default-Profil</a> hinzufügt. Entweder persistent (gespeichert in <code>backup-extra-paths.txt</code>) oder per Run (im Custom-Modus ausgewählt)."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Ziele und Speicher",
|
||||
"intro": "Begriffe, die an den Ort gebunden sind, an dem das Backup landet - PBS-Server, lokales Archiv oder Borg-Repository - und wie PBS die Daten organisiert.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "repositorio-pbs",
|
||||
"term": "PBS-Repository",
|
||||
"def": "Kombination von Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + Benutzer, der das Backup erhält. Identifiziert durch den String <code>user@realm@host:datastore</code>. Ein einzelner PBS-Server kann mehrere Repositories hosten."
|
||||
},
|
||||
{
|
||||
"id": "datastore",
|
||||
"term": "Datenspeicher",
|
||||
"def": "Konkreter Datenspeicher auf einem PBS-Server für Sicherungen und ihre Chunks. Er liegt auf einem Dateisystem des PBS-Servers und besitzt eigene Berechtigungen und Richtlinien."
|
||||
},
|
||||
{
|
||||
"id": "chunk",
|
||||
"term": "Chunk/Chunk-Deduplizierung",
|
||||
"def": "PBS teilt jedes Backup in Blöcke variabler Größe auf, identifiziert jedes Stück durch seinen Hash und speichert jedes Stück nur einmal, auch wenn es in vielen verschiedenen Backups erscheint. Dies bedeutet, dass aufeinanderfolgende Backups desselben Hosts - oder über ähnliche Hosts - sehr wenig zusätzlichen Speicherplatz benötigen."
|
||||
},
|
||||
{
|
||||
"id": "fingerprint",
|
||||
"term": "Fingerabdruck",
|
||||
"def": "Kryptografischer Fingerabdruck des PBS-Servers TLS Zertifikat. Der Client kann überprüfen, ob er mit dem vorgesehenen Server spricht, ohne sich auf eine öffentliche Zertifizierungsstelle zu verlassen. ProxMenux leitet sie über die Umgebungsvariable <code>PBS_FINGERPRINT</code> an <code>proxmox-backup-client</code> weiter."
|
||||
},
|
||||
{
|
||||
"id": "grupo-copia",
|
||||
"term": "Backup-Gruppe",
|
||||
"def": "Logischer Container innerhalb von PBS, unter dem sich aufeinanderfolgende Backups desselben Assets ansammeln. Jedes neue Backup teilt die Deduplizierung mit früheren in derselben Gruppe. ProxMenux verwendet zwei Gruppen pro Host, wenn die Verschlüsselung aktiviert ist: eine für das Host-Backup und eine mit einem <code>-keyrecovery</code>-Suffix für den <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a>."
|
||||
},
|
||||
{
|
||||
"id": "backup-id",
|
||||
"term": "Backup-ID",
|
||||
"def": "Name der <a href=\"#grupo-copia\">backup-Gruppe</a>. ProxMenux ist standardmäßig <code>hostcfg-HOSTNAME</code> und lässt den Benutzer es vor dem Hochladen bearbeiten; nicht unterstützte Zeichen werden automatisch entfernt."
|
||||
},
|
||||
{
|
||||
"id": "pxar",
|
||||
"term": ".pxar",
|
||||
"def": "PBS-natives Archivformat für Verzeichnisse. Es verhält sich wie ein für die Chunk-Deduplizierung optimierter tar-Archiv: Anstatt eine undurchsichtige Datei zu speichern, zerlegt PBS seinen Inhalt in wiederverwendbare Chunks."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Ausführung und Terminplanung",
|
||||
"intro": "Begriffe, die vom ProxMenux-Planed-Jobs-System verwendet werden.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "runner",
|
||||
"term": "Ausführungsprozess",
|
||||
"def": "Das <code>run_scheduled_backup.sh</code>-Script, das ein geplantes Backup ausführt. Es liest die Job-Konfiguration, startet das passende Backend (Local, PBS oder Borg), wendet nach Erfolg die Aufbewahrungsregeln an und sendet die konfigurierten Benachrichtigungen."
|
||||
},
|
||||
{
|
||||
"id": "trabajo-programado",
|
||||
"term": "Geplanter Auftrag",
|
||||
"def": "Beharrliche Konfiguration eines wiederkehrenden Backups. Behält Ziel, Anmeldeinformationen, Verschlüsselung, Zeitplan und Aufbewahrung. Lebt bei <code>/var/lib/proxmenux/backup-jobs/<id>.env</code>."
|
||||
},
|
||||
{
|
||||
"id": "modo-adjunto",
|
||||
"term": "Anhängemodus",
|
||||
"def": "Auftrag ohne eigenen Timer. Ein job-end-Hook von PVE-<code>vzdump</code> startet ihn nach Gastsicherungen bei passendem Zielspeicher. Der gewählte Elternauftrag liefert Speicher und Aufbewahrung, die bei jedem Lauf erneut aus dem Elternauftrag gelesen wird; der Hook vergleicht aber Speicher statt Auftrags-ID. Auch andere Aufgaben desselben Speichers können ihn auslösen. Nur Local und PBS."
|
||||
},
|
||||
{
|
||||
"id": "timer-systemd",
|
||||
"term": "Systemd Timer",
|
||||
"def": "Standard-systemd-Mechanismus, der einen Befehl in einem Kalender auslöst. ProxMenux erstellt einen Timer pro <em>unabhängigem</em> geplanten Job; <a href=\"#modo-adjunto\">attach-mode</a> Jobs verwenden keinen Timer, sie laufen über den PVE-Skript-Hook."
|
||||
},
|
||||
{
|
||||
"id": "retencion",
|
||||
"term": "Aufbewahrung (keep-last, keep-daily…)",
|
||||
"def": "Richtlinie, die entscheidet, welche älteren Backups aufbewahrt und welche beschnitten werden sollen. Definiert pro Auftrag mit Parametern wie <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Wird vom Ausführungsprozess nach jedem erfolgreichen Backup angewendet."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Wiederherstellen",
|
||||
"intro": "Terme aus dem Wiederherstellungsfluss.",
|
||||
"entries": [
|
||||
{
|
||||
"id": "restauracion-universal",
|
||||
"term": "Universale Wiederherstellung",
|
||||
"def": "Der ProxMenux-Wiederherstellungsfluss extrahiert nicht nur das Dateisystem: Er liest das Manifest, um Unterschiede zwischen Quelle und Ziel zu erkennen, reproduziert die Systemkonfiguration und führt die Installateure für die ProxMenux-verwalteten Komponenten erneut aus. Ziel ist es, den Quellhost zu reproduzieren, nicht nur das Archiv."
|
||||
},
|
||||
{
|
||||
"id": "hidratacion",
|
||||
"term": "Ergänzung zwischen Kernel-Versionen (Hydration)",
|
||||
"def": "Wiederherstellungsschritt, der die eigene Quellkonfiguration (IOMMU-Parameter, VFIO-Geräte-IDs, eigene Anpassungen und GRUB-Schlüssel) in die frische Boot-Konfiguration des Ziels übernimmt, ohne kernelgebundene Quelldateien unverändert zu kopieren. Läuft, wenn der Zielkernel neuer als der der Sicherung ist."
|
||||
},
|
||||
{
|
||||
"id": "cross-kernel",
|
||||
"term": "Kernübergreifende Wiederherstellung",
|
||||
"def": "Wiederherstellung, bei der der Zielkernel vom Quellkernel abweicht und meist neuer ist. Der <a href=\"#hidratacion\">Ergänzungsschritt</a> verhindert die Übernahme von Dateien, die mit dem Zielkernel inkompatibel sind."
|
||||
},
|
||||
{
|
||||
"id": "instalador-postboot",
|
||||
"term": "Installateur nach dem Booten",
|
||||
"def": "Komponenten, die nach dem ersten Booten des wiederhergestellten Hosts neu installiert wurden (NVIDIA-Treiber, Coral TPU-Treiber, AMD GPU-Tools, Intel GPU-Tools). Jeder Installer läuft gegen den Kernel des Ziels, so dass der wiederhergestellte Host nicht davon abhängt, ob der Kernel der Quelle vorhanden ist."
|
||||
},
|
||||
{
|
||||
"id": "compatibility-check",
|
||||
"term": "Kompatibilitätsprüfung",
|
||||
"def": "Vergleich zwischen dem Quellenmanifest und dem Zustand des Ziels, den ProxMenux zu Beginn der Wiederherstellung durchführt. Es entscheidet, welche Teile wortwörtlich kopiert werden, welche Hydratation benötigen und welche von einem Installateur neu erstellt werden."
|
||||
},
|
||||
{
|
||||
"id": "equipo-recien-instalado",
|
||||
"term": "Frische Installation",
|
||||
"def": "Host nur von Grund auf neu installiert, ohne lokale <a href=\"#clave-cifrado\">Schlüsseldatei</a>. Um ein verschlüsseltes Backup wiederherzustellen, muss zunächst die Schlüsseldatei aus der <a href=\"#sobre-recuperacion\">Wiederherstellungsumschlag</a>, die auf PBS gespeichert ist, mit der <a href=\"#passphrase-recuperacion\">Wiederherstellungspassphrase</a> wiederhergestellt werden."
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"whereNext": {
|
||||
"heading": "Wo als nächstes",
|
||||
"items": [
|
||||
{
|
||||
"label": "Wie es funktioniert",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "- wo das Rootfs-, Manifest- und Anwendungsinventar in ein Backup passt."
|
||||
},
|
||||
{
|
||||
"label": "Proxmox-Backup-Server-Ziel",
|
||||
"href": "/docs/backup-restore/destinations/pbs",
|
||||
"tail": "- wobei clientseitige Verschlüsselung, Keyfile, Recovery-Passphrase und Envelope ausführlich dokumentiert sind."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — Wiederherstellungsablauf und Verwendung des Manifests."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,205 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Wie ProxMenux Backup intern funktioniert – Rootfs, Manifest, Anwendungen",
|
||||
"description": "Detaillierte Aufschlüsselung dessen, was ein ProxMenux-Backup enthält: die Rootfs, die von rsync des Standardpfadprofils erzeugt werden, das strukturierte Manifest, das von sechs unabhängigen Sammlern erstellt wird, und das Anwendungsinventar, das die automatische Neuinstallation von Paketen und Komponenten nach einer Wiederherstellung steuert.",
|
||||
"ogTitle": "Wie ProxMenux Backup intern funktioniert",
|
||||
"ogDescription": "Die drei Nutzlasten eines ProxMenux-Backups wurden erklärt: Rootfs, Manifest und Anwendungen.",
|
||||
"twitterTitle": "Wie ProxMenux Backup funktioniert | ProxMenux",
|
||||
"twitterDescription": "Die drei Nutzlasten eines ProxMenux-Backups und wie die Wiederherstellung den Quellhost von ihnen reproduziert."
|
||||
},
|
||||
"header": {
|
||||
"title": "Wie es funktioniert",
|
||||
"description": "Die interne Aufschlüsselung eines ProxMenux-Backups - Dateisystem, Manifest und Anwendungsinventar - und wie die Wiederherstellung alle drei verbraucht, um den Quellhost auf einem Ziel zu reproduzieren, das möglicherweise nicht den gleichen Kernel teilt.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ein Archiv, drei Nutzlasten",
|
||||
"body": "Jedes Backup erzeugt drei klar getrennte Datenblöcke unter einem gemeinsamen Vorbereitungsverzeichnis. Das hochgeladene Archiv (lokales <code>.tar.zst</code>, PBS-Backup oder Borg-Archiv) enthält genau diese Struktur. Die Wiederherstellung nutzt alle drei: <strong>Das Manifest</strong> wird vor Änderungen ausgewertet, um Abweichungen zu erkennen und Ausschlüsse festzulegen; <strong>rootfs</strong> liefert die Konfigurationsdateien, die direkt oder nach einem Neustart angewendet werden; <strong>das Anwendungsinventar</strong> steuert die Paketinstallation und die Neuinstallation der Komponenten nach dem Start. Jeder Block lässt sich unabhängig untersuchen oder entpacken."
|
||||
},
|
||||
"layout": {
|
||||
"heading": "Archivlayout",
|
||||
"intro": "Jedes Archiv folgt dem gleichen Baumlayout, unabhängig vom Zielort. Das <code>metadata/</code>-Unterverzeichnis enthält die strukturierten Nutzlasten; das <code>rootfs/</code>-Unterverzeichnis enthält die Dateisystemkopie.",
|
||||
"treeCaption": "Das beim Backup angelegte Vorbereitungsverzeichnis. Alle Ziele erhalten denselben Verzeichnisbaum in ihrem nativen Format: tar bei lokalen Zielen, PBS-Blöcke bei PBS und Borg-Segmente bei Borg.",
|
||||
"tree": "backup-[timestamp]/\n├── manifest.json # structured host state\n├── metadata/\n│ ├── packages.manual.list # apt-mark showmanual\n│ ├── run_info.env # backup run identity + kernel version + pmxcfs method\n│ ├── paths_archived.txt # exact list of paths that reached rootfs/\n│ └── missing_paths.txt # paths from the profile absent on source\n└── rootfs/\n ├── etc/ # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n ├── root/ # /root (with volatile subdirs excluded)\n ├── usr/local/ # /usr/local/bin, /usr/local/share/proxmenux, …\n └── var/ # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
|
||||
},
|
||||
"rootfs": {
|
||||
"heading": "Die Rootfs Nutzlast",
|
||||
"intro": "Der Verzeichnisbaum <code>rootfs/</code> ist eine <strong>einfache Dateisystemkopie</strong>, die <code>rsync</code> vom Quellhost erstellt. Er enthält ein ausgewähltes <strong>Standardprofil</strong> der für eine Proxmox-Wiederherstellung wichtigen Pfade sowie <strong>eigene Pfade</strong>, die der Benutzer zum Backup-Auftrag oder zur interaktiven Sitzung hinzufügt. Die Auswahl ist bewusst eng: nur Pfade, die <em>Konfiguration enthalten</em> oder <em>Zustand speichern, den Proxmox nicht selbst wiederherstellen kann</em>.",
|
||||
"defaultProfileTitle": "Das Standardprofil",
|
||||
"defaultProfileBody": "Das Standardprofil wird durch <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code> definiert. Es umfasst acht feste Kategorien und bei Bedarf den ZFS-Zustand, die zusammen einen funktionierenden Proxmox-Host beschreiben:",
|
||||
"categoriesTitle": "Pfadkategorien",
|
||||
"categoryRows": [
|
||||
{
|
||||
"category": "PVE-Kern",
|
||||
"paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
|
||||
"why": "Cluster-Dateisysteminhalte und vzdump-Standards. Die pmxcfs-Datenbank (<code>config.db</code>) wird als konsistenter Snapshot über <code>sqlite3 .backup</code> erfasst, ohne den Cluster zu stoppen, und die <code>.db-wal</code> / <code>.db-shm</code> Sidecars sind vom rsync ausgeschlossen. Wenn <code>sqlite3</code> nicht verfügbar ist, wird stattdessen <code>config.db.raw-fallback</code> erstellt und bei der Wiederherstellung automatisch als Datenbank übernommen."
|
||||
},
|
||||
{
|
||||
"category": "Host-Identität und Netzwerk",
|
||||
"paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
|
||||
"why": "Alles, was der Host für den Netzwerkstart mit derselben Identität benötigt. Die <code>.link</code>-Dateien unter <code>/etc/systemd/network</code> ordnen Netzwerkkartennamen ihren MAC-Adressen zu, damit Neuinstallationen und Hardwareänderungen die Schnittstellen nicht umbenennen."
|
||||
},
|
||||
{
|
||||
"category": "Zugriff und Authentifizierung",
|
||||
"paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
|
||||
"why": "SSH Schlüssel, Sudo Regeln und PAM Konfiguration. Wenn Sie diese verlieren, wird der Benutzer aus dem wiederhergestellten Host ausgeschlossen."
|
||||
},
|
||||
{
|
||||
"category": "Kernel und Boot",
|
||||
"paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
|
||||
"why": "IOMMU-Token, Modul-Blacklists, VFIO-Geräte-IDs, Mount-Tabelle, Storage-Stack-Konfiguration."
|
||||
},
|
||||
{
|
||||
"category": "Shell und Gebietsschema",
|
||||
"paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
|
||||
"why": "Systemweite Shell-Einrichtung, Umgebungsvariablen und Konfiguration der Gebietsschema-Erzeugung."
|
||||
},
|
||||
{
|
||||
"category": "Paketverwaltung und cron",
|
||||
"paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
|
||||
"why": "APT-Quellen für konsistente Paketauflösung, geplante Aufgaben, die vom Benutzer definiert werden."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux Zustand & Werkzeuge",
|
||||
"paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
|
||||
"why": "Optionale, aber übliche Proxmox-Werkzeuge. Fehlende Pfade werden in <code>metadata/missing_paths.txt</code> vermerkt, ohne das Backup zu stoppen."
|
||||
},
|
||||
{
|
||||
"category": "ProxMenux Binärdateien und root",
|
||||
"paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (ausgenommen flüchtige Subdir)",
|
||||
"why": "ProxMenux-installierte Binärdateien und Konfiguration pro Benutzer unter <code>/root</code>. Flüchtige Pfade (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) sind von der Kopie ausgeschlossen. <code>/var/lib/proxmenux</code> hält die geplanten Backup-Jobs und den Host-Status, der von ProxMenux beibehalten wird; das Wiederherstellungsstaging, die Rollback-Kopien und die Post-Restore-Marker sind ausgeschlossen, da sie zu dem Host gehören, der eine Wiederherstellung ausführt."
|
||||
},
|
||||
{
|
||||
"category": "ZFS-Zustand (bedingter Zustand)",
|
||||
"paths": "/etc/zfs",
|
||||
"why": "Nur enthalten, wenn der Quellhost ZFS ausführt. Enthält <code>zpool.cache</code> und <code>hostid</code>."
|
||||
}
|
||||
],
|
||||
"customTitle": "Erweiterung des Profils mit benutzerdefinierten Pfaden",
|
||||
"customBody": "Neben dem Standardprofil bietet ProxMenux zwei Möglichkeiten, zusätzliche Pfade in ein Backup aufzunehmen. Sie komponieren ohne Konflikte und gelten beide für interaktive Backups und geplante Jobs.",
|
||||
"customExtrasTitle": "1. Persistente Extras (Pro-Host-Datei)",
|
||||
"customExtrasBody": "Eine Textdatei bei <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> enthält eine Liste absoluter Pfade, die der Benutzer auf diesem Host als \"immer einschließen\" markiert hat. Wenn ein Backup im <strong>Default</strong>-Modus ausgeführt wird, fügt ProxMenux diese Pfade automatisch an das Standardprofil an, ohne zu fragen. Die Datei wird von der Benutzeroberfläche aus bearbeitet - keine manuelle Bearbeitung erforderlich - und bleibt bei Neustarts und Updates bestehen. Ein absoluter Pfad pro Zeile; <code>#</code>-Kommentare sind zulässig.",
|
||||
"customModeTitle": "2. Benutzerdefinierter Modus (per Lauf)",
|
||||
"customModeBody": "Das Starten eines Backups im <strong>Custom</strong>-Modus ersetzt die automatische Anwendung des Standardprofils durch eine Checkliste, die jeden Pfad anzeigt: die Standardprofileinträge und die persistenten Extras (vorangestellt mit <code>[+]</code> und bereits ausgewählt). Der Benutzer aktiviert oder deaktiviert Einträge für diesen bestimmten Lauf und kann auch <em>Eigenen Pfad hinzufügen</em> drücken, um einen neuen Pfad einzugeben - der dann für zukünftige Backups auf der Extras-Datei verbleibt.",
|
||||
"customMissingTitle": "Aus der Quelle fehlende Pfade",
|
||||
"customMissingBody": "Jeder Pfad aus dem Profil (Standard oder hinzugefügt), der auf dem Quellhost nicht vorhanden ist, wird in <code>metadata/missing_paths.txt</code> im Archiv aufgezeichnet. Das Backup schlägt nicht fehl und stoppt nicht – der Benutzer sieht am Ende eine Zusammenfassung der archivierten Pfade und fehlenden Pfade. In der Praxis geschieht dies bei optionalen Werkzeugpfaden wie <code>/etc/wireguard</code> oder <code>/etc/prometheus</code>, wenn diese Werkzeuge nicht installiert sind."
|
||||
},
|
||||
"manifest": {
|
||||
"heading": "Der Manifest-Datenblock",
|
||||
"intro": "<code>manifest.json</code> ist ein strukturiertes JSON-Dokument, das den Quellhost zum Zeitpunkt des Backups beschreibt. Es wird von <strong>sechs unabhängigen Erfassungsskripten</strong> orchestriert von <code>build_manifest.sh</code> produziert. Jeder Kollektor ist schreibgeschützt, erzeugt ein gut definiertes JSON-Fragment und fällt bei einem Ausfall auf einen sicheren leeren Standard zurück - das Manifest ist immer noch verwendbar, wenn ein Abschnitt unvollständig ist.",
|
||||
"orchestratorCaption": "Die sechs Sammler verfassen das Manifest. Jeder Kollektor läuft in seinem eigenen Subprozess; ein Fehler in einem fällt auf einen dokumentierten sicheren Standard zurück und warnt, bricht aber das Backup nicht ab.",
|
||||
"collectorRows": [
|
||||
{
|
||||
"collector": "collect_source_host.sh",
|
||||
"produces": "source_host",
|
||||
"content": "Hostname, PVE-Version (<code>pveversion</code>), PBS-Version, wenn der Host die Backup-Server-Rolle ausführt, Kernel (<code>uname -r</code>), Boot-Modus (efi/bios), Root-Dateisystemtyp, CPU-Modell + Architektur, Speicher in KB."
|
||||
},
|
||||
{
|
||||
"collector": "collect_hardware.sh",
|
||||
"produces": "hardware_inventory",
|
||||
"content": "GPUs (mit Hersteller- und ProxMenux-Installationsprogramm), TPUs (Coral USB + M.2 mit <code>lsusb</code>/<code>lspci</code>-Erkennung), NICs (mit MAC-, PCI-Slot- und Bridge-Mitgliedschaft), drahtlose Geräte. GPU-Einträge tragen eine <code>passthrough_eligible</code>-Heuristik."
|
||||
},
|
||||
{
|
||||
"collector": "collect_storage.sh",
|
||||
"produces": "storage_inventory",
|
||||
"content": "ZFS-Pools (mit Pooltyp + Mitglieds-Festplatten, die nach <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> oder rohen <code>/dev/sdX</code>-Pfaden aufgelöst wurden, je nachdem, wie jeder Pool ursprünglich erstellt wurde), LVM-Volumengruppen + dünne Pools, physische Festplatten mit SMART-Fähigkeit, PVE <code>storage.cfg</code>-Einträge, externe Mounts."
|
||||
},
|
||||
{
|
||||
"collector": "collect_kernel.sh",
|
||||
"produces": "kernel_params",
|
||||
"content": "Vom Betreiber hinzugefügte Parameter aus <code>/proc/cmdline</code>, ohne übliche Standardwerte wie <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> und <code>splash</code>; beim Start geladene Module aus <code>/etc/modules</code>; sowie Pfade der Dateien <code>/etc/modprobe.d/*.conf</code> mit tatsächlichen Direktiven (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
|
||||
},
|
||||
{
|
||||
"collector": "collect_proxmenux_state.sh",
|
||||
"produces": "proxmenux_installed_components",
|
||||
"content": "Lesen Sie <code>/usr/local/share/proxmenux/managed_installs.json</code> (Registrierung von allem, was ProxMenux installiert hat) und <code>installed_tools.json</code>. Jeder Eintrag behält den Installationspfad (<code>menu_script</code>) bei, so dass die Wiederherstellung genau den gleichen Installationsfluss auslösen kann."
|
||||
},
|
||||
{
|
||||
"collector": "collect_guests.sh",
|
||||
"produces": "vms_lxcs_at_backup",
|
||||
"content": "Zählt VMs (<code>qm list</code>) und LXCs (<code>pct list</code>) auf, die zum Backup-Zeitpunkt vorhanden sind — VMID, Name, aktueller Status. Nur das Inventar: Die eigentlichen Gästedaten liegen in der Verantwortung von <code>vzdump</code> / PBS."
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validierung des Schemas",
|
||||
"schemaBody": "Das Manifest bestätigt gegen <code>scripts/backup_restore/schema/manifest.schema.json</code>. Das Ausführen von <code>build_manifest.sh --validate</code> löst eine Python-seitige JSON-Schemavalidierung aus (erfordert <code>python3</code> + <code>jsonschema</code>). Wenn das Modul nicht vorhanden ist, wird die Überprüfung still übersprungen - die Validierung ist in erster Linie eine Entwicklerhilfe, keine Laufzeitabhängigkeit."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "Das Anwendungsinventar",
|
||||
"intro": "Zwei Inventare erfassen die zusätzlich zu den Proxmox-VE-Basispaketen installierte Software: die Paketliste unter <code>metadata/</code> und das Komponentenverzeichnis im rootfs, beide unten beschrieben. Die Wiederherstellung installiert die Benutzersoftware je nach ursprünglichem Installationsweg mit APT oder den ProxMenux-Installationsskripten neu.",
|
||||
"packagesTitle": "packages.manual.list",
|
||||
"packagesBody": "Eine alphabetisch sortierte Textliste aus <code>apt-mark showmanual</code> mit allen auf dem Quellhost <em>ausdrücklich installierten</em> APT-Paketen. Als Abhängigkeiten des Proxmox-VE-Basissystems installierte Pakete fehlen darin; APT auf dem Ziel zieht sie selbst nach. Bei der Wiederherstellung liest <code>_rs_run_complete_extras</code> die Liste und wendet einen dreistufigen <em>Filter gegen Kaskadenentfernung</em> an: <code>dpkg -s</code> erkennt bereits installierte Pakete, für Bibliotheken werden vorhandene andere Hauptversionen erkannt und <code>apt-get install --simulate</code> prüft das Risiko von Folgeentfernungen. Danach folgt <code>apt-get install -y</code>.",
|
||||
"componentsTitle": "components_status.json (Teil des rootfs)",
|
||||
"componentsBody": "Ein JSON-Verzeichnis unter <code>/usr/local/share/proxmenux/</code> erfasst jede von ProxMenux installierte Komponente mit ihrem genauen Zustand: Version und ProxMenux-spezifische Merkmale (bei NVIDIA der boolesche Wert <code>patched</code>, bei Coral die DKMS-Version). Die Datei liegt im rootfs und nicht unter <code>metadata/</code>, weil sie <em>erst gelesen wird, nachdem</em> das rootfs auf das Ziel kopiert wurde. Der nach dem Start ausgeführte Dispatcher (<code>apply_cluster_postboot.sh</code>) geht alle Einträge durch und ruft den <code>--auto-reinstall</code>-Hook der jeweiligen Komponente auf. Dieser liest den gespeicherten Zustand und stellt die Installation für den aktuellen Kernel des Zielsystems wieder her.",
|
||||
"componentInstallersTitle": "Installationsskripte für Komponenten",
|
||||
"componentInstallersBody": "Vier ProxMenux-Installateure stellen derzeit einen <code>--auto-reinstall</code>-Einstiegspunkt frei:",
|
||||
"installerRows": [
|
||||
{
|
||||
"component": "nvidia_driver",
|
||||
"installer": "gpu_tpu/nvidia_installer.sh",
|
||||
"action": "Lesen Sie <code>version</code> + <code>patched</code>. Downloads der exakt gleichen NVIDIA-Runfile, baut DKMS-Module gegen den Kernel des Ziels und wendet den ProxMenux-Patch erneut an, wenn die Quelle ihn hatte."
|
||||
},
|
||||
{
|
||||
"component": "coral_driver",
|
||||
"installer": "gpu_tpu/install_coral.sh",
|
||||
"action": "Lesen Sie die Coral Driver Version. Kompiliert das DKMS-Modul gegen den Kernel des Ziels."
|
||||
},
|
||||
{
|
||||
"component": "amdgpu_top",
|
||||
"installer": "gpu_tpu/amd_gpu_tools.sh",
|
||||
"action": "Lesen Sie die aufgezeichnete Version. Laden Sie die genaue <code>.deb</code> aus dem GitHub-Release erneut herunter."
|
||||
},
|
||||
{
|
||||
"component": "intel_gpu_tools",
|
||||
"installer": "gpu_tpu/intel_gpu_tools.sh",
|
||||
"action": "APT installiert das Paket. Idempotent, wenn bereits vorhanden von <code>packages.manual.list</code>."
|
||||
}
|
||||
]
|
||||
},
|
||||
"restoreFlow": {
|
||||
"heading": "Wie die Wiederherstellung die drei Nutzlasten verbraucht",
|
||||
"intro": "Die Wiederherstellung ist eine sechsstufige Pipeline. Jede Stufe liest eine bestimmte Untergruppe des Archivs und aktualisiert den Zielhost. Keine Stufe erfordert, dass der Quellhost erreichbar ist - das Archiv ist vollständig in sich geschlossen.",
|
||||
"stagesCaption": "Stufe 1 wertet das Manifest aus und legt fest, was geändert werden darf. Stufe 2 kopiert rootfs-Pfade, die auf dem laufenden System angewendet werden können. Stufe 3 bereitet riskante Pfade für den nächsten Start vor. Stufe 3b importiert ZFS-Datenpools ohne Root-Dateisystem, deren Datenträger vollständig vorhanden sind. Stufe 4 installiert Pakete. Stufe 5 installiert nach dem Neustart Komponenten für den Kernel des Ziels neu.",
|
||||
"stageRows": [
|
||||
{
|
||||
"stage": "1",
|
||||
"name": "Kompatibilitätsprüfung",
|
||||
"reads": "manifest.json",
|
||||
"action": "Läuft <code>hb_compat_check</code> aus. Vergleicht Quelle und Zielhardware (NICs, Storage IDs), PVE-Version und Hauptkernel-Version. Setzt <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> oder <code>bk_older</code>) ein und füllt <code>RS_SKIP_PATHS</code> mit Hardware-Drift- und Cross-Kernel-Ausschlüssen."
|
||||
},
|
||||
{
|
||||
"stage": "2",
|
||||
"name": "Anwenden im laufenden Betrieb",
|
||||
"reads": "rootfs/ (nur sichere Pfade)",
|
||||
"action": "<code>_rs_apply … hot</code> kopiert <code>hb_classify_path</code>=<code>hot</code>-Einträge direkt auf das Live-Ziel. Alles, was unter <code>/etc/pve</code>, <code>/etc/network</code> oder als <em>reboot</em>/<em>dangerous</em> klassifiziert ist, wird verschoben."
|
||||
},
|
||||
{
|
||||
"stage": "3",
|
||||
"name": "Ausstehende Vorbereitung",
|
||||
"reads": "rootfs/ (Reboot + gefährliche Pfade)",
|
||||
"action": "<code>_rs_prepare_pending_restore</code> bereitet riskante Pfade unter <code>/var/lib/proxmenux/pending-restore/</code> vor, schreibt <code>plan.env</code>, <code>apply-on-boot.list</code> und <code>rs-skip-paths.txt</code> und aktiviert <code>proxmenux-restore-onboot.service</code> für den nächsten Start."
|
||||
},
|
||||
{
|
||||
"stage": "3b",
|
||||
"name": "Import von Datenpools",
|
||||
"reads": "manifest.storage_inventory + ZFS-Zustand des Ziels",
|
||||
"action": "<code>_rs_import_data_pools</code> importiert jeden Nicht-Root-ZFS-Pool, dessen vollständiger Satz von Festplatten auf dem Ziel vorhanden ist. Pools mit einem fremden Hostid werden mit <code>zpool import -f</code> getestet. Pools, denen eine Festplatte fehlt, werden mit einer Warnung übersprungen. Das Ergebnis pro Pool wird in <code>/var/log/proxmenux/restore-datapools-<timestamp>.log</code> aufgezeichnet."
|
||||
},
|
||||
{
|
||||
"stage": "4",
|
||||
"name": "Paketinstallation",
|
||||
"reads": "metadata/packages.manual.list",
|
||||
"action": "<code>_rs_run_complete_extras</code> führt den kaskadensicheren Filter aus und ruft <code>apt-get install -y</code> mit der Paketliste auf. Die volle Ausgabe geht an <code>/var/log/proxmenux/restore-apt-*.log</code>."
|
||||
},
|
||||
{
|
||||
"stage": "5",
|
||||
"name": "Postboot",
|
||||
"reads": "rootfs (bereits angewendet) + components_status.json",
|
||||
"action": "Nach dem Neustart spielt <code>apply_pending_restore.sh</code> die zurückgestellten Pfade ab und <code>apply_cluster_postboot.sh</code> läuft <code>update-initramfs</code>, <code>update-grub</code> (oder <code>proxmox-boot-tool refresh</code>) und iteriert über <code>components_status.json</code> und feuert den <code>--auto-reinstall</code>-Hook jeder Komponente."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyItWorks": {
|
||||
"heading": "Warum der Drei-Payload-Split verwendet wird",
|
||||
"body": "Die Aufteilung richtet sich nach dem <strong>Lebenszyklus</strong> der Daten. Dateisysteminhalte werden mit <code>rsync</code> übertragen: schnell, nachvollziehbar und atomar je Datei. Der vor Änderungen auszuwertende Konfigurationszustand liegt als <strong>strukturiertes JSON</strong> vor: unabhängig lesbar, per Schema versionierbar und maschinell mit dem Zielzustand vergleichbar. Neu zu installierende Software wird als <strong>Inventar</strong> mit Namen und Versionen erfasst. Der Paketmanager des Ziels und die ProxMenux-Installationsskripte wählen die passenden Binärdateien. Jeder Datenblock erfüllt seine eigene Aufgabe. Zusammen ermöglichen sie eine auf konsistente Wiederherstellung ausgerichtete, fehlertolerante Verarbeitung: Bei beschädigtem Manifest bleibt rootfs wiederherstellbar; ein fehlendes Paket verhindert die Komponenteninstallation nicht; scheitert ein Komponenteninstallationsskript an einem Eintrag, wird der nächste trotzdem bearbeitet."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,93 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Sichern und Wiederherstellen – Übersicht | Vollständige Hostsicherung und -wiederherstellung für Proxmox VE",
|
||||
"description": "ProxMenux Backup & Restore erfasst den vollständigen Zustand eines Proxmox-Hosts – Dateisystem, strukturiertes Konfigurationsmanifest und installierte Pakete/Komponenten – und reproduziert ihn auf demselben oder einem anderen Host. Das Backup und die Wiederherstellung sind in sich geschlossen: keine externen Abhängigkeiten und Kernel-übergreifende Wiederherstellungen werden durch einen richtungsbewussten Safe-Subset-Filter und eine Kernel-agnostische Hydratation unterstützt.",
|
||||
"ogTitle": "ProxMenux Sicherung und Wiederherstellung – Übersicht",
|
||||
"ogDescription": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE mit strukturiertem Manifest, Paketliste und Neuinstallationsprogrammen für Komponenten.",
|
||||
"twitterTitle": "ProxMenux Sichern und Wiederherstellen | ProxMenux",
|
||||
"twitterDescription": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE mit strukturiertem Manifest, Paketliste und Komponenten-Neuinstallationsprogrammen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sichern und Wiederherstellen",
|
||||
"description": "Vollständige Hostsicherung und -wiederherstellung für Proxmox VE. Erfasst Dateisystem, Konfiguration und installierte Komponenten in einem einzigen Archiv und reproduziert den Host auf derselben oder einer anderen Proxmox-Installation ohne externe Abhängigkeiten.",
|
||||
"section": "Sichern und Wiederherstellen"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was es ist, in einem Absatz",
|
||||
"body": "Eine ProxMenux-Sicherung erfasst den vollständigen Zustand eines Proxmox-Hosts: <strong>das Dateisystem</strong> mit den relevanten Verzeichnissen unter <code>/etc</code>, <code>/root</code> und <code>/var/lib/pve-cluster</code> sowie optionalen eigenen Pfaden; <strong>ein strukturiertes Manifest</strong> im JSON-Format mit erkannter Hardware, Kernel-Parametern, Netzwerkkonfiguration, ZFS-Zustand, Benutzern und Cron-Einträgen; und <strong>ein Anwendungsinventar</strong> mit allen von APT als manuell installiert markierten Paketen und den von ProxMenux installierten Komponenten samt exakten Versionen. Alle drei unterstützten Ziele – lokales Archiv, Proxmox Backup Server (empfohlen) und Borg – erhalten denselben eigenständigen Datenbestand. Mit jedem davon lässt sich der Zielhost wiederherstellen, ohne dass der Quellhost während der Wiederherstellung erreichbar sein muss."
|
||||
},
|
||||
"video": {
|
||||
"heading": "Videoanleitung",
|
||||
"intro": "Beobachten Sie Backup & Restore lieber in Aktion, bevor Sie es konfigurieren? Diese exemplarische Vorgehensweise umfasst eine vollständige End-to-End-Demo der Funktion in ProxMenux.",
|
||||
"title": "ProxMenux – Anleitung zum Sichern und Wiederherstellen",
|
||||
"caption": "Externes Video auf YouTube. Spielt im erweiterten Datenschutzmodus (keine Cookies, bis Sie auf „Play“ drücken)."
|
||||
},
|
||||
"whatItIsNot": {
|
||||
"heading": "Was es nicht ist",
|
||||
"intro": "Dieser Abschnitt beschreibt Sicherung und Wiederherstellung <strong>auf Host-Ebene</strong>: die Proxmox-Installation selbst, nicht die darauf ausgeführten Anwendungen und Gastsysteme.",
|
||||
"items": [
|
||||
"<strong>Dies ist kein Sicherungswerkzeug für VMs oder CTs.</strong> Gastfestplatten und RAM-Zustand werden nicht erfasst; dafür ist <code>vzdump</code> zuständig. Die <strong>Konfigurationsdateien</strong> der Gäste (<code>/etc/pve/nodes/<node>/qemu-server/*.conf</code> und <code>lxc/*.conf</code>) werden <strong>jedoch</strong> gesichert. Nach der Wiederherstellung erscheint das Gastinventar erneut, und die Festplatten können aus einer vorhandenen PBS- oder lokalen Sicherung wiederhergestellt und zugeordnet werden.",
|
||||
"<strong>Dies ist kein clusterweiter Vorgang.</strong> Jeder Knoten sichert sich selbst. Die Clusterzugehörigkeit wird mit <code>/etc/pve</code> erfasst, sodass ein wiederhergestellter Knoten erneut aufgenommen werden kann. Die Wiederherstellung eines ganzen Clusters erfordert jedoch die Abstimmung zwischen den einzelnen Knoten.",
|
||||
"<strong>Dies ist kein vollständiges Festplattenabbild.</strong> Kernel-Binärdateien, initramfs und Boot-Partition werden nicht gesichert. Bei der Wiederherstellung nutzt ProxMenux die Boot-Dateien des Zielhosts, die mit <code>update-initramfs</code> und dem Bootloader-Werkzeug automatisch neu erzeugt werden, und installiert passende Treiber für den dort laufenden Kernel."
|
||||
]
|
||||
},
|
||||
"threePillars": {
|
||||
"heading": "Die drei Säulen eines Backups",
|
||||
"intro": "Ein ProxMenux-Archiv ist um drei in sich geschlossene Nutzdaten herum strukturiert. Bei der Wiederherstellung werden alle drei zusammen verwendet, um den Quellhost auf einem Ziel zu reproduzieren, auf dem möglicherweise nicht einmal derselbe Kernel installiert ist.",
|
||||
"diagramCaption": "Jedes Backup versendet unabhängig vom Ziel dieselben drei Payloads. Die Wiederherstellung verbraucht alle drei: rootfs zum Ablegen von Dateien, Manifest zum Erkennen von Abweichungen und Kernel-übergreifenden Unterschieden und Anwendungsinventar zum Neuinstallieren von Paketen und Komponenten im eigenen Kernel des Ziels.",
|
||||
"pillar1Label": "Dateisystem",
|
||||
"pillar1Detail": "rootfs/\n(rsync von /etc,\n/etc/systemd/network,\n/root sowie ein\nsqlite3-Snapshot\nvon /var/lib/pve-cluster,\n+ optionale Pfade)",
|
||||
"pillar2Label": "Manifest",
|
||||
"pillar2Detail": "manifest.json\n(Hardware, Kernel-\nParameter, Netzwerk,\nZFS, Benutzer, Cron,\nZFS-Pools, Speicher)",
|
||||
"pillar3Label": "Anwendungen",
|
||||
"pillar3Detail": "packages.manual.list\n+ components_status.json\n(manuelle APT-Pakete + ProxMenux-\nInstaller mit Versionen)"
|
||||
},
|
||||
"restoreIsUniversal": {
|
||||
"heading": "Die Wiederherstellung reproduziert den Quellhost, nicht das Archiv",
|
||||
"body": "Beim Wiederherstellen eines ProxMenux-Backups wird nicht nur das Dateisystem extrahiert. Der Wiederherstellungsfluss liest das Manifest, um Abweichungen zwischen der Quelle und dem Ziel zu erkennen (Hardwareunterschiede, NIC-Umbenennungen, Kernelversion, ZFS-Pool-Identität), spielt das Dateisystem erneut ab und löst dann das richtige Komponenteninstallationsprogramm für jeden Dienst aus, der auf der Quelle installiert wurde (NVIDIA-Treiber, Coral TPU, AMD GPU-Tools, Intel-GPU-Tools). Jedes Installationsprogramm wird für den aktuellen Kernel des <strong>Ziels</strong> ausgeführt, sodass der wiederhergestellte Host nicht davon abhängt, dass der Kernel der Quelle vorhanden ist. Wenn der Kernel des Ziels neuer ist als der des Backups, führt ein Kernel-unabhängiger <strong>Hydration</strong>-Durchgang die eigene Optimierung des Benutzers (IOMMU-Tokens, VFIO-Geräte-IDs, benutzerdefinierte Sonderanpassungen, GRUB-Schlüssel) in die neue Startkonfiguration des Ziels ein, ohne Kernel-gebundene Dateien wörtlich zu kopieren."
|
||||
},
|
||||
"twoInterfaces": {
|
||||
"heading": "Zwei Schnittstellen, ein Backend",
|
||||
"intro": "Alle Schritte der Sicherung und Wiederherstellung sind über zwei Oberflächen erreichbar. Beide rufen dieselbe Shell-Bibliothek auf, erstellen identische Archive und verwenden dasselbe Auftragsverzeichnis.",
|
||||
"cliLabel": "ProxMenux Scripts (TUI)",
|
||||
"cliDetail": "Menü → Dienstprogramme →\nHost-Sicherung/Wiederherstellung\n\nDialogbasierter Ablauf,\nSSH-freundlich, skriptfähig\nzur unbeaufsichtigten Nutzung.",
|
||||
"webLabel": "ProxMenux Monitor (Web UI)",
|
||||
"webDetail": "Registerkarte Backups in der\nWeboberfläche von Monitor.\n\nWiederherstellung mit einem Klick,\nlaufende Protokollanzeige, integriert\nmit Benachrichtigungen und der\nAnzeige von Rollback-Differenzen."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin geht es von hier aus?",
|
||||
"intro": "Jeder Unterabschnitt unten behandelt einen Aspekt des Arbeitsablaufs ausführlich. Beginnen Sie mit <em>Wie es funktioniert</em>, wenn das Ziel darin besteht, zu verstehen, was das Archiv enthält und warum. Wechseln Sie zu <em>Ziele</em>, um das Ziel für die Kopie zu konfigurieren. Lesen Sie <em>Wiederherstellung</em> und <em>Cross-Kernel-Wiederherstellung</em> für die Wiederherstellungsseite.",
|
||||
"items": [
|
||||
{
|
||||
"label": "So funktioniert es",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": "– die drei Payloads (rootfs, Manifest, Anwendungen) im Detail, mit den Collectors, die sie erzeugen, und dem Format jeder Datei."
|
||||
},
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "– Vergleich von lokal, Proxmox Backup Server (empfohlen) und Borg und wie man sie jeweils konfiguriert."
|
||||
},
|
||||
{
|
||||
"label": "Backups erstellen",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "– einmalige Sicherungen, das Standardpfadprofil, Hinzufügen benutzerdefinierter Pfade, Verschlüsselung für PBS."
|
||||
},
|
||||
{
|
||||
"label": "Geplante Jobs",
|
||||
"href": "/docs/backup-restore/scheduled-jobs",
|
||||
"tail": "– neue Jobs im Vergleich zum Anhängen an einen vorhandenen PVE-vzdump-Job, Planungsformate, das Jobdetail-Modal."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellen",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": "– die drei Aktionen für ein Archiv (Anzeigen, Herunterladen, Wiederherstellen), vollständige vs. benutzerdefinierte Wiederherstellung, der Post-Boot-Dispatcher und warum die letzten zehn Minuten wichtig sind."
|
||||
},
|
||||
{
|
||||
"label": "Kernelübergreifende Wiederherstellung",
|
||||
"href": "/docs/backup-restore/cross-kernel",
|
||||
"tail": " — vom Versionswechsel abhängiges Verhalten bei unterschiedlichen Quell- und Zielkerneln, der Filter für eine sichere Teilmenge und die vier Hydratationsphasen."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Geplante Aufträge — Timer, Attachment-Modus, Retention | ProxMenux",
|
||||
"description": "Geplante ProxMenux Host-Backup-Jobs. Zwei Erstellungsmodi (eigener systemd-Timer oder Attachment zu einem vorhandenen PVE vzdump-Job), Retentionswerte, die pro Job über proxmox-backup-client/borg/local prune angewendet werden, Storage-Layout unter /var/lib/proxmenux/backup-jobs und das Runner-Script, das Archive erzeugt, die mit dem interaktiven Fluss identisch sind.",
|
||||
"ogTitle": "ProxMenux Backup — geplante Aufträge",
|
||||
"ogDescription": "Unbeaufsichtigte geplante Host-Backups mit Attachment-Modus, Retention und den gleichen drei Zielen wie der interaktive Fluss.",
|
||||
"twitterTitle": "Geplante Jobs | ProxMenux",
|
||||
"twitterDescription": "Unbeaufsichtigte geplante Host-Backup-Jobs mit Attach-Modus und Retention."
|
||||
},
|
||||
"header": {
|
||||
"title": "Geplante Aufträge",
|
||||
"description": "Unbeaufsichtigte Host-Backup-Jobs. Zwei Erstellungsmodelle: ein neuer unabhängiger Job mit einem eigenen Zeitplan oder ein Job, der an eine bestehende PVE vzdump-Aufgabe angehängt ist, die den Zeitplan und die Aufbewahrung dieser Aufgabe erbt. Beide produzieren Archive, die mit dem interaktiven Fluss identisch sind.",
|
||||
"section": "Sicherung und Wiederherstellung"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Die beiden planmäßigen Job-Modelle",
|
||||
"body": "Ein geplanter Job kann nach einem von zwei Modellen erstellt werden:",
|
||||
"modelsList": [
|
||||
"<strong>Neuer unabhängiger job</strong> — ProxMenux definiert den Jobplan selbst mit einem eigenen systemd-Timer, unabhängig von anderen Aufgaben auf dem Host. Kompatibel mit allen drei Destinationen: Local, PBS und Borg.",
|
||||
"<strong>An eine bestehende PVE vzdump-Task anhängen</strong> – der Job hat keinen eigenen Zeitplan; er wird automatisch ausgeführt, wenn die übergeordnete PVE vzdump-Task, die bereits die VMs und LXCs auf diesem Host sichert, ausgelöst wird. Erbt den Zeitplan und die Beibehaltung von der übergeordneten Aufgabe. Kompatibel mit Local und PBS (Borg wird nicht unterstützt, da PVE keinen nativen Scheduler für Borg hat)."
|
||||
]
|
||||
},
|
||||
"attachBadge": {
|
||||
"title": "Attach-Modus — empfohlen, wenn bereits eine PVE vzdump-Task existiert",
|
||||
"body": "Wenn bereits ein PVE-vzdump-Auftrag für die VMs und LXCs dieses Knotens eingerichtet ist, wird das angehängte Host-Backup nach dem Gast-Backup im <strong>selben Sicherungszyklus</strong> ausgeführt. Bei der Wiederherstellung stammen die Gastkonfigurationen aus dem Host-Backup (unter <code>/etc/pve</code>) und die Gastfestplatten aus den vzdump-Backups dieses Zyklus. Dies erleichtert eine koordinierte Wiederherstellung des gesamten Knotens, ist aber kein atomarer Snapshot: Änderungen während des Zyklus können Unterschiede zwischen Hostkonfiguration und Gastfestplattenzustand hinterlassen."
|
||||
},
|
||||
"frequencyBadge": {
|
||||
"title": "Empfohlene Häufigkeit",
|
||||
"body": "Um die Kompatibilität zwischen einem Host-Backup und seiner zukünftigen Wiederherstellung zu maximieren, führen Sie häufig Host-Backups aus. Je näher das Backup dem aktuellen Zustand des Hosts ist, desto weniger Konfigurations-, Paket- und Komponentendrift muss die Wiederherstellung in Einklang bringen."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Die beiden Modi",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Neuer geplanter Auftrag",
|
||||
"backends": "Lokal, PBS, Borg",
|
||||
"schedule": "Eigener <code>OnCalendar</code>-Ausdruck (systemd-Kalendersyntax, z. B. <code>daily</code> oder <code>Mon..Fri 03:00</code>).",
|
||||
"retention": "Separat abgefragt: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Wird vom Ausführungsskript nach jedem erfolgreichen Backup angewendet."
|
||||
},
|
||||
{
|
||||
"mode": "Anhängen an einen PVE vzdump Job",
|
||||
"backends": "Lokal, PBS (Borg hat keinen PVE-seitigen Scheduler)",
|
||||
"schedule": "Vererbt vom Eltern-PVE-Job. Auf der ProxMenux-Seite ist kein systemd-Timer installiert.",
|
||||
"retention": "Aus der <code>prune-backups</code>-Konfiguration des übergeordneten Auftrags übernommen (über <code>hb_pve_prune_to_keep_env</code> eins zu eins den <code>KEEP_*</code>-Variablen des Ausführungsskripts zugeordnet)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"attachDetail": {
|
||||
"heading": "Wie Attach Mode funktioniert",
|
||||
"intro": "PVE speichert <code>vzdump</code>-Aufträge in <code>/etc/pve/jobs.cfg</code> — einen Abschnitt pro Auftrag mit dem Speicherziel für VM- und LXC-Backups. Der Attach-Modus erfordert ein von ProxMenux unterstütztes Backend (Lokal oder PBS). Das Host-Backup wird nach Abschluss des Gast-Backups über den job-end-Hook ausgeführt.",
|
||||
"steps": [
|
||||
{
|
||||
"step": "1",
|
||||
"detail": "Während der Auftragserstellung listet ProxMenux kompatible übergeordnete PVE-Aufgaben über <code>hb_pve_list_vzdump_jobs_for_backend</code> auf. Der Benutzer wählt einen aus."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"detail": "Der <code>.env</code> des Jobs wird mit <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> und den geerbten <code>KEEP_*</code>-Werten geschrieben; es wird kein systemd-Timer erstellt."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"detail": "<code>hb_install_vzdump_hook</code> registriert einen Skript-Hook in <code>/etc/vzdump.conf</code>. In der job-end-Phase jedes vzdump-Auftrags vergleicht er den übergebenen <code>$STOREID</code> mit <code>PVE_STORAGE</code> aller aktivierten angehängten Aufträge und startet das Ausführungsskript bei Übereinstimmung. Der Abgleich erfolgt nach Speicher, nicht nach der ID des gewählten übergeordneten Auftrags."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"detail": "Das Archiv landet im selben Speicher, den die vzdump-Dumps gerade geschrieben haben: <code>path/dump/</code> für Local oder das PBS-Repository, das auf dem PVE-Speichereintrag konfiguriert ist."
|
||||
}
|
||||
],
|
||||
"outroBody": "Der Attach-Modus hat keinen eigenen Timer. Das Deaktivieren oder Löschen des gewählten übergeordneten PVE-Auftrags stoppt dessen Auslösung; andere vzdump-Aufträge mit demselben Speicher können das Host-Backup weiterhin auslösen. Deaktivieren oder löschen Sie den ProxMenux-Auftrag selbst, um dies zu verhindern. Beim Deaktivieren bleibt der Eintrag auf der Festplatte und kann später erneut aktiviert oder angehängt werden."
|
||||
},
|
||||
"storageLayout": {
|
||||
"heading": "Dateien, die einen Job ausmachen",
|
||||
"intro": "Jeder geplante Job wird vollständig durch drei oder vier Dateien auf der Festplatte beschrieben. Das Lesen gibt die vollständige Konfiguration des Jobs, ohne sich auf die Benutzeroberfläche zu verlassen.",
|
||||
"rows": [
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
|
||||
"content": "Backend, Backup-ID oder Ziel, Zeitplan (Neuer Auftrag) oder übergeordneter PVE-Auftrag (Attach-Modus), Aktivierungsstatus, Aufbewahrungswerte <code>KEEP_*</code> und Verweise auf Zugangsdaten."
|
||||
},
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
|
||||
"content": "Ein absoluter Pfad pro Zeile - die eingefrorene Auswahl wurde zum Zeitpunkt der Joberstellung aus dem Profil aufgelöst. Das Bearbeiten der Datei führt den Job mit der neuen Auswahl beim nächsten Auslösen des Timers erneut aus."
|
||||
},
|
||||
{
|
||||
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
|
||||
"content": "Nur neuer Modus. Der Dienst ruft <code>run_scheduled_backup.sh JOB_ID</code> auf. Der Timer plant es mit <code>Persistent=true</code> (verpasste Ausführungen werden beim nächsten Boot nachgeholt) und einem kleinen <code>RandomizedDelaySec=120</code>, um die Last zu verteilen, wenn mehrere Jobs den gleichen OnCalendar-Ausdruck teilen."
|
||||
},
|
||||
{
|
||||
"path": "/etc/vzdump.conf script-hook",
|
||||
"content": "Nur Attach-Modus. Einmal durch <code>hb_install_vzdump_hook</code> installiert; vergleicht <code>PVE_STORAGE</code> jedes angehängten Auftrags mit <code>$STOREID</code>, das PVE dem Hook-Skript übergibt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"runner": {
|
||||
"heading": "Was beim Start eines Auftrags geschieht",
|
||||
"intro": "Jeder Job - ob New-Model oder Attachment - führt die gleiche dreistufige Sequenz aus:",
|
||||
"steps": [
|
||||
"<strong>Backup vorbereiten.</strong> Liest die Job-Konfiguration (Ziel, Profil, Pfade) und stellt den Archivbaum genau so zusammen, wie es der interaktive Fluss tut. Das Ergebnis ist das gleiche Archiv, das ein manuelles Backup mit diesen Einstellungen erzeugen würde.",
|
||||
"<strong>An das Ziel schreiben.</strong> Überträgt oder schreibt das Archiv in das konfigurierte Ziel – eine lokale <code>.tar.zst</code>-Datei, ein PBS-Backup oder ein Borg-Archiv – mit genau den gleichen Tools und Anmeldeinformationen, die ein manuelles Backup für dasselbe Ziel verwenden würde.",
|
||||
"<strong>Aufbewahrungsregeln anwenden.</strong> Entfernt alte Backups vom Zielort, wobei die Anzahl der <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> für den Auftrag konfiguriert bleibt. Das Beschneiden wird vom Zielort selbst durchgeführt: PBS wendet seine eigene Aufbewahrung an, Borg führt <code>borg prune</code> aus und bei Lokal löscht ProxMenux die Dateien, die außerhalb des <code>keep-last</code>-Fensters liegen."
|
||||
]
|
||||
},
|
||||
"management": {
|
||||
"heading": "Aufträge verwalten",
|
||||
"intro": "Das Scheduler-Menü (Scripts TUI) und die Registerkarte Monitor Backups zeigen die gleichen Aktionen bei jedem Job.",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Jetzt ausführen",
|
||||
"detail": "Ruft das Ausführungsskript sofort auf und umgeht Timer bzw. vzdump-Hook. Damit lässt sich die Auftragskonfiguration prüfen, ohne auf die nächste geplante Ausführung zu warten."
|
||||
},
|
||||
{
|
||||
"action": "Aktivieren/Deaktivieren",
|
||||
"detail": "Neuer Modus: <code>systemctl enable/disable --now</code> der Timer. Attach-Modus: Dreht das <code>ENABLED</code>-Flag im Job Env um — das Hook-Skript berücksichtigt es beim nächsten PVE-Aufruf."
|
||||
},
|
||||
{
|
||||
"action": "Bearbeiten",
|
||||
"detail": "Öffnet Ziel, Zeitplan, Profil und Aufbewahrungsaufforderungen neu und schreibt die Jobdateien neu. Bewahrt die Job ID auf."
|
||||
},
|
||||
{
|
||||
"action": "Löschen",
|
||||
"detail": "Entfernt die Job env, Pfaddatei, systemd Timer + Service (Neuer Modus) und deaktiviert die Hakenbindung (Attach-Modus). Berührt keine Archive bereits am Zielort."
|
||||
},
|
||||
{
|
||||
"action": "Protokoll anzeigen",
|
||||
"detail": "Zeigt laufend an: <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> – eine Protokolldatei pro Lauf. Der Runner gibt außerdem eine kompakte Statuszeile an journald unter dem Dienst systemd aus."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Benachrichtigungen",
|
||||
"body": "Jeder geplante Lauf feuert die gleichen <code>hb_notify_lifecycle</code>-Ereignisse ab wie der interaktive Fluss (<code>start</code>, <code>complete</code>, <code>fail</code>). Wenn Benachrichtigungskanäle im Monitor konfiguriert sind, tauchen unbeaufsichtigte Jobs auf die gleiche Weise wie manuelle Backups auf - ein Benutzer muss das Protokoll nicht überprüfen, um zu wissen, ob ein Job erfolgreich war."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Wohin Sie als nächstes gehen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Backups erstellen",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": "- der interaktive Fluss, der das Backend mit dem Scheduler teilt."
|
||||
},
|
||||
{
|
||||
"label": "Ziele",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": "Per-Backend-Konfiguration, die sowohl vom interaktiven Flow als auch vom Scheduler verwendet wird."
|
||||
},
|
||||
{
|
||||
"label": "Wiederherstellung",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — der Ablauf zur Wiederherstellung der von den Aufträgen erzeugten Backups."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Hinzufügen von Controller oder NVMe zu VM | ProxMenux Dokumentation",
|
||||
"description": "PCI-Passthrough eines Speichercontrollers (SATA-/SAS-HBA) oder NVMe-Geräts an eine Proxmox-VM mit ProxMenux. Das Werkzeug aktiviert IOMMU, erkennt Konflikte und richtet die Zuweisung mit qm set --hostpci ein.",
|
||||
"ogTitle": "Hinzufügen von Controller oder NVMe zu VM | ProxMenux Dokumentation",
|
||||
"ogDescription": "Weisen Sie einer Proxmox-VM einen vollständigen SATA-/SAS-HBA oder ein NVMe-Gerät zu. ProxMenux übernimmt IOMMU, Konflikterkennung und die hostpci-Zuweisung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Controller oder NVMe zu VM hinzufügen",
|
||||
"description": "Weisen Sie einer Proxmox-VM einen vollständigen SATA-/SAS-Host-Bus-Adapter (HBA) oder ein NVMe-Gerät per PCI-Passthrough zu. ProxMenux prüft IOMMU und aktiviert es mit Ihrer Zustimmung, ermittelt geeignete Geräte, schließt Konflikte aus und trägt die Zuweisung mit qm set --hostpci ein.",
|
||||
"section": "Datenträgerverwaltung · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was dies tut (und nicht tut)",
|
||||
"body": "Dies ist <strong>Passthrough auf Geräteebene</strong>: Die PCIe-Karte wird der Kontrolle des Host-Kernels entzogen und an <code>vfio-pci</code> gebunden. Die VM sieht den Controller selbst statt einzeln durchgereichter Laufwerke und lädt ihren eigenen Treiber für dieses Modell. Alle am Controller angeschlossenen Laufwerke folgen automatisch, mit nativen SMART-Daten, vollständigen Firmware-Funktionen und ohne Proxmox-Zwischenschicht."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Fluss hat zwei Phasen mit klarer Trennung zwischen \"Sammeln von Informationen, Überprüfen von IOMMU und Auflisten von Kandidaten\" und \"Tatsächliches Anbringen des PCI-Geräts\". Bis zur endgültigen Bestätigung wird nichts an die VM-Konfiguration geschrieben."
|
||||
},
|
||||
"iommu": {
|
||||
"heading": "IOMMU-Gruppen - warum die gesamte Karte auf einmal geht",
|
||||
"body": "Die Isolationsgrenze für PCI-Passthrough ist die <strong>IOMMU-Gruppe</strong>, die kleinste von der IOMMU der CPU isolierbare Einheit. Geräte derselben Gruppe lassen sich nicht voneinander isolieren. Teilt ein SATA-Controller die Gruppe mit einem USB-Controller, muss für SATA-Passthrough möglicherweise auch USB vom Host gelöst werden, oder Passthrough ist nicht möglich. Dabei werden nicht automatisch alle Geräte der Gruppe der VM zugewiesen.",
|
||||
"outro": "ProxMenux zeigt die IOMMU-Gruppe neben jedem Gerät und warnt Sie, wenn eine Gruppe mehr als nur den gewünschten Controller trägt. Sie können weiterhin fortfahren, wenn die zusätzlichen Geräte in der Gruppe akzeptabel sind (z. B. alle Festplattencontroller) oder zurückgehen, wenn dies nicht der Fall ist."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Voraussetzungen",
|
||||
"items": [
|
||||
"<strong>CPU und Mainboard unterstützen</strong> VT-d (Intel) oder AMD-Vi, und die Funktion ist in der Firmware (BIOS/UEFI) aktiviert. ProxMenux kann die Kernelkonfiguration aktivieren, aber keine Firmware-Einstellung umschalten.",
|
||||
"Die Ziel-VM ist vor dem Anschließen von PCI-Geräten <strong>ausgeschaltet</strong>.",
|
||||
"Der Controller/NVMe <strong> ist nicht derjenige, der das Proxmox Root-Dateisystem</strong> hält. Das Skript verbirgt alles, was vom Host verwendet wird.",
|
||||
"Das Gastbetriebssystem hat Treiber für das Controllermodell. Linux unterstützt nahezu jeden HBA ab Werk; unter Windows muss der Herstellertreiber <em>vor</em> dem Start mit angeschlossenem Controller installiert sein."
|
||||
],
|
||||
"warnTitle": "Live Migration ist nicht möglich",
|
||||
"warnBody": "Ein VM mit PCI-Durchgang ist an den Knoten gebunden, der die Karte physisch hält. Live-Migration über Knoten wird fehlschlagen. Planen Sie Backups / Replikation entsprechend."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Ziel-VM auswählen",
|
||||
"bodyRich": "ProxMenux liest <code>qm list</code> und zeigt alle VMs an. Wählen Sie die VM, die den Controller erhalten soll.",
|
||||
"img": "/disk/nvme-passthrough/vm-selection.png",
|
||||
"alt": "VM Auswahldialog",
|
||||
"caption": "VM Auswahldialog"
|
||||
},
|
||||
{
|
||||
"title": "IOMMU-Prüfung",
|
||||
"bodyRich": "Wenn IOMMU auf der Kernel-Cmdline nicht aktiviert ist, bietet ProxMenux an, sie zu aktivieren. Es bearbeitet <code>/etc/kernel/cmdline</code> (für systemd-Boot) oder <code>/etc/default/grub</code> (für GRUB) und fügt den richtigen Parameter für Ihren CPU hinzu:",
|
||||
"items": [
|
||||
"<code>intel_iommu=on</code> für Intel CPUs.",
|
||||
"<code>amd_iommu=on</code> für AMD CPUs."
|
||||
],
|
||||
"outro": "Nach dieser Änderung ist ein Neustart erforderlich. Das Skript bietet einen Neustart jetzt oder später an; Passthrough kann erst fortgesetzt werden, wenn die neue Kernel-Kommandozeile aktiv ist.",
|
||||
"img": "/disk/nvme-passthrough/iommu-warning.png",
|
||||
"alt": "Dialog „IOMMU erforderlich“",
|
||||
"caption": "IOMMU Erforderlich — Angebot zum Aktivieren und Neustarten"
|
||||
},
|
||||
{
|
||||
"title": "Geräteaufzählung",
|
||||
"body": "ProxMenux listet jeden Speichercontroller (SATA / SAS HBA) und jedes NVMe-Gerät auf dem PCI-Bus auf. Für jedes Gerät zeigt es:",
|
||||
"items": [
|
||||
"PCI-Adresse (<code>00:17.0</code>, <code>01:00.0</code>, ...).",
|
||||
"Hersteller- und Gerätebeschreibung.",
|
||||
"IOMMU-Gruppe - und eine ⚠ Warnung, wenn die Gruppe mit anderen, nicht verwandten Geräten geteilt wird.",
|
||||
"Die aktuell am Controller angeschlossenen Laufwerke, damit Sie wissen, welche zur VM wechseln."
|
||||
],
|
||||
"img": "/disk/nvme-passthrough/device-list.png",
|
||||
"alt": "Controller / NVMe Geräteaufzählung",
|
||||
"caption": "Controller / NVMe Geräteaufzählung mit IOMMU Gruppeninfo"
|
||||
},
|
||||
{
|
||||
"title": "Konflikterkennung",
|
||||
"bodyRich": "Das Skript sperrt eindeutig unsichere Geräte: bereits einer anderen VM über <code>hostpci</code> zugewiesene Geräte, vom Host verwendete Geräte wie den Root-Laufwerkscontroller sowie Geräte in IOMMU-Gruppen, deren andere Mitglieder nicht sicher erkannt werden können. Geeignete Geräte stehen zur Auswahl.",
|
||||
"img": "/disk/nvme-passthrough/conflict-warning.png",
|
||||
"alt": "Konflikterkennungswarnung",
|
||||
"caption": "Konflikterkennung: Gerät mit Angabe des Grundes gesperrt"
|
||||
},
|
||||
{
|
||||
"title": "Zuweisen und abschließen",
|
||||
"bodyRich": "Für jedes gewählte Gerät führt ProxMenux <code>qm set <VMID> --hostpciN <pci-addr>,pcie=1</code> aus und verwendet den nächsten freien <code>hostpci</code>-Slot. Wurde IOMMU in dieser Sitzung aktiviert, wird vor dem Start der VM an den erforderlichen Neustart erinnert.",
|
||||
"img": "/disk/nvme-passthrough/assignment.png",
|
||||
"alt": "Zusammenfassung der Zuweisung",
|
||||
"caption": "Zusammenfassung der Zuweisung: belegte hostpciN-Slots und zugewiesene PCI-Adressen"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noGroupsTitle": "IOMMU aktiviert, aber keine Gruppen unter /sys/kernel/iommu_groups/",
|
||||
"noGroupsBody": "Ein Neustart ist erforderlich, damit die Kernel-Cmdline wirksam wird. Wenn die Gruppen nach dem Neustart immer noch fehlen, ist VT-d / AMD-Vi wahrscheinlich in der Firmware deaktiviert - überprüfen Sie das BIOS / UEFI-Setup.",
|
||||
"busyTitle": "VM startet nicht: \"hostpciN: device busy\"",
|
||||
"busyBody": "Ein anderer Prozess hält das PCI-Gerät noch belegt. Häufige Ursachen sind eine abgestürzte VM, die es nicht freigegeben hat, oder der Host-Kernel, der es beim letzten Start wieder übernommen hat. Prüfen Sie mit <code>lspci -nnk -s <addr></code> den gebundenen Treiber; es sollte <code>vfio-pci</code> sein. Ein vollständiger Neustart des Hosts behebt dies meist.",
|
||||
"noDisksTitle": "Gast sieht den Controller, aber nicht die Festplatten",
|
||||
"noDisksBody": "Im Gast fehlt der Treiber für das Controllermodell. Unter Linux tritt dies selten auf, unter Windows hingegen schon. Installieren Sie den Herstellertreiber, etwa von LSI/Broadcom für ältere SAS-HBAs, solange die Karte nicht zugewiesen ist, und starten Sie dann mit zugewiesener Karte neu.",
|
||||
"sharedTitle": "Die IOMMU-Gruppe enthält ein nicht zugehöriges Gerät",
|
||||
"sharedBody": "Möglichkeiten: (a) die Karte in einen anderen PCIe-Slot setzen, um ihre Gruppe zu ändern, (b) <em>ACS override</em> im Kernel aktivieren, um Gruppen aufzuteilen (Sicherheitskompromiss, vor der Anwendung recherchieren), oder (c) eine andere Karte in einer besser isolierten Gruppe wählen."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Datenträger in VM importieren",
|
||||
"tail": "Alternatives Modell: Befestigen Sie eine physische Festplatte über Proxmox ohne vollständigen PCIe-Durchgang."
|
||||
},
|
||||
{
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"label": "GPU zu VM hinzufügen (Passthrough)",
|
||||
"tail": "- gleiche IOMMU / VFIO-Konzepte, die auf einen GPU angewendet wurden."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/gpu-commands",
|
||||
"label": "GPU Durchgangsbefehle",
|
||||
"tail": "IOMMU-Verifizierungsbefehle gelten auch für den Controller / NVMe-Durchgang."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,142 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Physischen Datenträger formatieren oder löschen | ProxMenux-Dokumentation",
|
||||
"description": "Physische Datenträger auf Proxmox VE mit ProxMenux löschen und formatieren. Vier Betriebsarten, strenge Sicherheitsfilter gegen Systemlaufwerke, eingehängte oder verwendete Laufwerke und doppelte Bestätigung mit Eingabe des vollständigen Pfads.",
|
||||
"ogTitle": "Physischen Datenträger formatieren oder löschen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Physische Datenträger auf Proxmox löschen oder formatieren. Sicherheitsfilter, vier Betriebsarten und doppelte Bestätigung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Physischen Datenträger formatieren / löschen",
|
||||
"description": "Wischen oder formatieren Sie sicher eine physische Festplatte auf dem Proxmox-Host. ProxMenux zeigt nur Festplatten an, die völlig frei sind (keine Systemnutzung, keine Gastreferenz, keine Mounts) und erzwingt eine doppelte Bestätigung - ja / nein plus Eingabe des vollständigen Festplattenpfads -, bevor Daten zerstört werden.",
|
||||
"section": "Disk Manager · Dienstprogramme"
|
||||
},
|
||||
"danger": {
|
||||
"title": "Zerstörendes Werkzeug",
|
||||
"body": "Jede Operation hier schreibt auf die Festplatte. Es gibt kein Rückgängigmachen. ProxMenux wendet strenge Sicherheitsfilter und Bestätigungen an, aber die Verantwortung für die Auswahl der richtigen Festplatte liegt bei Ihnen. Lesen Sie den Festplattenpfad zweimal laut aus, bevor Sie ihn eingeben."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Ablauf hat zwei Phasen mit einer dreifachen Sicherheitsprüfung dazwischen. In Phase 1 werden Laufwerksauswahl, Betriebsart und Dateisystemdetails erfasst. Geschrieben wird erst, wenn Phase 2 unmittelbar vor der Ausführung eine abschließende erneute Prüfung bestanden hat."
|
||||
},
|
||||
"visibility": {
|
||||
"heading": "Sichtbarkeitsregeln",
|
||||
"intro": "Bevor das Menü überhaupt erscheint, filtert ProxMenux die Festplattenliste. Es werden nur Kandidaten gezeigt, die nachweislich sicher sind:",
|
||||
"items": [
|
||||
"<strong>Angezeigt</strong> werden Laufwerke, die <em>nicht</em> vom Host genutzt werden (Root-Pool, Swap, eingehängte Dateisysteme, aktives ZFS/LVM/RAID) und <em>nicht</em> in einer VM-/LXC-Konfiguration referenziert sind, unabhängig vom Betriebszustand des Gasts.",
|
||||
"<strong>Ausgeblendet</strong>: Host- und Systemlaufwerke.",
|
||||
"<strong>Ausgeblendet</strong>: in VM-/LXC-Konfigurationen referenzierte Laufwerke."
|
||||
],
|
||||
"safetyTitle": "Sicherheit bei Bestätigung und Ausführung",
|
||||
"safetyItems": [
|
||||
"Bei Laufwerken mit veralteten oder aktiven Metadaten erscheinen detaillierte Warnungen <em>vor</em> der Bestätigung.",
|
||||
"Von einer <strong>laufenden</strong> VM genutzte Laufwerke werden bei der Bestätigung <strong>vollständig gesperrt</strong>.",
|
||||
"Laufwerke mit eingehängten Partitionen werden bei der Ausführung <strong>vollständig gesperrt</strong>. Unmittelbar vor dem Schreiben erfolgt eine neue Prüfung.",
|
||||
"Zwei Bestätigungen sind immer erforderlich: ein <em>Ja/Nein</em>-Dialog und die exakte Eingabe des vollständigen Laufwerkspfads."
|
||||
]
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Betriebsarten",
|
||||
"intro": "Nachdem Sie eine Festplatte ausgewählt haben, wählen Sie einen von vier Modi. Sie unterscheiden sich darin, was sie zerstören und was sie zurücklassen.",
|
||||
"headerMode": "Modus",
|
||||
"headerPart": "Partitionstabelle",
|
||||
"headerData": "Daten",
|
||||
"headerUseCase": "Anwendungsfall",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "1. Alles löschen",
|
||||
"part": "Zerstört",
|
||||
"data": "Signaturen gelöscht",
|
||||
"useCase": "Entfernt die Partitionstabelle sowie Dateisystem- und RAID-Metadaten, überschreibt die ersten und letzten 16 MiB mit Nullen und führt bei Laufwerken mit Discard-Unterstützung ein TRIM über den gesamten Datenträger aus. Die übrigen Daten werden nicht überschrieben und können auf HDDs noch wiederherstellbar sein; dies ist kein sicheres Löschen."
|
||||
},
|
||||
{
|
||||
"mode": "2. FS-Etiketten entfernen",
|
||||
"part": "Erhalten",
|
||||
"data": "Erhalten",
|
||||
"useCase": "Entfernt alte ZFS-/LVM-/RAID-Signaturen, damit das Laufwerk nicht mehr automatisch eingebunden wird. Nutzdaten werden nicht flächig überschrieben, können durch das Entfernen der Signaturen aber unzugänglich werden."
|
||||
},
|
||||
{
|
||||
"mode": "3. Daten mit Nullen überschreiben",
|
||||
"part": "Erhalten",
|
||||
"data": "Zerstört (mit Nullen überschrieben)",
|
||||
"useCase": "Bestehende Partitionen mit Nullen überschreiben und die Partitionstabelle erhalten. Nicht zugewiesener Speicher und SSD-Reservebereiche sind nicht erfasst; dies garantiert keine vollständige Gerätesanitisierung."
|
||||
},
|
||||
{
|
||||
"mode": "4. Vollformat",
|
||||
"part": "Neue GPT",
|
||||
"data": "Zerstört",
|
||||
"useCase": "Einsatzbereites Laufwerk mit einer neuen Partition und einem neuen Dateisystem."
|
||||
}
|
||||
],
|
||||
"fullFormatOutro": "<strong>Vollständiges Formatieren</strong> führt zu zwei weiteren Dialogen:",
|
||||
"fullFormatItems": [
|
||||
"<strong>Dateisystem</strong>: <code>ext4</code>, <code>xfs</code>, <code>exfat</code> (portabel) oder <code>btrfs</code>. Fehlen Werkzeuge wie <code>mkfs.btrfs</code>, wird mit einer klaren Meldung abgebrochen.",
|
||||
"<strong>Label</strong> — optionales Dateisystem-Etikett zur Identifizierung."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Freies Laufwerk wählen",
|
||||
"body": "ProxMenux listet jede Festplatte auf, die die oben genannten Sichtbarkeitsfilter passiert. Festplatten mit ⚠-Markern tragen veraltete Metadaten und werden mit den Details angezeigt, damit Sie wissen, was Sie überschreiben möchten."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie einen Betriebsmodus",
|
||||
"bodyRich": "Wählen Sie gemäß obiger Tabelle <strong>Alles löschen</strong>, <strong>FS-Etiketten entfernen</strong>, <strong>Daten mit Nullen überschreiben</strong> oder <strong>Vollständiges Formatieren</strong>."
|
||||
},
|
||||
{
|
||||
"title": "(Nur Vollformat) Dateisystem und Label auswählen",
|
||||
"body": "ext4 / xfs / exfat / btrfs, plus ein optionales Etikett."
|
||||
},
|
||||
{
|
||||
"title": "Zweimal bestätigen",
|
||||
"bodyRich": "ProxMenux zeigt eine Zusammenfassung der geplanten Aktion. Sie bestätigen im Ja/Nein-Dialog und <strong>geben den vollständigen Laufwerkspfad</strong> exakt wie angezeigt ein, etwa <code>/dev/sdc</code>. Jede andere Eingabe bricht ab."
|
||||
},
|
||||
{
|
||||
"title": "Revalidierung und Ausführung",
|
||||
"body": "Kurz vor dem Schreiben überprüft das Skript den Festplattenzustand erneut. Wurde zwischenzeitlich eine Partition gemountet oder ein VM gestartet, wird die Ausführung abgebrochen. Ansonsten läuft die gewählte Operation und eine Zusammenfassung wird am Ende gedruckt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelle Äquivalente",
|
||||
"body": "Wenn Sie es vorziehen, die entsprechenden Befehle von Hand auszuführen:"
|
||||
},
|
||||
"troubleshoot": {
|
||||
"notListedTitle": "Disk nicht im Menü aufgeführt",
|
||||
"notListedBody": "Das Laufwerk wurde aus Sicherheitsgründen ausgeblendet. Häufige Gründe: Es ist eingehängt, auch unter <code>/mnt/tmp</code>, aktives Mitglied von ZFS/LVM/RAID, in einer VM-/LXC-Konfiguration referenziert oder das Proxmox-Root-Laufwerk. Prüfen Sie auf dem Host <code>lsblk -f</code> und <code>cat /proc/mdstat</code>, um den Grund zu ermitteln.",
|
||||
"busyTitle": "\"Disk may be busy\" / Unmount fehlgeschlagen",
|
||||
"busyBody": "Etwas hält immer noch eine offene Datei auf einer Partition dieser Festplatte - meistens ein Container oder eine Shell, deren cwd sich in einem Mountpoint befindet. Identifizieren Sie es mit <code>lsof | grep /dev/sdX</code> oder <code>fuser -vm /dev/sdX1</code>, stoppen Sie es und führen Sie das Tool erneut aus."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/smart-disk-test",
|
||||
"label": "SMART-Festplattenstatus und -test",
|
||||
"tail": "Überprüfen Sie eine Festplatte vor / nach dem Wischen, um zu bestätigen, dass sie gesund ist."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Datenträger in VM importieren",
|
||||
"tail": "Übergeben Sie eine frisch formatierte Festplatte an eine VM."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Lokale Festplatte als Proxmox-Speicher hinzufügen",
|
||||
"tail": "Registrieren Sie eine gelöschte Festplatte als Proxmox-Speicherpool."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Speicher- und Festplattenbefehle",
|
||||
"tail": " — Referenz für lsblk, blkid und parted."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Datenträgerbild in VM importieren | ProxMenux Dokumentation",
|
||||
"description": "Importieren Sie eine Disk-Image-Datei (.img / .qcow2 / .vmdk / .raw) mit ProxMenux in ein vorhandenes Proxmox VM. Per-Image-Schnittstelle, SSD-Emulation und bootfähiges Flag, mit qm importdisk unter der Haube.",
|
||||
"ogTitle": "Datenträgerbild in VM importieren | ProxMenux Dokumentation",
|
||||
"ogDescription": "Importieren Sie .img / .qcow2 / .vmdk / .raw Disk-Images in einen vorhandenen VM mit ProxMenux. Verwendet qm importdisk unter der Haube."
|
||||
},
|
||||
"header": {
|
||||
"title": "Disk-Image in VM importieren",
|
||||
"description": "Importieren Sie eine Disk-Image-Datei (.img, .qcow2, .vmdk oder .raw) in eine vorhandene Proxmox VM. ProxMenux sammelt jede Entscheidung im Voraus - Ziel VM, Proxmox-Speicher, Quellverzeichnis, Schnittstelle, SSD-Emulation, Boot-Order - und führt dann qm importdisk für jedes ausgewählte Image aus.",
|
||||
"section": "Datenträgerverwaltung · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Anders als <em>Datenträger in VM importieren</em>, das ein physisches Laufwerk direkt zuweist, verwendet dieser Ablauf eine <strong>Datei</strong> auf dem Host, etwa einen Export eines anderen Hypervisors, ein heruntergeladenes Cloud-Image oder ein aus einer Sicherung extrahiertes Image. Sie wird in ein Proxmox-VM-Laufwerk auf dem gewählten Speicher umgewandelt. Die Originaldatei bleibt erhalten: ProxMenux kopiert sie, statt sie zu verschieben."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Ablauf hat zwei Phasen. Phase 1 erfasst über Dialoge vorab alle Entscheidungen: VM, Speicher, Quellverzeichnis, Images und Optionen je Image. Phase 2 führt <code>qm importdisk</code> für jedes ausgewählte Image aus. Vor Beginn von Phase 2 wird weder etwas kopiert noch die VM-Konfiguration verändert."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Voraussetzungen",
|
||||
"items": [
|
||||
"Mindestens eine VM ist auf dem Host definiert. Die Ziel-VM sollte <strong>ausgeschaltet</strong> sein.",
|
||||
"Mindestens eine Disk-Image-Datei in einem unterstützten Format liegt im Quellverzeichnis. Unterstützt werden <code>.img</code>, <code>.qcow2</code>, <code>.vmdk</code> und <code>.raw</code>.",
|
||||
"Genug freien Speicherplatz auf dem Ziel-Proxmox-Speicher, um jede importierte Festplatte zu halten.",
|
||||
"ProxMenux sucht standardmäßig nach Images in <code>/var/lib/vz/template/iso</code>. Sie können es auf jedes andere Verzeichnis auf dem Host verweisen, wenn es gefragt wird."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Ziel-VM auswählen",
|
||||
"bodyRich": "ProxMenux liest <code>qm list</code> und zeigt jeden VM an. Wählen Sie diejenige aus, die die importierten Festplatten erhält."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie den Proxmox-Speicher",
|
||||
"bodyRich": "Die Liste enthält jeden Speicher, für den der Inhaltstyp <code>images</code> aktiviert ist. Wenn es nur einen Kandidaten gibt, wird er automatisch ausgewählt und der Dialog wird übersprungen."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie das Quellverzeichnis",
|
||||
"bodyRich": "Wählen Sie das Standardverzeichnis (<code>/var/lib/vz/template/iso</code>) oder geben Sie einen benutzerdefinierten Pfad ein - in der Regel, wo Sie das Image heruntergeladen / hochgeladen haben. Das Skript lehnt Pfade ab, die nicht existieren."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie ein oder mehrere Images",
|
||||
"bodyRich": "Das Verzeichnis wird nach <code>.img</code> / <code>.qcow2</code> / <code>.vmdk</code> / <code>.raw</code> Dateien gescannt. Sie können mehrere gleichzeitig auswählen; jede wird im nächsten Schritt die Per-Bild-Optionen durchlaufen."
|
||||
},
|
||||
{
|
||||
"title": "Per-Image Optionen",
|
||||
"intro": "Für jedes ausgewählte Image fragt ProxMenux:",
|
||||
"items": [
|
||||
"<strong>Interface</strong> — <code>scsi</code> (Standard), <code>virtio</code>, <code>sata</code> oder <code>ide</code>. Passt dazu, wie der Gast die Festplatte sehen wird.",
|
||||
"<strong>SSD-Emulation</strong>: nur für Nicht-VirtIO-Schnittstellen verfügbar. Fügt <code>ssd=1</code> hinzu, damit der Gast das Laufwerk als SSD erkennt. Discard/TRIM muss separat konfiguriert werden.",
|
||||
"<strong>Bootfähig</strong>: Bei Ja nimmt ProxMenux das Laufwerk als primäres Startgerät in die Bootreihenfolge der VM auf."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Importieren und zuweisen",
|
||||
"bodyRich": "ProxMenux führt <code>qm importdisk</code> für jedes Image aus (Konvertierung des Formats im laufenden Betrieb, wo dies erforderlich ist), fügt die resultierende Festplatte mit den von Ihnen gewählten Optionen an den nächsten freien Slot (<code>scsiN</code>, <code>sataN</code>, ...) an und aktualisiert - wenn Sie eine Festplatte als bootfähig markiert haben - die Boot-Order. Fortschritt zeigt sich im Terminal."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Ein einzelnes Image lässt sich mit drei <code>qm</code>-Befehlen importieren:",
|
||||
"warnTitle": "Konvertierung des Disk-Image-Formats",
|
||||
"warnBody": "Wenn der Zielspeicher das Quellformat nativ nicht halten kann (z. B. LVM-Speicher <code>.qcow2</code>), konvertiert <code>qm importdisk</code> das Image transparent. Dies kann mehrere Minuten für Multi-GB-Bilder dauern; planen Sie entsprechend und unterbrechen Sie das Skript nicht."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noImagesTitle": "\"Keine kompatiblen Disk Images gefunden\"",
|
||||
"noImagesBody": "Das Skript fand keine Datei mit <code>.img</code>, <code>.qcow2</code>, <code>.vmdk</code> oder <code>.raw</code>. Prüfen Sie die Erweiterung einschließlich Groß-/Kleinschreibung, ob die Datei direkt im gewählten Verzeichnis liegt (Unterverzeichnisse werden nicht durchsucht) und ob root sie lesen darf.",
|
||||
"slowTitle": "Import ist langsam",
|
||||
"slowBody": "Konvertierungen zwischen VMDK, QCOW2 und raw können durch CPU und E/A begrenzt sein. Die Importgeschwindigkeit hängt von Quelllesezugriffen, Zielschreibzugriffen und nötiger Dekomprimierung ab. Bevorzugen Sie nach Möglichkeit raw- oder qcow2-Quellen.",
|
||||
"uefiTitle": "Importiertes Laufwerk startet in der UEFI-Shell",
|
||||
"uefiBody": "Das Image wurde für Legacy (SeaBIOS) gebaut, aber der VM verwendet OVMF (oder umgekehrt). Wechseln Sie entweder den VM BIOS in Proxmox, um das Image abzugleichen, oder bauen Sie das Image vor dem Importieren im richtigen Modus neu auf."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Datenträger in VM importieren",
|
||||
"tail": " — derselbe Ablauf für physische Laufwerke (Passthrough)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/utils/import-vm",
|
||||
"label": "VM von OVA / OVF importieren",
|
||||
"tail": "- wenn Sie ein vollständiges VM-Paket haben, nicht nur ein Festplattenimage."
|
||||
},
|
||||
{
|
||||
"href": "/docs/utils/UUp-Dump-ISO-Creator",
|
||||
"label": "UUP-Dump-ISO-Erstellung",
|
||||
"tail": "- Generieren Sie eine Windows ISO, wenn Sie eine für eine neue Installation benötigen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Speicher- und Festplattenbefehle",
|
||||
"tail": " — Referenz für qm importdisk und qemu-img convert."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,115 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Datenträger zu LXC importieren | ProxMenux Dokumentation",
|
||||
"description": "Befestigen Sie eine physische Festplatte an einen vorhandenen LXC-Container auf Proxmox VE mit ProxMenux. Behandelt Dateisystemerkennung / -formatierung, Einhängepunkt, unprivilegierte → privilegierte Konvertierung und persistente Gerätepfade.",
|
||||
"ogTitle": "Datenträger zu LXC importieren | ProxMenux Dokumentation",
|
||||
"ogDescription": "Befestigen Sie eine physische Festplatte an einen vorhandenen LXC-Container. Behandelt Dateisystem, Mount Point und unprivilegierte → privilegierte Konvertierung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Datenträger in LXC importieren",
|
||||
"description": "Fügen Sie eine physische Festplatte an einen vorhandenen LXC-Container auf dem Proxmox-Host an. ProxMenux erkennt freie Festplatten, formatiert sie optional mit einem unterstützten Dateisystem und verkabelt die Partition mit persistenten Gerätepfaden an einen Einhängepunkt im Container.",
|
||||
"section": "Datenträgerverwaltung · LXC"
|
||||
},
|
||||
"intro": {
|
||||
"title": "VM-Passthrough und LXC-Passthrough",
|
||||
"body": "LXC-Passthrough stellt hier <strong>kein rohes Blockgerät</strong> bereit. Der Container erhält einen <em>Einhängepunkt</em>, also ein Verzeichnis auf der gewählten Host-Partition. Anders als bei einer VM nutzt der Gast den Host-Kernel; das Dateisystem (ext4/xfs/btrfs) wird daher vom Proxmox-Host gelesen, verwaltet und dem Container zugänglich gemacht."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Fluss hat zwei Phasen mit klarer Trennung zwischen \"Sammeln von Informationen und Entscheidungen\" und \"tatsächliches Ändern der Containerkonfiguration\". Bis zur endgültigen Bestätigung wird nichts in den CT eingebaut.",
|
||||
"summary": "ProxMenux blendet das Root-Laufwerk, eingehängte Laufwerke und bereits in VM-/LXC-Konfigurationen referenzierte Laufwerke aus. Aktive ZFS-/LVM-/RAID-Mitglieder werden ausgeblendet; alte Signaturen werden mit ⚠ markiert, damit Sie sie vor dem Formatieren löschen können."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Voraussetzungen",
|
||||
"items": [
|
||||
"Mindestens ein LXC-Container, der auf dem Host definiert ist.",
|
||||
"Der Container ist <strong>privilegiert</strong>, oder Sie nehmen das Konvertierungsangebot des Skripts an.",
|
||||
"Mindestens eine physische Festplatte, die vom Host oder einem anderen Gast nicht verwendet wird."
|
||||
],
|
||||
"warnTitle": "Privilegierter Container erforderlich",
|
||||
"warnBody": "Dieses Skript benötigt für die direkte Laufwerkszuweisung einen <strong>privilegierten</strong> Container. Bei <code>unprivileged: 1</code> bietet es an, <code>/etc/pve/lxc/<CTID>.conf</code> direkt zu ändern. Das ändert das Sicherheitsmodell, ordnet vorhandene Dateieigentümer aber nicht neu zu. Sichern Sie den Container und prüfen Sie die Eigentümer vor der Zustimmung, oder erstellen Sie ihn privilegiert neu."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Wählen Sie den Zielcontainer",
|
||||
"img": "/disk/select-container.png",
|
||||
"caption": "Auswahlmenü für Container",
|
||||
"bodyRich": "ProxMenux listet jeden LXC-Container auf dem Host auf (<code>pct list</code>). Wählen Sie diejenige, die die Festplatte erhalten wird. Wenn der Container nicht privilegiert ist, wird Ihnen angeboten, ihn jetzt umzuwandeln."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie die physische Festplatte",
|
||||
"img": "/disk/disk-selection-ct.png",
|
||||
"caption": "Freie Festplatten auf dem Host erkannt (mit ⚠ Labels für veraltete Metadaten)",
|
||||
"bodyRich": "Nur sichere Kandidaten werden angezeigt. Anders als bei VMs weist dieses Skript <strong>ein Laufwerk pro Durchlauf</strong> zu. Führen Sie es für jedes weitere Laufwerk erneut aus."
|
||||
},
|
||||
{
|
||||
"title": "Formatieren oder wiederverwenden",
|
||||
"intro": "Das Skript überprüft die Festplatte:",
|
||||
"items": [
|
||||
"Wenn es bereits ein unterstütztes Dateisystem (ext4 / xfs / btrfs) trägt, können Sie es so wiederverwenden, wie es ist (bestehende Dateien bleiben erhalten).",
|
||||
"Wenn es kein unterstütztes Dateisystem hat, wird Ihnen angeboten, es zu formatieren. Wählen Sie ext4 / xfs / btrfs."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie den Mount Point",
|
||||
"bodyRich": "Geben Sie den Pfad ein, unter dem der Container das Laufwerk sehen soll, etwa <code>/mnt/data</code> oder <code>/mnt/disk_passthrough</code>. Dies ist der Pfad <em>innerhalb</em> des Containers; der Host sieht die Partition bereits unter <code>/dev/disk/by-id/…</code>."
|
||||
},
|
||||
{
|
||||
"title": "Zuweisen und prüfen",
|
||||
"img": "/disk/assignment-ct.png",
|
||||
"caption": "Zuordnung zu CT",
|
||||
"bodyRich": "ProxMenux fügt der Containerkonfiguration einen neuen <code>mpN:</code>-Eintrag hinzu, überspringt belegte Indizes und liest die Konfiguration zur Bestätigung erneut. Bei laufendem Container wird die Einhängung sofort angewendet, andernfalls beim nächsten Start.",
|
||||
"extraImg": "/disk/result-point.png",
|
||||
"extraAlt": "Mount Point erfolgreich erstellt",
|
||||
"extraCaption": "Einhängepunkt erstellt und geprüft"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Das Skript wickelt <code>pct set</code> ab. Ein direkter Aufruf für eine einzelne Festplatte sieht so aus:"
|
||||
},
|
||||
"important": {
|
||||
"heading": "Wichtige Überlegungen",
|
||||
"items": [
|
||||
"<strong>Ein Laufwerk pro Durchlauf</strong>. Führen Sie das Skript für jedes weitere Laufwerk erneut aus.",
|
||||
"Hängen Sie <strong>nicht</strong> dieselbe Partition an mehrere Container an, die sie gleichzeitig bereitstellen könnten – gleichzeitige Schreibvorgänge beschädigen das Dateisystem.",
|
||||
"<strong>Alte Metadaten</strong> (RAID / ZFS / LVM-Signaturen) müssen manuell gelöscht werden, bevor Sie das Skript formatieren lassen, andernfalls weigert sich <code>mkfs</code> zu überschreiben. Verwenden Sie dafür das <wipeLink>Format / Wipe Physical Disk</wipeLink> Tool."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"unprivTitle": "\"Kann nicht mit einem unprivilegierten Container fortfahren\"",
|
||||
"unprivBody": "Sie haben die Konvertierung abgelehnt; das Skript wurde daher ohne Änderungen beendet. Um fortzufahren, führen Sie es erneut aus und stimmen zu: Das Skript stoppt den Container, sichert seine Konfiguration in <code>/etc/pve/lxc/<CTID>.conf.bak</code> und ersetzt <code>unprivileged: 1</code> durch <code>unprivileged: 0</code>. Diese Änderung allein wandelt die UID-/GID-Eigentümer vorhandener Dateien nicht um; sichern Sie den Container daher vorher und passen Sie die Eigentümer an. Alternativ stellen Sie ihn privilegiert wieder her oder erstellen ihn neu.",
|
||||
"permsTitle": "Berechtigungen im Container sind falsch",
|
||||
"permsBody": "Beim Einhängen in einen privilegierten Container bleiben vorhandene Dateieigentümer erhalten; ein neues Dateisystem gehört häufig <code>root:root</code>. Läuft der Dienst unter einem anderen Benutzer, etwa <code>www-data</code> für Nextcloud, prüfen Sie dessen UID/GID und passen Sie die nötigen Dateien mit <code>chown</code>/<code>chmod</code> an. Dies verändert auch den zugrunde liegenden Datenträger."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"label": "Datenträger in VM importieren",
|
||||
"tail": " — entsprechender Ablauf für VMs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Einhängepunkte (Host ↔ CT)",
|
||||
"tail": "- Hostverzeichnisse mit einem CT teilen, anstatt eine ganze Festplatte anzuhängen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/vm-ct-commands",
|
||||
"label": "VM und CT Verwaltungsbefehle",
|
||||
"tail": "- pct config / push / pull Referenz."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Datenträger zu VM importieren | ProxMenux Dokumentation",
|
||||
"description": "Befestigen Sie eine physische Festplatte an eine vorhandene Proxmox VM mit ProxMenux. Sichere Festplattenerkennung (ausgenommen System, montiert, in Gebrauch, ZFS/RAID/LVM), persistente /dev/disk/by-id-Pfade und SATA / SCSI / VirtIO / IDE-Schnittstellen.",
|
||||
"ogTitle": "Datenträger zu VM importieren | ProxMenux Dokumentation",
|
||||
"ogDescription": "Befestigen Sie eine physische Festplatte an eine vorhandene Proxmox VM. Verwendet persistente /dev/disk/by-id-Pfade und unterstützt SATA / SCSI / VirtIO / IDE."
|
||||
},
|
||||
"header": {
|
||||
"title": "Datenträger in VM importieren",
|
||||
"description": "Weisen Sie einer vorhandenen VM ein physisches Laufwerk des Proxmox-Hosts zu. ProxMenux erkennt freie Laufwerke, lässt Sie Ziel-VM und Bustyp (SATA/SCSI/VirtIO/IDE) wählen und verwendet persistente /dev/disk/by-id-Pfade. So bleibt die Zuordnung bei Neustarts und geänderter Gerätereihenfolge bestehen.",
|
||||
"section": "Datenträgerverwaltung · VM"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Ein physisches Laufwerk wird als Backend einer virtuellen Laufwerksschnittstelle zugewiesen. Der Gast erhält nicht automatisch native SMART-Daten oder Funktionen des physischen Controllers; dafür ist Controller-PCI-Passthrough geeignet. Das Laufwerk wird, falls vorhanden, über seinen Pfad <code>/dev/disk/by-id/…</code> zugewiesen, sodass eine geänderte Gerätereihenfolge beim Start die Zuordnung nicht unterbricht; andernfalls wird <code>/dev/sdX</code> verwendet."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Fluss hat zwei Phasen mit klarer Trennung zwischen \"Sammeln von Informationen und Entscheidungen\" und \"tatsächliches Anbringen von Festplatten am VM\". Bis zur endgültigen Bestätigung bleibt die VM-Konfiguration unberührt.",
|
||||
"summary": "ProxMenux blendet unsichere Kandidaten aus: Root-Laufwerk, auf dem Host eingehängte Laufwerke, aktive ZFS-/LVM-/RAID-Mitglieder und bereits in VM-/LXC-Konfigurationen referenzierte Laufwerke. Laufwerke mit <em>alten</em>, nicht mehr verwendeten ZFS-/RAID-/LVM-Metadaten erscheinen mit ⚠, werden aber nicht gesperrt."
|
||||
},
|
||||
"prereqs": {
|
||||
"heading": "Voraussetzungen",
|
||||
"items": [
|
||||
"Mindestens ein VM, der auf dem Host definiert ist (das Skript wird direkt an <code>qm list</code> gesendet).",
|
||||
"Die <strong>Ziel-VM ist ausgeschaltet</strong>. Läuft sie, bricht das Skript mit einer Meldung ab; das Hinzufügen im laufenden Betrieb ist nicht Teil dieses Ablaufs.",
|
||||
"Mindestens eine physische Festplatte auf dem Host, die nicht vom Host oder einem anderen Gast verwendet wird."
|
||||
]
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Ziel-VM auswählen",
|
||||
"bodyRich": "ProxMenux listet alle VMs auf dem Host über <code>qm list</code> auf. Wählen Sie die VM für das Laufwerk. Läuft sie, bricht das Skript ab und fordert Sie auf, sie zuerst herunterzufahren."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie die physische Festplatte(n) zum Anbringen",
|
||||
"img": "/disk/disk-selection.png",
|
||||
"caption": "Freie Festplatten auf dem Host erkannt (mit ⚠ Labels für veraltete Metadaten)",
|
||||
"body": "Das Skript scannt jede Host-Disk und zeigt nur diejenigen an, die sicher angehängt werden können. Mit der Checkliste können Sie eine oder mehrere auf einmal auswählen. Disks mit alten ZFS / LVM / RAID-Signaturen werden immer noch angezeigt, gekennzeichnet mit ⚠, so dass Sie wissen, dass sie ein Wischen benötigen, bevor der Gast sie formatieren kann."
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie die Bus-Schnittstelle",
|
||||
"img": "/disk/disk-assigment.png",
|
||||
"caption": "Auswahl der Busschnittstellen",
|
||||
"intro": "Wählen Sie aus, wie der Gast die Festplatte sehen soll:",
|
||||
"items": [
|
||||
"<strong>SCSI</strong> – moderner Standard für Linux und Windows mit installierten VirtIO-SCSI-Treibern.",
|
||||
"<strong>SATA</strong> — breite Kompatibilität, funktioniert out of the box auf praktisch jedem Gast.",
|
||||
"<strong>VirtIO</strong>: effizientes paravirtualisiertes Blockgerät; benötigt Gasttreiber.",
|
||||
"<strong>IDE</strong>: für ältere Gäste ohne einen der oben genannten Treiber."
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Zuweisen und prüfen",
|
||||
"bodyRich": "ProxMenux verbindet jede ausgewählte Festplatte mit dem besten <code>/dev/disk/by-id/</code>-Pfad, überspringt Slot-Indizes, die bereits in der VM-Konfiguration verwendet werden (<code>scsi0</code>, <code>sata0</code>, ...) und liest die Konfiguration erneut, um die Zuordnung zu bestätigen. Am Ende wird eine Zusammenfassung gedruckt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Das Skript ist ein Wrapper um <code>qm set</code>. Der genaue Befehl für eine einzelne Festplatte sieht so aus:",
|
||||
"migrationTitle": "Live Migration ist nicht möglich",
|
||||
"migrationBody": "Eine VM mit einem direkt zugewiesenen physischen Laufwerk ist <strong>an den Host gebunden, der dieses bereitstellt</strong>. Ein anderer Knoten hat normalerweise weder denselben Pfad <code>/dev/disk/by-id/…</code> noch dessen Daten. Sichern und übertragen Sie diese separat oder verwenden Sie verwaltete virtuelle Laufwerke auf gemeinsamem oder unterstützt repliziertem Speicher. Gehen Sie nicht davon aus, dass Proxmox-Speicherreplikation dieses Gerät umfasst.",
|
||||
"shareTitle": "Teilen Sie keine physische Festplatte zwischen VMs",
|
||||
"shareBody": "Wenn Sie dieselbe physische Festplatte gleichzeitig an zwei VMs anbringen, werden die Daten beim nächsten Schreiben beschädigt. ProxMenux erkennt diese Situation und blockiert sie, aber wenn Sie das Skript umgehen (direktes <code>qm set</code>), stellen Sie sicher, dass nur ein Gast jemals die Festplatte mountet."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noDisksTitle": "\"Für diesen VM sind keine Festplatten verfügbar\"",
|
||||
"noDisksIntro": "Das Skript fand Festplatten, aber jeder Kandidat wurde herausgefiltert. Häufige Gründe:",
|
||||
"noDisksItems": [
|
||||
"Jede verbleibende Festplatte wird bereits in der Konfiguration des Ziels VM referenziert.",
|
||||
"Jede verbleibende Festplatte wird auf dem Host montiert oder ist Teil eines aktiven ZFS / LVM / RAID.",
|
||||
"Der Host hat nur die Root Disk installiert."
|
||||
],
|
||||
"noDisksOutro": "Führen Sie <code>lsblk -f</code> auf dem Host aus, um den Status jeder Festplatte zu überprüfen.",
|
||||
"noVisibleTitle": "VM sieht die Festplatte nach dem Booten nicht",
|
||||
"noVisibleBody": "Bei <strong>SCSI</strong> oder <strong>VirtIO</strong> benötigt der Gast den passenden Treiber. Linux bringt ihn im Kernel mit; unter Windows installieren Sie ihn von der VirtIO-ISO (siehe <winLink>VM erstellen: Windows</winLink>). SATA auf der Hardware-Registerkarte der VM ist ein schneller Test, ob das Laufwerk zugewiesen ist."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-image-vm",
|
||||
"label": "Disk-Image in VM importieren",
|
||||
"tail": " — derselbe Ablauf für Disk-Image-Dateien (qcow2 / vmdk / raw / img)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/import-disk-lxc",
|
||||
"label": "Datenträger in LXC importieren",
|
||||
"tail": " — entsprechender Ablauf für LXC-Container."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"label": "Controller oder NVMe zu VM hinzufügen",
|
||||
"tail": "- wenn Sie einen vollständigen PCIe / NVMe-Durchgang anstelle eines Festplattenanschlusses benötigen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Speicher- und Festplattenbefehle",
|
||||
"tail": "qm importdisk und zugehörige Shell-Referenz."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,135 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox-Datenträgerverwaltung: VM/LXC-Zuweisung, SMART-Tests, Löschen | ProxMenux",
|
||||
"description": "Verwalten Sie physische Laufwerke auf einem Proxmox-VE-Host mit ProxMenux: Laufwerke VMs oder LXC zuweisen (qm set scsi/sata/virtio, pct mp), img-/qcow2-/vmdk-/raw-Images importieren, ganze HBAs oder NVMe-Controller durchreichen, Laufwerke mit Sicherheitsprüfungen löschen und SMART-Selbsttests ausführen.",
|
||||
"ogTitle": "Proxmox-Datenträgerverwaltung: VM/LXC-Zuweisung, SMART-Tests, Löschen",
|
||||
"ogDescription": "Laufwerke VMs/LXC zuweisen, Images importieren, Controller per PCI durchreichen, Laufwerke sicher bedienen und SMART-Tests auf Proxmox VE ausführen.",
|
||||
"twitterTitle": "Proxmox-Datenträgerverwaltung | ProxMenux",
|
||||
"twitterDescription": "Laufwerke VMs/LXC zuweisen, Images importieren, PCI-Passthrough, Löschen mit Sicherheitsprüfungen und SMART-Tests."
|
||||
},
|
||||
"header": {
|
||||
"title": "Festplattenmanager",
|
||||
"description": "Das Menü Datenträgerverwaltung bündelt ProxMenux-Werkzeuge für physische Laufwerke auf einem Proxmox-Host: Zuweisung an VMs und LXC, Import von Disk-Images, Passthrough ganzer Controller oder NVMe-Geräte, Löschen mit Sicherheitsprüfungen und SMART-Tests.",
|
||||
"section": "Festplattenmanager"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wofür dieses Menü ist",
|
||||
"body": "Diese Werkzeuge arbeiten mit <strong>für den Proxmox-Host sichtbaren physischen Laufwerken und dort gespeicherten Image-Dateien</strong>. Es gibt drei Gruppen: <strong>VM</strong> (Laufwerke zuweisen oder Images importieren), <strong>LXC</strong> (Laufwerke an Container anbinden) und <strong>Dienstprogramme</strong> (Formatierung und SMART-Status). Zuweisung und Löschen blenden Systemlaufwerke und belegte Laufwerke aus oder sperren sie; SMART-Prüfungen können sie ohne Löschen untersuchen."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Menüs",
|
||||
"body": "Wählen Sie im Hauptmenü von ProxMenux <strong>Disk Manager</strong>. Sie werden sehen:",
|
||||
"imageAlt": "Disk Manager Menü mit VM, LXC und Utilities Blöcken"
|
||||
},
|
||||
"groups": {
|
||||
"heading": "Drei Werkzeuggruppen",
|
||||
"intro": "Das Disk Manager-Menü ist in drei Gruppen unterteilt: <strong>VM</strong>, <strong>LXC</strong> und <strong>Utilities</strong>. Klicken Sie auf eine Karte, um direkt zu den Werkzeugen in dieser Gruppe zu springen.",
|
||||
"vmTitle": "VM",
|
||||
"vmBody": "Tools, die auf vorhandenen virtuellen Maschinen arbeiten. Der VM muss ausgeschaltet werden; ProxMenux validiert dies, bevor er die Konfiguration berührt.",
|
||||
"vmItems": [
|
||||
"Datenträger in VM importieren",
|
||||
"Disk-Image in VM importieren",
|
||||
"Controller oder NVMe zu VM hinzufügen"
|
||||
],
|
||||
"lxcTitle": "LXC",
|
||||
"lxcBody": "Werkzeuge für bestehende LXC-Container. Dieses Skript benötigt einen privilegierten Container und bietet bei Bedarf die Änderung der Einstellung an. Lesen Sie zuerst die Hinweise zur Konvertierung und zu Dateieigentümern auf der Werkzeugseite.",
|
||||
"lxcItems": [
|
||||
"Datenträger in LXC importieren"
|
||||
],
|
||||
"utilitiesTitle": "Dienstprogramme",
|
||||
"utilitiesBody": "Hostseitige Tools, die auf den Festplatten selbst arbeiten, unabhängig von VM oder Containern.",
|
||||
"utilitiesItems": [
|
||||
"Physischen Datenträger formatieren / löschen",
|
||||
"SMART-Festplattenstatus und -test"
|
||||
]
|
||||
},
|
||||
"vm": {
|
||||
"heading": "VM",
|
||||
"intro": "Tools, die auf vorhandenen virtuellen Maschinen arbeiten. Der VM muss ausgeschaltet werden; ProxMenux validiert dies, bevor er die Konfiguration berührt.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "HardDrive",
|
||||
"href": "/docs/disk-manager/import-disk-vm",
|
||||
"title": "Datenträger in VM importieren",
|
||||
"description": "Befestigen Sie eine nicht zugewiesene physische Festplatte an eine vorhandene VM. Unterstützt SATA / SCSI / VirtIO / IDE, verwendet persistente /dev/disk/by-id-Pfade."
|
||||
},
|
||||
{
|
||||
"icon": "FileDown",
|
||||
"href": "/docs/disk-manager/import-disk-image-vm",
|
||||
"title": "Disk-Image in VM importieren",
|
||||
"description": "Importieren Sie Disk-Image-Dateien (.img / .qcow2 / .vmdk / .raw) in eine vorhandene VM. Zweiphasiger Ablauf mit qm importdisk im Hintergrund."
|
||||
},
|
||||
{
|
||||
"icon": "Cpu",
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"title": "Controller oder NVMe zu VM hinzufügen",
|
||||
"description": "PCI-Durchgang eines ganzen SATA / SAS HBA- oder NVMe-Geräts zu einem VM. Behandelt IOMMU Enablement und Konflikterkennung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"lxc": {
|
||||
"heading": "LXC",
|
||||
"intro": "Werkzeuge für bestehende LXC-Container. Dieses Skript benötigt einen privilegierten Container und bietet bei Bedarf die Änderung der Einstellung an. Lesen Sie zuerst die Hinweise zur Konvertierung und zu Dateieigentümern auf der Werkzeugseite.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Boxes",
|
||||
"href": "/docs/disk-manager/import-disk-lxc",
|
||||
"title": "Datenträger in LXC importieren",
|
||||
"description": "Befestigen Sie eine nicht zugewiesene physische Festplatte an einem vorhandenen LXC-Container als Montagepunkt. Behandelt Dateisystemerkennung / Format und privilegierte Konvertierung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"utilities": {
|
||||
"heading": "Dienstprogramme",
|
||||
"intro": "Hostseitige Tools, die auf den Festplatten selbst arbeiten, unabhängig von VM oder Containern.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Eraser",
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"title": "Physische Festplatte formatieren/löschen (sicher)",
|
||||
"description": "Laufwerke mit strengen Sicherheitskontrollen löschen: Nur vollständig freie Laufwerke werden angezeigt, und eine doppelte Bestätigung ist immer erforderlich."
|
||||
},
|
||||
{
|
||||
"icon": "Activity",
|
||||
"href": "/docs/disk-manager/smart-disk-test",
|
||||
"title": "SMART-Festplattenstatus und -test",
|
||||
"description": "Führen Sie SMART Gesundheitschecks und kurze / lange Selbsttests auf SATA-, SAS- und NVMe-Laufwerken durch. Exportiert JSON für den Monitor."
|
||||
}
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"title": "Sicherheitsregeln für Laufwerkszuweisung und Löschen",
|
||||
"intro": "Zuweisungs- und Löschvorgänge filtern Geräte aus, die den Host gefährden könnten:",
|
||||
"items": [
|
||||
"Das <strong>Systemlaufwerk</strong> sowie Root-Pool, Swap und aktive ZFS-/LVM-/RAID-Mitglieder bleiben ausgeblendet.",
|
||||
"Auf dem Host <strong>eingehängte</strong> Laufwerke werden ausgeblendet oder bei der Ausführung gesperrt.",
|
||||
"Datenträger <strong>, auf die mit einem laufenden VM oder LXC</strong> verwiesen wird, können nicht neu zugewiesen oder gelöscht werden.",
|
||||
"Operationen, die den Host-Status ändern können (IOMMU enable, Wipe) erfordern eine explizite Bestätigung."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share",
|
||||
"label": "Speicher- und Freigabemanager",
|
||||
"tail": "- registrieren Sie den Speicher in Proxmox selbst (NFS / Samba / iSCSI / local) und teilen Sie Ordner zwischen Host und CTs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Speicher- und Festplattenbefehle",
|
||||
"tail": "— Blockgeräte, LVM, pvesm, SMART Referenz."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "ZFS Verwaltungsbefehle",
|
||||
"tail": "— für ZFS-Pools und Datensätze."
|
||||
},
|
||||
{
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"label": "GPU zu VM hinzufügen (Passthrough)",
|
||||
"tail": "- die gleichen IOMMU / VFIO-Konzepte für GPUs."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,146 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "SMART-Laufwerksstatus und Tests | ProxMenux-Dokumentation",
|
||||
"description": "Führen Sie SMART-Gesundheitsprüfungen und Festplattentests auf Proxmox VE mit ProxMenux aus. Unterstützt SATA / SAS (smartmontools) und NVMe (nvme-cli). Kurze und lange Selbsttests, JSON Export für ProxMenux Monitor Integration.",
|
||||
"ogTitle": "SMART-Laufwerksstatus und Tests | ProxMenux-Dokumentation",
|
||||
"ogDescription": "SMART Gesundheitschecks und Selbsttests für SATA / SAS und NVMe Laufwerke auf Proxmox. JSON Export für den Monitor."
|
||||
},
|
||||
"header": {
|
||||
"title": "SMART-Festplattenstatus und -test",
|
||||
"description": "Lesen Sie SMART-Daten und lösen Sie Selbsttests auf den physischen Festplatten aus, die an den Proxmox-Host angeschlossen sind. ProxMenux installiert automatisch Smartmontools für SATA / SAS und nvme-cli für NVMe, führt die Aktion innerhalb der Laufwerk-Firmware aus (lange Tests überleben Terminalschluss) und exportiert JSON-Ergebnisse für den ProxMenux Monitor.",
|
||||
"section": "Disk Manager · Dienstprogramme"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wofür das ist",
|
||||
"body": "SMART (Self-Monitoring, Analysis and Reporting Technology) ermöglicht es dem Laufwerk selbst, seinen Zustand zu melden und Selbsttests durchzuführen. Dieses Tool stellt diese Daten frei, ohne dass Sie sich die richtige <code>smartctl</code>/<code>nvme</code>-Aufrufung merken müssen, und behält die Ausgabe als JSON, so dass der Monitor Trends im Laufe der Zeit zeichnen kann."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Alle Aktionen hier sind zerstörungsfrei - SMART liest die Laufwerk-Firmware-Zähler, und Selbsttests werden innerhalb des Laufwerks selbst in die Warteschlange gestellt. Es ist keine Phasentrennung erforderlich. Der Ablauf ist: Abhängigkeitsprüfung → Festplattenauswahl → Aktionsauswahl → Werkzeugaufruf (smartctl oder nvme-cli abhängig vom Festplattenbus) → gedruckte Ausgabe plus JSON Export für den Monitor."
|
||||
},
|
||||
"deps": {
|
||||
"heading": "Abhängigkeiten",
|
||||
"body": "Das Tool installiert automatisch, was es beim ersten Durchlauf benötigt. SATA / SAS-Laufwerke verlassen sich auf <code>smartmontools</code>; NVMe-Laufwerke verlassen sich auf <code>nvme-cli</code>. Beide:"
|
||||
},
|
||||
"actions": {
|
||||
"heading": "Verfügbare Maßnahmen",
|
||||
"headerAction": "Aktion",
|
||||
"headerWhat": "Was gelesen oder ausgeführt wird",
|
||||
"headerDur": "Dauer",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Schneller Gesundheitszustand",
|
||||
"whatRich": "Insgesamt PASSED/FAILED + Schlüsselattribute.<br /><code>smartctl -H</code> + <code>-A</code> (SATA/SAS) oder <code>nvme smart-log</code> (NVMe).",
|
||||
"dur": "Sofort"
|
||||
},
|
||||
{
|
||||
"action": "Vollständiger Bericht",
|
||||
"whatRich": "Vollständige SMART-Daten, scrollbar. <code>smartctl -x</code> für SATA/SAS oder <code>nvme smart-log</code> + <code>id-ctrl</code> für NVMe.",
|
||||
"dur": "Sofort"
|
||||
},
|
||||
{
|
||||
"action": "Kurztest",
|
||||
"what": "Grundlegende Oberfläche und elektrische Überprüfung, in der Warteschlange innerhalb der Firmware des Laufwerks.",
|
||||
"dur": "~2 Minuten"
|
||||
},
|
||||
{
|
||||
"action": "Lange Prüfung",
|
||||
"what": "Vollständiger Scan der gesamten Oberfläche. Läuft auf der Laufwerk-Hardware - bleibt bestehen, auch wenn Sie das Terminal schließen.",
|
||||
"dur": "Stunden (abhängig von der Laufwerksgröße)"
|
||||
},
|
||||
{
|
||||
"action": "Testfortschritt prüfen",
|
||||
"what": "Status des aktiven oder letzten Selbsttests.",
|
||||
"dur": "Sofort"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Lange Tests laufen nach dem Schließen des Terminals weiter",
|
||||
"tipBody": "Ein langer Test läuft <em>im Laufwerk</em> und benötigt keinen weiterlaufenden ProxMenux-Prozess. Schließen Sie das Terminal und verwenden Sie später <strong>Testfortschritt prüfen</strong>. Ein Host-Neustart, Controller-Reset oder Stromausfall kann den Test und die Ergebniserfassung unterbrechen; eine automatische Fortsetzung ist nicht garantiert."
|
||||
},
|
||||
"json": {
|
||||
"heading": "JSON Export für den Monitor",
|
||||
"intro": "Status-, Kurztest- und Fortschrittsaktionen schreiben eine JSON-Datei mit Zeitstempel nach <code>/usr/local/share/proxmenux/smart/<disk>/</code>; Langtestergebnisse werden im Hintergrund erfasst. Der vollständige Bericht wird nur angezeigt. Die Struktur ist:",
|
||||
"outro": "ProxMenux Monitor liest diese Dateien zur Darstellung von Zustandstrends je Laufwerk. Beim Erreichen der Aufbewahrungsgrenze werden alte Dateien automatisch entfernt."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Schritt für Schritt",
|
||||
"stepLabel": "Schritt",
|
||||
"list": [
|
||||
{
|
||||
"title": "Laufwerk auswählen",
|
||||
"body": "ProxMenux listet jede physische Festplatte auf dem Host mit ihrem Modell und ihrer Größe auf. Im Gegensatz zum Format-Tool wird diese Liste nicht durch die Sicherheit gefiltert - das Lesen von SMART ist eine zerstörungsfreie Operation.",
|
||||
"img": "/disk/smart/disk-selection.png",
|
||||
"alt": "SMART Plattenauswahlmenü",
|
||||
"caption": "SMART Plattenauswahlmenü"
|
||||
},
|
||||
{
|
||||
"title": "Wählen Sie eine Aktion",
|
||||
"body": "Wählen Sie schnellen Status, vollständigen Bericht, Kurztest, Langtest oder Testfortschritt. Das Menü bleibt nach jeder Aktion offen, sodass Sie mehrere Abfragen desselben Laufwerks ausführen können.",
|
||||
"img": "/disk/smart/action-menu.png",
|
||||
"alt": "SMART Aktionsmenü",
|
||||
"caption": "SMART Aktionsmenü (5 Aktionen + Abbruch)"
|
||||
},
|
||||
{
|
||||
"title": "(Nur langer Test) Hintergrundausführung bestätigen",
|
||||
"body": "ProxMenux weist darauf hin, dass der Test nach dem Schließen des Terminals weiterläuft, und zeigt den Speicherort der JSON-Ergebnisse. Bestätigen Sie, um den Test zu starten.",
|
||||
"img": "/disk/smart/long-test-warning.png",
|
||||
"alt": "Dialog über lange Testbestätigung",
|
||||
"caption": "Lange Testbestätigung – läuft im Hintergrund, Ergebnis wird in JSON gespeichert"
|
||||
},
|
||||
{
|
||||
"title": "Prüfergebnisse",
|
||||
"bodyRich": "Status-, Test- und Fortschrittsausgaben erscheinen im Terminal; <strong>Vollständiger Bericht</strong> öffnet sich in einem scrollbaren Dialog. JSON wird für die oben genannten Aktionen exportiert, nicht für den vollständigen Bericht. Verwenden Sie bei Langtests später <strong>Testfortschritt prüfen</strong> für dasselbe Laufwerk.",
|
||||
"img": "/disk/smart/quick-status.png",
|
||||
"alt": "Schnelle Ausgabe des Gesundheitszustands",
|
||||
"caption": "Schnelle Ausgabe des Gesundheitszustands (SATA — smartctl -H + -A)"
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelle Äquivalente",
|
||||
"nvmeWarnTitle": "NVMe Selbsttests sind Laufwerk-Firmware abhängig",
|
||||
"nvmeWarnBody": "Nicht jedes NVMe-Laufwerk unterstützt den kurzen / langen Selbsttestbefehl. Wenn ein Laufwerk den Test ablehnt, sind das SMART-Protokoll und die ID-Controllerdaten (<code>nvme smart-log</code> + <code>id-ctrl</code>) immer noch das zuverlässigste Gesundheitssignal."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noSmartTitle": "\"Konnte SMART-Daten aus /dev/sdX nicht lesen\"",
|
||||
"noSmartBody": "Die Festplatte befindet sich wahrscheinlich hinter einem RAID / SAS-Controller, der SMART nicht durchläuft. Versuchen Sie mit Megaraid-basierten Karten <code>smartctl -d megaraid,N /dev/sdX</code>. Für HBAs im IT-Modus funktioniert der direkte Aufruf.",
|
||||
"longTitle": "Langer Test nie abgeschlossen",
|
||||
"longBody": "Der Test läuft in der Laufwerksfirmware; hohe E/A-Last kann ihn verzögern. Nutzen Sie eine ruhige Zeit, etwa nachts. Bei SATA zeigt <code>smartctl -c</code> den verbleibenden Prozentsatz, bei SAS <code>smartctl -l selftest</code>; das Selbsttestprotokoll zeigt Abschlussstatus und gegebenenfalls fehlerhafte LBAs. Lesefehler müssen untersucht werden; langsamer Fortschritt allein beweist keinen defekten Sektor."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"label": "Physischen Datenträger formatieren / löschen",
|
||||
"tail": "Wiederverwendung einer Festplatte, nachdem bestätigt wurde, dass sie gesund ist."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"label": "Speicher- und Laufwerksbefehle → SMART-Laufwerksstatus",
|
||||
"tail": "Referenz smartctl/nvme."
|
||||
},
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "ZFS Verwaltungsbefehle",
|
||||
"tail": " — zpool scrub prüft ZFS-Datenprüfsummen und ergänzt SMART-Hardwaretests."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/storage",
|
||||
"label": "ProxMenux Monitor — Speicherregister",
|
||||
"tail": " — Laufwerksdetailansicht mit den hier exportierten JSON-Daten: vollständige SMART-Tabelle, Verlauf und PDF-Bericht."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/hardware",
|
||||
"label": "ProxMenux Monitor — Register Hardware",
|
||||
"tail": "Speicherzusammenfassung mit Modell, Kapazität und ausgehandelter Verbindungsgeschwindigkeit (aktuell vs. maximal auf NVMe)."
|
||||
},
|
||||
{
|
||||
"href": "/docs/disk-manager",
|
||||
"label": "Übersicht Disk Manager",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Schnittstellen sichern und neu starten | ProxMenux-Dokumentation",
|
||||
"description": "Manuelle Schnappschüsse erstellen und unter /var/backups/proxmenux/ gespeicherte Backups von /etc/network/interfaces durchsuchen und wiederherstellen. Mit bestätigtem Neustart des Netzwerkdienstes und Schnellansicht der aktuellen Konfiguration.",
|
||||
"ogTitle": "Schnittstellen sichern und neu starten | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Snapshot und Wiederherstellung der Proxmox-Netzwerkkonfiguration; Neustart des Netzwerkdienstes mit Bestätigung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Schnittstellen sichern und neu starten",
|
||||
"description": "Vier Werkzeuge für /etc/network/interfaces: einen manuellen Schnappschuss erstellen, die aktuelle Konfiguration anzeigen, ein früheres Backup mit optionaler Vorschau wiederherstellen und den Netzwerkdienst nach ausdrücklicher Zustimmung neu starten. Sie verwenden dasselbe Backup-Verzeichnis wie die geführten Reparaturen.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Verwaltet das gleiche Backup-Verzeichnis, das von den geführten Reparaturflüssen verwendet wird (<code>/var/backups/proxmenux/</code>). Sie können vor jeder manuellen Änderung eine zusätzliche Momentaufnahme machen, alle vorhandenen Backups durchsuchen und zu einem von ihnen zurückkehren - immer mit einem neuen Pre-Restore-Backup, das automatisch als zweites Sicherheitsnetz übernommen wird."
|
||||
},
|
||||
"shared": {
|
||||
"heading": "Das gemeinsame Backup-Verzeichnis",
|
||||
"intro": "Jedes Backup im Netzwerkmenü landet an der gleichen Stelle:",
|
||||
"outro": "Dateinamen werden mit einem Zeitstempel versehen, nach Datum sortiert und nie überschrieben. Das Verzeichnis wird bei der ersten Verwendung erstellt."
|
||||
},
|
||||
"show": {
|
||||
"heading": "Netzwerkkonfigurationsdatei anzeigen",
|
||||
"body": "Gibt <code>/etc/network/interfaces</code> unverändert im Terminal aus. Schreibgeschützt. Nützlich zur Kontrolle vor einem Backup oder nach einer Wiederherstellung. Es gibt kein separates Werkzeug zum Vergleich mit dem vorherigen Backup; die aktuelle Datei direkt zu prüfen ist daher am einfachsten."
|
||||
},
|
||||
"create": {
|
||||
"heading": "Netzwerk-Backup erstellen",
|
||||
"body": "Kopiert den aktuellen <code>/etc/network/interfaces</code> mit einem neuen Zeitstempel in das Backup-Verzeichnis. Das ist es — keine Analyse, keine Aufforderungen, nur eine Momentaufnahme.",
|
||||
"whenTitle": "Wann Sie ein manuelles Backup durchführen sollten",
|
||||
"whenBody": "Vor der manuellen Bearbeitung von <code>/etc/network/interfaces</code>, vor der Installation eines Pakets, das den Netzwerkstack ändern kann (z. B. NetworkManager, Open vSwitch), oder vor Hardwareänderungen. Geführte Reparaturen erstellen bereits automatisch einen Schnappschuss — diese Option ist für <em>manuelle</em> Eingriffe."
|
||||
},
|
||||
"restore": {
|
||||
"heading": "Netzwerksicherung wiederherstellen",
|
||||
"intro": "Listet alle Backups in <code>/var/backups/proxmenux/</code> vom neuesten zum ältesten auf und führt durch eine abgesicherte Wiederherstellung:",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Wählen Sie ein Backup",
|
||||
"body": "Ein Menü listet jedes Backup nach seinem Zeitstempel auf. Wenn keine Backups vorhanden sind, wird der Flow mit einer klaren Nachricht beendet.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Optionale Vorschau",
|
||||
"body": "Bietet an, das ausgewählte Backup in einer scrollbaren Ansicht zu öffnen, bevor Sie es festlegen. Standardmäßig ja – überspringen Sie es nicht auf einem entfernten Host.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Backup vor der Wiederherstellung",
|
||||
"body": "Erstellt vor dem Überschreiben von <code>/etc/network/interfaces</code> ein <strong>weiteres</strong> Backup des aktuellen Zustands. Eine Wiederherstellung ist selbst ein destruktiver Vorgang. Mit dem neuen Schnappschuss können Sie zurückkehren, falls das gewählte Backup falsch war.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "4. Anwenden der Wiederherstellung",
|
||||
"body": "Kopiert das ausgewählte Backup über <code>/etc/network/interfaces</code>. Die Dateiänderung ist auf der Festplatte; der Live-Kernel-Zustand spiegelt immer noch die vorherige Konfiguration wider.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Optionaler Neustart",
|
||||
"body": "Fragt, ob <code>systemctl restart networking</code> jetzt ausgeführt werden soll. Lehnen Sie ab, um die Änderung auf den nächsten Neustart zu verschieben.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"autoBackupTitle": "Jede Wiederherstellung erstellt automatisch ein eigenes Backup",
|
||||
"autoBackupBody": "Die Auswahl von <em>Netzwerksicherung wiederherstellen</em> erstellt immer einen neuen Schnappschuss der <em>aktuellen</em> Konfiguration, bevor sie überschrieben wird. Falls Sie das falsche Backup wiederherstellen, enthält die neueste Datei in <code>/var/backups/proxmenux/</code> den vorherigen Zustand."
|
||||
},
|
||||
"restart": {
|
||||
"heading": "Starten Sie den Netzwerkdienst neu",
|
||||
"body": "Führt nach einer Ja/Nein-Bestätigung <code>systemctl restart networking</code> aus. Meldet das Ergebnis mit <code>msg_ok</code> / <code>msg_error</code>. Die meisten Abläufe in diesem Menü bieten am Ende selbst einen Neustart an. Diese Option dient zum Neustart nach manueller Bearbeitung oder wenn Sie den zuvor angebotenen Neustart abgelehnt haben.",
|
||||
"warnTitle": "Kurze Trennung garantiert; dauerhafte Trennung möglich",
|
||||
"warnBody": "Ein Neustart von <code>networking</code> deaktiviert alle in <code>/etc/network/interfaces</code> deklarierten Schnittstellen und wendet ihre Konfiguration erneut an. SSH-Sitzungen über diese Schnittstellen brechen ab. Ist die neue Konfiguration ungültig, kehrt das Netzwerk nicht zurück. Nur ausführen, wenn:",
|
||||
"warnItems": [
|
||||
"Sie Konsolen-/IPMI-/iKVM-Zugriff bereithalten, <em>oder</em>",
|
||||
"Sie sich direkt neben dem Rechner befinden, <em>oder</em>",
|
||||
"Sie haben gerade erfolgreich zu einer bekannten guten Konfiguration zurückgerollt und wollen sie anwenden."
|
||||
]
|
||||
},
|
||||
"manualRollback": {
|
||||
"heading": "Manuelles Rollback von einer Konsole",
|
||||
"intro": "Wenn Sie das Menü nicht erreichen können (kein SSH, Dialogabsturz, ...), aber eine Konsole erreichen können, besteht das Rollback aus zwei Befehlen:",
|
||||
"outro": "Das ist <em>dieselbe</em> Operation wie im Menü, nur von Hand eingegeben. Startet <code>networking</code> weiterhin nicht, prüfen Sie <code>journalctl -u networking -b</code> auf den zugrunde liegenden Syntax- oder Treiberfehler."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noneTitle": "„Keine Backups gefunden“ bei der Wiederherstellung",
|
||||
"noneBody": "Das Verzeichnis <code>/var/backups/proxmenux/</code> existiert nicht oder enthält keine <code>interfaces_backup_*</code>-Dateien. Führen Sie <em>Netzwerk-Backup erstellen</em> mindestens einmal aus oder starten Sie eine geführte Reparatur, die automatisch ein Backup erstellt. Prüfen Sie mit <code>ls /var/backups/proxmenux/</code>.",
|
||||
"unreachTitle": "Der Netzwerkneustart gelingt, aber der Host ist weiterhin nicht erreichbar",
|
||||
"unreachBody": "Entweder ist die neue Konfiguration falsch oder die beim Neustart angewendete Konfiguration weist Ihre Verwaltungs-IP nicht zu. Setzen Sie sie über die Konsole zurück (siehe oben). Nutzen Sie danach <bridgeLink>Brückenanalyse</bridgeLink> und <configLink>Konfigurationsanalyse</configLink>, um den Fehler vor einem erneuten Anwenden zu verstehen.",
|
||||
"emptyTitle": "Die Wiederherstellungsvorschau zeigt eine leere Datei",
|
||||
"emptyBody": "Die Backup-Datei ist leer (0 Bytes). Das passiert, wenn ein Kopiervorgang bei einem früheren Durchlauf unbemerkt fehlgeschlagen ist. Wählen Sie ein älteres Backup oder führen Sie <em>Netzwerk-Backup erstellen</em> jetzt erneut aus, wenn die aktuelle Konfiguration funktioniert."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Brückenanalyse und geführte Reparatur",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": " — der häufigste Grund, warum hier ein Backup erstellt wird."
|
||||
},
|
||||
{
|
||||
"label": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— schreibt auch automatisch an <code>/var/backups/proxmenux/</code>."
|
||||
},
|
||||
{
|
||||
"label": "Diagnose",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": "- Überprüfen Sie den Live-Zustand nach einer Wiederherstellung."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Brückenanalyse & geführte Reparatur | ProxMenux Dokumentation",
|
||||
"description": "Erkennt vmbrX-Bridges mit fehlenden oder ungültigen physischen Ports (typisch nach PCI-Reenumeration), meldet diese mit vorgeschlagenen Shell-Befehlen und bietet eine 5-schrittgesteuerte Reparatur mit obligatorischem Backup.",
|
||||
"ogTitle": "Brückenanalyse & geführte Reparatur | ProxMenux Dokumentation",
|
||||
"ogDescription": "Proxmox-Bridge-Ports nach Hardwareänderungen prüfen und reparieren, mit geführtem Ablauf und sicherer Rückkehr zur vorherigen Konfiguration."
|
||||
},
|
||||
"header": {
|
||||
"title": "Brückenanalyse und geführte Reparatur",
|
||||
"description": "Prüft jede in /etc/network/interfaces deklarierte vmbrX-Bridge und ob ihre physischen Ports tatsächlich existieren. Fehlende Ports können schrittweise repariert werden. Die Analyse ist schreibgeschützt; die Reparatur erfordert Zustimmung, zeigt eine Vorschau und erstellt ein Backup.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Liest jede Bridge in <code>/etc/network/interfaces</code>, prüft ihre Zeile <code>bridge-ports</code> und ob jeder deklarierte Port, etwa <code>enp3s0</code>, auf dem Host existiert. Fehlt ein Port, schlägt das Werkzeug einen Ersatz vor und wendet die Änderung nach ausdrücklicher Zustimmung mit dem Ablauf <strong>sichern, Vorschau anzeigen, anwenden, überprüfen</strong> an."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Wenn Sie das brauchen",
|
||||
"intro": "Linux weist vorhersehbare Schnittstellennamen aus PCI-Topologie und Slot-Reihenfolge zu. Mehrere Ereignisse mischen sie und lassen <code>/etc/network/interfaces</code> auf Namen verweisen, die nicht mehr existieren:",
|
||||
"items": [
|
||||
"Hinzufügen oder Entfernen einer PCIe-Karte (ein NIC, ein GPU, ein HBA, ein NVMe-Träger).",
|
||||
"Verschieben einer vorhandenen Karte in einen anderen PCIe-Slot.",
|
||||
"BIOS / UEFI Updates, die PCI-Geräte erneut aufzählen.",
|
||||
"Migration der Boot-Disk auf andere Hardware."
|
||||
],
|
||||
"outro": "Nach dem nächsten Start versucht die Bridge, einen nicht mehr vorhandenen Port einzubinden. Sie lässt sich nicht aktivieren und der Host verliert seine Netzwerkverbindung. <link>Persistente Schnittstellennamen</link> verhindern eine Wiederholung. Falls Sie bereits ausgesperrt sind, beschreibt diese Seite den Wiederherstellungsweg."
|
||||
},
|
||||
"bigPicture": {
|
||||
"heading": "Überblick",
|
||||
"diagram1": {
|
||||
"arrowLabel": "Stufe 1",
|
||||
"nodes": {
|
||||
"sourceLabel": "/etc/network/interfaces",
|
||||
"sourceDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports enp3s0",
|
||||
"bridgeLabel": "Analysieren (schreibgeschützt)",
|
||||
"bridgeDetail": "ip link show enp3s0\n→ nicht vorhanden",
|
||||
"targetLabel": "Bericht + Vorschlag",
|
||||
"targetDetail": "❌ enp3s0: NICHT GEFUNDEN\nErsetzen mit: eno1\n(noch keine Änderungen)"
|
||||
}
|
||||
},
|
||||
"diagram2": {
|
||||
"arrowLabel": "mit Backup anwenden",
|
||||
"nodes": {
|
||||
"sourceLabel": "Geführte Reparatur",
|
||||
"sourceDetail": "1. Backup\n2. Aktuelle Konfiguration anzeigen\n3. Änderungsvorschau\n4. Anwenden\n5. Überprüfen",
|
||||
"targetLabel": "/etc/network/interfaces (neu)",
|
||||
"targetDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports eno1"
|
||||
}
|
||||
}
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Schritt 1: Analyse (schreibgeschützt)",
|
||||
"intro": "Nach Auswahl von <strong>Brückenkonfiguration analysieren</strong> bricht das Werkzeug sofort ab, falls der Host nicht den klassischen Debian-/Proxmox-Stack nutzt. Andernfalls prüft es jede Bridge und meldet:",
|
||||
"items": [
|
||||
"Brückenname, aktueller Status (UP / DOWN), zugewiesene IP.",
|
||||
"Jeder deklarierte Port und ob er derzeit existiert (<code>ip link show <port></code>).",
|
||||
"Für jeden ungültigen Port: ein vorgeschlagener Ersatz (die erste verfügbare physische Schnittstelle) sowie der genaue Befehl <code>sed</code>, um ihn manuell anzuwenden.",
|
||||
"Brücken ohne <code>bridge-ports</code> und verwaiste <code>auto</code>-Einträge (kein passender <code>iface</code>-Block)."
|
||||
],
|
||||
"readonlyTitle": "Garantie einer schreibgeschützten Analyse",
|
||||
"readonlyBody": "Bis zu diesem Punkt hat das Skript keinen einzigen Änderungsbefehl ausgeführt. Sie können die Analyse offen lassen, die vorgeschlagenen <code>sed</code>-Befehle kopieren und sie manuell anwenden, wenn Sie möchten - oder die nächste Aufforderung akzeptieren, um in die geführte Reparatur einzusteigen."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Schritt 2: geführte Reparatur (5 Schritte)",
|
||||
"intro": "Wird nur gestartet, wenn Sie der Aufforderung am Ende der Analyse zustimmen. Jeder Schritt zeigt die geplante Aktion und bittet vor dem Fortfahren um Bestätigung.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sicherheitssicherung",
|
||||
"body": "Kopiert <code>/etc/network/interfaces</code> in <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Der genaue Sicherungspfad wird vor der Kopie und danach mit dem Rollback-Befehl angezeigt.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Überprüfung der aktuellen Konfiguration",
|
||||
"body": "Öffnet das Live <code>/etc/network/interfaces</code> in einem scrollbaren Dialog, so dass Sie genau sehen können, was geändert werden soll.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Vorgeschlagene Änderungen anzeigen",
|
||||
"body": "Listet genau die betroffenen Bridges und geplanten Portersetzungen auf. Falls inzwischen kein Reparaturbedarf mehr besteht, weil der Port zwischenzeitlich wieder aufgetaucht ist, endet der Ablauf mit <em>„Keine Änderungen erforderlich.“</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Änderungen anwenden",
|
||||
"body": "Für jede betroffene Brücke läuft <code>sed -i \"/iface $bridge/,/bridge-ports/ s/bridge-ports.*/bridge-ports $new_ports/\"</code> gegen <code>/etc/network/interfaces</code>. Wenn für eine Brücke kein gültiger Ersatz verfügbar war, wird die Substitution übersprungen und in Schritt 5 gemeldet.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Überprüfung",
|
||||
"body": "Liest die Datei erneut und bestätigt, dass der neue Port jeder Bridge existiert. Gibt den Befehl zum Zurücksetzen aus (<code>cp <backup> /etc/network/interfaces</code>). Bietet abschließend <strong>Netzwerk neu starten</strong> an — stimmen Sie nur zu, wenn ein Konsolenzugang als Ersatz bereitsteht.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"restartTitle": "Netzwerkneustart ≠ risikoloses Rückgängigmachen",
|
||||
"restartBody": "Die Reparatur wird auf den Datenträger geschrieben, unabhängig davon, ob Sie den Dienst neu starten. <code>systemctl restart networking</code> wendet die Änderung <em>jetzt</em> an und kann Ihre SSH-Sitzung unterbrechen, wenn der neue Port falsch ist. Lehnen Sie ab, wird die Änderung dennoch beim nächsten Systemstart wirksam. Prüfen Sie daher die neue Konfiguration oder setzen Sie sie mit dem angezeigten Befehl zurück."
|
||||
},
|
||||
"edits": {
|
||||
"heading": "Was wird bearbeitet (genau)",
|
||||
"body": "Nur die Zeile <code>bridge-ports</code> jeder betroffenen Bridge. Andere Direktiven (<code>address</code>, <code>netmask</code>, <code>gateway</code>, <code>bridge-stp</code>, …) bleiben unverändert. Das Skript erstellt oder entfernt in diesem Ablauf keine <code>iface</code>-Blöcke — dafür ist <link>Konfigurationsanalyse & Bereinigung</link> zuständig."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"unsupportedTitle": "Die Analyse bricht mit „Nicht unterstützter Netzwerkstack“ ab",
|
||||
"unsupportedBody": "Der Host läuft netplan, systemd-networkd oder NetworkManager. Das Tool unterstützt nur <code>/etc/network/interfaces</code>. Schalten Sie den Host zuerst auf den klassischen Stack oder bearbeiten Sie die Konfiguration mit dem nativen Tooling des Managers (z.B. <code>netplan apply</code>).",
|
||||
"noSuggestTitle": "Kein Vorschlag wird für einen ungültigen Port gedruckt",
|
||||
"noSuggestBody": "Der Host hat null freie physische Schnittstellen (alles befindet sich entweder bereits in einer anderen Brücke oder existiert nicht). Die Analyse greift auf <code>bridge-ports none</code> zurück, so dass die Brücke zumindest ohne Port auftauchen kann. Fügen Sie eine NIC hinzu oder migrieren Sie Ports zwischen Brücken manuell, bevor Sie erneut ausführen.",
|
||||
"stillDownTitle": "Die Reparatur ist abgeschlossen, aber die Brücke ist noch DOWN",
|
||||
"stillDownBody": "<code>sed</code> hat die Datei aktualisiert, aber <code>systemctl restart networking</code> wurde abgelehnt. Führen Sie den Befehl nach Prüfung der neuen Konfiguration manuell aus oder starten Sie das System neu. Wurde der Neustart angenommen und bleibt die Bridge DOWN, prüfen Sie mit <code>ip link show</code>, ob der neue Port existiert, und suchen Sie mit <code>journalctl -u networking</code> nach der Ursache: nicht eingestecktes Kabel, nicht ausgehandelte Verbindung oder ein Port, der schon zu einer anderen Bridge gehört.",
|
||||
"lostSshTitle": "Ich habe den SSH-Zugang direkt nach dem Neustart des Netzwerks verloren",
|
||||
"lostSshIntro": "Verwenden Sie Konsole / IPMI / iKVM, um den Host zu erreichen. Wiederherstellen des Backups:",
|
||||
"lostSshOutro": "Führen Sie dann die Analyse erneut von der Konsole aus aus, um herauszufinden, warum der Vorschlag nicht funktioniert hat (normalerweise: Der Ersatzanschluss ist nicht wirklich angeschlossen)."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Persistente Schnittstellennamen",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": " — bindet Namen an MAC-Adressen, damit dieses Szenario nicht erneut auftritt."
|
||||
},
|
||||
{
|
||||
"label": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— für verwaiste <code>iface</code>-Blöcke (die andere Hälfte des gleichen Problems)."
|
||||
},
|
||||
{
|
||||
"label": "Schnittstellen sichern und neu starten",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "- manuelle Snapshots und der Wiederherstellungsbrowser."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,122 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Konfigurationsanalyse und geführte Bereinigung | ProxMenux-Dokumentation",
|
||||
"description": "Erkennt iface-Blöcke in /etc/network/interfaces, die auf physische NICs verweisen, die nicht mehr auf dem Host vorhanden sind. Meldet sie und bietet eine 5-schrittgesteuerte Entfernung mit obligatorischem Backup und einer Blockvorschau.",
|
||||
"ogTitle": "Konfigurationsanalyse und geführte Bereinigung | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Finden und entfernen Sie verwaiste Schnittstellenblöcke, die durch Hardwareänderungen zurückgelassen wurden, mit vollständiger Vorschau und Rollback."
|
||||
},
|
||||
"header": {
|
||||
"title": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"description": "Untersucht jeden iface-Block in /etc/network/interfaces und prüft, ob die zugehörige physische Netzwerkkarte noch vorhanden ist. Meldet nach Hardwareänderungen verbliebene verwaiste Blöcke und bietet eine geführte Entfernung mit Backup, Vorschau und Bestätigung für jeden Block.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Identifiziert <code>iface</code>-Deklarationen, deren unterstützende NIC nicht mehr auf dem Host vorhanden ist (typisch nach dem Ersetzen oder Entfernen einer Netzwerkkarte). Anschließend wird eine geführte Bereinigung angeboten, bei der <em>nur</em> die verwaisten Blöcke entfernt werden, mit einer Sicherung, einer Vorschau pro Abschnitt und einer expliziten endgültigen Bestätigung."
|
||||
},
|
||||
"differs": {
|
||||
"heading": "Wie es sich von der Brückenanalyse unterscheidet",
|
||||
"headerAspect": "Aspekt",
|
||||
"headerBridge": "Brückenanalyse",
|
||||
"headerConfig": "Konfigurationsanalyse",
|
||||
"rows": [
|
||||
{
|
||||
"aspect": "Untersucht",
|
||||
"bridge": "Brücken (<code>vmbrX</code>) und ihre <code>bridge-ports</code>-Linie",
|
||||
"config": "Jeder <code>iface</code>-Block (ausgenommen Loopback, Bridges, Bonds)"
|
||||
},
|
||||
{
|
||||
"aspect": "Erkennt",
|
||||
"bridge": "Brücken, die auf einen nicht vorhandenen Port verweisen",
|
||||
"config": "Standalone-Schnittstellenblöcke für NICs, die nicht existieren"
|
||||
},
|
||||
{
|
||||
"aspect": "Reparaturmaßnahmen",
|
||||
"bridge": "Ersetzt den Portnamen in <code>bridge-ports</code>",
|
||||
"config": "Entfernen Sie den gesamten <code>iface</code>-Block"
|
||||
},
|
||||
{
|
||||
"aspect": "Ausgenommen sind",
|
||||
"bridge": "Nichts – jede Brücke wird analysiert",
|
||||
"config": "Bridges (<code>vmbrX</code>) und Bonds (<code>bondX</code>) bleiben immer erhalten, da sie virtuell sind und beim Start vorübergehend fehlen können"
|
||||
}
|
||||
],
|
||||
"outro": "In der Praxis führen Sie oft beide Werkzeuge in dieser Reihenfolge aus: zuerst <strong>Konfigurationsanalyse</strong>, um verwaiste Blöcke zu entfernen, dann <link>Brückenanalyse</link>, um Bridges, die auf die entfernte Schnittstelle verwiesen, neu zuzuordnen."
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Schritt 1: Analyse (schreibgeschützt)",
|
||||
"intro": "Bricht sofort ab, wenn der Host nicht den klassischen Netzwerkstack nutzt. Andernfalls werden alle konfigurierten Schnittstellen außer Loopback mit ihrem Status aufgelistet:",
|
||||
"virtTitle": "Virtuelle Schnittstellen sind geschützt",
|
||||
"virtBody": "Bridges (<code>vmbrX</code>) und Bonds (<code>bondX</code>) sind virtuelle Konstrukte. Sie können zum Zeitpunkt der Prüfung durchaus fehlen, etwa eine Bridge ohne Ports. Daher schlägt die Analyse nur die Entfernung physischer Netzwerkkarten vor, niemals die dieser virtuellen Schnittstellen."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Schritt 2: geführte Bereinigung (5 Schritte)",
|
||||
"intro": "Wird nur gestartet, wenn Sie der Aufforderung am Ende der Analyse zustimmen. Jeder Schritt muss bestätigt werden; bei Abbruch wird ohne Schreiben beendet.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sicherheitssicherung",
|
||||
"body": "Kopiert <code>/etc/network/interfaces</code> nach <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Der Pfad wird vorher und nachher angezeigt.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Bestätigen Sie die Entfernungsliste",
|
||||
"body": "Listet genau die zu entfernenden physischen Schnittstellenblöcke auf. Sind die Netzwerkkarten zwischen Analyse und Bereinigung wieder aufgetaucht, etwa nach erneutem Einsetzen einer Karte, endet der Ablauf mit <em>„Keine Bereinigung erforderlich.“</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Vorschau der genauen Block(s)",
|
||||
"body": "Öffnet eine scrollbare Ansicht jedes <code>iface</code>-Blocks, der gelöscht werden würde, exakt wie in der Datei. Hier können Sie etwa einen wichtigen <code>up</code>-Hook erkennen, den Sie behalten möchten.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Entfernung anwenden",
|
||||
"body": "Für jede verwaiste Schnittstelle läuft <code>sed -i \"/^iface $iface/,/^$/d\" /etc/network/interfaces</code>. Das löscht von der passenden <code>iface</code>-Zeile bis zur nächsten leeren Zeile.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Überprüfung",
|
||||
"body": "Liest die Datei erneut, listet auf, was entfernt wurde, und überprüft die verbleibenden Schnittstellen erneut. Gibt den Rollback-Befehl aus. Führt <strong>nicht</strong> einen automatischen Neustart des Netzwerks durch. Das Entfernen eines nicht verwendeten Blocks kann sicher beim nächsten Neustart angewendet werden und vermeidet eine Beeinträchtigung des Live-Status.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"noRestartTitle": "Startet das Netzwerk nicht automatisch neu",
|
||||
"noRestartBody": "Im Gegensatz zur Brückenreparatur bietet der Bereinigungsfluss keinen Neustart des Dienstes. Das Entfernen eines unbenutzten Schnittstellenblocks hat keine unmittelbaren Auswirkungen auf die laufende Konfiguration, so dass ein Neustart unnötig ist und ein unnötiges Verbindungsrisiko darstellt. Die Änderung wird beim nächsten manuellen <code>systemctl restart networking</code> oder beim nächsten Neustart wirksam."
|
||||
},
|
||||
"caveats": {
|
||||
"heading": "Wichtige Vorbehalte",
|
||||
"boundaryTitle": "Die Blockgrenze ist die erste leere Linie",
|
||||
"boundaryBody": "Das <code>sed</code>-Muster löscht von <code>iface <name></code> bis zur nächsten leeren Zeile. Fehlt in <code>/etc/network/interfaces</code> eine Leerzeile zwischen Blöcken, was nach manueller Bearbeitung möglich ist, kann auch der nächste Block gelöscht werden. Deshalb ist <strong>Schritt 3 obligatorisch</strong>: Prüfen Sie die Vorschau vor der Bestätigung.",
|
||||
"tandemTitle": "Ein Waisen-Iface, das von einer Brücke verwendet wird, wird hier erkannt, nicht in der Brückenanalyse",
|
||||
"tandemBody": "Wenn <code>vmbr0</code> <code>bridge-ports enp3s0</code> deklariert und <code>enp3s0</code> einen eigenen Block <code>iface enp3s0 inet manual</code> hat, bleibt nach der Entfernung von <code>enp3s0</code> eine ungültige Referenz in <code>vmbr0</code>. Führen Sie danach die <link>Brückenanalyse</link> aus, um den Bridge-Port neu zuzuordnen oder zu entfernen. Beide Abläufe sind für die gemeinsame Verwendung ausgelegt."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"notFoundTitle": "Die Analyse zeigt mein neues NIC als \"NICHT GEFUNDEN\"",
|
||||
"notFoundBody": "Der Kernel sieht das Gerät unter einem anderen Namen als in der Datei. Führen Sie <code>ip link show</code> aus, um den tatsächlichen Namen zu erhalten. Dies ist genau der Fall, wenn <link>Persistente Schnittstellennamen</link> das Problem verhindern würden.",
|
||||
"tooMuchTitle": "Die Bereinigung hat zu viel entfernt (einen Block, den ich behalten wollte)",
|
||||
"tooMuchBody": "Wiederherstellen aus dem in Schritt 5 gedruckten Backup:",
|
||||
"tooMuchOutro": "Bearbeiten Sie die Datei von Hand, um eine klare leere Linie zwischen den Blöcken hinzuzufügen, bevor Sie die Bereinigung erneut ausführen, oder entfernen Sie den problematischen Block manuell.",
|
||||
"bridgeBreakTitle": "Eine Brücke funktioniert nach dem Aufräumen nicht mehr",
|
||||
"bridgeBreakBody": "Die Bridge war auf einen Port angewiesen, dessen <code>iface</code>-Block gerade entfernt wurde. Führen Sie die <link>Brückenanalyse</link> aus; der Vorschlag ordnet der Bridge eine vorhandene physische Schnittstelle zu."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Brückenanalyse und geführte Reparatur",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": " — der natürliche nächste Schritt nach einer Bereinigung."
|
||||
},
|
||||
{
|
||||
"label": "Persistente Schnittstellennamen",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": " — verhindert, dass sich nach jeder Hardwareänderung verwaiste Blöcke ansammeln."
|
||||
},
|
||||
{
|
||||
"label": "Schnittstellen sichern und neu starten",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "- manuelle Snapshots und der Wiederherstellungsbrowser."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Diagnose | ProxMenux Dokumentation",
|
||||
"description": "Drei einmalige, schreibgeschützte Diagnoseprüfungen: Routingtabelle anzeigen, Konnektivität testen und erweiterte Diagnose. Reine Prüfung — schreibt nie in /etc/network/interfaces und führt nie ändernde Befehle aus, mit einer ausdrücklichen Ausnahme: Wird NetworkManager erkannt, kann er nach Ihrer Zustimmung vollständig entfernt werden.",
|
||||
"ogTitle": "Diagnose | ProxMenux Dokumentation",
|
||||
"ogDescription": "Schreibgeschützte Netzwerkdiagnose für den Proxmox-Host: Routing, Erreichbarkeit und erweiterte Statistiken."
|
||||
},
|
||||
"header": {
|
||||
"title": "Diagnose",
|
||||
"description": "Drei einmalige, schreibgeschützte Prüfungen des aktuellen Netzwerkzustands: Routingtabelle, Konnektivitätstest und erweiterte Statistiken. Keine schreibt in /etc/network/interfaces — jederzeit sicher nutzbar, auch über SSH. Für interaktive Echtzeitüberwachung siehe Überwachungswerkzeuge für Echtzeitdaten.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Berichtet über Routing, Erreichbarkeit und zusammengefasste Statistiken, <strong>ohne etwas zu ändern</strong>. Damit können Sie den ordnungsgemäßen Netzwerkbetrieb bestätigen oder doppelte IP-Adressen erkennen. Für die kontinuierliche Verkehrsbeobachtung siehe <monitoringLink>Überwachungswerkzeuge für Echtzeitdaten</monitoringLink>; zur Anzeige der unverarbeiteten Konfigurationsdatei siehe <backupLink>Schnittstellen sichern und neu starten</backupLink>."
|
||||
},
|
||||
"routing": {
|
||||
"heading": "Routing-Tabelle anzeigen",
|
||||
"body": "Listet alle aktuell vom Kernel verwendeten Routen auf (<code>ip route show</code>) und hebt das Standard-Gateway hervor. Damit lässt sich prüfen, ob Internetverkehr die erwartete Schnittstelle verwendet und keine veralteten Routen Vorrang haben."
|
||||
},
|
||||
"connectivity": {
|
||||
"heading": "Konnektivität testen",
|
||||
"intro": "Sendet zwei ICMP-Sonden nacheinander an drei Ziele und meldet jede einzelne. Führt dann eine <code>nslookup google.com</code> aus, um die DNS-Auflösung unabhängig von ICMP zu überprüfen.",
|
||||
"headerTest": "Test",
|
||||
"headerTarget": "Ziel",
|
||||
"headerConfirms": "Was es bestätigt",
|
||||
"rows": [
|
||||
{
|
||||
"test": "Google DNS",
|
||||
"target": "8.8.8.8",
|
||||
"confirms": "Externe Erreichbarkeit über bekannte Anycast IP"
|
||||
},
|
||||
{
|
||||
"test": "Cloudflare DNS",
|
||||
"target": "1.1.1.1",
|
||||
"confirms": "Unabhängige zweite Meinung, wenn Google ICMP blockiert"
|
||||
},
|
||||
{
|
||||
"test": "Gateway",
|
||||
"target": "(Standardroute)",
|
||||
"confirms": "L2/L3-Verbindung zum lokalen Router"
|
||||
},
|
||||
{
|
||||
"test": "DNS-Auflösung",
|
||||
"target": "google.com",
|
||||
"confirms": "Der DNS-Server ist erreichbar und antwortet"
|
||||
}
|
||||
],
|
||||
"readingTitle": "Lesen des Ergebnisses",
|
||||
"readingBody": "Wenn der Gateway-Test besteht, aber die öffentlichen DNS-Ziele fehlschlagen, haben Sie lokale Konnektivität, aber kein Internet - überprüfen Sie den Upstream des Gateways. Wenn die DNS-Auflösung fehlschlägt, Pings zu <code>8.8.8.8</code> jedoch erfolgreich sind, ist das Problem der Resolver, nicht das Netzwerk: Überprüfen Sie <code>/etc/resolv.conf</code>."
|
||||
},
|
||||
"advanced": {
|
||||
"heading": "Erweiterte Diagnose",
|
||||
"intro": "Fasst netzwerkweite Statistiken zusammen und prüft auf häufige Probleme. Meldet die Anzahl aktiver Verbindungen, lauschende Ports und die Gesamtzahl der Schnittstellen und weist ausdrücklich auf zwei problematische Konstellationen hin:",
|
||||
"items": [
|
||||
"<strong>NetworkManager läuft auf einem Proxmox-Host.</strong> NetworkManager und Proxmox’ <code>ifupdown</code> stehen im Konflikt: Beide versuchen, Schnittstellen zu verwalten, sodass Bridges ständig ihren Zustand wechseln oder nicht aktiviert werden. Wird NetworkManager erkannt, bietet das Werkzeug an, ihn interaktiv zu stoppen, zu deaktivieren und vollständig zu entfernen (dies ist die <em>einzige</em> Diagnose, die das System ändern kann, und nur nach ausdrücklicher Zustimmung).",
|
||||
"<strong>Doppelte IP-Adressen auf verschiedenen Schnittstellen.</strong> Zwei Schnittstellen mit derselben IPv4-Adresse verursachen sporadische Verbindungsprobleme, die innerhalb der VM äußerst schwer zu untersuchen sind. Erkannt über <code>ip -4 addr show | sort | uniq -d</code>."
|
||||
],
|
||||
"nmTitle": "Die NetworkManager-Eingabeaufforderung ist hier die einzige Änderungsaktion",
|
||||
"nmBody": "Alle anderen Prüfungen in der erweiterten Diagnose sind schreibgeschützt. Die Entfernung von NetworkManager erfordert eine Ja/Nein-Bestätigung und führt <code>systemctl stop / disable</code> + <code>apt-get purge -y network-manager</code> aus. Wenn Sie ablehnen, ändert sich nichts."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"gwTitle": "Konnektivität testen meldet einen Gatewayfehler, aber der Host hat Internetzugriff",
|
||||
"gwBody": "Einige Router reagieren nicht auf ICMP von ihrer internen Schnittstelle aus, selbst wenn sie den Datenverkehr gerne weiterleiten. Testen Sie mit <code>traceroute 8.8.8.8</code> von einer Konsole aus: Wenn der zweite Hop Ihr ISP ist und der öffentliche DNS-Test bestanden ist, ist das Gateway trotz des fehlgeschlagenen Pings in Ordnung.",
|
||||
"dupTitle": "Die erweiterte Diagnose meldet weiterhin doppelte IP-Adressen, obwohl ich eine entfernt habe",
|
||||
"dupBody": "Der Check betrachtet den Live-Kernel-Status, nicht die Config-Datei. Führen Sie <code>ip -4 addr show</code> aus, um zu bestätigen; wenn das Duplikat noch vorhanden ist, hält es immer noch eine Schnittstelle. Verwenden Sie <code>ip addr del <IP>/<mask> dev <iface></code>, um es aus dem Live-Zustand zu entfernen, und bearbeiten Sie dann <code>/etc/network/interfaces</code>, wenn es auch persistent ist."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Überwachungswerkzeuge für Echtzeitdaten",
|
||||
"href": "/docs/network/monitoring",
|
||||
"tail": "— interaktive iftop / iptraf-ng / iperf3 Launcher."
|
||||
},
|
||||
{
|
||||
"label": "Brückenanalyse und geführte Reparatur",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": " — wenn einem vmbrX der physische Port fehlt."
|
||||
},
|
||||
{
|
||||
"label": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — wenn eine alte Netzwerkkarte noch deklariert, aber nicht mehr vorhanden ist."
|
||||
},
|
||||
{
|
||||
"label": "Schnittstellen sichern und neu starten",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": " — um vor jeder Änderung einen Schnappschuss der Konfiguration zu erstellen."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,107 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox-Netzwerkverwaltung — Bridges, Bonds, Diagnose, Reparatur | ProxMenux",
|
||||
"description": "Schreibgeschützte Diagnose, Analysen mit anschließenden Vorschlägen und geführte Reparaturen für den Debian-/Proxmox-Netzwerkstack (/etc/network/interfaces). Prüfen Sie Bridges und Bonds, starten Sie Live-Überwachungswerkzeuge, vergeben Sie dauerhafte Schnittstellennamen, erstellen Sie Backups und starten Sie das Netzwerk sicher neu — mit obligatorischen Backups und schrittweiser Vorschau.",
|
||||
"ogTitle": "Proxmox-Netzwerkverwaltung — Bridges, Bonds, Diagnose, Reparatur",
|
||||
"ogDescription": "Diagnose, Analyse und geführte Reparaturen für den Proxmox-Netzwerkstack mit obligatorischen Backups und Schritt-für-Schritt-Vorschau.",
|
||||
"twitterTitle": "Proxmox-Netzwerkverwaltung | ProxMenux",
|
||||
"twitterDescription": "Brücken, Bonds, Diagnosen und geführte Reparaturen für den Proxmox-Netzwerkstack mit obligatorischen Backups."
|
||||
},
|
||||
"header": {
|
||||
"title": "Netzwerkmanagement",
|
||||
"description": "Schreibgeschützte Diagnose, Analyseberichte mit anschließenden Vorschlägen und geführte Reparaturen für den klassischen Debian-/Proxmox-Netzwerkstack. Jeder destruktive Vorgang erstellt zuerst ein Backup und zeigt die genauen Änderungen vor der Anwendung an.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wozu dieses Menü dient",
|
||||
"body": "Prüfen, diagnostizieren und reparieren Sie bei Bedarf die Netzwerkkonfiguration des Proxmox-Hosts, ohne den Fernzugriff zu verlieren. Die Werkzeuge folgen einem Prinzip: <strong>zuerst lesen, dann Vorschläge machen und Änderungen nur mit ausdrücklicher Zustimmung und einer Sicherheitskopie anwenden</strong>. Es gibt keine Schaltfläche „Alles automatisch reparieren“."
|
||||
},
|
||||
"openingMenu": {
|
||||
"heading": "Öffnen des Menüs",
|
||||
"intro": "Wählen Sie im Hauptmenü von ProxMenux <strong>Netzwerk</strong>. Folgendes wird angezeigt:",
|
||||
"imageAlt": "Menü Netzwerkmanagement mit Diagnose, Überwachung, Analyse, Reparatur, persistenten Namen und Backup-Optionen"
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Das Sicherheitsmodell",
|
||||
"body": "Das Bearbeiten der Netzwerkkonfiguration auf einem entfernten Proxmox-Host ist eine der einfachsten Möglichkeiten, sich auszusperren. ProxMenux behandelt jede Aktion entsprechend. Die Werkzeuge fallen in drei Verhaltensstufen - wählen Sie die Karte, die Ihrer Absicht entspricht:"
|
||||
},
|
||||
"tiers": {
|
||||
"readOnly": {
|
||||
"title": "Schreibgeschützt",
|
||||
"body": "Reine Inspektion. Kann das System unter keinen Umständen ändern.",
|
||||
"items": [
|
||||
"Routingtabelle, Konnektivitätstests, fortgeschrittene Statistiken",
|
||||
"Verkehrsüberwachung in Echtzeit (iftop, iptraf-ng)",
|
||||
"Bandbreitentest (iperf3)"
|
||||
]
|
||||
},
|
||||
"analyze": {
|
||||
"title": "Analysieren, dann vorschlagen",
|
||||
"body": "Erkennt Probleme, druckt einen Bericht mit vorgeschlagenen Shell-Befehlen und stoppt. Sie entscheiden, ob Sie anschließend in die geführte Reparatur eintreten möchten.",
|
||||
"items": [
|
||||
"Brückenkonfigurationsanalyse",
|
||||
"Netzwerkkonfigurationsanalyse"
|
||||
]
|
||||
},
|
||||
"apply": {
|
||||
"title": "Mit Backup anwenden",
|
||||
"body": "Ändert das System. Erstellt immer zuerst ein Backup der betroffenen Datei mit Zeitstempel und zeigt vor dem Schreiben eine Vorschau an.",
|
||||
"items": [
|
||||
"Persistente Schnittstellennamen (.link-Dateien)",
|
||||
"Manuelles Backup, Wiederherstellung und Neustart des Dienstes"
|
||||
]
|
||||
}
|
||||
},
|
||||
"classicTitle": "Nur klassischer Stack",
|
||||
"classicBody": "Jede Analyse- und Reparaturfunktion prüft den aktiven Netzwerkmanager, bevor sie etwas ändert. Wenn der Host <strong>netplan</strong>, <strong>systemd-networkd</strong> oder <strong>NetworkManager</strong> verwendet, bricht das Werkzeug sofort mit einer klaren Meldung ab — das Menü unterstützt nur den klassischen Debian-/Proxmox-Stack unter <code>/etc/network/interfaces</code>. Das ist beabsichtigt: Eine netplan-Datei nach Regeln für <code>ifupdown</code> zu bearbeiten, würde die Konfiguration unbemerkt beschädigen.",
|
||||
"backups": {
|
||||
"heading": "Wo Backups gespeichert werden",
|
||||
"intro": "Jede geführte Reparatur, Wiederherstellung oder manuelle Sicherung schreibt eine zeitgestempelte Kopie von <code>/etc/network/interfaces</code> auf <code>/var/backups/proxmenux/</code>:",
|
||||
"rollbackIntro": "So rollen Sie manuell von einer Konsole zurück:"
|
||||
},
|
||||
"readOnlySection": {
|
||||
"heading": "Schreibgeschützte Prüfung",
|
||||
"body": "Der Ausgangspunkt, wenn etwas nicht stimmt. Reine Prüfung — schreibt nie in <code>/etc/network/interfaces</code> und führt nie einen ändernden Befehl aus (mit einer ausdrücklichen Ausnahme: Wird NetworkManager erkannt, kann er nach Ihrer Zustimmung vollständig entfernt werden). Jederzeit sicher über SSH nutzbar.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Diagnose",
|
||||
"description": "Drei einmalige, schreibgeschützte Prüfungen: Routingtabelle anzeigen, Konnektivität testen und erweiterte Diagnose. Reine Prüfung — schreibt nie in das System."
|
||||
},
|
||||
{
|
||||
"title": "Überwachungswerkzeuge für Echtzeitdaten",
|
||||
"description": "Drei interaktive Launcher: iftop (Echtzeitbandbreite pro Hostpaar), iptraf-ng (Multi-Mode-Traffic-Monitor) und iperf3 (Bandbreitentest, Server / Client-Modus)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"analyzeSection": {
|
||||
"heading": "Analysieren, dann vorschlagen",
|
||||
"body": "Wenn eine Prüfung oder ein tatsächlicher Ausfall auf ein Konfigurationsproblem hinweist, kommen diese Werkzeuge zum Einsatz. Jedes untersucht den relevanten Teil von <code>/etc/network/interfaces</code>, gibt einen detaillierten Bericht mit dem genauen Shell-Befehl zur Behebung jedes Befunds aus und <strong>stoppt</strong>. Wenn Sie anschließend die optionale geführte Reparatur annehmen, wird vor jeder Änderung eine Sicherung erstellt und die Änderung vor dem Schreiben angezeigt.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Brückenanalyse und geführte Reparatur",
|
||||
"description": "Erkennt vmbrX-Bridges mit fehlenden oder ungültigen Ports, etwa nach einer neuen PCI-Gerätenummerierung. Zeigt zuerst einen Bericht an und repariert nur, wenn Sie dem geführten Ablauf mit 5 Schritten zustimmen."
|
||||
},
|
||||
{
|
||||
"title": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"description": "Findet in /etc/network/interfaces deklarierte physische Schnittstellen, die nicht mehr existieren (Waisenkonfigurationen, die durch Hardwareänderungen zurückgelassen wurden). Meldet sie und bietet eine geführte Entfernung an."
|
||||
}
|
||||
]
|
||||
},
|
||||
"applySection": {
|
||||
"heading": "Mit Backup anwenden",
|
||||
"body": "Diese Werkzeuge schreiben bestimmungsgemäß auf den Datenträger. Jedes erstellt vorher ein Backup der betroffenen Datei mit Zeitstempel. Destruktive Optionen wie Wiederherstellen und Neustarten erfordern eine ausdrückliche Ja/Nein-Bestätigung. <em>Persistente Schnittstellennamen</em> werden erst beim nächsten Neustart wirksam, sodass die Einrichtung auch auf einem entfernten Host sicher geplant werden kann.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Persistente Schnittstellennamen",
|
||||
"description": "Bindet Schnittstellennamen (eno1, enp3s0, …) über systemd-.link-Dateien an MAC-Adressen. Die Namen bleiben bei PCI-Steckplatzwechseln, Kernel-Upgrades und beim Hinzufügen oder Entfernen anderer Netzwerkkarten erhalten."
|
||||
},
|
||||
{
|
||||
"title": "Schnittstellen sichern und neu starten",
|
||||
"description": "Manueller Snapshot von /etc/network/interfaces, Durchsuchen und Wiederherstellen früherer Backups, Anzeigen der Live-Konfiguration und Neustart des Netzwerkdienstes bei Bedarf."
|
||||
}
|
||||
]
|
||||
},
|
||||
"consoleTitle": "Konsolenzugriff bereithalten",
|
||||
"consoleSubTitle": "Vor jeder Reparatur auf einem entfernten Host",
|
||||
"consoleBody": "Wenn Sie über SSH verbunden sind und nur einen Zugangsweg zum Host haben, halten Sie vor Netzwerkänderungen einen Ersatzweg bereit: eine physische Konsole, IPMI oder iKVM oder einen anderen Rechner im selben LAN. Die geführten Reparaturen sind sicher und bieten immer einen Befehl zum Zurücksetzen. Eine falsch konfigurierte Bridge oder eine unterbrochene Verbindung kann Sie dennoch aussperren, bis Sie die Konsole erreichen."
|
||||
}
|
||||
@@ -0,0 +1,136 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Überwachungswerkzeuge für Echtzeitdaten | ProxMenux-Dokumentation",
|
||||
"description": "Drei interaktive Netzwerküberwachungsstarter: iftop (Echtzeitbandbreite pro Hostpaar), iptraf-ng (Multi-Mode-Traffic-Monitor) und iperf3 (Bandbreitentest, Server / Client-Modus). Jeder wird bei der ersten Verwendung installiert.",
|
||||
"ogTitle": "Überwachungswerkzeuge für Echtzeitdaten | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Interaktive Netzwerküberwachung und Bandbreitentests für den Proxmox-Host: iftop, iptraf-ng, iperf3."
|
||||
},
|
||||
"header": {
|
||||
"title": "Überwachungswerkzeuge für Echtzeitdaten",
|
||||
"description": "Drei interaktive Starter zur Echtzeit-Netzwerkbeobachtung und Bandbreitenmessung: iftop, iptraf-ng und iperf3. Jedes Werkzeug wird beim ersten Gebrauch automatisch über apt installiert, läuft im Vordergrund und wird mit der angegebenen Taste beendet. Sie ändern die Netzwerkkonfiguration des Hosts nicht; iperf3 erzeugt Testverkehr.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Drei interaktive Monitoring-Tools, jedes hinter seinem eigenen Menüeintrag. Beim ersten Start eines Pakets wird das Paket lautlos über <code>apt-get</code> installiert. Nachfolgende Starts beginnen sofort. Keines dieser Tools ändert die Host-Netzwerkkonfiguration."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Welches Werkzeug Sie wann verwenden",
|
||||
"headerQuestion": "Fragestellung",
|
||||
"headerUse": "Verwenden",
|
||||
"rows": [
|
||||
{
|
||||
"question": "Wer lastet die Verbindung <em>gerade jetzt</em> aus?",
|
||||
"use": "iftop"
|
||||
},
|
||||
{
|
||||
"question": "Welche Protokollaufschlüsselung / Paketgrößen / TCP-Flows fließen?",
|
||||
"use": "iptraf-ng"
|
||||
},
|
||||
{
|
||||
"question": "Wie viel Bandbreite ist tatsächlich zwischen zwei Hosts verfügbar?",
|
||||
"use": "iperf3"
|
||||
}
|
||||
]
|
||||
},
|
||||
"iftop": {
|
||||
"heading": "Netzwerknutzung in Echtzeit (iftop)",
|
||||
"body": "Bandbreite pro Hostpaar (Quelle ↔ Ziel) in Echtzeit — wie <code>top</code> für Netzwerkverkehr. Zeigt die größten Datenströme oben an, mit gleitenden Durchschnitten über 2/10/40 Sekunden. Das beste Werkzeug für die Frage <em>„Warum ist mein Uplink ausgelastet?“</em>.",
|
||||
"exit": "<strong>Beenden:</strong> Drücken Sie <kbd>q</kbd>. ProxMenux zeigt vor dem Start einen Erinnerungsdialog.",
|
||||
"keysTitle": "Nützliche Tasten in iftop",
|
||||
"keysBody": "<kbd>n</kbd> DNS-Auflösung umschalten, <kbd>p</kbd> Portnummern anzeigen, <kbd>P</kbd> Anzeige pausieren, <kbd>t</kbd> Zeilenrichtung umschalten (gesendet / empfangen / beides), <kbd>1</kbd>/<kbd>2</kbd>/<kbd>3</kbd> nach dem Durchschnitt über 2 s / 10 s / 40 s sortieren. Vollständige Liste unter <code>man iftop</code>."
|
||||
},
|
||||
"iptraf": {
|
||||
"heading": "Netzwerküberwachungstool (iptraf-ng)",
|
||||
"intro": "Ein menügesteuerter Verkehrsmonitor mit mehreren Modi. iftop beantwortet <em>„wer“</em>, iptraf-ng beantwortet <em>„was“</em>: Byte-/Paketzähler pro Protokoll, Verfolgung des TCP-Verbindungszustands, Paketgrößenhistogramme und LAN-Aktivität pro Station.",
|
||||
"menuIntro": "Beim Start erhalten Sie ein Menü mit fünf Optionen:",
|
||||
"headerMode": "Modus",
|
||||
"headerUseFor": "Verwenden Sie es für",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "IP traffic monitor",
|
||||
"useFor": "Live TCP / UDP/ICMP / Other-IP-Flow-Liste mit Byte-Zählern und Verbindungszustand"
|
||||
},
|
||||
{
|
||||
"mode": "General interface stats",
|
||||
"useFor": "Aggregierte IPv4/IPv6/TCP/UDP/ICMP/Nicht-IP-Paketzahl pro NIC"
|
||||
},
|
||||
{
|
||||
"mode": "Detailed interface stats",
|
||||
"useFor": "Gleiche wie oben, aber für eine Schnittstelle, mit Paketgröße und -rate Details"
|
||||
},
|
||||
{
|
||||
"mode": "Statistical breakdowns",
|
||||
"useFor": "Histogramm der Paketgrößenverteilung nach TCP / UDP Port"
|
||||
},
|
||||
{
|
||||
"mode": "LAN station monitor",
|
||||
"useFor": "Per-MAC-Verkehrsstatistiken für die lokale Broadcast-Domain"
|
||||
}
|
||||
],
|
||||
"exit": "<strong>Beenden:</strong> Drücken Sie in einer beliebigen Ansicht <kbd>x</kbd> oder im Hauptmenü <kbd>Q</kbd>. ProxMenux zeigt vor dem Start einen Erinnerungsdialog.",
|
||||
"logTitle": "Erfasste Daten in einer Datei protokollieren",
|
||||
"logBody": "Jeder Modus bietet an, erfasste Statistiken unter <code>/var/log/iptraf-ng/</code> zu protokollieren. Nützlich zur Aufzeichnung einer Verkehrsspitze: Lassen Sie das Werkzeug laufen, protokollieren Sie in eine Datei und prüfen Sie diese später, statt die Live-Anzeige mitlesen zu müssen."
|
||||
},
|
||||
"iperf3": {
|
||||
"heading": "Bandbreitentest (iperf3)",
|
||||
"intro1": "Misst den tatsächlichen TCP-Durchsatz zwischen zwei Hosts. Anders als iftop / iptraf-ng, die vorhandenen Verkehr beobachten, erzeugt iperf3 künstlichen Verkehr für einen Belastungstest der Verbindung. Unverzichtbar für Fragen wie <em>„Erreicht mein 10-GbE-Link wirklich 10 GbE?“</em> oder <em>„Liegt der Engpass an der Netzwerkkarte, am Switch oder am Speicher?“</em>.",
|
||||
"intro2": "iperf3 ist ein <strong>Werkzeug für zwei Hosts</strong>: Eine Seite läuft als Server und lauscht auf TCP-Port 5201, die andere als Client, der sich verbindet, Daten sendet und die Rate ausgibt. Der ProxMenux-Starter fragt nach dem gewünschten Modus:",
|
||||
"headerMode": "Modus",
|
||||
"headerBehaviour": "Verhalten",
|
||||
"headerCli": "Entsprechender CLI-Befehl",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Server",
|
||||
"behaviour": "Lauscht auf TCP-Port 5201 und gibt für jeden eingehenden Test Ergebnisse aus. Beenden mit Ctrl+C.",
|
||||
"cli": "iperf3 -s"
|
||||
},
|
||||
{
|
||||
"mode": "Client",
|
||||
"behaviour": "Fragt nach der Server-IP / Hostname, verbindet, führt einen Standard-10-Sekunden-Test aus und druckt den Bericht aus.",
|
||||
"cli": "iperf3 -c <target>"
|
||||
}
|
||||
],
|
||||
"workflowIntro": "Typischer Workflow zum Testen einer 10 GbE-Verbindung zwischen zwei Proxmox-Hosts:",
|
||||
"workflow": [
|
||||
"Öffnen Sie auf Host A das Netzwerkmenü → <em>Bandbreitentest (iperf3)</em> → wählen Sie <strong>Server</strong>.",
|
||||
"Öffnen Sie auf Host B den gleichen Menüeintrag → Wählen Sie <strong>Client</strong> → Geben Sie die IP von Host A ein.",
|
||||
"Warten Sie 10 Sekunden. Vergleichen Sie die gemeldete Rate mit dem theoretischen Maximum des Links."
|
||||
],
|
||||
"sample": "Beispiel für die Client-Ausgabe:",
|
||||
"flagsTitle": "Nützliche manuelle Flags (aus einer Shell ausgeführt)",
|
||||
"flagsBody": "<code>-t 60</code> längerer Test (60 s statt 10 s), <code>-P 4</code> 4 parallele Datenströme (lastet schneller aus), <code>-R</code> umgekehrte Richtung (Server → Client), <code>-u -b 100M</code> UDP-Test mit 100 Mbit/s (für Jitter- und Paketverlustmessungen), <code>-p 5202</code> anderer Port (mehrere parallele Tests). Vollständige Liste unter <code>man iperf3</code>.",
|
||||
"firewallTitle": "Öffnen Sie den Firewall-Port auf dem Server",
|
||||
"firewallBody": "Der Server hört standardmäßig auf TCP <strong>5201</strong>. Wenn Sie den Server in einem Proxmox-Host mit einer strengen Firewall (Datacenter oder Host-Level) betreiben, erlauben Sie für die Dauer des Tests eingehende TCP 5201 von der IP des Clients und schließen Sie ihn erneut. Gleiches gilt für <code>nftables</code> / <code>iptables</code> auf bloßen Hosts."
|
||||
},
|
||||
"install": {
|
||||
"heading": "Erster Start installiert das Paket",
|
||||
"body": "Alle drei Starter prüfen, ob das Programm vorhanden ist, und führen bei Bedarf <code>apt-get update -qq && apt-get install -y <pkg></code> aus. Die Installation erfolgt ohne Ausgabe: Das Menü kann beim ersten Mal 10–30 Sekunden lang eingefroren wirken. Spätere Starts erfolgen sofort."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"hangTitle": "Die Installation hängt beim ersten Start endlos",
|
||||
"hangBody": "Der Host hat kein Internet oder die Apt-Repos sind nicht erreichbar. Brechen Sie mit <kbd>Ctrl</kbd>+<kbd>C</kbd> ab, führen Sie <code>apt-get update</code> manuell aus, um den tatsächlichen Fehler anzuzeigen (DNS, Repo-Signatur, Proxy …), und kehren Sie dann zum Menü zurück.",
|
||||
"refusedTitle": "iperf3-Client: „unable to connect to server: Connection refused“",
|
||||
"refusedBody": "Entweder läuft der Server nicht oder seine Firewall blockiert TCP 5201. Prüfen Sie auf dem Server mit <code>ss -tlnp | grep 5201</code>, ob iperf3 lauscht. Lauscht es, aber der Client kann sich weiterhin nicht verbinden, prüfen Sie die Firewalls auf dem Weg zwischen beiden Hosts.",
|
||||
"slowTitle": "iperf3 meldet deutlich weniger als die erwartete Verbindungsgeschwindigkeit",
|
||||
"slowBody": "Häufige Ursachen nach Wahrscheinlichkeit: (1) Die CPU eines Hosts begrenzt den Durchsatz — versuchen Sie <code>iperf3 -c <target> -P 4</code> zur Nutzung mehrerer Kerne; (2) der Weg enthält eine langsamere Verbindung, etwa einen Gigabit-Switch zwischen zwei 10-GbE-Karten; (3) unterschiedliche MTU — prüfen Sie <code>ip link show</code> an beiden Enden; (4) deaktiviertes NIC-Offloading — siehe Community-Skript <em>Disable NIC Offloading</em> bei einer Intel-e1000e-Karte.",
|
||||
"noTrafficTitle": "iftop / iptraf-ng zeigt keinen Traffic für einen beschäftigten Host an",
|
||||
"noTrafficBody": "Die Standarderfassung erfolgt auf der ersten erkannten Schnittstelle. Geben Sie die richtige explizit aus der Shell an: <code>iftop -i vmbr0</code> oder <code>iptraf-ng -i vmbr0</code>. Der Menüstarter verwendet den Standard; für nicht standardmäßige Schnittstellen, laufen Sie von einer Konsole aus."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Diagnose",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": " — die einmaligen, schreibgeschützten Prüfungen (Routing, Konnektivität, erweiterte Statistiken)."
|
||||
},
|
||||
{
|
||||
"label": "Brückenanalyse und geführte Reparatur",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "Wenn die Überwachung zeigt, dass eine Schnittstelle oder Brücke nicht das tut, was sie sollte."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,130 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Persistente Schnittstellennamen | ProxMenux-Dokumentation",
|
||||
"description": "Binden Sie Proxmox-Schnittstellennamen (eno1, enp3s0, …) über systemd-.link-Dateien an MAC-Adressen, damit sie bei neuer PCI-Nummerierung, Kernel-Upgrades und beim Hinzufügen oder Entfernen anderer Netzwerkkarten erhalten bleiben.",
|
||||
"ogTitle": "Persistente Schnittstellennamen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Verhindern Sie, dass sich Proxmox-Schnittstellennamen bei Hardwareänderungen ändern. Verwendet systemd-.link-Dateien mit Zuordnung über die MAC-Adresse."
|
||||
},
|
||||
"header": {
|
||||
"title": "Persistente Schnittstellennamen",
|
||||
"description": "Erstellt pro physischer Netzwerkkarte eine systemd-.link-Datei, die den vom Kernel vergebenen Namen an die MAC-Adresse der Karte bindet. Nach der Anwendung beim nächsten Neustart bleiben die Schnittstellennamen beim Hinzufügen, Entfernen oder Umstecken von PCIe-Karten stabil.",
|
||||
"section": "Netzwerk"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Schreibt für jede physische Netzwerkkarte des Hosts eine kleine Datei unter <code>/etc/systemd/network/10-<iface>.link</code> mit der Regel: <em>„Das Gerät mit dieser MAC-Adresse muss immer diesen Namen tragen.“</em> systemd-udevd wendet die Regel bei jedem Start an, bevor <code>ifupdown</code> die Datei <code>/etc/network/interfaces</code> liest."
|
||||
},
|
||||
"problem": {
|
||||
"heading": "Das Problem, das dies löst",
|
||||
"intro": "Linux leitet Standard-Schnittstellennamen aus der PCI-Topologie ab — <code>eno1</code> = onboard, <code>enp3s0</code> = die Karte in PCI-Bus 3, Steckplatz 0 usw. Das Namensschema ist deterministisch, <em>solange die Hardwareanordnung gleich bleibt</em>. Ändert sich die Anordnung, verschieben sich die Namen:",
|
||||
"items": [
|
||||
"Fügen Sie einen GPU vor einem vorhandenen NIC hinzu → die NIC-Busnummer kann sich ändern → Namensänderungen.",
|
||||
"Bewegen Sie eine Karte in einen anderen PCIe-Slot → Namensänderungen.",
|
||||
"BIOS / UEFI-Update, das Geräte erneut auflistet → Namen können sich ändern.",
|
||||
"Ersetzen Sie eine fehlerhafte Karte durch das gleiche Modell in einem anderen Slot → Namensänderungen."
|
||||
],
|
||||
"outro": "Nach einer solchen Änderung verweist <code>/etc/network/interfaces</code> weiterhin auf den <em>alten</em> Namen. Die Bridge lässt sich nicht aktivieren und der Host verliert die Netzwerkverbindung. Persistente Namen verhindern, dass dieses Szenario erneut auftritt."
|
||||
},
|
||||
"howWorks": {
|
||||
"heading": "Wie es funktioniert",
|
||||
"arrowLabel": "je NIC",
|
||||
"nodes": {
|
||||
"detectLabel": "Physische NIC erkennen",
|
||||
"detectDetail": "ls /sys/class/net/\nvmbr / bond / docker / veth /\nwireguard … ausschließen",
|
||||
"readLabel": "Jede MAC-Adresse lesen",
|
||||
"readDetail": "cat /sys/class/net/\n '<'iface'>'/address",
|
||||
"writeLabel": ".link-Datei schreiben",
|
||||
"writeDetail": "/etc/systemd/network/\n 10-'<'iface'>'.link"
|
||||
},
|
||||
"minimalIntro": "Jede generierte Datei ist absichtlich minimal:",
|
||||
"minimalOutro": "Beim Start erkennt systemd-udevd das Gerät anhand der MAC-Adresse und weist den gewünschten Namen zu, <em>bevor</em> andere Komponenten wie ifupdown oder die Standardbenennung des Kernels darauf zugreifen. Das Dateipräfix <code>10-</code> sorgt dafür, dass diese Regeln früh und vor der Standarddatei <code>99-default.link</code> geladen werden."
|
||||
},
|
||||
"scope": {
|
||||
"heading": "Was geschrieben wird, was übersprungen wird",
|
||||
"headerType": "Typ",
|
||||
"headerBehaviour": "Verhalten",
|
||||
"headerWhy": "Warum",
|
||||
"rows": [
|
||||
{
|
||||
"type": "Onboard-/PCIe-Netzwerkkarte",
|
||||
"behaviour": "<code>.link</code> Datei geschrieben",
|
||||
"why": "Unterstützt durch ein echtes PCI-Gerät - der Fall, für den das Tool geeignet ist"
|
||||
},
|
||||
{
|
||||
"type": "Wi-Fi (phy80211)",
|
||||
"behaviour": "<code>.link</code> Datei geschrieben",
|
||||
"why": "Hat einen echten MAC und profitiert von Namensstabilität"
|
||||
},
|
||||
{
|
||||
"type": "Brücken (vmbrX)",
|
||||
"behaviour": "Übersprungen",
|
||||
"why": "Virtuell; Name kommt von <code>/etc/network/interfaces</code>"
|
||||
},
|
||||
{
|
||||
"type": "Bonds (bondX)",
|
||||
"behaviour": "Übersprungen",
|
||||
"why": "Virtuell; Bondname wird von ifupdown festgelegt"
|
||||
},
|
||||
{
|
||||
"type": "veth / docker0 / br-XXXX",
|
||||
"behaviour": "Übersprungen",
|
||||
"why": "Erstellt auf Anfrage von Docker / LXC - keine persistente Hardware"
|
||||
},
|
||||
{
|
||||
"type": "tap / fwpr / fwln",
|
||||
"behaviour": "Übersprungen",
|
||||
"why": "Erstellt auf Anfrage von Proxmox per VM/CT"
|
||||
},
|
||||
{
|
||||
"type": "WireGuard / Cilium / Tailscale",
|
||||
"behaviour": "Übersprungen",
|
||||
"why": "Software-Schnittstellen, die von eigenen Daemons verwaltet werden"
|
||||
}
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Sicherheitsnetz: Frühere .link-Dateien werden gesichert",
|
||||
"intro": "Wenn <code>/etc/systemd/network/</code> bereits <code>.link</code>-Dateien enthält (aus einem früheren Lauf oder anderen Tools), werden diese in ein Backup-Verzeichnis mit Zeitstempel kopiert, bevor die neuen generiert werden:",
|
||||
"outro": "Zum Zurückrollen: Kopieren Sie die Dateien aus dem Backup-Verzeichnis zurück und starten Sie neu.",
|
||||
"rebootTitle": "Effekt beim nächsten Neustart, nicht sofort",
|
||||
"rebootBody": "Änderungen an <code>.link</code>-Dateien gelten nur beim Booten, wenn udev Geräte erneut auflistet. Das Tool meldet <em>\"Änderungen gelten nach dem Neustart\"</em> aus diesem Grund. Das Umbenennen einer Schnittstelle ist riskant und wird nicht versucht: Ein aktiver <code>vmbr0</code> mit Mitgliedern müsste atomar neu konfiguriert werden, weshalb die Operation auf den nächsten sauberen Boot verschoben wird."
|
||||
},
|
||||
"afterReboot": {
|
||||
"heading": "Nach dem Reboot",
|
||||
"intro": "Sobald die Namen angeheftet sind, ist der Workflow für zukünftige Hardwareänderungen einfach:",
|
||||
"items": [
|
||||
"Ausschalten, Hardware ändern (Karte hinzufügen, in einen anderen Steckplatz umstecken, …), starten.",
|
||||
"Jedes NIC behält seinen vorherigen Namen, weil sein MAC mit einer <code>.link</code>-Datei übereinstimmt.",
|
||||
"Wenn ein NIC ersetzt wird (anderer MAC), erhält er einen Standard-Kernelnamen (<code>enp<bus>s<slot></code>); Führen Sie dieses Menü erneut aus, um einen <code>.link</code>-Eintrag für den MAC der neuen Karte hinzuzufügen."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"emptyTitle": "\"Keine physischen Schnittstellen gefunden\" nach dem Ausführen des Tools",
|
||||
"emptyBody": "Der Kernel erkennt auf dem Host keine auf PCI oder phy80211 basierenden Schnittstellen. Prüfen Sie mit <code>ls -l /sys/class/net/</code> — jeder Eintrag sollte entweder einen <code>device</code>-Symlink (PCI) oder einen <code>phy80211</code>-Eintrag (WLAN) haben. Fehlt bei einer echten Netzwerkkarte beides, ist der Treiber nicht geladen.",
|
||||
"noChangeTitle": "Nach dem Neustart änderten sich die Namen nicht wie erwartet",
|
||||
"noChangeBody": "Überprüfen Sie, ob die Datei vorhanden und gut geformt ist: <code>cat /etc/systemd/network/10-<iface>.link</code>. Dann überprüfen Sie udev logs: <code>journalctl -u systemd-udevd -b | grep -i link</code>. Eine häufige Ursache ist ein veralteter <code>net.ifnames=0</code>-Kernelparameter, der die vorhersagbare Benennung vollständig deaktiviert - entfernen Sie ihn aus <code>/etc/default/grub</code>, führen Sie <code>update-grub</code> aus, Neustart.",
|
||||
"undoTitle": "Ich möchte persistente Benennung rückgängig machen",
|
||||
"undoBody": "Löschen Sie entweder die <code>.link</code>-Dateien (<code>rm /etc/systemd/network/10-*.link</code>) oder stellen Sie sie aus dem beim vorherigen Durchlauf erstellten Backup-Verzeichnis wieder her. Starten Sie neu, um die Änderung anzuwenden."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Brückenanalyse und geführte Reparatur",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tailRich": " — der Wiederherstellungsweg, wenn sich die Namen <em>bereits</em> geändert haben."
|
||||
},
|
||||
{
|
||||
"label": "Konfigurationsanalyse und geführte Bereinigung",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": "- um verwaiste Blöcke zu entfernen, die durch Namensverschiebungen zurückgelassen wurden."
|
||||
},
|
||||
{
|
||||
"label": "Diagnose",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tailRich": " — bestätigen Sie die neuen Namen nach dem Neustart mit <em>Routingtabelle anzeigen</em>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,171 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "So wird ein OCI-Image umgesetzt | ProxMenux",
|
||||
"description": "Vom Image-Repository und der Compose-Datei über eine überprüfbare Vorlage und einen Bereitstellungsplan zu einem nativen LXC unter Proxmox VE – ohne Docker im Container."
|
||||
},
|
||||
"header": {
|
||||
"title": "So wird ein OCI-Image umgesetzt",
|
||||
"description": "Vom Image-Repository und der Compose-Datei über eine überprüfbare Vorlage und einen Bereitstellungsplan zu einem nativen LXC, ohne Docker darin zu installieren.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "pipeline",
|
||||
"title": "Der Umsetzungsablauf",
|
||||
"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": "Image-Repository",
|
||||
"converter": "Konverter",
|
||||
"template": "JSON-Vorlage",
|
||||
"blockers": "Keine Hindernisse?",
|
||||
"no": "Nein",
|
||||
"yes": "Ja",
|
||||
"review": "Prüfung / Overlay",
|
||||
"plan": "Bereitstellungsplan",
|
||||
"lxc": "Nativer LXC"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Der Konverter liest das vom Projekt veröffentlichte Image und die Compose-Datei und erzeugt eine JSON-Vorlage. Lassen sich Anforderungen noch nicht umsetzen und verhindern dadurch die Installation, wird die Vorlage vor der Veröffentlichung im Katalog geprüft. Eine Datei mit geprüften Anpassungen, das Overlay, löst diese Hindernisse. Nur Vorlagen ohne verbleibende Hindernisse werden zur Installation angeboten."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "template",
|
||||
"title": "Was die Vorlage bewahrt",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Image-Identität",
|
||||
"body": "Repository, fortlaufend aktualisiertes Tag, Architektur, ermittelter Digest und Quellrevision."
|
||||
},
|
||||
{
|
||||
"icon": "braces",
|
||||
"title": "Container-Vertrag",
|
||||
"body": "Entrypoint, Cmd, Umgebung, Benutzer, Arbeitsverzeichnis, Stoppsignal, Ports und Volumes."
|
||||
},
|
||||
{
|
||||
"icon": "layers",
|
||||
"title": "Umsetzung für Proxmox VE",
|
||||
"body": "Ressourcen, Sicherheit, Mountpoints, Geräte, sysctls und Zustandsprüfungen sowie die jeweils nötigen Anpassungen mit ihrer Begründung."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Kompatibilität",
|
||||
"body": "Unterstützte Schlüssel, noch nicht umgesetzte Anforderungen, die die Installation verhindern, und der Status jeder Validierung."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "OCI liefert den Prozess, Compose die Umgebung",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Quelle",
|
||||
"Beispiel",
|
||||
"Natives Ergebnis"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"OCI-Metadaten",
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
|
||||
"Proxmox VE importiert sie beim Erstellen des CT"
|
||||
],
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
|
||||
"LXC-Umgebungseinträge, <code>mpN</code> und <code>devN</code>"
|
||||
],
|
||||
[
|
||||
"ProxMenux-Profil",
|
||||
"GPU, Zustandsprüfung, Zugangsdaten",
|
||||
"Rückfragen und geprüfte Anpassungen"
|
||||
],
|
||||
[
|
||||
"Benutzer",
|
||||
"VMID, Speicher, Netzwerk",
|
||||
"Der Instanzvertrag"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Was während der Installation passiert",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Referenz auflösen",
|
||||
"body": "Die Registry wird abgefragt, die Architektur des Hosts ausgewählt und der konkrete Digest festgehalten, auf den das fortlaufend aktualisierte Tag verweist."
|
||||
},
|
||||
{
|
||||
"title": "Herunterladen und prüfen",
|
||||
"body": "Skopeo lädt das Image als OCI-Archiv herunter. Bevor etwas erstellt wird, wird jede Schicht anhand ihres Digests geprüft und entpackt. Ist der Download beschädigt, wird er einmal wiederholt, bevor die Installation abbricht."
|
||||
},
|
||||
{
|
||||
"title": "Dateisystem erstellen",
|
||||
"body": "<code>pct create</code> erstellt das rootfs aus dem Archiv und übernimmt die offiziellen Prozessmetadaten des Images."
|
||||
},
|
||||
{
|
||||
"title": "Ressourcen anbinden",
|
||||
"body": "Die deklarierten Volumes, Netzwerkeinstellungen, Umgebung, Geräte und Sicherheitsprofile werden eingebunden."
|
||||
},
|
||||
{
|
||||
"title": "Konsole",
|
||||
"body": "Die Konsolenausgabe des Containers wird auf dem Host gespeichert. Die Proxmox-VE-Konsole öffnet eine Shell, sofern das Image eine enthält."
|
||||
},
|
||||
{
|
||||
"title": "Prüfen",
|
||||
"body": "Beim ersten Start wird gewartet, bis der Container eine Adresse hat und der Dienst antwortet. Schlägt dies fehl, wird die Installation nicht als erfolgreich gemeldet."
|
||||
},
|
||||
{
|
||||
"title": "Konfiguration erfassen",
|
||||
"body": "Die tatsächlich verwendete Konfiguration wird im Instanzvertrag gespeichert, den Aktualisierungen und Neuerstellungen verwenden."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Beispiel: ein Image mit /config und /downloads",
|
||||
"intro": "Eine typische Compose-Definition und die daraus erzeugte Proxmox-VE-Konfiguration. Die von der Anwendung erwarteten Pfade bleiben unverändert.",
|
||||
"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 (Auszug)",
|
||||
"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> ist ein zweiter Datenträger des Containers, der im gewählten Speicher <code>vm-VMID-disk-N</code> heißt. Er wird unter <code>/config</code> eingehängt und mit <code>backup=1</code> in die Containersicherung aufgenommen. <code>mp1</code> erstellt keinen Datenträger, sondern bindet das Host-Verzeichnis <code>/srv/downloads</code> unter <code>/downloads</code> im LXC ein. Port 8080 wird nicht weitergeleitet: Der LXC hat eine eigene Adresse, unter der der Dienst antwortet."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,278 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Image außerhalb des Katalogs installieren | ProxMenux",
|
||||
"description": "Übernehmen Sie ein OCI-Image aus einer Compose-Datei, einer URL, einem docker run-Befehl oder einer Image-Referenz und prüfen Sie vor der Installation, welche Konfiguration ProxMenux umsetzen kann."
|
||||
},
|
||||
"header": {
|
||||
"title": "Image außerhalb des Katalogs installieren",
|
||||
"description": "Ein eigenes Image wird anhand seiner Compose-Datei, eines docker run-Befehls oder allein seiner Referenz für LXC umgesetzt. Das Ergebnis wird zur Prüfung angezeigt, bevor ein LXC erstellt wird.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Derselbe Konverter und Installer",
|
||||
"body": "Die Option <strong>Image außerhalb des Katalogs installieren</strong> nutzt denselben Konverter und Installer wie die Katalogvorlagen. Der Unterschied: Der Vertrag wird erst in diesem Moment aus der angegebenen Definition erzeugt und vor dem Erstellen eines LXC validiert."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "Wie das Image beschrieben wird",
|
||||
"intro": "Die erste Ansicht fragt, wie das Image beschrieben ist. Vier Möglichkeiten liefern eine Definition, die umgesetzt wird. Eine fünfte verwendet nur den Image-Namen. Drei weitere lesen eine bereits geschriebene oci-compose-Datei.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Was eingelesen wird"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Compose-Datei im Terminal einfügen",
|
||||
"Fügen Sie den YAML-Inhalt im Terminal ein und schließen Sie mit Ctrl+D ab."
|
||||
],
|
||||
[
|
||||
"Compose-Datei auf diesem Host lesen",
|
||||
"Ein Pfad auf dem Knoten, standardmäßig <code>/root/docker-compose.yml</code>. Die Datei muss existieren und darf höchstens 256 KiB groß sein."
|
||||
],
|
||||
[
|
||||
"Compose-Datei von einer Adresse herunterladen",
|
||||
"Eine <code>http://</code>- oder <code>https://</code>-Adresse, die den unverarbeiteten YAML-Inhalt bereitstellt. Es werden höchstens 256 KiB heruntergeladen."
|
||||
],
|
||||
[
|
||||
"docker run-Befehl im Terminal einfügen",
|
||||
"Der vom Projekt veröffentlichte Befehl. Ports, Umgebung, Volumes, Geräte, Capabilities, Benutzer, gemeinsam genutzter Speicher und die weiteren unterstützten Optionen werden umgesetzt."
|
||||
],
|
||||
[
|
||||
"Nur die Image-Referenz, ohne Compose-Datei",
|
||||
"Eine Referenz wie <code>ghcr.io/user/application:latest</code>. Die Registry wird abgefragt und die OCI-Metadaten des Images werden übernommen."
|
||||
],
|
||||
[
|
||||
"oci-compose im Terminal einfügen",
|
||||
"Fügen Sie den JSON-Inhalt im Terminal ein und schließen Sie mit Ctrl+D ab. Er wird nicht konvertiert, sondern geprüft und so installiert, wie er geschrieben ist."
|
||||
],
|
||||
[
|
||||
"oci-compose-Datei auf diesem Host lesen",
|
||||
"Eine JSON-Datei auf dem Knoten, standardmäßig <code>/root/oci-compose.json</code>, mit höchstens 2 MiB."
|
||||
],
|
||||
[
|
||||
"oci-compose von einer Adresse herunterladen",
|
||||
"Eine <code>http://</code>- oder <code>https://</code>-Adresse, die die JSON-Datei bereitstellt. Es werden höchstens 2 MiB heruntergeladen."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-source-menu.png",
|
||||
"alt": "Menü zur Auswahl der Beschreibung eines Images außerhalb des Katalogs",
|
||||
"caption": "Möglichkeiten zur Beschreibung eines Images außerhalb des Katalogs."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "reference-only",
|
||||
"title": "Was die Image-Referenz allein liefert",
|
||||
"intro": "Das Image enthält seine Prozessmetadaten, aber nicht die gesamte Umgebung, die eine Compose-Datei gewöhnlich ergänzt.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Aus dem Image gelesen",
|
||||
"Nicht im Image enthalten",
|
||||
"Folge"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> und die enthaltene Umgebung",
|
||||
"Variablen, die nur in der Dokumentation stehen",
|
||||
"Werden bei der Installation oder über Ändern ergänzt"
|
||||
],
|
||||
[
|
||||
"Vom Image deklarierte Volumes",
|
||||
"Host-Verzeichnisse, die nur in der Compose-Datei angegeben sind",
|
||||
"Weitere Pfade werden vor der Installation ergänzt"
|
||||
],
|
||||
[
|
||||
"<code>EXPOSE</code>-Ports",
|
||||
"URL, Protokoll oder funktionale Zustandsprüfung",
|
||||
"Port und Prüfverfahren des Dienstes werden bestätigt"
|
||||
],
|
||||
[
|
||||
"Architekturen und Digest in der Registry",
|
||||
"Geräte, Privilegien oder externe Abhängigkeiten",
|
||||
"Ohne eine entsprechende Anforderung in der Definition werden sie nicht aktiviert"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "review",
|
||||
"title": "Vor der Installation prüfen",
|
||||
"intro": "Nach dem Umsetzen der Definition zeigt ProxMenux seine Interpretation, bevor VMID, Ressourcen oder Speicher abgefragt werden.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Analysieren",
|
||||
"body": "Dienste, Image, Ports, Pfade, Umgebung, Geräte, Sicherheit und Zustandsprüfung werden eingelesen."
|
||||
},
|
||||
{
|
||||
"title": "Registry abfragen",
|
||||
"body": "Das Image muss in seiner Registry vorhanden sein; die veröffentlichten Architekturen werden aufgelistet. Bei einer privaten Registry wird das dafür gespeicherte Konto verwendet."
|
||||
},
|
||||
{
|
||||
"title": "Nicht angewendete Optionen auflisten",
|
||||
"body": "Labels, Docker-Netzwerke, Swarm-Einstellungen und andere Schlüssel ohne Wirkung in einem LXC werden aufgelistet."
|
||||
},
|
||||
{
|
||||
"title": "Optionen ohne sichere Entsprechung blockieren",
|
||||
"body": "Schlüssel ohne sichere Entsprechung erscheinen unter <strong>Nicht umsetzbare Optionen</strong>; die Installation wird dann nicht fortgesetzt. Nichts wird stillschweigend verworfen."
|
||||
},
|
||||
{
|
||||
"title": "Geheime Werte abfragen",
|
||||
"body": "Variablen, deren Namen auf Passwort, Token oder Schlüssel hinweisen, werden bei der Installation als sensible Werte abgefragt."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-review.png",
|
||||
"alt": "Zusammenfassung der Interpretation einer Compose-Datei durch ProxMenux",
|
||||
"caption": "Zusammenfassung, die vor der Abfrage von VMID und Ressourcen erscheint."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Nach Bestätigung der Zusammenfassung folgt derselbe Ablauf wie im Katalog: Name, Standard- oder erweiterter Modus, VMID, CPU, Arbeitsspeicher, Netzwerk, Start mit dem Knoten, persistente und zusätzliche Pfade, kompatible Geräte und abschließende Zusammenfassung."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "examples",
|
||||
"title": "Eingabebeispiele",
|
||||
"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": "Eine von Hand geschriebene oci-compose-Datei",
|
||||
"intro": "oci-compose ist die JSON-Datei, aus der eine Anwendung installiert wird. Der Katalog enthält eine solche Datei pro Anwendung. Dasselbe Format kann von Hand geschrieben und über diese Option installiert werden.",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Bei einer handgeschriebenen Datei legt der Autor Image, Ports, Variablen, Volumes und Installationsfragen fest. ProxMenux ergänzt den Rest beim Einlesen. Das Format kann Dinge ausdrücken, die Compose nicht enthält: Fragetexte, bei der Installation erzeugte Passwörter, GPU-Profile, Eigentümer einzelner Volumes, die Prüfung des ersten Starts und abschließend angezeigte Zugangsdaten."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Prüfen",
|
||||
"body": "Dateien mit Fehlern werden nicht installiert. Jeder Fehler nennt das betroffene Feld. Bei ungültigem JSON werden Zeile und Spalte angegeben."
|
||||
},
|
||||
{
|
||||
"title": "Überprüfen",
|
||||
"body": "Eine gültige Datei zeigt, was sie installiert: Image, Webadresse, Ports, persistente Pfade, abgefragte Variablen und geschriebene Dateien."
|
||||
},
|
||||
{
|
||||
"title": "Installieren",
|
||||
"body": "Die Installation erfolgt wie bei jeder Kataloganwendung mit Standard- oder erweiterten Einstellungen."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Eine Datei, die Privilegien festlegt",
|
||||
"body": "oci-compose legt fest, was im Container eingehängt wird und mit welchen Privilegien. Die Prüfung zeigt dies vor der Installation. Installieren Sie nur Dateien aus vertrauenswürdigen Quellen."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Die <readmeLink>README der OCI-Engine</readmeLink> beschreibt das Format Block für Block und enthält zwei vollständige Beispiele. Auch ein Installationsdatensatz kann so eingelesen werden: Verwendet wird nur die ursprüngliche Vorlage, keine der damaligen Antworten."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "private-registries",
|
||||
"title": "Images aus privaten Registries",
|
||||
"intro": "Ein Image aus einer privaten Registry, etwa ein privates GitHub-Paket oder ein privates Docker-Hub-Repository, wird mit einem in ProxMenux gespeicherten Konto gelesen.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Die Registry verweigert den Image-Zugriff",
|
||||
"body": "Meldet die Registry, dass ein Konto benötigt wird, bietet die Prüfung eine Anmeldung an und liest das Image danach erneut."
|
||||
},
|
||||
{
|
||||
"title": "Anmelden",
|
||||
"body": "Benutzername und Passwort oder Zugriffstoken mit Download-Berechtigung. Die Registry prüft sie; gespeichert werden sie nur bei erfolgreicher Anmeldung."
|
||||
},
|
||||
{
|
||||
"title": "Installieren und aktuell halten",
|
||||
"body": "Dieses Konto wird beim Herunterladen während der Installation und ebenso für Aktualisieren, Ändern, Neuerstellen, Watchdog und die Update-Prüfung des Monitors verwendet – auf jedem Cluster-Knoten."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "<strong>Registry-Konten</strong> im Hauptmenü von OCI manager Apps zeigt gespeicherte Konten nach Registry und Benutzer, niemals ihre geheimen Zugangsdaten. Pro Konto können Images geprüft, heruntergeladen oder installiert sowie Zugangsdaten aktualisiert oder entfernt werden."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"GitHub (<code>ghcr.io</code>): Als Benutzer dient das GitHub-Konto, als Passwort ein persönliches Zugriffstoken mit <code>read:packages</code>-Berechtigung.",
|
||||
"Docker Hub (<code>docker.io</code>): Als Benutzer dient das Docker-Hub-Konto, als Passwort ein Zugriffstoken mit Leseberechtigung.",
|
||||
"Andere Registries, auch mit eigenem Port wie <code>registry.example.com:5000</code>: Benutzername und Passwort oder Token dieser Registry."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Wo die Konten gespeichert werden",
|
||||
"body": "Unter <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, nur für root lesbar, im selben Ordner wie die Speicherpasswörter von Proxmox. <code>/etc/pve</code> wird von allen Cluster-Knoten gemeinsam genutzt. Ein auf einem Knoten hinzugefügtes Konto gilt daher auf allen. Die Host-Sicherung enthält die Datei; die Deinstallation von ProxMenux entfernt sie auf allen Knoten."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "limits",
|
||||
"title": "Nicht installierbare Definitionen",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Ein Dockerfile ohne veröffentlichtes Image: Das Image muss zuerst gebaut und in einer OCI-Registry veröffentlicht werden.",
|
||||
"Eine Compose-Datei mit mehreren Diensten: Diese Option installiert jeweils einen Dienst in einem Container, auch wenn mehrere Dienste dasselbe Image verwenden.",
|
||||
"<code>configs</code>, externe Geheimnisse oder Geräteformate, die sich nicht eindeutig umsetzen lassen.",
|
||||
"Shell-Ersetzungen wie <code>$(command)</code>: Stattdessen muss der resultierende Wert angegeben werden.",
|
||||
"Nicht erkannte <code>docker run</code>-Optionen und <code>--env-file</code>: Verwenden Sie stattdessen eine Compose-Datei mit expliziten Werten."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,392 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Geräte und Beschleunigung | ProxMenux",
|
||||
"description": "Wie OCI manager Apps GPU, NVIDIA, Coral, USB, FUSE und weitere Geräte als geprüfte native Proxmox-VE-Ressourcen für einen OCI-Container bereitstellt."
|
||||
},
|
||||
"header": {
|
||||
"title": "Geräte und Beschleunigung",
|
||||
"description": "GPU, NVIDIA, Coral, USB, FUSE und Blockgeräte werden validierte native Proxmox VE-Ressourcen des Containers.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "principle",
|
||||
"title": "Das Gerät, das die Anwendung benötigt, nicht der gesamte Host",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Ein in der Compose-Datei oder im Anwendungsprofil angefordertes Gerät wird als konkreter <code>devN</code>-Eintrag oder LXC-Mount eingerichtet. Das Anfordern einer GPU, eines USB-Geräts oder eines Coral-Beschleunigers macht den Container nicht privilegiert."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Host-Inventar",
|
||||
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "Hersteller und\nBerechtigungen geprüft"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "dasselbe Gerät\neffektive GID"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "origin",
|
||||
"title": "Woher die Geräteanforderung kommt",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Quelle",
|
||||
"Was gelesen wird",
|
||||
"Was der Installateur macht"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> und NVIDIA Anforderungen",
|
||||
"Jede Anforderung wird zu einer Geräteanforderung, die zur Überprüfung angezeigt wird"
|
||||
],
|
||||
[
|
||||
"Katalogprofil",
|
||||
"Die tatsächliche GPU-, Coral-, OpenCL-, USB- oder FUSE-Unterstützung der Anwendung",
|
||||
"Es werden nur die für dieses Image validierten Optionen angeboten"
|
||||
],
|
||||
[
|
||||
"Bildmetadaten und Dokumentation",
|
||||
"VA-API, Selkies, LinuxServer Mods oder die NVIDIA Laufzeit",
|
||||
"Die dokumentierten Variablen und die Vorbereitung werden hinzugefügt"
|
||||
],
|
||||
[
|
||||
"Auswahl der Nutzer",
|
||||
"Nur CPU, Intel/AMD, OpenCL, NVIDIA oder ein optionales Gerät",
|
||||
"Die Auswahl wird im Instanzvertrag gespeichert"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Erkannte Geräte werden nicht automatisch eingebunden",
|
||||
"body": "Der Host wird inventarisiert, aber nur Geräte, die in der Compose-Datei oder in einem kompatiblen Profil deklariert sind, werden angeboten und angehängt. Ein GPU, USB-Dongle oder Coral auf dem Host ist nicht jedem LXC ausgesetzt."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "identify",
|
||||
"title": "Wie das Host-Gerät identifiziert wird",
|
||||
"intro": "Bevor der LXC geändert wird, wird das Gerät auf dem Host gelesen und mit dem gewählten Profil verglichen.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Typ",
|
||||
"Identität",
|
||||
"Validierung"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD DRM",
|
||||
"<code>/dev/dri/renderD*</code> und <code>/sys/class/drm/NODE/device/vendor</code>",
|
||||
"Ein Zeichengerät mit dem Anbieter <code>0x8086</code> (Intel) oder <code>0x1002</code> (AMD)"
|
||||
],
|
||||
[
|
||||
"AMD OpenCL",
|
||||
"Der Render-Knoten plus <code>/dev/kfd</code>, wenn das Profil es benötigt",
|
||||
"Existenz, Typ, Anbieter, Berechtigungen und deklarierte Kompatibilität"
|
||||
],
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Der Renderknoten, <code>/dev/kfd</code> und die Generation, die der Compute-Treiber in <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code> meldet",
|
||||
"Eine GPU-Generation, für die das ROCm-Image der Anwendung passende Rechenkernel enthält — die dort genannten RDNA2-GPUs und neuere — wird unverändert angeboten. Andere GPUs dieser Familien, etwa Radeon 680M und 780M, werden als experimentell angeboten und nie vorausgewählt: ROCm unterstützt sie nicht offiziell, die Anwendung meldet sie als Generation ihrer Familie (<code>HSA_OVERRIDE_GFX_VERSION</code>), und vor dem Download des größeren Images ist eine Bestätigung erforderlich. Ältere GPUs, etwa die integrierte Grafik eines Ryzen 5000U, werden nicht angeboten; Immich führt die Erkennung weiter auf der CPU aus."
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"<code>nvidia-smi</code> und <code>nvidia-container-cli</code>",
|
||||
"GPU, UUID, PCI-Bus, Treiberversion, Toolkit, <code>/dev/nvidia*</code>-Knoten, Binärdateien und Bibliotheken"
|
||||
],
|
||||
[
|
||||
"Coral PCIe/M.2",
|
||||
"<code>/dev/apex_N</code> und sein Link in <code>/sys/dev/char/MAJOR:MINOR</code>",
|
||||
"Zeichengeräteknoten, Major-/Minor-Nummern, Eigentümer, GID und Berechtigungen"
|
||||
],
|
||||
[
|
||||
"USB und serielle",
|
||||
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> oder <code>/dev/bus/usb/BBB/DDD</code>",
|
||||
"Zeichenknoten; für USB auch Anbieter, Produkt und Seriennummer, wenn sysfs sie veröffentlicht"
|
||||
],
|
||||
[
|
||||
"KVM, TUN, FUSE, Video und generische SCSI",
|
||||
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> oder <code>/dev/sgN</code>",
|
||||
"Unterstützter Pfad, Knotentyp und effektive Berechtigungen"
|
||||
],
|
||||
[
|
||||
"Optisches Laufwerk",
|
||||
"<code>/dev/srN</code>",
|
||||
"Ein Blockgerät"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Was passiert während der Installation",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Das Template bietet seine Profile",
|
||||
"body": "Nur CPU, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL oder NVIDIA. Die Optionen gehören zum Image, nicht zu einem gemeinsamen Menü."
|
||||
},
|
||||
{
|
||||
"title": "Ein Profil wird gewählt",
|
||||
"body": "Es definiert die Geräteknoten, die Umgebung, die Mods oder die Laufzeit, die die Anwendung benötigt."
|
||||
},
|
||||
{
|
||||
"title": "Ein Pfad wird vorgeschlagen",
|
||||
"body": "Für DRM <code>/dev/dri/renderD128</code>, das auf einem Host mit mehreren Renderknoten geändert werden kann. Für USB oder seriell wird der konkrete Knoten ausgewählt."
|
||||
},
|
||||
{
|
||||
"title": "Validierung",
|
||||
"body": "Existenz, Typ, erlaubter Anbieter, Berechtigungen und GID werden überprüft. Eine Abweichung stoppt die Operation."
|
||||
},
|
||||
{
|
||||
"title": "Der Vertrag ist geschrieben",
|
||||
"body": "Pfad, Modus, GID, Schreibzugriff und Profil werden für Updates und Neuerstellungen aufgezeichnet."
|
||||
},
|
||||
{
|
||||
"title": "Einbinden und testen",
|
||||
"body": "<code>pct set</code> fügt den <code>devN</code>-Eintrag hinzu und der Zugriff wird dann im LXC überprüft. LinuxServer-Images werden auch als Benutzer <code>abc</code> überprüft."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "config",
|
||||
"title": "Wie es in der LXC-Konfiguration erscheint",
|
||||
"intro": "Beispiele: <code>dev0</code> und <code>dev1</code> sind die freien Slots, die Proxmox VE zuweist, und <code>renderD128</code>, <code>apex_0</code> und die GID hängen von der Hardware des Knotens ab.",
|
||||
"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": "Ein spezifisches USB-Gerät",
|
||||
"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": "Die GID wird mit <code>stat</code> auf dem Host gelesen und in den <code>devN</code>-Eintrag geschrieben; es wird nicht angenommen, dass die Gruppen <code>render</code> und <code>video</code> eine feste Nummer haben. Das Gerät behält den gleichen <code>/dev</code>-Pfad innerhalb des LXC, wo die anwendungseigenen Mechanismen danach suchen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "profiles",
|
||||
"title": "Profile, die ein Image bieten kann",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Profil",
|
||||
"Umsetzung",
|
||||
"Angeboten, wenn"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD VA-API",
|
||||
"<code>/dev/dri</code> Renderknoten",
|
||||
"Die Anwendung unterstützt Videobeschleunigung"
|
||||
],
|
||||
[
|
||||
"OpenCL",
|
||||
"Renderknoten, <code>/dev/kfd</code> bei Bedarf und der offizielle Mod",
|
||||
"Das Image oder Profil dokumentiert es"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"Treibergeräte und Bibliotheken des Hosts",
|
||||
"Der Host hat einen funktionierenden Treiber und das NVIDIA Container Toolkit"
|
||||
],
|
||||
[
|
||||
"Coral",
|
||||
"<code>/dev/apex_0</code> oder USB-Bus",
|
||||
"Das Profil erklärt Coral-Unterstützung (Frigate)"
|
||||
],
|
||||
[
|
||||
"USB, seriell, FUSE",
|
||||
"Ein einzelnes Gerät, ein validierter Baum oder eine LXC-Funktion",
|
||||
"Der Vertrag verlangt es"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "nvidia",
|
||||
"title": "NVIDIA",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Voraussetzung auf dem Knoten: NVIDIA Container Toolkit",
|
||||
"body": "Ein funktionierender Treiber auf Proxmox VE reicht nicht aus, um einem OCI-Image eine NVIDIA-GPU zu geben. OCI Manager Apps verwendet <code>nvidia-container-cli</code> aus dem NVIDIA Container Toolkit, um die Geräte zu identifizieren und die Binärdateien und Bibliotheken zu erhalten, die dem geladenen Treiber entsprechen."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "<nvidiaLink>ProxMenux NVIDIA installer</nvidiaLink> installiert das NVIDIA Container Toolkit aus dem offiziellen NVIDIA-Repository zusammen mit dem Treiber. Es überprüft seine vier Pakete, validiert <code>nvidia-container-cli</code> und zeichnet das Ergebnis im Change Journal von <auditLink>Audit & Report</auditLink> auf."
|
||||
},
|
||||
{
|
||||
"p": "Diese beiden Befehle auf dem Host zeigen an, ob der Treiber und das Toolkit verfügbar sind:"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-smi -L\nnvidia-container-cli --version"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Auf einem Host, auf dem der Treiber auf andere Weise installiert wurde, wird das Toolkit aus dem offiziellen stabilen Repository installiert:"
|
||||
},
|
||||
{
|
||||
"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": "Das von OCI manager Apps verwendete Inventar stammt aus der Ausgabe von:"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Docker Laufzeitkonfiguration ist nicht beteiligt",
|
||||
"body": "Die Container sind native LXCs ohne Docker-Daemon. Daher spielt <code>nvidia-ctk runtime configure --runtime=docker</code> keine Rolle: ProxMenux fragt <code>nvidia-container-cli</code> direkt ab und trägt Geräte und Mounts in die LXC-Konfiguration ein. Die aktuellen Befehle und unterstützten Plattformen stehen in der <toolkitLink>Installationsanleitung zum NVIDIA Container Toolkit</toolkitLink>."
|
||||
}
|
||||
},
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "cpu",
|
||||
"title": "Inventar aus dem Treiber",
|
||||
"body": "<code>nvidia-container-cli</code> listet Geräteknoten, Binärdateien, Firmware und Bibliotheken des installierten Treibers auf."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Keine feste Version",
|
||||
"body": "Die Vorlage nennt keine Bibliotheksdateien. Das Profil wird vom aktuellen Host generiert."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Nur lesbare Mounts",
|
||||
"body": "Die Hostbibliotheken werden schreibgeschützt montiert, anstatt in den Container kopiert zu werden."
|
||||
},
|
||||
{
|
||||
"icon": "hardDrive",
|
||||
"title": "Treiberänderungen",
|
||||
"body": "Nach einem Treiberwechsel wird das Inventar erneut generiert, bevor die betroffenen LXCs starten."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"code": {
|
||||
"title": "NVIDIA Ergebnis (vereinfacht)",
|
||||
"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": "Nur <code>/dev/nvidia0</code> zu übergeben ist nicht genug. Die Benutzerraumkomponenten des geladenen Treibers werden schreibgeschützt montiert, und <code>nvidia-smi</code> läuft dann innerhalb des LXC, um GPU, UUID, PCI-Bus und Version mit dem Host-Inventar zu vergleichen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "usb",
|
||||
"title": "USB, serielle und USB Coral",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "USB-Nummerierung kann sich ändern",
|
||||
"body": "Ein Pfad wie <code>/dev/bus/usb/003/004</code> kann sich ändern, wenn das Gerät wieder angeschlossen wird oder der Host neu gestartet wird. Das Profil zeichnet Anbieter, Produkt und Seriennummer auf, wenn sie verfügbar sind, aber eine neue Busadresse wird nicht automatisch neu zugeordnet."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Ein Peripheriegerät wird durch seinen konkreten Knoten angegeben: <code>/dev/ttyUSB0</code>, <code>/dev/ttyACM0</code>, <code>/dev/apex_0</code> oder <code>/dev/bus/usb/BBB/DDD</code>. Die Weitergabe des gesamten <code>/dev</code> wird nicht akzeptiert. Coral wird nur Anwendungen angeboten, deren Profil es deklariert."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "trees",
|
||||
"title": "Gerätebäume und LXC-Funktionen",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Anforderung",
|
||||
"Umsetzung",
|
||||
"Umfang"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>/dev/dvb</code>, <code>/dev/snd</code> oder <code>/dev/bus/usb</code>",
|
||||
"Jeder Zeichenknoten des Baumes erhält seinen eigenen <code>devN</code>-Eintrag mit dem Host-Modus und GID",
|
||||
"Nur der angeforderte Baum, nicht der Rest von <code>/dev</code>"
|
||||
],
|
||||
[
|
||||
"<code>/dev/fuse</code>",
|
||||
"Der Knoten und, wenn das Profil es benötigt, die <code>fuse=1</code>-Funktion",
|
||||
"FUSE allein veröffentlicht keine Mounts für andere LXCs"
|
||||
],
|
||||
[
|
||||
"<code>/dev/net/tun</code>",
|
||||
"Ein <code>devN</code>-Eintrag auf demselben Pfad innerhalb des LXC",
|
||||
"Die VPN- oder Netzwerkkonfiguration bleibt in der Anwendung"
|
||||
],
|
||||
[
|
||||
"<code>/dev/kvm</code>",
|
||||
"Ein validierter <code>devN</code>-Eintrag",
|
||||
"Angeboten nur, wenn der Vertrag es verlangt"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "security",
|
||||
"title": "Bestätigungen nach Risikograd",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Konkrete Geräte, optionale Privilegien, erforderliche Privilegien, AppArmor- oder seccomp-Entspannung und der Zugriff auf den Host-PID-Namespace werden als separate Fälle behandelt, nicht unter einem generischen privilegierten Label. Jede Option mit einem Risiko wird während der Installation erklärt und bestätigt."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,213 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "OCI manager Apps | ProxMenux",
|
||||
"description": "Führen Sie offizielle OCI-Images als native LXC-Container unter Proxmox VE aus – mit persistenten Daten, Gerätezugriff, Anwendungen aus mehreren Containern und transaktionalen Aktualisierungen."
|
||||
},
|
||||
"header": {
|
||||
"title": "OCI manager Apps",
|
||||
"description": "Offizielle OCI-Images laufen als native LXC-Container unter Proxmox VE. Das vom Maintainer veröffentlichte Image bleibt unverändert; ProxMenux bildet die Umgebung nach, die Docker Compose dafür eingerichtet hätte.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "model",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Ein OCI-Image, ein nativer LXC",
|
||||
"body": "In den Containern läuft keine Docker Engine. Proxmox VE importiert das Dateisystem und die OCI-Metadaten des Images. Die Anwendung wird zum Hauptprozess eines nativen LXC und lässt sich mit denselben Werkzeugen verwalten wie andere Container auf dem Knoten."
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Quelle",
|
||||
"detail": "OCI-Image\nCompose und Dokumentation"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "JSON-Vertrag\nValidierung und Planung"
|
||||
},
|
||||
{
|
||||
"label": "Proxmox VE",
|
||||
"detail": "Nativer LXC\nVolumes und Geräte"
|
||||
}
|
||||
],
|
||||
"caption": "Die Anwendung wird nicht neu gebaut. Ihre Umgebung wird deklarativ beschrieben und nachgebildet."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "where",
|
||||
"title": "Wo Sie es finden",
|
||||
"intro": "Öffnen Sie auf dem Proxmox-Knoten als root den Eintrag <strong>OCI manager Apps (Technology Preview)</strong> im ProxMenux-Hauptmenü. Die erste Ansicht bietet:",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"<strong>Anwendungen suchen</strong> – den gesamten Katalog nach Namen durchsuchen.",
|
||||
"<strong>Alle Anwendungen</strong> – den vollständigen Katalog samt Anzahl der Anwendungen anzeigen.",
|
||||
"<strong>Installierte OCI-Anwendungen verwalten</strong> – vorhandene Installationen aktualisieren, ändern, entfernen oder wiederherstellen.",
|
||||
"<strong>Registry-Konten</strong> – Konten zum Installieren und Aktualisieren von Images aus privaten Registries verwalten.",
|
||||
"<strong>Image außerhalb des Katalogs installieren</strong> – eine Compose-Datei, einen <code>docker run</code>-Befehl oder eine Image-Referenz übernehmen und anpassen.",
|
||||
"Die Kategorien des Katalogs, jeweils mit der Anzahl ihrer Anwendungen."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/main-menu.png",
|
||||
"alt": "Hauptansicht von OCI manager Apps mit Suche, Gesamtkatalog, Anwendungsverwaltung, eigenen Images und Katalogkategorien.",
|
||||
"caption": "Hauptansicht von OCI manager Apps."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Nach der Auswahl einer Anwendung sehen Sie deren Beschreibung, das verwendete Image und zwei Installationsarten. <strong>Mit Standardeinstellungen installieren</strong> fragt nur die grundlegenden Entscheidungen ab: Speicher, Datenablage, Adresse und Start. <strong>Mit erweiterten Einstellungen installieren</strong> führt nacheinander durch alle Optionen: VMID und Ressourcen, Speicher für jeden Pfad, Netzwerk-Bridge und Geräte."
|
||||
},
|
||||
{
|
||||
"p": "Tatsächlich getestete Anwendungen zeigen in dieser Ansicht <strong>Geprüft</strong> und sind in den Listen mit ✓ gekennzeichnet. Das gilt für Tests im ProxMenux-Labor ebenso wie für Tests durch die Community."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "beta",
|
||||
"title": "Warum es als Technology Preview gekennzeichnet ist",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "OCI manager Apps verwendet die Bezeichnung <strong>Technology Preview</strong>, die Proxmox VE den aus OCI-Images erstellten Anwendungscontainern zuweist. Deren Unterstützung wurde mit Proxmox VE 9.1 eingeführt. Die Bezeichnung betrifft die zugrunde liegende Proxmox-Technik, nicht die ProxMenux-Engine: Das Verhalten dieser Container kann sich zwischen Proxmox-VE-Versionen noch ändern. Die Kennzeichnung bleibt bestehen, bis Proxmox VE diese Unterstützung als stabil einstuft."
|
||||
},
|
||||
{
|
||||
"p": "Die Funktionen von OCI manager Apps werden im ProxMenux-Labor getestet: Installation, Aktualisierung, Änderung, Neuerstellung, Sicherung, Wiederherstellung, Migration und Watchdog. Jede Anwendung wird separat geprüft. Tatsächlich getestete Anwendungen tragen die Kennzeichnung <strong>Geprüft</strong> und ein ✓ in den Listen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "translation",
|
||||
"title": "Wie Docker Anforderungen beschreibt und OCI manager Apps sie umsetzt",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Anforderung",
|
||||
"Darstellung in Docker",
|
||||
"Umsetzung durch OCI manager Apps"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Anwendung ausführen",
|
||||
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
|
||||
"OCI-rootfs und Hauptprozess des LXC"
|
||||
],
|
||||
[
|
||||
"Konfiguration erhalten",
|
||||
"<code>volumes: /config</code>",
|
||||
"Ein persistentes <code>mpN</code>-Volume, das in die Sicherung aufgenommen wird, oder ein Verzeichnis auf dem Host."
|
||||
],
|
||||
[
|
||||
"Dienst bereitstellen",
|
||||
"<code>ports</code>",
|
||||
"Eine eigene Adresse für den LXC und die Zugriffs-URL des Dienstes."
|
||||
],
|
||||
[
|
||||
"Hardware verwenden",
|
||||
"<code>devices</code>, <code>group_add</code>",
|
||||
"<code>devN</code>-Einträge mit der tatsächlich verwendeten Gruppen-ID (GID) des Hosts und einem validierten Profil."
|
||||
],
|
||||
[
|
||||
"Abhängigkeiten verbinden",
|
||||
"<code>networks</code>, <code>depends_on</code>",
|
||||
"Eine private Netzwerk-Bridge, feste Adressen, Startreihenfolge und Zustandsprüfungen."
|
||||
],
|
||||
[
|
||||
"Aktualisieren",
|
||||
"Mit <code>pull</code> herunterladen und neu erstellen",
|
||||
"Ein neues rootfs mit demselben Persistenzvertrag."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "kept",
|
||||
"title": "Was erhalten bleibt und was sich ändert",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Bleibt erhalten",
|
||||
"body": "Das offizielle Image, seine internen Pfade, seine Umgebung, sein Startprozess und seine Nutzungsdokumentation."
|
||||
},
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Wird angepasst",
|
||||
"body": "Die Laufzeitumgebung: Netzwerk, Persistenz, Geräte, Berechtigungen und Abhängigkeiten werden mit den nativen LXC-Funktionen von Proxmox VE umgesetzt."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Ohne Entsprechung",
|
||||
"body": "Eine Compose-Option ohne sichere Entsprechung wird als Installationshindernis aufgeführt. Vorlagen mit solchen Hindernissen werden nicht zur Installation angeboten. Sensible Optionen müssen während der Installation bestätigt werden."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Wird gespeichert",
|
||||
"body": "Image-Digest, Ressourcen, Pfade, Netzwerk, Geräte und Zugehörigkeit zu einem Stack werden im Instanzvertrag gespeichert. Aktualisierungen und Neuerstellungen bilden diesen Vertrag wieder ab."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "pages",
|
||||
"title": "Seiten in diesem Abschnitt",
|
||||
"blocks": [
|
||||
{
|
||||
"next": {
|
||||
"items": [
|
||||
{
|
||||
"label": "So wird ein OCI-Image umgesetzt",
|
||||
"href": "/docs/oci-manager/architecture",
|
||||
"tail": "Vom Image und seiner Compose-Datei zu einem nativen LXC."
|
||||
},
|
||||
{
|
||||
"label": "Image außerhalb des Katalogs installieren",
|
||||
"href": "/docs/oci-manager/custom-image",
|
||||
"tail": "Compose-Datei, docker run oder eine Image-Referenz."
|
||||
},
|
||||
{
|
||||
"label": "Daten, Pfade und Netzwerk",
|
||||
"href": "/docs/oci-manager/storage-network",
|
||||
"tail": "Container-Volumes, Host-Verzeichnisse, rclone-Mounts und Adressen."
|
||||
},
|
||||
{
|
||||
"label": "Geräte und Beschleunigung",
|
||||
"href": "/docs/oci-manager/hardware",
|
||||
"tail": "GPU, NVIDIA, Coral, USB und weitere Geräte."
|
||||
},
|
||||
{
|
||||
"label": "Anwendungen mit mehreren Containern",
|
||||
"href": "/docs/oci-manager/stacks",
|
||||
"tail": "Anwendung, Datenbank und Cache als koordinierte LXCs."
|
||||
},
|
||||
{
|
||||
"label": "Installieren, aktualisieren und ändern",
|
||||
"href": "/docs/oci-manager/lifecycle",
|
||||
"tail": "Der Instanzvertrag und seine Vorgänge."
|
||||
},
|
||||
{
|
||||
"label": "In ProxMenux Monitor",
|
||||
"href": "/docs/oci-manager/monitor",
|
||||
"tail": "Versionen, Aktualisierungen, Konsolenausgabe und Terminal."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,499 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Installieren, Aktualisieren und Ändern | ProxMenux",
|
||||
"description": "Der Instanzvertrag eines OCI-Containers und die darauf beruhenden Vorgänge: Aktualisieren, Ändern, Entfernen, Fortsetzen eines unterbrochenen Vorgangs und Wiederherstellen des Betriebs nach einer Wiederherstellung auf diesem oder einem anderen Host."
|
||||
},
|
||||
"header": {
|
||||
"title": "Installation, Aktualisierung und Änderung",
|
||||
"description": "Jede Instanz behält einen reproduzierbaren Vertrag, sodass ihr rootfs ersetzt werden kann, ohne Konfiguration oder persistente Daten zu verlieren.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "contract",
|
||||
"title": "Der Instanzvertrag",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Nach einer Installation wird die effektive Konfiguration in <code>/usr/local/share/proxmenux/oci/instances/VMID/oci-compose.json</code> gespeichert. Es ist keine Kopie der ursprünglichen Compose-Datei: Es ist der reproduzierbare Vertrag des LXC, der auf diesem Host existiert."
|
||||
},
|
||||
{
|
||||
"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": "Eine Kopie des Vertrags liegt im Container unter <code>/.proxmenux/oci-record.json</code> und ist nur für dessen Benutzer root lesbar. Eine Containersicherung enthält daher immer den zu diesem Zeitpunkt gültigen Vertrag. Eine zweite Kopie liegt unter <code>/etc/pve/priv/proxmenux/oci</code>; dieses Verzeichnis ist auf allen Clusterknoten verfügbar und nur für root des Hosts lesbar. Beide Kopien werden nach jeder Installation, Aktualisierung und Änderung geschrieben."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "manage",
|
||||
"title": "Verwalten installierter OCI-Anwendungen",
|
||||
"intro": "Diese Option auf dem Hauptbildschirm listet die registrierten Instanzen mit ihrer Anwendung und ihrem Image auf. Vor jeder Aktion wird jede Instanz mit ihrem Vertrag abgeglichen; ein CT, der nicht mehr zu seinem Datensatz passt, wird weder geändert noch gelöscht. Dieselbe Aktualisierungsfunktion und derselbe Editor stehen auf der Registerkarte Aktualisierungen von <monitorLink>ProxMenux Monitor</monitorLink> bereit.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Was sich ändert",
|
||||
"Was erhalten bleibt"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Aktualisieren Sie das Image mit der gespeicherten Konfiguration",
|
||||
"Das rootfs wird durch das Image ersetzt, das der gespeicherte Kanal aktuell bereitstellt",
|
||||
"Vertrag, Containerplatten, Hostverzeichnisse, Netzwerk und Geräte"
|
||||
],
|
||||
[
|
||||
"Ändern: Ressourcen, Netzwerk, Pfade und GPU bearbeiten",
|
||||
"Der Editor öffnet sich mit dem aktuellen Vertrag; der CT wird mit den Änderungen neu erstellt",
|
||||
"Die Daten von Container-Disks und Host-Verzeichnissen"
|
||||
],
|
||||
[
|
||||
"Watchdog: Neustart der Anwendung, wenn sie abstürzt",
|
||||
"Ob die Anwendung nach einem selbstständigen Beenden erneut gestartet wird. Es wird nichts neu erstellt",
|
||||
"Die gesamte Installation; nur die Wahl ist im Vertrag gespeichert"
|
||||
],
|
||||
[
|
||||
"Entfernen: Löschen Sie die Anwendung und ihre Container",
|
||||
"Der LXC oder jedes Mitglied eines Stacks und seine Verträge werden gelöscht",
|
||||
"Host-Verzeichnisse mit ihren Inhalten"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Für eine Anwendung mit mehreren Containern bietet das Menü <strong>Alle Container der Anwendung aktualisieren</strong>, <strong>Zusätzliche Pfade und Geräte ändern</strong>, <strong>Alle Container mit ihrer gespeicherten Konfiguration neu erstellen</strong>, den Watchdog und die Entfernung. Ändern fügt die zusätzlichen Pfade und Geräte des Anwendungscontainers hinzu oder entfernt sie, ohne etwas neu zu erstellen. Bei Immich lässt sich damit auch ändern, womit die Erkennung ausgeführt wird. Neu erstellen erstellt jeden Container anhand des ursprünglich installierten Images neu, ohne nach einem neueren zu suchen."
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/manage-menu.png",
|
||||
"alt": "Liste der installierten OCI-Anwendungen und der Optionen zum Aktualisieren, Ändern und Entfernen",
|
||||
"caption": "Verwalten Sie installierte OCI-Anwendungen."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "update",
|
||||
"title": "Transaktionsaktualisierung",
|
||||
"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": "Benutzer",
|
||||
"registry": "OCI-Register",
|
||||
"update": "Instanz aktualisieren",
|
||||
"resolve": "Tag auflösen",
|
||||
"verify": "Archiv prüfen und Vorabprüfungen durchführen",
|
||||
"backup": "Stoppen und sichern Sie den CT",
|
||||
"import": "Neues rootfs importieren",
|
||||
"reapply": "Den Vertrag erneut anwenden",
|
||||
"healthy": "in Ordnung",
|
||||
"failure": "Ausfall",
|
||||
"commit": "Vertrag mit dem neuen Digest veröffentlicht",
|
||||
"restored": "Frühere Instanz wiederhergestellt"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Wenn die Registry weiterhin den installierten Digest bedient, wird nichts heruntergeladen und die Instanz nicht berührt.",
|
||||
"Das neue Image wird Schicht für Schicht verifiziert, bevor der CT stoppt. Ein Download, der beschädigt ankommt, wird ein zweites Mal abgerufen; ein bereits zwischengespeichertes Image, das den Check nicht besteht, wird erneut heruntergeladen.",
|
||||
"Nach der Installation in Proxmox VE geänderte Einstellungen (Arbeitsspeicher, Swap, Kerne, CPU-Limit, CPU-Priorität, Start mit dem Knoten) bleiben erhalten und werden in den neuen Vertrag übernommen.",
|
||||
"Die LAN-Schnittstelle, die die Arr-Suite und Multi-Container-Anwendungen hinzufügen (<code>net1</code>) und die Startreihenfolge (<code>startup</code>) werden an den neuen Container zurückgegeben.",
|
||||
"Jeder andere Unterschied zwischen dem CT und seinem Vertrag stoppt das Update, bevor der CT gestoppt wird."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Vorher",
|
||||
"detail": "rootfs A\n/config mp0\n/media Hostverzeichnis"
|
||||
},
|
||||
{
|
||||
"label": "Aktualisierung",
|
||||
"detail": "ersetzt nur\ndas rootfs"
|
||||
},
|
||||
{
|
||||
"label": "Nachher",
|
||||
"detail": "rootfs B\n/config mp0\n/media Hostverzeichnis"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Bevor etwas gestoppt wird, prüft der Vorgang, ob ausreichend Platz für die Sicherung vorhanden ist: die belegten Daten der zu sichernden Volumes plus eine Reserve. Die Sicherung wird neben dem Anwendungsdatensatz auf dem Systemlaufwerk des Hosts gespeichert. Reicht der Platz dort nicht aus, fragt das Menü nach einem anderen Host-Speicher, der Sicherungen unterstützt. Dort wird die Sicherung erstellt und nach Abschluss des Vorgangs gelöscht. Die Auswahl wird für diese Anwendung auch für geplante Aktualisierungen gespeichert. Hat kein Speicher ausreichend Platz, wird der Vorgang abgelehnt und die Anwendung bleibt unverändert. Der Platzbedarf des neuen Images wird vor dem Herunterladen ebenso geprüft."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "recovery",
|
||||
"title": "Wiederherstellung eines unterbrochenen Vorgangs",
|
||||
"intro": "Ein Update und eine Änderung verwenden eine persistente Transaktion. Wenn der Prozess, das Terminal oder der Knoten nach dem Stoppen des CT unterbrochen wird, wird die Operation nicht als abgeschlossen angesehen.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Ausstehender Marker",
|
||||
"body": "Beim Öffnen von „Installierte OCI-Anwendungen verwalten“ zeigt der gespeicherte Zustand, dass der Ersatz nie veröffentlicht wurde."
|
||||
},
|
||||
{
|
||||
"title": "Status anzeigen",
|
||||
"body": "Zeigt die Phase an, die erreicht wurde, ohne Container oder Daten zu ändern."
|
||||
},
|
||||
{
|
||||
"title": "Wiederherstellen der vorherigen Installation",
|
||||
"body": "Stellt die vor dem Ersatz erstellte und geprüfte native Sicherung sowie den vorherigen Vertrag wieder her."
|
||||
},
|
||||
{
|
||||
"title": "Stacks als Einheit",
|
||||
"body": "Für eine Multi-Container-Anwendung wird jedes Mitglied aus dem gleichen Transaktionspunkt wiederhergestellt, nicht nur das ausgewählte."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Host-Verzeichnisse liegen außerhalb des Rollbacks",
|
||||
"body": "Die Sicherung umfasst das rootfs und die darin eingeschlossenen Containerlaufwerke. Ein Hostverzeichnis wird nicht zurückgesetzt, da andere LXCs dessen Daten verwenden können."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "watchdog",
|
||||
"title": "Watchdog: Neustart einer Anwendung, die stoppt",
|
||||
"intro": "Proxmox hat keine Neustartrichtlinie: Wenn der Prozess eines Anwendungscontainers endet, bleibt der Container gestoppt. Mit dem Watchdog wird eine Anwendung, die von selbst aufhört, erneut gestartet. Es tut für eine OCI-Anwendung, was <code>restart: unless-stopped</code> in einer Compose-Datei tut.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Was passiert",
|
||||
"Mit aktiviertem Watchdog"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Die Anwendung stürzt ab oder ihr Prozess endet",
|
||||
"Der Container wird innerhalb von Sekunden wieder gestartet"
|
||||
],
|
||||
[
|
||||
"Es wird von Proxmox, vom Monitor oder mit <code>pct</code> gestoppt oder heruntergefahren",
|
||||
"Er bleibt gestoppt, bis ihn jemand startet"
|
||||
],
|
||||
[
|
||||
"Ein Backup, eine Migration oder eine ProxMenux-Operation arbeitet daran",
|
||||
"Nichts wird getan, bis das endet"
|
||||
],
|
||||
[
|
||||
"Er war beim Start des Hosts bereits gestoppt",
|
||||
"Er bleibt gestoppt; dafür ist <strong>Mit Proxmox starten</strong> zuständig"
|
||||
],
|
||||
[
|
||||
"Es stoppt direkt nach dem Start",
|
||||
"Bei einer Anwendung, die Sekunden nach dem Start wieder stoppt oder gar nicht startet, werden fünf Startversuche unternommen. Dazwischen liegen Wartezeiten von 30 Sekunden, 1, 2 und 5 Minuten. Danach bleibt sie gestoppt und eine Benachrichtigung wird gesendet"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Das Installationsprogramm fragt in beiden Installationsmodi danach und schlägt den im Anwendungsrezept angegebenen Wert vor. Später lässt sich die Einstellung unter <strong>Installierte OCI-Anwendungen verwalten</strong> oder mit dem Schalter <strong>Watchdog</strong> des Containers in <monitorLink>ProxMenux Monitor</monitorLink> ändern. Sie gilt für alle Container einer Anwendung mit mehreren Containern. Ein einziger Host-Dienst, <code>proxmenux-oci-watchdog.service</code>, überwacht alle Anwendungen, für die dies aktiviert wurde; seine Installation erscheint auf der Registerkarte Änderungen von Audit & Report."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Was der Host nicht sagen kann",
|
||||
"body": "Der Exit-Code der Anwendung erreicht den Host nicht. Daher sind ein reguläres Beenden und ein Absturz nicht unterscheidbar; in beiden Fällen wird neu gestartet, wie bei <code>always</code> und <code>unless-stopped</code> in Docker. Ein außerhalb von Proxmox mit <code>lxc-stop</code> oder <code>systemctl</code> angeforderter Stopp hinterlässt keinen Stopp-Task und wird als selbstständiges Beenden gewertet."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Backup, Wiederherstellung und ein weiterer Host",
|
||||
"intro": "Eine mit vzdump oder Proxmox Backup Server erstellte Sicherung enthält den Container, die für die Sicherung ausgewählten Containerlaufwerke und die Kopie seines Vertrags. Was die Installation auf dem Host speichert, ist nicht darin enthalten. <strong>Installierte OCI-Anwendungen verwalten</strong> erkennt Container, die auf einem Host ohne ihren Vertrag wiederhergestellt wurden, etwa nach einer Proxmox-Neuinstallation oder auf einem anderen Host, und bietet ihre erneute Registrierung an.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Wiederherstellen der Container in Proxmox",
|
||||
"body": "Vom Sicherungsspeicher, mit der ursprünglichen ID oder einer beliebigen freien ID. Bei einer Anwendung mit mehreren Containern werden alle ihre Container benötigt."
|
||||
},
|
||||
{
|
||||
"title": "Installierte OCI-Anwendungen verwalten öffnen",
|
||||
"body": "Die wiederhergestellten Container werden aufgelistet und die Wiederherstellung ihrer Registrierung wird angeboten. Die Schaltfläche <strong>Wiederherstellen</strong> auf der Registerkarte Aktualisierungen von <monitorLink>ProxMenux Monitor</monitorLink> öffnet denselben Vorgang."
|
||||
},
|
||||
{
|
||||
"title": "Überprüfen Sie vor dem Wechsel",
|
||||
"body": "Die Wiederherstellung überprüft, ob der Host alles hat, was jede Anwendung benötigt. Eine Anwendung, die nicht als Ganzes wiederhergestellt werden kann, bleibt so, wie sie gefunden wurde, mit dem Grund."
|
||||
},
|
||||
{
|
||||
"title": "Registrieren und starten",
|
||||
"body": "Der Vertrag wird auf diesem Host registriert und was die Installation darauf aufbewahrt, wird erneut geschrieben. Das Starten der Anwendungen ist eine separate Frage, die mit Nein beantwortet wird, wenn die ursprünglichen Container noch auf einem anderen Host ausgeführt werden."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-offer.png",
|
||||
"alt": "Dialog, der die wiederhergestellten Container auflistet und anbietet, sie wiederherzustellen",
|
||||
"caption": "Die beim Öffnen von „Installierte OCI-Anwendungen verwalten“ angebotene Wiederherstellung."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Was der Host behalten hat",
|
||||
"Nach der Wiederherstellung"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Instanzvertrag",
|
||||
"Wird aus der Kopie im Container registriert und mit der von Proxmox wiederhergestellten Konfiguration abgeglichen"
|
||||
],
|
||||
[
|
||||
"Privates Netzwerk einer Multicontainer-Anwendung",
|
||||
"Wird mit derselben Bridge und demselben Subnetz neu erstellt; die festen Adressen der Container ändern sich nicht"
|
||||
],
|
||||
[
|
||||
"Startreihenfolge einer Anwendung mit mehreren Containern",
|
||||
"Das Abhängigkeits-Hookscript und sein Vertrag werden wieder installiert; Snippets sind auf dem <code>local</code>-Speicher aktiviert, wenn kein Speicher sie akzeptiert"
|
||||
],
|
||||
[
|
||||
"Netzwerk sysctls und Host-Monitor-Datei",
|
||||
"Nochmals geschrieben in <code>/etc/pve/proxmenux</code>"
|
||||
],
|
||||
[
|
||||
"NVIDIA Laufzeit",
|
||||
"Der Hook eines unprivilegierten Containers wird erneut installiert. Ein privilegierter Container erhält die Treiberdateien dieses Hosts statt der Dateien seines ursprünglichen Hosts"
|
||||
],
|
||||
[
|
||||
"Rclone mount",
|
||||
"Das Hookscript und die Programme, die das Mount veröffentlichen, werden erneut geschrieben, mit den gleichen Ansichten auf dem Host"
|
||||
],
|
||||
[
|
||||
"Host-Firewallregel eines Host-Monitors",
|
||||
"Wird erneut abgefragt, für seinen Web-Port und das Subnetz der Bridge auf diesem Host"
|
||||
],
|
||||
[
|
||||
"<code>lost+found</code> jeder wiederhergestellten Festplatte",
|
||||
"Wird entfernt, wenn es leer ist; bei einer Wiederherstellung wird es angelegt, und manche Anwendungen starten nicht, wenn es in ihrem Datenverzeichnis liegt"
|
||||
],
|
||||
[
|
||||
"Disks auf einem anderen Speicher wiederhergestellt",
|
||||
"Der Vertrag wird auf den Speicher aktualisiert, auf dem sie sich jetzt befinden"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Ein mit einer anderen ID wiederhergestellter Container behält seine Anwendung. Der Vertrag, sein Konsolenprotokoll, seine Netzwerk-sysctls, das Hookscript einer Rclone-Einhängung und die Startreihenfolge einer Anwendung mit mehreren Containern werden mit den IDs registriert, die die Container auf diesem Host haben."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Was eine Wiederherstellung verhindert",
|
||||
"Was zu tun ist"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Ein Container einer Multicontainer-Anwendung fehlt",
|
||||
"Stellen Sie es auch wieder her; Die Anwendung wird als Ganzes wiederhergestellt"
|
||||
],
|
||||
[
|
||||
"Das private Subnetz wird bereits auf diesem Host verwendet",
|
||||
"Die Wiederherstellung wird abgebrochen und nichts wird geändert: Die Adressen der Container sind fixiert und werden nicht in ein anderes Subnetz verschoben"
|
||||
],
|
||||
[
|
||||
"Ein Hostverzeichnis existiert nicht",
|
||||
"Mounten oder erstellen Sie es mit seinen Daten; ein Backup des Containers enthält keine Hostverzeichnisse"
|
||||
],
|
||||
[
|
||||
"Ein Gerät existiert nicht auf diesem Host",
|
||||
"Verbinden Sie es oder entfernen Sie es aus dem Container in Proxmox"
|
||||
],
|
||||
[
|
||||
"Eine Anwendung mit NVIDIA auf einem Host ohne Treiber",
|
||||
"Installieren Sie den NVIDIA-Treiber und das Container Toolkit"
|
||||
],
|
||||
[
|
||||
"Das Backup wurde erstellt, bevor die Kopie des Vertrages existierte",
|
||||
"Der Container bleibt als gewöhnlicher LXC und wird nicht wieder angeboten"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Ein Container, der zurückkommt",
|
||||
"body": "Ein Container, der von einem älteren Backup wiederhergestellt, zu einem Snapshot zurückgerollt oder von einem anderen Knoten zurückgegeben wurde, trägt den Vertrag des Zustands, in dem er sich befindet. Wenn es für eine Operation ausgewählt wird und sein Vertrag von dem dieses Hosts abweicht, startet die Operation nicht und der Container wird zur Wiederherstellung angeboten."
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-result.png",
|
||||
"alt": "Ergebnis der Wiederherstellung mit privatem Netzwerk, Startreihenfolge und registrierten Containern",
|
||||
"caption": "Das Ergebnis einer Wiederherstellung, Schritt für Schritt."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "remove",
|
||||
"title": "Entfernen einer OCI-Anwendung",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Vor der Bestätigung wird eine Zusammenfassung aus der tatsächlichen Konfiguration erstellt: die zu entfernenden Container, die damit gelöschten Daten, das freigegebene private Netzwerk und die erhaltenen Hostverzeichnisse. Die Bestätigung steht standardmäßig auf <strong>Nein</strong>, da die Daten gelöschter Laufwerke anschließend nicht wiederhergestellt werden können."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ressource",
|
||||
"Beim Entfernen",
|
||||
"Grund"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"rootfs und Container-Festplatten",
|
||||
"Gelöscht",
|
||||
"Sie gehören nur zum Container"
|
||||
],
|
||||
[
|
||||
"Hostverzeichnis",
|
||||
"Bleibt mit seinem Inhalt erhalten",
|
||||
"Andere Anwendungen können es verwenden"
|
||||
],
|
||||
[
|
||||
"Host-Dateien des Containers",
|
||||
"Gelöscht",
|
||||
"Sein Konsolenprotokoll, Netzwerk-Sysctls, Rclone Mount Hookscript und seine Registrierung in der App-Registerkarte von ProxMenux Monitor dienen keinem anderen Container"
|
||||
],
|
||||
[
|
||||
"Von mehreren Installationen gemeinsam genutzte Dateien",
|
||||
"Gelöscht mit der letzten Installation, die sie verwendet",
|
||||
"Die Host-Monitor-Datei und das Dependency-Hookscript von Multi-Container-Anwendungen"
|
||||
],
|
||||
[
|
||||
"Instanzvertrag",
|
||||
"Nach erfolgreicher Entfernung gelöscht",
|
||||
"Kein CT ist mehr damit verbunden"
|
||||
],
|
||||
[
|
||||
"Private Bridge eines Stacks",
|
||||
"Mit dem Stack freigegeben",
|
||||
"Es sind keine Mitglieder mehr zu verbinden"
|
||||
],
|
||||
[
|
||||
"Von der Arr-Suite gemeinsam genutztes Netzwerk",
|
||||
"Wird beim Entfernen der letzten Anwendung der Suite freigegeben",
|
||||
"Jede Anwendung der Suite ist unabhängig und wird einzeln entfernt"
|
||||
],
|
||||
[
|
||||
"Ein einzelnes Mitglied eines Stapels",
|
||||
"Wird nicht einzeln entfernt",
|
||||
"Die gesamte Anwendung wird entfernt, so dass kein Stapel unvollständig bleibt"
|
||||
],
|
||||
[
|
||||
"Ein Container auf einem anderen Knoten des Clusters",
|
||||
"Nicht entfernt",
|
||||
"Seine Datensatz- und Hostdateien befinden sich auf dem Knoten, auf dem es installiert wurde: Es wird dort entfernt, nachdem es zurück migriert wurde."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/remove-summary.png",
|
||||
"alt": "Zusammenfassung zum Entfernen mit den betroffenen Containern, Daten und Hostverzeichnissen",
|
||||
"caption": "Die Entfernungszusammenfassung, aufgebaut aus der realen Konfiguration."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "archives",
|
||||
"title": "Heruntergeladene Images und Speicherplatz auf dem Host",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Das OCI-Archiv dient zum Erstellen des rootfs; der laufende CT liest es nicht. Nach einer Installation oder Aktualisierung werden die dabei heruntergeladenen Archive mit ihrer Größe aufgelistet und zur Löschung angeboten. Ihre Löschung gibt Speicherplatz frei, ohne den Container oder seine Daten zu beeinträchtigen."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Updates benötigen das Archiv nicht",
|
||||
"body": "Ohne Archiv löst ein Update den gespeicherten Kanal auf und lädt den neuen Digest herunter. Mit ihm wird ein Archiv nur dann wiederverwendet, wenn seine Referenz und Integrität mit dem übereinstimmen, was angefordert wird."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "registry",
|
||||
"title": "Einträge und Bereinigung",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Beim Öffnen von <strong>Installierte OCI-Anwendungen verwalten</strong> werden zuerst Reste von Containern entfernt, die auf keinem Clusterknoten mehr existieren: der als Verlauf aufbewahrte Datensatz eines über die Proxmox-Oberfläche gelöschten Containers sowie Host-Dateien, die bei einer Entfernung zurückblieben. Ein Datensatz mit einem unterbrochenen Vorgang bleibt erhalten, da seine Sicherung noch benötigt werden könnte. Volumes und Hostverzeichnisse werden niemals aufgrund bloßer Schlussfolgerungen gelöscht."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "cluster",
|
||||
"title": "In einem Cluster: Migration und hohe Verfügbarkeit",
|
||||
"intro": "Ein OCI-Container ist ein gewöhnlicher Proxmox-LXC: Er kann wie jeder andere migriert oder von HA verwaltet werden, mit denselben Einschränkungen. Alles, was er zum Starten benötigt, wird dort gespeichert, wo jeder Clusterknoten darauf zugreifen kann.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Teil",
|
||||
"Auf einem anderen Knoten des Clusters"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Konsolenlogbuch",
|
||||
"Der Container erstellt <code>/var/log/proxmenux/oci</code> vor dem Start auf dem jeweiligen ausführenden Knoten. Jeder Knoten behält das Protokoll der von ihm ausgeführten Starts."
|
||||
],
|
||||
[
|
||||
"Netzwerk sysctls und Host-Monitor",
|
||||
"Werden in <code>/etc/pve/proxmenux</code> gespeichert, das alle Clusterknoten gemeinsam nutzen, sodass ein migrierter Container sie findet."
|
||||
],
|
||||
[
|
||||
"Containerfestplatten",
|
||||
"Proxmox verschiebt sie mit dem Container. Für HA müssen ihre Daten auf dem Zielknoten verfügbar sein, über gemeinsamen Speicher oder eine unterstützte Replikationskonfiguration."
|
||||
],
|
||||
[
|
||||
"Host-Verzeichnisse und Geräte",
|
||||
"Die gleichen Regeln wie bei jedem LXC: Ein Host-Verzeichnis muss auf dem Zielknoten vorhanden sein und als gemeinsam genutzt markiert werden, und ein GPU, Coral oder NPU muss dort vorhanden sein."
|
||||
],
|
||||
[
|
||||
"ProxMenux-Datensatz",
|
||||
"Der Vertrag bleibt auf dem Knoten, auf dem die Anwendung installiert wurde; alle Knoten lesen die Kopie unter <code>/etc/pve/priv/proxmenux/oci</code>. Eine migrierte Anwendung mit einem einzelnen Container wird auf dem Zielknoten registriert, sobald <strong>Installierte OCI-Anwendungen verwalten</strong> geöffnet oder eine Aktion für sie gestartet wird. Eine Anwendung mit mehreren Containern wird dort zur Wiederherstellung angeboten, da ihr privates Netzwerk auf diesem Knoten erstellt werden muss."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Nicht für hohe Verfügbarkeit",
|
||||
"body": "Eine Multicontainer-Anwendung erreicht ihre Mitglieder über eine private Brücke des Knotens, auf dem sie installiert wurde, so dass ihre Mitglieder auf diesem Knoten bleiben. Ein Hostmonitor, z. B. Glances im Hostmodus oder Netdata, überwacht den Knoten, auf dem er ausgeführt wird; das Bewegen würde einen anderen Knoten überwachen."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Ein Backup, das außerhalb des Clusters wiederhergestellt wird, erhält die Dateien von <code>/etc/pve/proxmenux</code>, die der Container verwendet, wenn die Anwendung wiederhergestellt wird."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "channel",
|
||||
"title": "Ein Rolling Tag ist kein unbeaufsichtigtes Update",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Der Katalog installiert das vom Maintainer veröffentlichte Rolling-Tag. Der tatsächliche Digest wird aufgelöst und aufgezeichnet und nur durch eine explizite Aktualisierung mit Vorabprüfung und Rollback geändert. <monitorLink>ProxMenux Monitor</monitorLink> vergleicht den installierten Digest mit dem von der Registry veröffentlichten Digest und zeigt und meldet, wenn ein neues Image verfügbar ist."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,213 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "OCI Container in ProxMenux Monitor | ProxMenux",
|
||||
"description": "Was ProxMenux Monitor für einen mit OCI manager Apps installierten Container zeigt: Anwendungs- und Image-Versionen, neue Images, Konsolenausgabe und Proxmox-VE-Terminal."
|
||||
},
|
||||
"header": {
|
||||
"title": "In ProxMenux Monitor",
|
||||
"description": "Ein mit OCI manager Apps installierter Container erscheint wie jeder andere LXC unter VMs & LXCs. Sein Detaildialog liest den Installationsdatensatz: Anwendungs- und Image-Versionen, neue Images, Konsolenausgabe und Terminal.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Die Aufzeichnung ist die Quelle",
|
||||
"body": "OCI manager Apps kennt die installierte Anwendung und ihre Herkunft. Der Monitor liest diesen Installationsdatensatz, statt die Anwendung im Container zu untersuchen. Diese Informationen stehen deshalb sowohl bei laufendem als auch bei gestopptem Container zur Verfügung."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Tab.",
|
||||
"Was ändert sich für einen OCI Container"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Status",
|
||||
"Ein <strong>Watchdog</strong> Switch unter Start beim Booten: Die Anwendung wird wieder gestartet, wenn sie von selbst stoppt"
|
||||
],
|
||||
[
|
||||
"App",
|
||||
"Die Anwendung wird aus dem Datensatz identifiziert und Updates werden nach Image verfolgt"
|
||||
],
|
||||
[
|
||||
"Aktualisierungen",
|
||||
"Das Image wird aktualisiert oder die Anwendung geändert, mit dem gleichen Ablauf wie das OCI-Menü"
|
||||
],
|
||||
[
|
||||
"Mounts",
|
||||
"Containerfestplatten und Hostverzeichnisse mit ihrer Belegung"
|
||||
],
|
||||
[
|
||||
"Protokolle",
|
||||
"Nur für OCI-Container: die Konsolenausgabe der Anwendung"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "app",
|
||||
"title": "App",
|
||||
"intro": "Die Registerkarte <appLink>App</appLink> bietet die installierte Anwendung als Erkennung mit dem Namen, dem Logo, dem Port und dem Schema des Datensatzes. Die Registrierung öffnet den Editor mit der Methode <strong>OCI-Image (installiert von ProxMenux)</strong>, die keine Konfiguration benötigt.",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Anwendung",
|
||||
"body": "Die Version der Anwendung im Image, gelesen aus dem Image selbst: seine Umgebung oder seine <code>org.opencontainers.image.version</code> Label. Es ist informativ."
|
||||
},
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Image",
|
||||
"body": "Das Build-Datum und der Digest des installierten Images. Das Update wird hier entschieden: Der installierte Digest wird mit dem verglichen, den die Registry heute für dasselbe Tag veröffentlicht."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Wenn die Registry einen neuen Digest veröffentlicht, zeigt die Karte <strong>Neues Image</strong> mit seinem Datum und Digest an, auch wenn sich die Anwendungsversion im Inneren nicht geändert hat: Ein Neuaufbau auf einer aktualisierten Basis ist ein Update.",
|
||||
"Wenn die Digests übereinstimmen, liest die Karte <strong>Version</strong>.",
|
||||
"Die Karte verlinkt auf das Repository des Images: das GitHub-Projekt oder die Docker-Hub-Seite für ein offizielles Image.",
|
||||
"Der Zugangslink verwendet die LAN-Adresse des Containers, auch für das Hauptmitglied einer Multicontainer-Anwendung, die eine zweite Adresse in ihrem privaten Netzwerk hat.",
|
||||
"Die Schaltfläche <strong>Daten aktualisieren</strong> liest den Datensatz und die Registry erneut. Die Optionen zum Suchen oder Registrieren weiterer Anwendungen werden nicht angeboten: Der Container enthält genau die Anwendung seines Datensatzes."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/monitor-app-tab.png",
|
||||
"alt": "App-Tab eines OCI-Containers mit Anwendungsversion, Image und Repository-Link",
|
||||
"caption": "Registerkarte App eines mit OCI manager Apps installierten Containers."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Der Check läuft einmal täglich mit den Update-Checks des Monitors und <strong>Daten aktualisieren</strong> führt ihn sofort aus. Ein neues Image wird als Benachrichtigung über die in <notificationsLink>Benachrichtigungen</notificationsLink> konfigurierten Kanäle gesendet. Das Update wird über den Tab Updates angewendet."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "updates",
|
||||
"title": "Aktualisierungen",
|
||||
"intro": "Bei einem mit OCI manager Apps installierten Container zeigt die Registerkarte Updates die Anwendung mit ihrem installierten Image und gegebenenfalls dem neuen Image aus der Registry, im selben Format wie andere Anwendungen. Die Paket- und Anwendungs-Updater eines gewöhnlichen LXC werden nicht angeboten.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Schaltfläche",
|
||||
"Was es öffnet"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Aktualisierung",
|
||||
"Die Aktualisierung aus <lifecycleLink>Installierte OCI-Anwendungen verwalten</lifecycleLink> für diesen Container im Monitor-Terminal. Sie kann mit oder ohne neues Image ausgeführt werden; ohne neues Image wird nichts verändert. Bei einer Multicontainer-Anwendung werden alle Mitglieder aktualisiert."
|
||||
],
|
||||
[
|
||||
"Ändern",
|
||||
"Der Editor der Anwendung (Ressourcen, Netzwerk, Pfade und GPU). In einer Multicontainer-Anwendung werden die zusätzlichen Pfade und Geräte des Anwendungscontainers hinzugefügt oder entfernt und in Immich wird geändert, was die Erkennung ausführt."
|
||||
],
|
||||
[
|
||||
"Wiederherstellen",
|
||||
"Ersetzt Update, wenn eine Operation auf dem Container unterbrochen wurde, und öffnet seine Wiederherstellung."
|
||||
],
|
||||
[
|
||||
"Wiederherstellen (wiederhergestellter Container)",
|
||||
"Wird für einen aus einem Backup wiederhergestellten Container ohne Vertrag auf diesem Host unter <strong>Wiederhergestellte OCI-Anwendung</strong> angezeigt. Öffnet die <lifecycleLink>Wiederherstellung</lifecycleLink> im Monitor-Terminal; Aktualisieren und Ändern erscheinen nach der Registrierung."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Externe Änderungen, Hostverzeichnisse und Multicontainer-Anwendungen werden wie im OCI-Menü behandelt. In einer Multicontainer-Anwendung erscheinen die Buttons und die Optionen nur auf dem Hauptcontainer; die anderen Mitglieder zeigen ihr Image, eine Notiz, dass sie vom Hauptcontainer aktualisiert werden, und eine Schaltfläche, die es öffnet. Wenn das Terminal schließt, werden das Image, der Datensatz und die Mounts erneut gelesen."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Verhalten"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Das vor dem Update erstellte Backup behalten",
|
||||
"Jedes Update sichert den Container, um ihn wiederherzustellen, wenn das Update fehlschlägt. Mit dieser Option wird dasselbe Backup im ausgewählten Speicher gespeichert und erscheint unter den Backups des CT; auf Proxmox Backup Server wird vor dem Update ein Backup geschrieben."
|
||||
],
|
||||
[
|
||||
"Geplante Updates",
|
||||
"Das Image wird zum gewählten Zeitpunkt nur aktualisiert, wenn die Registry ein neues veröffentlicht, und optional nur, wenn es 1, 3, 7 oder 14 Tage alt ist. Ein Container mit Änderungen außerhalb von ProxMenux wird übersprungen und gemeldet."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "logs",
|
||||
"title": "Protokolle",
|
||||
"intro": "Die Registerkarte Logs erscheint nur bei mit OCI manager Apps installierten Containern, zwischen Mounts und Backups. Sie zeigt Standardausgabe und Standardfehler des Hauptprozesses des Images, entsprechend der Ausgabe von <code>docker logs</code> bei Docker-Containern.",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Die Ausgabe wird auf dem Host in <code>/var/log/proxmenux/oci/VMID.console.log</code> (Modus 0600) vom ersten Start und über Neustarts gehalten, so dass sie mit gestopptem Container gelesen werden kann.",
|
||||
"Die Datei wird bei 10 MB gedreht und behält drei komprimierte Kopien (<code>/etc/logrotate.d/proxmenux-oci</code>).",
|
||||
"Jeder Start des Containers wird in der Ausgabe markiert. Die Registerkarte zeigt die Ausgabe seit dem letzten Start standardmäßig; <strong>Vollständiger Verlauf</strong> zeigt auch die vorherigen.",
|
||||
"Wenn die Anwendung entfernt wird, wird ihre Ausgabe mit ihr entfernt.",
|
||||
"Die letzten 100-, 500- oder 1000-Zeilen werden gezeigt. Während der Container läuft, werden neue Zeilen live verfolgt; das Scrollen nach oben pausiert das Folgen und <strong>Follow</strong> nimmt es wieder auf.",
|
||||
"Ein Filter zeigt nur die Zeilen an, die einen Text enthalten, und <strong>Herunterladen</strong> speichert die geladenen Zeilen.",
|
||||
"Farbcodes werden entfernt und eine Zeile, die eine Fortschrittsleiste neu zeichnet, wird in ihrem endgültigen Zustand angezeigt.",
|
||||
"Die Registerkarte liest die Datei bei jedem Öffnen; es wird nicht zwischengespeichert."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Zugangsdaten beim ersten Start",
|
||||
"body": "Images, die ein generiertes Passwort beim ersten Start ausdrucken, lassen es in dieser Ausgabe, wie <code>docker logs</code>. Der Installateur liest es von dort aus, um es in seiner Zusammenfassung zu zeigen."
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/monitor-logs-tab.png",
|
||||
"alt": "Logs Tab mit dem Konsolenausgang eines OCI-Containers, dem Zeilenwähler, dem Filter und der Follow-Taste",
|
||||
"caption": "Konsolenausgabe eines OCI-Containers."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "terminal",
|
||||
"title": "Proxmox VE Konsole",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Ein OCI-Image startet seinen eigenen Prozess als PID 1 und keinen Anmeldedienst. Die übliche LXC-Konsole würde deshalb ein Terminal ohne antwortenden Login-Prozess öffnen. Mit OCI manager Apps installierte Container erhalten <code>cmode: shell</code>: Die Proxmox-VE-Konsole öffnet über <code>lxc-attach</code> eine Shell, entsprechend <code>docker exec</code>. Die laufende Anwendung bleibt dabei unverändert."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Die Shell ist diejenige, die <code>/etc/passwd</code> dem Root im Image gibt. Ein Image, dessen Root keine Shell hat oder keine ausliefert, behält die Standardkonsole.",
|
||||
"Die Shell ist root im Container, ohne Passwort. Wer es öffnen kann, wird durch die <code>VM.Console</code>-Berechtigung von Proxmox VE entschieden.",
|
||||
"Das Terminal des Monitors betritt den Container mit <code>pct enter</code>, was auf die gleiche Weise funktioniert."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "mounts",
|
||||
"title": "Mounts",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Die Registerkarte <mountsLink>Mounts</mountsLink> listet die Festplatten und Hostverzeichnisse des Containers auf. Die Belegung einer Containerfestplatte auf Blockspeicher wie LVM-thin wird aus deren Dateisystem gelesen, das nur im Container eingehängt ist."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,404 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Multicontainer-Anwendungen | ProxMenux",
|
||||
"description": "Wie OCI manager Apps eine Anwendung mit Datenbank und Cache als koordinierte native LXCs umsetzt: Planung, privates Netzwerk, Abhängigkeits-Hook, Validierung und transaktionale Aktualisierungen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Anwendungen mit mehreren Containern",
|
||||
"description": "Eine Anwendung mit Datenbank, Cache und anderen Diensten wird zu mehreren koordinierten nativen LXCs, die als eine installiert und aktualisiert werden.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Eine Anwendung für den Benutzer, mehrere LXCs für Proxmox VE",
|
||||
"body": "Eine Multicontainer-Definition ist ein Eintrag des Katalogs. Der Installer erstellt einen nativen LXC pro Dienst und behält seine Abhängigkeiten explizit. Immich, Nextcloud, Paperless-ngx und Tandoor werden auf diese Weise installiert."
|
||||
}
|
||||
},
|
||||
{
|
||||
"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": "Stack-Plan",
|
||||
"app": "Anwendungs-LXC",
|
||||
"appNet": "LAN + privat",
|
||||
"db": "PostgreSQL LXC",
|
||||
"cache": "Valkey LXC",
|
||||
"private": "privat"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "plan",
|
||||
"title": "1. Der Plan, bevor ein Container existiert",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Es wird kein LXC erstellt, während die Compose-Definition interpretiert wird. Ein vollständiger Plan steht an erster Stelle, mit jedem Mitglied, Image, VMID, Netzwerk, Pfad, Geheimnis, Ordnung und Gesundheitscheck. Wenn der Plan nicht konsistent ist, wird die Installation nicht gestartet."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Planelement",
|
||||
"Inhalt",
|
||||
"Vor dem Erstellen geprüft"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Mitglieder",
|
||||
"Hauptanwendung, Datenbank, Cache, maschinelles Lernen und andere Abhängigkeiten",
|
||||
"Einzigartige VMIDs, bekannte Rollen und genau ein Hauptmitglied"
|
||||
],
|
||||
[
|
||||
"Images",
|
||||
"Rollende Referenz, Architektur und aufgelöster Digest jedes Dienstes",
|
||||
"Alle existieren, unterstützen die Architektur und bestehen die OCI-Integritätsprüfung"
|
||||
],
|
||||
[
|
||||
"Netzwerk",
|
||||
"Private Bridge, Subnetz, eine feste Adresse pro Dienst und LAN-Zugang für das Hauptmitglied",
|
||||
"Keine Kollision mit vorhandenen Brücken oder Subnetzen und keine wiederholte Adresse"
|
||||
],
|
||||
[
|
||||
"Persistenz",
|
||||
"Container-Disks, Host-Verzeichnisse, Besitzer und Backup",
|
||||
"Keine überlappenden Pfade, Speicher verfügbar und deklarierte Berechtigungen"
|
||||
],
|
||||
[
|
||||
"Geheimnisse",
|
||||
"Datenbankpasswort, Anwendungsschlüssel und erste Anmeldeinformationen",
|
||||
"Einmal generiert und nur an die Mitglieder gegeben, die sie verwenden"
|
||||
],
|
||||
[
|
||||
"Lebenszyklus",
|
||||
"Start-Order, Stop-Order und Gesundheitscheck pro Mitglied",
|
||||
"Die Hauptanwendung startet zuletzt und stoppt zuerst"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "create",
|
||||
"title": "2. Erstellung, Mitglied für Mitglied",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Reservieren Sie jeden VMID",
|
||||
"body": "Das Proxmox-VE-Inventar und das Instanzverzeichnis werden geprüft. Ein vorhandener CT wird nicht übernommen; ein Vertrag, der noch zu einer anderen Instanz gehört, wird nicht wiederverwendet."
|
||||
},
|
||||
{
|
||||
"title": "Jedes Image vorbereiten",
|
||||
"body": "Alle Images werden aufgelöst, heruntergeladen und verifiziert, bevor der erste Container erstellt wird."
|
||||
},
|
||||
{
|
||||
"title": "Erstellen Sie alle Rootfs",
|
||||
"body": "Die offiziellen OCI-Metadaten werden importiert und die ProxMenux-Instanzidentität und die Mitgliedsrolle hinzugefügt."
|
||||
},
|
||||
{
|
||||
"title": "Privates Netzwerk",
|
||||
"body": "Eine Brücke und ein Subnetz werden erstellt und jedes Mitglied erhält seine feste Adresse; nur das Hauptmitglied erhält auch die LAN-Schnittstelle."
|
||||
},
|
||||
{
|
||||
"title": "Persistenz",
|
||||
"body": "Jede Datenbank und Konfiguration erhält eine eigene Containerplatte; nur Daten, die freigegeben werden sollen, verwenden Hostverzeichnisse."
|
||||
},
|
||||
{
|
||||
"title": "Umgebung",
|
||||
"body": "Interne Endpunkte, Shared Secrets und Servicevariablen werden geschrieben. Die Anwendung erreicht ihre Abhängigkeiten an ihren reservierten Privatadressen."
|
||||
},
|
||||
{
|
||||
"title": "Aufzeichnung",
|
||||
"body": "Jedes Mitglied zeichnet seine native Konfiguration, die Rootfs-Änderungen, die Updates reproduzieren müssen, und seine Beziehung zum Stack auf."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "checks",
|
||||
"title": "3. Starten und Überprüfen Sie jeden Container",
|
||||
"intro": "Ein erstellter LXC bedeutet noch keinen betriebsbereiten Dienst. Die Abhängigkeiten starten der Reihe nach und durchlaufen jeweils eine dienstspezifische Prüfung.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Dienst",
|
||||
"Überprüfung",
|
||||
"Was es zeigt"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"PostgreSQL",
|
||||
"<code>pg_isready</code> im CT mit erwartetem Host, Benutzer und Datenbank",
|
||||
"Der Server akzeptiert Verbindungen für die konfigurierte Datenbank"
|
||||
],
|
||||
[
|
||||
"Redis / Valkey",
|
||||
"<code>redis-cli</code> oder <code>valkey-cli</code> <code>PING</code> gegen seine Privatadresse",
|
||||
"Der Broker hört zu und antwortet"
|
||||
],
|
||||
[
|
||||
"Immich Maschinelles Lernen",
|
||||
"HTTP <code>GET /ping</code>, plus eine Überprüfung der ausgewählten GPU-Laufzeit",
|
||||
"Der Service antwortet und die angeforderte Beschleunigung ist nicht auf CPU zurückgefallen"
|
||||
],
|
||||
[
|
||||
"Nextcloud",
|
||||
"<code>GET /status.php</code> mit <code>installed=true</code>, <code>maintenance=false</code> und <code>needsDbUpgrade=false</code>",
|
||||
"Initialisierung ohne anstehende Migration beendet"
|
||||
],
|
||||
[
|
||||
"Paperless-ngx / Tandoor",
|
||||
"HTTP über die LAN-Adresse und den realen Port des Dienstes",
|
||||
"Das Frontend und seine Abhängigkeiten stellen die Anwendung bereit"
|
||||
],
|
||||
[
|
||||
"Hauptanwendung",
|
||||
"Der Endpunkt seines Templates, zum Beispiel <code>/api/server/ping</code> in Immich",
|
||||
"Der gesamte Stapel arbeitet durch die Anwendung, die die Abhängigkeiten verwendet"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Laufend bedeutet nicht funktionsfähig",
|
||||
"body": "Der laufende Zustand sagt nur, dass der LXC-Prozess existiert. Wenn der Dienst eine bessere Prüfung bietet, wird eine Exec- oder HTTP-Prüfung mit einem Timeout verwendet. Wenn ein Mitglied stoppt oder seine Prüfung nicht besteht, wird der Stapel nicht als installiert deklariert."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "hook",
|
||||
"title": "4. Der Abhängigkeits-Hook",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Der Haken wird nur auf den Hauptcontainer eines abhängigen Stapels gesetzt. Proxmox VE behält das Skript als Snippet und führt es als <code>hookscript</code> dieses CT aus. Das Stack-Rezept ist nicht im Skript geschrieben: Es befindet sich in einem separaten privaten Vertrag."
|
||||
},
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Hauptkonfiguration CT",
|
||||
"code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh"
|
||||
},
|
||||
{
|
||||
"title": "Privatvertrag (Beispiel)",
|
||||
"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": "Vollständige Quelle von proxmenux-stack-dependencies.sh",
|
||||
"pathCode": "local:snippets/proxmenux-stack-dependencies.sh",
|
||||
"snippetCode": "stackDependencyHook"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Das Skript ist für jeden Stack gleich. VMIDs, Namen, Prüftypen und Timeouts stammen aus dem privaten Vertrag <code>/etc/pve/priv/proxmenux-stack-VMID.json</code> jedes Stacks."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Proxmox VE ruft pre-start auf",
|
||||
"body": "Bevor der Haupt-CT startet, läuft der Hook mit seinem VMID und der Lebenszyklusphase."
|
||||
},
|
||||
{
|
||||
"title": "Eine Sperre pro Stack",
|
||||
"body": "<code>flock</code> auf <code>/run/lock/proxmenux-stack-VMID.lock</code> verhindert zwei Startsequenzen gleichzeitig."
|
||||
},
|
||||
{
|
||||
"title": "Der Vertrag wird gelesen und validiert",
|
||||
"body": "Ein bekanntes Schema, numerische Abhängigkeiten, Labels, ein exec, http oder Running Check und ein positives Timeout sind erforderlich."
|
||||
},
|
||||
{
|
||||
"title": "Abhängigkeiten in der Reihenfolge",
|
||||
"body": "Jeder CT muss vorhanden sein; ein gestoppter wird gestartet und ein bereits laufender wird nicht neu gestartet."
|
||||
},
|
||||
{
|
||||
"title": "Auf Betriebsbereitschaft warten",
|
||||
"body": "Der Check läuft alle zwei Sekunden, und der CT wird ebenfalls bestätigt, dass er noch läuft."
|
||||
},
|
||||
{
|
||||
"title": "Der Haupt-CT startet",
|
||||
"body": "Wenn jede Abhängigkeit bereit ist, endet der Vorstart und Proxmox VE startet die Anwendung."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Der Haken stoppt Abhängigkeiten nicht",
|
||||
"body": "Die Post-Start-, Pre-Stop- und Post-Stop-Phasen tun nichts. Das Stoppen des Haupt-CT lässt PostgreSQL, Redis, Valkey oder Machine Learning laufen. Der Hook ordnet den Start an; er verwandelt nicht mehrere LXCs in einen Prozess."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Typ",
|
||||
"Beispiel",
|
||||
"Spätere Starts"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Abhängiger Stapel",
|
||||
"Immich, Nextcloud, Anwendung mit PostgreSQL",
|
||||
"Der Haken des Haupt-CT startet die Abhängigkeiten und wartet auf sie"
|
||||
],
|
||||
[
|
||||
"Anwendungssuite",
|
||||
"Arr Suite",
|
||||
"Kein Hauptmitglied: jeder LXC folgt seinem eigenen <code>onboot</code>"
|
||||
],
|
||||
[
|
||||
"Einzelne Anwendung",
|
||||
"Jellyfin",
|
||||
"Proxmox VE startet diesen LXC direkt"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "stack-checks",
|
||||
"title": "5. Kontrollen am Stapel als Ganzes",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Jede VMID existiert, ist einzigartig und behält die erwartete Instanzidentität.",
|
||||
"Jeder Vertrag gehört zum selben Stack, behält seine Rolle und seine aufgezeichnete native Konfiguration.",
|
||||
"Das Hauptmitglied ist das letzte in <code>start_order</code> und das erste in <code>stop_order</code>.",
|
||||
"Es fehlt keine Member-, Volume- oder Rootfs-Adaption.",
|
||||
"Der Haken zeigt auf das offizielle Snippet, sein Inhalt ist unverändert und sein Vertrag entspricht dem Stapelrezept.",
|
||||
"Die beobachteten Images und Digests stimmen mit den vorbereiteten OCI-Archiven überein.",
|
||||
"Geräte, GPU-Profile, Mounts, Geheimnisse und Endpunkte stimmen immer noch mit den Verträgen überein.",
|
||||
"Nachdem alle Abhängigkeiten ihre Prüfung bestanden haben, prüft der Endpunkt der Hauptanwendung die Integration zwischen den Mitgliedern."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "manage",
|
||||
"title": "Verwalten eines installierten Stapels",
|
||||
"intro": "Unter <strong>Installierte OCI-Anwendungen verwalten</strong> führt jedes Mitglied zum gesamten Stack. Das Menü bietet <strong>Alle Container der Anwendung aktualisieren</strong>, <strong>Zusätzliche Pfade und Geräte ändern</strong>, <strong>Alle Container mit ihrer gespeicherten Konfiguration neu erstellen</strong> und <strong>Entfernen: Anwendung und Container löschen</strong>. Die Neuerstellung baut jeden Container anhand des gespeicherten Digests aus seinem ursprünglichen Image neu auf, ohne nach einem neueren zu suchen. Sie verwendet dieselben Schritte wie ein Update und wird für aktualisierbare Stacks angeboten.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Jedes Mitglied",
|
||||
"body": "Der Vertrag des Mitglieds nennt die Haupt-VMID und die vollständige Liste der Mitglieder."
|
||||
},
|
||||
{
|
||||
"title": "Der Stapel ist reproduzierbar",
|
||||
"body": "Identitäten, Verträge, Hook, Anpassungen und eine koordinierte Wiederholung für dieses Rezept werden validiert."
|
||||
},
|
||||
{
|
||||
"title": "Images zuerst",
|
||||
"body": "Die Anwendung wird nicht gestoppt, bis jeder Digest gelöst, heruntergeladen und verifiziert wurde."
|
||||
},
|
||||
{
|
||||
"title": "Stoppen und sichern Sie das Set",
|
||||
"body": "Verifizierte native Backups werden mit gestopptem Stack übernommen, sodass Anwendung und Datenbanken zum selben Zeitpunkt gehören."
|
||||
},
|
||||
{
|
||||
"title": "Aktualisieren und überprüfen Sie jedes Mitglied",
|
||||
"body": "Anpassung, Netzwerk, Mounts, Geheimnisse und Geräte werden vor dem Gesundheitscheck jedes Mitglieds erneut angewendet."
|
||||
},
|
||||
{
|
||||
"title": "Alles veröffentlichen oder wiederherstellen",
|
||||
"body": "Die neuen Verträge werden nur veröffentlicht, wenn jedes Mitglied besteht. Wenn einer scheitert, wird jedes Mitglied wiederhergestellt."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ändern",
|
||||
"Was sich ändert",
|
||||
"Was erhalten bleibt"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Extra Pfade und Geräte",
|
||||
"Sie werden dem Anwendungscontainer hinzugefügt oder daraus entfernt, der neu gestartet wird. Es wird nichts neu erstellt",
|
||||
"Die Daten der Anwendung, ihrer Datenbank und der anderen Container"
|
||||
],
|
||||
[
|
||||
"Was die Erkennung ausführt (Immich)",
|
||||
"Der Machine Learning Container nimmt das Image und die Geräte des CPU oder eines GPU des Hosts auf. Die gesamte Anwendung wird gestoppt und aktualisiert, wie in einem Update",
|
||||
"Der Modell-Cache, die Bibliothek und die Datenbank. Wenn etwas fehlschlägt, werden die vorherigen Container und die vorherige Auswahl wiederhergestellt"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Ein Stack ohne koordinierte Wiederholung wird nicht aktualisiert",
|
||||
"body": "Wenn die Vorbereitung eines Stapels nicht reproduziert werden kann, wird die Aktualisierung abgelehnt, bevor der Stapel gestoppt wird. Die Anwendung läuft so, wie sie ist."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "failure",
|
||||
"title": "6. Wenn etwas versagt",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Während einer Installation stoppt und entfernt ein Fehler die unvollständigen Container, die die Operation erstellt hat, und die private Bridge, wenn die Operation sie erstellt hat. Ein Stack wird nicht als gültig veröffentlicht, bis die gesamte Sequenz beendet ist."
|
||||
},
|
||||
{
|
||||
"p": "Ein Update ist transaktional: Alle Images werden zuerst vorbereitet, dann stoppt der Stapel, jedes Mitglied wird gesichert und das Backup verifiziert, und nur dann werden alle Rootfs ersetzt. Mitglieder beginnen eins nach dem anderen mit ihrem Gesundheitscheck; Wenn einer fehlschlägt, wird jedes Mitglied aus dem gleichen Backup-Satz wiederhergestellt, so dass die Datenbank und die Anwendung niemals zu verschiedenen Momenten gehören."
|
||||
},
|
||||
{
|
||||
"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": "Jedes Image vorbereiten",
|
||||
"stop": "Stop, Hauptelement zuerst",
|
||||
"backup": "Verifiziertes Backup jedes CT",
|
||||
"replace": "rootfs ersetzen",
|
||||
"healthy": "Alle funktionsfähig?",
|
||||
"yes": "Ja",
|
||||
"no": "Nein",
|
||||
"commit": "Verträge veröffentlichen",
|
||||
"rollback": "Jedes Mitglied wiederherstellen"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "not-assumed",
|
||||
"title": "Was ein Stack nicht beinhaltet",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Eine in einem Fluss installierte Suite, wie die Arr-Suite, ist kein abhängiger Stapel: Ihre Container haben keine Startreihenfolge zwischen ihnen.",
|
||||
"Das private Netzwerk ersetzt nicht die Authentifizierung, TLS oder die Konfiguration jeder Anwendung.",
|
||||
"Das Backup eines LXC enthält nicht die Brücke, den Haken oder die Verträge des Rests des Stapels.",
|
||||
"Prowlarr, Sonarr oder Radarr erhalten von ProxMenux keine Indexer, Profile oder Anbieter."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,305 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Daten, Pfade und Netzwerk | ProxMenux",
|
||||
"description": "So bewahrt OCI manager Apps die Daten eines OCI-Containers: Container-Datenträger, Host-Verzeichnisse, rclone-Mounts, Adressen und private Netzwerke."
|
||||
},
|
||||
"header": {
|
||||
"title": "Daten, Pfade und Netzwerk",
|
||||
"description": "Was im rootfs liegt, was beim Ersetzen erhalten bleibt, wie Container Daten gemeinsam nutzen und wie jeder Container seine Adresse erhält.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Persistenz wird vor dem Erstellen des LXC festgelegt",
|
||||
"body": "Vor dem Erstellen des Containers werden die vom Image und seiner Compose-Datei deklarierten Volumes ausgelesen. Jeder Pfad, der eine Aktualisierung überstehen muss, erhält einen vom rootfs unabhängigen Mountpoint. Das rootfs enthält damit nur die zum Image gehörenden Dateien und kann ersetzt werden."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "questions",
|
||||
"title": "Was der Installer abfragt",
|
||||
"intro": "Die Vorlage gibt die von der Anwendung benötigten Pfade vor. Jeder wird auf einem Container-Datenträger oder in einem Host-Verzeichnis abgelegt. Vor der Zusammenfassung können weitere Pfade ergänzt werden.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Benötigte Pfade",
|
||||
"body": "<code>/config</code>, <code>/data</code>, Bibliotheken, Downloads und alle von der Anwendung deklarierten Volumes werden aufgelistet."
|
||||
},
|
||||
{
|
||||
"title": "Speicherort",
|
||||
"body": "Jeder Pfad wird auf einem Container-Datenträger oder in einem vorhandenen Host-Verzeichnis abgelegt."
|
||||
},
|
||||
{
|
||||
"title": "Speicher und Größe",
|
||||
"body": "Ein Container-Datenträger wird mit der angegebenen Größe auf einem Proxmox-VE-Speicher erstellt. Die Standardinstallation verwendet <code>local-lvm</code>. Die erweiterte Installation fragt für jeden Pfad zuerst den Speicher und dann die Größe ab; vorgeschlagen wird der Speicher des rootfs. Der Datenträger erscheint als <code>vm-VMID-disk-N</code> und wird als <code>mpN</code> eingebunden."
|
||||
},
|
||||
{
|
||||
"title": "Host-Verzeichnis",
|
||||
"body": "Das Host-Verzeichnis wird über seinen Pfad angegeben. Existiert es noch nicht, wird es angelegt und dem Host-Benutzer zugeordnet, auf den der Container-Benutzer abgebildet wird."
|
||||
},
|
||||
{
|
||||
"title": "Weitere Pfade",
|
||||
"body": "Vor der Installation können weitere Zuordnungen von Host-Pfad oder Volume zu einem Pfad im Container ergänzt werden."
|
||||
},
|
||||
{
|
||||
"title": "Zusammenfassung",
|
||||
"body": "Vor dem Erstellen des CT wird die vollständige Pfadzuordnung angezeigt und im Instanzvertrag gespeichert."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "options",
|
||||
"title": "Die beiden persistenten Speicherorte",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Eigenschaft",
|
||||
"Container-Datenträger",
|
||||
"Host-Verzeichnis"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"In der Konfiguration",
|
||||
"<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>",
|
||||
"<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"
|
||||
],
|
||||
[
|
||||
"Containersicherung (vzdump)",
|
||||
"Mit <code>backup=1</code> enthalten",
|
||||
"Nicht enthalten"
|
||||
],
|
||||
[
|
||||
"Größe",
|
||||
"Festgelegt; durch Vergrößern des Mountpoints erweiterbar",
|
||||
"Der freie Platz im Dateisystem oder Dataset des Hosts"
|
||||
],
|
||||
[
|
||||
"Andere Container",
|
||||
"Nur vom zugehörigen Container eingebunden",
|
||||
"Dasselbe Verzeichnis kann in mehrere Container eingebunden werden"
|
||||
],
|
||||
[
|
||||
"Snapshots und Wiederherstellung",
|
||||
"Von Proxmox VE zusammen mit dem CT verwaltet",
|
||||
"Im Speicher des Hosts verwaltet"
|
||||
],
|
||||
[
|
||||
"Beim Entfernen der Anwendung",
|
||||
"Wird mit dem Container gelöscht",
|
||||
"Bleibt mit seinem Inhalt erhalten"
|
||||
],
|
||||
[
|
||||
"Beim Verschieben des CT auf einen anderen Knoten",
|
||||
"Wird mit dem CT verschoben",
|
||||
"Derselbe Pfad muss auf dem anderen Knoten vorhanden sein"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Das rootfs ist den Binärdateien und dem Inhalt des Images vorbehalten. Eine Aktualisierung oder Neuerstellung ersetzt es, ohne eine der beiden Arten von Mountpoints anzutasten."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Beispiel: ein Container mit beiden Speicherorten",
|
||||
"blocks": [
|
||||
{
|
||||
"code": {
|
||||
"title": "Jellyfin als CT 151 auf local-lvm installiert (Auszug)",
|
||||
"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": "Eine Aktualisierung oder Neuerstellung ersetzt nur das rootfs: <code>mp0</code> bewahrt Benutzer, Bibliotheken und Einstellungen, während <code>mp1</code> weiterhin dieselben Medien bereitstellt. Die Wiederherstellung der CT-Sicherung stellt <code>/config</code> wieder her. Das Medienverzeichnis wird bei Bedarf aus der Sicherung des Host-Speichers wiederhergestellt."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Vertrag",
|
||||
"detail": "/config"
|
||||
},
|
||||
{
|
||||
"label": "Speicherort",
|
||||
"detail": "Container-Datenträger\noder Host-Verzeichnis"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "Für die Anwendung\nimmer /config"
|
||||
}
|
||||
],
|
||||
"caption": "Die Anwendung sieht den vom Image vorgegebenen Pfad. Nur der Speicherort ändert sich."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "shared",
|
||||
"title": "Ein Host-Verzeichnis, mehrere 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": "Host-Verzeichnis",
|
||||
"config": "Eigene Konfiguration"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Jeder Container speichert seine Konfiguration auf einem eigenen Datenträger. Bibliothek oder Downloads liegen in einem gemeinsamen Host-Verzeichnis, das in allen Containern unter demselben internen Pfad eingebunden wird. So ist der Pfad, in den eine Anwendung schreibt, derselbe, aus dem eine andere liest."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "rclone",
|
||||
"title": "Cloud-Speicher über die rclone-Anwendung",
|
||||
"intro": "Der rclone-Eintrag im Katalog bietet neben der Installation auch <strong>Mount in einem vorhandenen rclone-OCI-Container aktivieren</strong>. Dabei wird ein bereits in der rclone-Weboberfläche angelegtes und autorisiertes Remote eingehängt und auf dem Host bereitgestellt. Andere Container können es als Host-Verzeichnis nutzen.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Container und Remote",
|
||||
"body": "Die VMID des rclone-Containers, der genaue Name des Remotes und optional ein Pfad darin."
|
||||
},
|
||||
{
|
||||
"title": "Mount-Name und Cache",
|
||||
"body": "Der Name des Mounts und der VFS-Cache-Modus: <code>off</code>, <code>minimal</code>, <code>writes</code> oder <code>full</code> (Standard)."
|
||||
},
|
||||
{
|
||||
"title": "Bereitgestellte Ansichten",
|
||||
"body": "Ein gemeinsames Stammverzeichnis, standardmäßig <code>/mnt/oci-shared</code>, enthält eine Ansicht mit Lese- und Schreibzugriff unter <code>/mnt/oci-shared/remotes/NAME</code> sowie eine schreibgeschützte Ansicht unter <code>/mnt/oci-shared/remotes-ro/NAME</code>."
|
||||
},
|
||||
{
|
||||
"title": "Aktivierung",
|
||||
"body": "Nach der Bestätigung wird der CT gestoppt. Sein Startbefehl und ein Proxmox-VE-Hookscript werden eingerichtet, dann wird er wieder gestartet. Der Vorgang wartet, bis beide Ansichten auf dem Host eingehängt sind."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Wenn der Mount nicht zustande kommt",
|
||||
"body": "Die vorherige Container-Konfiguration wird wiederhergestellt und der Container erneut gestartet. Eine fehlgeschlagene Aktivierung lässt rclone damit im bisherigen Zustand."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "network",
|
||||
"title": "Adressen und Netzwerke",
|
||||
"intro": "Eine einzelne Anwendung benötigt eine Adresse. Eine Anwendung aus mehreren Containern braucht zusätzlich ein stabiles Netzwerk zwischen ihren Mitgliedern.",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "network",
|
||||
"title": "Anwendung mit einem Container",
|
||||
"body": "Gewählt werden die Netzwerk-Bridge sowie DHCP oder eine feste Adresse im CIDR-Format. Der LXC hat eine eigene Adresse, und die Zusammenfassung zeigt die vollständigen Dienst-URLs."
|
||||
},
|
||||
{
|
||||
"icon": "waypoints",
|
||||
"title": "Anwendung mit mehreren Containern",
|
||||
"body": "Ein freies Subnetz wird ermittelt und eine dauerhafte private Bridge erstellt. Jedes Mitglied – Anwendung, Datenbank und Cache – erhält dort eine feste Adresse."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "LAN",
|
||||
"detail": "Erreichbare Adresse\nnur für den Hauptdienst"
|
||||
},
|
||||
{
|
||||
"label": "Haupt-LXC",
|
||||
"detail": "Web / API\nLAN + privates Netzwerk"
|
||||
},
|
||||
{
|
||||
"label": "Privates Netzwerk",
|
||||
"detail": "PostgreSQL · Valkey · ML\nfeste Adressen"
|
||||
}
|
||||
],
|
||||
"caption": "Abhängigkeiten kommunizieren über das private Netzwerk und haben keine Adresse im LAN."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Der Stack-Vertrag speichert Bridge, Subnetz, Adressen und Beziehungen zwischen den Diensten. Bei einer Aktualisierung der Anwendung wird dieselbe Topologie für alle Mitglieder wiederverwendet. ProxMenux Monitor öffnet den Hauptcontainer über seine LAN-Adresse, nicht über seine Adresse im privaten Netzwerk."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "ownership",
|
||||
"title": "Datei- und Verzeichnisbesitz",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Neue Verzeichnisse werden mit der UID und GID angelegt, auf die der unprivilegierte LXC abgebildet wird.",
|
||||
"Bei vorhandenen Verzeichnissen wird der Eigentümer nicht rekursiv geändert.",
|
||||
"Sockets, Systemdateien und sensible Pfade werden nicht als allgemeine Host-Verzeichnisse angeboten."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "backup",
|
||||
"title": "Was eine Containersicherung enthält",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Bestandteil",
|
||||
"In der vzdump-Sicherung des CT",
|
||||
"Aufbewahrungsort"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"OCI-rootfs",
|
||||
"Ja",
|
||||
"In der CT-Sicherung; außerdem aus Image und Vertrag neu erstellbar"
|
||||
],
|
||||
[
|
||||
"Container-Datenträger mit <code>backup=1</code>",
|
||||
"Ja",
|
||||
"Die CT-Sicherung"
|
||||
],
|
||||
[
|
||||
"Host-Verzeichnis",
|
||||
"Nein",
|
||||
"Die Sicherung des Host-Speichers"
|
||||
],
|
||||
[
|
||||
"Instanzvertrag",
|
||||
"Ja, die im CT mitgeführte Kopie",
|
||||
"<code>/.proxmenux/oci-record.json</code> im CT; weitere Host- und Cluster-Kopien werden separat gespeichert"
|
||||
],
|
||||
[
|
||||
"Anwendung mit mehreren Containern",
|
||||
"Jedes Mitglied in einer eigenen Sicherung",
|
||||
"Die Sicherungen aller Mitglieder sowie der Stack-Vertrag und seine Netzwerk-Bridge auf dem Host"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,172 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Automatisiertes Nachinstallationsskript | ProxMenux Dokumentation",
|
||||
"description": "Das automatisierte Nachinstallationsskript von ProxMenux führt 14 festgelegte, hardwareabhängige Optimierungen auf einem neuen Proxmox-VE-Host aus. Es gibt keine Funktionsauswahlliste; Systemaktualisierung, Bannerentfernung, manche Log2RAM-Installationen und Neustart können jedoch eine Bestätigung verlangen. Rückgängig zu machende Konfigurationsänderungen werden erfasst.",
|
||||
"ogTitle": "Automatisiertes Nachinstallationsskript | ProxMenux Dokumentation",
|
||||
"ogDescription": "14 festgelegte, hardwareabhängige Optimierungen für einen neuen Proxmox-VE-Host, mit Bestätigungen für einige Aktionen und Erfassung rückgängig zu machender Änderungen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Automatisiertes Post-Install-Skript",
|
||||
"description": "ProxMenux führt 14 festgelegte Basisoptimierungen ohne Funktionsauswahlliste aus. Einige Aktionen verlangen eine Bestätigung. Rückgängig zu machende Konfigurationsänderungen werden für Optimierungen deinstallieren erfasst; Paket-Upgrades werden nicht als reversibel beschrieben.",
|
||||
"section": "Post-Installation · Automatisiert"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wann automatisiert ausgewählt werden soll",
|
||||
"body": "Führen Sie dies auf einem frisch installierten Proxmox-Host aus, wenn Sie eine sinnvolle Basislinie wünschen, ohne Entscheidungen treffen zu müssen. Das Skript ist idempotent – es ist sicher, es zweimal auszuführen, es wendet lediglich dieselben Konfigurationen erneut an. Opt-in-Funktionen (Fastfetch, IOMMU, Ceph Repo, HA, AMD-Fixes…) sind absichtlich <strong>nicht</strong> Teil dieses Pfades; Wählen Sie sie bei Bedarf unter <link>Anpassbar</link> aus."
|
||||
},
|
||||
"applies": {
|
||||
"heading": "Was das Skript anwendet",
|
||||
"intro": "Die Optimierungen werden genau in dieser Reihenfolge angewendet. Die Spalte <em>Kategorie</em> verlinkt auf die ausführliche Dokumentation jeder Änderung in der anpassbaren Nachinstallation.",
|
||||
"headerNum": "#",
|
||||
"headerTool": "Werkzeug",
|
||||
"headerWhat": "Was es tut",
|
||||
"headerCategory": "Kategorie"
|
||||
},
|
||||
"optimizations": [
|
||||
{
|
||||
"tool": "APT-Repositorys + vollständiges Upgrade",
|
||||
"what": "Deaktiviert die Enterprise-Quellen pve-enterprise.sources und ceph.sources, erstellt eine passende No-Subscription-Quelle für den Debian-Codenamen des Hosts und führt apt update && apt full-upgrade -y aus (offizieller Proxmox-Upgrade-Befehl).",
|
||||
"category": "Grundeinstellungen",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
{
|
||||
"tool": "Subskriptionsbanner entfernen",
|
||||
"what": "Passt die Weboberfläche an, um den Hinweis „Kein gültiges Abonnement“ auszublenden. Fragt vorher nach Bestätigung; über Optimierungen deinstallieren rückgängig zu machen.",
|
||||
"category": "Anpassung",
|
||||
"categorySlug": "customization"
|
||||
},
|
||||
{
|
||||
"tool": "IPv4 erzwingen",
|
||||
"what": "Schreibt /etc/apt/apt.conf.d/99-force-ipv4, damit apt nur IPv4 nutzt und instabile IPv6-Verbindungen zu Spiegelservern umgeht.",
|
||||
"category": "Netzwerk",
|
||||
"categorySlug": "network"
|
||||
},
|
||||
{
|
||||
"tool": "Sprachpakete überspringen",
|
||||
"what": "Schreibt /etc/apt/apt.conf.d/99-disable-translations, um übersetzte Paketbeschreibungsindizes nicht mehr herunterzuladen und die Datenmenge bei apt-Updates zu verringern.",
|
||||
"category": "Grundeinstellungen",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
{
|
||||
"tool": "Erhöhung der Systemgrenzen",
|
||||
"what": "Erhöht inotify-Überwachungen, nofile/nproc-Grenzen, Kernel-Schlüsselbundgrenzen und fs.file-max über sysctl.d, limits.d, pam und systemd — ausreichend für Hosts mit vielen Containern.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Speicherabstimmung",
|
||||
"what": "Setzt vm.swappiness=10, ausgewogene Anteile noch nicht geschriebener Speicherseiten, vm.max_map_count=262144 und bei Unterstützung proaktive Speicherkompaktierung. Die Overcommit-Richtlinie des Kernels bleibt auf dem Proxmox-Standard.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Verhalten bei Kernel-Panik",
|
||||
"what": "Konfiguriert den Host so, dass er 10 Sekunden nach einer Panik / oops / Hardlockup neu startet, anstatt auf unbestimmte Zeit einzufrieren.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Netzwerk-Stack abstimmen",
|
||||
"what": "TCP Buffer Sizing, IPv4-Härtung (redirects off, rp_filter=2, martian log off), lokaler Portbereich 1024-65535, TCP MTU-Probing, RFC 1337, plus ein Helfer bei /usr/local/sbin/proxmenux-fwbr-tune, der mit einer oneshot systemd-Einheit und einer udev-Regel verdrahtet ist, so dass rp_filter=0 / log_martians=0 jedes Mal wieder auf fwbr*/fwln*/fwpr*/tap*-Schnittstellen angewendet werden, wenn Proxmox sie bei VM Start / Stop, Neustart oder Live-Migration neu erstellt.",
|
||||
"category": "Netzwerk",
|
||||
"categorySlug": "network"
|
||||
},
|
||||
{
|
||||
"tool": "Bashrc-Anpassung (root)",
|
||||
"what": "Farbige PS1, gebräuchliche Aliase (l/la/ll/ls/grep), Zeitstempel-Historie und Bash-Completion-Sourcing, alles in einem PMX_CORE_BASHRC eingezäunten Block, so dass es leicht zu entfernen ist.",
|
||||
"category": "Anpassung",
|
||||
"categorySlug": "customization"
|
||||
},
|
||||
{
|
||||
"tool": "Log2RAM (SSD-bewusst, auto)",
|
||||
"what": "Reduziert SSD-/NVMe-Verschleiß durch Verschieben von /var/log in eine tmpfs-RAM-Disk mit regelmäßiger Synchronisierung auf Datenträger. Installation aus dem Upstream-Projekt bei SSD oder NVMe als Systemplatte. Die Größe richtet sich nach dem Host-RAM (128M / 256M / 512M). Ein Schutz leert alte Journale ab 80% Belegung und kürzt stark wachsende Logs ab 92% vor dem Schreiben. Regelmäßige Synchronisierung wird geplant und journald an den verfügbaren Platz angepasst. Details unter <link>Log2RAM</link>.",
|
||||
"category": "Speicher",
|
||||
"categorySlug": "storage"
|
||||
},
|
||||
{
|
||||
"tool": "ZFS Autotrim (nur SSD)",
|
||||
"what": "Aktiviert zpool autotrim=on in jedem ZFS-Pool, dessen vdevs alle SSD/NVMe mit TRIM-Unterstützung sind (überprüft /sys/block/[dev]/queue/rotational und discard_granularity). Pools, die von HDDs unterstützt werden, werden automatisch übersprungen. Nur Pools, die tatsächlich von ProxMenux geändert wurden, werden zur Deinstallation aufgezeichnet - Pools, die Sie manuell autotrimieren, werden in Ruhe gelassen.",
|
||||
"category": "Speicher",
|
||||
"categorySlug": "storage"
|
||||
},
|
||||
{
|
||||
"tool": "Journald Größenbeschränkungen",
|
||||
"what": "Erzwingt dauerhaften Speicher, begrenzt SystemMaxUse=64M / RuntimeMaxUse=60M und aktiviert Komprimierung sowie Info-Protokollierung für Monitor. Wird bei aktivem Log2RAM automatisch übersprungen, da dieses die Anpassung selbst übernimmt.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Logrotate abstimmen",
|
||||
"what": "Setzt global daily und danach size 10M, behält 7 Rotationen und aktiviert Komprimierung sowie copytruncate. Das spätere Größenkriterium hat Vorrang; einzelne Logregeln können es überschreiben. Für Log2RAM geeignet, die Häufigkeit hängt aber von Regeln und Timer ab.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
{
|
||||
"tool": "Persistente Schnittstellennamen",
|
||||
"what": "Schreibt einen <code>/etc/systemd/network/10-proxmenux-<iface>.link</code> pro physischem NIC (jeder beginnt mit einem 'Managed by ProxMenux'-Header), der den MAC an den aktuellen Namen anheftet, so dass <code>eth0</code> / <code>enp…</code> Namen über Neustarts und neue NIC-Ergänzungen stabil bleiben.",
|
||||
"category": "Netzwerk",
|
||||
"categorySlug": "network"
|
||||
}
|
||||
],
|
||||
"hardwareTitle": "Hardwareabhängige Standardwerte",
|
||||
"hardwareBody": "Das Skript liest die Host-Hardware vor dem Anwenden von Einstellungen. Log2RAM ist standardmäßig nur auf SSD / NVMe Root-Festplatten installiert (es wird aufgefordert, wenn die Erkennung etwas anderes sagt). Die Ramdisk-Größe von Log2RAM wird aus der Gesamt-RAM (<code>≤ 8 GB → 128M</code>, <code>≤ 16 GB → 256M</code>, <code>'>' 16 GB → 512M</code>) ausgewählt. Die Journald-Limits werden an die Ramdisk-Größe angepasst, wenn Log2RAM aktiv ist, um ein Ausfüllen zu vermeiden.",
|
||||
"upgrade": {
|
||||
"heading": "Paketlisten und System aktualisieren",
|
||||
"intro": "Der erste Schritt der automatisierten Nachinstallation ist das Proxmox-Upgrade. Für einen laufenden Host innerhalb derselben Hauptversion empfiehlt Proxmox selbst:",
|
||||
"after": "Diese Zeile ist der offizielle Befehl für aktuelle Proxmox-Versionen. Das automatisierte Skript führt <strong>genau</strong> das aus und ergänzt Repository-Bereinigung und Nacharbeiten gemäß Upgrade-Anleitung — dieselben Schritte wie das separate Werkzeug <link>Proxmox-Systemaktualisierung</link>:",
|
||||
"items": [
|
||||
"Deaktiviert die Enterprise-Quellen <code>pve-enterprise.sources</code> / <code>ceph.sources</code>, entfernt alte Repository-Dateien und erstellt eine saubere No-Subscription-Quelle für den Codenamen des Hosts.",
|
||||
"Führt das Upgrade nicht interaktiv mit <code>DEBIAN_FRONTEND=noninteractive</code> und <code>--force-confdef --force-confold</code> aus. Angepasste Konfigurationsdateien bleiben erhalten, auch wenn sie sich im Upstream geändert haben.",
|
||||
"Installiert wichtige Proxmox-Pakete, wenn sie fehlen (<code>zfsutils-linux</code>, <code>proxmox-backup-restore-image</code>, <code>chrony</code>).",
|
||||
"LVM Metadaten-Sanitätsprüfung, <code>apt-get autoremove -y</code> + <code>apt-get autoclean -y</code> und eine Neustartaufforderung nur, wenn der Kernel tatsächlich geändert wurde."
|
||||
],
|
||||
"sameTitle": "Gleicher Updater, zwei Einstiegspunkte",
|
||||
"sameBody": "Das automatisierte Paket und das eigenständige <link>Proxmox System Update</link>-Dienstprogramm teilen sich die gleichen zugrunde liegenden Skripte (<code>update-pve8.sh</code> / <code>update-pve9_2.sh</code>). Verwenden Sie das Dienstprogramm selbst, wenn Sie nur den Host aktualisieren möchten, ohne den Rest der Optimierungen anzuwenden."
|
||||
},
|
||||
"endResult": {
|
||||
"heading": "Erwartetes Endergebnis",
|
||||
"body": "Am Ende sehen Sie eine Erfolgsmeldung mit Ausgaben der einzelnen Schritte und eine Neustartfrage, da einige Kerneleinstellungen einen Neustart benötigen. Sie können den Neustart verschieben; die Einstellungen gelten beim nächsten Start.",
|
||||
"imageAlt": "Automatisiertes Nachinstallationsskript — abschließende Terminalausgabe mit erfolgreich angewendeten Optimierungen"
|
||||
},
|
||||
"notDoes": {
|
||||
"heading": "Was dieses Skript nicht tut",
|
||||
"items": [
|
||||
"Automatische Zeitzonenerkennung (im Quellskript auskommentiert; bei Bedarf die anpassbare Nachinstallation verwenden).",
|
||||
"Portmapper / rpcbind deaktivieren (siehe <secLink>Sicherheit</secLink>).",
|
||||
"IOMMU / VFIO aktivieren (siehe <virtLink>Virtualisierung</virtLink>).",
|
||||
"Fastfetch / Figurine / Ceph-Repository / HA / AMD-CPU-Korrekturen installieren (siehe <optLink>Optional</optLink>).",
|
||||
"pigz installieren oder ZFS ARC abstimmen (siehe <perfLink>Leistung</perfLink> / <storLink>Speicher</storLink>)."
|
||||
]
|
||||
},
|
||||
"xshokTitle": "xshok-proxmox-Erkennung",
|
||||
"xshokBody": "Wenn der Host zuvor das <code>xshok-proxmox</code>-Skript ausgeführt hat, erkennt ProxMenux die Markierungsdatei und warnt Sie, bevor Sie fortfahren. Einige Tweaks können sich überschneiden. Das Begleitskript ist veraltet - wenn Sie sich entscheiden, trotzdem fortzufahren, überprüfen Sie <link>die Übersicht</link> für den Kontext.",
|
||||
"revert": {
|
||||
"heading": "Rückgängig machen",
|
||||
"body": "Jedes Werkzeug der Tabelle wird in <code>/usr/local/share/proxmenux/installed_tools.json</code> erfasst. Unter <link>Optimierungen deinstallieren</link> können Sie einzelne Änderungen zurücksetzen. Sicherungen geänderter Konfigurationsdateien liegen mit der Endung <code>.bak</code> neben den Originalen."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — wählen Sie im selben Katalog genau die gewünschten Funktionen."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — einzelne hier angewendete Änderungen rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Nützliche Systembefehle",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": " — Änderungen überprüfen (uptime, free, journalctl usw.)."
|
||||
},
|
||||
{
|
||||
"label": "Übersicht Post-Install",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,240 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Install: Grundeinstellungen | ProxMenux Dokumentation",
|
||||
"description": "Grundlegende Optionen nach der Installation: Wechseln Sie zu kostenlosen Proxmox-Repositories und Upgraden, erkennen Sie automatisch die Zeitzone und aktivieren Sie NTP, überspringen Sie APT-Sprachdownloads und wählen Sie aus 25 gängigen System-Dienstprogrammen zur Installation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install: Grundeinstellungen",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Fünf Grundlagen für einen neuen Proxmox-Host: auf Community-Repositories ohne Abonnement umstellen, das System vollständig aktualisieren, Zeitzone und NTP automatisch konfigurieren, APT-Sprachdownloads zur Einsparung von Bandbreite und Speicherplatz abschalten und aus 25 gängigen Systemwerkzeugen wählen."
|
||||
},
|
||||
"upgrade": {
|
||||
"heading": "Paketlisten und System aktualisieren",
|
||||
"intro": "Stellt APT auf das kostenlose Repository <em>pve-no-subscription</em> statt des abonnementpflichtigen Enterprise-Repositorys um und aktualisiert das gesamte System. Die Schritte hängen von der Proxmox-VE-Hauptversion ab; ProxMenux erkennt sie und startet das passende Skript.",
|
||||
"headerVersion": "PVE-Version",
|
||||
"headerScript": "Versionsabhängiges Startskript",
|
||||
"headerCodename": "Debian-Codename",
|
||||
"rows": [
|
||||
{
|
||||
"version": "9.x",
|
||||
"script": "update-pve9_2.sh",
|
||||
"codename": "trixie"
|
||||
},
|
||||
{
|
||||
"version": "8.x",
|
||||
"script": "update-pve8.sh",
|
||||
"codename": "bookworm"
|
||||
}
|
||||
],
|
||||
"officialTitle": "Die offizielle Proxmox Empfehlung",
|
||||
"officialBody": "Die offizielle Proxmox-Anleitung empfiehlt diese genaue Reihenfolge:",
|
||||
"officialOutro": "Das ist der übliche Befehl für Updates innerhalb der installierten Proxmox-VE-Hauptversion. Prüfen Sie die Repositories und vorgeschlagenen Paketänderungen, <em>bevor</em> Sie fortfahren. Ein Hauptversionswechsel erfordert das offizielle Migrationsverfahren.",
|
||||
"doesTitle": "Was die ProxMenux-Option tut - verifiziert gegen das Skript",
|
||||
"doesIntro": "Das ProxMenux-Update wickelt die oben genannten exakten apt-Befehle ab und fügt eine Reihe von Pre-/Post-Schritten hinzu, die Sie sich sonst von Hand merken müssten. Jedes Element unten ist, was das Dispatcher-Skript tatsächlich tut (siehe <link>Proxmox System Update</link> für die vollständige Aufschlüsselung):",
|
||||
"doesItems": [
|
||||
"<strong>Zuerst die Repositories bereinigen.</strong> Deaktiviert die Enterprise-Quellen <code>pve-enterprise.sources</code> / <code>ceph.sources</code>, entfernt alte Repository-Dateien früherer PVE-Versionen und erstellt eine saubere <code>proxmox.sources</code> für den kostenlosen Kanal <em>pve-no-subscription</em>, passend zum Debian-Codenamen: trixie für PVE 9, bookworm für PVE 8.",
|
||||
"<strong>Debian-Repositories neu schreiben</strong> mit main / updates / security und <code>non-free-firmware</code>, damit die Firmwarewarnung beim Upgrade entfällt.",
|
||||
"<strong>Führt das offizielle Upgrade aus.</strong> <code>apt-get update</code> gefolgt von <code>apt full-upgrade -y</code> (PVE 9) oder <code>apt dist-upgrade -y</code> (PVE 8), jeweils nicht interaktiv mit <code>--force-confdef --force-confold</code>, um angepasste Konfigurationsdateien zu erhalten.",
|
||||
"<strong>Installiert fehlende wichtige Pakete:</strong> <code>zfsutils-linux</code>, <code>proxmox-backup-restore-image</code>, <code>chrony</code>.",
|
||||
"<strong>LVM-Metadaten prüfen.</strong> Sucht nach VMs mit Festplatten-Passthrough, die veraltete Physical-Volume-Header auf Rohdatenträger geschrieben haben könnten. Warnt bei Auffälligkeiten, ohne sie automatisch zu beheben.",
|
||||
"<strong>Bereinigt danach:</strong> <code>apt-get autoremove -y</code> + <code>apt-get autoclean -y</code>, dann Neustartabfrage bei Kernel-Update oder vorhandener Datei <code>/var/run/reboot-required</code>."
|
||||
],
|
||||
"shortTitle": "Kurz gesagt",
|
||||
"shortBody": "Die Option führt das empfohlene <code>apt update && apt full-upgrade -y</code> aus, ergänzt die im offiziellen Leitfaden genannte Repository- und Nachbereitung und fragt am Ende nach dem Neustart. Siehe <link>Proxmox-Systemupdate</link> mit vollständigem Ablaufdiagramm — derselbe Updater ist als eigenständiges Werkzeug im Hauptmenü verfügbar.",
|
||||
"subTitle": "Nicht auf einen abonnierten Host anwenden",
|
||||
"subBody": "Wenn Sie ein Proxmox-Abonnement haben und Enterprise-Repositories behalten möchten, überspringen Sie diese Option. Sie deaktiviert Enterprise und stellt auf den Community-Kanal um. Paketupgrade und Repository-Umschreibung lassen sich unter Optimierungen deinstallieren nicht zurücksetzen. Einen späteren Kanalwechsel müssen Sie gezielt über die Repository-Konfiguration vornehmen.",
|
||||
"safetyTitle": "Sicherheitsüberprüfung nach der Aktualisierung",
|
||||
"safetyBody": "Nach dem Upgrade prüft das Skript auf Festplatten mit veralteten PV-Metadaten (Physical Volume) - ein Edge Case, der auftreten kann, wenn ein VM mit Festplattendurchgang LVM-Header auf eine Rohplatte kritzelt. Wenn etwas Verdächtiges gefunden wird, sehen Sie eine Warnung, die <code>pvs</code> zur Inspektion vorschlägt. Es wird nicht automatisch gehandelt."
|
||||
},
|
||||
"time": {
|
||||
"heading": "Zeit automatisch synchronisieren",
|
||||
"intro": "Erkennt die öffentliche IP des Servers über <code>dig myip.opendns.com @resolver1.opendns.com</code>, fragt dann <code>ipapi.co/'{'ip'}'/timezone</code>, um die passende IANA-Zeitzone nachzuschlagen, und wendet sie mit <code>timedatectl set-timezone</code> an. Endlich ermöglicht NTP mit <code>timedatectl set-ntp true</code>.",
|
||||
"depTitle": "Abhängig von zwei externen Diensten",
|
||||
"depBody": "Der Lookup basiert darauf, dass OpenDNS und <code>ipapi.co</code> erreichbar sind und ihre Antworten korrekt sind. Wenn Sie Proxmox hinter einem VPN oder einem VLAN ausführen, das aus einer anderen Region austritt, ist die automatisch erkannte Zeitzone möglicherweise falsch. In diesem Fall überspringen Sie diese Option und legen Sie die Zeitzone von Hand fest:",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "<link>Optimierungen deinstallieren</link> setzt die Zeitzone auf UTC zurück, eine sichere Vorgabe. NTP bleibt aktiv; die Uhr synchronisiert sich weiter und zeigt UTC, bis Sie eine andere Zeitzone einstellen."
|
||||
},
|
||||
"languages": {
|
||||
"heading": "Das Herunterladen zusätzlicher Sprachen überspringen",
|
||||
"intro": "Bei <code>apt update</code> kann APT übersetzte Paketbeschreibungen zusätzlich zu den Hauptmetadaten herunterladen. Die Option deaktiviert diese Downloads zur Einsparung von Bandbreite und Speicherplatz. Zuvor <strong>stellt ProxMenux sicher, dass die Locale des Hosts generiert ist</strong>: Es liest <code>/etc/default/locale</code> oder <code>/etc/environment</code>, ergänzt <code>/etc/locale.gen</code> bei Bedarf und führt <code>locale-gen</code> aus. Die Shell-Locale bleibt erhalten.",
|
||||
"writtenTitle": "Was geschrieben wird",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "Das Löschen von <code>/etc/apt/apt.conf.d/99-disable-translations</code> (manuell oder aus dem Menü Deinstallieren) stellt das Standardverhalten wieder her und APT lädt Sprachdateien erneut herunter."
|
||||
},
|
||||
"utilities": {
|
||||
"heading": "Allgemeine Systemdienstprogramme installieren",
|
||||
"intro": "Öffnet eine gruppierte Auswahlliste mit <strong>25 ausgewählten Werkzeugen</strong>. Wählen und bestätigen Sie; ProxMenux installiert sie über <code>apt</code>, überprüft das Ergebnis und zeigt eine Zusammenfassung.",
|
||||
"imageAlt": "Auswahldialog für ProxMenux-Systemwerkzeuge: Leertaste zum Auswählen, Eingabetaste zum Bestätigen",
|
||||
"reuseTitle": "Die gleiche Liste wird an anderer Stelle wiederverwendet",
|
||||
"reuseBody": "Der Katalog mit 25 Werkzeugen ist zentral definiert: <code>PROXMENUX_UTILS</code> in <code>scripts/global/utils-install-functions.sh</code>. Unter <em>Dienstprogramme und Werkzeuge → Systemwerkzeuge</em> finden Sie dieselbe Liste für spätere Installationen ohne erneuten Nachinstallationslauf.",
|
||||
"listTitle": "Was ist in der Liste",
|
||||
"groups": [
|
||||
{
|
||||
"group": "Systemüberwachung",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "htop",
|
||||
"desc": "Interaktiver Prozess-Viewer"
|
||||
},
|
||||
{
|
||||
"pkg": "btop",
|
||||
"desc": "Moderner Ressourcenmonitor (CPU, RAM, Festplatten, Netz, Prozesse)"
|
||||
},
|
||||
{
|
||||
"pkg": "s-tui",
|
||||
"desc": "Terminaloberfläche für CPU-Belastungstests und Überwachung"
|
||||
},
|
||||
{
|
||||
"pkg": "iftop",
|
||||
"desc": "Live-Bandbreitennutzung pro Verbindung"
|
||||
},
|
||||
{
|
||||
"pkg": "iotop",
|
||||
"desc": "Datenträger-I/O pro Prozess"
|
||||
},
|
||||
{
|
||||
"pkg": "iptraf-ng",
|
||||
"desc": "Interaktiver IP-LAN-Monitor"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Netzwerk",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "iperf3",
|
||||
"desc": "Messen Sie die maximal erreichbare Bandbreite zwischen Hosts"
|
||||
},
|
||||
{
|
||||
"pkg": "net-tools",
|
||||
"desc": "Legacy-Tools (ifconfig, netstat, route). Immer noch praktisch für schnelle Überprüfungen."
|
||||
},
|
||||
{
|
||||
"pkg": "ipset",
|
||||
"desc": "Verwalten Sie große IP-Sets im Kernel – nützlich mit iptables/nftables-Regeln."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Download und Archiv",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "axel",
|
||||
"desc": "Leichter paralleler Download-Beschleuniger"
|
||||
},
|
||||
{
|
||||
"pkg": "aria2",
|
||||
"desc": "Multi-Source-/Multi-Protokoll-Downloader (HTTP, FTP, BitTorrent, Metalink)"
|
||||
},
|
||||
{
|
||||
"pkg": "unzip",
|
||||
"desc": "ZIP-Archive extrahieren"
|
||||
},
|
||||
{
|
||||
"pkg": "zip",
|
||||
"desc": "ZIP-Archive erstellen"
|
||||
},
|
||||
{
|
||||
"pkg": "cabextract",
|
||||
"desc": "Extrahieren von Microsoft CAB-Archiven (bei der Arbeit mit Windows ISOs praktisch)"
|
||||
},
|
||||
{
|
||||
"pkg": "wimtools",
|
||||
"desc": "Windows-WIM-Abbilder bearbeiten (extrahieren, aufteilen, einbinden, anwenden)"
|
||||
},
|
||||
{
|
||||
"pkg": "genisoimage",
|
||||
"desc": "ISO-9660-Abbilder aus einem Verzeichnis erstellen"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Text und Dateien",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "dos2unix",
|
||||
"desc": "CRLF-Zeilenenden (Windows) in LF-Zeilenenden (Unix) umwandeln"
|
||||
},
|
||||
{
|
||||
"pkg": "grc",
|
||||
"desc": "Färbt Ausgaben von ping, traceroute, dig, tail usw. mit Syntaxhervorhebung ein"
|
||||
},
|
||||
{
|
||||
"pkg": "plocate",
|
||||
"desc": "Schnelle Dateisuche (indexiert). Führen Sie `updatedb` nach der Installation aus, um den Index zu erstellen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Remote und Sessions",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "sshpass",
|
||||
"desc": "Nicht interaktive SSH-Passwortauthentifizierung (für Skripte, nicht für den täglichen Gebrauch)"
|
||||
},
|
||||
{
|
||||
"pkg": "tmux",
|
||||
"desc": "Terminal-Multiplexer: Sitzungen abkoppeln, Fenster teilen und Sitzungen bei Verbindungsabbrüchen erhalten"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Hardware und Low-Level",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "msr-tools",
|
||||
"desc": "CPU modellspezifische Register lesen/schreiben (rdmsr, wrmsr)"
|
||||
},
|
||||
{
|
||||
"pkg": "intel-gpu-tools",
|
||||
"desc": "Intel GPU Diagnoseprogramme einschließlich `intel_gpu_top`"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Virtualisierung",
|
||||
"items": [
|
||||
{
|
||||
"pkg": "libguestfs-tools",
|
||||
"desc": "VM-Festplattenabbilder untersuchen und ändern (virt-ls, virt-cat, guestmount…)"
|
||||
},
|
||||
{
|
||||
"pkg": "chntpw",
|
||||
"desc": "Bearbeiten von Windows SAM - nützlich für die Passwortwiederherstellung auf Windows VMs, die Sie erben"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"actionTitle": "Einige davon in Aktion",
|
||||
"noBulkTitle": "Nur von ProxMenux installierte Werkzeuge werden entfernt",
|
||||
"noBulkBody": "ProxMenux erfasst nur ausgewählte Pakete, die noch nicht installiert waren. Optimierungen deinstallieren entfernt diese Pakete vollständig und lässt zuvor vorhandene Pakete bestehen. Für APT-Upgrades gibt es kein sicheres atomares Zurückrollen: Das Entfernen der Werkzeuge macht das System-Upgrade nicht rückgängig."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Proxmox-Systemupdate",
|
||||
"href": "/docs/utils/system-update",
|
||||
"tail": " — Führt den Zyklus apt update + dist-upgrade bei Bedarf erneut aus."
|
||||
},
|
||||
{
|
||||
"label": "Installationsprogramm für Systemdienstprogramme",
|
||||
"href": "/docs/utils/system-utils",
|
||||
"tail": "— Installation (oder Neuinstallation) von Dienstprogrammen einzeln nach der Nachinstallation."
|
||||
},
|
||||
{
|
||||
"label": "Befehle für Updates und Pakete",
|
||||
"href": "/docs/help-info/update-commands",
|
||||
"tail": " — APT-Referenz für die Shell."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Anpassbares Post-Install-Script | ProxMenux Dokumentation",
|
||||
"description": "Wählen Sie genau die Optimierungen aus, die ProxMenux auf Ihrem Proxmox-VE-Host anwenden soll. 10 Kategorien, etwa 35 einzelne Werkzeuge und eine Auswahl mit Kontrollkästchen. Enthält alle Funktionen des automatischen Skripts plus ausdrücklich wählbare Optionen wie IOMMU, Fastfetch, Figurine, Ceph, HA und AMD-Korrekturen.",
|
||||
"ogTitle": "Anpassbares Post-Install-Script | ProxMenux Dokumentation",
|
||||
"ogDescription": "10 Kategorien, ~35 individuelle Optimierungen. Wählen Sie genau das aus, was Sie auf einem Proxmox VE-Host wünschen. Reversible Veränderungen werden verfolgt."
|
||||
},
|
||||
"header": {
|
||||
"title": "Anpassbares Post-Install-Script",
|
||||
"description": "Wählen Sie genau die Optimierungen für Ihren Proxmox-VE-Host. ProxMenux gruppiert etwa 35 Werkzeuge in 10 Kategorien in einem gemeinsamen Auswahldialog. Dieselbe Grundlage wie Automatisch, aber mit voller Kontrolle über die angewendeten Änderungen.",
|
||||
"section": "Post-Installation · Anpassbar"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wann Sie Anpassbar wählen sollten",
|
||||
"body": "Wählen Sie diesen Weg, wenn Sie die gewünschten oder unerwünschten Anpassungen bereits kennen. Eine nach Kategorien gruppierte Auswahlliste erlaubt das Vorwählen, Abwählen und Kombinieren von Optimierungen. Einträge können später erneut angewendet werden. Reversible Konfigurationsänderungen werden für <link>Optimierungen deinstallieren</link> erfasst; Paket-Upgrades gelten nicht als reversibel."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "Vergleich mit Automatisch",
|
||||
"body": "Anpassbar umfasst das gesamte <link>automatische Skript</link>: dieselben 14 Basisoptimierungen plus zahlreiche ausdrücklich wählbare Optionen, die Automatisch absichtlich auslässt. Diese sind nur für bestimmte Hardware (AMD-Korrekturen), Hostinganbieter (OVH RTM) oder Arbeitslasten nützlich (IOMMU/VFIO, Ceph-Repository, Hochverfügbarkeit, Fastfetch, Figurine, ZFS-ARC-Anpassung, pigz, automatische ZFS-Snapshots, vzdump-Geschwindigkeitsgrenzen, Open vSwitch, TCP BBR …)."
|
||||
},
|
||||
"categoriesSection": {
|
||||
"heading": "Die 10 Kategorien",
|
||||
"body": "Das anpassbare Skript gruppiert die Optimierungen in 10 Kategorien in einem gemeinsamen Auswahldialog. Jede Kategorie hat eine eigene Dokumentationsseite. Öffnen Sie eine Karte für die Begründung, Vorgaben und Prüfschritte jeder Option."
|
||||
},
|
||||
"categories": [
|
||||
{
|
||||
"name": "Grundeinstellungen",
|
||||
"description": "APT-Quellen bereinigen, das offizielle Proxmox-Upgrade ausführen und Zeitzone, Gebietsschema sowie häufig benötigte Werkzeuge einrichten. Die Grundlage aller anderen Gruppen."
|
||||
},
|
||||
{
|
||||
"name": "System",
|
||||
"description": "Optimieren Sie das Protokollsubsystem und die Kernel-Grenzwerte für einen Host, der viele VMs und Container enthält. Behandelt journald, Logrotate, Sysctl (Speicher, Dateibeschränkungen), Kernel-Panic-Verhalten und schnelle Neustarts."
|
||||
},
|
||||
{
|
||||
"name": "Virtualisierung",
|
||||
"description": "Bereitet den Host auf erweiterte Virtualisierung vor. Installiert den passenden Gastagenten, wenn Proxmox selbst in einer unterstützten VM läuft, und aktiviert IOMMU/VFIO für die PCI-Durchreichung von GPUs, Controllern und TPUs."
|
||||
},
|
||||
{
|
||||
"name": "Netzwerk",
|
||||
"description": "Härtet und optimiert den Netzwerkstack des Hosts. Erzwingt IPv4 für APT, wendet sysctl-Härtung und TCP-Pufferanpassungen an, bietet Open vSwitch, TCP BBR und TCP Fast Open und bindet persistente Schnittstellennamen an MAC-Adressen."
|
||||
},
|
||||
{
|
||||
"name": "Speicher",
|
||||
"description": "Richten Sie die gängigen Speicher-Subsysteme von Proxmox ein: ZFS ARC Sizing, ZFS auto-snapshot, ZFS autotrim für SSD/NVMe Pools und vzdump Geschwindigkeitsbegrenzungen, um eine Sättigung der Festplatte bei Backups zu vermeiden."
|
||||
},
|
||||
{
|
||||
"name": "Sicherheit",
|
||||
"description": "Verringert die standardmäßig offene Angriffsfläche. Deaktiviert die RPC-Dienste portmapper/rpcbind, die Proxmox nicht benötigt, aber lauschen lässt."
|
||||
},
|
||||
{
|
||||
"name": "Anpassung",
|
||||
"description": "Ändern Sie das visuelle und Shell-Erlebnis des Hosts: Farben und Aliase in bashrc, MOTD-Banner und Entfernen des Abonnementbescheids in der Web-Benutzeroberfläche."
|
||||
},
|
||||
{
|
||||
"name": "Überwachung",
|
||||
"description": "Integriert den Host in OVH Real-Time Monitoring. Installiert RTM nur, wenn ProxMenux einen OVH-Server erkennt; auf anderen Hosts ändert die Option nichts."
|
||||
},
|
||||
{
|
||||
"name": "Leistung",
|
||||
"description": "Beschleunigen Sie Kompressionsvorgänge (Backups, Transfers), indem Sie gzip durch sein paralleles Gegenstück pigz ersetzen."
|
||||
},
|
||||
{
|
||||
"name": "Fakultativ",
|
||||
"description": "Nischenstücke, die nicht jeder Host braucht: AMD CPU Fixes, Fastfetch-Banner, Figurine 3D-Hostname, Indexaktualisierung des PVE Appliance Managers, Ceph Repository, High Availability Services, Log2RAM zur Reduzierung des SSD-Verschleisses und ein ZRAM-Swap-Profil."
|
||||
}
|
||||
],
|
||||
"mixTip": {
|
||||
"title": "Automatisch und Anpassbar kombinieren",
|
||||
"body": "Ein übliches Vorgehen: zuerst <strong>Automatisch</strong> für sinnvolle Grundeinstellungen, dann <strong>Anpassbar</strong> öffnen und nur benötigte Zusatzwerkzeuge wählen, etwa IOMMU für GPU-Passthrough. Änderungen werden unabhängig erfasst; Deinstallieren zeigt alle angewendeten Einträge unabhängig vom verwendeten Weg."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Automatische Nachinstallation",
|
||||
"href": "/docs/post-install/automated",
|
||||
"tail": " — sinnvolle Vorgaben ohne Rückfragen anwenden."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — jede Auswahl sauber rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Grundeinstellungen",
|
||||
"href": "/docs/post-install/basic-settings",
|
||||
"tail": "— Repos, Zeit, Sprache, Dienstprogramme."
|
||||
},
|
||||
{
|
||||
"label": "Virtualisierung",
|
||||
"href": "/docs/post-install/virtualization",
|
||||
"tail": "— IOMMU + VFIO für Passthrough."
|
||||
},
|
||||
{
|
||||
"label": "Sicherheit",
|
||||
"href": "/docs/post-install/security",
|
||||
"tailRich": " · <storageLink>Speicher</storageLink> · <networkLink>Netzwerk</networkLink> · <customLink>Anpassung</customLink> — weitere Kategorien."
|
||||
},
|
||||
{
|
||||
"label": "Übersicht nach der Installation",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,74 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Nach der Installation: Anpassung | ProxMenux-Dokumentation",
|
||||
"description": "Anpassungen im anpassbaren ProxMenux-Skript nach der Installation: farbige Bash-Eingabeaufforderung mit nützlichen Aliasen, ProxMenux-Banner in der MOTD und Entfernung des Abonnementhinweises aus der Proxmox-Weboberfläche."
|
||||
},
|
||||
"header": {
|
||||
"title": "Nach der Installation: Anpassung",
|
||||
"description": "Optische und praktische Anpassungen für den Proxmox-Host. Sie machen die Shell angenehmer und blenden den Abonnementhinweis in der Weboberfläche aus. Bashrc, MOTD und Abonnementbanner werden erfasst und lassen sich über Deinstallieren zurücksetzen.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Drei kleine, unabhängige Optionen: eine <strong>farbige Bash-Eingabeaufforderung mit Aliasen</strong> für die root-Shell, ein einzeiliges <strong>MOTD-Banner</strong> bei SSH-Anmeldung und Entfernung des <strong>Popups „Kein gültiges Abonnement“</strong>, das Proxmox bei jeder Web-Anmeldung zeigt."
|
||||
},
|
||||
"bashrc": {
|
||||
"heading": "bashrc anpassen",
|
||||
"intro": "Injiziert einen kuratierten Block in <code>/root/.bashrc</code> mit einer farbigen Eingabeaufforderung, Zeitstempel-Historie, Standard-<code>ls</code>/<code>grep</code>-Aliasen und einem <code>source</code> für die Bash-Vervollständigung. Macht das Arbeiten über SSH spürbar angenehmer und macht deutlich, auf welchem Host Sie sich befinden, wenn Sie viele Tabs geöffnet haben.",
|
||||
"writesTitle": "Was ProxMenux zu .bashrc hinzufügt",
|
||||
"writesOutro": "Der Block wird durch die <code>PMX_CORE_BASHRC</code>-Marker begrenzt. Das Ausführen des Skripts ersetzt den vorherigen Block, anstatt ihn zu duplizieren. Die ursprüngliche <code>.bashrc</code> wird einmal auf <code>/root/.bashrc.bak</code> gesichert, und eine <code>source /root/.bashrc</code>-Zeile wird an <code>/root/.bash_profile</code> angehängt, so dass die Aufforderung auch für Login-Shells gilt (z. B. nach <code>su -</code>).",
|
||||
"rootTitle": "Gilt nur für root",
|
||||
"rootBody": "Die Anpassung zielt auf die Shell des Root-Kontos ab. Andere Benutzer, die Sie auf dem Host erstellen, behalten ihre eigenen Standardeinstellungen. Wenn Sie Proxmox ausschließlich über die Web-Benutzeroberfläche verwalten und niemals die Shell verwenden, ist diese Option reine Ästhetik und Sie können sie überspringen."
|
||||
},
|
||||
"motd": {
|
||||
"heading": "Richten Sie ein benutzerdefiniertes MOTD-Banner ein",
|
||||
"intro": "Stellt <em>\"This system is optimised by: ProxMenux\"</em> an den Anfang von <code>/etc/motd</code>, der Nachricht nach erfolgreicher SSH-Anmeldung oberhalb der Shell-Eingabeaufforderung und vor den <code>update-motd</code>-Skripten. Harmlos und rein informativ — als schnelle sichtbare Bestätigung, dass ProxMenux auf diesem Host angewendet wurde.",
|
||||
"writesTitle": "Was ProxMenux schreibt",
|
||||
"writesOutro": "Bei der ersten Anwendung erfasst ProxMenux, ob <code>/etc/motd</code> existierte und speichert seinen ursprünglichen Inhalt unter <code>/usr/local/share/proxmenux</code>. Die Operation ist idempotent: Wenn die Markierungslinie bereits vorhanden ist, wird nichts hinzugefügt. Ältere Anlagen mit einem vorhandenen <code>/etc/motd.bak</code> werden in den gleichen reversiblen Zustand migriert."
|
||||
},
|
||||
"banner": {
|
||||
"heading": "Abonnementbanner entfernen",
|
||||
"intro": "Entfernt den Dialog <em>„Sie haben kein gültiges Abonnement für diesen Server“</em>, der bei jeder Anmeldung ohne Enterprise-Abonnement in der Proxmox-Weboberfläche erscheint. ProxMenux berücksichtigt die Version und startet das passende Skript für die unterschiedlichen UI-Pakete der Hauptversionen.",
|
||||
"versionTitle": "Skriptauswahl nach Version",
|
||||
"versionItems": [
|
||||
"<strong>PVE 9.x</strong> führt <code>remove-banner-pve-v3.sh</code> aus (patcht sowohl die Desktop-<code>proxmoxlib.js</code> als auch die neue Yew-basierte mobile Benutzeroberfläche).",
|
||||
"<strong>PVE 8.x</strong> führt <code>remove-banner-pve8.sh</code> aus (nur auf dem Desktop)."
|
||||
],
|
||||
"versionOutro": "Vor dem Patchen sichert ProxMenux die ursprünglichen JS/Template-Dateien mit einem Zeitstempel auf <code>/usr/local/share/proxmenux/backups/</code>. Der Deinstallationsfluss verwendet diese Backups, um die Originaldateien wiederherzustellen, und greift auf die Neuinstallation der Proxmox-Benutzeroberflächenpakete zurück, wenn das Backup fehlt oder beschädigt ist.",
|
||||
"breakTitle": "Kann nach Proxmox Updates brechen",
|
||||
"breakBody": "Proxmox-UI-Updates überschreiben regelmäßig <code>proxmoxlib.js</code>, wodurch der Hinweis zurückkehren kann. Sie können die Option danach erneut anwenden oder den Hinweis bis dahin hinnehmen. ProxMenux installiert außerdem einen APT-Hook zum automatischen erneuten Patchen bei Paket-Upgrades. Unter <link>Optimierungen deinstallieren</link> erfahren Sie, wie dieser Hook entfernt wird.",
|
||||
"legalTitle": "Rechtliche Anmerkung (immer wiederholenswert)",
|
||||
"legalBody": "Diese Option blendet nur den UI-Hinweis aus. Sie gewährt <strong>keinen</strong> Enterprise-Support oder Zugriff auf das Enterprise-Repository und ändert die Softwarelizenz nicht. Proxmox VE wird unter GNU AGPLv3 veröffentlicht. Ein Abonnement unterstützt das Projekt und ermöglicht den Enterprise-Updatekanal. Wählen Sie eine passende Supportstufe für Ihre Umgebung."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Verifizierung",
|
||||
"intro": "Nach Anwendung aller drei:",
|
||||
"reversibleTitle": "Alle drei Anpassungsänderungen werden verfolgt",
|
||||
"reversibleBody": "<link>Optimierungen deinstallieren</link> stellt <code>/root/.bashrc</code> wieder her, gibt MOTD zu seinem genauen Pre-ProxMenux-Inhalt zurück (oder entfernt die Datei, wenn sie vorher nicht existierte) und stellt die gepatchten UI-Dateien aus dem Backup wieder her oder installiert die betroffenen Proxmox-Pakete bei Bedarf neu."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Fakultativ",
|
||||
"href": "/docs/post-install/optional",
|
||||
"tail": " — Fastfetch und Figurine, weitere visuelle Anpassungen."
|
||||
},
|
||||
{
|
||||
"label": "Versionsinformationen anzeigen",
|
||||
"href": "/docs/settings/show-version-information",
|
||||
"tail": " — bestätigt, dass die Anpassungen als installiert erfasst sind."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — bashrc, motd und Abonnementhinweis zurücksetzen."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox VE Post-Install-Script — Automatisiert und anpassbar | ProxMenux",
|
||||
"description": "Überblick über die ProxMenux-Skripte nach der Installation von Proxmox VE. Das automatische Skript wendet sinnvolle Vorgaben ohne Rückfragen an. Mit dem anpassbaren Skript wählen Sie gezielt aus 10 Kategorien. Unter Optimierungen deinstallieren können unterstützte reversible Änderungen zurückgesetzt werden.",
|
||||
"ogTitle": "Proxmox VE Post-Install-Script — Automatisiert und anpassbar",
|
||||
"ogDescription": "Übliche Proxmox VE-Postinstallationsoptimierungen in 10-Kategorien anwenden - automatisiert oder à la carte mit reversiblen Optionen.",
|
||||
"twitterTitle": "Proxmox VE Post-Install-Script | ProxMenux",
|
||||
"twitterDescription": "Automatisierte und anpassbare Nachinstallationsoptimierungen für Proxmox VE – mit reversiblen Optionen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install Skripte",
|
||||
"description": "Konfigurieren Sie einen neuen Proxmox VE-Host mit den ProxMenux-Optimierungen nach der Installation. Wenden Sie die Baseline automatisch an, wählen Sie einzelne Optionen aus, aktualisieren Sie installierte Funktionen oder stellen Sie unterstützte reversible Änderungen wieder her. Paket-Upgrades werden nicht als reversibel dargestellt.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wozu dieses Menü dient",
|
||||
"body": "Direkt nach der Installation von Proxmox VE machen Dutzende kleine Änderungen den Host schneller und leichter wartbar: Repositories ohne Abonnement, sinnvolle journald-Limits und TCP-Puffer, SSD-schonende Protokollspeicherung, bashrc-Verbesserungen und mehr. ProxMenux automatisiert sie und erfasst die unterstützten reversiblen Konfigurationsänderungen."
|
||||
},
|
||||
"openingMenu": {
|
||||
"heading": "Öffnen des Menüs",
|
||||
"body": "Wählen Sie im Hauptmenü von ProxMenux <strong>Einstellungen nach der Installation von Proxmox</strong>. Folgendes wird angezeigt:",
|
||||
"imageAlt": "Menü für Skripte nach der Installation: Automatisch, Anpassbar, der bedingte Eintrag Verfügbare Updates anwenden (nur bei ausstehenden Updates) und Deinstallieren, gefolgt von Community-Skripten"
|
||||
},
|
||||
"threeWays": {
|
||||
"heading": "Vier Möglichkeiten, Optimierungen anzuwenden",
|
||||
"body": "Die vier ProxMenux-Einträge nutzen denselben Code und dasselbe Register installierter Werkzeuge, bieten aber unterschiedliche Kontrolle. <em>Verfügbare Updates anwenden</em> erscheint nur, wenn für mindestens eine installierte Optimierung eine neuere Version auf dem Datenträger liegt als die registrierte. Direkt nach der Einrichtung bleibt der Eintrag verborgen."
|
||||
},
|
||||
"routes": [
|
||||
{
|
||||
"title": "Automatisch",
|
||||
"description": "Eine sorgfältig ausgewählte Gruppe von 14 sicheren, stets nützlichen Optimierungen, die nacheinander ohne Rückfragen angewendet werden. Eine gute Vorgabe für die meisten Benutzer.",
|
||||
"bullets": [
|
||||
"Repositories ohne Abonnement + Systemupgrade",
|
||||
"Speicher, Kernel, Netzwerk-Tuning",
|
||||
"Log2RAM (automatisch auf SSD/NVMe erkannt)",
|
||||
"Journald + Logrotate-Größenbeschränkungen",
|
||||
"Persistente Schnittstellennamen"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Anpassbar",
|
||||
"description": "Etwa 35 einzelne Optimierungen in 10 Kategorien. Sie wählen genau aus, welche angewendet werden. Dieselbe Grundlage wie Automatisch, aber mit voller Kontrolle.",
|
||||
"bullets": [
|
||||
"Auswahllisten pro Kategorie",
|
||||
"Enthält alle Funktionen von Automatisch plus ausdrücklich auswählbare Optionen (IOMMU, Fastfetch, Figurine, Ceph, HA, AMD-Korrekturen …)",
|
||||
"Beliebig oft ausführbar — die Änderungen sind idempotent"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Verfügbare Updates anwenden",
|
||||
"description": "Liegt eine Nachinstallationsoptimierung (Log2Ram, Speichereinstellungen, Logrotate …) auf dem Datenträger in einer neueren Version vor als der auf dem Host erfassten, zeigt dieser Menüpunkt nur die betroffenen Optimierungen an. Er führt die jeweilige Funktion erneut aus und aktualisiert den gespeicherten Versionsstand. Alles andere bleibt unverändert.",
|
||||
"bullets": [
|
||||
"Jede Optimierung einzeln auswählen (nur geänderte)",
|
||||
"Dieselbe Auswahl ist im Monitor-Dashboard verfügbar",
|
||||
"Eine gemeinsame Benachrichtigung, wenn neue Updates verfügbar werden"
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Optimierungen deinstallieren",
|
||||
"description": "Unterstützte rückgängig machbare Änderungen werden in einer JSON-Datei erfasst und mit einer Wiederherstellungsfunktion verknüpft. Aktionen ohne sichere Rückkehrmöglichkeit, etwa ein vollständiges Paketupgrade, sind bewusst ausgeschlossen.",
|
||||
"bullets": [
|
||||
"Erkennt zuvor angewendete Optimierungen automatisch",
|
||||
"Wählt für jeden Eintrag den passenden Rückweg: aus einem vorhandenen .bak-Backup wiederherstellen, den sysctl.d-Konfigurationsausschnitt löschen, wenn keine Sicherung nötig war, oder das unveränderte Originalpaket mit --force-confnew neu installieren (z. B. beim Abonnementbanner)",
|
||||
"Neustartabfrage bei Bedarf (VFIO, persistente Namen usw.)"
|
||||
]
|
||||
}
|
||||
],
|
||||
"whichTitle": "Welches sollten Sie wählen?",
|
||||
"whichBody": "Bei einer neuen Proxmox-Installation mit sinnvollen Grundeinstellungen ohne Entscheidungen: <autoLink><strong>Automatisch</strong></autoLink>. Wenn Sie die gewünschten oder unerwünschten Anpassungen schon kennen: <customLink><strong>Anpassbar</strong></customLink>. Für eine bereits angewendete Optimierung, deren neuere Version auf dem Datenträger liegt: <updatesLink><strong>Verfügbare Updates anwenden</strong></updatesLink>. Zum sauberen Zurücksetzen früherer Änderungen: <uninstallLink><strong>Optimierungen deinstallieren</strong></uninstallLink>. Sie können kombinieren: zuerst Automatisch, dann unter Anpassbar Optionen wie Fastfetch oder IOMMU hinzufügen und später einzelne Einträge zurücksetzen.",
|
||||
"mixing": {
|
||||
"heading": "Mischen mit anderen Post-Installation-Scripts",
|
||||
"stackTitle": "Stapeln Sie nicht mehrere Post-Installationsskripte",
|
||||
"stackBody": "Das Ausführen mehrerer Post-Installationsskripte auf demselben Host kann doppelte Konfigurationsdateien, widersprüchliche sysctl-Einträge oder, schlimmer noch, defekte Netzwerke nach dem Neustart verursachen. Wenn Sie das <strong>Helper-Scripts Post Install</strong> bereits angewendet haben, können sich einige ProxMenux-Optimierungen mit dem bereits konfigurierten überschneiden. Bleiben Sie bei einem Post-Installations-Tool pro Host.",
|
||||
"xshokTitle": "xshok-proxmox: veraltet",
|
||||
"xshokBody": "Frühere Versionen von ProxMenux verwies auf <a>xshok-proxmox</a> als Begleitwerkzeug nach der Installation. Dieses Projekt ist jetzt veraltet und wird nicht mehr von ProxMenux angeboten. Wenn ein früherer Lauf von xshok-proxmox Markierungen auf dem Host hinterlassen hat, erkennt ProxMenux sie immer noch und wird Sie warnen - aber es ist nicht etwas, das Sie heute neben ProxMenux installieren sollten."
|
||||
},
|
||||
"community": {
|
||||
"heading": "Gemeinschaftsskripte",
|
||||
"body": "Das Menü bietet zwei Drittanbieterskripte aus dem Projekt <a>community-scripts</a>: <em>Proxmox VE Post Install</em> und <em>Proxmox VE Microcode</em>. Die Wrapper laden die Originalskripte mit <code>wget | bash</code> herunter und führen sie aus. ProxMenux pflegt sie nicht. Lesen Sie vor der Ausführung <link>Externe Repositories</link> für Details und Hinweise zur Vertrauenswürdigkeit."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Proxmox-Systemupdate",
|
||||
"href": "/docs/utils/system-update",
|
||||
"tail": " — hält den Host nach der Ersteinrichtung aktuell."
|
||||
},
|
||||
{
|
||||
"label": "Sicherheit",
|
||||
"href": "/docs/security",
|
||||
"tail": "- Fail2Ban + Lynis oben auf der Nachinstallationshärtung."
|
||||
},
|
||||
{
|
||||
"label": "Versionsinformationen anzeigen",
|
||||
"href": "/docs/settings/show-version-information",
|
||||
"tail": " — zeigt, welche Komponenten nach der Installation als installiert erfasst sind."
|
||||
},
|
||||
{
|
||||
"label": "Befehle für Updates und Pakete",
|
||||
"href": "/docs/help-info/update-commands",
|
||||
"tail": " — Referenz für apt / pveupgrade."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,56 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Nach der Installation: Überwachung | ProxMenux-Dokumentation",
|
||||
"description": "Überwachungsoptionen im ProxMenux anpassbaren Post-Installationsskript. Derzeit eine einzige Option: OVH Real-Time Monitoring (RTM) installieren, das nur aktiviert wird, wenn der Host als OVH-Server erkannt wird."
|
||||
},
|
||||
"header": {
|
||||
"title": "Nach der Installation: Überwachung",
|
||||
"description": "Überwachungsoptionen im anpassbaren Skript nach der Installation. Diese kleine, anbieterspezifische Kategorie installiert den OVH-Real-Time-Monitoring-Agenten auf dedizierten OVH-Servern und tut auf anderen Hosts nichts.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Zweckgebundener enger Anwendungsbereich",
|
||||
"body": "Die Überwachung nach der Installation beschränkt sich auf <strong>einen anbieterspezifischen Agenten</strong>. Allgemeine Überwachung mit Prometheus, Grafana oder node_exporter gehört nicht dazu, da Entscheidungen über einen separaten Host, Datenaufbewahrung und Alarmziele nicht in einen Ein-Klick-Schritt passen. Der mitgelieferte ProxMenux Monitor erfüllt den Großteil dieser Aufgabe ohne externen Agenten."
|
||||
},
|
||||
"ovh": {
|
||||
"heading": "Installation von OVH Real-Time Monitoring (RTM)",
|
||||
"intro": "Wenn Ihr Proxmox-Host ein dedizierter Server ist, der von <a>OVHcloud</a> gemietet wird, können Sie RTM aktivieren, um Hardware-Telemetrie (CPU-Temperatur, PSU-Status, Festplatte SMART, RAID-Controller-Zustand usw.) dem OVH-Bedienfeld auszusetzen. Dies ist der gleiche Agent, den OVH für seine eigene \"Server Monitoring\" -Funktion verwendet.",
|
||||
"decisionsTitle": "Wie ProxMenux entscheidet",
|
||||
"decisionsItems": [
|
||||
"Ermittelt die öffentliche IP-Adresse des Hosts mit <code>curl ipinfo.io/ip</code>.",
|
||||
"Sucht den besitzenden ISP mit einer <code>whois</code>-Abfrage zu <code>v4.whois.cymru.com</code> nach.",
|
||||
"Wenn das Ergebnis OVH nennt, lädt es <code>last-public-ovh-infra-yak.snap.mirrors.ovh.net/yak/archives/apply.sh</code> herunter und leitet es mit dem Puppet-Manifest für RTM v2 an <code>bash</code> weiter.",
|
||||
"Wenn im Ergebnis OVH <em>nicht</em> erwähnt wird, ist nichts installiert. Die Option ist eine No-Op."
|
||||
],
|
||||
"remoteTitle": "Remote-Skript per Pipe an bash übergeben",
|
||||
"remoteBody": "Die Installation läuft <code>wget -qO - https://…apply.sh | bash</code>. Wenn der OVH-Spiegel jemals kompromittiert wird, wird das Skript als root auf Ihrem Host ausgeführt. Bevor Sie diese Option aktivieren, entscheiden Sie, ob Sie der Spiegelkette von OVH mehr vertrauen als der Überwachung, die Sie erhalten. Für die meisten Heimlabor- oder Nicht-OVH-Benutzer sollte diese Option einfach ausgeschaltet bleiben.",
|
||||
"noOpTitle": "Nur aktivieren, wenn der Host tatsächlich bei OVH ist",
|
||||
"noOpBody": "Die Option ist ein No-Op auf Nicht-OVH-Servern, so dass das Ankreuzen auf einem Heimlabor Proxmox nichts kaputt macht. Auf einem Nicht-OVH-Host druckt das Skript <em>\"Kein OVH-Server, überspringt die RTM-Installation\"</em> und verlässt es sauber; es werden keine Pakete installiert.",
|
||||
"runsTitle": "Was ProxMenux ausführt",
|
||||
"verifyTitle": "Verifizierung",
|
||||
"verifyBody": "Auf einem echten OVH-Host sollten Sie nach einem Neustart das <a>RTM-Dashboard</a> in Ihrem OVH-Manager sehen, das mit Live-Daten für den Host gefüllt ist. Auf der Proxmox-Seite ist der RTM-Sammler ein systemd-Service - überprüfen Sie es direkt:",
|
||||
"troubleTitle": "Fehlerbehebung",
|
||||
"revertTitle": "RTM über das Menü Deinstallieren entfernen",
|
||||
"revertBody": "Ist RTM als installiert registriert, bietet Optimierungen deinstallieren einen Eintrag für OVH Real-Time Monitoring. Er führt <code>apt-get purge -y ''ovh-rtm*'' ''rtm'' ''rtm-*''</code> aus, löscht /etc/rtm und markiert RTM als deinstalliert. Puppet-Reste müssen eventuell manuell bereinigt werden; prüfen Sie RTM-spezifische Manifeste unter <code>/etc/puppet/</code>. Auf einem Nicht-OVH-Host wurden keine RTM-Pakete installiert, daher ist nichts zu entfernen."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "ProxMenux Monitor",
|
||||
"href": "/docs/settings/proxmenux-monitor",
|
||||
"tail": "- lokales Web-Dashboard für den Host (funktioniert bei jedem Anbieter, nicht nur OVH)."
|
||||
},
|
||||
{
|
||||
"label": "Nützliche Systembefehle",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": "– Referenz zur Überwachung des lokalen Hosts."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Install: Netzwerk | ProxMenux Dokumentation",
|
||||
"description": "Netzwerkoptionen im anpassbaren Nachinstallationsskript von ProxMenux: APT über IPv4 erzwingen, ein abgestimmtes sysctl-Profil anwenden, Open vSwitch installieren, TCP BBR + Fast Open aktivieren und Schnittstellennamen an MAC-Adressen binden."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install: Netzwerk",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Fünf unabhängige Netzwerkoptionen: Zwei sind einfach (<strong>APT über IPv4</strong>, <strong>Open vSwitch installieren</strong>), zwei passen das TCP-Verhalten an (<strong>Netzwerk-sysctl-Profil</strong>, <strong>BBR + Fast Open</strong>). Eine behebt ein häufiges Betriebsproblem: <strong>Schnittstellennamen fest zuweisen</strong>, damit eine neue Netzwerkkarte oder ein BIOS-Update <code>enp3s0</code> nicht in <code>enp4s0</code> umbenennt und Ihre Bridges unterbricht."
|
||||
},
|
||||
"ipv4": {
|
||||
"heading": "Erzwingen Sie, dass APT IPv4 verwendet",
|
||||
"intro": "Schreibt <code>Acquire::ForceIPv4 \"true\";</code> in <code>/etc/apt/apt.conf.d/99-force-ipv4</code>. APT weigert sich dann, IPv6 für Paketdownloads zu verwenden, auch wenn der Host über IPv6-Konnektivität verfügt.",
|
||||
"tipTitle": "Wer profitiert",
|
||||
"tipBody": "Hilfreich bei instabilen oder gegenüber IPv4 langsameren IPv6-Verbindungen oder wenn der Debian-/Proxmox-Spiegel gelegentlich über IPv6 ausfällt. Auf Hosts ohne IPv6 unproblematisch. In einem funktionierenden Dual-Stack-Netz sorgt es für vorhersehbares Verhalten: apt überrascht Sie nicht mit einer IPv6-Zeitüberschreitung."
|
||||
},
|
||||
"sysctl": {
|
||||
"heading": "Netzwerkoptimierungen anwenden",
|
||||
"intro": "Schreibt ein abgestimmtes sysctl-Profil nach <code>/etc/sysctl.d/99-network.conf</code>. Es umfasst Socket-Puffer des Kernels, ICMP-Härtung, grundlegenden Schutz vor Adressfälschung und TCP-Puffergrößen für einen Hypervisor mit vielen gleichzeitigen Datenströmen.",
|
||||
"tunedTitle": "Was angepasst wird",
|
||||
"headerArea": "Thema",
|
||||
"headerSettings": "Schlüsseleinstellungen",
|
||||
"rows": [
|
||||
{
|
||||
"area": "Socket-Puffer des Kernels",
|
||||
"settings": "<code>netdev_max_backlog=8192</code>, <code>rmem_max=16M</code>, <code>wmem_max=16M</code>, <code>somaxconn=8192</code>"
|
||||
},
|
||||
{
|
||||
"area": "ICMP-Härtung",
|
||||
"settings": "<code>icmp_echo_ignore_broadcasts=1</code>, <code>icmp_ignore_bogus_error_responses=1</code>"
|
||||
},
|
||||
{
|
||||
"area": "Routing-Sicherheit",
|
||||
"settings": "<code>accept_redirects=0</code>, <code>accept_source_route=0</code>, <code>secure_redirects=0</code>, <code>send_redirects=0</code>, <code>log_martians=0</code>"
|
||||
},
|
||||
{
|
||||
"area": "Rückwärtspfadfilter",
|
||||
"settings": "<code>rp_filter=2</code> (lockerer Modus, siehe Hinweis unten)"
|
||||
},
|
||||
{
|
||||
"area": "TCP",
|
||||
"settings": "<code>tcp_mtu_probing=1</code>, <code>tcp_rfc1337=1</code>, <code>tcp_sack=1</code>, <code>tcp_rmem=8K/87K/16M</code>, <code>tcp_wmem=8K/64K/16M</code>"
|
||||
},
|
||||
{
|
||||
"area": "Ports",
|
||||
"settings": "<code>ip_local_port_range=1024 65535</code> (Bereich kurzlebiger Ports)"
|
||||
},
|
||||
{
|
||||
"area": "Unix-Sockets",
|
||||
"settings": "<code>net.unix.max_dgram_qlen=4096</code>"
|
||||
}
|
||||
],
|
||||
"sourceOutro": "Es fügt auch <code>source /etc/network/interfaces.d/*</code> zu <code>/etc/network/interfaces</code> hinzu, wenn nicht bereits vorhanden - Standardpraxis, so dass Sie modulare Schnittstellensnippets ablegen können, ohne die Hauptdatei zu bearbeiten.",
|
||||
"fwbrTitle": "Automatisches Tuning von virtuellen Firewall Bridges",
|
||||
"fwbrBody": "Zusätzlich zum sysctl-Profil installiert ProxMenux das Hilfsskript <code>/usr/local/sbin/proxmenux-fwbr-tune</code>. Es setzt <code>rp_filter=0</code> und <code>log_martians=0</code> für die Schnittstellen <code>fwbr*</code> / <code>fwln*</code> / <code>fwpr*</code> / <code>tap*</code>, die Proxmox für VMs und Container erstellt. Die einmalig ausgeführte Unit <code>proxmenux-fwbr-tune.service</code> ruft es beim Booten auf, die Regel <code>/etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules</code> bei jedem <code>net add</code>-Ereignis mit diesen Präfixen. So werden auch bei VM-Start/-Stopp, Neustart und Live-Migration neu erstellte Schnittstellen erfasst. Direkt nach der Installation verarbeitet das Skript zudem alle bereits vorhandenen Schnittstellen.",
|
||||
"rpFilterTitle": "Warum rp_filter=2 (lose) statt 1 (streng)",
|
||||
"rpFilterBody": "Strenge Rückwärtspfadfilterung verwirft Pakete, deren Quelladresse über eine <em>andere</em> Schnittstelle erreichbar wäre. Das ist ein sinnvoller Standard für Clients, kann aber auf einem Proxmox-Host Probleme verursachen: VM-Verkehr kommt häufig über eine Bridge an und geht bei asymmetrischem Routing über einen Uplink hinaus. <code>rp_filter=2</code> (locker) verwirft nur Pakete mit tatsächlich nicht erreichbaren Quelladressen. Der Kompromiss: etwas geringere Erkennung lokaler IP-Adressfälschung, dafür ein funktionierendes VM-Netz."
|
||||
},
|
||||
"ovs": {
|
||||
"heading": "Open vSwitch installieren",
|
||||
"intro": "Installiert <code>openvswitch-switch</code> + <code>openvswitch-common</code>. Damit steht OVS als Alternative zu den standardmäßigen Linux-Bridges von Proxmox bereit. Die Installation allein ändert keine Netzwerkkonfiguration; vorhandene <code>vmbrX</code>-Bridges funktionieren weiter. Wenn Sie eine neue Bridge <em>erstellen</em>, können Sie OVS im Typ-Auswahlmenü der Proxmox-Oberfläche wählen.",
|
||||
"tipTitle": "Wenn OVS Sinn macht",
|
||||
"tipBody": "Ziehen Sie OVS in Betracht, wenn Sie <strong>VLAN-Trunking mit nicht zusammenhängenden VLAN-IDs</strong>, <strong>LACP mit LLDP in bestimmten Modi</strong>, <strong>feingranulare Programmierung von Datenflüssen</strong> (OpenFlow) oder die Zusammenarbeit mit SDN-Controllern benötigen. Für ein Heimlabor mit wenigen VLANs und einem LACP-Uplink sind Linux-Bridges + <code>vmbrX.VID</code> einfacher und gut geeignet.",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "OVS wird erfasst. <link>Optimierungen deinstallieren</link> führt <code>apt purge</code> für <code>openvswitch-switch</code> und <code>openvswitch-common</code> aus. Migrieren Sie OVS-Bridges <em>vor</em> der Deinstallation zu Linux-Bridges, sonst verlieren die VMs darauf beim nächsten Start die Netzwerkanbindung. Manuelles Äquivalent:"
|
||||
},
|
||||
"bbr": {
|
||||
"heading": "TCP BBR + TCP Fast Open aktivieren",
|
||||
"intro": "Schreibt zwei sysctl-Dateien und lädt sie neu. BBR ersetzt CUBIC durch Googles bandbreitenbasierten Überlastungsalgorithmus, der Verbindungen mit hoher Kapazität und Latenz sowie verlustbehaftete Verbindungen besser verarbeitet. TCP Fast Open (TFO) spart bei wiederholten TCP-Verbindungen einen Umlauf, indem bereits der SYN Daten mitführt.",
|
||||
"verifyTitle": "Verifizierung",
|
||||
"impactTitle": "Die Wirkung hängt von der Arbeitslast ab",
|
||||
"impactBody": "BBR ist bei hoher Latenz oder Paketverlust besonders hilfreich (kontinentübergreifende Replikation, VPN-Tunnel, mobile Clients). Im LAN zwischen zwei Rechnern am selben Switch liegt der Unterschied oft innerhalb der Messschwankungen. TFO hilft besonders bei kurzen, wiederholten HTTP-Verbindungen.",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "BBR/TFO werden erfasst. <link>Optimierungen deinstallieren</link> entfernt die zwei sysctl-Dateien (<code>/etc/sysctl.d/99-kernel-bbr.conf</code> und <code>99-tcp-fastopen.conf</code>) und lädt die übrige Konfiguration neu. Das Löschen setzt aktive Kernelwerte nicht automatisch zurück. Standards wie <code>cubic</code> und <code>tcp_fastopen=1</code> gelten nach einem Neustart, sofern keine andere Konfiguration sie überschreibt. Manuelles Äquivalent:"
|
||||
},
|
||||
"names": {
|
||||
"heading": "Schnittstellennamen (persistent)",
|
||||
"intro": "Durchläuft alle physischen Netzwerkkarten des Hosts (überspringt Loopback, Docker-veths, Bridges, TAP-Geräte, Bonds, Cilium, ZeroTier und WireGuard). Für jede schreibt es eine systemd-<code>.link</code>-Datei, die den aktuellen Namen an die aktuelle MAC-Adresse bindet. Damit hat die MAC-Zuordnung Vorrang vor der Namenslogik des Kernels.",
|
||||
"whyTitle": "Warum das wichtig ist",
|
||||
"whyItems": [
|
||||
"Das Hinzufügen oder Entfernen von PCIe-Geräten kann die Busnummerierung verschieben und <code>enp3s0</code> in <code>enp4s0</code> verwandeln. Wenn Ihr <code>/etc/network/interfaces</code> auf den alten Namen verweist, verschwindet die Brücke beim Neustart.",
|
||||
"BIOS / Firmware-Updates ändern manchmal, wie Geräte aufgezählt werden, mit dem gleichen Effekt.",
|
||||
"Das Hilfsskript schreibt <code>.link</code>-Dateien für physische Netzwerkkarten, auch für Bond-Ports, mit der MAC, die sysfs gerade meldet; bei Bond-Ports kann das die gemeinsame MAC des Bonds sein, prüfen Sie ihre Namen daher nach einem Neustart. Virtuelle Schnittstellen wie LXC-veth-Geräte und die Bond-Geräte selbst werden übersprungen. Namenskonflikte virtueller <code>hotplug</code>-NICs behebt es nicht."
|
||||
],
|
||||
"writtenTitle": "Was geschrieben wird",
|
||||
"writtenIntro": "Eine Datei pro physischem NIC, bei <code>/etc/systemd/network/10-proxmenux-<iface>.link</code>. Jede Datei beginnt mit dem Header <code># Managed by ProxMenux — do not edit</code>, so dass ProxMenux seine eigenen Dateien von benutzer- oder paketgebundenen <code>.link</code>-Dateien unterscheiden kann.",
|
||||
"writtenOutro": "<code>.link</code>-Dateien anderer Pakete oder des Benutzers bleiben erhalten; nur Dateien mit ProxMenux-Header werden verwaltet. Bei erneutem Ausführen gleicht die Funktion ihren Bestand ab: Sie liest <code>MACAddress=</code> aus jeder <code>10-proxmenux-*.link</code> und entfernt Dateien, deren MAC unter <code>/sys/class/net/</code> nicht mehr vorkommt. Dateien älterer ProxMenux-Versionen im Format <code>10-<iface>.link</code> werden beim ersten Lauf automatisch migriert.",
|
||||
"pveTitle": "PVE 9 vs PVE 8",
|
||||
"pveBody": "Das Skript nutzt systemd-<code>.link</code>-Dateien für feste Namen. Auf Proxmox VE 9 lädt es danach zusätzlich udev-Regeln neu, damit eine bereits festgelegte NIC, die erneut angeschlossen oder erkannt wird, ihre Regel ohne Neustart übernimmt. Prüfen Sie vorhandene Schnittstellen nach einem Neustart auf PVE 8 und PVE 9. Der Host bleibt bei <code>ifupdown2</code>. In beiden Fällen setzt das Skript das Neustart-Flag, damit die anpassbare Nachinstallation danach fragt.",
|
||||
"reviewTitle": "Überprüfen Sie zuerst bestehende /etc/network/interfaces",
|
||||
"reviewBody": "Verweist die ältere Konfiguration in <code>/etc/network/interfaces</code> auf automatisch vom Kernel erzeugte NIC-Namen, ist das Festschreiben der <em>aktuellen</em> Namen sinnvoll. Haben Sie die Konfiguration bereits manuell an bestimmte Namen angepasst, prüfen Sie vor dem Neustart sorgfältig, ob die festen Namen mit der interfaces-Datei übereinstimmen.",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "<link>Optimierungen deinstallieren</link> löscht nur <code>10-proxmenux-*.link</code>-Dateien mit ProxMenux-Header aus <code>/etc/systemd/network/</code>. Jede vom Benutzer oder anderen Paketen hinzugefügte <code>.link</code>-Datei bleibt erhalten. Beim nächsten Neustart gilt wieder das Standard-Namensverhalten von systemd."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Netzwerkmanagement",
|
||||
"href": "/docs/network",
|
||||
"tail": " — Diagnose, Bridge-Analyse und geführte Reparaturen."
|
||||
},
|
||||
{
|
||||
"label": "Persistente Schnittstellennamen",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": " — dieselbe Funktion später als eigener Menüpunkt; verwenden Sie eine der beiden Möglichkeiten."
|
||||
},
|
||||
{
|
||||
"label": "Referenz der Netzwerkbefehle",
|
||||
"href": "/docs/help-info/network-commands",
|
||||
"tail": " — ip, ss, ethtool, sysctl."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — diese Netzwerkänderungen rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,177 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "ProxMenux Post-Install: Optionale Einstellungen",
|
||||
"description": "Anleitung zu optionalen Einstellungen im ProxMenux-Skript nach der Installation für zusätzliche Proxmox VE-Funktionen und -Optimierungen.",
|
||||
"ogTitle": "ProxMenux Post-Install: Optionale Einstellungen",
|
||||
"ogDescription": "Anleitung zu optionalen Einstellungen im ProxMenux-Skript nach der Installation für zusätzliche Proxmox VE-Funktionen und -Optimierungen.",
|
||||
"ogImageAlt": "ProxMenux Optionale Einstellungen nach der Installation"
|
||||
},
|
||||
"title": "Optionale Einstellungen",
|
||||
"intro": "Die Kategorie <strong>Optionale Einstellungen</strong> bietet zusätzliche Funktionen und Optimierungen für Ihre Proxmox-VE-Installation. Sie sind nicht unbedingt erforderlich, können aber in bestimmten Situationen die Fähigkeiten des Systems erweitern.",
|
||||
"available": "Verfügbare optionale Funktionen",
|
||||
"stepLabel": "Schritt",
|
||||
"ceph": {
|
||||
"title": "Aktuelle Ceph Unterstützung hinzufügen",
|
||||
"intro": "Diese Option installiert die neueste Ceph-Speichersystemunterstützung für Proxmox VE. Ceph ist ein verteiltes Speichersystem, das hohe Leistung, Zuverlässigkeit und Skalierbarkeit bietet.",
|
||||
"doesIntro": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Fügt das Ceph-Repository zu Ihrem System hinzu",
|
||||
"Paketlisten aktualisieren",
|
||||
"Installiert Ceph-Pakete mit dem Befehl 'pveceph install'",
|
||||
"Überprüft die Installation"
|
||||
],
|
||||
"howUse": "Verwendung: Nach der Installation können Sie den Ceph-Speicher mit der Proxmox VE-Weboberfläche oder den Befehlszeilentools konfigurieren und verwalten.",
|
||||
"automates": "Diese Anpassung automatisiert die folgenden Befehle:"
|
||||
},
|
||||
"amd": {
|
||||
"title": "AMD-CPU-Korrekturen anwenden",
|
||||
"intro": "Diese Option wendet spezifische Korrekturen für AMD EPYC und Ryzen CPUs an, um die Stabilität und Kompatibilität zu verbessern.",
|
||||
"doesIntro": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Erkennen, ob ein AMD EPYC oder Ryzen CPU vorhanden ist",
|
||||
"Wendet den Kernelparameter 'idle=nomwait' an, um zufällige Abstürze zu verhindern (über /etc/kernel/cmdline auf systemd-Boot-Hosts oder /etc/default/grub auf GRUB-Hosts — mit einem .bak des Originals)",
|
||||
"Konfiguriert KVM, um bestimmte MSRs (Model Specific Registers) für eine bessere Windows-Gastkompatibilität zu ignorieren"
|
||||
],
|
||||
"howUse": "Verwendung: Diese Fixes werden automatisch angewendet und erfordern einen Systemneustart.",
|
||||
"automates": "Diese Anpassung automatisiert die folgenden Befehle:"
|
||||
},
|
||||
"ha": {
|
||||
"title": "Hochverfügbarkeitsdienste ermöglichen",
|
||||
"intro": "Diese Option ermöglicht High Availability (HA)-Dienste in Proxmox VE und ermöglicht ein automatisches Failover von VMs und Containern im Falle eines Knotenausfalls.",
|
||||
"doesIntro": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Aktiviert und startet den Dienst pve-ha-lrm (Local Resource Manager)",
|
||||
"Aktiviert und startet den pve-ha-crm (Cluster Resource Manager) Service",
|
||||
"Aktiviert und startet den corosync-Dienst für die Clusterkommunikation"
|
||||
],
|
||||
"howUse": "Verwendung: Nach Aktivierung dieser Dienste können Sie HA-Gruppen und -Ressourcen in der Proxmox VE-Weboberfläche konfigurieren.",
|
||||
"automates": "Diese Anpassung automatisiert die folgenden Befehle:"
|
||||
},
|
||||
"pveam": {
|
||||
"title": "Proxmox VE Appliance Manager aktualisieren",
|
||||
"intro": "Aktualisiert den lokalen Index der Containervorlagen, den <code>pveam</code> in der Proxmox-Oberfläche bereitstellt. So ist die Liste der verfügbaren Softwarevorlagen beim nächsten Erstellen eines LXC aktuell.",
|
||||
"doesIntro": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Führt <code>pveam update</code> gegen die Proxmox-Spiegelserver aus, um den aktuellen Katalog der Softwarevorlagen abzurufen",
|
||||
"Füllt die Liste der Softwarevorlagen in der Weboberfläche beim Erstellen eines Containers"
|
||||
],
|
||||
"howUse": "Verwendung: Einmal ausführen, wenn die Vorlagenliste in der Oberfläche veraltet wirkt oder Sie den Spiegelserver gewechselt haben. Es lädt nur den Katalogindex herunter, nicht die Vorlagen selbst.",
|
||||
"automates": "Diese Anpassung automatisiert den folgenden Befehl:"
|
||||
},
|
||||
"fastfetch": {
|
||||
"title": "Installieren und Konfigurieren von Fastfetch",
|
||||
"intro": "Diese Option installiert und konfiguriert leise Fastfetch, ein Systeminformationstool, das Systemspezifikationen und ein benutzerdefiniertes Logo beim Login anzeigt.",
|
||||
"doesLabel": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Lädt und installiert die neueste Fastfetch-Version ohne zusätzliche Rückfragen",
|
||||
"Ermöglicht Ihnen die Auswahl eines benutzerdefinierten Logos (<strong>ProxMenux, Proxmox, Helper-Scripts, Home-Labs-Club, Proxmology</strong> oder ein benutzerdefiniertes).",
|
||||
"Konfiguriert Fastfetch zur Anzeige von <em>\"System optimiert durch ProxMenux\"</em>",
|
||||
"Richtet Fastfetch so ein, dass es automatisch bei der Konsolenanmeldung ausgeführt wird"
|
||||
],
|
||||
"importantLabel": "Wichtig:",
|
||||
"importantBody": "Wenn Sie sich über SSH mit Proxmox verbinden, sollten Sie das <strong>Proxmox</strong>-Logo auswählen oder ein benutzerdefiniertes mit <code>jp2a</code> oder <code>img2txt</code> erstellen. Die anderen Logos werden mit <code>chafa</code> generiert und werden in einer Standard-SSH-Sitzung möglicherweise nicht korrekt angezeigt.",
|
||||
"customLabel": "Eigene Logos:",
|
||||
"customBody1": "Um ein benutzerdefiniertes Logo zu verwenden, legen Sie Ihre ASCII-Kunsttextdatei in: <code>/usr/local/share/fastfetch/logos/</code>",
|
||||
"customBody2": "Sie können benutzerdefinierte Logos mit Tools wie <code>chafa</code>, <code>jp2a</code> oder <code>img2txt</code> erstellen.",
|
||||
"customBody3": "Für beste Ergebnisse:",
|
||||
"customItems": [
|
||||
"Halten Sie die Logohöhe auf 35-Linien oder weniger, um Proportionen beizubehalten und in das Terminal zu passen",
|
||||
"Verwenden Sie <code>chafa</code> für Farblogos (in SSH-Sitzungen möglicherweise nicht korrekt angezeigt)",
|
||||
"Verwenden Sie <code>jp2a</code> oder <code>img2txt</code> für SSH-kompatible Logos"
|
||||
],
|
||||
"examplesLabel": "Beispiel Logos:",
|
||||
"logos": [
|
||||
{
|
||||
"name": "ProxMenux",
|
||||
"alt": "ProxMenux-Logo",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmenux.png"
|
||||
},
|
||||
{
|
||||
"name": "Proxmox",
|
||||
"alt": "Proxmox-Logo",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmox.png"
|
||||
},
|
||||
{
|
||||
"name": "JC Channel",
|
||||
"alt": "JC-Channel-Logo",
|
||||
"src": "/fastfetch/jc-channel.png"
|
||||
},
|
||||
{
|
||||
"name": "Helper-Scripts",
|
||||
"alt": "Helper-Scripts-Logo",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/helper-scripts.png"
|
||||
},
|
||||
{
|
||||
"name": "Home-Labs-Club",
|
||||
"alt": "Home-Labs-Club-Logo",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/home-labs-club.png"
|
||||
},
|
||||
{
|
||||
"name": "Proxmology",
|
||||
"alt": "Proxmology-Logo",
|
||||
"src": "https://macrimi.github.io/ProxMenux/fastfetch/proxmology.png"
|
||||
}
|
||||
],
|
||||
"automates": "Diese Anpassung automatisiert die folgenden Befehle:"
|
||||
},
|
||||
"figurine": {
|
||||
"title": "Installieren und Konfigurieren von Figurine",
|
||||
"intro": "Diese Option installiert und konfiguriert Figurine, ein Tool, das stilvolle ASCII-Textbanner für Ihr Terminal erstellt und Ihren Hostnamen in einem optisch ansprechenden 3D-Format anzeigt.",
|
||||
"doesLabel": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Lädt Figurine v2.1.1 von GitHub herunter und installiert die passende Version für die Host-Architektur (AMD64, ARM64 oder ARMv7)",
|
||||
"Erstellen Sie eine Begrüßungsnachricht, die Ihren Hostnamen in 3D ASCII-Kunst anzeigt, wenn Sie sich anmelden",
|
||||
"Aktualisiert eine vorhandene Figurine-Programmdatei erst nach erfolgreichem Download und Entpacken",
|
||||
"Richtet die Willkommensnachricht so ein, dass sie automatisch beim Login ausgeführt wird"
|
||||
],
|
||||
"practicalLabel": "Praktische Verwendung:",
|
||||
"practicalBody": "Beim Verwalten mehrerer Proxmox-Knoten in einem Cluster bietet Figurine eine sofortige visuelle Anzeige, an welchem Knoten Sie gerade angemeldet sind. Dies verhindert versehentliche Befehle auf dem falschen Knoten und verbessert Ihren Workflow bei der Verwaltung mehrerer Server.",
|
||||
"exampleLabel": "Beispielausgabe:",
|
||||
"imageAlt": "Figurine Beispielausgabe",
|
||||
"automates": "Diese Anpassung automatisiert den folgenden Prozess:",
|
||||
"outro": "Nach der Installation wird Ihr Hostname bei jeder Anmeldung in 3D ASCII-Kunst angezeigt, wodurch sofort klar wird, an welchem Proxmox-Knoten Sie arbeiten."
|
||||
},
|
||||
"log2ram": {
|
||||
"title": "Log2RAM installieren (SSD/NVMe Verschleißreduzierung)",
|
||||
"intro": "Log2RAM bindet <code>/var/log</code> als tmpfs-RAM-Disk ein und synchronisiert regelmäßig auf den Datenträger. Das Puffern häufiger journald-Schreibvorgänge im RAM kann SSD-Verschleiß und Datenträger-I/O verringern. Synchronisierung und sauberes Herunterfahren sichern die Logs; bei abruptem Stromausfall können Einträge seit der letzten Synchronisierung verloren gehen.",
|
||||
"upstreamLabel": "Vorgelagertes Projekt:",
|
||||
"upstreamUrl": "https://github.com/azlux/log2ram",
|
||||
"upstreamLinkLabel": "azlux/log2ram auf GitHub",
|
||||
"doesLabel": "Was ProxMenux tut:",
|
||||
"doesItems": [
|
||||
"Erkennt anhand von <code>/sys/block/<dev>/queue/rotational</code>, ob die Systemplatte SSD/NVMe ist. Bei einer rotierenden Festplatte fragt die automatisierte Variante vor der Installation nach.",
|
||||
"Klont das Originalprojekt (<code>azlux/log2ram</code>) nach <code>/tmp/log2ram</code> und passt <code>install.sh</code> an: <code>rsync -aAXv</code> wird durch <code>rsync -aXv --no-acls</code> ersetzt. Dadurch wird der Fehler <em>set_acl: Operation not supported</em> mit Exitcode 23 vermieden, der beim Verschieben von /var/log auf Dateisystemen ohne ACL-Unterstützung auftreten kann. Die systemd-Unit <code>log2ram</code> wird nach Installation aktiviert.",
|
||||
"Größe der Ramdisk auf Basis des Hosts RAM: <code>≤ 8 GB → 128M</code>, <code>≤ 16 GB → 256M</code>, <code>> 16 GB → 512M</code>. Schreibt den Wert in <code>SIZE=</code> in <code>/etc/log2ram.conf</code>.",
|
||||
"Plant eine regelmäßige Datenträgersynchronisierung über <code>/etc/cron.d/log2ram</code>: alle 1 / 3 / 6 Stunden entsprechend derselben RAM-Stufe.",
|
||||
"Installiert den Schutz <code>/usr/local/bin/log2ram-check.sh</code>, der über <code>/etc/cron.d/log2ram-auto-sync</code> alle 10 Minuten läuft. Bei 80% Belegung von <code>/var/log</code> bereinigt er journald. Bei 92% führt er zunächst <code>logrotate -f /etc/logrotate.d/proxmox-backup-api</code> aus, falls die Datei existiert: Die PBS-API-Logs sind oft der größte Platzverbraucher auf einem PBS-Host. Danach kürzt er <code>pveproxy access/error</code> und <code>pveam.log</code> vor der Synchronisierung. <code>log2ram write</code> allein kopiert tmpfs auf Disk, verkleinert es aber nicht. Der Schutz hilft gegen PVE-Ausfälle mit <em>No space left on device</em> durch unkontrolliertes Logwachstum.",
|
||||
"Erkennt den Dienst <code>proxmox-backup-server</code> auf dem Host. Falls vorhanden, erstellt es <code>/etc/logrotate.d/proxmox-backup-api</code> (20 MB × 3 Rotationen) und <code>/etc/cron.hourly/proxmox-backup-logrotate</code>, damit die häufig stark wachsenden PBS-API-Logs auch zwischen Log2RAM-Synchronisierungen begrenzt werden. Ohne PBS erfolgt keine Änderung.",
|
||||
"Stellt systemd-journald-Grenzwerte (<code>SystemMaxUse</code>, <code>RuntimeMaxUse</code>) so ein, dass sie in die Ramdisk passen, so dass ein einzelner Burst sie nicht füllen kann.",
|
||||
"Wird in <code>installed_tools.json</code> erfasst und kann über Optimierungen deinstallieren rückgängig gemacht werden."
|
||||
],
|
||||
"howUseLabel": "Wie zu verwenden:",
|
||||
"howUseBody": "Die automatisierte Variante installiert Log2RAM unbeaufsichtigt bei erkanntem SSD-/NVMe-Systemlaufwerk. Die anpassbare Variante fragt nach Größe, Intervall und Auto-Sync-Schutz. Die Abfrage nennt derzeit 90%, das erzeugte Skript nutzt jedoch 80% für Bereinigung und 92% für die oben beschriebene intensive Bereinigung.",
|
||||
"verifyLabel": "Überprüfen und Verwalten aus der Shell:",
|
||||
"verifyCode": "# Service state and configured timers\nsystemctl status log2ram\nsystemctl list-timers log2ram*\n\n# Current ramdisk usage — /var/log IS the tmpfs itself\ndf -h /var/log\n\n# Force a sync now (tmpfs → disk); does NOT shrink the tmpfs\nlog2ram write\n\n# Trigger the auto-sync guard on demand (vacuum + sync when usage is high)\n/usr/local/bin/log2ram-check.sh\n\n# Current config: SIZE, mail settings, path\ncat /etc/log2ram.conf\n\n# ProxMenux-specific cron jobs\ncat /etc/cron.d/log2ram /etc/cron.d/log2ram-auto-sync\n\n# Recent Log2RAM activity\njournalctl -u log2ram -n 50 --no-pager"
|
||||
},
|
||||
"zram": {
|
||||
"title": "ZRAM-Swap-Profil aktivieren",
|
||||
"intro": "Erstellt das komprimierte Swap-Gerät <code>/dev/zram0</code> im RAM mit <code>systemd-zram-generator</code>. Ausgelagerte Speicherseiten werden mit zstd komprimiert und im RAM gehalten, bevor Swap auf dem Datenträger genutzt wird.",
|
||||
"doesLabel": "Was sie tut:",
|
||||
"doesItems": [
|
||||
"Installiert <code>systemd-zram-generator</code>, wenn es fehlt, und zeichnet auf, ob ProxMenux es installiert hat.",
|
||||
"Schreibt <code>/etc/systemd/zram-generator.conf.d/90-proxmenux.conf</code>: ein <code>zram0</code>-Gerät mit einem Zehntel des Host-RAMs, zstd-Komprimierung (<code>zstd(level=9)</code> mit systemd-zram-generator ab 1.2.0) und Swap-Priorität 32767.",
|
||||
"Mit dieser Priorität füllt der Kernel zuerst ZRAM. Ein vorhandener Swap auf der Festplatte behält seine eigene Priorität und nimmt die Seiten, die nicht mehr in ZRAM passen.",
|
||||
"Sucht vor Änderungen nach einer anderen ZRAM-Konfiguration: aktivem zram-Swap, zram-Eintrag in <code>/etc/fstab</code>, systemd-Unit oder anderer Generatordatei. Wird eine gefunden, bricht die Option ab und lässt sie unverändert.",
|
||||
"Startet <code>dev-zram0.swap</code> und überprüft, ob das aktive Gerät mit dem Profil übereinstimmt. Wenn nicht, wird der vorherige Zustand wiederhergestellt.",
|
||||
"Wird in <code>installed_tools.json</code> erfasst und kann über Optimierungen deinstallieren rückgängig gemacht werden."
|
||||
],
|
||||
"howUseLabel": "Wie zu verwenden:",
|
||||
"howUseBody": "Diese Option gibt es nur in der anpassbaren Variante; die automatisierte wendet sie nicht an. Das Gerät wird bei jedem Start neu erstellt. Solange es aktiv ist, zeigt die Karte „Arbeitsspeicher“ in ProxMenux Monitor Kapazität, belegten Swap, Algorithmus, Kompressionsverhältnis und tatsächlichen RAM-Verbrauch.",
|
||||
"verifyLabel": "Überprüfen Sie von der Shell:",
|
||||
"verifyCode": "# Active swap devices and their priority\nswapon --show\n\n# ZRAM device: algorithm, size and compressed data\nzramctl\n\n# Profile written by ProxMenux\ncat /etc/systemd/zram-generator.conf.d/90-proxmenux.conf\n\n# State of the swap unit\nsystemctl status dev-zram0.swap"
|
||||
},
|
||||
"autoApplication": {
|
||||
"title": "Automatische Anwendung",
|
||||
"body": "Wählen Sie in der anpassbaren Variante die optionalen Funktionen nach Bedarf. Log2RAM gehört mit Hardwareerkennung auch zur automatisierten Variante; ZRAM bleibt ausschließlich anpassbar. Die Abschnitte erläutern Abfragen und Voraussetzungen."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,61 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Nach der Installation: Leistung | ProxMenux-Dokumentation",
|
||||
"description": "Leistungsoptionen im anpassbaren ProxMenux-Skript nach der Installation. Ersetzt das einsträngige gzip durch pigz (paralleles gzip) für schnellere Backups und Komprimierung auf Hosts mit mehreren Kernen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Nach der Installation: Leistung",
|
||||
"description": "Leistungsoptionen innerhalb des anpassbaren Post-Installationsskripts. Derzeit enthält diese Kategorie eine einzige Optimierung: Ersetzen von gzip durch pigz, so dass Backups und Kompression jeden CPU-Kern anstelle von einem verwenden.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Die einzige Leistungsoption hier leitet das gzip des Systems auf eine parallele Implementierung um. Andere Leistungsanpassungen wie Speicheroptimierung, E/A-Scheduling, ZFS-ARC-Größe und Kernel-Limits finden Sie in ihren Kategorien (<em>System</em>, <em>Speicher</em>), da sie andere Subsysteme betreffen."
|
||||
},
|
||||
"pigz": {
|
||||
"heading": "Verwenden Sie pigz für eine schnellere GZIP-Komprimierung",
|
||||
"intro": "Standard-<code>gzip</code> komprimiert Daten mit <strong>einem einzigen CPU-Kern</strong>. Auf modernen Proxmox-Hosts mit 8, 16 oder 32 Kernen ist das ein großer Engpass bei VM-/CT-Backups mit <code>vzdump</code>, Logrotation und allen Vorgängen über <code>gzip</code>. <a>pigz</a> ist ein direkt einsetzbarer paralleler Ersatz: dieselbe gzip-kompatible Ausgabe, aber auf alle Kerne verteilte Arbeit.",
|
||||
"doesTitle": "Was ProxMenux tut",
|
||||
"doesIntro": "Fünf Schritte, alle idempotent:",
|
||||
"doesItems": [
|
||||
"Setzt <code>pigz: 1</code> in <code>/etc/vzdump.conf</code>, so dass das Backup-Tool von Proxmox pigz nativ verwendet.",
|
||||
"Installiert das Paket <code>pigz</code> apt, falls nicht bereits vorhanden.",
|
||||
"Schreibt ein Wrapper-Script bei <code>/bin/pigzwrapper</code>, das jedes Argument an <code>/usr/bin/pigz</code> weiterleitet.",
|
||||
"Registriert eine dpkg-Umleitung für das Systemprogramm <code>gzip</code> (<code>/usr/bin/gzip</code> bei Proxmox VE 9, <code>/bin/gzip</code> bei Proxmox VE 8). Die Originaldatei bleibt daneben als <code>gzip.distrib</code> erhalten und wird durch den Wrapper ersetzt. Danach verwendet <em>alles</em>, was <code>gzip</code> aufruft — logrotate, <code>tar czf</code>, Skripte und vzdump — transparent pigz.",
|
||||
"Prüft, ob die als <code>gzip.distrib</code> gespeicherte Datei ein funktionierender Gzip ist, bevor der Wrapper installiert wird, und installiert das <code>gzip</code>-Paket zuerst neu, wenn dies nicht der Fall ist. Ein Host, der noch den früheren <code>/bin/gzip.original</code>-Swap hat, wird in die Umleitung verschoben, wenn die Option erneut angewendet wird."
|
||||
],
|
||||
"replacesTitle": "Ersetzt ein Systemprogramm",
|
||||
"replacesBody": "Ein Wrapper anstelle von <code>gzip</code> ist ungewöhnlich. Das ist sicher, da der Wrapper gzip-kompatible Ausgabe erzeugt. Skripte mit fest kodierten Pfaden, in restriktiven chroot-Umgebungen oder mit Prüfung von Binärdatei-Hashes können sich jedoch anders verhalten. Das Original bleibt als <code>gzip.distrib</code> erhalten. Durch die dpkg-Umleitung aktualisieren Updates des Pakets <code>gzip</code> und das Upgrade von Proxmox VE 8 auf 9 diese Datei, während der Wrapper erhalten bleibt.",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "Diese Optimierung wird erfasst. <link>Optimierungen deinstallieren</link> kopiert das Original aus <code>gzip.distrib</code> über den Wrapper, entfernt die Umleitung und <code>pigzwrapper</code>, kommentiert die Zeile <code>pigz</code> in <code>/etc/vzdump.conf</code> aus und führt nach erfolgreicher gzip-Prüfung <code>apt purge pigz</code> aus. Manuelles Äquivalent für Proxmox VE 9:",
|
||||
"verifyTitle": "Verifizierung",
|
||||
"verifyBody": "Nach der Anwendung sollte <code>gzip --version</code> pigz erwähnen. Ein schneller Benchmark zeigt auch den Geschwindigkeitsunterschied auf einem Multi-Core-Host:",
|
||||
"whenTitle": "Wenn das am wichtigsten ist",
|
||||
"whenBody": "Der Nutzen wächst mit der <strong>Anzahl der CPU-Kerne</strong> und der <strong>Häufigkeit der Backups</strong>. Auf einem Heimlaborrechner mit 2 Kernen und einem täglichen vzdump ist der Vorteil gering. Auf einem Produktionshost mit 16 Kernen, der jede Nacht ein Dutzend VMs sichert, kann pigz das Backup-Zeitfenster auf einen Bruchteil der Zeit von einsträngigem gzip verkürzen."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Backup- und Wiederherstellungsbefehle",
|
||||
"href": "/docs/help-info/backup-commands",
|
||||
"tailRich": " — vzdump-CLI-Referenz einschließlich der Thread-Option <code>--pigz</code>."
|
||||
},
|
||||
{
|
||||
"label": "Speicher",
|
||||
"href": "/docs/post-install/storage",
|
||||
"tail": " — Geschwindigkeitsgrenzen für vzdump und ZFS-ARC-Anpassungen."
|
||||
},
|
||||
{
|
||||
"label": "System",
|
||||
"href": "/docs/post-install/system",
|
||||
"tail": " — Anpassung von Dateideskriptoren und Speicher."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,57 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Install: Sicherheit | ProxMenux Dokumentation",
|
||||
"description": "Sicherheitsoptionen im anpassbaren ProxMenux-Skript nach der Installation. Derzeit eine Option: den Dienst portmapper/rpcbind deaktivieren, um die Angriffsfläche des Hosts zu reduzieren."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install: Sicherheit",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Die Sicherheit nach der Installation beschränkt sich auf <strong>Host-Härtung, die sicher unbeaufsichtigt angewendet werden kann</strong>: selten benötigte Dienste deaktivieren und dies über Deinstallieren wieder rückgängig machen. Aktive Sicherheitswerkzeuge wie Fail2Ban zur Einbruchsverhinderung und Lynis für Audits finden Sie unter <em>Sicherheit</em> im ProxMenux-Hauptmenü, außerhalb der Nachinstallation."
|
||||
},
|
||||
"rpcbind": {
|
||||
"heading": "Portmapper/rpcbind deaktivieren",
|
||||
"intro": "<code>rpcbind</code> (früher <code>portmap</code>) ordnet RPC-Programmnummern Netzwerkports zu. NFS und einige ältere RPC-Werkzeuge sind davon abhängig. Auf einem typischen Proxmox-Host ohne NFS-Server <strong>nutzt es nichts</strong>; aktiviert bleibt Port <code>111/tcp</code> auf allen Schnittstellen offen.",
|
||||
"whyTitle": "Warum es sich lohnt zu deaktivieren",
|
||||
"whyItems": [
|
||||
"Reduziert die Angriffsfläche des Hosts – ein Hördienst weniger, um den man sich Sorgen machen muss.",
|
||||
"Historisch missbraucht als Reflexions- / Verstärkungsvektor in DDoS-Angriffen. Durch das Deaktivieren von <code>rpcbind</code> wird dieser Verstärkungsfaktor für Ihren Host entfernt.",
|
||||
"Entfernt das Rauschen, das es in Protokollen und <code>netstat</code> / <code>ss</code> erzeugt, wodurch echte Aktivitäten leichter zu erkennen sind."
|
||||
],
|
||||
"nfsTitle": "Deaktivieren Sie dies nicht, wenn Sie NFS verwenden",
|
||||
"nfsBody": "NFS-Server <strong>und</strong> NFS-Client benötigen <code>rpcbind</code> zur Aushandlung der Ports für <code>mountd</code>, <code>statd</code>, <code>lockd</code> usw. Wenden Sie diese Option nicht an, wenn Ihr Proxmox-Host NFS-Freigaben <em>exportiert</em> oder NFS-Freigaben eines NAS <em>einbindet</em>. Das Einbinden schlägt sonst mit <code>mount.nfs: rpc.statd is not running</code> oder ähnlichen Fehlern fehl.",
|
||||
"runsTitle": "Was ProxMenux ausführt",
|
||||
"runsOutro": "Das Paket bleibt installiert. ProxMenux zeichnet den ursprünglichen aktivierten/aktiven Zustand von rpcbind.service und rpcbind.socket auf und deaktiviert und stoppt dann beide Einheiten, so dass die Socket-Aktivierung den Dienst nicht zurückbringen kann.",
|
||||
"verifyTitle": "Verifizierung",
|
||||
"verifyBody": "Bestätigen Sie nach der Anwendung, dass <code>rpcbind</code> deaktiviert ist und nichts auf Port 111 zuhört:",
|
||||
"reversibleTitle": "Wiederherstellen des ursprünglichen Service-Status",
|
||||
"reversibleBody": "Die Änderung wird in <code>installed_tools.json</code> erfasst. <link>Optimierungen deinstallieren</link> setzt jede rpcbind-Einheit auf den zuvor aufgezeichneten aktivierten/deaktivierten und aktiven/inaktiven Zustand zurück. Dabei wird nicht vorausgesetzt, dass rpcbind auf jedem Host aktiviert war."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Sicherheitsmenü",
|
||||
"href": "/docs/security",
|
||||
"tail": " — leistungsfähigere Werkzeuge: Fail2Ban (Einbruchsverhinderung) und Lynis (Audit)."
|
||||
},
|
||||
{
|
||||
"label": "Lynis",
|
||||
"href": "/docs/security/lynis",
|
||||
"tail": "– Überprüfen Sie den Host, um weitere Möglichkeiten zur Härtung zu finden."
|
||||
},
|
||||
{
|
||||
"label": "Nützliche Systembefehle",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": " — Referenz für Dienststatus, journalctl und lynis audit."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,167 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Nachinstallation: Speicher | ProxMenux Dokumentation",
|
||||
"description": "Speicheroptimierungen im anpassbaren Nachinstallationsskript von ProxMenux: ZFS-ARC-Größe nach Host-RAM, regelmäßige Snapshots mit zfs-auto-snapshot und Entfernen der vzdump-Backup-Drosselung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Installation: Speicher",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Vier Speicheroptimierungen: <strong>ZFS ARC</strong> auf einen sinnvollen Anteil des Host-RAMs abstimmen, <strong>automatische ZFS-Snapshots</strong> installieren und planen, <strong>ZFS autotrim</strong> auf SSD-/NVMe-Pools aktivieren und <strong>vzdump</strong> von Drosselungen befreien. Wählen Sie die unabhängigen Optionen passend zu Ihrem System. Als fünfte speichernahe Option reduziert <link>Log2RAM</link> SSD-/NVMe-Schreibvorgänge, indem es <code>/var/log</code> in eine RAM-Disk verschiebt. Es steht unter Optional, weil das anpassbare Menü es dort einordnet."
|
||||
},
|
||||
"trackedTitle": "Alle vier werden im Deinstallationsmenü erfasst",
|
||||
"trackedBody": "Jede Option registriert ein Werkzeug in <code>installed_tools.json</code> für <link>Optimierungen deinstallieren</link>. <code>zfs_arc</code> entfernt <code>/etc/modprobe.d/99-zfsarc.conf</code> und erstellt initramfs neu; <code>zfs_auto_snapshot</code> entfernt den Cron-Zeitplan und bietet die vollständige Paketentfernung an; <code>zfs_autotrim</code> setzt <code>autotrim=off</code> auf den zuvor aktivierten Pools; <code>vzdump_speed</code> stellt <code>/etc/vzdump.conf</code> aus der bei Installation erstellten <code>.bak</code> wieder her.",
|
||||
"arc": {
|
||||
"heading": "ZFS ARC-Größe optimieren",
|
||||
"intro": "Der <strong>Adaptive Replacement Cache (ARC)</strong> ist der ZFS-Lesecache im RAM. Proxmox-VE-Installationen ab 8.1 setzen 10% RAM mit maximal 16 GiB; ältere oder aktualisierte Hosts können abweichen. Diese Option schreibt genau diese Regel ausdrücklich (RAM/10, höchstens 16 GiB, mindestens 64 MiB) in eine eigene Datei und deckt so auch ältere oder aktualisierte Hosts ab. Prüfen Sie vorhandene Einstellungen und Arbeitslast; ein kleinerer Cache ist nicht immer schneller.",
|
||||
"sizingTitle": "Größenregeln",
|
||||
"headerRam": "Host-Arbeitsspeicher",
|
||||
"headerMax": "ARC-Obergrenze",
|
||||
"rows": [
|
||||
{
|
||||
"ram": "Formel",
|
||||
"max": "RAM / 10, höchstens 16 GiB und mindestens 64 MiB"
|
||||
},
|
||||
{
|
||||
"ram": "8 GB Host",
|
||||
"max": "≈ 819 MiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "16 GB Host",
|
||||
"max": "≈ 1.6 GiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "64 GB Host",
|
||||
"max": "≈ 6.4 GiB (RAM/10)"
|
||||
},
|
||||
{
|
||||
"ram": "≥ 160 GB Host",
|
||||
"max": "16 GiB (Obergrenze)"
|
||||
}
|
||||
],
|
||||
"after": "Die Datei <code>/etc/modprobe.d/99-zfsarc.conf</code> enthält nur <code>options zfs zfs_arc_max=…</code>. Andere ZFS-Parameter (<code>zfs_arc_min</code>, L2ARC-Vorablesen/Schreibbegrenzung, TXG-Zeitlimit) werden nicht abgestimmt. Vorher prüft ein Abgleich andere <code>*.conf</code> in <code>/etc/modprobe.d/</code> auf <code>zfs_arc_min</code> / <code>zfs_arc_max</code>, sichert sie mit Manifest unter <code>/usr/local/share/proxmenux/backups/zfs_arc/</code> und entfernt daraus die widersprüchlichen Werte <code>zfs_arc_min</code> / <code>zfs_arc_max</code> (andere Optionen dieser Zeilen bleiben erhalten). Damit legt nur die ARC-Datei von ProxMenux den Grenzwert fest. Anschließend werden <code>update-initramfs -u -k all</code> und gegebenenfalls <code>proxmox-boot-tool refresh</code> ausgeführt, damit der Grenzwert auch im initramfs für ZFS-Root-Systeme ankommt.",
|
||||
"rebootTitle": "Erfordert einen Neustart, um wirksam zu werden",
|
||||
"rebootBody": "ARC-Einstellungen werden beim Laden des Kernelmoduls <code>zfs</code> gelesen. Für ZFS-Root-Hosts erzeugt ProxMenux initramfs mit <code>update-initramfs -u -k all</code> neu und aktualisiert bei Bedarf den Bootloader mit <code>proxmox-boot-tool refresh</code>. Der neue Modulparameter wird erst nach Neustart genutzt; das entsprechende Flag wird automatisch gesetzt.",
|
||||
"safeTitle": "Sicher auf Nicht-ZFS-Hosts",
|
||||
"safeBody": "Die Funktion schreibt die Konfiguration nur, wenn <code>zpool list</code> mindestens einen importierten ZFS-Pool meldet. Auf ext4 / LVM-only Proxmox-Hosts oder auf Maschinen, auf denen die ZFS-Tools installiert sind, aber kein Pool importiert wird, ist das Ankreuzen dieser Option ein No-Op - nichts wird geschrieben.",
|
||||
"verifyTitle": "Verifizierung und manuelles Rollback"
|
||||
},
|
||||
"autoSnap": {
|
||||
"heading": "ZFS-Auto-Snapshot installieren",
|
||||
"intro": "Installiert <a>zfs-auto-snapshot</a> und schreibt die Cron-Zeitpläne für automatische Snapshots in mehreren Intervallen neu. Eine einfache zusätzliche Absicherung neben regulären vzdump-Backups.",
|
||||
"cadenceTitle": "Von ProxMenux eingerichteter Snapshot-Zeitplan",
|
||||
"headerLabel": "Etikett",
|
||||
"headerRuns": "Ausführung",
|
||||
"headerKept": "Snapshots behalten",
|
||||
"rows": [
|
||||
{
|
||||
"label": "häufig",
|
||||
"runs": "jede 15 min",
|
||||
"kept": "4"
|
||||
},
|
||||
{
|
||||
"label": "stündlich",
|
||||
"runs": "jede Stunde",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "täglich",
|
||||
"runs": "einmal täglich",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "wöchentlich",
|
||||
"runs": "einmal pro Woche",
|
||||
"kept": "1"
|
||||
},
|
||||
{
|
||||
"label": "monatlich",
|
||||
"runs": "einmal im Monat",
|
||||
"kept": "1"
|
||||
}
|
||||
],
|
||||
"conservativeTitle": "Zurückhaltende Aufbewahrungszahlen",
|
||||
"conservativeBody": "ProxMenux wird mit konservativer Aufbewahrung ausgeliefert (nur 4 häufig + 1 jedes längeren Intervalls), sodass der ZFS snapshot-Speicher nicht überlastet wird. Wenn Sie eine längere Aufbewahrung wünschen, bearbeiten Sie die Zahlen in <code>/etc/cron.d/zfs-auto-snapshot</code>, <code>/etc/cron.hourly/zfs-auto-snapshot</code> usw., nachdem das Skript ausgeführt wird.",
|
||||
"onlyZfsTitle": "Nur nützlich für ZFS Pools",
|
||||
"onlyZfsBody": "Die Installation des Pakets auf einem Ext4-Host ist harmlos, aber sinnlos - es gibt keine ZFS-Datensätze, die es zum Schnappschuss verwenden kann. Überspringen Sie diese Option, wenn Sie ZFS nicht verwenden.",
|
||||
"verifyTitle": "Verifizierung und manuelles Rollback"
|
||||
},
|
||||
"autotrim": {
|
||||
"heading": "ZFS-Autotrim aktivieren (SSD/NVMe-Pools)",
|
||||
"intro": "Aktiviert <code>autotrim</code> auf ZFS-Pools ausschließlich mit TRIM-fähigen SSDs oder NVMe-Laufwerken. Pools mit rotierenden Laufwerken werden vorsorglich übersprungen. Vorhandenes <code>autotrim=on</code> bleibt unverändert.",
|
||||
"trimTitle": "Was TRIM macht und warum es auf ZFS wichtig ist",
|
||||
"trimBody1": "SSDs und NVMe-Laufwerke arbeiten intern mit Löschblöcken, die größer als die logischen Dateisystemsektoren sind. Nach dem Löschen einer Datei weiß das Laufwerk zunächst nicht, dass die Sektoren frei sind. Seine Speicherbereinigung kopiert daher eventuell unnötige Daten beim Freimachen weiterer Blöcke. <strong>TRIM</strong> meldet dem Laufwerk freie Sektoren, damit es sie vorab löschen kann.",
|
||||
"trimBody2": "Ohne TRIM verschlechtert sich die SSD-Leistung im Laufe der Zeit, da das Laufwerk keine vorgelöschten Blöcke mehr hat und die Lösch-on-Write-Funktion ausführen muss, und die Schreibverstärkung steigt - beides verkürzt die Lebensdauer des Laufwerks. Wenn TRIM aktiviert ist, kann das Laufwerk einen gesunden Pool leerer Blöcke zum Schreiben bereithalten.",
|
||||
"trimBody3": "Mit <code>autotrim=on</code> trimmt ZFS kürzlich freigegebenen Platz im Hintergrund und bündelt Bereiche. Regelmäßiges <code>zpool trim <pool></code> ist eine Alternative. Autotrim spart einen eigenen Zeitplan, belastet Geräte aber unterschiedlich; regelmäßiges manuelles TRIM kann für einfachere Laufwerke besser sein.",
|
||||
"practicalTitle": "Warum kann die Aktivierung nützlich sein?",
|
||||
"practicalItems": [
|
||||
"<strong>Dauerhafte Schreibleistung.</strong> TRIM kann ungenutzte Blöcke effizient freigeben helfen. Nutzen und Latenzauswirkungen hängen von Gerät und Arbeitslast ab.",
|
||||
"<strong>Laufwerkslebensdauer.</strong> Weniger unnötige interne Kopien können Schreibverstärkung und NAND-Verschleiß verringern. Eine bestimmte zusätzliche Lebensdauer ist nicht garantiert.",
|
||||
"<strong>Kein geplanter Cron-Job zum Erinnern.</strong> Im Gegensatz zu einem periodischen <code>zpool trim</code> ist Autotrim Fire-and-Forget - der Pool erledigt es selbstständig."
|
||||
],
|
||||
"whenTitle": "Wann ist das notwendig?",
|
||||
"whenIntro1": "<strong>Erwägen Sie die Aktivierung</strong> auf ZFS-Pools nur mit TRIM-fähigen SSD-/NVMe-Geräten. Prüfen Sie Verhalten und Latenz; geplantes manuelles TRIM kann geeigneter sein.",
|
||||
"whenIntro2": "<strong>Das Skript überspringt es automatisch</strong> auf:",
|
||||
"whenSkipItems": [
|
||||
"Pools mit rotierenden HDD-vdevs — ein vorsichtiger Hardwarefilter dieses Skripts.",
|
||||
"Laufwerke ohne in sysfs sichtbares <code>discard_granularity</code> — meist alte SSDs ohne TRIM oder Passthrough-Pfade, über die das Betriebssystem das zugrunde liegende Gerät nicht sieht.",
|
||||
"Pools, in denen ZFS selbst die Eigenschaft nicht unterstützt meldet (selten; sehr alte Pools).",
|
||||
"Pools bereits auf <code>autotrim=on</code> eingestellt (no-op)."
|
||||
],
|
||||
"whenIntro3": "<strong>Nicht relevant für ext4-nur Hosts</strong> - es gibt nichts für ZFS zu trimmen. Die Funktion wird in diesem Fall mit einer freundlichen Nachricht beendet.",
|
||||
"recordedTitle": "Warum nur von ProxMenux geänderte Pools erfasst werden",
|
||||
"recordedBody": "Die Funktion schreibt einen Pool nur dann in seine interne Zustandsdatei (<code>/usr/local/share/proxmenux/zfs_autotrim_pools</code>), wenn er diesen Pool aktiv von <code>off</code> nach <code>on</code> umgedreht hat. Pools, die Sie vor dem Ausführen des Skripts auf Autotrim hatten, werden aus der Liste ausgeschlossen, so dass eine zukünftige Deinstallation die Einstellungen, die Sie selbst konfiguriert haben, nicht deaktiviert - nur die eigenen Änderungen von ProxMenux werden zurückgesetzt.",
|
||||
"manualTitle": "Manuelles Äquivalent (auf Ihrem Server ausgeführt)",
|
||||
"manualIntro": "Die vollständige Sequenz, die das Skript gegen jeden Pool läuft, ist von Hand replizierbar. Dies ist, was Sie eingeben würden, wenn Sie dasselbe in einem einzelnen Pool ohne ProxMenux tun möchten:",
|
||||
"verifyTitle": "Verifizierung und manuelles Rollback",
|
||||
"oneShotTitle": "Einmaliges TRIM statt Hintergrundaktivität?",
|
||||
"oneShotBody": "Einige Betreiber bevorzugen eine manuelle Trimmung während Off-Peak-Stunden anstelle von kontinuierlichen Trimmaktivitäten. Deaktivieren Sie Autotrim und planen Sie einen Cron-Job, der <code>zpool trim <pool></code> ausführt - gleiches Endziel, unterschiedliche Kadenz."
|
||||
},
|
||||
"vzdump": {
|
||||
"heading": "Erhöhen Sie die Backup-Geschwindigkeit von vzdump",
|
||||
"intro": "Schreibt bwlimit: 0 und ionice: 5 in die globale vzdump-Konfiguration. Proxmox hat bereits standardmäßig kein Bandbreitenlimit; nur ein vorhandenes Limit wird entfernt. Gegenüber ionice: 7 erhöht 5 die Best-Effort-I/O-Priorität, sofern der Scheduler sie beachtet. Das kann Gäste beeinflussen und garantiert keine schnelleren Backups.",
|
||||
"changedTitle": "Was sich in /etc/vzdump.conf ändert",
|
||||
"backupTitle": "Erster Durchlauf erstellt ein .bak von vzdump.conf",
|
||||
"backupBody": "Beim ersten Ausführen kopiert ProxMenux <code>/etc/vzdump.conf</code> vor Änderungen nach <code>/etc/vzdump.conf.bak</code>. Spätere Läufe überschreiben diese Sicherung nicht; frühere manuelle Einstellungen bleiben wiederherstellbar. <code>bwlimit</code> und <code>ionice</code> werden mit <code>sed</code> geändert, andere Optionen wie compress, pigz, tmpdir und exclude-path bleiben erhalten.",
|
||||
"skipTitle": "Wann man das überspringt",
|
||||
"skipBody": "Auf einem Host mit langsamem lokalem Speicher und VMs, die latenzempfindlich sind, kann das Entfernen der Bandbreitenobergrenze zu spürbaren Verlangsamungen bei Backups führen. Wenn Sie aus diesem Grund zuvor einen bestimmten <code>bwlimit</code> festgelegt haben, behalten Sie ihn bei - überspringen Sie diese Option.",
|
||||
"verifyTitle": "Verifizierung und manuelles Rollback"
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "ZFS Verwaltungsbefehle",
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"tail": "— zpool / zfs Referenz für ARC, Snapshots, Scrub."
|
||||
},
|
||||
{
|
||||
"label": "Speicher- und Festplattenbefehle",
|
||||
"href": "/docs/help-info/storage-commands",
|
||||
"tail": "generische Blockgeräte und Proxmox-Speicherreferenz."
|
||||
},
|
||||
{
|
||||
"label": "Backup- und Wiederherstellungsbefehle",
|
||||
"href": "/docs/help-info/backup-commands",
|
||||
"tail": " — vzdump-CLI-Referenz für Bandbreite und I/O-Priorität."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — Änderungen an ARC / vzdump rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Log2RAM",
|
||||
"href": "/docs/post-install/optional#log2ram",
|
||||
"tail": "- reduziert den Verschleiß von SSD/NVMe durch Ramdisk-Backing /var/log; dokumentiert unter Optional."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,133 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Install: System | ProxMenux Dokumentation",
|
||||
"description": "Systemoptimierungen im anpassbaren Nachinstallationsskript von ProxMenux: Größenbegrenzungen für journald und logrotate, höhere Kernel- und Dateideskriptorgrenzen, ausgewogene Speicherabstimmung, schnelle Neustarts mit kexec und Wiederherstellung nach Kernel-Panik."
|
||||
},
|
||||
"header": {
|
||||
"title": "Nach der Installation: System",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Sechs unabhängige Systemoptimierungen. Sie stimmen <strong>journald</strong> und <strong>logrotate</strong> ab, damit Logs nicht die Platte füllen, erhöhen <strong>Kernel- und Dateideskriptorgrenzen</strong> für Anwendungen mit vielen offenen Dateien, sorgen für <strong>ausgewogene Speichernutzung</strong> auf einem Virtualisierungshost, ergänzen <strong>kexec</strong> für Neustarts ohne BIOS und konfigurieren <strong>automatische Wiederherstellung</strong> bei Kernel-Panik. Alle sechs werden erfasst und sind über das Deinstallationsmenü rückgängig zu machen."
|
||||
},
|
||||
"journald": {
|
||||
"heading": "journald optimieren",
|
||||
"intro": "Schreibt <code>/etc/systemd/journald.conf</code> mit sinnvollen Standardwerten neu, damit das systemd-Journal nicht nach und nach die Root-Partition füllt. Startet dann <code>systemd-journald</code> neu und bereinigt vorhandene Protokolle.",
|
||||
"keyTitle": "Schlüsselwerte",
|
||||
"keyItems": [
|
||||
"<code>Storage=persistent</code> — Protokolle auf der Festplatte über Neustarts halten.",
|
||||
"<code>SystemMaxUse=64M</code> / <code>RuntimeMaxUse=60M</code> — Grenzen für die Datenträger- und Speichernutzung des Journals.",
|
||||
"<code>Compress=yes</code>, <code>Seal=no</code> — Logs komprimieren, kryptografische Vorwärtssicherung durch Versiegelung auslassen (spart CPU).",
|
||||
"<code>MaxLevelStore=info</code> — info und höhere Schweregrade speichern. Erforderlich für den Logbetrachter von ProxMenux Monitor und damit Fail2Ban fehlgeschlagene SSH-/Proxmox-Anmeldungen im Journal erkennt.",
|
||||
"Ratenbegrenzung: <code>1000 events / 30 s</code>, um eine Protokollflut zu vermeiden.",
|
||||
"<code>ForwardToSyslog=no</code>, <code>ForwardToWall=no</code> - Duplizieren Sie keine Nachrichten in syslog oder senden Sie sie an Konsolen."
|
||||
],
|
||||
"tipTitle": "Warum MaxLevelStore=info wichtig ist",
|
||||
"tipBody": "Ein strengerer Schweregrad wie <code>warning</code> lässt ProxMenux Monitor in allen Zeiträumen fast dieselben Einträge zeigen, weil die meisten Aktivitäten auf Info-Ebene liegen. Fail2Ban kann dadurch fehlgeschlagene Anmeldungen übersehen. Begrenzen Sie die Menge stattdessen mit <code>SystemMaxUse</code> und <code>RateLimitBurst</code>, ohne die gespeicherten Schweregrade einzuschränken."
|
||||
},
|
||||
"logrotate": {
|
||||
"heading": "Logrotate optimieren",
|
||||
"intro": "Schreibt <code>/etc/logrotate.conf</code> mit globalen Tages- und Größeneinstellungen, 7 aufbewahrten Rotationen, Komprimierung und <code>copytruncate</code> neu, damit Dienste ohne erneutes Öffnen der Logs weiterschreiben. Die spätere Größeneinstellung hat Vorrang vor täglich, sofern keine einzelne Logregel sie überschreibt. Original <code>logrotate.conf</code> wird beim ersten Anwenden nach <code>.bak</code> gesichert.",
|
||||
"tipTitle": "Für Log2RAM geeignet",
|
||||
"tipBody": "Die Anweisung <code>size 10M</code> hat Vorrang vor der vorherigen Tageseinstellung; es gilt <em>nicht</em> das zuerst eintretende Kriterium. Logrotate prüft den Grenzwert beim Ausführen, und einzelne Logregeln können globale Werte überschreiben. Für Log2RAMs RAM-basiertes <code>/var/log</code> sollten Regeln und Timerfrequenz geprüft werden, um die Belegung zu steuern."
|
||||
},
|
||||
"limits": {
|
||||
"heading": "Verschiedene Systemgrenzen erhöhen",
|
||||
"intro": "Erhöht Kernel-, systemd- und PAM-Grenzen, deren Standardwerte für Hosts mit vielen VMs, Containern und Netzwerkdiensten zu niedrig sein können.",
|
||||
"headerFile": "Datei",
|
||||
"headerSets": "Was es setzt",
|
||||
"rows": [
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-maxwatches.conf",
|
||||
"sets": "<code>fs.inotify.max_user_watches / max_user_instances / max_queued_events = 1048576</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-maxkeys.conf",
|
||||
"sets": "<code>kernel.keys.maxkeys / root_maxkeys = 1000000</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-swap.conf",
|
||||
"sets": "<code>vm.swappiness = 10</code>, <code>vm.vfs_cache_pressure = 100</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/sysctl.d/99-fs.conf",
|
||||
"sets": "<code>fs.nr_open / file-max = 2097152</code>, <code>fs.aio-max-nr = 1048576</code>"
|
||||
},
|
||||
{
|
||||
"file": "/etc/security/limits.d/99-limits.conf",
|
||||
"sets": "<code>nofile</code> und <code>nproc</code> bis 1,048,576 (unbegrenzt für root)"
|
||||
},
|
||||
{
|
||||
"file": "/etc/systemd/system.conf + user.conf",
|
||||
"sets": "<code>DefaultLimitNOFILE=1048576</code> für systemd-Dienste"
|
||||
},
|
||||
{
|
||||
"file": "/etc/pam.d/common-session + runuser-l",
|
||||
"sets": "<code>session required pam_limits.so</code>, also gelten die oben genannten für Login-Shells"
|
||||
},
|
||||
{
|
||||
"file": "/root/.profile",
|
||||
"sets": "<code>ulimit -n 1048576</code> für die Root-Shell"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Warum inotify wichtig ist",
|
||||
"tipBody": "Docker, Syncthing, Node.js-Dateibeobachter und Plex-Bibliotheksscans können <code>max_user_watches</code> ausschöpfen. Der Standard hängt von Kernel und Host-RAM ab und ist nicht immer 8192. 1M erlaubt mehr Überwachungen, ohne sie vorab anzulegen. Aktive Überwachungen benötigen Kernel-Speicher; prüfen Sie die Nutzung auf speicherknappen Hosts."
|
||||
},
|
||||
"memory": {
|
||||
"heading": "Optimieren der Speichereinstellungen",
|
||||
"intro": "Schreibt ein ausgewogenes sysctl-Profil in <code>/etc/sysctl.d/99-memory.conf</code>. Entwickelt für einen Hypervisor-Host - bevorzugt es, VM-Arbeitssets in RAM zu halten und Seiten proaktiv freizugeben, damit Zuweisungsbursts nicht zum Stillstand kommen.",
|
||||
"warnTitle": "swappiness=10 auf Hosts mit wenig freiem Speicher",
|
||||
"warnBody": "Auf einem Host mit 16 GB RAM, auf dem viele VMs ausgeführt werden, kann die Senkung der Swappiness den Kernel zu OOM-Kill-Prozessen anstelle von Swaping bringen. Wenn Sie routinemäßig OOM-Ereignisse sehen, erhöhen Sie die Swappiness nach dem Ausführen des Skripts in <code>/etc/sysctl.d/99-memory.conf</code> auf 30–60."
|
||||
},
|
||||
"kexec": {
|
||||
"heading": "Schnelle Neustarts ermöglichen (kexec)",
|
||||
"intro": "Installiert <code>kexec-tools</code> und verkabelt es, so dass Sie den Host direkt in einen neuen Kernel <em> neu starten können, ohne die BIOS/UEFI-Firmware </em> zu durchlaufen. Auf großen Servern, auf denen POST 45 bis 90 Sekunden benötigt, verwandelt sich ein Neustart von einer Kaffeepause in einige Sekunden Ausfallzeit.",
|
||||
"installsTitle": "Was ProxMenux installiert",
|
||||
"installsItems": [
|
||||
"Paket <code>kexec-tools</code> (debconf mit <code>kexec-tools/load_kexec boolean false</code> vorbeantwortet, damit apt nicht nachfragt und automatisches Laden beim Herunterfahren deaktiviert bleibt).",
|
||||
"Systemd-Einheit <code>/etc/systemd/system/kexec-pve.service</code> lädt den Proxmox-Kernel und initrd beim Booten in den Speicher, wobei die aktuelle cmdline wiederverwendet wird.",
|
||||
"Ein Aliasname in <code>/root/.bash_profile</code>: <code>reboot-quick</code> → <code>systemctl kexec</code>."
|
||||
],
|
||||
"usageIntro": "Nutzung nach dem nächsten Reboot (oder manuell <code>systemctl start kexec-pve</code>):",
|
||||
"warnTitle": "Wann man Kexec nicht benutzt",
|
||||
"warnBody": "kexec überspringt Firmware-Level Init. Wenn Sie sich auf BIOS/UEFI verlassen, um den Hardwarezustand zurückzusetzen - beispielsweise einen GPU, der Passthrough durchführt, der nur bei voller POST sauber zurückgesetzt wird, oder eine lästige HBA-Firmware - können Kexec-Neustarts diese Geräte in einem halbinitialisierten Zustand belassen. Verwenden Sie einen normalen <code>reboot</code> nach Kernel-Upgrades oder wenn Sie BIOS/UEFI Änderungen benötigen, um wirksam zu werden. <code>reboot-quick</code> ist für alltägliche Neustarts gedacht."
|
||||
},
|
||||
"panic": {
|
||||
"heading": "Neustart bei Kernel-Panic aktivieren",
|
||||
"intro": "Lässt den Kernel <strong>automatisch neu starten</strong>, statt dauerhaft am Panikbildschirm zu hängen. Besonders wichtig für entfernte Proxmox-Hosts ohne lokale Konsole: Bei blockiertem Kernel bleiben alle VMs aus, bis Sie den Host aus- und wieder einschalten können.",
|
||||
"tipTitle": "Verbinden Sie dies mit Remote-Konsolenzugriff",
|
||||
"tipBody": "Der automatische Neustart dient der Wiederherstellung, nicht der Fehlersuche. Um eine Panik zu <em>untersuchen</em>, statt nur neu zu starten, nutzen Sie <link>die kexec-Option</link> oben zusammen mit Kernel-kdump-Unterstützung, die ProxMenux nicht einrichtet. Alternativ zeichnen Sie vor Aktivierung eine serielle Konsole auf einem anderen Host auf."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Verifizierung",
|
||||
"intro": "Nach Anwendung der Systemoptimierungen:",
|
||||
"tipTitle": "Wiederherstellung und Grenzen",
|
||||
"tipBody": "Alle sechs Optionen werden in <code>installed_tools.json</code> erfasst und unter <link>Optimierungen deinstallieren</link> angeboten. Die Wiederherstellung entfernt die Konfigurationsdateien sowie kexec-Unit und Alias, schreibt journald.conf mit den systemd-Standardwerten neu und stellt logrotate.conf aus der Sicherung wieder her. Manche aktiven Grenzen brauchen eine neue Sitzung oder einen Neustart."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Nützliche Systembefehle",
|
||||
"href": "/docs/help-info/system-commands",
|
||||
"tail": "— die Änderungen überprüfen (free -h, journalctl, ulimit -a)."
|
||||
},
|
||||
{
|
||||
"label": "Leistung",
|
||||
"href": "/docs/post-install/performance",
|
||||
"tail": " — zusätzliche Systemabstimmung (pigz)."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — diese Änderungen rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,271 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Optimierungen deinstallieren | ProxMenux Dokumentation",
|
||||
"description": "Macht reversible Nachinstallationsänderungen von ProxMenux rückgängig. Registrierte Werkzeuge haben eigene Deinstallationsfunktionen, die den vorherigen Hostzustand nach Möglichkeit erhalten."
|
||||
},
|
||||
"header": {
|
||||
"title": "Optimierungen deinstallieren",
|
||||
"description": "Stellen Sie reversible Änderungen wieder her, die durch die automatisierten oder anpassbaren Skripte nach der Installation vorgenommen wurden. ProxMenux registriert jede unterstützte Optimierung mit ihrer dedizierten Wiederherstellungsfunktion; Paket-Upgrades sind absichtlich ausgeschlossen.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Warum es das gibt",
|
||||
"body": "Jede unterstützte rückgängig zu machende Änderung wird <strong>erfasst</strong> in <code>/usr/local/share/proxmenux/installed_tools.json</code>. Dieses Verzeichnis steuert die Deinstallation: Es zeigt aktive Optimierungen und ruft deren Wiederherstellungsfunktion auf. Aktionen ohne sicheres Zurücksetzen, etwa vollständige Paket-Upgrades, werden nicht aufgenommen."
|
||||
},
|
||||
"openMenu": {
|
||||
"heading": "Wie man es öffnet",
|
||||
"body": "Öffnen Sie im Hauptmenü <strong>Proxmox-Nachinstallationseinstellungen → Optimierungen deinstallieren</strong>. Die Liste zeigt <em>aktuell angewendete</em> Optimierungen; nicht angewendete Einträge fehlen.",
|
||||
"imageAlt": "Auswahlliste „Optimierungen deinstallieren“ mit aktiven Änderungen und Kontrollkästchen zum Zurücksetzen"
|
||||
},
|
||||
"howWorks": {
|
||||
"heading": "Wie die Umkehrung funktioniert",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Gespeicherte Einträge und automatische Erkennung",
|
||||
"body1": "Beim ersten Lauf sucht ProxMenux nach Erkennungsmerkmalen auf dem Host, etwa <code>/etc/sysctl.d/99-memory.conf</code>, <code>/etc/apt/apt.conf.d/99-force-ipv4</code>, installiertem <code>haveged</code> oder aktivem Log2RAM-Dienst. Erkannte Änderungen werden als rückgängig zu machen erfasst, auch wenn eine ältere ProxMenux-Version ohne Register sie vorgenommen hat.",
|
||||
"body2": "Diese Migration wird nur einmal ausgeführt. Anschließend aktualisiert jeder Anwenden- oder Rückgängig-Vorgang den gespeicherten Eintrag direkt."
|
||||
},
|
||||
{
|
||||
"title": "Änderungen zum Zurücksetzen auswählen",
|
||||
"body1": "Die Checkliste zeigt pro Artikel ein menschenlesbares Label (z.B. <em>Speichereinstellungen Optimierung</em>, <em>IOMMU/VFIO PCI-Durchgang</em>, <em>Log2RAM (SSD-Schutz)</em>). Klicken Sie auf die, die Sie umkehren möchten. Nichts, was Sie nicht ankreuzen, wird berührt."
|
||||
},
|
||||
{
|
||||
"title": "Rückgängigmachen wird ausgeführt",
|
||||
"body1": "Für jedes ausgewählte Element ruft ProxMenux seine passende Deinstallationsfunktion auf. Die meisten Umkehrungen folgen einem von drei Mustern:",
|
||||
"items": [
|
||||
"<strong>Backup-basierte </strong> — Wiederherstellung eines <code>.bak</code>, das zum Zeitpunkt der Anwendung erfasst wurde (bashrc, logrotate.conf, journald.conf, GRUB/kernel cmdline).",
|
||||
"<strong>Konfiguration löschen</strong> — ProxMenux-Dateien <code>/etc/sysctl.d/99-*.conf</code>, <code>/etc/apt/apt.conf.d/99-*</code> oder die systemd-Unit entfernen und neu laden.",
|
||||
"<strong>Pakete neu installieren</strong> — bei UI-Änderungen wie dem Abonnementhinweis die Originalpakete mit <code>--force-confnew</code> neu installieren, um ausgelieferte Einstellungen wiederherzustellen."
|
||||
],
|
||||
"body2": "Jede Umkehrung protokolliert ihren Fortschritt. Elemente, die einen Neustart erfordern (VFIO, persistente Schnittstellennamen), setzen ein Flag, das die Neustartaufforderung am Ende auslöst."
|
||||
},
|
||||
{
|
||||
"title": "Neustartabfrage am Ende",
|
||||
"body1": "Nachdem die Umkehrung beendet ist, zeigt das Menü eine Neustartaufforderung an. Elemente, die Kernelparameter, Kernelmodule oder Netzwerknamen (VFIO, persistente Schnittstellennamen) geändert haben, benötigen den Neustart, um wirksam zu werden; andere Elemente nicht, und die Eingabeaufforderung ist ein Sicherheitsstandard und keine Per-Item-Überprüfung."
|
||||
}
|
||||
]
|
||||
},
|
||||
"reversible": {
|
||||
"heading": "Was reversibel ist",
|
||||
"intro": "Registrierte reversible Optimierungen und deren passende Deinstallateure werden hier nach Bereichen gruppiert:",
|
||||
"groups": [
|
||||
{
|
||||
"title": "Repositories und APT",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Abonnementbanner entfernen",
|
||||
"restores": "Zunächst wird versucht, die UI-Dateien aus ProxMenux-eigenen Backups wiederherzustellen (/usr/local/share/proxmenux/backups/proxmoxlib.js.backup.* und, wenn die mobile UI gepatcht wird, index.html.tpl.backup.*). Nur wenn ein Backup fehlt oder beschädigt ist, greift man auf die Neuinstallation von pve-manager, proxmox-widget-toolkit, libjs-extjs und libpve-http-server-perl mit force-confnew zurück. Löscht auch zwischengespeicherte .js / .gz-Kopien."
|
||||
},
|
||||
{
|
||||
"tool": "APT-Sprachdateien überspringen",
|
||||
"restores": "Entfernt /etc/apt/apt.conf.d/99-disable-translations, damit APT übersetzte Paketbeschreibungsindizes gemäß den übrigen Spracheinstellungen herunterladen kann."
|
||||
},
|
||||
{
|
||||
"tool": "IPv4 für APT erzwingen",
|
||||
"restores": "Entfernen von /etc/apt/apt.conf.d/99-force-ipv4."
|
||||
},
|
||||
{
|
||||
"tool": "Systemwerkzeuge",
|
||||
"restores": "Entfernt nur ausgewählte Werkzeugpakete vollständig, die ProxMenux als neu installiert erfasst hat. Zuvor vorhandene Pakete werden nie in diese Liste aufgenommen und bleiben unverändert."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Kernel, Speicher und Systemgrenzen",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Speichereinstellungen",
|
||||
"restores": "Entfernt /etc/sysctl.d/99-memory.conf und lädt sysctl neu."
|
||||
},
|
||||
{
|
||||
"tool": "Kernel Panic Konfiguration",
|
||||
"restores": "Entfernen von /etc/sysctl.d/99-kernelpanic.conf."
|
||||
},
|
||||
{
|
||||
"tool": "Systemgrenzen erhöhen",
|
||||
"restores": "Entfernt /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf und /etc/security/limits.d/99-limits.conf. Setzt PAM-Grenzen und systemd DefaultLimitNOFILE zurück. In /root/.profile entfernt es nur die alte Zeile ulimit -n 256000; ulimit -n 1048576 des aktuellen Installers kann bleiben und manuelle Entfernung erfordern."
|
||||
},
|
||||
{
|
||||
"tool": "ZRAM-Swapprofil",
|
||||
"restores": "Deaktiviert den Swap auf /dev/zram0, stoppt dev-zram0.swap und entfernt /etc/systemd/zram-generator.conf.d/90-proxmenux.conf. Das systemd-zram-generator-Paket wird nur gelöscht, wenn ProxMenux es installiert hat und kein anderes ZRAM-Setup vorhanden ist. Wenn die Seiten in ZRAM nicht verschoben werden können, bleibt das Profil aktiv und es wird nichts entfernt."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Vernetzung",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Netzwerkoptimierungen",
|
||||
"restores": "Entfernt /etc/sysctl.d/99-network.conf, 97-proxmenux-fwbr.conf und 98-proxmenux-rpf.conf sowie proxmenux-fwbr-tune.service, das Hilfsskript /usr/local/sbin/proxmenux-fwbr-tune und die udev-Regel /etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules. Entfernt außerdem source /etc/network/interfaces.d/* aus /etc/network/interfaces. Lädt sysctl, systemd und udev-Regeln neu."
|
||||
},
|
||||
{
|
||||
"tool": "Open vSwitch",
|
||||
"restores": "Führt apt purge für openvswitch-switch und openvswitch-common aus. Migrieren Sie OVS-Bridges vorher zu Linux-Bridges, sonst verlieren die VMs darauf beim nächsten Start die Netzwerkanbindung."
|
||||
},
|
||||
{
|
||||
"tool": "TCP BBR + TCP Fast Open",
|
||||
"restores": "Entfernt /etc/sysctl.d/99-kernel-bbr.conf und 99-tcp-fastopen.conf und lädt übrige sysctl-Konfiguration neu. Das Löschen setzt aktive Werte nicht zurück; Standards wie cubic und tcp_fastopen=1 gelten nach Neustart, sofern keine andere Konfiguration sie überschreibt."
|
||||
},
|
||||
{
|
||||
"tool": "Persistente Schnittstellennamen",
|
||||
"restores": "Entfernt nur die 10-proxmenux-*.link-Dateien mit dem ProxMenux-Header aus /etc/systemd/network/. Jede .link-Datei, die von einem anderen Paket bereitgestellt oder vom Benutzer geschrieben wurde, bleibt an Ort und Stelle. Schnittstellennamen kehren beim nächsten Neustart zum Standardverhalten von systemd zurück."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Protokollierung",
|
||||
"items": [
|
||||
{
|
||||
"tool": "journald-Optimierung",
|
||||
"restores": "Schreibt /etc/systemd/journald.conf mit ursprünglichen Standardwerten neu und startet systemd-journald neu."
|
||||
},
|
||||
{
|
||||
"tool": "Logrotate-Optimierung",
|
||||
"restores": "Stellt /etc/logrotate.conf aus der vor der Änderung erstellten .bak-Datei wieder her."
|
||||
},
|
||||
{
|
||||
"tool": "Log2RAM",
|
||||
"restores": "Stoppt und deaktiviert Dienst und Timer. Entfernt Cron-Jobs, systemd-Units, Programmdateien, Konfiguration und /var/log.hdd. Entfernt auch das apt-Paket, falls darüber installiert."
|
||||
},
|
||||
{
|
||||
"tool": "Automatisches ZFS-TRIM",
|
||||
"restores": "Liest /usr/local/share/proxmenux/zfs_autotrim_pools mit den tatsächlich geänderten Pools und führt jeweils zpool set autotrim=off aus. Bereits vor ProxMenux manuell aktivierter Autotrim bleibt bestehen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Shell und Erscheinungsbild",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Bashrc anpassen",
|
||||
"restores": "Wiederherstellt /root/.bashrc aus dem .bak-Backup. Wenn kein Backup vorhanden ist, wird der PMX_CORE_BASHRC-Block durch Markierungen entfernt."
|
||||
},
|
||||
{
|
||||
"tool": "Eigenes MOTD-Banner",
|
||||
"restores": "Stellen Sie den genauen ursprünglichen /etc/motd-Inhalt, der unter /usr/local/share/proxmenux gespeichert ist, wieder her, entfernen Sie die Datei, wenn sie vorher nicht vorhanden war, oder entfernen Sie den alten Marker sicher, wenn Sie eine ältere Installation migrieren."
|
||||
},
|
||||
{
|
||||
"tool": "Fastfetch",
|
||||
"restores": "Entfernt Programmdatei, Konfigurationsverzeichnis, update-motd-Hook und den abgegrenzten Block BEGIN FASTFETCH / END FASTFETCH aus /root/.bashrc, ~/.profile, /etc/profile und /etc/profile.d/fastfetch.sh. Entfernt ein installiertes apt-Paket vollständig."
|
||||
},
|
||||
{
|
||||
"tool": "Figurine",
|
||||
"restores": "Entfernt den Binär-, profile.d-Eintrag und den Alias-Block in bashrc/profile."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Hardware & Virtualisierung",
|
||||
"items": [
|
||||
{
|
||||
"tool": "IOMMU / VFIO",
|
||||
"restores": "Entfernt vfio Module aus /etc/modules, die Nouveau / Radeon / nvidia Blacklist Einträge und intel_iommu=on / amd_iommu=on / iommu=pt / pcie_acs_override Parameter aus /etc/kernel/cmdline (ZFS) oder GRUB. Baut Initramfs wieder auf."
|
||||
},
|
||||
{
|
||||
"tool": "AMD-CPU-Korrekturen (Ryzen/EPYC)",
|
||||
"restores": "Entfernt idle=nomwait aus Kernel cmdline (ZFS) oder GRUB und die ignore_msrs / report_ignored_msrs Optionen aus /etc/modprobe.d/kvm.conf."
|
||||
},
|
||||
{
|
||||
"tool": "Gast-Agent für einen virtualisierten Proxmox-Host",
|
||||
"restores": "Liest /usr/local/share/proxmenux/guest_agent.pkg und entfernt das erfasste Hostpaket vollständig. Der Installer wählt qemu-guest-agent, open-vm-tools oder virtualbox-guest-utils nach Hypervisor. Ohne Eintrag versucht die Deinstallation diese drei Pakete. Betroffen ist der verschachtelte Proxmox-Host, nicht Gastvorlagen."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Speicher",
|
||||
"items": [
|
||||
{
|
||||
"tool": "ZFS-ARC-Größe anpassen",
|
||||
"restores": "Entfernt /etc/modprobe.d/99-zfsarc.conf, stellt gesicherte widersprüchliche externe *.conf aus /usr/local/share/proxmenux/backups/zfs_arc/ wieder her, baut initramfs neu und führt proxmox-boot-tool refresh auf systemd-boot-Hosts aus."
|
||||
},
|
||||
{
|
||||
"tool": "Automatische ZFS-Snapshots",
|
||||
"restores": "Entfernt die Cron-Einträge, die das Skript geschrieben hat, und bietet an, zfs-auto-snapshot zu bereinigen. Bestehende Snapshot-Datensätze in den Pools bleiben intakt - entfernen Sie sie separat, wenn Sie sie weghaben möchten."
|
||||
},
|
||||
{
|
||||
"tool": "vzdump-Geschwindigkeitsbegrenzung",
|
||||
"restores": "Stellt /etc/vzdump.conf aus der Installationssicherung .bak wieder her und setzt bwlimit und ionice auf die Werte vor ProxMenux zurück."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Dienstleistungen & Extras",
|
||||
"items": [
|
||||
{
|
||||
"tool": "Zeitsynchronisation",
|
||||
"restores": "Setzt die Zeitzone mit timedatectl auf UTC als sicheren Standard zurück."
|
||||
},
|
||||
{
|
||||
"tool": "Entropieerzeugung (haveged)",
|
||||
"restores": "Stoppt und deaktiviert haveged und entfernt das Paket vollständig."
|
||||
},
|
||||
{
|
||||
"tool": "kexec (schnelle Neustarts)",
|
||||
"restores": "Deaktiviert kexec-pve.service, entfernt die Unit-Datei und den Alias reboot-quick aus /root/.bash_profile und entfernt kexec-tools vollständig."
|
||||
},
|
||||
{
|
||||
"tool": "RPC / rpcbind deaktiviert",
|
||||
"restores": "Stellt rpcbind.service und rpcbind.socket jeweils auf den zuvor erfassten Aktivierungs- und Laufzustand zurück: aktiviert/deaktiviert und aktiv/inaktiv."
|
||||
},
|
||||
{
|
||||
"tool": "pigz (paralleles gzip)",
|
||||
"restores": "Kopiert den echten gzip von gzip.distrib zurück, entfernt die dpkg-Umleitung und /bin/pigzwrapper, kommentiert die pigz-Linie in /etc/vzdump.conf und löscht pigz, sobald gzip verifiziert ist."
|
||||
},
|
||||
{
|
||||
"tool": "Dienste mit hoher Verfügbarkeit",
|
||||
"restores": "Stoppt und deaktiviert pve-ha-lrm, pve-ha-crm und corosync. Bestehende HA-Gruppen und Ressourcendefinitionen werden nicht gelöscht – entfernen Sie sie aus der Web-Benutzeroberfläche, wenn Sie sie nicht mehr benötigen."
|
||||
},
|
||||
{
|
||||
"tool": "Ceph-Repository",
|
||||
"restores": "Bereinigt die mit dieser Option installierten Ceph-Pakete, entfernt die deb822 /etc/apt/sources.list.d/ceph.sources auf PVE 9 (oder die alte Ceph-Liste auf PVE 8) und aktualisiert den APT-Cache."
|
||||
},
|
||||
{
|
||||
"tool": "OVH RTM (Überwachung)",
|
||||
"restores": "Entfernt Pakete passend zu ovh-rtm*, rtm und rtm-*, löscht /etc/rtm und entfernt den RTM-Registereintrag. Puppet-Reste unter /etc/puppet/ müssen eventuell manuell geprüft und bereinigt werden; das Verzeichnis wird nicht gelöscht. Auf Nicht-OVH-Hosts nimmt der Installer normalerweise keine Änderungen vor."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"edge": {
|
||||
"heading": "Sonderfälle und Einschränkungen",
|
||||
"packageTitle": "Neuinstallation betrifft laufende Proxmox-Pakete",
|
||||
"packageBody": "Können ProxMenux-Sicherungen <strong>Abonnementhinweis entfernen</strong> nicht zurücksetzen, installiert der Rückfallweg <code>pve-manager</code>, <code>proxmox-widget-toolkit</code>, <code>libjs-extjs</code> und <code>libpve-http-server-perl</code> mit <code>--force-confnew</code> neu. Das betrifft die laufende Weboberfläche: Browser neu laden und einige Sekunden zum Wiederverbinden abwarten. Nicht während Migrationen oder Klonvorgängen ausführen.",
|
||||
"rebootTitle": "Persistente Namen und VFIO benötigen einen Neustart",
|
||||
"rebootBody": "Das Entfernen der <code>10-proxmenux-*.link</code>-Dateien (<em>Persistente Schnittstellennamen</em>) und Zurücksetzen von <em>IOMMU/VFIO</em> ändern den bereits gestarteten Zustand nicht; sie werden nach Neustart wirksam. ProxMenux setzt dafür automatisch das Neustart-Flag.",
|
||||
"perItemTitle": "Sie können eine Sache rückgängig machen und den Rest behalten",
|
||||
"perItemBody": "Der Deinstaller arbeitet per Item. Wenn Sie nur Log2RAM entfernen möchten, aber die Netzwerk-Tuning- und Bashrc-Änderungen beibehalten möchten, kreuzen Sie nur <em>Log2RAM</em> an. Nichts anderes wird berührt und die Registry wird entsprechend aktualisiert."
|
||||
},
|
||||
"inspect": {
|
||||
"heading": "Kontrolle des Registers manuell",
|
||||
"intro": "Wenn Sie sehen möchten, was verfolgt wird, ohne das Menü zu öffnen:",
|
||||
"outro": "Jeder <code>\"tool\": true</code>-Eintrag entspricht etwas ProxMenux angewendet und kann umgekehrt werden. Das manuelle Entfernen eines Eintrags wird nicht empfohlen - verwenden Sie immer das Menü, das auch die Umkehrfunktion ausführt, anstatt nur die Änderung zu vergessen.",
|
||||
"reinstallTitle": "Neuinstallieren nach Deinstallieren",
|
||||
"reinstallBody": "Eine zurückgesetzte Optimierung kann später erneut angewendet werden. Öffnen Sie <link>das Nachinstallationsmenü</link> und starten Sie Automatisiert oder Anpassbar; das Register erfasst den neuen Zustand."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "Automatisiertes Post-Install",
|
||||
"href": "/docs/post-install/automated",
|
||||
"tail": " — die sinnvolle Grundkonfiguration erneut anwenden."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — eine andere Auswahl treffen."
|
||||
},
|
||||
{
|
||||
"label": "Deinstallieren Sie ProxMenux",
|
||||
"href": "/docs/settings/uninstall-proxmenux",
|
||||
"tail": "- andere Operation: entfernt ProxMenux selbst, nicht seine angewandten Optimierungen."
|
||||
},
|
||||
{
|
||||
"label": "Übersicht Post-Install",
|
||||
"href": "/docs/post-install",
|
||||
"tail": "."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,112 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Verfügbare Updates anwenden — Optimierungen nach der Installation | ProxMenux Dokumentation",
|
||||
"description": "Wie ProxMenux neue Versionen von Nachinstallationsoptimierungen wie Log2Ram, Speichereinstellungen, Systemlimits, Logrotate und Netzwerkanpassungen erkennt und wie Sie sie im Nachinstallationsmenü oder Monitor-Dashboard anwenden."
|
||||
},
|
||||
"header": {
|
||||
"title": "Verfügbare Updates anwenden",
|
||||
"description": "Liegt eine Nachinstallationsoptimierung (Log2Ram, Speichereinstellungen, Systemlimits, Logrotate …) auf dem Datenträger in einer neueren Version vor als der auf dem Host erfassten, zeigt ProxMenux ein verfügbares Update an. Sie können es im Nachinstallationsmenü der Skriptoberfläche oder im Monitor-Dashboard anwenden. Beide Wege führen dieselbe Nachinstallationsfunktion erneut aus und aktualisieren den gespeicherten Versionsstand.",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das ist",
|
||||
"body": "ProxMenux-Nachinstallationsoptimierungen haben Versionsnummern, etwa <code>Log2ram SSD Protection v1.2</code>. Der Host erfasst aktive Optimierungen und ihre Versionen in <code>/usr/local/share/proxmenux/installed_tools.json</code>. Liefert eine neue ProxMenux-Version eine aktualisierte Optimierung, erkennt ProxMenux den Unterschied und bietet an, nur diese erneut anzuwenden, ohne die gesamte Nachinstallation zu wiederholen."
|
||||
},
|
||||
"why": {
|
||||
"heading": "Warum es das gibt",
|
||||
"body": "Nachinstallationsoptimierungen erhalten Verbesserungen wie bessere sysctl-Einstellungen, strengere Logrotate-Limits, neue Log2RAM-Größenregeln oder Fehlerkorrekturen. Ohne Updateweg mussten Sie den ganzen Skriptlauf mit <em>allen</em> Optimierungen wiederholen oder auf die Verbesserung verzichten. Verfügbare Updates anwenden erlaubt die ausdrückliche Auswahl einzelner Optimierungen, deren Version sich geändert hat."
|
||||
},
|
||||
"detection": {
|
||||
"heading": "Wie Updates erkannt werden",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Versionierte Skripte auf Disk",
|
||||
"body": "Jede Funktion nach der Installation deklariert ihre Version innerhalb des Skripts (<code>scripts/post_install/auto_post_install.sh</code> und <code>scripts/post_install/customizable_post_install.sh</code>). Ein Scanner extrahiert diese Versionen aus der Quelle auf der Festplatte."
|
||||
},
|
||||
{
|
||||
"title": "Versioniertes Register auf dem Host",
|
||||
"body": "Wenn der Operator jede Optimierung anwendete, schrieb der entsprechende <code>register_tool</code>-Aufruf die aktive Version in <code>/usr/local/share/proxmenux/installed_tools.json</code>. Diese Datei ist die Quelle der Wahrheit für \"was auf diesem Host gerade aktiv ist\"."
|
||||
},
|
||||
{
|
||||
"title": "Monitor vergleicht beide Seiten",
|
||||
"body": "Beim Start und alle 24 Stunden vergleicht der Monitor Festplattenversionen mit Registrierungsversionen. Jede Inkongruenz führt zu einem Eintrag in <code>/usr/local/share/proxmenux/updates_available.json</code>. Diese Datei steuert sowohl den Post-Install-Menüeintrag als auch die Monitor-Dashboardkarte."
|
||||
},
|
||||
{
|
||||
"title": "Eine Benachrichtigung pro neuer Version",
|
||||
"body": "Wenn mindestens eine Optimierung ein ausstehendes Update hat, sendet der Monitor eine einzelne gruppierte Benachrichtigung aus - zum Beispiel <em>\"4 ProxMenux Optimierungsupdate(s) verfügbar\"</em> - mit einer Zeile pro Tool im selben <code>name (vX → vY)</code>-Format, das für Proxmox-Paketupdates verwendet wird. Die Benachrichtigung ist Anti-Kaskade, so dass sie sich nicht Tag für Tag für denselben Satz wiederholt; nur eine neue Version (oder ein neues Tool, das in die Liste eintritt) löst sie erneut aus."
|
||||
}
|
||||
]
|
||||
},
|
||||
"pathA": {
|
||||
"heading": "Pfad A — Aus dem Menü nach der Installation",
|
||||
"intro": "Öffnen Sie im ProxMenux-Hauptmenü <strong>Einstellungen nach der Installation von Proxmox</strong>. Bei ausstehenden Updates erscheint <strong>Verfügbare Updates anwenden (N)</strong> direkt über <em>Optimierungen deinstallieren</em>. Die Zahl zeigt die Optimierungen mit neuerer Version auf dem Datenträger als im Register. Ist alles aktuell, bleibt der Eintrag verborgen.",
|
||||
"menuAlt": "Das Menü Post-Install Scripts zeigt den bedingte Eintrag \"Verfügbare Updates anwenden (N)\" direkt über \"Optimierungen deinstallieren\" an, wobei das Zählabzeichen anzeigt, wie viele Optimierungen eine neuere Version auf der Festplatte haben",
|
||||
"menuCaption": "<em>Verfügbare Updates anwenden (N)</em> erscheint nur, wenn mindestens eine Optimierung ein Update hat, und wird bei aktuellem Host ausgeblendet.",
|
||||
"checklistBody": "Öffnet eine Auswahlliste aller ausstehenden Updates, jeweils im Format <code>name (vX → vY)</code>. Alle Zeilen sind standardmäßig ausgewählt; wählen Sie die ab, die Sie diesmal nicht anwenden möchten.",
|
||||
"checklistAlt": "Auswahldialog Verfügbare Updates anwenden mit einer Zeile pro Optimierung, ihrem Namen und Versionswechsel (aktuell → verfügbar). Alle Zeilen sind ausgewählt.",
|
||||
"checklistCaption": "Jede Optimierung einzeln wählen: Entscheiden Sie, welche Versionen aktualisiert werden. Dieselbe Grundlage wie Automatisch und Anpassbar wendet die Funktionen im Hintergrund erneut an und aktualisiert ihre Registerversionen."
|
||||
},
|
||||
"pathB": {
|
||||
"heading": "Pfad B — Vom Monitor-Dashboard",
|
||||
"intro": "Dieselben Updates erscheinen unter <link>Einstellungen → ProxMenux-Optimierungen</link> im Monitor. Bei ausstehenden Updates zeigt die Karte ein <strong>Update-Zählabzeichen</strong>, das die Auswahl einzelner Optimierungen öffnet. Jedes Werkzeug bietet auch eine eigene Updateaktion.",
|
||||
"imageAlt": "Karte ProxMenux-Optimierungen in den Monitor-Einstellungen mit Zählabzeichen für ausstehende Updates zum Öffnen der Auswahl und Updateaktionen pro Werkzeug",
|
||||
"imageCaption": "Die Optimierungskarte im Monitor bietet über ihr Zählabzeichen Zugriff auf Updates, sobald eine neuere Version auf dem Datenträger liegt, ohne Shell-Zugriff."
|
||||
},
|
||||
"applying": {
|
||||
"heading": "Was beim Anwenden passiert",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Führt die Post-Installation-Funktion erneut aus",
|
||||
"body": "Die Funktion der ausgewählten Optimierung wird gegen den Host erneut ausgeführt. Da jede Funktion nach der Installation <strong>idempotent</strong> ist, wird die Konfiguration nicht dupliziert - sie überschreibt die vorherige Version mit der neuen (Sysctl-Dateien, Drop-Ins, Serviceeinheiten usw.)."
|
||||
},
|
||||
{
|
||||
"title": "Aktualisieren des Registers",
|
||||
"body": "Der <code>register_tool</code>-Aufruf innerhalb der Funktion schreibt die neue Version in <code>installed_tools.json</code>. Beim nächsten Scan wird keine Diskrepanz mehr festgestellt und der Updateeintrag verschwindet sowohl aus dem Menü als auch aus der Monitorkarte."
|
||||
},
|
||||
{
|
||||
"title": "Kein Neustart, es sei denn, die Funktion sagt es",
|
||||
"body": "Die meisten Updates werden sofort wirksam. Updates, die Kernelmodule, persistente Schnittstellennamen oder VFIO berühren, zeigen die gleiche Neustartaufforderung wie eine Neuinstallation."
|
||||
},
|
||||
{
|
||||
"title": "Registrieraktualisierung an den Monitor gesendet",
|
||||
"body": "Nach dem Durchlauf sendet das Menü eine POST-Anfrage an <code>http://127.0.0.1:8008/api/updates/post-install/scan</code>, um <code>/usr/local/share/proxmenux/updates_available.json</code> neu zu erstellen. Nach Anwendung aller Updates verschwinden das Update-Zählabzeichen und der bedingte Shell-Menüeintrag ohne Warten auf den nächsten Scan. Die Optimierungskarte bleibt verfügbar."
|
||||
}
|
||||
],
|
||||
"jqTitle": "jq ist erforderlich",
|
||||
"jqBody": "Die Path-A-Checkliste basiert auf <code>jq</code>, um die ausstehenden Updates JSON zu analysieren. Wenn <code>jq</code> fehlt, verlässt der Fluss lautlos - Sie würden den Menüeintrag mit einer Zählung sehen, aber nach dem Auswählen von Zeilen würde nichts passieren. Auf jeder modernen Proxmox-Installation ist <code>jq</code> vorhanden; im Zweifelsfall führen Sie <code>apt install -y jq</code> aus."
|
||||
},
|
||||
"differs": {
|
||||
"heading": "Wie es sich von den anderen Pfaden unterscheidet",
|
||||
"headerPath": "Path",
|
||||
"headerScope": "Umfang",
|
||||
"headerWhen": "Wenn es Sinn macht",
|
||||
"rows": [
|
||||
{
|
||||
"pathLabel": "Automatisch",
|
||||
"pathHref": "/docs/post-install/automated",
|
||||
"scope": "Wendet <em>jede</em> Optimierung des Pakets erneut an.",
|
||||
"when": "Frischer Host oder vollständige Re-Baseline eines vollständig verwalteten Knotens."
|
||||
},
|
||||
{
|
||||
"pathLabel": "Anpassbar",
|
||||
"pathHref": "/docs/post-install/customizable",
|
||||
"scope": "Wählen Sie aus dem vollständigen Katalog.",
|
||||
"when": "Gezielt auswählen, welche Optimierungen auf dem Host aktiv sind."
|
||||
},
|
||||
{
|
||||
"pathLabel": "Verfügbare Updates anwenden",
|
||||
"pathHref": null,
|
||||
"scope": "Nur Optimierungen mit neuerer Version auf dem Datenträger.",
|
||||
"when": "Halten Sie bereits installierte Optimierungen aktuell, ohne den Rest zu berühren."
|
||||
},
|
||||
{
|
||||
"pathLabel": "Optimierungen deinstallieren",
|
||||
"pathHref": "/docs/post-install/uninstall",
|
||||
"scope": "Optimierung rückgängig machen und ihren Registereintrag entfernen.",
|
||||
"when": "Rollen Sie eine bestimmte Änderung zurück."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifTitle": "Benachrichtigung steuern",
|
||||
"notifBody": "Ausstehende Updates werden durch <em>ProxMenux-Optimierungsupdates verfügbar</em> angekündigt. Das Ereignis ist auf allen Kanälen standardmäßig aktiv und kann unter <link>Einstellungen → Benachrichtigungen</link> pro Kanal stummgeschaltet werden. Es wird nur einmal pro unterschiedlicher Updategruppe ausgelöst, nicht bei jedem 24-Stunden-Scan."
|
||||
}
|
||||
@@ -0,0 +1,116 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Post-Install: Virtualisierung | ProxMenux Dokumentation",
|
||||
"description": "Virtualisierungsoptionen im ProxMenux Anpassbares Post-Installationsskript: Installieren Sie automatisch den richtigen Gastagenten, wenn Proxmox in einem VM läuft, und aktivieren Sie IOMMU / VFIO, damit Sie PCI-Geräte (GPUs, NICs, HBAs) an Ihre eigenen VMs weitergeben können."
|
||||
},
|
||||
"header": {
|
||||
"title": "Post-Install: Virtualisierung",
|
||||
"section": "Einstellungen nach der Installation von Proxmox"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Kategorie abdeckt",
|
||||
"body": "Zwei unabhängige Optionen. <strong>Passenden Gastagenten installieren</strong> hilft, wenn Proxmox selbst in einem anderen Hypervisor verschachtelt läuft. <strong>VFIO-IOMMU-Unterstützung aktivieren</strong> ist für die meisten Benutzer relevant: Es aktiviert die Kernelfunktionen zur direkten Zuweisung einer GPU, HBA oder Netzwerkkarte an eine VM mit nahezu nativer Leistung."
|
||||
},
|
||||
"guestAgent": {
|
||||
"heading": "Relevanten Gastagenten installieren",
|
||||
"intro": "Erkennt die Virtualisierungsumgebung des Proxmox-Hosts mit <code>systemd-detect-virt</code> und <code>dmidecode</code> und installiert das passende Gastwerkzeugpaket für die Kommunikation mit dem äußeren Hypervisor: geordnetes Herunterfahren, Uhrzeitsynchronisierung, IP-Meldung usw.",
|
||||
"headerDetected": "Erkannter Host",
|
||||
"headerPackage": "Installiertes Paket",
|
||||
"rows": [
|
||||
{
|
||||
"detected": "QEMU / KVM",
|
||||
"package": "qemu-guest-agent"
|
||||
},
|
||||
{
|
||||
"detected": "VMware (ESXi, Workstation)",
|
||||
"package": "open-vm-tools"
|
||||
},
|
||||
{
|
||||
"detected": "VirtualBox",
|
||||
"package": "virtualbox-guest-utils"
|
||||
},
|
||||
{
|
||||
"detected": "Direkt auf Hardware (keiner)",
|
||||
"package": "— no-op, nichts installiert"
|
||||
}
|
||||
],
|
||||
"skipTitle": "Überspringen Sie dies auf Bare-Metal Proxmox",
|
||||
"skipBody": "Wenn Proxmox direkt auf Hardware läuft (der übliche Fall), ist das Ankreuzen dieser Option ein No-Op - der Detektor gibt <code>none</code> zurück und das Skript wird ohne Änderungen beendet. Die Option ist nur für die Minderheit der Setups wichtig, die Proxmox <em> als Gast</em> für Tests oder Labors ausführen."
|
||||
},
|
||||
"vfio": {
|
||||
"heading": "VFIO IOMMU-Unterstützung aktivieren",
|
||||
"intro": "Aktiviert IOMMU auf dem Host und lädt die Kernelmodule für PCI-Passthrough (<code>vfio</code>, <code>vfio_iommu_type1</code>, <code>vfio_pci</code>). Damit kann ein physisches Gerät direkt einer VM zugewiesen werden, deren Gast einen nahezu hardwaredirekten Zugriff erhält.",
|
||||
"whoTitle": "Wer das braucht",
|
||||
"whoItems": [
|
||||
"Sie möchten eine GPU an eine Windows-Gaming-VM oder macOS-VM durchreichen.",
|
||||
"Sie haben eine dedizierte 10G NIC für eine Firewall / Router VM (OPNsense, pfSense).",
|
||||
"Sie möchten einen HBA direkt an einen TrueNAS/Unraid VM für ZFS auf nackten Festplatten übergeben.",
|
||||
"Sie planen, <em>Coral TPU</em>, eine Capture-Karte oder einen SDR-Dongle in einem VM zu verwenden."
|
||||
],
|
||||
"whoOutro": "Trifft nichts davon zu, können Sie die Option sicher überspringen. Für die Geräteweitergabe an einen <strong>LXC</strong>-Container statt an eine VM ist IOMMU <em>nicht</em> erforderlich.",
|
||||
"doesTitle": "Was ProxMenux tut",
|
||||
"doesIntro": "Die Funktion ist bootloaderbewusst: Sie erkennt, ob Proxmox auf ZFS (systemd-boot) oder LVM/ext4 (GRUB) ist und schreibt in die richtige Datei. Es ist auch idempotent - wenn die Parameter bereits vorhanden sind, wird nichts hinzugefügt.",
|
||||
"headerBoot": "Bootstyp",
|
||||
"headerFile": "Geänderte Datei",
|
||||
"headerPost": "Schritt nach der Aktualisierung",
|
||||
"bootRows": [
|
||||
{
|
||||
"boot": "systemd-boot (ZFS)",
|
||||
"file": "/etc/kernel/cmdline",
|
||||
"post": "proxmox-boot-tool refresh"
|
||||
},
|
||||
{
|
||||
"boot": "GRUB (LVM/ext4)",
|
||||
"file": "/etc/default/grub",
|
||||
"post": "update-grub"
|
||||
}
|
||||
],
|
||||
"kernelIntro": "Zusätzliche Kernelparameter:",
|
||||
"modulesIntro": "Kernelmodule, die <code>/etc/modules</code> hinzugefügt wurden:",
|
||||
"blacklistIntro": "Konfliktierende Treiber auf der schwarzen Liste in <code>/etc/modprobe.d/blacklist.conf</code>:",
|
||||
"blacklistTitle": "GPU-Treibersperren verhindern die GPU-Nutzung auf dem Host",
|
||||
"blacklistBody": "Die Sperrliste verhindert, dass der Host-Kernel <em>irgendeinen</em> GPU-Treiber bindet, damit VFIO die GPU übernehmen kann. Das ist für die Durchreichung an eine VM erwünscht, aber das <strong>Gegenteil</strong> dessen, was Sie zum <link>Installieren von NVIDIA-Treibern auf dem Host</link> benötigen, etwa für LXC-Transcodierung. Wählen Sie pro GPU einen Weg:",
|
||||
"pathItems": [
|
||||
"<strong>GPU → VM:</strong> aktivieren VFIO/IOMMU hier, lassen Sie die GPU-Treiber auf der schwarzen Liste.",
|
||||
"<strong>GPU → LXC (oder Host):</strong> überspringen Sie diese Option, installieren Sie NVIDIA auf dem Host und sperren Sie nvidia/nouveau nicht.",
|
||||
"<strong>Zwei GPUs:</strong> Eine kann einer VM, die andere einem LXC zugeordnet werden. Dafür ist eine gezieltere Konfiguration nötig: Binden Sie nur eine Karte über ihre PCI-ID an <code>vfio-pci</code>. Die Standardsperrliste ist dafür zu umfassend; bearbeiten Sie danach <code>blacklist.conf</code>."
|
||||
],
|
||||
"acsTitle": "Über pcie_acs_override - wissen, was Sie aktivieren",
|
||||
"acsBody": "<code>pcie_acs_override=downstream,multifunction</code> entspannt den PCIe Access Control Services Check. Es ermöglicht dem Kernel, IOMMU-Gruppen aufzuteilen, die von der Firmware als monolithisch gemeldet werden, was manchmal die einzige Möglichkeit ist, ein Gerät einer Gruppe zu durchlaufen, ohne den Rest zu ziehen. Der Kompromiss ist <strong> reduzierte Isolation zwischen Geräten</strong>: ein bösartiger oder kompromittierter VM mit Durchgang hat eine größere Angriffsfläche über DMA. Gut für ein Heimlabor; Überlegen Sie zweimal, bevor Sie einen Host aktivieren, der nicht vertrauenswürdige Workloads ausführt. Wenn Sie es nicht benötigen, entfernen Sie dieses Token aus <code>/etc/kernel/cmdline</code> oder <code>/etc/default/grub</code>, nachdem das Skript ausgeführt wurde, und führen Sie den Schritt zur Aktualisierung des Bootloaders erneut aus.",
|
||||
"rebootTitle": "Reboot erforderlich",
|
||||
"rebootBody": "IOMMU, VFIO-Module und Sperrliste werden erst nach initramfs-Neuerstellung und Neustart wirksam. Das Skript führt <code>update-initramfs -u -k all</code> und die Bootloader-Aktualisierung aus und setzt „Neustart erforderlich“, sodass Anpassbar am Ende danach fragt.",
|
||||
"verifyTitle": "Überprüfung nach dem Neustart",
|
||||
"revertTitle": "Reversibel aus dem Menü Deinstallieren",
|
||||
"revertBody": "<link>Optimierungen deinstallieren</link> macht alle Änderungen rückgängig: entfernt IOMMU-Parameter aus <code>/etc/kernel/cmdline</code> oder GRUB, VFIO-Module aus <code>/etc/modules</code> und die Treibersperren und erstellt initramfs neu. Erst ein Neustart wendet die Rücknahme an."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"label": "GPU zu VM hinzufügen (Passthrough)",
|
||||
"href": "/docs/hardware/gpu-vm-passthrough",
|
||||
"tail": "— natürlicher nächster Schritt, sobald IOMMU + VFIO aktiviert sind."
|
||||
},
|
||||
{
|
||||
"label": "Controller oder NVMe zu VM hinzufügen",
|
||||
"href": "/docs/disk-manager/add-controller-nvme-vm",
|
||||
"tail": " — dieselbe Passthrough-Infrastruktur für Speichercontroller."
|
||||
},
|
||||
{
|
||||
"label": "GPU-Passthrough-Befehle",
|
||||
"href": "/docs/help-info/gpu-commands",
|
||||
"tail": "Referenz der IOMMU-Prüfung."
|
||||
},
|
||||
{
|
||||
"label": "Optimierungen deinstallieren",
|
||||
"href": "/docs/post-install/uninstall",
|
||||
"tail": " — IOMMU/VFIO sauber rückgängig machen."
|
||||
},
|
||||
{
|
||||
"label": "Anpassbare Nachinstallation",
|
||||
"href": "/docs/post-install/customizable",
|
||||
"tail": " — zurück zum übergeordneten Menü."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,152 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Fail2Ban | ProxMenux-Dokumentation",
|
||||
"description": "Installieren Sie Fail2Ban mit drei jails abgestimmt auf Proxmox (SSH aggressiv, Proxmox UI 8006, ProxMenux Monitor 8008). Beinhaltet den Fix journald MaxLevelStore, benutzerdefinierte Protokolldienste für Zuverlässigkeit, automatisch erkanntes nftables/iptables-Backend und SSH MaxAuthTries Härtung.",
|
||||
"ogTitle": "Fail2Ban | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Brute-Force-Schutz für SSH und Proxmox-Weboberflächen mit Proxmox-spezifischen journald- und Backend-Korrekturen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Fail2Ban",
|
||||
"description": "Installiert Fail2Ban für Proxmox: drei Jails (SSH aggressiv, Proxmox-Weboberfläche auf 8006, ProxMenux Monitor auf 8008 und Reverse Proxy), journald-Korrektur zum Speichern von SSH-Anmeldeereignissen, zwei Journal-zu-Datei-Dienste als Umgehung eines bekannten systemd-Backend-Problems, automatische Firewall-Backend-Erkennung und SSH-Härtung mit MaxAuthTries.",
|
||||
"section": "Sicherheit"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Installiert Fail2Ban aus Debian-Paketquellen und schreibt eine Proxmox-Konfiguration, die SSH, Proxmox-Weboberfläche und ProxMenux Monitor sofort schützt. Bei vorhandener Installation erscheint stattdessen ein Verwaltungsmenü zum Neuinstallieren oder Entfernen."
|
||||
},
|
||||
"firstLaunch": {
|
||||
"heading": "Erststart-Dialog",
|
||||
"body": "Ohne vorhandenes Fail2Ban zeigt das Skript einen Bestätigungsdialog mit den geplanten Installations- und Konfigurationsschritten. Abbrechen beendet ohne Änderungen; Bestätigen startet die Installation.",
|
||||
"imageAlt": "Fail2Ban-Installationsbestätigung mit drei Jails, journald-Korrektur und SSH-Härtung"
|
||||
},
|
||||
"jails": {
|
||||
"heading": "Die drei jails",
|
||||
"headerJail": "Jail",
|
||||
"headerProtects": "Schützt",
|
||||
"headerRetries": "Fehlversuche / Zeitfenster",
|
||||
"headerBan": "Sperrdauer",
|
||||
"rows": [
|
||||
{
|
||||
"jail": "[sshd]",
|
||||
"protects": "SSH (aggressiver Modus — umfasst ddos, mode, normal)",
|
||||
"retries": "2 / 60 min",
|
||||
"ban": "9 Stunden"
|
||||
},
|
||||
{
|
||||
"jail": "[proxmox]",
|
||||
"protects": "Proxmox web UI (Port 8006)",
|
||||
"retries": "3 / 10 min",
|
||||
"ban": "1 Stunde"
|
||||
},
|
||||
{
|
||||
"jail": "[proxmenux]",
|
||||
"protects": "ProxMenux Monitor (Port 8008 + http/https Reverse Proxy)",
|
||||
"retries": "3 / 10 min",
|
||||
"ban": "1 Stunde"
|
||||
}
|
||||
],
|
||||
"outro": "Globale Standardwerte von <code>jail.local</code>: <code>ignoreip = 127.0.0.1/8 ::1</code>, <code>ignoreself = true</code>,<code> bantime = 86400</code> (24-Stunden-Fallback für jails, die es nicht überschreiben), <code>maxretry = 2</code>, <code>findtime = 1800</code>."
|
||||
},
|
||||
"journald": {
|
||||
"heading": "Warum die journald-Korrektur wichtig ist",
|
||||
"intro": "Proxmox liefert <code>/etc/systemd/journald.conf</code> mit <codeNw>MaxLevelStore=warning</codeNw>. journald verwirft Meldungen <em>unterhalb</em> von warning vor dem Speichern. SSH und PAM melden Anmeldefehler auf den Stufen <em>info</em> / <em>notice</em>, daher :",
|
||||
"diagram": {
|
||||
"sshLabel": "SSH / PAM",
|
||||
"sshDetail": "Anmeldefehler\n(Stufe info / notice)",
|
||||
"journaldLabel": "journald",
|
||||
"journaldDetail": "MaxLevelStore=warning\n→ Ereignis ohne Hinweis verworfen",
|
||||
"fail2banLabel": "Fail2Ban",
|
||||
"fail2banDetail": "Nichts sehen\nNiemals etwas verbieten",
|
||||
"arrowLabel": "Standard Proxmox"
|
||||
},
|
||||
"afterDiagram": "Der Installateur erkennt dies und schreibt ein Drop-in bei <codeXs>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</codeXs> und erhöht sowohl <code>MaxLevelStore</code> als auch <code>MaxLevelSyslog</code> auf <code>info</code>:",
|
||||
"code": "[Journal]\nMaxLevelStore=info\nMaxLevelSyslog=info",
|
||||
"outro": "Dann startet <code>systemd-journald</code> neu. Das Drop-In wird bei der Deinstallation entfernt, wodurch der ursprüngliche Proxmox-Standard wiederhergestellt wird."
|
||||
},
|
||||
"loggers": {
|
||||
"heading": "Warum zwei Custom Logger Services",
|
||||
"intro1": "Fail2Ban kann direkt aus dem systemd-Journal lesen (<code>backend = systemd</code>). Auf Proxmox gibt es jedoch bekannte Zuverlässigkeitsprobleme mit Worker-Prozessen von <code>pvedaemon</code>: Anmeldeereignisse erscheinen im Journal, werden aber nicht immer erkannt. Zeitweise betrifft dies auch <code>sshd</code>.",
|
||||
"intro2": "ProxMenux erstellt zwei kleine systemd-Dienste, die die betreffenden Units mit <code>journalctl -f</code> verfolgen und jede Zeile an eine Datei anhängen. Fail2Ban liest diese Dateien mit dem zuverlässigen <code>backend = auto</code> (Dateimodus) :",
|
||||
"headerService": "Dienst",
|
||||
"headerSource": "Quelleneinheit",
|
||||
"headerOutput": "Ausgabedatei",
|
||||
"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": "Beide Dienste sind als <code>PartOf=fail2ban.service</code> deklariert, sodass sie mit Fail2Ban neu starten und damit stoppen. Modus 640 im Besitz von <code>root:adm</code> in den Protokolldateien. Das dritte Protokoll, das von <code>[proxmenux]</code> jail (<code>/var/log/proxmenux-auth.log</code>) verwendet wird, wird direkt von der App ProxMenux Monitor Flask geschrieben – dafür ist kein Logger-Dienst erforderlich."
|
||||
},
|
||||
"backend": {
|
||||
"heading": "Firewall-Backend-Autoerkennung",
|
||||
"intro": "Der Installer prüft den Host: Wenn <code>nft list ruleset</code> funktioniert, wählt er <code>nftables</code> als Sperraktion. Ansonsten fällt es auf <code>iptables-multiport</code> / <code>iptables-allports</code> zurück. Die Auswahl ist in <code>jail.local</code> geschrieben:",
|
||||
"code": "# nftables host\nbanaction = nftables\nbanaction_allports = nftables[type=allports]\n\n# iptables host (fallback)\nbanaction = iptables-multiport\nbanaction_allports = iptables-allports"
|
||||
},
|
||||
"hardening": {
|
||||
"heading": "SSH-Härtung: MaxAuthTries",
|
||||
"intro": "Die Lynis-Prüfung <strong>SSH-7408</strong> empfiehlt <code>MaxAuthTries 3</code> in <code>sshd_config</code>. Die SSH-Jail verwendet <code>maxretry = 2</code> für Sperren nach wiederholten Fehlversuchen; MaxAuthTries begrenzt die Versuche innerhalb einer Verbindung. Diese SSH-Einstellung bietet zusätzliche Abwehr, auch bei wegen Wartung gestopptem Fail2Ban.",
|
||||
"installerIntro": "Der Installer:",
|
||||
"items": [
|
||||
"Lesen Sie den aktuellen <code>MaxAuthTries</code>-Wert (oder standardmäßig 6, falls nicht vorhanden).",
|
||||
"Speichert es in <code>/usr/local/share/proxmenux/sshd_maxauthtries_backup</code>.",
|
||||
"Bearbeitet <code>sshd_config</code> direkt: ersetzt die vorhandene Zeile, entfernt das Kommentarzeichen oder fügt eine neue Zeile hinzu.",
|
||||
"Lädt <code>sshd</code> neu, ohne den Dienst neu zu starten, damit bestehende Sitzungen aktiv bleiben."
|
||||
],
|
||||
"outro": "Bei der Deinstallation wird der gespeicherte Originalwert wiederhergestellt und <code>sshd</code> erneut geladen."
|
||||
},
|
||||
"manage": {
|
||||
"heading": "Verwalten einer vorhandenen Installation",
|
||||
"intro": "Wenn Fail2Ban beim Öffnen des Menüs bereits installiert ist, erkennt das Skript es und zeigt ein Verwaltungsmenü an, anstatt das Installationsprogramm erneut auszuführen:",
|
||||
"headerAction": "Aktion",
|
||||
"headerWhat": "Was es tut",
|
||||
"rows": [
|
||||
{
|
||||
"action": "Neuinstallieren",
|
||||
"what": "Führt den vollständigen Installer erneut aus und schreibt alle Jails mit den aktuellen ProxMenux-Vorgaben neu. Verwenden Sie dies, wenn ein Update die empfohlenen Werte ändert."
|
||||
},
|
||||
{
|
||||
"action": "Entfernen",
|
||||
"what": "Stoppt fail2ban und die beiden Logger-Dienste, löscht das apt-Paket, entfernt alle jail/Filterdateien, löscht das journald-Drop-In (stellt die Proxmox-Standardeinstellung wieder her) und stellt das ursprüngliche SSH wieder her. MaxAuthTries."
|
||||
}
|
||||
]
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Überprüfen Sie, ob es funktioniert",
|
||||
"intro": "Nach der Installation nützliche Befehle vom 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": "Fehlerbehebung",
|
||||
"neverBansTitle": "Fail2Ban läuft, verbietet aber niemals etwas",
|
||||
"neverBansBody": "Prüfen Sie, ob <code>tail -f /var/log/ssh-auth.log</code> nach einer SSH-Anmeldung mit falschem Passwort von einem anderen Rechner einen Eintrag erhält. Bleibt die Datei leer, prüfen Sie <code>systemctl status ssh-auth-logger.service</code>. Ist der Logger aktiv, zeigen Sie aktuelle SSH-Ereignisse mit <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> an und prüfen, ob der journald-Zusatz die Stufe <em>info</em> erlaubt.",
|
||||
"monitorEmptyTitle": "ProxMenux Monitor jail hat keine Einträge, auch nach fehlgeschlagenen Anmeldungen",
|
||||
"monitorEmptyBody": "Der <code>[proxmenux]</code> jail liest <code>/var/log/proxmenux-auth.log</code>, der von der ProxMenux Monitor Flask-App geschrieben wurde – nicht von einem journald-Logger. Wenn Sie den Monitor nicht ausführen, bleibt die Datei leer und jail wird nie ausgelöst. Das wird erwartet; Die jail-Konfiguration ist harmlos. Wenn Sie den Monitor ausführen und das Protokoll leer ist, überprüfen Sie die Protokollierungskonfiguration Flask.",
|
||||
"selfBanTitle": "Ich habe meinen eigenen Zugriff gesperrt",
|
||||
"selfBanIntro": "Von einer Konsole / IPMI / iKVM (oder einer anderen Whitelist-IP):",
|
||||
"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 schlägt fehl: ''Unable to locate package fail2ban''",
|
||||
"aptFailBody": "Dem Host fehlen die Debian-Repos (üblich bei Barebones, die Proxmox installiert). Der Installateur erkennt dies und schreibt <code>/etc/apt/sources.list.d/debian.sources</code> mit dem richtigen Codenamen (<code>bookworm</code> / <code>trixie</code>), bevor er es erneut versucht. Wenn es immer noch fehlschlägt, überprüfen Sie <code>/etc/os-release</code> für <code>VERSION_CODENAME</code> und bestätigen Sie, dass die Repo-URL erreichbar ist.",
|
||||
"lockoutTitle": "SSH sperrt mich nach der Installation aus",
|
||||
"lockoutBody": "Das Installationsprogramm setzt <code>MaxAuthTries=3</code>. Wenn Ihr Passwort-Manager / Agent mehrere Schlüssel wiederholt, können Sie diese bei einem einzigen Verbindungsversuch überschreiten. Begrenzen Sie die angebotenen Schlüssel: <code>ssh -o IdentitiesOnly=yes -i ~/.ssh/specific_key user@host</code>. Oder erhöhen Sie <code>MaxAuthTries</code> vorübergehend in <code>sshd_config</code>, während Sie debuggen."
|
||||
},
|
||||
"files": {
|
||||
"heading": "Dateien geschrieben",
|
||||
"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": "Verwandte Themen",
|
||||
"monitorLabel": "ProxMenux Monitor - Sicherheits-Tab",
|
||||
"monitorTail": " — Installation über das Dashboard, aktueller Jail-Status, gesperrte IP-Adressen und Einstellung von Fehlversuchen und Sperrdauer je Jail im Browser.",
|
||||
"lynisLabel": "Lynis",
|
||||
"lynisTail": " — führen Sie vorher und nachher eine Sicherheitsprüfung aus, um die Erfüllung von SSH-7408 zu bestätigen.",
|
||||
"securityLabel": "Sicherheitsübersicht",
|
||||
"securityTail": " — zurück zur Abschnittsübersicht."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,70 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox-Sicherheit — Fail2Ban, Lynis-Härtungsprüfung | ProxMenux",
|
||||
"description": "Zwei installierbare Sicherheitswerkzeuge für Proxmox VE: Fail2Ban (Einbruchsschutz für SSH, Proxmox-Weboberfläche und ProxMenux Monitor) und Lynis (Sicherheits- und Härtungsprüfung aus dem offiziellen GitHub-Repository).",
|
||||
"ogTitle": "Proxmox-Sicherheit — Fail2Ban und Lynis-Härtungsprüfung",
|
||||
"ogDescription": "Fail2Ban und Lynis für Proxmox VE: Einbruchsschutz und Härtungsprüfung, installiert und verwaltet durch ProxMenux.",
|
||||
"twitterTitle": "Proxmox Sicherheit | ProxMenux",
|
||||
"twitterDescription": "Fail2Ban und Lynis für Proxmox VE: Einbruchsschutz und Härtungsprüfung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sicherheit",
|
||||
"description": "Zwei ergänzende Sicherheitswerkzeuge für Proxmox VE: aktive Abwehr (Fail2Ban sperrt IP-Adressen, die SSH oder Weboberflächen angreifen) und Offline-Prüfung (Lynis sucht Härtungslücken und vergibt 0–100 Punkte). Beide haben ein eigenes Installations- und Verwaltungsmenü, das vorhandene Installationen vor jeder Aktion erkennt.",
|
||||
"section": "Sicherheit"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Aktive Abwehr und Offline-Prüfung",
|
||||
"body": "Sie beantworten unterschiedliche Fragen. <strong>Fail2Ban</strong> beantwortet <em>„Werden wir gerade angegriffen?“</em>, indem es Anmeldeprotokolle überwacht und angreifende IP-Adressen sperrt. <strong>Lynis</strong> beantwortet <em>„Wie gut ist dieser Host gehärtet?“</em> mit einer einmaligen Prüfung und konkreten Empfehlungen. Nutzen Sie beide: Lynis zeigt Verbesserungen auf, Fail2Ban reagiert auf laufende Angriffe."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Menüs",
|
||||
"body": "Wählen Sie im ProxMenux-Hauptmenü <strong>Sicherheit</strong>. Folgendes wird angezeigt :",
|
||||
"imageAlt": "Sicherheitsmenü mit Fail2Ban und Lynis Optionen"
|
||||
},
|
||||
"pick": {
|
||||
"heading": "Wählen Sie Ihr Werkzeug",
|
||||
"body": "Die beiden Werkzeuge sind unabhängig: Installieren Sie eines, beide oder keines. Jede Karte unten führt zum Abschnitt mit der ausführlichen Erklärung."
|
||||
},
|
||||
"cards": {
|
||||
"fail2ban": {
|
||||
"title": "Fail2Ban",
|
||||
"body": "Aktiver Einbruchsschutz. Überwacht Anmeldeprotokolle von SSH und Weboberflächen und sperrt IP-Adressen nach wiederholten Fehlversuchen.",
|
||||
"bullets": [
|
||||
"Drei jails: SSH, Proxmox UI (8006), ProxMenux Monitor (8008)",
|
||||
"Korrigiert Proxmox-Standardeinstellungen von journald, die Anmeldeprotokolle blockieren",
|
||||
"Erkennt nftables / iptables automatisch",
|
||||
"SSH-Härtung: MaxAuthTries=3 (Empfehlung von Lynis)"
|
||||
]
|
||||
},
|
||||
"lynis": {
|
||||
"title": "Lynis",
|
||||
"body": "Offline-Sicherheitsprüfer. Prüft den Host und zeigt eine Härtungsbewertung sowie konkrete Hinweise zur Behebung von Problemen.",
|
||||
"bullets": [
|
||||
"Aus dem offiziellen CISOfy-GitHub-Repository installiert (neueste Version)",
|
||||
"Härtungsbewertung 0–100 und Liste mit Warnungen und Vorschlägen",
|
||||
"Prüfung und Aktualisierung über das Menü",
|
||||
"Nur lesend konzipiert: verändert das System nicht"
|
||||
]
|
||||
}
|
||||
},
|
||||
"workflowTip": {
|
||||
"title": "Workflow, der beides nutzt",
|
||||
"body": "Führen Sie zuerst Lynis aus, um Ausgangsbewertung und wichtigste Empfehlungen zu sehen. Setzen Sie gewünschte Korrekturen um. Installieren Sie dann Fail2Ban: Es setzt automatisch den SSH-Brute-Force-Schutz um und passt <code>MaxAuthTries</code> in <code>sshd_config</code> an die Prüfung SSH-7408 an. Prüfen Sie anschließend mit Lynis die Verbesserung."
|
||||
},
|
||||
"fail2banSection": {
|
||||
"heading": "Fail2Ban",
|
||||
"body": "ProxMenux installiert Fail2Ban mit einer speziell für Proxmox optimierten Konfiguration. Über den Standard SSH jail hinaus bietet es Schutz für das Proxmox-Web UI und das ProxMenux Monitor und umgeht zwei Proxmox-spezifische Macken: eine journald-Standardeinstellung, die Authentifizierungsereignisse verwirft, und die systemd-Backend-Problem, das verhindert, dass Fail2Ban bestimmte Journalquellen zuverlässig liest. Die Detailseite behandelt den vollständigen Installationsablauf, die drei jails, den journald-Fix, die SSH-Härtungsänderung und den Fehlerbehebungs-Cheatsheet.",
|
||||
"optionTitle": "Fail2Ban — installieren und verwalten",
|
||||
"optionDescription": "Drei vorkonfigurierte Jails (sshd aggressiv, Proxmox-Weboberfläche auf 8006, ProxMenux Monitor auf 8008 und Reverse Proxy), automatische nftables/iptables-Erkennung, journald-Korrektur und SSH-Härtung mit MaxAuthTries."
|
||||
},
|
||||
"lynisSection": {
|
||||
"heading": "Lynis",
|
||||
"body": "ProxMenux klont Lynis von <code>github.com/CISOfy/lynis</code> nach <code>/opt/lynis</code> und macht es als <code>/usr/local/bin/lynis</code> verfügbar. Das Debian-Paket wird bewusst vermieden, da es mehrere Hauptversionen hinter dem Originalprojekt liegt. Die Detailseite erklärt Installation, Prüfung, Aktualisierung, Deinstallation, Auswertung des Berichts und Umsetzung der Ergebnisse.",
|
||||
"optionTitle": "Lynis — installieren, auditieren und verwalten",
|
||||
"optionDescription": "Installiert das neueste Lynis aus dem offiziellen CISOfy GitHub-Repo (nicht das ältere Debian-Paket), führt Systemaudits mit Hardening-Score und Updates per Git Pull aus."
|
||||
},
|
||||
"componentStatus": {
|
||||
"heading": "Komponentenstatus",
|
||||
"body": "Beide Installateure registrieren ihren Status in <code>/usr/local/share/proxmenux/components_status.json</code> unter der Kategorie <code>security</code>. ProxMenux verwendet diese Datei, um zu entscheiden, ob die Installation oder das Menü bei nachfolgenden Durchläufen angezeigt werden soll, und die gleichen Daten speisen die Dashboards im ProxMenux Monitor, wenn vorhanden."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Lynis | ProxMenux-Dokumentation",
|
||||
"description": "Installieren Sie die neueste Lynis-Version aus dem offiziellen CISOfy-GitHub-Repository, führen Sie eine Sicherheitsprüfung mit Härtungsbewertung 0–100 aus und aktualisieren Sie per git pull. Rein lesende Prüfung ohne Systemänderungen.",
|
||||
"ogTitle": "Lynis | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Lynis-Sicherheitsprüfung auf Proxmox VE installieren und ausführen. Installation aus dem Original-GitHub-Repository, Prüfung und Aktualisierung."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lynis",
|
||||
"description": "Klont die neueste Lynis-Version aus dem offiziellen CISOfy-GitHub-Repository, stellt sie als /usr/local/bin/lynis bereit und bietet Prüfung, Aktualisierung, Neuinstallation und Deinstallation im Menü. Der Auditor liest nur und meldet Ergebnisse, ohne das System zu ändern.",
|
||||
"section": "Sicherheit"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Installiert Lynis, den Open-Source-Sicherheitsprüfer von CISOfy, aus dessen GitHub-Repository nach <code>/opt/lynis</code> und erstellt einen Starter unter <code>/usr/local/bin/lynis</code> für den Aufruf über <code>PATH</code>. Eine vorhandene Installation öffnet stattdessen ein Verwaltungsmenü für Prüfung, Aktualisierung, Neuinstallation oder Entfernung."
|
||||
},
|
||||
"manageMenu": {
|
||||
"heading": "Verwaltungsmenü (nach der Installation)",
|
||||
"intro": "Nach der Installation öffnet jeder weitere Aufruf das Verwaltungsmenü. Dort können Sie eine Prüfung starten, per git pull aktualisieren, neu installieren oder deinstallieren.",
|
||||
"imageAlt": "Lynis Management Menü mit Audit, Update, Neuinstallation und Entfernen von Optionen"
|
||||
},
|
||||
"whyUpstream": {
|
||||
"heading": "Warum das Original-GitHub-Repository statt apt",
|
||||
"intro": "Debian bietet Lynis über apt an, doch das Paket liegt meist mehrere Hauptversionen hinter dem Originalprojekt. Neue Prüfungen, Korrekturen für neue Angriffsvektoren und überarbeitete Empfehlungen erscheinen zuerst auf GitHub. Lynis ist ein eigenständiges Shell-Skript ohne Kompilierung und ohne weitere Installationsabhängigkeiten außer <code>git</code>; CISOfy empfiehlt daher das Klonen des Repositorys.",
|
||||
"headerSource": "Quelle",
|
||||
"headerPath": "Install path",
|
||||
"headerUpdate": "Aktualisierungsmethode",
|
||||
"headerFresh": "Aktualität der Version",
|
||||
"rows": [
|
||||
{
|
||||
"sourceRich": "<strong>ProxMenux (dieses Skript)</strong>",
|
||||
"path": "/opt/lynis/",
|
||||
"update": "git pull (im Menü)",
|
||||
"fresh": "Neueste Version des Originalprojekts"
|
||||
},
|
||||
{
|
||||
"sourceRich": "<strong>Debian apt</strong>",
|
||||
"path": "/usr/bin/lynis",
|
||||
"update": "apt upgrade",
|
||||
"fresh": "Oft Monate / Jahre zurück"
|
||||
}
|
||||
]
|
||||
},
|
||||
"install": {
|
||||
"heading": "Wie die Installation funktioniert",
|
||||
"node1Label": "github.com/CISOfy/lynis",
|
||||
"node1Detail": "git clone\n(git zuerst installieren, falls nicht vorhanden)",
|
||||
"node2Label": "/opt/lynis/",
|
||||
"node2Detail": "Vollständiges Repo\neinschließlich ./lynis Skript",
|
||||
"node3Label": "/usr/local/bin/lynis",
|
||||
"node3Detail": "Umschlag:\ncd /opt/lynis && ./lynis $@",
|
||||
"outro": "Der Wrapper ist obligatorisch - Lynis besteht darauf, aus seinem eigenen Verzeichnis ausgeführt zu werden, da er relative Pfade für Plugins und Profildaten lädt. Der Wrapper verbirgt dieses Detail, so dass <code>lynis audit system</code> von überall aus funktioniert."
|
||||
},
|
||||
"detection": {
|
||||
"heading": "Detektionspfade",
|
||||
"intro": "Bevor Sie das Menü anzeigen, überprüft das Skript drei Standorte, um zu entscheiden, ob Lynis bereits vorhanden ist:",
|
||||
"items": [
|
||||
"<code>/usr/local/bin/lynis</code> — Wrapper installiert von ProxMenux",
|
||||
"<code>/opt/lynis/lynis</code> — direkter Pfad (falls der Wrapper entfernt wurde)",
|
||||
"<code>/usr/bin/lynis</code> — apt-installierte Version, wenn der Benutzer es zuvor so installiert hat"
|
||||
],
|
||||
"outro": "Wird einer dieser Pfade gefunden, öffnet sich das Verwaltungsmenü. Das Skript deinstalliert <strong>kein</strong> über apt installiertes Lynis, sondern nur die selbst verwaltete Installation in <code>/opt/lynis</code> samt Starter."
|
||||
},
|
||||
"audit": {
|
||||
"heading": "Durchführung eines Audits",
|
||||
"intro": "Wählen Sie im Verwaltungsmenü <strong>Sicherheitsprüfung jetzt ausführen</strong>. Das entspricht folgendem Aufruf :",
|
||||
"code": "lynis audit system --no-colors",
|
||||
"outro": "Die Prüfung dauert je nach Hostgröße 30 Sekunden bis einige Minuten. Die Ausgabe erscheint direkt im Terminal, ohne Warteanimation. Lynis gliedert die Prüfungen nach Kategorien und kennzeichnet Tests mit <ok>[ OK ]</ok>, <warn>[ WARNING ]</warn> oder <sugg>[ SUGGESTION ]</sugg>. Die abschließende Zusammenfassung enthält die wichtigsten Zahlen :",
|
||||
"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": "Lesen Sie den Bericht",
|
||||
"intro": "Die beiden wichtigen Abschnitte sind <strong>Warnings</strong> (Dinge, die Sie bald beheben sollten) und <strong>Suggestions</strong> (Empfehlungen zur Verbesserung der Härtung). Jedes Element trägt eine Kontroll-ID wie <code>SSH-7408</code> - nützlich bei der Suche nach den Lynis-Dokumenten für die Gründe und die Korrektur.",
|
||||
"headerMarker": "Markierung",
|
||||
"headerMeaning": "Bedeutung",
|
||||
"headerAction": "Aktion",
|
||||
"rows": [
|
||||
{
|
||||
"markerRich": "<strong>OK</strong>",
|
||||
"meaning": "Test bestanden",
|
||||
"action": "Nichts"
|
||||
},
|
||||
{
|
||||
"markerRich": "<strong>WARNING</strong>",
|
||||
"meaning": "Echtes Problem, Fix empfohlen",
|
||||
"action": "Lesen Sie die Prüfungsbeschreibung und planen Sie eine Korrektur."
|
||||
},
|
||||
{
|
||||
"markerRich": "<strong>SUGGESTION</strong>",
|
||||
"meaning": "Härtungsverbesserung verfügbar",
|
||||
"action": "Umsetzen, wenn es zu Ihrem Bedrohungsmodell passt"
|
||||
}
|
||||
],
|
||||
"outro": "Der vollständige Bericht und die maschinenlesbaren Daten werden von Lynis selbst in <code>/var/log/lynis.log</code> und <code>/var/log/lynis-report.dat</code> geschrieben."
|
||||
},
|
||||
"pairFail2ban": {
|
||||
"title": "Mit Fail2Ban kombinieren",
|
||||
"body": "SSH-7408 (MaxAuthTries) ist eine der häufigsten Warnungen. Die Installation von <link>Fail2Ban</link> aus ProxMenux löscht es automatisch, da der Installer <code>MaxAuthTries=3</code> als Teil seines SSH-Härtungsschritts einstellt. Führen Sie Lynis danach erneut aus, um zu bestätigen, dass die Warnung verschwunden ist."
|
||||
},
|
||||
"update": {
|
||||
"heading": "Lynis aktualisieren",
|
||||
"body": "Im Verwaltungsmenü führt <strong>Lynis auf die neueste Version aktualisieren</strong> den Befehl <code>git pull --quiet</code> in <code>/opt/lynis</code> aus. Ist das Verzeichnis keine Git-Arbeitskopie, etwa nach manuellem Kopieren der Dateien, wird vollständig neu installiert."
|
||||
},
|
||||
"reinstall": {
|
||||
"heading": "Reinstallieren / Deinstallieren",
|
||||
"headerAction": "Aktion",
|
||||
"headerWhat": "Was es tut",
|
||||
"rows": [
|
||||
{
|
||||
"actionRich": "<strong>Neu installieren</strong>",
|
||||
"whatRich": "Entfernt <code>/opt/lynis</code>, klont erneut von GitHub und erstellt den Starter neu. Für eine beschädigte lokale Arbeitskopie."
|
||||
},
|
||||
{
|
||||
"actionRich": "<strong>Entfernen</strong>",
|
||||
"whatRich": "Löscht <code>/opt/lynis</code> und <code>/usr/local/bin/lynis</code>. Protokolle bei <code>/var/log/lynis*</code> werden aufbewahrt (sie sind Audit-Historie). Ein apt-installiertes Lynis bei <code>/usr/bin/lynis</code> bleibt unberührt."
|
||||
}
|
||||
]
|
||||
},
|
||||
"cli": {
|
||||
"heading": "Nützliche CLI Optionen",
|
||||
"intro": "Einmal installiert, kann Lynis direkt von einer Shell aus aufgerufen werden, wobei zusätzliche Optionen im Menü nicht angezeigt werden:",
|
||||
"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": "Fehlerbehebung",
|
||||
"cloneTitle": "git clone schlägt bei der Installation fehl",
|
||||
"cloneBody": "Der Host benötigt Netzwerkzugang und DNS, um <code>github.com</code> zu erreichen. Von einer Konsole: <code>curl -sI https://github.com</code> und <code>git ls-remote https://github.com/CISOfy/lynis.git</code> wird der tatsächliche Fehler (DNS, TLS, Proxy, Repo-URL) enthüllt. Wenn ein Proxy erforderlich ist, legen Sie <code>https_proxy</code> in der Umgebung fest, bevor Sie das Menü erneut ausführen.",
|
||||
"notFoundTitle": "lynis: Befehl nach der Installation nicht gefunden",
|
||||
"notFoundIntro": "Der Wrapper bei <code>/usr/local/bin/lynis</code> wurde entweder nicht erstellt oder entfernt. Schnellste Lösung: Neuinstallation aus dem Menü. Manuelle Fixierung:",
|
||||
"notFoundCode": "cat > /usr/local/bin/lynis <<'EOF'\n#!/bin/bash\ncd /opt/lynis && ./lynis \"$@\"\nEOF\nchmod +x /usr/local/bin/lynis",
|
||||
"sshTitle": "Die Prüfung zeigt \"Warning: Test SSH-7408 — MaxAuthTries set incorrectly\"",
|
||||
"sshIntro": "Der SSH-Daemon erlaubt zu viele Auth-Versuche pro Verbindung. Installieren Sie entweder <link>Fail2Ban</link> von ProxMenux (was <code>MaxAuthTries=3</code> automatisch einstellt) oder bearbeiten Sie <code>/etc/ssh/sshd_config</code> von Hand:",
|
||||
"sshCode": "sed -i 's/^#?MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config\nsystemctl reload sshd",
|
||||
"scoreTitle": "Score ging nach einem Proxmox-Upgrade zurück",
|
||||
"scoreBody": "Führen Sie <code>lynis update info</code> zuerst aus - ein Lynis-Update hat möglicherweise neue Steuerelemente hinzugefügt, die bestehende Konfiguration kennzeichnen. Aktualisieren Sie Lynis aus dem Menü, überprüfen Sie es erneut und sprechen Sie die neuen Erkenntnisse an."
|
||||
},
|
||||
"files": {
|
||||
"heading": "Dateien geschrieben",
|
||||
"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": "Beispielbericht",
|
||||
"intro": "ProxMenux Monitor erstellt zu jedem Lynis-Durchlauf eine mehrseitige PDF-Datei im <link>Reiter Sicherheit</link>. Die erste Seite fasst Härtungsbewertung, Systeminformationen und Sicherheitslage zusammen. Die weiteren Seiten erläutern jede Warnung, ordnen Vorschläge nach Auswirkung und enthalten das bei der Prüfung verwendete Paketinventar.",
|
||||
"imageAlt": "Erste Seite des Lynis Security Audit Report PDF – Zusammenfassung mit Hardening Index 71/100, Systeminformationsblock und Sicherheitsübersicht mit Firewall, Malware-Scanner und installierten Paketen",
|
||||
"captionPrefix": "Erste Seite eines Beispielberichts. Die vollständige PDF-Datei (",
|
||||
"captionLink": "Probe",
|
||||
"captionSuffix": ") fährt mit detaillierten Warnungen, Vorschlägen und der Liste der installierten Pakete fort.",
|
||||
"cli": "Auf der CLI-Seite befinden sich die gleichen Daten in <code>/var/log/lynis-report.dat</code> (maschinenlesbare Flat-Datei) und <code>/var/log/lynis.log</code> (das vom Menschen lesbare Run-Log). Die PDF-Datei wird auf Anfrage von ProxMenux Monitor generiert – die Ausführung von <code>lynis</code> aus der Befehlszeile erzeugt keine."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/security",
|
||||
"label": "ProxMenux Monitor - Sicherheits-Tab",
|
||||
"tail": " — Prüfung ausführen, frühere Berichte ansehen und die PDF-Datei direkt aus dem Dashboard herunterladen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/security/fail2ban",
|
||||
"label": "Fail2Ban",
|
||||
"tailRich": "- implementiert den von Lynis empfohlenen Brute-Force-Schutz SSH."
|
||||
},
|
||||
{
|
||||
"href": "/docs/security",
|
||||
"label": "Sicherheitsübersicht",
|
||||
"tail": " — zurück zur Abschnittsübersicht."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,169 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "HTTPS für ProxMenux Monitor — Proxmox-Hostzertifikat oder eigene Pfade | ProxMenux",
|
||||
"description": "Stellen Sie ProxMenux Monitor per HTTPS bereit, mit dem automatisch erkannten Proxmox-Hostzertifikat, einschließlich eines über Proxmox ACME installierten Let’s-Encrypt-Zertifikats, oder einem eigenen Zertifikat an beliebiger Stelle auf dem Datenträger.",
|
||||
"ogTitle": "HTTPS für ProxMenux Monitor — Proxmox-Host oder benutzerdefiniertes Zertifikat",
|
||||
"ogDescription": "Aktivieren Sie HTTPS am Port 8008 mit dem Proxmox-Hostzertifikat oder einem benutzerdefinierten .pem / .key-Paar."
|
||||
},
|
||||
"header": {
|
||||
"title": "HTTPS für ProxMenux Monitor",
|
||||
"description": "Aktivieren Sie HTTPS für Monitor auf Port 8008 mit dem automatisch erkannten Proxmox-Hostzertifikat oder einem eigenen Zertifikat auf dem Datenträger. Die Proxmox-Option bevorzugt das ACME-Zertifikat, falls vorhanden, und nutzt das von Proxmox verwaltete Let’s-Encrypt-Zertifikat ohne eigene Erneuerungsaufgabe.",
|
||||
"section": "Sicherheit"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was diese Seite abdeckt",
|
||||
"body": "So wechseln Sie Monitor unter Einstellungen → Sicherheit von HTTP auf HTTPS, welche Dateien die Zertifikatsquellen verwenden, wie die Proxmox-Option mit Let’s Encrypt umgeht und wie Sie eigene Pfade für außerhalb von Proxmox verwaltete Zertifikate festlegen."
|
||||
},
|
||||
"wheresetting": {
|
||||
"heading": "Wo Sie die Einstellung finden",
|
||||
"body": "Öffnen Sie Monitor und gehen Sie zu <strong>Einstellungen → Sicherheit → HTTPS / SSL</strong>. Der Bereich zeigt HTTP oder HTTPS und bei noch deaktiviertem HTTPS die erkannten Zertifikatsquellen.",
|
||||
"imageAlt": "Einstellungen → Sicherheit → HTTPS / SSL mit deaktiviertem HTTPS, erkanntem Proxmox-Zertifikat (Inhaber, Aussteller, Ablauf) und der Option für ein eigenes Zertifikat",
|
||||
"caption": "Bereich Einstellungen → Sicherheit → HTTPS / SSL vor der Aktivierung. Monitor zeigt das von Proxmox verwendete Zertifikat und bietet es zur Auswahl mit einem Klick an."
|
||||
},
|
||||
"twoways": {
|
||||
"heading": "Zwei Möglichkeiten, HTTPS zu aktivieren",
|
||||
"proxmox": {
|
||||
"title": "Das Proxmox-Zertifikat verwenden",
|
||||
"summary": "Ein Klick: Monitor nutzt das Zertifikat, das Proxmox VE auf Port 8006 bereitstellt.",
|
||||
"items": [
|
||||
"Automatisch erkannt, keine Pfadeingabe erforderlich",
|
||||
"Bevorzugt das ACME-Zertifikat, falls vorhanden; andernfalls das selbstsignierte Standardzertifikat",
|
||||
"Proxmox erneuert; Monitor prüft und lädt das Zertifikat bei der nächsten neuen TLS-Verbindung"
|
||||
]
|
||||
},
|
||||
"custom": {
|
||||
"title": "Benutzerdefiniertes Zertifikat verwenden",
|
||||
"summaryRich": "Richten Sie den Monitor auf ein <code>.pem</code> / <code>.key</code>-Paar überall auf der Festplatte.",
|
||||
"items": [
|
||||
"Nur absolute Pfade (der Monitor-Prozess muss beide lesen können)",
|
||||
"Nützlich, wenn Zertifikate von <code>certbot</code>, <code>acme.sh</code> oder einer Wildcard stammen",
|
||||
"Sie verwalten die Erneuerung: Starten Sie Monitor nach Dateiänderungen neu"
|
||||
]
|
||||
}
|
||||
},
|
||||
"proxmoxCert": {
|
||||
"heading": "Proxmox-Zertifikat - was es tatsächlich zeigt",
|
||||
"intro": "Proxmox VE führt zwei Zertifikatspaare in <code>/etc/pve/local/</code>:",
|
||||
"table": {
|
||||
"headers": {
|
||||
"file": "Datei",
|
||||
"origin": "Ursprung",
|
||||
"when": "Wenn der Monitor es verwendet"
|
||||
},
|
||||
"rows": [
|
||||
{
|
||||
"fileRich": "<code>pveproxy-ssl.pem</code><br /><code>pveproxy-ssl.key</code>",
|
||||
"originRich": "Benutzerdefiniertes Zertifikat, das über die Proxmox-Benutzeroberfläche hochgeladen wird - einschließlich des Let's Encrypt-Zertifikats, das unter <em>Datacenter → Node → Certificates → ACME</em> ausgestellt wurde.",
|
||||
"when": "Bevorzugt, wenn beide Dateien existieren; Monitor nutzt das von Proxmox bereitgestellte Zertifikat."
|
||||
},
|
||||
{
|
||||
"fileRich": "<code>pve-ssl.pem</code><br /><code>pve-ssl.key</code>",
|
||||
"originRich": "Selbstsigniertes Zertifikat, das zum Zeitpunkt der Installation vom Proxmox PKI generiert wurde.",
|
||||
"whenRich": "Fallback, wenn kein <code>pveproxy-ssl.pem</code> vorhanden ist."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
"title": "Gleiche Priorität wie Proxmox selbst",
|
||||
"bodyRich": "<code>pveproxy</code> nutzt dieselbe Auswahlregel. Mit der Proxmox-Option verwendet Monitor das Zertifikat der Proxmox-Weboberfläche auf Port 8006, ohne Kopieren oder getrennten Erneuerungsablauf."
|
||||
}
|
||||
},
|
||||
"letsencrypt": {
|
||||
"heading": "Erhalten eines Let's Encrypt Zertifikats über Proxmox ACME",
|
||||
"intro": "Proxmox VE enthält einen eigenen ACME-Client. <em>„Order Certificate Now“</em> speichert das Ergebnis in <code>/etc/pve/local/pveproxy-ssl.pem</code>, das Monitor liest. Die folgenden fünf Schritte fassen die <extlink1>offizielle Proxmox-Anleitung</extlink1> in den benötigten Befehlen zusammen.",
|
||||
"prereqs": {
|
||||
"title": "Voraussetzungen",
|
||||
"items": [
|
||||
"Der Knoten hat einen echten DNS-Namen (nicht nur eine IP), der darauf zeigt.",
|
||||
"<strong>Entweder</strong> Port 80 aus dem Internet erreichbar (HTTP-01-Prüfung, am einfachsten) <strong>oder</strong> ein DNS-Anbieter mit API-Zugangsdaten (DNS-01, funktioniert hinter NAT und unterstützt Wildcards).",
|
||||
"Eine E-Mail-Adresse für das ACME-Konto."
|
||||
]
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Schritt 1 — Registrieren Sie das ACME-Konto",
|
||||
"introRich": "Ersetzen Sie die E-Mail durch Ihre. Der Kontoname <code>default</code> ist nur ein Label - Sie können eine beliebige Zeichenfolge verwenden.",
|
||||
"code": "pvenode acme account register default you@example.com",
|
||||
"afterRich": "Proxmox fordert Sie auf, die Nutzungsbedingungen von Let's Encrypt zu akzeptieren. Danach wird das Konto unter <code>/etc/pve/priv/acme/</code> fortgesetzt und die Registerkarte ACME in der GUI zeigt es an."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Schritt 2 - Wählen Sie einen Herausforderungstyp",
|
||||
"http01Rich": "<strong>HTTP-01</strong> ist das einfachste: es ist eingebaut, kein zusätzliches Plugin. Let's Encrypt verbindet sich mit <code>http://<your-host>/.well-known/acme-challenge/...</code> an Port 80, so dass Port 80 vom öffentlichen Internet zu Ihrem Knoten geöffnet sein muss - normalerweise ein Port vorwärts auf Ihrem Router.",
|
||||
"dns01Rich": "<strong>DNS-01</strong> funktioniert ohne Port 80 (gut für Homelabs hinter CG-NAT) und ist die einzige Option für Wildcard-Zertifikate. Sie fügen ein DNS-Plugin einmal mit dem API-Token Ihres Providers hinzu. Cloudflare Beispiel:",
|
||||
"code": "pvenode acme plugin add dns cf \\\n --api cloudflare \\\n --data CF_Token=YOUR_CLOUDFLARE_API_TOKEN",
|
||||
"outroRich": "Für andere Anbieter (Gandi, OVH, AWS Route 53 usw.) nutzen Sie <code>pvenode acme plugin add dns --help</code>. Proxmox enthält <extlink2>alle DNS-Plugins von acme.sh</extlink2>."
|
||||
},
|
||||
"step3": {
|
||||
"heading": "Schritt 3 - Binden Sie die Domain an Ihren Knoten",
|
||||
"http01Rich": "Für HTTP-01 (verwendet das eingebaute <code>standalone</code>-Plugin):",
|
||||
"code1": "pvenode config set --acme domains=host.example.com,account=default",
|
||||
"dns01": "Für DNS-01 mit dem Cloudflare-Plugin aus Schritt 2:",
|
||||
"code2": "pvenode config set --acmedomain0 domain=host.example.com,plugin=cf\npvenode config set --acme account=default",
|
||||
"wildcardRich": "Wildcard? Fügen Sie <code>domain=*.example.com</code> auf einem separaten <code>--acmedomainN</code>-Eintrag hinzu. Wildcards erfordern DNS-01."
|
||||
},
|
||||
"step4": {
|
||||
"heading": "Schritt 4 — Bestellen Sie das Zertifikat",
|
||||
"code": "pvenode acme cert order",
|
||||
"afterRich": "Der erste Lauf dauert normalerweise 30–60 Sekunden, während sich die Herausforderung ausbreitet. Beim Erfolg schreibt Proxmox <code>/etc/pve/local/pveproxy-ssl.pem</code> + <code>.key</code>, startet <code>pveproxy</code> neu und ein Erneuerungs-Cron wird automatisch geplant (Let's Encrypt Zertifikate sind gültig 90 Tage; Proxmox erneuert bei 60)."
|
||||
},
|
||||
"step5": {
|
||||
"heading": "Schritt 5 — Überprüfung des Emittenten",
|
||||
"code": "openssl x509 -in /etc/pve/local/pveproxy-ssl.pem -noout -issuer",
|
||||
"afterRich": "Sollte einen Emittenten ab <code>O = Let's Encrypt</code> drucken. Wenn stattdessen <code>CN = Proxmox Virtual Environment</code> gelesen wird, ist die Bestellung fehlgeschlagen und die Datei ist immer noch das selbstsignierte PVE-Zertifikat - führen Sie <code>pvenode acme cert order --debug 1</code> erneut aus, um zu sehen, warum."
|
||||
},
|
||||
"gui": {
|
||||
"title": "Bevorzugen Sie die GUI? Gleiche fünf Schritte",
|
||||
"bodyRich": "<em>Datacenter → ACME</em> registriert das Konto; <em>Datacenter → ACME → Plugins</em> fügt das DNS-Plugin hinzu; <em>Node → Certificates → ACME</em> verknüpft die Domain; <em>Order Certificates Now</em> führt Schritt 4 aus. Die obigen CLI-Befehle eignen sich für Skripte und Systeme ohne grafische Oberfläche."
|
||||
}
|
||||
},
|
||||
"switchToHttps": {
|
||||
"heading": "Schalten Sie den Monitor auf HTTPS",
|
||||
"bodyRich": "Sobald <code>/etc/pve/local/pveproxy-ssl.pem</code> von Let's Encrypt signiert ist, öffnen Sie <strong>Einstellungen → Sicherheit → HTTPS / SSL</strong>, prüfen als Aussteller <em>Let's Encrypt</em> statt der lokalen Proxmox-CA und wählen <strong>Proxmox-Zertifikat verwenden</strong>. Monitor startet neu und der nächste Aufruf nutzt HTTPS auf 8008 mit öffentlich vertrauenswürdiger Zertifikatskette. Spätere ACME-Erneuerungen werden bei der nächsten neuen TLS-Verbindung geprüft und ausgewählt, ohne regelmäßige Abfrage oder Dienstneustart zur Erneuerung. <strong>Zertifikat aktualisieren</strong> bleibt unter Sicherheit für Diagnose und Wiederherstellung verfügbar."
|
||||
},
|
||||
"custom": {
|
||||
"heading": "Benutzerdefiniertes Zertifikat — wann es sinnvoll ist",
|
||||
"intro": "Klicken Sie auf <strong>Benutzerdefiniertes Zertifikat verwenden</strong> und geben Sie zwei absolute Pfade ein :",
|
||||
"items": [
|
||||
"<strong>Zertifikat</strong>: vollständige Kette im PEM-Format (<code>.pem</code> oder <code>.crt</code>).",
|
||||
"<strong>Privater Schlüssel</strong>: passender Schlüssel im PEM-Format (<code>.key</code>)."
|
||||
],
|
||||
"outro": "Beide Dateien werden beim Start vom Monitor-Prozess gelesen. Sie müssen für den Benutzer lesbar bleiben, unter dem die systemd-Unit läuft (standardmäßig root). Übliche Orte bei ACME-Verwaltung außerhalb von Proxmox:",
|
||||
"code": "# certbot\n/etc/letsencrypt/live/<your-host>/fullchain.pem\n/etc/letsencrypt/live/<your-host>/privkey.pem\n\n# acme.sh\n~/.acme.sh/<your-host>_ecc/fullchain.cer\n~/.acme.sh/<your-host>_ecc/<your-host>.key",
|
||||
"symlinkCallout": {
|
||||
"title": "Symlink-Ziele vs. Dateien",
|
||||
"bodyRich": "<code>certbot</code> speichert die eigentlichen Dateien in <code>/etc/letsencrypt/archive/</code> und der <code>live/</code>-Pfad ist ein Symlink. Richten Sie den Monitor auf den <code>live/</code>-Symlink, nicht auf die <code>archive/</code>-Datei - so schreibt jeder Erneuerungszyklus einfach das Symlink-Ziel um und der Monitor nimmt das neue Zertifikat beim nächsten Servicestart entgegen."
|
||||
}
|
||||
},
|
||||
"afterHttps": {
|
||||
"heading": "Nach Aktivierung von HTTPS",
|
||||
"bodyRich": "Das Speichern der Änderung schreibt <code>/etc/proxmenux/ssl_config.json</code> und löst einen Neustart der <code>proxmenux-monitor</code> systemd Einheit aus. Die Browser-Registerkarte verliert ihre aktuelle Verbindung - laden Sie sie auf <code>https://<host>:8008/</code> neu. Die erste Ladung mit einem Let's Encrypt-Zertifikat sollte keine Warnung zeigen; mit dem selbstsignierten Proxmox-Zertifikat benötigt der Browser eine Ausnahme, die gleiche wie für Port 8006.",
|
||||
"reverse": {
|
||||
"heading": "Reverse Proxys und Webhooks",
|
||||
"bodyRich": "Wenn der Monitor zu HTTPS wechselt, schalten auch die für Benachrichtigungen registrierten Proxmox VE-webhook-URLs automatisch von <code>http://</code> zu <code>https://</code> um. Bestehende webhook-Einträge werden beim nächsten Speichern oder erneuten Erkennen einer Benachrichtigungsregel neu geschrieben, so dass keine manuelle Bearbeitung der Proxmox-Benachrichtigungskonfiguration erforderlich ist."
|
||||
}
|
||||
},
|
||||
"trustCa": {
|
||||
"heading": "Der selbstsignierten Proxmox-CA vertrauen",
|
||||
"intro1Rich": "Um das Proxmox-Standardzertifikat ohne ACME zu behalten, importieren Sie die Cluster-Stamm-CA in den Zertifikatsspeicher von Betriebssystem oder Browser. Monitor erkennt <code>/etc/pve/local/pve-ssl.pem</code> als Ersatzzertifikat. Der Client vertraut dadurch dem Aussteller; die URL muss weiterhin zu einem Namen im Zertifikat passen.",
|
||||
"intro2Rich": "Die CA-Datei lebt bei <code>/etc/pve/pve-root-ca.pem</code> auf jedem Knoten. In einem Cluster befindet sich der Pfad auf dem gemeinsamen <code>pmxcfs</code>-Dateisystem, so dass alle Knoten die gleiche Wurzel teilen und ein einziger Import das gesamte Rechenzentrum abdeckt. Kopieren Sie es auf Ihre Maschine:",
|
||||
"code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
|
||||
"thenImport": "Importieren Sie die Datei anschließend auf dem Client:",
|
||||
"items": [
|
||||
"<strong>Linux (systemweit):</strong> Führen Sie <code>sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt</code> und anschließend <code>sudo update-ca-certificates</code> aus. Browser mit System-Zertifikatsspeicher (Chromium, Edge) erkennen die CA nach dem Neustart; Firefox nutzt seinen eigenen Speicher und benötigt den folgenden manuellen Import.",
|
||||
"<strong>macOS:</strong> Doppelklicken Sie auf die <code>.pem</code>-Datei. Fügen Sie sie in der Schlüsselbundverwaltung zum Schlüsselbund <em>System</em> hinzu und wählen Sie <em>Vertrauen → Immer vertrauen</em>.",
|
||||
"<strong>Windows:</strong> Rechtsklick auf die Datei → <em>Zertifikat installieren</em> → unter <em>Vertrauenswürdige Stammzertifizierungsstellen</em> ablegen.",
|
||||
"<strong>Firefox (jedes Betriebssystem):</strong> <em>Einstellungen → Datenschutz und Sicherheit → Zertifikate → Zertifikate anzeigen → Zertifizierungsstellen → Importieren</em>; aktivieren Sie <em>Dieser CA vertrauen, um Websites zu identifizieren</em>."
|
||||
],
|
||||
"standalone": {
|
||||
"title": "Standalone Knoten außerhalb eines Clusters",
|
||||
"bodyRich": "Jeder nicht geclusterte Proxmox-Host hat seinen eigenen <code>pve-root-ca.pem</code>. Wenn Sie mehrere eigenständige Hosts verwalten, wiederholen Sie die Kopie / den Import für jeden oder verbinden Sie sie zu einem Cluster, so dass sie sich eine einzelne Wurzel teilen."
|
||||
}
|
||||
},
|
||||
"disable": {
|
||||
"heading": "Deaktivierung von HTTPS",
|
||||
"bodyRich": "Wählen Sie im selben Bereich <strong>HTTPS deaktivieren</strong>. Monitor startet mit unverschlüsseltem HTTP neu, etwa wenn eine eigene Zertifikatsdatei unlesbar ist und der Dienst nicht startet. Es gibt keinen weiteren Deinstallationsschritt; Zertifikatsdateien bleiben unverändert.",
|
||||
"stateCallout": {
|
||||
"title": "Wo der Zustand gespeichert wird",
|
||||
"bodyRich": "<code>/etc/proxmenux/ssl_config.json</code> speichert die aktiven Zertifikatpfade und die Quelle (<code>none</code>, <code>proxmox</code>, <code>custom</code>). Das Löschen der Datei entspricht dem Deaktivieren von HTTPS - beim nächsten Start fällt der Monitor auf HTTP zurück."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,123 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Host: Hinzufügen von iSCSI-Ziel als Proxmox-Speicher | ProxMenux Dokumentation",
|
||||
"description": "Registrieren Sie ein iSCSI-Ziel als Proxmox-Speicher mit ProxMenux. Das Werkzeug installiert open-iscsi, erkennt Ziele am Portal per sendtargets, lässt ein Ziel auswählen und führt pvesm add iscsi aus. Es stellt rohe Blockgeräte für VM-Festplattenabbilder bereit.",
|
||||
"ogTitle": "Host: Hinzufügen von iSCSI-Ziel als Proxmox-Speicher | ProxMenux Dokumentation",
|
||||
"ogDescription": "Registrieren Sie ein iSCSI-Ziel als Proxmox-Speicher mit geführter Entdeckung. Verwendet pvesm add iscsi und bietet rohe Blockgeräte für VM Festplatten."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host: Hinzufügen von iSCSI-Ziel als Proxmox-Speicher",
|
||||
"description": "Registrieren Sie ein iSCSI-Ziel (von einem SAN, TrueNAS / FreeNAS, Synology, einem Windows Server-Ziel, einem Array, das iSCSI spricht) als Proxmox-Speicher. Die exportierten LUNs erscheinen als Blockgeräte und können VM-Disk-Images mit nahezu lokaler Leistung über das Netzwerk hosten.",
|
||||
"section": "Speicher und Freigaben · Host"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "ProxMenux wickelt <code>pvesm add iscsi</code> mit einem geführten Fluss ab: Es installiert <code>open-iscsi</code> bei Bedarf, fragt nach dem iSCSI-Portal (IP:port), führt <code>iscsiadm --mode discovery --type sendtargets</code> dagegen aus, lässt Sie einen Ziel-IQN auswählen und registriert den iSCSI-Speicher in Proxmox. Der <code>iscsid</code>-Dienst hält dann die iSCSI-Sitzung über Neustarts hinweg am Leben."
|
||||
},
|
||||
"vocab": {
|
||||
"heading": "iSCSI Vokabular (schnelle Referenz)",
|
||||
"headerTerm": "Begriff",
|
||||
"headerMeaning": "Bedeutung",
|
||||
"rows": [
|
||||
{
|
||||
"term": "Portal",
|
||||
"meaningRich": "Der iSCSI-Service-Endpunkt auf dem Zielserver – eine IP (oder ein Hostname) sowie ein TCP-Port. Standard-Port ist <code>3260</code>; ProxMenux nimmt es an, wenn Sie keinen angeben."
|
||||
},
|
||||
{
|
||||
"term": "Ziel",
|
||||
"meaningRich": "Ein einzelner exportierter \"Server\" innerhalb des Portals, der durch seine IQN identifiziert wird (<em>iSCSI Qualified Name</em>). Ein Portal kann viele Ziele hosten."
|
||||
},
|
||||
{
|
||||
"term": "IQN",
|
||||
"meaningRich": "Canonical Form ist <code>iqn.YYYY-MM.reverse.domain:identifier</code>, zum Beispiel <code>iqn.2024-08.com.truenas:proxmox-pool</code>. Sowohl das Ziel als auch der Initiator haben ihren eigenen IQN."
|
||||
},
|
||||
{
|
||||
"term": "LUN",
|
||||
"meaningRich": "Ein Blockgerät innerhalb eines Ziels (Logical Unit Number). Ein einzelnes Ziel kann mehrere LUNs freilegen; jede LUN erscheint als eigene Festplatte in Proxmox und kann eine VM-Festplatte werden."
|
||||
},
|
||||
{
|
||||
"term": "Initiator",
|
||||
"meaningRich": "Der Client, der sich mit einem Ziel verbindet - in diesem Fall Ihr Proxmox-Host. Der Initiator hat seine eigene IQN in <code>/etc/iscsi/initiatorname.iscsi</code> gespeichert. Ziele akzeptieren in der Regel nur Sitzungen von vorautorisierten Initiator-IQNs."
|
||||
}
|
||||
]
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → iSCSI Target als Proxmox Storage</strong> hinzufügen. Sie sehen dieses sub-Menü mit vier Optionen:",
|
||||
"imageAlt": "iSCSI Host Manager-Menü – Konnektivität hinzufügen / anzeigen / entfernen / testen"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft (Flow hinzufügen)",
|
||||
"body": "Der Fluss hat zwei Phasen mit klarer Trennung zwischen \"Einrichten des Initiators, Auffinden von Zielen\" und \"tatsächliche Registrierung von Speicher in Proxmox\". Im Gegensatz zu NFS / Samba gibt es keine automatische Entdeckung im Subnetz - Sie müssen die Portaladresse kennen (iSCSI ist nicht sendefreundlich)."
|
||||
},
|
||||
"add": {
|
||||
"heading": "Hinzufügen von iSCSI-Ziel als Proxmox-Speicher",
|
||||
"items": [
|
||||
"<strong>Portal eingeben</strong> — geben Sie die IP-Adresse oder den Hostnamen des iSCSI-Zielservers ein. Port <code>3260</code> wird angenommen, es sei denn, Sie geben <code>host:port</code> ein.",
|
||||
"<strong>Zielerkennung</strong> — ProxMenux ruft <code>iscsiadm --mode discovery --type sendtargets --portal <ip:port></code> auf. Der Server antwortet mit jedem IQN, den dieser Initiator sehen kann. Wenn die Entdeckung fehlschlägt, zeigt das Skript den genauen Fehler aus <code>iscsiadm</code> und listet die häufigsten Ursachen auf (falsche IP, Firewall, Initiator IQN nicht autorisiert).",
|
||||
"<strong>Zielauswahl</strong> — einzelnes Ziel wird automatisch ausgewählt; mehrere Ziele zeigen ein Menü an.",
|
||||
"<strong>Storage ID</strong> — Standard ist <code>iscsi-<last IQN segment, 20 chars max></code>. Nur Buchstaben, Ziffern, <code>-</code> und <code>_</code>.",
|
||||
"<strong>Inhaltstyp</strong> — im Gegensatz zu NFS/Samba ist der iSCSI-Inhalt <strong>fest auf <code>images</code></strong> eingestellt. iSCSI stellt rohe Blockgeräte bereit, kein Dateisystem; deshalb sind dort nur VM-Festplatten möglich."
|
||||
],
|
||||
"authTitle": "Autorisieren Sie den Proxmox-Initiator auf dem Target",
|
||||
"authBody1": "Bevor der Add-Flow Ende-zu-Ende funktioniert, muss das iSCSI-Ziel Ihren Proxmox-Host kennen. Holen Sie sich Ihren Initiator IQN:",
|
||||
"authBody2": "Fügen Sie dieses IQN zur Zugriffsliste des Ziels hinzu (TrueNAS: <em>Sharing → Block → Initiators Groups</em>; Synology: <em>SAN Manager → iSCSI → Target → Edit → Initiators</em>; usw.). Ist der Initiator nicht autorisiert, liefert die Erkennung mit <code>iscsiadm</code> eine leere Liste oder einen Authentifizierungsfehler."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Der gesamte Flow bildet diese Befehle ab:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Ansicht konfigurierter iSCSI-Speicher",
|
||||
"body": "Listet jeden iSCSI-Eintrag in Proxmox (<code>pvesm status | awk ''$2 == \"iscsi\"''</code>) mit Portal, Ziel-IQN, Inhaltstyp und Live-Status auf."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "iSCSI-Speicher entfernen",
|
||||
"body": "Führt <code>pvesm remove <storage-id></code> nach Bestätigung von Portal, Ziel und Inhalt aus. Nur die Proxmox-Registrierung wird entfernt - <strong>das iSCSI-Ziel selbst wird nicht berührt</strong> und bestehende Sitzungen auf der Kernelseite können bis zum nächsten Neustart verweilen.",
|
||||
"warnTitle": "Zuerst vorhandene VM-Festplatten auf diesem iSCSI prüfen",
|
||||
"warnBody": "Das Entfernen eines iSCSI-Speichers, während VMs noch Festplatten haben, lässt diese VMs auf einen verschwundenen Speicher zeigen. Proxmox markiert den Fehler, aber die LUN-Daten sind auf dem Ziel unberührt - Sie können den Speicher später erneut registrieren, um die Festplatten zurückzubekommen. Bewegen oder sichern Sie die VMs zuerst, um sicher zu sein."
|
||||
},
|
||||
"test": {
|
||||
"heading": "iSCSI-Konnektivität testen",
|
||||
"body": "Führt einen Diagnosedurchlauf aus: Prüft, ob <code>iscsiadm</code> installiert ist, druckt Ihren Initiator IQN aus, bestätigt, dass <code>iscsid</code> ausgeführt wird, pingt jedes registrierte Portal, prüft seinen Port und meldet <code>pvesm status</code> sowie, ob eine iSCSI-Sitzung derzeit aktiv ist (<code>iscsiadm --mode session</code>). Aktive Sitzung plus erreichbares Portal, aber \"inaktiv\" in Proxmox bedeutet normalerweise einen abgestandenen Zustand - versuchen Sie <code>pvesm set <id> --disable 0</code>."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"portalTitle": "\"Kann das Portal nicht erreichen\", aber die Server-IP antwortet an anderer Stelle",
|
||||
"portalBody": "Ping scheiterte an der Portaladresse. Überprüfen Sie, ob Sie die <em>storage-Netzwerk</em>-Schnittstelle erreichen (iSCSI lebt oft in einem separaten VLAN / Subnetz aus dem Verwaltungsnetzwerk). Überprüfen Sie auch DNS, wenn Sie einen Hostnamen eingegeben haben.",
|
||||
"discoverTitle": "\"iSCSI Discovery failed\" von iscsiadm",
|
||||
"discoverIntro": "Das Skript zeigt den genauen Fehler. Die häufigsten Ursachen:",
|
||||
"discoverItems": [
|
||||
"Portal IP / Port falsch (Doppelprüfung, standardmäßig 3260).",
|
||||
"iSCSI-Dienst läuft nicht auf dem Zielserver.",
|
||||
"Firewall blockiert 3260 zwischen Proxmox und dem Ziel.",
|
||||
"<strong>Die Initiator-IQN ist auf dem Ziel nicht autorisiert.</strong> Dies ist die häufigste Ursache bei Unternehmens-Arrays. Tragen Sie die Proxmox-IQN zuerst in die Initiator-ACL des Ziels ein."
|
||||
],
|
||||
"noTargetTitle": "Keine Ziele gefunden, aber Entdeckung erfolgreich",
|
||||
"noTargetBody": "Der Server hat Ihren Initiator akzeptiert, setzt ihm aber kein Ziel aus. Überprüfen Sie die Authentifizierung / Zugriffskontrollen des Ziels - einige Arrays ermöglichen die Erkennung für alle IQNs, filtern jedoch, welche Ziele jedes IQN sehen kann.",
|
||||
"noLunTitle": "LUNs erscheinen nicht in /dev/disk/by-path nach der Registrierung",
|
||||
"noLunBody": "<code>pvesm add iscsi</code> war erfolgreich, aber der Kernel sieht keine Blockgeräte. Überprüfen Sie <code>iscsiadm --mode session</code> - wenn keine Sitzung aktiv ist, starten Sie eine manuell mit <code>iscsiadm --mode node --login</code>. Wenn eine Sitzung existiert, aber keine LUNs angezeigt werden, erzwingen Sie ein Rescannen: <code>iscsiadm --mode session --rescan</code>. Wenn immer noch nichts, hat das Ziel wahrscheinlich noch keine LUNs diesem IQN zugewiesen (Konfigurieren Sie die LUN-Zuordnung auf dem Ziel).",
|
||||
"chapTitle": "CHAP-Authentifizierung",
|
||||
"chapBody": "ProxMenux bietet im interaktiven Ablauf keine Felder für CHAP-Benutzername und -Passwort. Schlägt die Erkennung fehl, stoppt das Skript vor <code>pvesm add</code>; der Speicher wird nicht trotzdem registriert. Konfigurieren Sie die CHAP-Anforderungen des Ziels separat in <code>open-iscsi</code>, einschließlich der Erkennungsauthentifizierung, falls nötig, und versuchen Sie es erneut. Prüfen Sie die Konfiguration mit <code>iscsiadm</code> und aktive Sitzungen mit <code>iscsiadm --mode session</code>."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "NFS-Freigabe als Proxmox-Speicher",
|
||||
"tail": "— Alternative auf Dateiebene. Einfacher einzurichten, flexibler (Backup / ISO / tmpl / Images), etwas langsamer für VM-Live-Disketten."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS als Proxmox-Speicher",
|
||||
"tail": " — eine weitere Option auf Dateiebene; wegen der Sperrsemantik für Festplatten laufender VMs vermeiden."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Lokale Festplatte als Proxmox-Speicher hinzufügen",
|
||||
"tail": "- wenn die Festplatte lokal auf dem Proxmox-Host ist, nicht auf einer anderen Box über das Netzwerk."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,186 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Host: Lokale Festplatte als Proxmox-Speicher hinzufügen | ProxMenux Dokumentation",
|
||||
"description": "Formatieren Sie einen lokalen SATA-, SAS- oder NVMe-Datenträger auf einem Proxmox-Host und registrieren Sie ihn als Verzeichnis- oder ZFS-Pool-Storage. Mit sicherer Datenträgerauswahl, Bestätigung vor destruktiven Schritten, UUID-basiertem fstab, ZFS-Pool-Erstellung und pvesm add dir / zfspool im Hintergrund.",
|
||||
"ogTitle": "Host: Lokale Festplatte als Proxmox-Speicher hinzufügen | ProxMenux Dokumentation",
|
||||
"ogDescription": "Formatieren Sie eine lokale Festplatte und registrieren Sie sie als Proxmox-Verzeichnis oder ZFS-Poolspeicher mit einem geführten, sicherheitsgefilterten Fluss."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host: Lokale Festplatte als Proxmox-Speicher hinzufügen",
|
||||
"description": "Nehmen Sie eine physische Festplatte auf dem Proxmox-Host, formatieren Sie sie optional (ext4 / xfs / btrfs / zfs) und registrieren Sie sie als Proxmox-Speicher - entweder als Verzeichnis (pvesm add dir) oder als ZFS-Pool (pvesm add zfspool). ProxMenux filtert die Festplattenliste, so dass Sie die Systemfestplatte oder etwas in Gebrauch nicht auswählen können, und macht jeden destruktiven Schritt explizit, bevor Sie sie ausführen.",
|
||||
"section": "Speicher und Freigaben · Host"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Andere <em>Host</em>-Tools in diesem Abschnitt befassen sich mit <strong>Netzwerkspeicher</strong> (NFS / Samba / iSCSI). Dieser befasst sich mit <strong>lokalen</strong> Festplatten - Ersatzlaufwerke, die physisch an Ihren Proxmox-Host angeschlossen sind und die Sie für VM-Festplatten, Backups, ISOs oder Vorlagen verwenden möchten. ProxMenux bereitet die Festplatte (Partition + Format + Mount) vor und registriert sie in Proxmox, damit die Benutzeroberfläche Inhalte dort platzieren kann."
|
||||
},
|
||||
"destructive": {
|
||||
"title": "Zerstörendes Werkzeug für den \"Format\"-Pfad",
|
||||
"body": "Der Ablauf <em>Formatieren</em> <strong>zerstört die vorhandenen Partitionen und Daten auf dem ausgewählten Datenträger</strong>. ProxMenux zeigt eine Warnung, filtert verwendete Datenträger heraus und verlangt eine Bestätigung vor <code>wipefs</code> / <code>sgdisk</code> / <code>mkfs</code>. Dies ist kein sicheres Überschreiben jedes Bytes. Prüfen Sie den Gerätepfad vor der Bestätigung zweimal."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "Verzeichnis oder ZFS-Pool — was wählen?",
|
||||
"headerDir": "Verzeichnis (ext4 / xfs / btrfs)",
|
||||
"headerZfs": "ZFS-Pool",
|
||||
"rows": [
|
||||
{
|
||||
"label": "Proxmox-Speichertyp",
|
||||
"dirRich": "<code>dir</code>",
|
||||
"zfsRich": "<code>zfspool</code>"
|
||||
},
|
||||
{
|
||||
"label": "VM Plattenformat",
|
||||
"dir": "qcow2-/raw-Datei in einem Dateisystem",
|
||||
"zfs": "Nativer ZFS-Datensatz (zvol) pro Festplatte"
|
||||
},
|
||||
{
|
||||
"label": "Momentaufnahmen",
|
||||
"dir": "qcow2-Snapshots; btrfs-Snapshots bei fs=btrfs",
|
||||
"zfs": "Native, Instant, Copy-on-Write"
|
||||
},
|
||||
{
|
||||
"label": "Dynamische Speicherzuweisung",
|
||||
"dir": "Ja (qcow2-Standard)",
|
||||
"zfs": "Ja (ZFS Standard)"
|
||||
},
|
||||
{
|
||||
"label": "RAM Bedürfnisse",
|
||||
"dir": "niedrig",
|
||||
"zfs": "Hoch — ZFS nutzt freien RAM als ARC-Cache"
|
||||
},
|
||||
{
|
||||
"label": "Unterstützt Inhaltstypen",
|
||||
"dir": "images, backup, iso, vztmpl, snippets, rootdir",
|
||||
"zfs": "nur images und rootdir (Blockspeicher)"
|
||||
},
|
||||
{
|
||||
"label": "Am besten für",
|
||||
"dir": "Allzweck-Disk: Mix aus VM-Disks, Backups, ISOs",
|
||||
"zfs": "Reine VM / LXC-Datenplatte mit Snapshot + Integritätsanforderungen"
|
||||
}
|
||||
]
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im ProxMenux-Hauptmenü <strong>Storage & Share Manager → Add Local Disk as Proxmox Storage</strong>. Das Untermenü enthält vier Optionen:",
|
||||
"imageAlt": "Lokales Disk Manager-Menü – Hinzufügen / Anzeigen / Entfernen / Auflisten verfügbarer Festplatten"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft (Flow hinzufügen)",
|
||||
"body": "Der Ablauf hat zwei Phasen mit einem Sicherheitsfilter mit drei Prüfungen. Phase 1 entdeckt sichere Festplatten, entscheidet, was mit der gewählten zu tun ist und sammelt Speicherparameter; Phase 2 erledigt die destruktive Arbeit. Bis zur endgültigen Bestätigung ist die Festplatte unberührt."
|
||||
},
|
||||
"format": {
|
||||
"heading": "Leeren Datenträger formatieren",
|
||||
"intro": "Der Pfad für eine neue Festplatte oder eine, deren Inhalt Ihnen egal ist.",
|
||||
"items": [
|
||||
"Wählen Sie die Festplatte (System / In-Use-Disks sind versteckt).",
|
||||
"Wählen Sie \"Formatdiskette (ERASE alle Daten)\".",
|
||||
"Wählen Sie das Dateisystem aus - siehe Tabelle oben für Kompromisse.",
|
||||
"Storage ID (default <code>disk-<device></code>), Mount-Pfad, Voreinstellung des Inhaltstyps.",
|
||||
"Bestätigen Sie im <strong>FINAL CONFIRMATION — DATA WILL BE ERASED</strong> Dialog.",
|
||||
"ProxMenux löscht die Partitionstabelle und erstellt eine Partition über den Datenträger. Es führt <code>mkfs.<fs></code> oder <code>zpool create</code> aus und hängt das Ergebnis ein. Normale Dateisysteme erhalten einen UUID-Eintrag in <code>/etc/fstab</code> mit <code>defaults,nofail</code>; ZFS verwendet die Mount-Konfiguration des Pools. Ist <em>Als Proxmox-Speicher</em> markiert (bei ZFS immer), wird er anschließend mit <code>pvesm add dir</code> oder <code>pvesm add zfspool</code> registriert; andernfalls bleibt er nur ein Host-Mount."
|
||||
],
|
||||
"tipTitle": "Warum UUID + nofail in /etc/fstab",
|
||||
"tipBody": "Das Skript schreibt <code>UUID=… /mnt/<id> <fs> defaults,nofail 0 2</code>. UUID überlebt die Geräteumordnung über Neustarts hinweg (so dass <code>/dev/sdc</code>, das <code>/dev/sdd</code> wird, den Boot nicht unterbricht). <code>nofail</code> bedeutet, dass, wenn die Festplatte jemals verschwindet (Hardwarefehler, Unplugged), Proxmox immer noch bootet - der Speicher wird nur als inaktiv angezeigt, bis die Festplatte zurückkommt."
|
||||
},
|
||||
"reuse": {
|
||||
"heading": "Wiederverwendung eines vorhandenen Dateisystems",
|
||||
"intro": "Der Pfad für eine Festplatte, auf der Sie die Daten behalten möchten - vielleicht haben Sie sie von einem anderen Proxmox-Host verschoben, oder die Festplatte verfügt bereits über Backups / ISOs, die Sie zugänglich halten möchten.",
|
||||
"items": [
|
||||
"Wählen Sie den Datenträger.",
|
||||
"Wählen Sie \"Vorhandenes Dateisystem verwenden\".",
|
||||
"Speicher-ID, Mount-Pfad und Inhaltstyp-Voreinstellung.",
|
||||
"ProxMenux berührt die Daten <strong>nicht</strong>: Es erstellt den Mount-Punkt, mountet die Festplatte, fügt einen UUID-Eintrag zu <code>/etc/fstab</code> hinzu und registriert ihn als Proxmox-<code>dir</code>-Speicher."
|
||||
],
|
||||
"warnTitle": "Wiederverwendungspfad behandelt keine ZFS-Pools",
|
||||
"warnBody": "Wenn die Festplatte bereits einen ZFS-Pool enthält, versucht der <em>reuse</em>-Pfad hier nur, ihn als reguläres Dateisystem zu montieren - was fehlschlägt. Um einen vorhandenen ZFS-Pool zu importieren, verwenden Sie <code>zpool import <name></code> auf der Kommandozeile und registrieren Sie ihn dann manuell bei <code>pvesm add zfspool</code>."
|
||||
},
|
||||
"presets": {
|
||||
"heading": "Inhaltstyp-Presets",
|
||||
"intro": "ProxMenux bietet drei Voreinstellungen und eine eigene Eingabe. Die gewählte Inhaltsliste wird an <code>pvesm add … --content <csv></code> übergeben:",
|
||||
"headerPreset": "Voreinstellung",
|
||||
"headerContent": "Inhaltsliste",
|
||||
"headerUse": "Anwendungsfall",
|
||||
"rows": [
|
||||
{
|
||||
"preset": "VM Speicherplatz",
|
||||
"content": "images,backup",
|
||||
"use": "Ein dedizierter VM-Festplattenspeicher, der auch Backups dieser VMs in der Nähe hält."
|
||||
},
|
||||
{
|
||||
"preset": "Standard-NAS",
|
||||
"content": "backup,iso,vztmpl",
|
||||
"use": "Ein Archiv / Media Disk - Backups, ISOs und LXC Vorlagen. Keine live VM Festplatten hier."
|
||||
},
|
||||
{
|
||||
"preset": "Alle Typen",
|
||||
"content": "images,backup,iso,vztmpl,snippets",
|
||||
"use": "Diese breite Voreinstellung aktiviert Images, Sicherungen, ISOs, LXC-Vorlagen und Snippets. Fügen Sie weitere unterstützte Typen wie rootdir bei Bedarf über Benutzerdefiniert hinzu."
|
||||
},
|
||||
{
|
||||
"preset": "Benutzerdefiniert",
|
||||
"content": "(freier Input)",
|
||||
"useRich": "Geben Sie den genauen CSV selbst ein, z.B. <code>images</code> allein oder <code>rootdir,images</code>."
|
||||
}
|
||||
],
|
||||
"zfsTitle": "ZFS Pool-Inhalte sind schmaler",
|
||||
"zfsBody": "Bei <strong>zfs</strong> unterstützt ein <code>zfspool</code> nur <code>images</code> und <code>rootdir</code>, keine ISO- oder Sicherungsdateien. Geben Sie unter Benutzerdefiniert eine unterstützte Liste ein. Das Skript reicht sie unverändert weiter; unzulässige Typen können die Registrierung scheitern lassen. Prüfen Sie danach <code>pvesm status</code>."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"extIntro": "Format + Registrierung einer Festplatte als ext4-Verzeichnisspeicher:",
|
||||
"zfsIntro": "Oder als ZFS Pool:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Datenträgerspeicher anzeigen",
|
||||
"body": "Listet alle plattengestützten Proxmox-Speicher auf (sowohl <code>dir</code> als auch <code>zfspool</code>, die vom Benutzer erstellt wurden – Systempools wie <code>rpool</code> sind ausgeblendet). Zeigt den Mount-Pfad / Pool-Namen, Inhaltstypen und Live-Status an."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Disk Storage entfernen",
|
||||
"body": "Hebt die Registrierung des Speichers bei Proxmox auf (<code>pvesm remove</code>) und bietet an, den passenden Eintrag in <code>/etc/fstab</code> zu bereinigen. Für ZFS pools zerstört das Skript <strong>nicht</strong> automatisch das pool – das ist ein separater <code>zpool destroy <name></code>-Schritt, den Sie manuell ausführen, wenn Sie sicher sind.",
|
||||
"warnTitle": "Daten und bestehende VM Abhängigkeiten",
|
||||
"warnBody": "Das Entfernen des Speichers berührt nicht das Dateisystem oder den Pool - die Daten bleiben auf der Festplatte. Aber VMs / CTs, die diesen Speicher nach ID referenzieren, können nach dem Entfernen nicht starten. Verschieben Sie diese VM-Festplatten in einen anderen Speicher (oder nehmen Sie ein Backup), bevor Sie sie entfernen."
|
||||
},
|
||||
"list": {
|
||||
"heading": "Liste der verfügbaren Datenträger",
|
||||
"body": "Eine schreibgeschützte Diagnoseansicht: Druckt die Ausgabe von <code>lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL</code>, gefolgt von den <code>dir</code>/<code>zfspool</code>-Speichern, die Proxmox bereits kennt. Guter erster Stopp, wenn Sie das Tool öffnen und sehen möchten \"Was ist auf diesem Host?\", Bevor Sie etwas hinzufügen."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noDisksTitle": "\"Keine verfügbaren Festplatten gefunden\"",
|
||||
"noDisksIntro": "Der Sicherheitsfilter hat alle Datenträger ausgeblendet. Häufige Gründe:",
|
||||
"noDisksItems": [
|
||||
"Nur die Root Disc ist vorhanden.",
|
||||
"Jede andere Festplatte ist Teil eines aktiven ZFS / LVM / RAID-Arrays.",
|
||||
"Jede andere Festplatte wird durch eine VM- oder LXC-Konfiguration (Durchgang) referenziert.",
|
||||
"Die Festplatte befindet sich im schreibgeschützten Modus (ausfallende Hardware oder Schreibblocker)."
|
||||
],
|
||||
"noDisksOutro": "Verwenden Sie <em>List Available Disks</em> aus dem Menü, um die <code>lsblk</code>-Rohausgabe zu sehen und zu verstehen, was passiert.",
|
||||
"mountedTitle": "Format fehlschlägt mit \"Device is mount\"",
|
||||
"mountedBody": "Etwas hat die Festplatte automatisch gemountet (udisksd, ein Desktop-Manager, eine anhaltende systemd-Einheit). Unmount: <code>umount /dev/sdX?*</code> oder <code>systemctl stop <whatever-mounts-it></code>, dann wiederholen. Der Sicherheitsfilter des Skripts sollte versteckte montierte Festplatten haben, so dass, wenn Sie diesen Fehler erreicht haben, die Mount zwischen dem angezeigten Menü und der Bestätigung stattgefunden hat.",
|
||||
"zpoolTitle": "zpool create schlägt mit „invalid vdev specification“ fehl",
|
||||
"zpoolBody": "Normalerweise bedeutet dies, dass die Festplatte immer noch veraltete GPT / LVM / ZFS-Signaturen aufweist, die <code>zpool</code> nicht ohne Erzwingen überschreiben möchte. Das Skript führt <code>wipefs</code> und <code>sgdisk --zap-all</code> vor dem Formatieren aus, aber eine sehr hartnäckige Festplatte kann immer noch ein veraltetes Label haben. Erzwingen Sie manuell eine Bereinigung: <code>zpool labelclear -f /dev/sdX</code> oder <code>dd if=/dev/zero of=/dev/sdX bs=1M count=10</code> und wiederholen Sie es.",
|
||||
"inactiveTitle": "Storage wird nach dem Neustart als inaktiv angezeigt",
|
||||
"inactiveBody": "Überprüfen Sie <code>findmnt <mount-path></code> - wenn die Mount fehlt, ist etwas in <code>/etc/fstab</code> fehlgeschlagen. <code>dmesg | tail</code> zeigt normalerweise auf den Grund (UUID-Mismatch, Dateisystemkorruption, <code>nofail</code> ließ die Wiederholung fallen). Ein <code>mount -a</code> reaktiviert normalerweise den Speicher, sobald die Ursache behoben ist."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/disk-manager/format-disk",
|
||||
"label": "Datenträgerverwaltung: Physischen Datenträger formatieren / löschen",
|
||||
"tail": "Low-Level-Alternative, wenn Sie nur eine Festplatte vorbereiten möchten, ohne sie als Proxmox-Speicher zu registrieren."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-iscsi",
|
||||
"label": "Hinzufügen von iSCSI-Ziel als Proxmox-Speicher",
|
||||
"tail": " — Entsprechende Netzwerklösung, wenn sich das Blockgerät auf einem anderen Rechner befindet."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"label": "Shared Directory auf Host hinzufügen",
|
||||
"tail": "Bereiten Sie ein Verzeichnis für LXC-Bind-Mounts auf dem Host vor (registriert keinen Proxmox-Speicher)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,103 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Host: Freigegebenes Verzeichnis auf dem Host hinzufügen | ProxMenux-Dokumentation",
|
||||
"description": "Erstellen Sie ein Hostverzeichnis, das für LXC-Bind-Mounts bereit ist, mit Berechtigungen, die für privilegierte und unprivilegierte Container gleichzeitig funktionieren. Sticky Bit + World-Rwx + ACLs für die Standardvererbung.",
|
||||
"ogTitle": "Host: Freigegebenes Verzeichnis auf dem Host hinzufügen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Bereiten Sie ein Hostverzeichnis für LXC-Bind-Mounts vor, dessen Berechtigungen mit privilegierten und unprivilegierten CTs kompatibel sind."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host: Freigegebenes Verzeichnis hinzufügen",
|
||||
"description": "Erstellen Sie ein Host-Verzeichnis, das so konzipiert ist, dass es in einen oder mehrere LXC-Container eingebunden wird. ProxMenux wendet eine Reihe von Berechtigungen an, die sowohl für privilegierte als auch für unprivilegierte CTs gleichzeitig funktionieren - keine verschobenen UID-Kopfschmerzen, keine pro-Container-Chowns - und registriert das Verzeichnis, damit der LXC Mount Manager es später abholen kann.",
|
||||
"section": "Speicher und Freigaben · Host"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das ist (und nicht ist)",
|
||||
"body": "Dieses Tool registriert <strong>nicht</strong> irgendetwas in Proxmox (kein <code>pvesm add</code> hier). Es bereitet lediglich ein Verzeichnis auf dem Host vor – standardmäßig <code>/mnt/shared</code> – mit Berechtigungen, die jeder LXC-Container lesen und schreiben kann, unabhängig davon, ob der CT privilegiert oder nicht privilegiert ist. Der übliche nächste Schritt besteht darin, es mit dem <mountLink>LXC-Mount-Manager</mountLink> in jedes CT einzubinden."
|
||||
},
|
||||
"why": {
|
||||
"heading": "Warum ein dediziertes Tool dafür",
|
||||
"intro": "Wenn Sie ein Hostverzeichnis in einen LXC-Container binden, hängen die Berechtigungen ab von:",
|
||||
"items": [
|
||||
"Ob der CT <strong>privilegiert</strong> ist (UID 0 im CT = UID 0 auf dem Host) oder <strong>unprivilegiert</strong> (UID 0 im CT = UID 100000 auf dem Host — alle UIDs sind um +100000 verschoben).",
|
||||
"Der Besitz des Hostverzeichnisses (eine Datei im Besitz von UID 1000 auf dem Host erscheint als \"andere\" aus der Perspektive eines unprivilegierten CT, da kein CT-Benutzer UID 1000 zuordnet).",
|
||||
"Ob mehrere CTs das gleiche Verzeichnis teilen (unterschiedliche CTs können unterschiedliche UID-Bereiche haben)."
|
||||
],
|
||||
"outro": "ProxMenux verwendet hier einen pragmatischen Ansatz: <strong>allen Zugriff gewähren</strong>, und zwar auf Dateisystemebene. Dazu kommen rwx-Rechte für alle, das Sticky-Bit und ACLs zur Vererbung der Rechte an neue Dateien. Jede zugeordnete UID kann lesen und schreiben; ein Abgleich von UIDs/GIDs ist nicht nötig."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Das Skript hat kein Hauptmenü – es führt eine einzelne Aktion aus, <strong>Freigegebenes Verzeichnis erstellen</strong>. Phase 1 sammelt den Zielpfad; Phase 2 erstellt das Verzeichnis und wendet Berechtigungen an."
|
||||
},
|
||||
"bits": {
|
||||
"heading": "Was jedes Berechtigungsbit tut",
|
||||
"intro": "Die Nummer <strong>1777</strong> ist nicht willkürlich - es ist der gleiche Modus, den Linux für <code>/tmp</code> verwendet. Drei Eigenschaften kombiniert:",
|
||||
"headerBit": "Bit",
|
||||
"headerEffect": "Wirkung",
|
||||
"headerWhy": "Warum es hier wichtig ist",
|
||||
"rows": [
|
||||
{
|
||||
"bit": "1 (sticky bit)",
|
||||
"effect": "Löschen und Umbenennen sind auf den Datei- oder Verzeichniseigentümer und ausreichend privilegierte Prozesse beschränkt.",
|
||||
"why": "Hilft Benutzern mit unterschiedlichen zugeordneten UIDs, fremde Dateien vor Löschung zu schützen. CTs mit derselben zugeordneten UID oder privilegiertem Root-Zugriff sind dadurch nicht voneinander isoliert."
|
||||
},
|
||||
{
|
||||
"bit": "777 (rwx-rwx-rwx)",
|
||||
"effect": "Jeder kann lesen, schreiben und das Verzeichnis betreten.",
|
||||
"why": "Unprivilegierte CT UIDs (100000+) erscheinen als \"andere\" vom Host, so dass world-rwx ihnen Zugriff gibt."
|
||||
},
|
||||
{
|
||||
"bit": "ACLs (Standard)",
|
||||
"effect": "Vererbt auf jeder neu erstellten Datei / Subdir.",
|
||||
"why": "Neue Inhalte erben die Standard-ACLs, ohne das Skript erneut auszuführen. Anwendungen können weiterhin restriktive Modi anfordern oder Rechte später ändern."
|
||||
}
|
||||
],
|
||||
"privTitle": "Privilegierte CTs sehen dasselbe, nur ohne die Verschiebung",
|
||||
"privBody": "Für einen privilegierten CT ist UID 0 im CT UID 0 auf dem Host, so dass <code>root</code> im CT das Hostverzeichnis direkt lesen / schreiben kann. <code>1777</code> ist immer noch in Ordnung - es bedeutet nur, dass Nicht-Root-Benutzer im CT auch das Verzeichnis verwenden können. Die gleichen Berechtigungen decken beide Fälle ab."
|
||||
},
|
||||
"where": {
|
||||
"heading": "Wo das freigegebene Verzeichnis liegen soll",
|
||||
"intro": "Der Location Picker bietet vier Optionen:",
|
||||
"opt1Title": "1. Erstellen Sie einen neuen Ordner in /mnt",
|
||||
"opt1Body": "Die übliche Wahl. ProxMenux schlägt automatisch den ersten freien Namen vor (<code>shared</code>, <code>shared2</code>, <code>shared3</code>, ...). Sie bestätigen oder geben nur einen anderen Namen ein.",
|
||||
"opt2Title": "2. Benutzerdefinierter Pfad",
|
||||
"opt2Body": "Für Verzeichnisse außerhalb von <code>/mnt</code>. Jeder absolute Pfad funktioniert (z.B. <code>/srv/media</code>, <code>/data/family</code>). Das Skript verwendet die gleichen Berechtigungen.",
|
||||
"opt3Title": "3. Bestehende Ordner in /mnt anzeigen",
|
||||
"opt3Body": "Read-only Diagnose: listet jedes Verzeichnis unter <code>/mnt</code> mit seinen Berechtigungen, Eigentümer und verfügbaren Speicherplatz auf. Nützlich, bevor Sie eine neue erstellen, um Namenskollisionen zu vermeiden.",
|
||||
"opt4Title": "4. Abbrechen",
|
||||
"opt4Body": "Beendet den Vorgang, ohne etwas zu erstellen. Entspricht <kbd>Esc</kbd>.",
|
||||
"tipTitle": "Wo lebt /mnt?",
|
||||
"tipBody": "Standardmäßig befindet sich <code>/mnt</code> auf dem Proxmox-Root-Dateisystem. Wenn Sie das freigegebene Verzeichnis auf einer anderen Festplatte (einer Datenplatte, einem ZFS-Pool) haben möchten, mounten Sie diese Festplatte zuerst unter <code>/mnt/<name></code> (Disk Manager oder <diskLink>Lokale Festplatte als Proxmox-Speicher hinzufügen</diskLink>) und erstellen Sie dann das freigegebene Verzeichnis als Unterordner darin - oder wählen Sie \"Benutzerdefinierten Pfad eingeben\" hier und zeigen Sie auf die eingehängte Festplatte."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Der gesamte Flow kann von Hand wiedergegeben werden:"
|
||||
},
|
||||
"next": {
|
||||
"heading": "Nächster Schritt: Bind-Mount in Container",
|
||||
"body": "Durch das Erstellen des Verzeichnisses wird es nur vorbereitet – noch wird es von keinem Container gesehen. Um es in einem oder mehreren LXCs sichtbar zu machen, verwenden Sie den Mount-Manager <mountLink>LXC</mountLink>, um <code>/mnt/<name></code> in die CTs einzubinden. Da die Berechtigungen bereits geöffnet sind, bietet der Mount-Manager <strong>nicht</strong> an, sie zu ändern – das Verzeichnis kann unverändert verwendet werden."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"mkdirTitle": "\"Failed to create directory\"",
|
||||
"mkdirBody": "Normalerweise ein Dateisystemproblem: <code>/mnt</code> befindet sich in einem schreibgeschützten Dateisystem, der Pfad enthält eine Komponente, die kein Verzeichnis ist (z. B. Sie haben <code>/etc/passwd/sub</code> eingegeben), oder die Festplatte ist voll. Überprüfen Sie mit <code>df -h /mnt</code> und <code>mount | grep /mnt</code>.",
|
||||
"writeTitle": "Container kann trotz offener Berechtigungen nicht schreiben",
|
||||
"writeBody": "Überprüfen Sie, ob der CT tatsächlich den Bind-Mount (<code>pct config <ctid> | grep ^mp</code>) verwendet. Führen Sie im CT <code>touch /mnt/data/test-$(date +%s)</code> aus – wenn dies mit verweigerter Berechtigung fehlschlägt, befindet sich das Mount möglicherweise auf einem Host-Dateisystem, das ACLs nicht berücksichtigt (einige ältere <code>ext3</code>- oder <code>vfat</code>-Mounts). Verschieben Sie das freigegebene Verzeichnis in ein ext4 / xfs / btrfs / zfs Backing.",
|
||||
"aclTitle": "ACL Befehle leise nicht verfügbar",
|
||||
"aclBody": "Bei einer minimalen Proxmox-Installation sind <code>setfacl</code> / <code>getfacl</code> möglicherweise nicht installiert. Das Skript fällt anmutig zurück (<code>command -v setfacl</code>-Check) und wendet nur POSIX-Berechtigungen an - was oft genug ist, aber neue Dateien werden das permissive Profil nicht automatisch erben. Installieren Sie <code>acl</code> mit <code>apt-get install -y acl</code> und führen Sie das Skript im Verzeichnis erneut aus."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Mount-Verwaltung",
|
||||
"tail": "— der natürliche nächste Schritt: bind-mount dieses Verzeichnis in einen oder mehrere Container."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"label": "Lokale Festplatte als Proxmox-Speicher hinzufügen",
|
||||
"tailRich": "Wenn Sie das freigegebene Verzeichnis auf einer dedizierten Festplatte haben möchten, bereiten Sie die Festplatte zuerst vor, mounten Sie sie unter <code>/mnt</code> und erstellen Sie dann den freigegebenen Unterordner hier."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,174 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Host: NFS-Freigabe einhängen | ProxMenux-Dokumentation",
|
||||
"description": "Montieren Sie einen externen NFS-Export auf dem Proxmox-Host - entweder als Proxmox-Speicher (pvesm add nfs), als einfacher fstab-Mount auf dem Host (NICHT sichtbar in Datacenter > Storage) oder beides. Die fstab-Methode ist ideal, um die Freigabe in LXC-Container zu binden, ohne sie als Proxmox-Speicher freizulegen.",
|
||||
"ogTitle": "Host: NFS-Freigabe einhängen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Montieren Sie einen externen NFS-Export auf dem Proxmox-Host über pvesm, fstab oder beides. fstab-Pfad ist ideal für LXC-Bind-Mounts."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host: NFS-Freigabe auf dem Host einhängen",
|
||||
"description": "Montieren Sie einen externen NFS-Export (von einem NAS, einem anderen Server, einer Homelab-Freigabe ...) auf dem Proxmox-Host. Wählen Sie eine oder beide Methoden aus: Registrieren Sie sie als Proxmox-Speicher (sichtbar in Datacenter > Storage) und/oder fügen Sie einen einfachen Mount über /etc/fstab an einem von Ihnen gewählten Pfad hinzu (nützlich für das Binden der Freigabe in LXC-Container, ohne sie als Proxmox-Speicher freizulegen).",
|
||||
"section": "Speicher und Freigaben · Host"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "ProxMenux bietet zwei Mount-Methoden für jeden NFS-Export an: <strong>(1) Proxmox-Speicher</strong> über <code>pvesm add nfs</code> - die Freigabe wird in Datacenter > Storage angezeigt und Proxmox verwaltet das Mount bei <code>/mnt/pve/<id></code>; <strong>(2) Host-Fstab-Mount</strong> auf einem Weg, den Sie auswählen - persistent über <code>/etc/fstab</code>, NICHT sichtbar als Proxmox-Speicher, ideal für Bindemontage an LXC-Container (Proxmox UI bleibt sauber). Sie können eine Methode, die andere oder beides ausführen."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Speicher & Freigabe-Manager → NFS Freigabe auf Host bereitstellen</strong>. Sie sehen dieses sub-Menü mit vier Optionen:",
|
||||
"imageAlt": "NFS-Host-Menü — Einhängen / Anzeigen / Entfernen / Verbindung testen"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Ablauf hat zwei Phasen mit klarer Trennung zwischen \"Entdecken, Validieren und Auswählen\" und \"tatsächlich einhängen und Konfiguration schreiben\". Nachdem Sie einen Export ausgewählt haben, wählen Sie die Mount-Methode(n) über eine Checkliste aus; der Rest der Dialoge fragt nur nach Parametern für die von Ihnen ausgewählten Methoden. Bis zur endgültigen Bestätigung werden weder <code>/etc/pve/storage.cfg</code> noch <code>/etc/fstab</code> berührt."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Mount-Methode wählen (eine oder beide Optionen)",
|
||||
"intro": "Nach Auswahl und Validierung des Exports zeigt ProxMenux eine Checkliste mit den beiden Mount-Methoden an. Sie können entweder oder beide markieren. Wenn Sie auf OK drücken, ohne etwas zu markieren, erscheint der Dialog erneut, bis Sie mindestens eine Option auswählen oder auf Abbrechen drücken, um den Fluss zu verlassen.",
|
||||
"imageAlt": "Mount Method Checkliste mit pvesm und fstab Optionen",
|
||||
"headerMethod": "Methode",
|
||||
"headerMount": "Mount-Pfad",
|
||||
"headerUi": "Sichtbar in Datacenter > Storage",
|
||||
"headerUseCase": "Typischer Anwendungsfall",
|
||||
"rows": [
|
||||
{
|
||||
"method": "<strong>Als Proxmox-Speicher (pvesm)</strong>",
|
||||
"mountRich": "<code>/mnt/pve/<storage-id></code> (verwaltet von Proxmox)",
|
||||
"ui": "Ja",
|
||||
"useCase": "VM Disk-Images, Backups, ISOs, LXC-Vorlagen - alles, was in der Proxmox-Benutzeroberfläche angezeigt werden muss."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Nur Host-fstab</strong>",
|
||||
"mountRich": "<code>/mnt/<path></code> (Sie wählen den Weg)",
|
||||
"ui": "Nein",
|
||||
"useCaseRich": "Die Freigabe per Bind-Mount in einen oder mehrere LXCs einbinden, <em>ohne</em> sie als Proxmox-Speicher anzuzeigen. Hält die Datacenter-Oberfläche übersichtlich."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Beide</strong>",
|
||||
"mount": "Beide Pfade oben (zwei Mount-Punkte desselben NFS-Exports)",
|
||||
"ui": "Ja",
|
||||
"useCase": "Oberflächenintegration und ein separater stabiler Host-Pfad mit offenen Berechtigungen für LXC-Bind-Mounts."
|
||||
}
|
||||
],
|
||||
"bothTitle": "„Beide“ erstellt zwei unabhängige NFS-Mounts",
|
||||
"bothBody": "Beide Methoden laufen getrennt: pvesm hängt unter <code>/mnt/pve/<id></code> ein, fstab unter <code>/mnt/<path></code>. So erhalten Sie einen Proxmox-Mount mit Standardoptionen und einen separaten Host-Mount für LXC-Bind-Mounts. Zwei Mount-Punkte garantieren keine zwei TCP-Verbindungen; der NFS-Client kann Transporte wiederverwenden."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Methode A — als Proxmox-Speicherung (pvesm)",
|
||||
"intro": "Wenn <em>Als Proxmox-Speicher</em> markiert ist, führt ProxMenux den ursprünglichen pvesm-Flow aus:",
|
||||
"items": [
|
||||
"<strong>Storage ID</strong> – was Proxmox diesen Speicher nennen wird. Standardmäßig ist <code>nfs-<server-ip-with-dashes></code>. Es werden nur Buchstaben, Ziffern, <code>-</code> und <code>_</code> akzeptiert.",
|
||||
"<strong>Inhaltstypen</strong> — Proxmox verknüpft Inhaltskategorien mit Speichervolumen; wählen Sie aus, was dieser NFS enthalten darf:"
|
||||
],
|
||||
"headerType": "Inhaltsart",
|
||||
"headerAllows": "Was es erlaubt",
|
||||
"rows": [
|
||||
{
|
||||
"type": "import",
|
||||
"allowsRich": "Datenträgerbildimporte (standardmäßig ausgewählt). Benötigt für <em>Import Disk Image zu VM</em>."
|
||||
},
|
||||
{
|
||||
"type": "backup",
|
||||
"allowsRich": "VM und CT Backup-Dateien (<code>vzdump</code>)."
|
||||
},
|
||||
{
|
||||
"type": "iso",
|
||||
"allows": "ISO-Abbildungen für die Installation."
|
||||
},
|
||||
{
|
||||
"type": "vztmpl",
|
||||
"allows": "LXC-Vorlagen."
|
||||
},
|
||||
{
|
||||
"type": "images",
|
||||
"allows": "VM-Disk-Images (dadurch wird der NFS in einen VM-Disk-Store verwandelt)."
|
||||
},
|
||||
{
|
||||
"type": "rootdir",
|
||||
"allows": "LXC Root-Dateisysteme (selten für NFS – lesen Sie den unten stehenden Hinweis)."
|
||||
},
|
||||
{
|
||||
"type": "snippets",
|
||||
"allows": "Hook-Scripts und Cloud-Init-Snippets."
|
||||
}
|
||||
],
|
||||
"warnTitle": "images und rootdir auf NFS",
|
||||
"warnBody": "Mit <code>images</code> kann Proxmox VM-Festplatten auf NFS speichern. Die Leistung hängt von Netzwerk, Server und Last ab; ein Ausfall kann davon abhängige E/A blockieren. Mit <code>rootdir</code> liegen LXC-Root-Dateisysteme auf NFS. Unprivilegierte Container können dort Einschränkungen bei UID-Zuordnung, Overlay und Eigentümern haben. Prüfen Sie dies vor der Ablage von <code>images</code> / <code>rootdir</code>; NFS eignet sich auch für <code>backup</code> / <code>iso</code> / <code>vztmpl</code>.",
|
||||
"result": "Das Ergebnis ist <code>pvesm add nfs <id> --server <srv> --export <path> --content <csv></code> und Proxmox Auto-Mounts bei <code>/mnt/pve/<id></code>."
|
||||
},
|
||||
"fstabBranch": {
|
||||
"heading": "Methode B — nur ein fstab-Mount auf dem Host",
|
||||
"intro": "Wenn <em>Nur fstab-Mount auf dem Host</em> markiert ist, fragt ProxMenux nach einem host mount path und persistenten Optionen, dann mountet und schreibt den Eintrag in <code>/etc/fstab</code>:",
|
||||
"items": [
|
||||
"<strong>Mount-Pfad auf dem Host</strong> — standardmäßig <code>/mnt/<export-basename></code>. Es muss ein absoluter Weg sein. Wenn dort bereits etwas montiert ist oder ein Fstab-Eintrag für den gleichen Pfad existiert, warnt Sie ProxMenux und bietet an, ihn zu ersetzen.",
|
||||
"<strong>Mount-Optionen</strong> — <em>Lesen/Schreiben</em> (Standard: <code>rw,hard,nofail,_netdev,rsize=131072,wsize=131072,timeo=600,retrans=2</code>), <em>Nur Lesen</em>, <em>Benutzerdefiniert</em> (eigene Optionen eingeben)."
|
||||
],
|
||||
"appliesIntro": "Sobald Sie bestätigen, das Skript:",
|
||||
"applies": [
|
||||
"<code>mkdir -p</code> der Mount Path.",
|
||||
"<code>mount -t nfs -o <opts> <srv>:<export> <path></code>.",
|
||||
"Schreibt einen einzeiligen Eintrag in <code>/etc/fstab</code>: <code><srv>:<export> <path> nfs <opts> 0 0</code>.",
|
||||
"Führt <code>systemctl daemon-reload</code> aus, so dass systemd den neuen Fstab-Eintrag abholt.",
|
||||
"Versucht <code>chmod 1777</code> und <code>setfacl o::rwx</code> auf dem Mount-Punkt. Fehler werden still ignoriert; es gelingt nur, wenn der NFS-Server es erlaubt. Viele NAS-Exporte sind bereits für alle Benutzer beschreibbar."
|
||||
],
|
||||
"lxcTitle": "Den fstab-Mount aus einem LXC verwenden",
|
||||
"lxcBody": "Das Skript zeigt einen <code>pct set</code>-Befehl für einen Bind-Mount, etwa <code>pct set <ctid> -mp0 /mnt/<path>,mp=/mnt/<ct-path>,shared=1,backup=0</code>. Alternativ erkennt der <mountLink>LXC Mount Manager</mountLink> fstab-Mounts. <strong>Im Container wird nichts geändert</strong>. Der Zugriff unprivilegierter CTs hängt von Serverrechten für ihre zugeordneten UIDs/GIDs ab. Das Skript versucht nur Berechtigungsänderungen vom Host aus; beschreibbare Exporte oder Herstellerstandards sind nicht garantiert. Bei Fehlern siehe Fehlerbehebung.",
|
||||
"noUiTitle": "Der fstab-Mount ist KEIN Proxmox-Speicher",
|
||||
"noUiBody": "Der fstab-Mount auf dem Host erscheint bewusst nicht in der Proxmox-Weboberfläche. Er fehlt unter <em>Datacenter > Storage</em>, lässt sich beim Erstellen einer VM oder eines CT nicht auswählen und kann nicht als Ziel eines Proxmox-Sicherungsauftrags dienen. Er ist lediglich ein Pfad im Dateisystem des Hosts. Wünschen Sie zusätzlich die Integration in die Oberfläche, wählen Sie <em>beide</em> Methoden aus."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"pvesmIntro": "Methode A (pvesm) bildet ab:",
|
||||
"fstabIntro": "Methode B (Fstab) bildet ab:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Ansicht konfigurierter NFS-Speicher",
|
||||
"body": "Zeigt alle NFS-Einträge in Proxmox (<code>pvesm status | awk ''$2 == \"nfs\"''</code>) mit Server, Export, Inhaltstypen, Mount-Pfad und aktuellem Status. <strong>Hinweis:</strong> Diese Ansicht enthält nur über pvesm registrierte Storages. Reine fstab-Mounts werden nicht aufgeführt; prüfen Sie diese mit <code>findmnt -t nfs</code> oder <code>grep nfs /etc/fstab</code>."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "NFS-Speicher entfernen",
|
||||
"body": "Führt <code>pvesm remove <storage-id></code> nach einer Bestätigung aus, die den Server / Export / Inhalt anzeigt. Nur die Registrierung auf Proxmox-Seite wird entfernt — <strong>der entfernte NFS-Server selbst wird nie berührt</strong>, es werden keine Dateien gelöscht. Um ein fstab-only-Halter zu entfernen, bearbeiten Sie <code>/etc/fstab</code> von Hand und führen Sie <code>umount <path></code> aus.",
|
||||
"warnTitle": "Abhängigkeiten zuerst sichern",
|
||||
"warnBody": "Wenn VMs, CTs oder Backup-Jobs immer noch auf diesen Speicher verweisen (nach ID), zeigt das Entfernen auf einen verschwundenen Speicher. Proxmox wird den Fehler markieren, aber nicht bereinigen. Verschieben oder löschen Sie diese Referenzen zuerst und entfernen Sie dann den Speicher."
|
||||
},
|
||||
"test": {
|
||||
"heading": "NFS-Verbindung testen",
|
||||
"body": "Führt einen Diagnosepass über jeden in Proxmox registrierten NFS-Speicher aus: Prüft, ob <code>showmount</code> verfügbar ist, ob <code>rpcbind</code> ausgeführt wird, pingt jeden Server, prüft den Port 2049, ruft <code>showmount -e</code> auf und meldet schließlich die eigene Ansicht von Proxmox (<code>pvesm status</code>). Gute erste Station, wenn ein Speicher als <em>inactive</em> in der Proxmox-Benutzeroberfläche angezeigt wird."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noServersTitle": "\"Keine NFS-Server im Netzwerk gefunden\"",
|
||||
"noServersBody": "Auto-discover verwendet <code>nmap -p 2049 --open <subnet>/24</code>. Der Server reagiert möglicherweise nicht, wenn: er befindet sich in einem anderen VLAN / Subnetz, seine Firewall blockiert nmap Sonden (viele tun dies) oder der Port 2049 wird absichtlich auf dieser Schnittstelle geschlossen. Verwenden Sie stattdessen die Option <em>Manual</em> mit der IP oder dem Hostnamen des Servers.",
|
||||
"portTitle": "„NFS-Port (2049) ist nicht erreichbar“",
|
||||
"portBody": "Ping war erfolgreich, aber <code>nc -z -w 3 <server> 2049</code> scheiterte. Überprüfen Sie, ob der NFS-Dienst auf dem Server ausgeführt wird (<code>systemctl status nfs-server</code> auf Linux, Systemsteuerung → Dateidienste auf Synology, NFS-Plugin auf OMV / TrueNAS) und ob die Firewall 2049 vom Proxmox-Host ermöglicht.",
|
||||
"showmountTitle": "\"Failed to connect\" von showmount",
|
||||
"showmountBody": "Der Server lehnte die Exportlistenabfrage ab. Häufige Ursachen: Der Server erzwingt strenge Client-ACLs (Ihre Proxmox-IP steht nicht auf der erlaubten Liste), <code>rpcbind</code> läuft nicht auf dem Server oder der Server stellt nur NFSv4 mit deaktiviertem <code>showmount</code> bereit. Der Exportpfad kann weiterhin manuell hinzugefügt werden, wenn Sie ihn kennen.",
|
||||
"inactiveTitle": "Storage zeigt als inaktiv in der Proxmox UI",
|
||||
"inactiveBody": "Starten Sie zuerst <em>NFS-Verbindung testen</em>: Es prüft, ob der Server auf Ping antwortet, Port 2049 offen ist und die Exportliste (<code>showmount -e</code>) verfügbar ist. Bleibt der Speicher bei funktionierender Verbindung inaktiv, prüfen Sie <code>journalctl -u pvestatd</code> und Server-/Exportkonfiguration. Beheben Sie zuerst Verbindungs- oder Berechtigungsprobleme. <code>pvesm set <id> --disable 0</code> aktiviert einen deaktivierten Speicher und ist keine allgemeine NFS-Reparatur.",
|
||||
"lxcNoWriteTitle": "fstab mount funktioniert, aber unprivilegierte LXC kann nicht durch ein bind-mount schreiben",
|
||||
"lxcNoWriteBody": "NFS-Zugriff hängt von Eigentümern, ACLs und Squash-Einstellungen auf dem Server ab. CIFS-Optionen wie <code>uid=</code> und <code>file_mode=</code> gelten <strong>nicht</strong> für NFS. Bei der Standard-LXC-Zuordnung wird CT-root zu Host-UID 100000, nicht zu Remote-UID 0. Gewähren Sie der tatsächlich zugeordneten UID/GID oder anonymen Serveridentität Zugriff. <code>no_root_squash</code> betrifft nur Remote-UID 0 und löst Probleme mit UID 100000 nicht allgemein. Das Skript versucht <code>chmod 1777</code>, kann Serverrechte aber nicht umgehen.",
|
||||
"fstabBootTitle": "fstab Mount wird nach dem Neustart nicht angezeigt",
|
||||
"fstabBootBody": "Das Skript fügt <code>nofail,_netdev</code> hinzu, so dass ein fehlender Anteil beim Booten den Start nicht blockiert. Wenn das mount nie auftaucht: bestätigen, dass das netzwerk erreichbar ist (<code>ping <server></code>), überprüfen sie <code>journalctl -u remote-fs.target</code> und überprüfen sie, ob der eintrag mit <code>mount -fav | grep nfs</code> gültig ist. <code>mount -a</code> nach dem Booten montiert alles, was derzeit fehlt."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS als Proxmox-Speicher",
|
||||
"tail": "— gleiches Flussmuster (Methode A pvesm + Methode B fstab) für SMB/CIFS-Freigaben."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Mount-Verwaltung",
|
||||
"tailRich": "— bind-mount den fstab-only Pfad <code>/mnt/<path></code> in einen oder mehrere Container."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "NFS-Client in LXC",
|
||||
"tail": "— Alternative: NFS direkt aus einem privilegierten Container montieren (überspringt den Host)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,172 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Host: Samba-Freigabe einhängen | ProxMenux-Dokumentation",
|
||||
"description": "Montieren Sie eine externe Samba / CIFS-Freigabe auf dem Proxmox-Host - entweder als Proxmox-Speicher (pvesm add cifs), als einfacher fstab-Mount auf dem Host mit offenem uid / gid / file_mode (NICHT sichtbar in Datacenter > Storage) oder beides. Die fstab-Methode öffnet Berechtigungen, so dass eine unprivilegierte LXC-Bindung des Pfades ohne Änderungen im Container lesen / schreiben kann.",
|
||||
"ogTitle": "Host: Samba-Freigabe einhängen | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Eine externe Samba-/CIFS-Freigabe auf dem Proxmox-Host über pvesm, fstab mit offenen Berechtigungen für LXC-Bind-Mounts oder beide Methoden einhängen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Host: Samba-Freigabe auf dem Host einhängen",
|
||||
"description": "Montieren Sie eine externe Samba (SMB / CIFS)-Freigabe - von einem NAS, einer Windows-Box, einem TrueNAS SMB Export - auf dem Proxmox-Host. Wählen Sie eine oder beide Methoden: Registrieren Sie es als Proxmox-Speicher (sichtbar in Datacenter > Storage) und/oder fügen Sie einen einfachen Mount über /etc/fstab an einem von Ihnen gewählten Pfad mit offenem uid/gid/file_mode hinzu, so dass unprivilegierte LXCs ohne Änderungen im Container bind-mounten und schreiben können.",
|
||||
"section": "Speicher und Freigaben · Host"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "ProxMenux bietet zwei Methoden für Samba-Freigaben: <strong>(1) Proxmox-Speicher</strong> über <code>pvesm add cifs</code>, sichtbar unter Datacenter > Storage und eingehängt unter <code>/mnt/pve/<id></code>. Das Passwort liegt im Klartext in <code>/etc/pve/priv/storage/<id>.pw</code>, geschützt durch das nur für root zugängliche private Verzeichnis. Das ist Zugriffsschutz, keine Verschlüsselung. <strong>(2) fstab-Mount auf dem Host</strong> an einem gewählten Pfad, dauerhaft über <code>/etc/fstab</code> und mit <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>, damit unprivilegierte LXCs über Bind-Mounts schreiben können. Die Zugangsdaten liegen in einer nur für root lesbaren Datei unter <code>/etc/samba/credentials/</code>, nie direkt in <code>fstab</code>. Beide Methoden sind einzeln oder gemeinsam nutzbar."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Speicher & Freigabe-Manager → Samba Freigabe auf Host bereitstellen</strong>. Sie sehen dieses sub-Menü mit vier Optionen:",
|
||||
"imageAlt": "Samba-Host-Menü — Einhängen / Anzeigen / Entfernen / Verbindung testen"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft",
|
||||
"body": "Der Ablauf hat zwei Phasen. Phase 1: Server entdecken, Anmeldeinformationen validieren, Share auswählen und dann die Mount-Methode(n) über eine Checkliste auswählen. Phase 2: Nur die von Ihnen markierten Methoden werden ausgeführt. Anmeldeinformationen werden im Voraus benötigt, weil <code>smbclient</code> sie benötigt, um Freigaben aufzulisten. Bis zur endgültigen Bestätigung werden weder <code>/etc/pve/storage.cfg</code> noch <code>/etc/fstab</code> berührt."
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Mount-Methode wählen (eine oder beide Optionen)",
|
||||
"intro": "Nach Auswahl der Freigabe und Validierung der Anmeldeinformationen zeigt ProxMenux eine Checkliste mit den beiden Mount-Methoden an. Sie können entweder oder beide markieren. Wenn Sie auf OK drücken, ohne etwas zu markieren, erscheint der Dialog erneut, bis Sie mindestens eine Option auswählen oder auf Abbrechen drücken, um den Fluss zu verlassen.",
|
||||
"headerMethod": "Methode",
|
||||
"headerMount": "Mount-Pfad",
|
||||
"headerUi": "Sichtbar in Datacenter > Storage",
|
||||
"headerUseCase": "Typischer Anwendungsfall",
|
||||
"rows": [
|
||||
{
|
||||
"method": "<strong>Als Proxmox-Speicher (pvesm)</strong>",
|
||||
"mountRich": "<code>/mnt/pve/<storage-id></code> (verwaltet von Proxmox)",
|
||||
"ui": "Ja",
|
||||
"useCase": "Backups, ISOs, LXC-Vorlagen - alles, was in der Proxmox-Benutzeroberfläche angezeigt werden muss. Live VM-Festplatten werden technisch unterstützt, aber von CIFS (Locking Semantics) abgeraten."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Nur Host-fstab</strong>",
|
||||
"mountRich": "<code>/mnt/<path></code> mit offenem uid/gid/file_mode",
|
||||
"ui": "Nein",
|
||||
"useCaseRich": "Die Freigabe per Bind-Mount in LXCs einbinden, <em>ohne</em> Proxmox-Speicher zu registrieren. Offene lokale Rechte erleichtern unprivilegierten CTs den Zugriff; Schreibzugriff muss der SMB-Server dem angemeldeten Benutzer trotzdem erlauben."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Beide</strong>",
|
||||
"mount": "Beide Pfade oben (zwei Mount-Punkte desselben CIFS-Exports)",
|
||||
"ui": "Ja",
|
||||
"useCase": "Sie wollen UI-Integration UND einen stabilen hostseitigen Pfad mit offenen Berechtigungen für LXC-Bind-Mounts. Der pvesm-Mount verwendet Proxmox-Standards; der fstab-Mount wendet das offene uid/gid/file_mode separat an."
|
||||
}
|
||||
],
|
||||
"bothTitle": "„Beide“ erstellt zwei CIFS-Mount-Punkte",
|
||||
"bothBody": "pvesm hängt unter <code>/mnt/pve/<id></code> mit Proxmox-Standardoptionen ein. fstab verwendet <code>/mnt/<path></code> mit <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> für lokalen Zugriff über LXC-Bind-Mounts. Der SMB-Server erzwingt weiterhin die Rechte des Mount-Benutzers. Zwei Mount-Punkte garantieren keine zwei getrennten TCP-Verbindungen."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Methode A — als Proxmox-Speicherung (pvesm)",
|
||||
"intro": "Wenn <em>Als Proxmox-Speicher</em> markiert ist, führt ProxMenux den ursprünglichen pvesm-Flow aus:",
|
||||
"items": [
|
||||
"<strong>Storage ID</strong> — Standard <code>cifs-<server-ip-with-dashes></code>. Nur Buchstaben, Ziffern, <code>-</code> und <code>_</code>.",
|
||||
"<strong>Inhaltstypen</strong> — diese ProxMenux-Auswahl bietet <strong>6</strong> Optionen. Gegenüber NFS fehlt <code>rootdir</code>. Das ist eine Entscheidung des Skripts und keine Aussage, dass jede Proxmox-CIFS-Version LXC-Root-Dateisysteme verbietet:"
|
||||
],
|
||||
"headerType": "Inhaltsart",
|
||||
"headerAllows": "Was es erlaubt",
|
||||
"rows": [
|
||||
{
|
||||
"type": "import",
|
||||
"allows": "Datenträgerbildimporte (standardmäßig ausgewählt)."
|
||||
},
|
||||
{
|
||||
"type": "backup",
|
||||
"allowsRich": "VM und CT Backup-Dateien (<code>vzdump</code>)."
|
||||
},
|
||||
{
|
||||
"type": "iso",
|
||||
"allows": "ISO-Abbildungen für die Installation."
|
||||
},
|
||||
{
|
||||
"type": "vztmpl",
|
||||
"allows": "LXC-Vorlagen."
|
||||
},
|
||||
{
|
||||
"type": "images",
|
||||
"allowsRich": "VM-Festplatten in Betrieb — <strong>mit Warnung im Dialog</strong>, siehe unten."
|
||||
},
|
||||
{
|
||||
"type": "snippets",
|
||||
"allows": "Hook-Scripts und Cloud-Init-Snippets."
|
||||
}
|
||||
],
|
||||
"warnTitle": "VM-Disks auf CIFS",
|
||||
"warnBody": "Die Auswahl <code>images</code> löst eine ProxMenux-Warnung aus: CIFS/SMB kann Sperrprobleme bei VM-Festplattenoperationen verursachen. Das Skript empfiehlt NFS, lässt Sie aber fortfahren. Sicherungen und ISOs sind typische CIFS-Anwendungen. Prüfen Sie Sperren, Snapshots, Migration und Last vor der Verwendung für <code>images</code>.",
|
||||
"credsTitle": "Wo pvesm Anmeldeinformationen speichert",
|
||||
"credsBody": "Das Passwort steht nicht in <code>/etc/pve/storage.cfg</code>. Proxmox schreibt Klartext-Zugangsdaten in <code>/etc/pve/priv/storage/<storage-id>.pw</code>, im privaten Bereich des Cluster-Dateisystems, den nur <code>root</code> lesen kann (Modus <code>0600</code>); geschützt sind sie durch Zugriffsrechte, nicht durch Verschlüsselung. Nach einer Passwortänderung am Server verwenden Sie <code>pvesm set <id> --password <new></code> oder entfernen und ergänzen den Speicher über ProxMenux erneut."
|
||||
},
|
||||
"fstabBranch": {
|
||||
"heading": "Methode B — nur ein fstab-Mount auf dem Host",
|
||||
"intro": "Wenn <em>Nur fstab-Mount auf dem Host</em> ausgewählt ist, fragt ProxMenux nach Host-Pfad und dauerhaften Optionen, erstellt im Benutzermodus eine nur für root lesbare Zugangsdaten-Datei, hängt die Freigabe ein und schreibt den Eintrag in <code>/etc/fstab</code>:",
|
||||
"items": [
|
||||
"<strong>Mount-Pfad auf dem Host</strong> — standardmäßig <code>/mnt/<share-name></code>. Es muss ein absoluter Weg sein. Wenn dort bereits etwas montiert ist oder ein fstab-Eintrag vorhanden ist, bietet ProxMenux an, ihn zu ersetzen.",
|
||||
"<strong>Mount-Optionen</strong> — <em>Lesen/Schreiben</em> (Standard: <code>rw,uid=0,gid=0,file_mode=0777,dir_mode=0777,iocharset=utf8,nofail,_netdev</code>), <em>Nur Lesen</em> (<code>file_mode=0555,dir_mode=0555</code>), <em>Benutzerdefiniert</em> (eigene Optionen eingeben). Das Skript empfiehlt offene uid/gid/file_mode für Schreibzugriffe über LXC-Bind-Mounts."
|
||||
],
|
||||
"credsTitle": "Anmeldedatendatei (Benutzermodus)",
|
||||
"credsBody": "Wenn Sie sich mit einem Benutzernamen + Passwort authentifiziert haben, schreibt ProxMenux eine Root-Only-Anmeldedatendatei unter <code>/etc/samba/credentials/<server>_<share>.cred</code> (Modus <code>0600</code>) mit <code>username=</code> und <code>password=</code> Zeilen und verweist sie im fstab-Eintrag über die <code>credentials=</code>-Mount-Option. Klartext landet nie in <code>/etc/fstab</code>. Für den Gastmodus wird stattdessen die Option <code>guest</code> angehängt und es wird keine Anmeldedatei erstellt.",
|
||||
"appliesIntro": "Sobald Sie bestätigen, das Skript:",
|
||||
"applies": [
|
||||
"<code>mkdir -p</code> der Mount Path.",
|
||||
"<code>mount -t cifs -o <opts>,credentials=<file></code> (oder <code>guest</code>) <code>//<srv>/<share> <path></code>.",
|
||||
"Schreibt einen einzeiligen Eintrag in <code>/etc/fstab</code>: <code>//<srv>/<share> <path> cifs <opts> 0 0</code>.",
|
||||
"Führt <code>systemctl daemon-reload</code> aus, so dass systemd den neuen Fstab-Eintrag abholt."
|
||||
],
|
||||
"lxcTitle": "Verwendung des fstab-Mounts aus einem unprivilegierten LXC",
|
||||
"lxcBody": "Die CIFS-Optionen <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> öffnen lokale Berechtigungsprüfungen für LXC-Bind-Mounts. Server-ACLs und ausgehandelte Unix-/POSIX-Semantik können den Zugriff weiterhin beeinflussen. <strong>Im Container wird nichts geändert</strong>: kein CT-<code>chown</code>, keine Gruppen oder Änderungen an <code>/etc/lxc</code>. Die <code>mp</code>-Zeile verwaltet Proxmox in der CT-Konfiguration. Verwenden Sie den angezeigten <code>pct set</code>-Befehl oder den <mountLink>LXC Mount Manager</mountLink>.",
|
||||
"noUiTitle": "Der fstab-Mount ist KEIN Proxmox-Speicher",
|
||||
"noUiBody": "Der fstab-Mount auf dem Host erscheint bewusst nicht in der Proxmox-Weboberfläche. Er fehlt unter <em>Datacenter > Storage</em>, lässt sich beim Erstellen einer VM oder eines CT nicht auswählen und kann nicht als Ziel eines Proxmox-Sicherungsauftrags dienen. Er ist lediglich ein Pfad im Dateisystem des Hosts. Wünschen Sie zusätzlich die Integration in die Oberfläche, wählen Sie <em>beide</em> Methoden aus."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"pvesmIntro": "Methode A (pvesm) bildet ab:",
|
||||
"fstabUserIntro": "Methode B (fstab, user auth) — Anmeldedatendatei + Mount:",
|
||||
"fstabGuestIntro": "Methode B (fstab, guest auth) — keine Anmeldedatendatei:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "CIFS-Speicher und Host-Mounts anzeigen",
|
||||
"body": "Zeigt registrierte CIFS-Speicher (<code>pvesm status | awk ''$2 == \"cifs\"''</code>) mit Server, Freigabe, Inhalt, Benutzer oder <em>Gast</em>, Pfad und Status. Passwörter werden <strong>nie ausgegeben</strong>. <strong>Hinweis:</strong> Ein zweiter Abschnitt zeigt Host-fstab-Mounts mit Optionen, Zugangsdaten-Dateipfad und Aktivitätsstatus. Manuelle Prüfung mit <code>findmnt -t cifs</code> oder <code>grep cifs /etc/fstab</code>."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "CIFS-Speicher oder Host-Mount entfernen",
|
||||
"body": "Die Auswahl enthält pvesm-Speicher und Host-fstab-Mounts. Für pvesm läuft <code>pvesm remove <storage-id></code>; Proxmox entfernt zugehörige Zugangsdaten. Für fstab versucht das Skript <code>umount <path></code>, entfernt den Eintrag aus <code>/etc/fstab</code> und Zugangsdaten unter <code>/etc/samba/credentials/</code> sowie nach Möglichkeit das leere Mount-Verzeichnis. Scheitert das Aushängen, sind manueller Unmount oder Neustart nötig. <strong>Der entfernte Samba-Server und seine Dateien bleiben unverändert</strong>.",
|
||||
"warnTitle": "Abhängigkeiten zuerst sichern",
|
||||
"warnBody": "VMs, CTs oder Backup-Jobs, die sich auf diesen Speicher nach ID beziehen, schlagen nach dem Entfernen fehl. Verschieben / löschen Sie diese Referenzen, bevor Sie den Speicher entfernen."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Samba Konnektivität testen",
|
||||
"body": "Führt einen Diagnosepass über jeden in Proxmox registrierten CIFS-Speicher aus: Prüft, ob <code>smbclient</code> verfügbar ist, pingt jeden Server, prüft die Ports 445 und 139, versucht eine Gästeliste und meldet die eigene Ansicht von Proxmox (<code>pvesm status</code>). \"Erfordert Authentifizierung\" auf der Gästeliste bedeutet, dass Ihr Server nur Anteile authentifizierten Benutzern aussetzt - normal für die meisten NAS-Setups."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noServersTitle": "\"Keine Samba-Server im Netzwerk gefunden\"",
|
||||
"noServersBody": "Auto-discover verwendet <code>nmap -p 139,445</code>. Der Server kann sich in einem anderen Subnetz befinden, eine Firewall haben oder nur über den Hostnamen (mDNS / WINS) erreichbar sein. Verwenden Sie stattdessen die Option <em>Manual</em> mit IP oder Hostname.",
|
||||
"noSharesTitle": "„Keine zugänglichen Freigaben gefunden“",
|
||||
"noSharesBody": "<code>smbclient -L</code> gab nichts für diese Anmeldeinformationen zurück. Ursachen: Der Benutzer hat keine Berechtigung zum Auflisten von Shares (versuchen Sie es einmal mit Admin-Anmeldeinformationen oder geben Sie den Share-Namen manuell ein), der Server hat die Share-Sichtbarkeit deaktiviert oder die Anmeldeinformationen sind falsch. Mit dem Skript können Sie den Share-Namen in diesem Fall von Hand eingeben.",
|
||||
"denyTitle": "Proxmox Mount scheitert mit NT_STATUS_ACCESS_DENIED",
|
||||
"denyBody": "Die gespeicherten Anmeldeinformationen pvesm sind nicht mit dem Samba-Server synchronisiert (Passwort geändert, Konto deaktiviert, Domain / Arbeitsgruppenfehlanpassung). Wiedereingabe von Anmeldeinformationen mit <code>pvesm set <id> --username <u> --password <p></code> oder Entfernen und erneutes Hinzufügen von ProxMenux. Wenn sich der Server in einer AD-Domäne befindet, fügen Sie <code>--domain <DOMAIN></code> an den <code>pvesm set</code>-Aufruf an.",
|
||||
"sleepTitle": "\"host is down\" oder der Speicherstatus wird nachts inaktiv",
|
||||
"sleepBody": "Einige NAS-Appliances setzen SMB aggressiv schlafen. <code>pvestatd</code> sieht den Speicher dann als inaktiv, bis der erste Zugriff den NAS weckt. Wenn das kosmetisch ist, ist nichts kaputt. Wenn es zu Backup-Fehlern kommt, deaktivieren Sie die SMB Leerlauftrennung am NAS oder planen Sie Backups außerhalb des Schlaffensters.",
|
||||
"lxcNoWriteTitle": "Unprivilegiertes LXC bind-mount kann nicht in den fstab Pfad schreiben",
|
||||
"lxcNoWriteBody": "Prüfen Sie <code>findmnt /mnt/<path></code> auf die vorgesehenen Optionen, etwa <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>. Fehlende lokale Schreibrechte können zugeordnete LXC-UIDs blockieren. Wenden Sie das RW-Profil erneut an oder passen Sie eigene Optionen an. Prüfen Sie auch die Schreibrechte des SMB-Benutzers auf dem Server und ob Unix-/POSIX-Erweiterungen Servermodi liefern. Offene lokale Modi umgehen keine Server-ACLs.",
|
||||
"fstabBootTitle": "fstab Mount wird nach dem Neustart nicht angezeigt",
|
||||
"fstabBootBody": "Das Skript fügt <code>nofail,_netdev</code> hinzu, so dass ein fehlende Freigabe beim Booten den Start nicht blockiert. Wenn der Mount nie auftaucht: Bestätigen Sie, dass das Netzwerk erreichbar ist (<code>ping <server></code>), überprüfen Sie <code>journalctl -u remote-fs.target</code>, überprüfen Sie, ob die Anmeldedatendatei noch vorhanden ist (<code>ls -l /etc/samba/credentials/</code>) und lesbar ist, und versuchen Sie <code>mount -a</code> manuell."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "NFS-Freigabe als Proxmox-Speicher",
|
||||
"tail": "— Geschwisterseite mit dem gleichen Flussmuster (Methode A pvesm + Methode B fstab) und Side-by-Side-Trade-offs."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Mount-Verwaltung",
|
||||
"tailRich": "— bind-mount den fstab-only Pfad <code>/mnt/<path></code> in einen oder mehrere Container."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Samba-Client in LXC",
|
||||
"tail": "— Alternative: Samba direkt aus einem privilegierten Container montieren (überspringt den Host)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,135 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox NFS, Samba, iSCSI und LXC-Mounts — Speicher und Freigaben | ProxMenux",
|
||||
"description": "Integrieren Sie externen und lokalen Speicher in Proxmox VE und teilen Sie Ordner zwischen dem Host und LXC-Containern. Fügen Sie NFS-Freigaben, Samba-Freigaben (CIFS) und iSCSI-Ziele als Proxmox-Speicher hinzu, richten Sie LXC-Bind-Mounts mit dem Mount Manager ein und betreiben Sie NFS-/Samba-Clients und -Server in Containern.",
|
||||
"ogTitle": "Proxmox NFS, Samba, iSCSI und LXC-Mounts — Speicher und Freigaben",
|
||||
"ogDescription": "Integrieren Sie externen / lokalen Speicher in Proxmox VE - NFS, Samba, iSCSI-Registrierung sowie LXC-Bind-Mounts und Netzwerkfreigabe.",
|
||||
"twitterTitle": "Proxmox NFS, Samba, iSCSI | ProxMenux",
|
||||
"twitterDescription": "Fügen Sie NFS / Samba / iSCSI als Proxmox-Speicher hinzu und teilen Sie Ordner zwischen Host und LXC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Speicher- und Freigabemanager",
|
||||
"description": "Integrieren Sie externen oder lokalen Speicher in Proxmox VE und teilen Sie Ordner zwischen dem Host und LXC-Containern. Drei Werkzeuggruppen: Host-Speicherintegration (Speicher direkt in Proxmox registrieren), der LXC Mount Manager (Bind-Mounts mit pragmatischer Rechteverwaltung) und LXC-Netzwerkfreigaben (NFS-/Samba-Client- und -Server-Abläufe für bestimmte Anwendungsfälle).",
|
||||
"section": "Speicher und Freigaben"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Wofür dieses Menü ist",
|
||||
"body": "Der Disk Manager arbeitet auf der Ebene von <em>individuellen physischen Disks</em>. Der Storage & Share Manager arbeitet eine Ebene höher – er <strong> registriert Speicherpools und Netzwerkfreigaben in Proxmox</strong> (damit die Benutzeroberfläche und der VM-Ersteller sie verwenden können) und <strong> richtet die Dateifreigabe zwischen dem Host und Ihren Containern</strong> ein."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Menüs",
|
||||
"body": "Wählen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager</strong>. Sie werden sehen:",
|
||||
"imageAlt": "Storage & Share Manager Menü mit HOST und LXC Blöcken"
|
||||
},
|
||||
"groups": {
|
||||
"heading": "Drei Werkzeuggruppen",
|
||||
"intro": "Das Menü ist in drei Gruppen aufgeteilt. <strong>Host-Speicherintegration</strong> registriert externen oder lokalen Speicher direkt in Proxmox. Der <strong>LXC Mount Manager</strong> ist das Hauptwerkzeug zur Ordnerfreigabe für Container — ein pragmatischer Bind-Mount-Ablauf, der die UID-Zuordnung unprivilegierter CTs auf dem Host berücksichtigt. <strong>LXC-Netzwerkfreigaben</strong> decken vier zusätzliche Szenarien ab, in denen ein Container NFS-/Samba-Freigaben direkt <em>nutzen</em> oder <em>bereitstellen</em> muss.",
|
||||
"hostTitle": "Host-Speicher",
|
||||
"hostBody": "Registrieren Sie externe und lokale Speicherung in Proxmox über <code>pvesm add …</code>. Nach der Registrierung erscheint der Speicher in der Proxmox-Benutzeroberfläche und steht den VM- und CT-Erstellern zur Verfügung.",
|
||||
"hostItems": [
|
||||
"Externer NFS / Samba / iSCSI → Proxmox Speicher",
|
||||
"Lokale Festplatte → Proxmox Verzeichnis oder ZFS Speicher",
|
||||
"Lokales freigegebenes Verzeichnis (für Bind-Mounts in mehrere CTs)"
|
||||
],
|
||||
"lxcMountTitle": "LXC-Mount-Verwaltung",
|
||||
"lxcMountBody": "Das primäre LXC-Sharing-Tool. Bindet Host-Verzeichnisse über <code>pct set -mpN</code> in Container ein und verarbeitet die Besonderheiten der Berechtigungen von unprivilegierten CTs, ohne eine Gruppe oder einen Benutzer im Container zu erstellen.",
|
||||
"lxcMountItems": [
|
||||
"Arbeitet mit privilegierten und unprivilegierten CTs",
|
||||
"Bietet <code>o+rwx</code> für das Hostverzeichnis an, um unprivilegierte UIDs zu unterstützen",
|
||||
"Behebt vorhandene CIFS / NFS Mounts bei Bedarf"
|
||||
],
|
||||
"lxcNetTitle": "LXC Netzwerkfreigabe",
|
||||
"lxcNetBody": "Vier zusätzliche Abläufe, wenn ein Container NFS-/Samba-Freigaben direkt nutzen oder bereitstellen muss. Alle erfordern einen <strong>privilegierten</strong> Container.",
|
||||
"lxcNetItems": [
|
||||
"NFS-/Samba-<strong>Client</strong> (externe Freigaben nutzen)",
|
||||
"NFS-/Samba-<strong>Server</strong> (CT-Ordner bereitstellen)"
|
||||
]
|
||||
},
|
||||
"host": {
|
||||
"heading": "Integration von Host-Speicher",
|
||||
"intro": "Speicher in Proxmox registrieren. Jede Option ruft <code>pvesm add …</code> unter der Haube auf, so dass der Speicher in <strong>Datacenter → Storage</strong> angezeigt wird und den VM / CT-Erstellern zur Verfügung steht.",
|
||||
"options": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"icon": "Network",
|
||||
"title": "NFS-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"description": "Registrieren Sie einen externen NFS-Export als Proxmox-Speicher über pvesm add nfs. Proxmox übernimmt das mount - keine fstab-einträge erforderlich."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"icon": "Share2",
|
||||
"title": "Samba-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"description": "Registrieren Sie eine externe Samba-/CIFS-Freigabe als Proxmox-Speicher über pvesm add cifs. Proxmox übernimmt das Einhängen und die Anmeldeinformationen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-iscsi",
|
||||
"icon": "Database",
|
||||
"title": "Hinzufügen von iSCSI-Ziel als Proxmox-Speicher",
|
||||
"description": "Verbinden Sie sich mit einem externen iSCSI-Ziel und registrieren Sie es als Proxmox-Speicher (Blockgerät) für VM-Disk-Images."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-disk",
|
||||
"icon": "HardDrive",
|
||||
"title": "Lokale Festplatte als Proxmox-Speicher hinzufügen",
|
||||
"description": "Formatieren Sie eine lokale SATA / SAS / NVMe-Festplatte und registrieren Sie sie als Proxmox-Verzeichnis oder ZFS-Poolspeicher."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"icon": "FolderOpen",
|
||||
"title": "Freigegebenes Verzeichnis auf dem Host hinzufügen",
|
||||
"description": "Erstellen Sie ein Host-Verzeichnis, das in mehrere CTs eingebunden werden soll. Kein Proxmox-Speicher - rein eine hostseitige Ressource für LXC-Bind-Mounts."
|
||||
}
|
||||
]
|
||||
},
|
||||
"lxcMount": {
|
||||
"heading": "LXC-Mount-Verwaltung",
|
||||
"intro": "Das primäre Tool zum Teilen von Ordnern zwischen dem Proxmox-Host und LXC-Containern. Es verwendet <code>pct set -mpN</code>, um ein Host-Verzeichnis in den Container zu binden, und behandelt die Besonderheiten der Berechtigungen von unprivilegierten CTs auf der Hostseite (es werden keine Gruppen oder Benutzer innerhalb des Containers erstellt).",
|
||||
"card": {
|
||||
"title": "LXC-Mountpoints (Host ↔ CT)",
|
||||
"description": "Binden Sie ein beliebiges Hostverzeichnis mit pct set -mpN in einen LXC-Container ein. Dies funktioniert mit privilegierten und unprivilegierten CTs. Das Werkzeug bietet chmod o+rwx und ACLs für das Hostverzeichnis an und korrigiert bei Bedarf vorhandene CIFS- oder NFS-Mounts."
|
||||
}
|
||||
},
|
||||
"lxcNet": {
|
||||
"heading": "LXC Netzwerkfreigabe",
|
||||
"intro": "Verwenden Sie diese Abläufe, wenn ein Container ein NFS-/Samba-Endpunkt <em>sein</em> muss — entweder eine externe Freigabe nutzen (Client) oder eigene Ordner bereitstellen (Server). Für die meisten Dateifreigaben (Bind-Mounts zwischen Host ↔ CT) ist der <mountLink>LXC Mount Manager</mountLink> einfacher und erfordert keine privilegierten Container.",
|
||||
"options": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"icon": "Download",
|
||||
"title": "NFS-Client in LXC",
|
||||
"description": "NFS-Freigaben innerhalb eines privilegierten LXC-Containers einhängen. Unterstützt automatische Erkennung, dauerhafte Einträge in /etc/fstab und sauberes Aushängen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"icon": "Download",
|
||||
"title": "Samba-Client in LXC",
|
||||
"description": "Samba-/CIFS-Freigaben innerhalb eines privilegierten LXC-Containers einhängen. Zugangsdaten werden geschützt gespeichert; automatische Erkennung ist verfügbar."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"icon": "Upload",
|
||||
"title": "NFS Server in LXC",
|
||||
"description": "Exportieren Sie Ordner über NFS aus einem privilegierten LXC-Container."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"icon": "Upload",
|
||||
"title": "Samba-Server in LXC",
|
||||
"description": "Geben Sie Ordner über SMB / CIFS aus einem privilegierten LXC-Container frei."
|
||||
}
|
||||
]
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privilegierte Containeranforderung",
|
||||
"body": "Die vier obigen Abläufe für <strong>LXC-Netzwerkfreigaben</strong> erfordern einen <strong>privilegierten</strong> Container. Die Skripte prüfen diesen unterstützten Modus, bevor sie Dienste und Mount-Werkzeuge konfigurieren (<code>nfs-kernel-server</code>, <code>smbd</code>, <code>mount.nfs</code>, <code>mount.cifs</code>). Wenn Sie nur Dateien zwischen Host und unprivilegiertem CT teilen möchten, verwenden Sie den <mountLink>LXC Mount Manager</mountLink>: Er bindet die Verzeichnisse vom Host aus ein und passt dort die Rechte an, sodass der Container lesen und schreiben kann, ohne diese Dienste oder Werkzeuge in ihm einzurichten."
|
||||
},
|
||||
"unprivExplain": {
|
||||
"title": "Wie ProxMenux unprivilegierte CT-Berechtigungen verarbeitet",
|
||||
"body": "Unprivilegierte LXC-Container verschieben ihre UIDs auf dem Host um <strong>+100000</strong> (Container-UID 0 = Host-UID 100000, Container-UID 1000 = Host-UID 101000, …). Eine von einem Container-Benutzer erstellte Datei erscheint daher auf dem Host als <em>andere</em> — sie gehört keinem regulären Host-Benutzer oder keiner regulären Host-Gruppe. Der LXC Mount Manager löst dies pragmatisch: Statt UIDs/GIDs zwischen Host und CT abzugleichen, bietet er <code>chmod o+rwx</code> mit passenden ACLs für das Hostverzeichnis an, sodass jede zugeordnete UID lesen und schreiben kann. CIFS wird mit <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> neu eingehängt; bei NFS wird ein für alle beschreibbares Verzeichnis mit Sticky-Bit eingerichtet. Bei Root-Squashing weist das Werkzeug auf die nötige serverseitige Korrektur hin."
|
||||
},
|
||||
"scripts": {
|
||||
"heading": "Involvierte Skripte",
|
||||
"intro": "Jede einzelne Seite verlinkt auf das Skript, das seinen Fluss antreibt. Die folgende Datei ist ein gemeinsamer Helfer, der nicht als eigene Seite dokumentiert ist, sondern von mehreren LXC-Netzwerk-Sharing-Flows verwendet wird:",
|
||||
"itemTail": "CT-Validierung, Einhängepunktauswahl, privilegierte Überprüfung und universelle Gruppeneinrichtungshelfer, die über die LXC-Client- / Serverflüsse hinweg geteilt werden."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,174 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "LXC-Einhängepunkte (Host ↔ Container) | ProxMenux-Dokumentation",
|
||||
"description": "Der LXC Mount Manager bindet ein beliebiges Hostverzeichnis mit pct set -mpN in einen oder mehrere LXC-Container ein. Er berücksichtigt Besonderheiten der Berechtigungen unprivilegierter Container, korrigiert vorhandene CIFS- und NFS-Mounts auf dem Host und verändert nichts im Container.",
|
||||
"ogTitle": "LXC-Einhängepunkte (Host ↔ Container) | ProxMenux-Dokumentation",
|
||||
"ogDescription": "Bind-Mount-Hostverzeichnisse in LXC-Containern. Behandelt unprivilegiertes UID-Mapping pragmatisch, behebt CIFS / NFS-Zugriff auf der Hostseite."
|
||||
},
|
||||
"header": {
|
||||
"title": "LXC-Einhängepunkte (Host ↔ Container)",
|
||||
"description": "Das primäre Tool zum Teilen von Ordnern zwischen dem Proxmox-Host und LXC-Containern. Bindet ein beliebiges Hostverzeichnis in einen oder mehrere Container mit Proxmox's nativer pct set -mpN-Syntax. Die Besonderheit: Es löst die Berechtigungsprobleme von unprivilegierten Containern auf der Hostseite - es ändert niemals etwas im Container.",
|
||||
"section": "Speicher und Freigaben · LXC"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Was das macht",
|
||||
"body": "Nehmen Sie ein Verzeichnis, das sich auf dem Proxmox-Host befindet (ein lokaler Ordner, eine eingehängte NAS-Freigabe, ein von Proxmox verwalteter Speicher ...) und lassen Sie es in einem LXC-Container auf einem von Ihnen gewählten Pfad erscheinen, mit Berechtigungen, die auch für unprivilegierte Container funktionieren - ohne etwas im Container zu berühren."
|
||||
},
|
||||
"bigPicture": {
|
||||
"heading": "Wie es funktioniert (das große Bild)",
|
||||
"intro": "Bei einem Bind-Mount weist Proxmox den Kernel an, das Hostverzeichnis <code>X</code> auch unter <code>Y</code> im Container bereitzustellen. Keine Kopie, keine Synchronisierung, kein Netzwerk: Beide Seiten sehen gleichzeitig die <em>gleichen Dateien</em>.",
|
||||
"sourceLabel": "Proxmox-Host",
|
||||
"sourceDetail": "/mnt/data\n(Ihr Ordner)",
|
||||
"targetLabel": "LXC-Container",
|
||||
"targetDetail": "/mnt/data\n(erscheint hier)",
|
||||
"arrowLabel": "Bind-Mount",
|
||||
"outro": "Der Host-Pfad links und der Container-Pfad rechts können unterschiedlich sein - zum Beispiel kann <code>/mnt/nas-films</code> auf dem Host <code>/media/films</code> innerhalb des Containers werden. Das Skript fügt den Eintrag zur Container-Konfiguration (<code>/etc/pve/lxc/<ctid>.conf</code>) mit dem nächsten freien <code>mpN</code>-Index hinzu, wobei zwei sichere Standardeinstellungen eingebaut sind:",
|
||||
"items": [
|
||||
"<code>shared=1</code> — kennzeichnet die Daten als gemeinsam genutzt, sodass Proxmox sie nicht mit dem CT migriert. Das Flag repliziert keine Daten: Derselbe Pfad und dieselben Daten müssen auf dem Zielknoten bereits verfügbar sein.",
|
||||
"<code>backup=0</code> – schließt die Bind-Mount von <code>vzdump</code>-Backups aus (die Daten leben auf dem Host, Sie sichern sie separat)."
|
||||
]
|
||||
},
|
||||
"perms": {
|
||||
"heading": "Berechtigungen handhaben",
|
||||
"intro": "Bind-Mounts sind prinzipiell einfach. Der schwierige Teil sind Berechtigungen: Ein <strong>unprivilegierter</strong> LXC-Container verschiebt jede UID durch <strong> + 100000</strong>, so dass eine Datei, die vom Benutzer 1000 im Container erstellt wurde, auf dem Host als UID 101000 erscheint - eine UID, die niemand auf dem Host besitzt. Um dies zu ermöglichen, ohne UIDs über Hosts und Container auszurichten, wendet ProxMenux den richtigen \"Öffnen von Berechtigungen\" -Trick auf der <em>Host</em>-Seite an, je nachdem, welche Art von Verzeichnis Sie ausgewählt haben:",
|
||||
"headerType": "Host-Verzeichnistyp",
|
||||
"headerAction": "Was das Skript zu tun anbietet",
|
||||
"localType": "Lokaler Ordner",
|
||||
"localTypeSub": "z.B. /mnt/data",
|
||||
"localActionRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> im Hostverzeichnis. Nur angeboten, wenn der CT nicht privilegiert ist und die aktuellen Berechtigungen nicht ausreichen.",
|
||||
"cifsType": "Eingehängtes CIFS / SMB",
|
||||
"cifsTypeSub": "z.B. /mnt/pve/cifs-…",
|
||||
"cifsActionRich": "Remount mit <code>uid=0, gid=0, file_mode=0777, dir_mode=0777</code>, damit der CT (jede UID) die Freigabe lesen und schreiben kann. <code>/etc/fstab</code> wird aktualisiert.",
|
||||
"nfsType": "Eingehängtes NFS",
|
||||
"nfsTypeSub": "z.B. /mnt/pve/nfs-…",
|
||||
"nfsActionRich": "<code>chmod 1777</code> und <code>setfacl o::rwx</code> auf dem NFS-Mount. Serverseitiges Squashing lässt sich damit nicht umgehen. Kann selbst root auf dem Host nicht schreiben, werden Sie zur Korrektur des Exports auf dem NFS-Server angeleitet.",
|
||||
"privTitle": "Privilegierte Container benötigen nichts davon",
|
||||
"privBody": "Für privilegierte Container ist UID 0 im CT UID 0 auf dem Host - root im CT kann das Hostverzeichnis direkt ohne Berechtigungstricks lesen und schreiben. Das Skript erkennt dies und überspringt den Schritt \"Öffnen von Berechtigungen\" vollständig.",
|
||||
"noCtTitle": "Das Skript ändert niemals etwas im Container",
|
||||
"noCtBody": "Alle Berechtigungsanpassungen erfolgen auf dem <strong>host-Dateisystem</strong>. Keine <code>pct exec</code>-Chowns, keine im CT erstellten Gruppen, kein Fstab im Container. Wenn Sie das bind-mounted-Verzeichnis später in einem anderen CT wiederverwenden, gelten die gleichen Berechtigungen automatisch - keine Einrichtung pro Container."
|
||||
},
|
||||
"writes": {
|
||||
"heading": "Was ProxMenux schreibt - und was nicht",
|
||||
"intro": "Eine häufige Verwirrung beim Binden in einen unprivilegierten CT: Die Leute gehen davon aus, dass ProxMenux <code>lxc.idmap</code>-Einträge in <code>/etc/pve/lxc/<CTID>.conf</code> schreiben muss. <strong>Das tut es nicht.</strong> Nur eine Zeile ist an diese Datei angehängt – das Bind-Mount selbst:",
|
||||
"outro": "Die Ausgabezeile, die Sie am Ende des Laufs sehen, <em>\"Unprivilegierter Container - UID-Offset: 100000\"</em>, ist rein informativ - sie sagt Ihnen nur, dass der CT die standardmäßige unprivilegierte Zuordnung von Proxmox verwendet (root in CT = UID 100000 auf Host). Das Skript konfiguriert nichts um es herum.",
|
||||
"twoWaysHeading": "Die beiden Möglichkeiten, Berechtigungen funktionieren zu lassen - und warum ProxMenux eine auswählt",
|
||||
"headerApproach": "Ansatz",
|
||||
"headerChanges": "Was es verändert",
|
||||
"headerWhen": "Wenn es passt",
|
||||
"hostType": "Berechtigungen auf dem Host",
|
||||
"hostTypeSub": "(Was dieses Skript macht)",
|
||||
"hostChangesRich": "<code>chmod o+rwx</code> + <code>setfacl o::rwx</code> im Hostverzeichnis. Die abgebildeten UIDs des CT (100000+) fallen in den \"Anderen\"-Bucket, so dass das Öffnen von <em>andere</em> ausreicht.",
|
||||
"hostWhen": "Generic Shared-Ordner-Zugriff von jedem CT. Mehrere CTs teilen sich das gleiche Hostverzeichnis. Einfach und wiederverwendbar.",
|
||||
"idmapTypeRich": "<code>lxc.idmap</code>",
|
||||
"idmapTypeSub": "(nicht von diesem Skript verwendet)",
|
||||
"idmapChangesRich": "Benutzerdefiniertes UID/GID-Mapping in <code>/etc/pve/lxc/<CTID>.conf</code> plus passende <code>/etc/subuid</code> + <code>/etc/subgid</code> Einträge auf dem Host. CT muss bei jeder Änderung neu gestartet werden.",
|
||||
"idmapWhenRich": "Sie benötigen eine <em>bestimmte</em> UID innerhalb der CT, um einer <em>bestimmte</em> UID auf dem Host zuzuordnen (z.B.) <code>media:1000</code> im CT muss Dateien als <code>media:1000</code> auf dem Host besitzen, damit NFS nicht quetscht. Ein starreres Setup, das sich normalerweise nur für genau dieses Szenario lohnt.",
|
||||
"idmapTipTitle": "Wenn Sie lxc.idmap tatsächlich benötigen",
|
||||
"idmapTipBody": "Verwenden Sie manuelle ID-Zuordnung, wenn im CT geschriebene Dateien auf dem Host einer bestimmten numerischen UID/GID gehören sollen, etwa für gemeinsame Eigentümerschaft mit einem Hostbenutzer. Sie umgeht NFS-<code>all_squash</code> nicht; anonyme Identität und Rechte bestimmt weiterhin der Server. Fügen Sie bei Bedarf <code>lxc.idmap</code>-Einträge von Hand hinzu. Die Bind-Mount-Zeile ist davon unabhängig."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → Konfigurieren Sie LXC Mount Points (Host ↔ Container)</strong>. Sie sehen dieses sub-Menü mit drei Optionen:",
|
||||
"imageAlt": "LXC Mount Manager-Menü - Hinzufügen / Ansicht / Entfernen"
|
||||
},
|
||||
"addFlow": {
|
||||
"heading": "Mount hinzufügen — vollständiger Ablauf",
|
||||
"intro": "Die technische Ansicht, wenn Sie genau wissen möchten, was jeder Dialog tut:"
|
||||
},
|
||||
"sources": {
|
||||
"heading": "Was Sie als Host-Verzeichnis auswählen können",
|
||||
"intro": "Der Host-Verzeichnis-Picker ist der gründlichste im Abschnitt Storage & Share. Es scannt vier Quellen und präsentiert eine deduplizierte Liste:",
|
||||
"headerSource": "Quelle",
|
||||
"headerWhere": "Woher es kommt",
|
||||
"headerLabel": "Label im Menü",
|
||||
"rows": [
|
||||
{
|
||||
"source": "Aktive Netzwerk-Mounts",
|
||||
"whereRich": "Aktuell eingehängte CIFS-/NFS-Freigaben aus <code>/proc/mounts</code>.",
|
||||
"labelRich": "<code>NFS [used/size]</code> oder <code>CIFS/SMB [used/size]</code>"
|
||||
},
|
||||
{
|
||||
"source": "Inaktive fstab-Mounts",
|
||||
"whereRich": "Definiert in <code>/etc/fstab</code>, aber derzeit nicht montiert.",
|
||||
"labelRich": "<code>fstab(off)-NFS</code> / <code>fstab(off)-CIFS/SMB</code>"
|
||||
},
|
||||
{
|
||||
"source": "Lokale Verzeichnisse",
|
||||
"whereRich": "Sub-Verzeichnisse unter <code>/mnt</code>, die keine Netzwerk-Mounts sind.",
|
||||
"labelRich": "<code>Local [size]</code>"
|
||||
},
|
||||
{
|
||||
"source": "Proxmox-Speicher",
|
||||
"whereRich": "Speicherpfade unter <code>/mnt/pve/*</code> (NFS / CIFS registriert über <code>pvesm</code>).",
|
||||
"labelRich": "<code>PVE-NFS</code> / <code>PVE-CIFS/SMB</code> / <code>Proxmox-Storage</code>"
|
||||
},
|
||||
{
|
||||
"source": "Manuelle Eingabe",
|
||||
"where": "Alles andere - geben Sie den absoluten Pfad selbst ein.",
|
||||
"labelRich": "<em>Pfad manuell eingeben</em>"
|
||||
}
|
||||
],
|
||||
"tipTitle": "Interne Proxmox Pfade werden herausgefiltert",
|
||||
"tipBody": "Der Picker überspringt explizit interne Proxmox-Pfade (<code>/mnt/pve/local</code>, <code>/mnt/pve/local-lvm</code>, <code>/mnt/pve/backup</code>, ...) – diese sind für Proxmox-Interna reserviert und Sie sollten sie nicht binden. Nur vom Benutzer hinzugefügte Speicher werden angezeigt."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"privIntro": "Für einen privilegierten Container — der einfachste Fall, keine Berechtigung Tricks:",
|
||||
"unprivLocalIntro": "Für einen unprivilegierten Container mit einem lokalen Host-Verzeichnis - öffnen Sie zuerst Berechtigungen auf dem Host:",
|
||||
"unprivCifsIntro": "Für einen unprivilegierten Container mit einem CIFS-Freigabe, der bereits auf dem Host montiert ist:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Einhängepunkte anzeigen",
|
||||
"body": "Listet jeden <code>mpN</code>-Eintrag für jeden Container auf diesem Proxmox-Host auf, gruppiert nach CT ID und zeigt Hostpfad → Containerpfad plus zusätzliche Optionen an. Nur Lesen - nützlich als Plausibilitätsprüfung, bevor Sie etwas hinzufügen oder entfernen."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Einhängepunkt entfernen",
|
||||
"body": "Wählen Sie den Container, wählen Sie den <code>mpN</code>-Eintrag, bestätigen Sie. Das Skript führt <code>pct set --delete mpN</code> aus, um den Eintrag aus der CT-Konfiguration zu löschen, und bietet an, den Container neu zu starten, wenn er ausgeführt wird. Das Host-Verzeichnis und sein Inhalt sind <strong>unverändert</strong> – Sie können das Mount später erneut hinzufügen (oder dasselbe Verzeichnis an ein anderes CT) anhängen.",
|
||||
"warnTitle": "Live-laufende Container benötigen einen Neustart, damit Änderungen wirksam werden können",
|
||||
"warnBody": "Sowohl Hinzufügen als auch Entfernen von Befestigungspunkten werden erst nach einem Neustart im Inneren des Containers sichtbar. Das Skript bietet einen <code>pct reboot</code> mit einem Klick am Ende jeder Operation; Sie können später manuell ablehnen und neu starten."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"noMountTitle": "Mount erscheint in pct config, aber nicht im Container",
|
||||
"noMountBody": "Bind-Mounts werden nur dann angebracht, wenn der Container startet. Wenn Sie die Mount hinzugefügt haben, während die CT ausgeführt wurde, starten Sie sie neu (<code>pct reboot <ctid></code>). Wenn es bereits neu gestartet wurde und immer noch fehlt, überprüfen Sie <code>pct config <ctid></code>, um zu bestätigen, dass der Eintrag existiert und der Hostpfad tatsächlich ein Verzeichnis enthält.",
|
||||
"noWriteTitle": "Container kann das Verzeichnis sehen, aber nicht schreiben",
|
||||
"noWriteBody": "Fast immer ein Berechtigungsproblem. Führen Sie bei unprivilegierten Containern die Berechtigungskorrektur des Skripts erneut aus - die ACLs des Hostverzeichnisses wurden möglicherweise von einem anderen Tool zurückgesetzt (rsync, Wiederherstellen aus dem Backup, manuelles <code>chmod</code>). Überprüfen Sie für CIFS die Mount-Optionen auf dem Host: <code>findmnt /mnt/pve/cifs-…</code>, suchen Sie nach <code>uid=</code> / <code>gid=</code> / <code>file_mode=</code> Werten.",
|
||||
"alreadyTitle": "\"Dieser Pfad wird bereits als Einhängepunkt in diesem Container verwendet\"",
|
||||
"alreadyBody": "Sie haben den gleichen Containerpfad ausgewählt, der bereits mit einem anderen Hostverzeichnis verdrahtet ist. Wählen Sie entweder einen anderen Containerpfad oder entfernen Sie zuerst den vorhandenen Montagepunkt.",
|
||||
"nfsTitle": "NFS-Zugriff auch nach Anwendung des Host-Fixes blockiert",
|
||||
"nfsIntro": "Ihr NFS-Server quetscht Root oder alle Verbindungen. Das Skript kann dies erkennen (es versucht, eine Testdatei vom Host zu schreiben) und zeigt die serverseitige Anleitung. Zwei gängige serverseitige Fixes für den Export:",
|
||||
"nfsItems": [
|
||||
"<code>no_root_squash</code> - privilegierte CTs können direkt schreiben.",
|
||||
"<code>all_squash,anonuid=65534,anongid=65534</code> — für unprivilegierte CTs."
|
||||
],
|
||||
"nfsOutro": "Diese Änderungen finden auf dem NFS-Server (TrueNAS, Synology, Ihr benutzerdefinierter Export, ...) statt, nicht auf Proxmox.",
|
||||
"fstabOffTitle": "\"Fstab(off)\"-Einträge machen nichts",
|
||||
"fstabOffBody": "Der Picker zeigt <code>fstab(off)-</code>-Einträge an, wenn ein Netzwerk-Mount in fstab definiert, aber derzeit nicht montiert ist. Mit dem Skript können Sie den Pfad bind-mounten, aber das Verzeichnis wird leer sein, bis Sie die Freigabe tatsächlich mounten (<code>mount <path></code> auf dem Host). Montieren Sie es zuerst und binden Sie es dann in den CT."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/host-local-shared",
|
||||
"label": "Shared Directory auf Host hinzufügen",
|
||||
"tailRich": "— typischer erster Schritt: Bereiten Sie einen <code>/mnt/shared</code> auf dem Host vor, bevor Sie ihn hier in einen oder mehrere CTs binden."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "NFS-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"extraHref": "/docs/storage-share/host-samba",
|
||||
"extraLabel": "Samba-Freigabe als Proxmox-Speicher hinzufügen",
|
||||
"joiner": " / ",
|
||||
"tailRich": "- registrieren Sie zuerst eine externe Freigabe in Proxmox und binden Sie dann den <code>/mnt/pve/<id></code>-Pfad hier in den CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "NFS-Client in LXC",
|
||||
"extraHref": "/docs/storage-share/lxc-samba-client",
|
||||
"extraLabel": "Samba-Client in LXC",
|
||||
"joiner": " / ",
|
||||
"tail": "- die Alternative, wenn Sie möchten, dass der CT selbst die Freigabe anbringt (erfordert einen privilegierten Container)."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,128 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "NFS Client in LXC | ProxMenux Dokumentation",
|
||||
"description": "NFS-Freigaben direkt in einem Proxmox-LXC-Container mit ProxMenux einhängen. Installiert nfs-common automatisch, unterstützt automatische Erkennung im LAN, dauerhafte Mounts über /etc/fstab und sichere Starteinstellungen. Erfordert einen privilegierten Container.",
|
||||
"ogTitle": "NFS Client in LXC | ProxMenux Dokumentation",
|
||||
"ogDescription": "NFS-Freigaben in einem privilegierten LXC einhängen. Automatische Erkennung, dauerhafte Einträge in /etc/fstab und sichere Starteinstellungen."
|
||||
},
|
||||
"header": {
|
||||
"title": "NFS-Client in LXC",
|
||||
"description": "NFS-Freigaben direkt in einem Proxmox-LXC-Container einhängen. Der Container ist ein eigener NFS-Client: Er kommuniziert über das Netzwerk mit dem Server, führt mount.nfs aus und schreibt in /etc/fstab. ProxMenux installiert nfs-common, hilft beim Auffinden von Servern und Exporten und setzt sichere Starteinstellungen.",
|
||||
"section": "Speicher und Freigaben · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privilegierter Container erforderlich",
|
||||
"body": "Der Kernel-<code>mount.nfs</code>-Client benötigt Funktionen (mindestens <code>SYS_ADMIN</code>), die nicht privilegierte LXC-Container nicht bereitstellen. Das Skript erzwingt dies - es fordert Sie auf, einen CT auszuwählen, und <strong>bricht bei unprivilegierten CTs ab</strong>. Wenn Sie die Freigabe in einem unprivilegierten CT benötigen, montieren Sie sie zuerst auf dem Proxmox-Host (mit <hostNfsLink>NFS-Freigabe als Proxmox-Speicher</hostNfsLink>) und binden Sie sie mit dem <mountLink>LXC-Mount-Manager</mountLink> in den CT ein."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Was das macht",
|
||||
"body": "Im Gegensatz zum LXC Mount Manager, der den CT dazu bringt, etwas <em>via</em> im Proxmox-Host zu sehen, gibt dieses Skript dem Container seinen <strong>eigenen NFS-Client</strong>: Er spricht NFS über das Netzwerk, mountet Shares direkt vom NFS-Server und speichert das Mount im <code>/etc/fstab</code> des Containers. Der Proxmox-Host befindet sich nicht im Datenpfad.",
|
||||
"diagramServerLabel": "NFS-Server",
|
||||
"diagramServerDetail": "/export/data",
|
||||
"diagramHostLabel": "Proxmox-Host",
|
||||
"diagramHostDetail": "(nur eine\nNetzwerkbrücke)",
|
||||
"diagramCtLabel": "LXC (privilegiert)",
|
||||
"diagramCtDetail": "/mnt/data\nmount.nfs im CT",
|
||||
"diagramArrow": "NFS",
|
||||
"twoWaysTitle": "Zwei Möglichkeiten, einem CT NFS Zugang zu gewähren - wählen Sie einen",
|
||||
"twoWaysBind": "<strong>Bind-Mount über den Host</strong> (<mountLink>LXC Mount Manager</mountLink>): Der Host bindet die NFS-Freigabe einmal ein; jeder CT erhält denselben Pfad als Bind-Mount. Funktioniert mit unprivilegierten CTs und empfiehlt sich, wenn mehrere CTs dieselbe Freigabe benötigen.",
|
||||
"twoWaysDirect": "<strong>Direct NFS Mount im CT</strong> (diese Seite): Der CT montiert den NFS selbst. Erfordert Privilegien. Nützlich, wenn der CT seine Verbindung / Anmeldeinformationen besitzen muss, oder für Setups, bei denen jeder CT mit einem anderen Server spricht."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → NFS-Client in LXC (nur privilegiert)</strong> konfigurieren. ProxMenux fordert Sie zuerst auf, <strong> das Ziel CT</strong> auszuwählen (und startet es, wenn es gestoppt wird); abbricht, wenn es nicht privilegiert ist. Sobald das CT ausgewählt ist, sehen Sie dieses sub-Menü:",
|
||||
"imageAlt": "NFS Client-Manager-Menü — Mount / View / Unmount / Testverbindung"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft (Mount Flow)"
|
||||
},
|
||||
"fstabFlags": {
|
||||
"heading": "Warum diese Fstab Flags",
|
||||
"intro": "Für permanente Mounts fügt das Skript drei Flags hinzu, die über die Standard-NFS-Optionen hinausgehen: <code>_netdev,x-systemd.automount,noauto</code>. Jeder löst ein echtes Boot-Time-Problem:",
|
||||
"headerFlag": "Flagge",
|
||||
"headerEffect": "Was es tut",
|
||||
"rows": [
|
||||
{
|
||||
"flag": "_netdev",
|
||||
"effect": "Sagt dem init-system, dass dieses mount das netzwerk benötigt. Boot blockiert nicht das Warten darauf, bevor das Netzwerk aufgebaut ist."
|
||||
},
|
||||
{
|
||||
"flag": "x-systemd.automount",
|
||||
"effectRich": "Erstellt eine automatische systemd-Einheit: Die Mount erfolgt nur beim ersten Zugriff auf <code>/mnt/<path></code>. NFS-Server, der beim Booten nicht erreichbar ist, stoppt den CT nicht."
|
||||
},
|
||||
{
|
||||
"flag": "noauto",
|
||||
"effect": "Überspringt das sofortige Einhängen beim Booten. Zusammen mit der Automount-Einheit wird der Mount erst beim ersten Zugriff eingerichtet."
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Nettoeffekt",
|
||||
"netEffectBody": "Das NFS-Dateisystem wird beim <em>ersten Zugriff</em> eingehängt statt sofort beim Booten. Ist der Server offline, kann dieser Zugriff warten oder fehlschlagen; davon abhängige Dienste können betroffen sein. Automount verringert die Abhängigkeit beim Booten, garantiert aber nicht, dass alle CT-Dienste von einem NFS-Ausfall unberührt bleiben."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Replizieren Sie den gesamten Ablauf per Hand – jeder Befehl führt <strong> im CT</strong> über <code>pct exec <ctid> --</code> oder direkt über <code>pct enter <ctid></code> aus:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Aktuelle Mounts anzeigen",
|
||||
"body": "Listet jeden NFS-Montagepunkt auf, der innerhalb des CT (<code>mount | grep nfs</code>) aktiv ist, sowie jede NFS-Linie im <code>/etc/fstab</code> des CT. Für jeden fstab-eintrag wird der live-mount-status angezeigt - nützlich, um permanente mounts zu erkennen, die beim booten nicht aufgekommen sind."
|
||||
},
|
||||
"unmount": {
|
||||
"heading": "NFS-Freigabe aushängen",
|
||||
"body": "Kombiniert die Live-Mounts und die fstab-Einträge in einer Liste, lässt Sie einen auswählen und <strong>entfernt die entsprechende Zeile aus <code>/etc/fstab</code></strong>. Das Skript führt <em>nicht</em> <code>umount</code> auf dem Live-Mount aus – stattdessen teilt es Ihnen mit, dass ein CT Neustart erforderlich ist, damit das Unmounten wirksam wird.",
|
||||
"warnTitle": "Das Skript entfernt fstab-Einträge, nicht Live-Mounts",
|
||||
"warnBody": "Dies ist eine bewusste Entscheidung: <code>umount</code> schlägt bei einem noch verwendeten Mount mit „device busy“ fehl, wenn ein Prozess im CT darauf zugreift. Ohne den fstab-Eintrag wird der Mount beim nächsten CT-Start nicht erneut eingerichtet. Soll er <em>sofort</em> verschwinden und sind Sie sicher, dass nichts mehr darauf zugreift, führen Sie nach Abschluss des Skripts <code>pct exec <ctid> -- umount /mnt/<path></code> manuell aus."
|
||||
},
|
||||
"test": {
|
||||
"heading": "NFS-Verbindung testen",
|
||||
"body": "Diagnose im CT: Prüft, ob <code>nfs-common</code> installiert ist und <code>rpcbind</code> läuft, und listet die aktuellen NFS-Mounts auf. Anschließend wird für jeden in fstab eingetragenen NFS-Server die Folge Ping → Port 2049 → <code>showmount -e</code> geprüft. Ein sinnvoller erster Schritt, wenn ein dauerhafter Mount nicht verfügbar wird."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"privTitle": "Privilegierter Container erforderlich (Skript bricht ab)",
|
||||
"privBody": "Der ausgewählte CT ist unprivilegiert. Der Kernel-NFS-Client benötigt <code>SYS_ADMIN</code>-Fähigkeiten, die nicht privilegierte CTs nicht aussetzen. Entweder konvertieren Sie die CT in privilegierte (die Konvertierung von Disk Manager & ist auf der <importLink>Import Disk in LXC</importLink> Seite dokumentiert) oder verwenden Sie den alternativen Pfad, der in der Warnung oben auf dieser Seite beschrieben ist.",
|
||||
"aptTitle": "apt-get install nfs-common fails",
|
||||
"aptIntro": "Das Skript nimmt eine Debian-Familie CT (<code>apt-get</code>) an. Wenn der CT Alpine / Arch / Rocky / Alma läuft, schlägt der Installationsschritt lautlos fehl. Installieren Sie den NFS-Client von Hand für diese Distribution:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add nfs-utils</code>",
|
||||
"Arch: <code>pacman -S nfs-utils</code>",
|
||||
"Rocky / Alma: <code>dnf install nfs-utils</code>"
|
||||
],
|
||||
"aptOutro": "Führen Sie dann das ProxMenux-Skript erneut aus - der Installationsschritt überspringt, wenn die Tools bereits vorhanden sind.",
|
||||
"portTitle": "\"NFS port (2049) is not accessible\"",
|
||||
"portBody": "Ping war erfolgreich, aber <code>nc -z <server> 2049</code> scheiterte innerhalb des CT. Überprüfen Sie, ob der NFS-Dienst auf dem Server ausgeführt wird, ob die Firewall 2049 aus dem Netzwerk des CT zulässt und ob der CT tatsächlich eine gültige Netzwerkroute hat (probieren Sie <code>pct exec <ctid> -- ip route</code>).",
|
||||
"bootTitle": "Permanent Mount gelingt, kommt aber nicht beim Booten",
|
||||
"bootBody": "Fast immer einer von: Das Netzwerk ist nicht bereit, wenn die CT-Mounts (die <code>_netdev,x-systemd.automount,noauto</code>-Flags des Skripts beheben dies - fügen Sie das Mount über das Skript erneut hinzu, wenn Sie die Fstab-Zeile von Hand ohne diese geschrieben haben), der Server ist beim Booten nicht erreichbar (Auto-Mount wartet auf den ersten Zugriff - das ist normal), oder DNS ist beim Booten ungelöst (verwenden Sie die IP des Servers, nicht seinen Hostnamen).",
|
||||
"squashTitle": "Server Squashes root, kein Schreibzugriff von innen CT",
|
||||
"squashIntro": "Der NFS-Export verwendet <code>root_squash</code> (Standard) und der CT schreibt als root. Zwei Optionen:",
|
||||
"squashItems": [
|
||||
"Server-Seite: Ändern Sie den Export in <code>no_root_squash</code> (nur wenn Sie dem CT vertrauen).",
|
||||
"CT-Seite: Schreiben Sie als Nicht-Root-Benutzer, den der Server akzeptiert, oder chownen Sie die Freigabe entsprechend."
|
||||
],
|
||||
"squashOutro": "ProxMenux kann dies nicht beheben - es ist eine Serverrichtlinie."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Einhängepunkte (Host ↔ Container)",
|
||||
"tail": "— die Alternative für unprivilegierte CTs: mount on host, bind in CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Samba-Client in LXC",
|
||||
"tail": " — verwandte Seite mit demselben Ablauf für SMB-/CIFS-Freigaben."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"label": "NFS Server in LXC",
|
||||
"tailRich": " — die umgekehrte Richtung: Ordner <em>aus</em> einem CT über NFS freigeben."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "NFS-Freigabe als Proxmox-Speicher",
|
||||
"tail": " — die Freigabe direkt in Proxmox statt in einem einzelnen CT registrieren."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,159 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "NFS Server in LXC | ProxMenux Dokumentation",
|
||||
"description": "Ordner über NFS aus einem Proxmox-LXC-Container mit ProxMenux freigeben. Installiert nfs-kernel-server automatisch, richtet die gemeinsame Gruppe sharedfiles und /etc/exports ein und bietet Netzwerk-ACLs sowie vollständige Deinstallation. Erfordert einen privilegierten Container.",
|
||||
"ogTitle": "NFS Server in LXC | ProxMenux Dokumentation",
|
||||
"ogDescription": "Führen Sie einen NFS-Server in einem privilegierten LXC-Container aus. Universelle Sharedfiles-Gruppe, Netzwerk-ACL und vollständige Deinstallation."
|
||||
},
|
||||
"header": {
|
||||
"title": "NFS Server in LXC",
|
||||
"description": "Betreiben Sie einen NFS-Kernel-Server in einem Proxmox-LXC-Container und geben Sie Ordner für andere Rechner im Netzwerk frei. ProxMenux installiert nfs-kernel-server, richtet die gemeinsame Gruppe sharedfiles ein, damit mehrere privilegierte CTs Dateien gemeinsam nutzen können, verwaltet /etc/exports und bietet eine vollständige Deinstallation.",
|
||||
"section": "Speicher und Freigaben · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privilegierter Container erforderlich",
|
||||
"body": "<code>nfs-kernel-server</code> muss das Kernel-Dateisystem <code>nfsd</code> unter <code>/proc/fs/nfsd</code> einhängen. Dafür benötigt es <code>CAP_SYS_ADMIN</code> im Namensraum des Host-Kernels, nicht nur im Benutzer-Namensraum des Containers. Unprivilegierte LXC-Container besitzen diese Fähigkeit nicht: <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code>; systemd markiert <code>nfs-server.service</code> mit einem Abhängigkeitsfehler. Das Skript verlangt daher einen privilegierten CT und <strong>bricht bei unprivilegierten CTs ab</strong>. Alternativ kann der NFS-Server in einer VM laufen."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Was das macht",
|
||||
"body": "Dies ist die umgekehrte Richtung zur <em>NFS-Client-Seite</em>: Der CT wird zum <strong>NFS-Server</strong> und stellt einen eigenen Ordner anderen CTs, dem Proxmox-Host, VMs oder physischen Rechnern bereit.",
|
||||
"diagramServerLabel": "LXC (privilegiert) — NFS-Server",
|
||||
"diagramServerDetail": "/mnt/data\n(freigegebener Ordner)\n\nchown root:sharedfiles\nchmod 2775 (SGID)\n\nnfs-kernel-server\n+ rpcbind läuft",
|
||||
"diagramClientLabel": "Jeder Client im Netzwerk",
|
||||
"diagramClientDetail": "einem anderen CT, dem Host,\nVM, eine physische Maschine...",
|
||||
"diagramArrow": "NFS-Export"
|
||||
},
|
||||
"shared": {
|
||||
"heading": "Die \"sharedfiles\" Gruppenkonvention",
|
||||
"body": "Vor dem Exportieren des Ordners erstellt ProxMenux eine Gruppe namens <code>sharedfiles</code> mit <strong>GID 101000</strong> im Container, fügt jeden regulären Benutzer hinzu und setzt dann das Exportverzeichnis mit dem Modus <code>2775</code> auf <code>root:sharedfiles</code>. Das <code>2</code> an der Vorderseite ist das SGID-Bit - jede Datei oder jeder Ordner, der im Inneren erstellt wird, erbt automatisch die <code>sharedfiles</code>-Gruppe.",
|
||||
"gidTitle": "Warum GID 101000 speziell",
|
||||
"gidBody": "Mit der standardmäßigen LXC-ID-Zuordnung (+100000) erscheint Host-GID 101000 als GID <strong>1000</strong> in einem unprivilegierten CT. Dieser Serverablauf verwendet einen <strong>privilegierten</strong> CT ohne Verschiebung. Zwei privilegierte CTs mit <code>sharedfiles</code> bei GID 101000 verwenden daher dieselbe numerische Gruppen-ID.",
|
||||
"remapTitle": "Die alte Erstellung von „remap_*“-Benutzern wird bei privilegierten CTs übersprungen",
|
||||
"remapBody": "Der alte Zweig für unprivilegierte CTs würde <code>remap_<uid></code>-Benutzer mit UID <code><uid> + 100000</code> in <code>sharedfiles</code> für normale Benutzer und übliche UIDs (33, 1000, 1001, 1002) anlegen. Diese <code>+100000</code>-Verschiebung gilt nicht für die hier vorgeschriebenen <strong>privilegierten</strong> CTs; deshalb überspringt das Skript diesen Zweig. Fehlende <code>remap_*</code>-Konten in <code>getent passwd</code> sind zu erwarten und kein Fehler."
|
||||
},
|
||||
"defaults": {
|
||||
"heading": "Standard-Exportoptionen - lesen Sie dies zuerst",
|
||||
"warnTitle": "Standardoptionen umfassen no_root_squash",
|
||||
"warnBody": "ProxMenux verwendet standardmäßig <code>rw,sync,no_subtree_check,'<'strong'>'no_root_squash'<'/strong'>'</code>. <strong>Jeder Client-Benutzer root kann auf dem Export als root schreiben.</strong> Verwenden Sie dies nur in einem vertrauenswürdigen Heimnetz. Ist der CT aus einem nicht vertrauenswürdigen Netzwerk erreichbar (VPS oder fremdes VLAN), <strong>ersetzen Sie die Exportoption im Dialog für eigene Optionen durch <code>root_squash</code></strong>."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → NFS-Server in LXC (nur privilegiert)</strong> konfigurieren. ProxMenux fordert Sie zuerst auf, das Ziel CT auszuwählen (und startet es, wenn es gestoppt wird); abbricht, wenn es nicht privilegiert ist. Sobald das CT ausgewählt ist, sehen Sie dieses sub-Menü mit fünf Optionen:",
|
||||
"imageAlt": "NFS Server-Manager-Menü – Erstellen / Ansicht / Löschen / Status / Deinstallieren"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft (Create flow)"
|
||||
},
|
||||
"network": {
|
||||
"heading": "Netzwerk-ACL — wer darf einhängen?",
|
||||
"intro": "<code>/etc/exports</code> filtert, welche Clients den Export einhängen dürfen. Der Dialog bietet drei Möglichkeiten:",
|
||||
"headerMode": "Modus",
|
||||
"headerValue": "Wert geschrieben an /etc/exports",
|
||||
"headerWhen": "Wann man es wählt",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Lokales Netz",
|
||||
"value": "192.168.0.0/16",
|
||||
"whenRich": "Für übliche Heim- und SOHO-Netzwerke. Deckt alle Adressen unter <code>192.168.*.*</code> ab."
|
||||
},
|
||||
{
|
||||
"mode": "Eigenes Subnetz",
|
||||
"value": "Ein beliebiges CIDR-Subnetz (z. B. 10.0.0.0/24)",
|
||||
"when": "Wenn sich Ihr LAN nicht in 192.168.x.x befindet oder Sie einen engeren Umfang wünschen."
|
||||
},
|
||||
{
|
||||
"mode": "Einzelner Host",
|
||||
"value": "Die IP-Adresse eines einzelnen Clients (z. B. 192.168.1.50)",
|
||||
"when": "Nur eine bestimmte Maschine sollte montieren. Am restriktivsten."
|
||||
}
|
||||
]
|
||||
},
|
||||
"options": {
|
||||
"heading": "Exportoptionen",
|
||||
"headerOption": "Option",
|
||||
"headerEffect": "Was es tut",
|
||||
"rows": [
|
||||
{
|
||||
"option": "rw / ro",
|
||||
"effect": "Ermöglichen Sie Lese-Schreib- oder Lesezugriff für Verbindungsclients."
|
||||
},
|
||||
{
|
||||
"option": "sync",
|
||||
"effectRich": "Bestätigt Schreibanforderungen erst, wenn die Daten auf dem Datenträger liegen. Sicherer als <code>async</code>, aber mit geringerem Durchsatz."
|
||||
},
|
||||
{
|
||||
"option": "no_subtree_check",
|
||||
"effect": "Überspringt die Prüfung bei jeder Anfrage, ob die Datei noch im exportierten Teilbaum liegt. Das ist schneller und vermeidet Probleme, wenn Dateien während des Zugriffs umbenannt werden."
|
||||
},
|
||||
{
|
||||
"option": "no_root_squash",
|
||||
"effectRich": "<strong>Root auf dem Client vertrauen.</strong> Ein als root zugreifender Client schreibt auf dem Server als root. Geeignet für vertrauenswürdige LANs, etwa wenn Sicherungswerkzeuge die Eigentümer erhalten müssen. Ersetzen Sie dies durch <code>root_squash</code>, wenn Sie nicht jedem Rechner in der Netzwerk-ACL vollständig vertrauen."
|
||||
}
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Führen Sie den gesamten Ablauf von Hand aus. Jeder Befehl läuft <strong>innerhalb des CTs</strong> über <code>pct exec <ctid> --</code> oder <code>pct enter <ctid></code>:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Aktuelle Exporte ansehen",
|
||||
"body": "Zeigt <code>/etc/exports</code> aus dem CT ohne Kommentare und Leerzeilen an. Jeder Export wird mit Netzwerk-ACL und Optionen ausgegeben. Damit lässt sich vor der Weitergabe der CT-IP prüfen, welche Ordner freigegeben sind."
|
||||
},
|
||||
"delete": {
|
||||
"heading": "Einen Export löschen",
|
||||
"body": "Listet jede Zeile in <code>/etc/exports</code> zur Auswahl auf, entfernt die ausgewählte (<code>sed -i</code>), führt <code>exportfs -ra</code> aus und startet <code>nfs-kernel-server</code> neu. Der Ordner selbst und sein Inhalt bleiben intakt."
|
||||
},
|
||||
"status": {
|
||||
"heading": "NFS-Status überprüfen",
|
||||
"body": "Diagnosepass: bestätigt, dass <code>nfs-kernel-server</code> und <code>rpcbind</code> installiert und aktiv sind, druckt <code>exportfs -v</code>-Ausgabe, listet aktive NFS-Sitzungen (<code>showmount -a</code>) und aktuelle Clientverbindungen auf."
|
||||
},
|
||||
"uninstall": {
|
||||
"heading": "NFS-Server deinstallieren",
|
||||
"body": "Vollständige Bereinigung nach Bestätigung: stoppt und deaktiviert <code>nfs-kernel-server</code> und <code>rpcbind</code>, leert <code>/etc/exports</code>, entfernt die NFS-Pakete mit <code>apt-get purge</code>, löscht die Gruppe <code>sharedfiles</code> und die Benutzer <code>remap_*</code> und beendet verbleibende Prozesse. Die <strong>exportierten Ordner selbst bleiben erhalten</strong>; entfernt werden nur NFS-Konfiguration und Pakete.",
|
||||
"warnTitle": "Das Skript stoppt an der Exportlinie, nicht an den Daten",
|
||||
"warnBody": "Sowohl <em>Export löschen</em> als auch <em>NFS-Server deinstallieren</em> entfernen die Exportkonfiguration. Die Daten im freigegebenen Ordner bleiben erhalten. Löschen Sie Daten bei Bedarf nach Abschluss des Skripts ausdrücklich mit <code>rm -rf</code>; sichern Sie sie vorher, falls jemand sie noch benötigen könnte."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"privTitle": "Privilegierter Container erforderlich (Skript bricht ab)",
|
||||
"privBody": "Der ausgewählte CT ist unprivilegiert. <code>nfs-kernel-server</code> kann dort nicht starten, da die Einhängen von <code>/proc/fs/nfsd</code> <code>CAP_SYS_ADMIN</code> im Host-Kernel-Namespace benötigt und das <code>nfsd</code>-Modul auch nicht dem Namespace des Containers ausgesetzt ist (<code>modprobe nfsd</code> von innen gibt <code>FATAL: Module nfsd not found</code>). Wenn Sie das Gate umgehen, sehen Sie <code>rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or directory)</code> im Journal und keine NFS-Ports werden jemals geöffnet. Die einzigen praktikablen Optionen sind: Wandeln Sie den CT in einen privilegierten CT um oder verschieben Sie den NFS-Server in eine VM.",
|
||||
"aptTitle": "apt-get install schlägt fehl",
|
||||
"aptIntro": "Das Skript nimmt eine Debian-Familie CT an. Auf Alpine / Arch / Rocky / Alma installieren Sie die NFS-Serverpakete von Hand:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add nfs-utils</code>",
|
||||
"Arch: <code>pacman -S nfs-utils</code>",
|
||||
"Rocky / Alma: <code>dnf install nfs-utils</code>"
|
||||
],
|
||||
"aptOutro": "Führen Sie danach das ProxMenux-Skript erneut aus; sind die Werkzeuge schon vorhanden, wird die Installation übersprungen.",
|
||||
"aclTitle": "Client kann nicht mounten: \"Zugriff verweigert durch Server\"",
|
||||
"aclBody": "Die Client-IP liegt außerhalb der konfigurierten Netzwerk-ACL. Erstellen Sie den Export mit einem größeren Subnetz neu oder fügen Sie die genaue Client-IP hinzu. Häufige Ursache: Hinter Router-NAT kann der Client mit der WAN-IP des Routers statt seiner LAN-IP erscheinen. Prüfen Sie dies auf dem Server mit <code>tcpdump -n port 2049</code>.",
|
||||
"ownTitle": "Vom Client geschriebene Dateien erscheinen mit seltsamem Besitz auf dem Server",
|
||||
"ownIntro": "Zwei Möglichkeiten:",
|
||||
"ownItems": [
|
||||
"Mit <code>no_root_squash</code> (Standard) schreibt Client root als root auf den Server. Dateien gehören <code>root:sharedfiles</code> dank der SGID im Ordner.",
|
||||
"Nicht-Root-Client-Benutzer schreiben als ihre eigene UID / GID. Wenn ihre UID nicht auf dem Server existiert, erscheinen Dateien mit Rohnummern (z.B. <code>1234:1234</code>). Verwenden Sie die <code>sharedfiles</code>-Gruppe auch auf dem Client oder richten Sie UIDs auf den Systemen aus, die Dateien gemeinsam nutzen."
|
||||
],
|
||||
"noShowTitle": "Server erreichbar, aber showmount gibt nichts zurück",
|
||||
"noShowBody": "Nach dem Bearbeiten von <code>/etc/exports</code> müssen Sie die Exporttabelle mit <code>exportfs -ra</code> neu laden und <code>nfs-kernel-server</code> neu starten – das Skript macht beides, aber wenn Sie die Datei von Hand bearbeitet haben, tun Sie es selbst. Bestätigen Sie auch, dass die Firewall auf dem CT (und auf dem Proxmox-Host) TCP/UDP 2049 und den rpcbind-Port (111) ermöglicht."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "NFS-Client in LXC",
|
||||
"tail": " — umgekehrte Richtung: externe NFS-Freigaben im CT einhängen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"label": "Samba-Server in LXC",
|
||||
"tail": "— Geschwisterseite, gleiches Muster mit SMB / CIFS anstelle von NFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-nfs",
|
||||
"label": "NFS-Freigabe als Proxmox-Speicher",
|
||||
"tailRich": " — Sobald der CT Ordner über NFS freigibt, registrieren Sie die NFS-Freigabe in Proxmox, damit sie unter <em>Datacenter → Storage</em> erscheint."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,155 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Samba-Client in LXC | ProxMenux Dokumentation",
|
||||
"description": "Samba-/CIFS-Freigaben direkt in einem Proxmox-LXC-Container mit ProxMenux einhängen. Installiert cifs-utils und smbclient automatisch, unterstützt Erkennung im Netzwerk, geschützte Zugangsdaten und dauerhafte Mounts über /etc/fstab. Erfordert einen privilegierten Container.",
|
||||
"ogTitle": "Samba-Client in LXC | ProxMenux Dokumentation",
|
||||
"ogDescription": "Samba-/CIFS-Freigaben in einem privilegierten LXC einhängen. Automatische Erkennung, geschützte Zugangsdaten-Datei und dauerhafte Einträge in /etc/fstab."
|
||||
},
|
||||
"header": {
|
||||
"title": "Samba-Client in LXC",
|
||||
"description": "Samba-Freigaben (SMB/CIFS) direkt in einem Proxmox-LXC-Container einhängen. Der Container wird zu einem echten CIFS-Client - spricht mit dem Samba-Server über das Netzwerk, führt mount.cifs aus, speichert Anmeldeinformationen sicher und schreibt an /etc/fstab. ProxMenux installiert cifs-utils + smbclient für Sie und validiert Anmeldeinformationen gegen den Server vor der Montage.",
|
||||
"section": "Speicher und Freigaben · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privilegierter Container erforderlich",
|
||||
"body": "Der Kernel-<code>mount.cifs</code>-Client benötigt Funktionen (mindestens <code>SYS_ADMIN</code>), die nicht privilegierte LXC-Container nicht bereitstellen. Das Skript erzwingt dies - es fordert Sie auf, einen CT auszuwählen, und <strong>bricht bei unprivilegierten CTs ab</strong>. Wenn Sie die Freigabe in einem unprivilegierten CT benötigen, montieren Sie sie zuerst auf dem Proxmox-Host (mit <hostSambaLink>Samba / CIFS-Freigabe als Proxmox-Speicher</hostSambaLink>) und binden Sie sie mit dem <mountLink>LXC-Mount-Manager</mountLink> in den CT ein."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Was das macht",
|
||||
"body": "Der Container spricht CIFS über das Netzwerk und montiert die Freigabe selbstständig. Der Proxmox-Host ist nur die Netzwerkbrücke - er sieht oder verwaltet das Mount nicht.",
|
||||
"diagramServerLabel": "Samba-Server",
|
||||
"diagramServerDetail": "//srv/share",
|
||||
"diagramHostLabel": "Proxmox-Host",
|
||||
"diagramHostDetail": "(nur eine\nNetzwerkbrücke)",
|
||||
"diagramCtLabel": "LXC (privilegiert)",
|
||||
"diagramCtDetail": "/mnt/share\nmount.cifs im CT",
|
||||
"diagramArrow": "CIFS",
|
||||
"twoWaysTitle": "Zwei Möglichkeiten, einem CT einen Samba-Anteil zu geben - wählen Sie einen",
|
||||
"twoWaysBind": "<strong>Bind-Mount über den Host</strong> (<mountLink>LXC Mount Manager</mountLink>): Der Host bindet die CIFS-Freigabe einmal ein; jeder CT erhält denselben Pfad als Bind-Mount. Funktioniert mit unprivilegierten CTs und empfiehlt sich, wenn mehrere CTs dieselbe Freigabe benötigen.",
|
||||
"twoWaysDirect": "<strong>Direkte CIFS-Montage im CT</strong> (diese Seite): Der CT montiert das CIFS selbst. Erfordert Privilegien. Nützlich, wenn der CT seine eigenen Anmeldeinformationen besitzen muss oder wenn jeder CT mit einem anderen Server spricht."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → Samba-Client in LXC (nur privilegiert)</strong> konfigurieren. ProxMenux fordert Sie zuerst auf, <strong> das Ziel CT</strong> auszuwählen (und startet es, wenn es gestoppt wird); abbricht, wenn es nicht privilegiert ist. Sobald das CT ausgewählt ist, sehen Sie dieses sub-Menü:",
|
||||
"imageAlt": "Menü Samba Client Manager — Mount / View / Unmount / Test Connectivity"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Wie das Skript läuft (Mount Flow)"
|
||||
},
|
||||
"creds": {
|
||||
"heading": "Wo sich das Passwort befindet",
|
||||
"body": "ProxMenux <strong>schreibt das Passwort nicht in den Mount-Befehl</strong> oder in <code>/etc/fstab</code>. Stattdessen wird eine Zugangsdaten-Datei im CT angelegt. Sie enthält Klartext-Zugangsdaten mit Nur-Root-Berechtigungen und ist nicht verschlüsselt:",
|
||||
"whyTitle": "Warum eine separate Datei statt fstab",
|
||||
"whyBody": "Das CIFS-Modul akzeptiert <code>username=</code> / <code>password=</code> Optionen inline in fstab, aber jeder, der <code>/etc/fstab</code> lesen kann, sieht das Passwort klar. Wenn Sie Anmeldeinformationen in eine Root-only-Datei einfügen und darauf zeigen (<code>credentials=</code>), wird das Passwort aus der weltlesbaren Konfiguration ausgeschlossen."
|
||||
},
|
||||
"options": {
|
||||
"heading": "Mount Optionen erklärt",
|
||||
"headerOption": "Option",
|
||||
"headerEffect": "Was es tut",
|
||||
"rows": [
|
||||
{
|
||||
"option": "rw / ro",
|
||||
"effect": "Read-Write- oder Read-Only-Modus für das gesamte Mount."
|
||||
},
|
||||
{
|
||||
"option": "file_mode=0664",
|
||||
"effect": "Berechtigungen für Dateien gemeldet über CIFS. Default lässt owner+group schreiben, andere lesen."
|
||||
},
|
||||
{
|
||||
"option": "dir_mode=0775",
|
||||
"effect": "Gemeldete Verzeichnisrechte. Standardmäßig dürfen Eigentümer und Gruppe das Verzeichnis betreten und Inhalte erstellen; andere dürfen es durchqueren."
|
||||
},
|
||||
{
|
||||
"option": "iocharset=utf8",
|
||||
"effect": "Erzwingen Sie UTF-8 für Dateinamen, die über den Draht kommen. Vermeidet Mojibake auf Nicht-ASCII-Namen."
|
||||
},
|
||||
{
|
||||
"option": "credentials=file",
|
||||
"effect": "Lesen Sie Benutzername / Passwort aus der Datei (automatisch für Benutzer auth hinzugefügt)."
|
||||
},
|
||||
{
|
||||
"option": "guest",
|
||||
"effect": "Authentifizierung als Gast, keine Anmeldeinformationen erforderlich (automatisch hinzugefügt, wenn der Gast ausgewählt wird)."
|
||||
},
|
||||
{
|
||||
"option": "_netdev",
|
||||
"effect": "Sagt dem init-system, dass dieses mount das netzwerk benötigt. Boot blockiert nicht das Warten darauf."
|
||||
},
|
||||
{
|
||||
"option": "x-systemd.automount",
|
||||
"effect": "Lazy Mount: nur Mounts beim ersten Zugriff. CIFS-Server, der beim Booten nicht erreichbar ist, stoppt den CT nicht."
|
||||
},
|
||||
{
|
||||
"option": "noauto",
|
||||
"effect": "Überspringt das sofortige Einhängen beim Booten. Die Automount-Einheit richtet den Mount erst beim ersten Zugriff ein."
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Nettoeffekt der Fstab Flags",
|
||||
"netEffectBody": "Das CIFS-Dateisystem wird beim <em>ersten Zugriff</em> eingehängt statt sofort beim Booten. Ist der Server offline, kann dieser Zugriff warten oder fehlschlagen; davon abhängige Dienste können betroffen sein. Automount verringert die Abhängigkeit beim Booten, garantiert aber nicht, dass alle CT-Dienste von einem CIFS-Ausfall unberührt bleiben."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Replizieren Sie den gesamten Ablauf per Hand – jeder Befehl führt <strong> im CT</strong> über <code>pct exec <ctid> --</code> oder direkt über <code>pct enter <ctid></code> aus:",
|
||||
"guestIntro": "Gastvariante — keine Anmeldedatendatei erforderlich:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "Aktuelle Mounts anzeigen",
|
||||
"body": "Listet jeden CIFS-Einhängepunkt auf, der innerhalb des CT (<code>mount -t cifs</code>) aktiv ist, sowie jede CIFS-Linie im <code>/etc/fstab</code> des CT. Für jeden fstab-eintrag wird der live-mount-status angezeigt - nützlich, um permanente mounts zu erkennen, die beim boot nicht aufgekommen sind."
|
||||
},
|
||||
"unmount": {
|
||||
"heading": "Samba-Freigabe aushängen",
|
||||
"body": "Fasst aktive Mounts und fstab-Einträge in einer Auswahlliste zusammen. Für den gewählten Eintrag <strong>wird die entsprechende Zeile aus <code>/etc/fstab</code> entfernt</strong>, zusammen mit der zugehörigen Datei mit Zugangsdaten. Das Skript führt kein <code>umount</code> auf dem aktiven Mount aus, sondern weist darauf hin, dass zum Aushängen ein CT-Neustart nötig ist.",
|
||||
"warnTitle": "Das Skript entfernt fstab-Einträge, nicht Live-Mounts",
|
||||
"warnBody": "Gleiches Design wie der NFS-Client: <code>umount</code> auf einem belegten Mount schlägt mit \"Device Besetzt\" fehl. Das Entfernen des Fstab-Eingangs garantiert, dass die Mount beim nächsten CT-Start sauber verschwindet. Wenn Sie möchten, dass die Mount <em>sofort</em> verschwunden ist, führen Sie <code>pct exec <ctid> -- umount /mnt/<path></code> nach Abschluss des Skripts von Hand aus."
|
||||
},
|
||||
"test": {
|
||||
"heading": "Samba Konnektivität testen",
|
||||
"body": "Diagnose im CT: Prüft, ob <code>cifs-utils</code> installiert ist, listet aktive CIFS-Mounts auf und prüft für jeden in fstab eingetragenen Server Ping → Ports 139/445 → Freigabenliste als Gast. „Authentifizierung erforderlich“ beim Gasttest ist normal, wenn der Server keine öffentlichen Freigaben anbietet."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"privTitle": "Privilegierter Container erforderlich (Skript bricht ab)",
|
||||
"privBody": "Der ausgewählte CT ist unprivilegiert. Der Kernel-CIFS-Client benötigt <code>SYS_ADMIN</code>-Fähigkeit, die nicht privilegierte CTs nicht aussetzen. Konvertieren Sie entweder den CT in privilegierte oder verwenden Sie den alternativen Pfad, der in der Warnung oben auf dieser Seite beschrieben ist.",
|
||||
"aptTitle": "apt-get install fails",
|
||||
"aptIntro": "Das Skript nimmt eine Debian-Familie CT (<code>apt-get</code>) an. Auf Alpine / Arch / Rocky / Alma installieren Sie den CIFS-Client von Hand:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add cifs-utils samba-client</code>",
|
||||
"Arch: <code>pacman -S cifs-utils smbclient</code>",
|
||||
"Rocky / Alma: <code>dnf install cifs-utils samba-client</code>"
|
||||
],
|
||||
"aptOutro": "Führen Sie dann das ProxMenux-Skript erneut aus - der Installationsschritt überspringt, wenn die Tools bereits vorhanden sind.",
|
||||
"guestFallbackTitle": "\"Der Server hat Sie als Gast anstelle des angegebenen Benutzers verbunden\"",
|
||||
"guestFallbackBody": "Die aktive Validierung des Skripts hat ein echtes Auth-Problem aufgefangen. Der server akzeptierte die verbindung, degradierte sie jedoch auf gast, weil die anmeldeinformationen falsch sind. Häufige Ursachen: Tippfehler im Benutzernamen oder Passwort, der Benutzer existiert nicht auf dem Server, der Benutzer ist ausgesperrt oder die Arbeitsgruppe / Domäne ist nicht übereinstimmend. Führen Sie den Ablauf erneut aus und geben Sie die Anmeldeinformationen sorgfältig erneut ein (das Passwort ist im Dialog verborgen).",
|
||||
"denyTitle": "\"NT_STATUS_ACCESS_DENIED\" bei der Montage",
|
||||
"denyBody": "Anmeldeinformationen wurden validiert, aber die Freigabe verweigert den Zugang. Überprüfen Sie auf der Serverseite, ob der Benutzer über Berechtigungen für diese bestimmte Freigabe verfügt (die Validierung bestätigt nur die Anmeldung, nicht per-share-ACLs). Überprüfen Sie auch, ob der Server eine bestimmte SMB-Protokollversion benötigt: Fügen Sie <code>vers=3.0</code> (oder <code>2.1</code>, <code>2.0</code>) an die Mount-Optionen an.",
|
||||
"utf8Title": "UTF-8 / Nicht-ASCII-Dateinamen sind verstümmelt",
|
||||
"utf8Body": "Die Standardoptionen umfassen <code>iocharset=utf8</code>, aber einige Serverkonfigurationen melden eine unerwartete Codepage. Wenn Dateinamen mit Akzenten / Symbolen falsch aussehen, versuchen Sie auch <code>nounix</code> (einige Linux-Samba-Server benötigen dies, wenn der Client auch Linux ist) oder setzen Sie die Serverseite auf <code>unix extensions = no</code>.",
|
||||
"bootTitle": "Permanent Mount gelingt, kommt aber nicht beim Booten",
|
||||
"bootBody": "Fast immer eines von: das Netzwerk ist nicht bereit, wenn die CT-Mounts (die <code>_netdev,x-systemd.automount,noauto</code>-Flags des Skripts beheben dies), der Server ist beim Booten nicht erreichbar (Auto-Mount wartet auf den ersten Zugriff - das ist normal), oder DNS ist beim Booten ungelöst (verwenden Sie die IP des Servers, nicht seinen Hostnamen)."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-mount-points",
|
||||
"label": "LXC-Einhängepunkte (Host ↔ Container)",
|
||||
"tail": "— die Alternative für unprivilegierte CTs: mount on host, bind in CT."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-client",
|
||||
"label": "NFS-Client in LXC",
|
||||
"tail": " — verwandte Seite mit demselben Ablauf für NFS-Freigaben."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-server",
|
||||
"label": "Samba-Server in LXC",
|
||||
"tailRich": " — die umgekehrte Richtung: Ordner <em>aus</em> einem CT über Samba freigeben."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS als Proxmox-Speicher",
|
||||
"tail": " — die Freigabe direkt in Proxmox statt in einem einzelnen CT registrieren."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Samba-Server in LXC | ProxMenux Dokumentation",
|
||||
"description": "Mit ProxMenux einen Samba-Server (SMB / CIFS) in einem Proxmox-LXC-Container betreiben. Installiert samba automatisch und verwaltet /etc/samba/smb.conf, smbpasswd-Benutzer und die Gruppe sharedfiles für per Bind-Mount eingebundene Ordner. Erfordert einen privilegierten Container.",
|
||||
"ogTitle": "Samba-Server in LXC | ProxMenux Dokumentation",
|
||||
"ogDescription": "Ordner über SMB/CIFS aus einem privilegierten LXC-Container freigeben. Automatische Installation, smbpasswd-Benutzer und an Bind-Mounts angepasste Berechtigungen."
|
||||
},
|
||||
"header": {
|
||||
"title": "Samba-Server in LXC",
|
||||
"description": "Führen Sie einen Samba-Server (SMB / CIFS) in einem Proxmox LXC-Container aus und stellen Sie Ordner Windows / macOS / Linux-Clients im Netzwerk aus. ProxMenux installiert samba, erstellt einen Samba-Benutzer mit smbpasswd, verwaltet /etc/samba/smb.conf und wendet bind-mount-bewusste Berechtigungen an, wenn der freigegebene Ordner vom Host stammt.",
|
||||
"section": "Speicher und Freigaben · LXC"
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privilegierter Container erforderlich",
|
||||
"body": "Samba nimmt die Identität des verbindenden Benutzers an mit <code>setgroups()</code> auf jeder Baumverbindung (der Moment, in dem ein Client eine Freigabe öffnet). In einem unprivilegierten LXC lehnt der Kernel diesen Syscall ab, weil der Namespace des Containers mit <code>setgroups=deny</code> erstellt wird – und <code>smbd</code> reagiert, indem er den Worker-Prozess mit <code>PANIC: sys_setgroups failed</code> abbricht. Das Ergebnis ist, dass <code>smbd</code> die Ports 139/445 startet und bindet, aber jede Clientverbindung mit <code>NT_STATUS_CONNECTION_DISCONNECTED</code> fehlschlägt. Das Skript erzwingt aus diesem Grund einen privilegierten CT und <strong>bricht bei unprivilegierten CTs ab</strong>. Es gibt keine saubere Lösung auf der Serverseite; Verwenden Sie einen privilegierten CT oder führen Sie Samba in einer VM aus."
|
||||
},
|
||||
"what": {
|
||||
"heading": "Was das macht",
|
||||
"body": "Der Container wird zu einem SMB/CIFS-Server: Er führt <code>smbd</code> aus, stellt einen Ordner über <code>/etc/samba/smb.conf</code> frei und akzeptiert Clientverbindungen an den Ports <code>139</code> / <code>445</code>. Clients sehen die Freigabe unter <code>\\\\<ct-ip>\\<share-name></code> im Windows Explorer, <code>smb://<ct-ip>/<share-name></code> im macOS Finder oder über <code>mount.cifs</code> unter Linux.",
|
||||
"diagramServerLabel": "LXC (privilegiert) — Samba-Server",
|
||||
"diagramServerDetail": "/mnt/data\n(freigegebener Ordner)\n\nsmbd + nmbd laufen\n\nBenutzer: <username>\n(via smbpasswd)\n\nErzwungene Gruppe:\nsharedfiles",
|
||||
"diagramClientLabel": "Jeder Client im Netzwerk",
|
||||
"diagramClientDetail": "Windows: \\\\<ip>\\<share>\nmacOS: smb://<ip>/<share>\nLinux: mount.cifs",
|
||||
"diagramArrow": "SMB / CIFS"
|
||||
},
|
||||
"perms": {
|
||||
"heading": "Zwei Berechtigungspfade abhängig vom Ordnertyp",
|
||||
"body": "Vor dem Hinzufügen der Freigabe zu <code>smb.conf</code> prüft das Skript, ob der Ordner ein <strong>Bind-Mount vom Host</strong> oder ein normaler <strong>lokaler Ordner im CT</strong> ist. Entsprechend setzt es Eigentümer und Berechtigungen:",
|
||||
"headerType": "Art des Ordners",
|
||||
"headerAction": "Was das Skript macht",
|
||||
"bindType": "Bind-Mount vom Host",
|
||||
"bindTypeSubRich": "erfasst über <code>mount</code> Ausgang",
|
||||
"bindActionRich": "Erstellt Gruppe <code>sharedfiles</code> (Standard GID 999, dynamisch, wenn genommen), fügt den Samba-Benutzer hinzu, dann <code>chown root:sharedfiles</code> + <code>chmod 2775</code> (SGID - neue Dateien erben die Gruppe). Wenn der Benutzer immer noch nicht schreiben kann, wendet <code>setfacl -m u:<user>:rwx</code> an.",
|
||||
"localType": "Lokaler Ordner im CT",
|
||||
"localTypeSub": "Kein Bind-Mount erkannt",
|
||||
"localActionRich": "Standardbesitz: <code>chown -R <user>:<user></code> + <code>chmod -R 755</code>. Keine freigegebene Gruppe erforderlich, da kein anderer CT in diesen Ordner schreibt. Fällt zurück zu <code>setfacl</code>, wenn der Schreibzugriff noch fehlt.",
|
||||
"gidTitle": "GID für 'sharedfiles' unterscheidet sich vom NFS Server Flow",
|
||||
"gidBody": "Das Samba-Serverskript verwendet GID <strong>999</strong> für <code>sharedfiles</code>, während der <nfsLink>NFS-Serverablauf</nfsLink> GID <strong>101000</strong> verwendet. Wenn Sie beide Server in demselben CT betreiben und eine einzelne gemeinsame Gruppe für beide Protokolle wünschen, bearbeiten Sie eines von ihnen nach der Installation so, dass es mit dem anderen übereinstimmt (z.B. <code>groupmod -g 101000 sharedfiles</code>) und setzen Sie die Eigentümer der betroffenen Ordner erneut. Dies ist eine bekannte Inkonsistenz in den aktuellen Skripten."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Öffnen des Tools",
|
||||
"body": "Öffnen Sie im Hauptmenü von ProxMenux <strong>Storage & Share Manager → Samba-Server in LXC (nur privilegiert)</strong> konfigurieren. ProxMenux fordert Sie zuerst auf, das Ziel CT auszuwählen (und startet es, wenn es gestoppt wird); abbricht, wenn es nicht privilegiert ist. Sobald das CT ausgewählt ist, sehen Sie dieses sub-Menü mit fünf Optionen:",
|
||||
"imageAlt": "Samba Server Manager-Menü - Erstellen / Anzeigen / Löschen / Status / Deinstallieren"
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "Ablauf des Skripts beim Erstellen"
|
||||
},
|
||||
"modes": {
|
||||
"heading": "Die drei Share-Modi",
|
||||
"intro": "Jeder Modus schreibt einen anderen Konfigurationsabschnitt in <code>smb.conf</code>. Alle drei beinhalten <code>valid users = <username></code> (nicht anonym), <code>force group = sharedfiles</code> (damit neue Dateien zur freigegebenen Gruppe gehören) und <code>veto files = /lost+found/</code> (versteckt sie vor Clients).",
|
||||
"headerMode": "Modus",
|
||||
"headerBlock": "Block geschrieben an smb.conf",
|
||||
"rwMode": "Lesen und Schreiben",
|
||||
"roMode": "Schreibgeschützt",
|
||||
"customMode": "Benutzerdefiniert",
|
||||
"customBodyRich": "Sie geben Ihre eigenen Direktiven in ein Freitextfeld ein. ProxMenux wickelt sie weiterhin in einen <code>[share]</code>-Block mit den Standards <code>path</code>, <code>valid users</code>, <code>force group</code> und <code>veto files</code> ein."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manuelles Äquivalent",
|
||||
"body": "Führen Sie den gesamten Ablauf von Hand aus. Jeder Befehl läuft <strong>innerhalb des CTs</strong> über <code>pct exec <ctid> --</code> oder <code>pct enter <ctid></code>:"
|
||||
},
|
||||
"connect": {
|
||||
"heading": "Verbindung von Clients",
|
||||
"headerOs": "Client-Betriebssystem",
|
||||
"headerHow": "Wie man verbindet",
|
||||
"windowsOs": "Windows",
|
||||
"windowsHowRich": "Datei-Explorer → Adressleiste: <code>\\\\<ct-ip>\\<share-name></code>. Oder <em>Netzlaufwerk verbinden</em> → „Verbindung mit anderen Anmeldeinformationen herstellen“ aktivieren.",
|
||||
"macosOs": "macOS",
|
||||
"macosHowRich": "Finder → <em>Gehe zu → Verbindung zum Server...</em> → <code>smb://<ct-ip>/<share-name></code>. Oder <code>mount_smbfs //user@<ct-ip>/<share> /mountpoint</code>.",
|
||||
"linuxOs": "Linux",
|
||||
"linuxHowRich": "<code>mount -t cifs //<ct-ip>/<share> /mnt/x -o username=<u>,password=<p>,iocharset=utf8</code>. Oder verwenden Sie den <clientLink>Samba-Client auf der LXC</clientLink>-Seite, wenn der Client ein anderer Proxmox CT ist."
|
||||
},
|
||||
"view": {
|
||||
"heading": "Aktuelle Freigaben anzeigen",
|
||||
"body": "Liest <code>/etc/samba/smb.conf</code> im CT und listet jeden <code>[share]</code>-Block (überspringen <code>[global]</code>, <code>[homes]</code>, <code>[printers]</code>) mit seinem Pfad auf. Nützlich als schnelles Inventar."
|
||||
},
|
||||
"delete": {
|
||||
"heading": "Freigabe löschen",
|
||||
"body": "Sie können eine Freigabe nach Namen auswählen, den Block aus <code>smb.conf</code> entfernen (<code>sed</code> löscht aus <code>[share]</code> bis zur nächsten leeren Zeile) und <code>smbd</code> neu starten. Der Ordner selbst und sein Inhalt bleiben intakt."
|
||||
},
|
||||
"status": {
|
||||
"heading": "Samba-Status überprüfen",
|
||||
"body": "Gibt an, ob <code>smbd</code> und <code>nmbd</code> installiert und aktiv sind, listet Samba-Benutzer auf (<code>pdbedit -L</code>) und druckt aktive Sitzungen aus (<code>smbstatus</code>)."
|
||||
},
|
||||
"uninstall": {
|
||||
"heading": "Samba-Server deinstallieren",
|
||||
"body": "Vollständige Bereinigung nach Bestätigung: stoppt und deaktiviert <code>smbd</code> und <code>nmbd</code>, sichert <code>smb.conf</code> als <code>smb.conf.backup.YYYYMMDD_HHMMSS</code>, entfernt Samba-Benutzer mit <code>smbpasswd -x</code> und die Samba-Pakete mit <code>apt-get purge</code>. Die <strong>exportierten Ordner selbst bleiben erhalten</strong>.",
|
||||
"warnTitle": "Ordner überleben – Daten separat sichern",
|
||||
"warnBody": "<em>Freigabe löschen</em> und <em>Samba-Server deinstallieren</em> entfernen die Freigabekonfiguration. Die Daten in den exportierten Ordnern bleiben erhalten. Löschen Sie Daten bei Bedarf nach Abschluss des Skripts ausdrücklich mit <code>rm -rf</code>."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Fehlerbehebung",
|
||||
"privTitle": "Privilegierter Container erforderlich (Skript bricht ab)",
|
||||
"privBody": "Der ausgewählte CT ist unprivilegiert und <code>smbd</code> kann dort keine Dateien bedienen. Wenn Sie das Gate umgehen und Samba von Hand konfigurieren, startet <code>smbd</code> und die Ports öffnen sich, aber die erste Clientverbindung gerät in Panik mit <code>PANIC: sys_setgroups failed</code> in <code>/var/log/samba/log.<client></code> und der Client sieht <code>NT_STATUS_CONNECTION_DISCONNECTED</code>. Die Ursache ist der unprivilegierte Benutzernamensraum mit <code>setgroups=deny</code>, der die Per-Verbindungs-Imitation von Samba blockiert. Weder <code>features=keyctl=1</code> noch das Entfernen von <code>force user</code> / <code>force group</code> ändert dies. Die einzigen praktikablen Optionen sind: Wandeln Sie den CT in einen privilegierten CT um oder verschieben Sie Samba in eine VM.",
|
||||
"aptTitle": "apt-get install schlägt fehl",
|
||||
"aptIntro": "Das Skript nimmt eine Debian-Familie CT an. Auf Alpine / Arch / Rocky / Alma installieren Sie Samba von Hand:",
|
||||
"aptItems": [
|
||||
"Alpine: <code>apk add samba</code>",
|
||||
"Arch: <code>pacman -S samba</code>",
|
||||
"Rocky / Alma: <code>dnf install samba</code>"
|
||||
],
|
||||
"aptOutro": "Führen Sie danach das ProxMenux-Skript erneut aus; sind die Werkzeuge schon vorhanden, wird die Installation übersprungen.",
|
||||
"noShareTitle": "Client verbindet sich, sieht aber die Freigabe nicht",
|
||||
"noShareBody": "Überprüfen Sie, ob <code>browseable = yes</code> im Freigabeblock eingestellt ist (Standard für rw / ro-Modi; möglicherweise fehlt es in benutzerdefinierten). Überprüfen Sie auch die CT-Firewall und die Proxmox-Host-Firewall erlauben TCP 445 (SMB) und 139 (NetBIOS). Einige Windows-Clients benötigen auch eine Namensauflösung - versuchen Sie die IP direkt zuerst.",
|
||||
"authTitle": "Authentifizierung fehlschlägt (NT_STATUS_LOGON_FAILURE)",
|
||||
"authBody": "Entweder ist das Passwort falsch (Samba-Passwörter sind von Systempasswörtern <em>getrennt</em>; Samba-Benutzer mit <code>pdbedit -L</code> auflisten) oder der Benutzer fehlt in <code>valid users</code> für diese Freigabe. Setzen Sie das Passwort im CT mit <code>smbpasswd <user></code> zurück.",
|
||||
"groupTitle": "Vom Client geschriebene Dateien erscheinen mit falscher Gruppe auf dem Server",
|
||||
"groupBody": "Das Skript setzt <code>force group = sharedfiles</code> im Freigabeblock, so dass neue Dateien die Gruppe <code>sharedfiles</code> sein sollten. Wenn dies nicht der Fall ist, ist das SGID-Bit im Elternverzeichnis möglicherweise verloren gegangen (jemand hat <code>chmod</code> von Hand ausgeführt). Erneut anwenden: <code>chmod 2775 /mnt/<share></code>.",
|
||||
"bothTitle": "Teilen des gleichen Ordners über NFS und Samba",
|
||||
"bothBody": "ProxMenux verwendet unterschiedliche GIDs für <code>sharedfiles</code> in jedem Skript (Samba: 999, NFS: 101000). Wenn Sie den gleichen Ordner über beide bedienen, entscheiden Sie sich für eine GID und richten Sie beide aus. Die einfachste Lösung: Nachdem Sie beide Skripte ausgeführt haben, bearbeiten Sie die kleinere GID:"
|
||||
},
|
||||
"related": {
|
||||
"heading": "Verwandte Themen",
|
||||
"items": [
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-samba-client",
|
||||
"label": "Samba-Client in LXC",
|
||||
"tail": " — umgekehrte Richtung: externe Samba-Freigaben im CT einhängen."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/lxc-nfs-server",
|
||||
"label": "NFS Server in LXC",
|
||||
"tail": "— Geschwisterseite, gleiches Muster mit NFS anstelle von CIFS."
|
||||
},
|
||||
{
|
||||
"href": "/docs/storage-share/host-samba",
|
||||
"label": "Samba / CIFS als Proxmox-Speicher",
|
||||
"tailRich": " — Sobald der CT Ordner über Samba freigibt, registrieren Sie die Samba-Freigabe in Proxmox, damit sie unter <em>Datacenter → Storage</em> erscheint."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -28,7 +28,12 @@
|
||||
"switcher": "Language",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina"
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
|
||||
@@ -8,5 +8,6 @@
|
||||
"errors": {
|
||||
"notFound": "Error: CODE_OF_CONDUCT.md file not found.",
|
||||
"loadFailed": "Error: Unable to load the Code of Conduct content."
|
||||
}
|
||||
},
|
||||
"contentMarkdown": "# 📝 Code of Conduct & Best Practices\n\nThis document defines the **principles and guidelines** for the use of **ProxMenux**, aiming to foster **respect, collaboration, and security** in development.\n\n## 📌 1. Code Attribution & Recognition\n\n- If **scripts, code snippets, or ideas** from other repositories or developers are used, the original author will always be credited. \n- A comment will be added in the code or documentation mentioning the source and linking to the original repository if possible. \n- When using code with a specific **license**, its terms must be respected. \n\n### ✅ Example of proper attribution in code:\n\n```bash\n# Script based on the work of [Author] at [Repository Link]\n```\n\n## 🔒 2. Security & Code Responsibility\n\n- All code in this repository follows secure development best practices.\n- Contributions introducing intentional vulnerabilities or unsafe practices are not allowed.\n- Scripts should never compromise system security or user data.\n- Before implementation, contributions should be reviewed to ensure security and stability.\n\n### ⚠️ Responsible Disclosure of Vulnerabilities\n\nIf you discover a security vulnerability, DO NOT report it in public Issues or forums.\n\nInstead, please report it privately via email:\n\n📧 proxmenux@macrimi.pro\n\nFor detailed information on security vulnerabilities and how to report them, please refer to our [Security Policy](./SECURITY.md).\n\n## 🤝 3. Community Guidelines\n\nTo maintain a respectful and professional environment, all users must follow these guidelines:\n\n- ✅ Be respectful and constructive in discussions.\n- ❌ No harassment, hate speech, or offensive behavior will be tolerated.\n- ✅ Provide feedback professionally, avoiding personal attacks.\n- ❌ Violating these guidelines may result in warnings or bans, depending on severity.\n\n\n##\n\nWith this document, we promote ethical code use, security awareness, and a respectful community.\n\n📢 Let's build something great, together!\n\n"
|
||||
}
|
||||
|
||||
@@ -45,7 +45,7 @@
|
||||
},
|
||||
"q4": {
|
||||
"question": "Can I customise ProxMenux?",
|
||||
"p1Rich": "The core scripts can't be modified directly because they're hosted on GitHub and refreshed by the auto-update flow. What you <em>can</em> customise:",
|
||||
"p1Rich": "Local changes to the core scripts can be overwritten by the update flow, so avoid editing those files directly. What you <em>can</em> customise:",
|
||||
"items": [
|
||||
"The console banner via the <strong>FastFetch</strong> tool in the Post-Install options.",
|
||||
"Which optional components are installed (Monitor, Fail2Ban, Lynis…) — pick during install or via the relevant menu later."
|
||||
@@ -63,15 +63,15 @@
|
||||
},
|
||||
"q7": {
|
||||
"question": "Can I contribute to ProxMenux?",
|
||||
"p1Rich": "<strong>Absolutely.</strong> ProxMenux is open source and collaborative. Contributions can be code (bash, Next.js / TypeScript, the translation Python venv), testing, documentation, design, or just ideas.",
|
||||
"p1Rich": "<strong>Absolutely.</strong> ProxMenux is open source and collaborative. Contributions can be code (Bash, Next.js/TypeScript and Python translation tools), testing, documentation, design, or just ideas.",
|
||||
"item1Rich": "Discuss ideas in <discusslink>GitHub Discussions</discusslink> before opening a feature request.",
|
||||
"item2Rich": "For PRs, read the <coclink>Code of Conduct & Best Practices</coclink> first.",
|
||||
"item3Rich": "See the <contriblink>Contributors page</contriblink> for current testers and reviewers."
|
||||
},
|
||||
"q8": {
|
||||
"question": "Does ProxMenux modify critical system files?",
|
||||
"p1Rich": "<strong>No.</strong> ProxMenux installs:",
|
||||
"item1Rich": "Dependencies via apt: <code>dialog</code>, <code>curl</code>, <code>jq</code>, <code>git</code> (and <code>python3</code> + <code>googletrans</code> on the Translation install).",
|
||||
"p1Rich": "<strong>Installing ProxMenux adds the following components.</strong>",
|
||||
"item1Rich": "Dependencies via apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> and <code>git</code>. Translations use pre-built JSON catalogs; the installer does not add a translation virtualenv to the host.",
|
||||
"item2Rich": "The script tree at <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "The launcher at <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "Optional: the Monitor systemd service at <code>proxmenux-monitor.service</code>.",
|
||||
@@ -83,12 +83,12 @@
|
||||
},
|
||||
"q10": {
|
||||
"question": "How do I uninstall ProxMenux?",
|
||||
"p1Rich": "From inside ProxMenux: <strong>Settings → Uninstall ProxMenux</strong>. The uninstaller removes the script tree, the launcher and the Monitor service, optionally removes selected dependencies, and restores <code>/root/.bashrc</code> and <code>/etc/motd</code> backups taken at install time.",
|
||||
"p1Rich": "From inside ProxMenux: <strong>Settings → Uninstall ProxMenux</strong>. The uninstaller removes the script tree, the launcher and the Monitor service, optionally removes selected dependencies, and restores <code>/root/.bashrc</code> and <code>/etc/motd</code> from install-time backups if those backups exist.",
|
||||
"p2Rich": "Full step-by-step: <uninstalllink>Uninstall ProxMenux</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal flags the install URL — is it safe?",
|
||||
"p1Rich": "A 1/95 detection by heuristic engines (e.g. <em>Chong Lua Dao</em>) is a known false positive. The installer uses the standard <code>curl | bash</code> pattern and downloads legitimate binaries (like <code>jq</code> from its official GitHub release), which aggressive scanners flag based on <em>behaviour</em> rather than actual malicious code.",
|
||||
"p1Rich": "The 1/95 result reported in Issue #162, from <em>Chong Lua Dao</em>, was identified by the maintainer as a false positive. The installer uses the <code>curl | bash</code> pattern and can download <code>jq</code> from its official GitHub release. Such <em>behaviour</em> can trigger heuristic scanners; the historical report is not a verdict on every future download.",
|
||||
"p2Rich": "ProxMenux is 100% open source and the install script is reviewable line by line: <scriptlink>install_proxmenux.sh</scriptlink>. More context in <issuelink>Issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -20,9 +20,21 @@
|
||||
"heading": "The direction check",
|
||||
"intro": "During the compatibility check, <code>hb_compat_check</code> compares the kernel recorded in the backup's manifest against the target's current kernel (<code>uname -r</code>) and classifies the restore into one of three cases, stored in the internal variable <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
|
||||
"rows": [
|
||||
{ "direction": "same", "condition": "The major kernel version matches between backup and target.", "behavior": "The full restore flow runs unchanged. No extra filter, no hydration, no special notice in the UI." },
|
||||
{ "direction": "bk_newer", "condition": "Backup kernel is NEWER than the target's (for example: the backup was made on kernel 7.0 and the target runs kernel 6.17).", "behavior": "The full restore flow runs unchanged, exactly like <code>same</code>. No filter is applied. Verified empirically: drivers auto-reinstall against the target's kernel, IOMMU config applies cleanly, VMs with GPU passthrough come up without issue." },
|
||||
{ "direction": "bk_older", "condition": "Backup kernel is OLDER than the target's (for example: the backup was made on kernel 6.17 and the target runs kernel 7.0).", "behavior": "The safe-subset filter and the four-phase hydration below are activated. The restore proceeds — the target reproduces the source, but boot-critical files are not copied verbatim." }
|
||||
{
|
||||
"direction": "same",
|
||||
"condition": "The major kernel version matches between backup and target.",
|
||||
"behavior": "The full restore flow runs unchanged. No extra filter, no hydration, no special notice in the UI."
|
||||
},
|
||||
{
|
||||
"direction": "bk_newer",
|
||||
"condition": "Backup kernel is NEWER than the target's (for example: the backup was made on kernel 7.0 and the target runs kernel 6.17).",
|
||||
"behavior": "The full restore flow runs unchanged, exactly like <code>same</code>. No filter is applied. Verified empirically: drivers auto-reinstall against the target's kernel, IOMMU config applies cleanly, VMs with GPU passthrough come up without issue."
|
||||
},
|
||||
{
|
||||
"direction": "bk_older",
|
||||
"condition": "Backup kernel is OLDER than the target's (for example: the backup was made on kernel 6.17 and the target runs kernel 7.0).",
|
||||
"behavior": "The safe-subset filter and the four-phase hydration below are activated. The restore proceeds — the target reproduces the source, but boot-critical files are not copied verbatim."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whyBkNewerIsSafe": {
|
||||
@@ -31,25 +43,60 @@
|
||||
},
|
||||
"safeSubsetFilter": {
|
||||
"heading": "The safe-subset filter (only when the target kernel is newer)",
|
||||
"intro": "When the target kernel is newer than the backup's, the compatibility check adds 16 boot-critical paths from <code>hb_unsafe_paths_cross_version</code> to <code>RS_SKIP_PATHS</code>. These paths are excluded from the restore because writing a version of them from an older kernel over a target running a newer one has caused kernel panics in bench tests. The paths cover four categories:",
|
||||
"intro": "When the target kernel is newer than the backup's, the compatibility check adds 16 boot-critical paths from <code>hb_unsafe_paths_cross_version</code> to <code>RS_SKIP_PATHS</code>. These paths are excluded from the restore because writing a version of them from an older kernel over a target running a newer one has caused kernel panics in bench tests. The paths cover five categories:",
|
||||
"categoryRows": [
|
||||
{ "category": "Bootloader", "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>", "reason": "GRUB defaults tied to the prior kernel order, and proxmox-boot-tool state (cmdline, ESP UUIDs, hooks) that references paths and identifiers from the older install." },
|
||||
{ "category": "Kernel modules and boot artifacts", "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>", "reason": "Autoload lists that may reference modules renamed between kernel majors, module options that may not apply, initramfs hooks written for the older kernel." },
|
||||
{ "category": "Storage stack and filesystem identity", "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>", "reason": "UUIDs that may not exist on this install, multipath drivers that change between kernels, iSCSI parameters that evolve, udev rules that may bind to nonexistent subsystems, ZFS state (<code>zpool.cache</code> + <code>hostid</code>) that can lock the pool as foreign." },
|
||||
{ "category": "APT sources", "paths": "<code>/etc/apt</code>", "reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade." },
|
||||
{ "category": "systemd", "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>", "reason": "Unit overrides and .wants tied to the older systemd major; configuration keys that may not parse on a newer systemd." }
|
||||
{
|
||||
"category": "Bootloader",
|
||||
"paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
|
||||
"reason": "GRUB defaults tied to the prior kernel order, and proxmox-boot-tool state (cmdline, ESP UUIDs, hooks) that references paths and identifiers from the older install."
|
||||
},
|
||||
{
|
||||
"category": "Kernel modules and boot artifacts",
|
||||
"paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
|
||||
"reason": "Autoload lists that may reference modules renamed between kernel majors, module options that may not apply, initramfs hooks written for the older kernel."
|
||||
},
|
||||
{
|
||||
"category": "Storage stack and filesystem identity",
|
||||
"paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
|
||||
"reason": "UUIDs that may not exist on this install, multipath drivers that change between kernels, iSCSI parameters that evolve, udev rules that may bind to nonexistent subsystems, ZFS state (<code>zpool.cache</code> + <code>hostid</code>) that can lock the pool as foreign."
|
||||
},
|
||||
{
|
||||
"category": "APT sources",
|
||||
"paths": "<code>/etc/apt</code>",
|
||||
"reason": "APT source suites may trigger a downgrade of critical packages on the next upgrade."
|
||||
},
|
||||
{
|
||||
"category": "systemd",
|
||||
"paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
|
||||
"reason": "Unit overrides and .wants tied to the older systemd major; configuration keys that may not parse on a newer systemd."
|
||||
}
|
||||
],
|
||||
"outroBody": "The filter runs BEFORE the confirmation dialog so the user sees the exact list of paths that will be skipped, categorised by reason. The restore still proceeds — everything else (VMs, LXCs, network, /etc/pve, users, cron, ProxMenux state, packages, drivers, /root) is restored normally."
|
||||
"outroBody": "The filter runs BEFORE the confirmation dialog so the user sees the exact list of paths that will be skipped, categorised by reason. The restore still proceeds — everything else (VM/LXC configuration, network, /etc/pve, users, cron, ProxMenux state, packages, drivers, /root) is restored normally."
|
||||
},
|
||||
"hydration": {
|
||||
"heading": "Kernel-agnostic hydration",
|
||||
"intro": "The safe-subset filter alone would leave the target without the tuning the user had inside those boot-critical files: IOMMU cmdline for GPU passthrough, VFIO device IDs, custom <code>GRUB_TIMEOUT</code>, nvidia blacklists. The hydration pass re-applies those bits kernel-agnostically. Four phases run when the target kernel is newer than the backup's, each additive (never overwrites a value the target already carries) and idempotent (running twice is a no-op).",
|
||||
"intro": "The filter omits boot-critical files, so hydration reapplies selected user tuning: IOMMU cmdline, VFIO IDs, custom <code>GRUB_TIMEOUT</code> and nvidia blacklists. It runs when the target kernel is newer. Cmdline merges preserve existing target keys and module merges append missing entries. Whitelisted GRUB values and user files may replace differing target content. Repeating the same input is idempotent.",
|
||||
"phaseRows": [
|
||||
{ "phase": "1a — GRUB path", "detail": "For hosts using GRUB (ext4/lvm installs). <code>_rs_hyd_grub</code> merges every token from the backup's <code>manifest.kernel_params.cmdline_extra</code> into the target's live <code>GRUB_CMDLINE_LINUX_DEFAULT</code>, skipping tokens whose key the target already carries. Then merges whitelisted <code>GRUB_*</code> keys (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) from the backup's <code>/etc/default/grub</code> if they differ from the target's." },
|
||||
{ "phase": "1b — systemd-boot / ZFS path", "detail": "For hosts using systemd-boot (typically ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> merges user tokens from <code>cmdline_extra</code> into the target's <code>/etc/kernel/cmdline</code>, keeping the target's own <code>root=</code>, <code>boot=</code> and <code>rootflags=</code> boilerplate intact." },
|
||||
{ "phase": "2 — /etc/modules merge", "detail": "<code>_rs_hyd_modules</code> appends modules from <code>manifest.kernel_params.modules_loaded_at_boot</code> that are in the whitelist (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) AND not already present in the target's <code>/etc/modules</code>." },
|
||||
{ "phase": "3 — Whitelisted files copy", "detail": "<code>_rs_hyd_files</code> copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, and the ProxMenux VFIO bind rule + nvidia udev rules under <code>/etc/udev/rules.d</code>. Distro-owned files (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) are intentionally excluded — their contents evolve between releases." },
|
||||
{ "phase": "4 — Force post-boot reflows", "detail": "The four phases write directly to the live target OUTSIDE the normal restore pipeline. To make the merged tokens/modules/files take effect on the next boot, <code>HB_HYDRATION_APPLIED=1</code> propagates through <code>plan.env</code> to <code>apply_pending_restore.sh</code>, which forces <code>NEEDS_INITRAMFS=1</code> and <code>NEEDS_GRUB=1</code> regardless of what was in the apply list. The post-boot dispatcher then regenerates initramfs and refreshes the bootloader." }
|
||||
{
|
||||
"phase": "1a — GRUB path",
|
||||
"detail": "For hosts using GRUB (ext4/lvm installs). <code>_rs_hyd_grub</code> merges every token from the backup's <code>manifest.kernel_params.cmdline_extra</code> into the target's live <code>GRUB_CMDLINE_LINUX_DEFAULT</code>, skipping tokens whose key the target already carries. Then merges whitelisted <code>GRUB_*</code> keys (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) from the backup's <code>/etc/default/grub</code> if they differ from the target's."
|
||||
},
|
||||
{
|
||||
"phase": "1b — systemd-boot / ZFS path",
|
||||
"detail": "For hosts using systemd-boot (typically ZFS-on-root). <code>_rs_hyd_kernel_cmdline</code> merges user tokens from <code>cmdline_extra</code> into the target's <code>/etc/kernel/cmdline</code>, keeping the target's own <code>root=</code>, <code>boot=</code> and <code>rootflags=</code> boilerplate intact."
|
||||
},
|
||||
{
|
||||
"phase": "2 — /etc/modules merge",
|
||||
"detail": "<code>_rs_hyd_modules</code> appends modules from <code>manifest.kernel_params.modules_loaded_at_boot</code> that are in the whitelist (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) AND not already present in the target's <code>/etc/modules</code>."
|
||||
},
|
||||
{
|
||||
"phase": "3 — Whitelisted files copy",
|
||||
"detail": "<code>_rs_hyd_files</code> copies user-authored files from the staging rootfs to the live target when the content differs. Whitelist covers VFIO/nvidia/blacklist files under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, and the ProxMenux VFIO bind rule + nvidia udev rules under <code>/etc/udev/rules.d</code>. Distro-owned files (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) are intentionally excluded — their contents evolve between releases."
|
||||
},
|
||||
{
|
||||
"phase": "4 — Force post-boot reflows",
|
||||
"detail": "The four phases write directly to the live target OUTSIDE the normal restore pipeline. To make the merged tokens/modules/files take effect on the next boot, <code>HB_HYDRATION_APPLIED=1</code> propagates through <code>plan.env</code> to <code>apply_pending_restore.sh</code>, which forces <code>NEEDS_INITRAMFS=1</code> and <code>NEEDS_GRUB=1</code> regardless of what was in the apply list. The post-boot dispatcher then regenerates initramfs and refreshes the bootloader."
|
||||
}
|
||||
]
|
||||
},
|
||||
"planCommit": {
|
||||
@@ -65,8 +112,14 @@
|
||||
"heading": "Concrete examples",
|
||||
"intro": "The hydration pass is not abstract — it produces observable, correct outcomes for common scenarios. Two examples that hydration handles automatically:",
|
||||
"rows": [
|
||||
{ "scenario": "GPU passthrough (VFIO)", "detail": "Source had <code>intel_iommu=on iommu=pt</code> in the cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, an <code>/etc/modprobe.d/vfio.conf</code> with <code>options vfio-pci ids=10de:2216</code>, and a <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to <code>/etc/modules</code>, and copies the two user-authored modprobe files. On the next boot, IOMMU is active, VFIO modules load, the GPU is bound to vfio-pci and the VM comes up with passthrough working." },
|
||||
{ "scenario": "Custom GRUB defaults", "detail": "Source had <code>GRUB_TIMEOUT=1</code> and <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration reads both keys from the backup's <code>/etc/default/grub</code>, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including <code>GRUB_DISTRIBUTOR</code>, untouched)." }
|
||||
{
|
||||
"scenario": "GPU passthrough (VFIO)",
|
||||
"detail": "Source had <code>intel_iommu=on iommu=pt</code> in the cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> in <code>/etc/modules</code>, an <code>/etc/modprobe.d/vfio.conf</code> with <code>options vfio-pci ids=10de:2216</code>, and a <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration merges the cmdline tokens into the target's GRUB or kernel cmdline, appends the vfio modules to <code>/etc/modules</code>, and copies the two user-authored modprobe files. On the next boot, IOMMU is active, VFIO modules load, the GPU is bound to vfio-pci and the VM comes up with passthrough working."
|
||||
},
|
||||
{
|
||||
"scenario": "Custom GRUB defaults",
|
||||
"detail": "Source had <code>GRUB_TIMEOUT=1</code> and <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration reads both keys from the backup's <code>/etc/default/grub</code>, sees they differ from the fresh install's defaults, and rewrites those two lines in the target's file (leaving everything else, including <code>GRUB_DISTRIBUTOR</code>, untouched)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"callout": {
|
||||
@@ -77,18 +130,41 @@
|
||||
"heading": "Where the mechanisms live",
|
||||
"intro": "For developers looking to trace or extend the cross-kernel behaviour:",
|
||||
"rows": [
|
||||
{ "component": "Direction detection", "location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Sets <code>HB_COMPAT_KERNEL_DIRECTION</code>." },
|
||||
{ "component": "Safe-subset path list", "location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emits <code>path\\treason</code> lines used by both the CLI filter and the Web endpoint <code>/api/host-backups/restore/prepare</code>." },
|
||||
{ "component": "Hydration phases", "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> in <code>backup_host.sh</code>. Orchestrated by <code>_rs_apply_bk_older_hydration</code>." },
|
||||
{ "component": "Post-boot reflow forcing", "location": "<code>apply_pending_restore.sh</code> reads <code>HB_HYDRATION_APPLIED</code> from <code>plan.env</code> and forces <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>." },
|
||||
{ "component": "Web preview", "location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Sources the helper library, runs <code>_rs_apply_bk_older_hydration</code> in plan mode, returns the actions to the Web modal." }
|
||||
{
|
||||
"component": "Direction detection",
|
||||
"location": "<code>hb_compat_check</code> in <code>lib_host_backup_common.sh</code>. Sets <code>HB_COMPAT_KERNEL_DIRECTION</code>."
|
||||
},
|
||||
{
|
||||
"component": "Safe-subset path list",
|
||||
"location": "<code>hb_unsafe_paths_cross_version</code> in <code>lib_host_backup_common.sh</code>. Emits <code>path\\treason</code> lines used by both the CLI filter and the Web endpoint <code>/api/host-backups/restore/prepare</code>."
|
||||
},
|
||||
{
|
||||
"component": "Hydration phases",
|
||||
"location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> in <code>backup_host.sh</code>. Orchestrated by <code>_rs_apply_bk_older_hydration</code>."
|
||||
},
|
||||
{
|
||||
"component": "Post-boot reflow forcing",
|
||||
"location": "<code>apply_pending_restore.sh</code> reads <code>HB_HYDRATION_APPLIED</code> from <code>plan.env</code> and forces <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
|
||||
},
|
||||
{
|
||||
"component": "Web preview",
|
||||
"location": "<code>/api/host-backups/restore/prepare</code> in <code>flask_server.py</code>. Sources the helper library, runs <code>_rs_apply_bk_older_hydration</code> in plan mode, returns the actions to the Web modal."
|
||||
}
|
||||
]
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Where to go next",
|
||||
"items": [
|
||||
{ "label": "Restoring", "href": "/docs/backup-restore/restoring", "tail": " — the full restore pipeline this page's mechanisms plug into." },
|
||||
{ "label": "How it works", "href": "/docs/backup-restore/how-it-works", "tail": " — the manifest and collectors that produce the <code>kernel_params</code> block hydration reads from." }
|
||||
{
|
||||
"label": "Restoring",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — the full restore pipeline this page's mechanisms plug into."
|
||||
},
|
||||
{
|
||||
"label": "How it works",
|
||||
"href": "/docs/backup-restore/how-it-works",
|
||||
"tail": " — the manifest and collectors that produce the <code>kernel_params</code> block hydration reads from."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -24,19 +24,47 @@
|
||||
"heading": "The borg binary",
|
||||
"intro": "Borg is not a base dependency of the ProxMenux installer. When a backup runs, <code>hb_ensure_borg</code> resolves the binary from four sources in order and returns the first that works:",
|
||||
"rows": [
|
||||
{ "priority": "1", "source": "System <code>borg</code>", "detail": "If the host already has <code>borg</code> installed via APT (<code>which borg</code> resolves), that binary is used." },
|
||||
{ "priority": "2", "source": "State-dir cache", "detail": "<code>/usr/local/share/proxmenux/borg</code> — kept from a prior GitHub download on this host." },
|
||||
{ "priority": "3", "source": "Monitor AppImage bundle", "detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working <code>borg</code>." },
|
||||
{ "priority": "4", "source": "GitHub download", "detail": "<code>wget</code> against the pinned <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verified against a constant SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). On checksum mismatch the binary is discarded and the backup aborts. The downloaded file is cached in the state dir so subsequent backups use path 2." }
|
||||
{
|
||||
"priority": "1",
|
||||
"source": "System <code>borg</code>",
|
||||
"detail": "If the host already has <code>borg</code> installed via APT (<code>which borg</code> resolves), that binary is used."
|
||||
},
|
||||
{
|
||||
"priority": "2",
|
||||
"source": "State-dir cache",
|
||||
"detail": "<code>/usr/local/share/proxmenux/borg</code> — kept from a prior GitHub download on this host."
|
||||
},
|
||||
{
|
||||
"priority": "3",
|
||||
"source": "Monitor AppImage bundle",
|
||||
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — the AppImage bundles a signed borg-linux64. This is the offline-safe path: a host with no internet still has a working <code>borg</code>."
|
||||
},
|
||||
{
|
||||
"priority": "4",
|
||||
"source": "GitHub download",
|
||||
"detail": "<code>wget</code> against the pinned <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verified against a constant SHA-256 in <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). On checksum mismatch the binary is discarded and the backup aborts. The downloaded file is cached in the state dir so subsequent backups use path 2."
|
||||
}
|
||||
]
|
||||
},
|
||||
"repoTypes": {
|
||||
"heading": "Repository types",
|
||||
"intro": "The repository type is chosen when a target is added. Each type resolves to a different repository URL that Borg understands.",
|
||||
"rows": [
|
||||
{ "type": "remote", "url": "ssh://USER@HOST/RPATH", "detail": "Repository lives on a remote server that runs <code>borg serve</code>. Requires an SSH connection to that server." },
|
||||
{ "type": "usb", "url": "/mnt/MOUNTPOINT/borgbackup", "detail": "Repository lives on a mounted external disk (typically USB). The mount is resolved via <code>hb_prompt_mounted_path</code>, which detects, mounts or formats USB partitions as needed." },
|
||||
{ "type": "local", "url": "/backup/borgbackup (any absolute path)", "detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against operator error but not against disk failure." }
|
||||
{
|
||||
"type": "remote",
|
||||
"url": "ssh://USER@HOST/RPATH",
|
||||
"detail": "Repository lives on a remote server that runs <code>borg serve</code>. Requires an SSH connection to that server."
|
||||
},
|
||||
{
|
||||
"type": "usb",
|
||||
"url": "/mnt/MOUNTPOINT/borgbackup",
|
||||
"detail": "Repository lives on a mounted external disk (typically USB). The mount is resolved via <code>hb_prompt_mounted_path</code>, which detects, mounts or formats USB partitions as needed."
|
||||
},
|
||||
{
|
||||
"type": "local",
|
||||
"url": "/backup/borgbackup (any absolute path)",
|
||||
"detail": "Repository lives on a local directory. Meaningful only when the target directory is on a separate physical disk — a repository on the same disk as the source protects against operator error but not against disk failure."
|
||||
}
|
||||
]
|
||||
},
|
||||
"serverSetup": {
|
||||
@@ -50,30 +78,62 @@
|
||||
"Another Proxmox host on the same LAN, or a VM anywhere reachable over SSH."
|
||||
],
|
||||
"lxcWarningTitle": "LXC as Borg server",
|
||||
"lxcWarningBody": "If the Borg server runs inside an LXC, the container must have a user account with a password.",
|
||||
"lxcWarningBody": "If the Borg server runs inside an LXC, generate-auto requires an account that accepts SSH password authentication during key installation. If password login is unavailable, use manual key installation or the generate-pct alternative through the PVE host.",
|
||||
"requirementsTitle": "Requirements on the server",
|
||||
"requirementsRows": [
|
||||
{ "requirement": "borg binary at <code>/usr/bin/borg</code>", "detail": "The <code>command=\"/usr/bin/borg serve ...\"</code> line ProxMenux writes into <code>authorized_keys</code> hard-codes that path. Installing via APT (<code>apt install borgbackup</code>) puts it there. A standalone binary must be symlinked to <code>/usr/bin/borg</code>." },
|
||||
{ "requirement": "A dedicated user account (typically <code>borg</code>)", "detail": "Owns the repository directory and receives incoming SSH connections. Does not need sudo or shell access — the authorized_keys line disables interactive shells anyway." },
|
||||
{ "requirement": "A writable repository directory", "detail": "The path the operator gives ProxMenux (for example <code>/backup/borgbackup</code>) must exist on the server and be owned by the borg user." },
|
||||
{ "requirement": "SSH daemon accepting the borg user", "detail": "<code>PubkeyAuthentication yes</code> (default). Password authentication is only needed for the one-shot <em>generate-auto</em> flow — after the key is installed, the server can disable password auth entirely." }
|
||||
{
|
||||
"requirement": "borg binary at <code>/usr/bin/borg</code>",
|
||||
"detail": "The <code>command=\"/usr/bin/borg serve ...\"</code> line ProxMenux writes into <code>authorized_keys</code> hard-codes that path. Installing via APT (<code>apt install borgbackup</code>) puts it there. A standalone binary must be symlinked to <code>/usr/bin/borg</code>."
|
||||
},
|
||||
{
|
||||
"requirement": "A dedicated user account (typically <code>borg</code>)",
|
||||
"detail": "Owns the repository directory and receives incoming SSH connections. Does not need sudo or shell access — the authorized_keys line disables interactive shells anyway."
|
||||
},
|
||||
{
|
||||
"requirement": "A writable repository directory",
|
||||
"detail": "The path the operator gives ProxMenux (for example <code>/backup/borgbackup</code>) must exist on the server and be owned by the borg user."
|
||||
},
|
||||
{
|
||||
"requirement": "SSH daemon accepting the borg user",
|
||||
"detail": "<code>PubkeyAuthentication yes</code> (default). Password authentication is only needed for the one-shot <em>generate-auto</em> flow — after the key is installed, the server can disable password auth entirely."
|
||||
}
|
||||
],
|
||||
"minimalSetupTitle": "Minimal server setup",
|
||||
"minimalSetupBody": "On a Debian or Ubuntu Borg server, a working baseline is four commands as root:",
|
||||
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
|
||||
"minimalSetupNote": "After this, ProxMenux's <code>generate-auto</code> mode can connect using the borg user's password once, install its own SSH key, and every subsequent backup uses that key. No further server-side configuration is needed — the key restricts itself to <code>borg serve</code> on that path."
|
||||
"minimalSetupNote": "With the server prepared and SSH password authentication available, ProxMenux’s <code>generate-auto</code> mode can install its SSH key using an account permitted to write the borg user’s authorized_keys file. Subsequent backups use that key, restricted to <code>borg serve</code> on the configured path. Without password login, install the key manually or use the PVE-host alternative."
|
||||
},
|
||||
"sshAuth": {
|
||||
"heading": "SSH authentication (client side)",
|
||||
"intro": "Remote Borg repositories are accessed over SSH. The connection runs from the ProxMenux host to a user account on the Borg server that runs <code>borg serve</code>. This user is typically named <code>borg</code>, NOT the admin/root user of the server — the borg-serve command line locks the connection to that specific repository path (see the key strategies below).",
|
||||
"strategiesTitle": "The four key strategies",
|
||||
"strategiesIntro": "When a remote target is added, ProxMenux prompts for the SSH user, host and remote path, then asks how to authenticate. Four modes:",
|
||||
"strategiesTitle": "SSH key strategies",
|
||||
"strategiesIntro": "When a remote target is added, ProxMenux asks for the SSH user, host, port and remote path, then offers four authentication choices. The additional generate-pct path is offered when password authentication is refused. The modes are described below:",
|
||||
"strategyRows": [
|
||||
{ "mode": "generate-auto", "label": "Recommended", "detail": "ProxMenux generates a new ed25519 keypair at <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, then uses <code>sshpass</code> to log in ONCE to the server with the admin password and append the public key to <code>~borg/.ssh/authorized_keys</code>. The admin password is only used for this one call — it is never stored." },
|
||||
{ "mode": "generate-manual", "label": "No admin password on this host", "detail": "ProxMenux generates the keypair as above but displays the full <code>authorized_keys</code> line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for." },
|
||||
{ "mode": "generate-pct", "label": "Borg server is a PVE LXC", "detail": "The Borg server runs inside an LXC on a PVE node. ProxMenux authorises the key via <code>pct exec</code> from the PVE host — root on the PVE host writes into the LXC's <code>~borg/.ssh/authorized_keys</code> without needing SSH into the LXC itself." },
|
||||
{ "mode": "existing", "label": "Use an existing key", "detail": "ProxMenux scans <code>/root/.ssh/</code> and <code>$HOME/.ssh/</code> for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path." },
|
||||
{ "mode": "none", "label": "Default SSH config", "detail": "No custom key — Borg relies on the host's default SSH configuration (typically <code>~/.ssh/id_rsa</code> or an SSH agent)." }
|
||||
{
|
||||
"mode": "generate-auto",
|
||||
"label": "Recommended",
|
||||
"detail": "ProxMenux generates or reuses an ed25519 keypair at <code>~/.ssh/borg_proxmenux_HOST_ed25519</code>, then uses <code>sshpass</code> for a login probe and installation of the public key in <code>~borg/.ssh/authorized_keys</code>. The password belongs to an account allowed to write that file, usually root or the borg user. It is used during setup and is not saved."
|
||||
},
|
||||
{
|
||||
"mode": "generate-manual",
|
||||
"label": "No admin password on this host",
|
||||
"detail": "ProxMenux generates the keypair as above but displays the full <code>authorized_keys</code> line for the operator to paste manually into the server. The admin password never leaves the ProxMenux host because it is never asked for."
|
||||
},
|
||||
{
|
||||
"mode": "generate-pct",
|
||||
"label": "Borg server is a PVE LXC",
|
||||
"detail": "The Borg server runs inside an LXC on a PVE node. ProxMenux authorises the key via <code>pct exec</code> from the PVE host — root on the PVE host writes into the LXC's <code>~borg/.ssh/authorized_keys</code> without needing SSH into the LXC itself."
|
||||
},
|
||||
{
|
||||
"mode": "existing",
|
||||
"label": "Use an existing key",
|
||||
"detail": "ProxMenux scans <code>/root/.ssh/</code> and <code>$HOME/.ssh/</code> for parseable ed25519/RSA private keys and lists them. The operator picks one or browses manually to a non-standard path."
|
||||
},
|
||||
{
|
||||
"mode": "none",
|
||||
"label": "Default SSH config",
|
||||
"detail": "No custom key — Borg relies on the host's default SSH configuration (typically <code>~/.ssh/id_rsa</code> or an SSH agent)."
|
||||
}
|
||||
],
|
||||
"restrictTitle": "The authorized_keys line",
|
||||
"restrictBody": "For every generated key, the <code>authorized_keys</code> line ProxMenux writes on the server locks the key to a single borg-serve invocation against the configured repository path:",
|
||||
@@ -84,24 +144,50 @@
|
||||
"heading": "Saved targets",
|
||||
"intro": "A saved target persists the repository configuration under a friendly name so the details do not have to be re-entered. Storage layout in the ProxMenux state directory:",
|
||||
"rows": [
|
||||
{ "file": "borg-targets.txt", "content": "One line per target: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Read by <code>hb_collect_borg_configs</code> to populate the target-selection menu." },
|
||||
{ "file": "borg-pass-NAME.txt", "content": "Passphrase for the target NAMEd above (<code>chmod 600</code>). Only present when the operator chose repokey encryption." }
|
||||
{
|
||||
"file": "borg-targets.txt",
|
||||
"content": "One line per target: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Read by <code>hb_collect_borg_configs</code> to populate the target-selection menu."
|
||||
},
|
||||
{
|
||||
"file": "borg-pass-NAME.txt",
|
||||
"content": "Passphrase for the target NAMEd above (<code>chmod 600</code>). Only present when the operator chose repokey encryption."
|
||||
}
|
||||
],
|
||||
"outro": "Saving is optional — the operator can decline the save prompt for a one-shot backup that leaves no credentials on the host."
|
||||
"outro": "Saving the target is optional. Declining the save prompt omits the named target configuration, but does not remove a generated SSH key. If repokey encryption is enabled without a saved target, ProxMenux still saves the passphrase in the legacy borg-pass.txt file."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Encryption",
|
||||
"body": "Repositories are initialised with an encryption mode via <code>hb_borg_init_if_needed</code>: the modern <code>borg repo-create -e MODE</code> when available, or the legacy <code>borg init --encryption=MODE</code>. ProxMenux exposes two modes: <code>repokey</code> (default) and <code>none</code>. In <code>repokey</code> mode Borg stores the encryption key inside the repository itself; access requires a passphrase, which ProxMenux prompts for twice with match validation and stores at <code>borg-pass-NAME.txt</code>. A mandatory acknowledgement dialog is shown after the passphrase is saved: the passphrase is the only way to access the encrypted archives, and losing it makes every archive in the repository unrecoverable."
|
||||
"body": "Repositories are initialised with an encryption mode via <code>hb_borg_init_if_needed</code>: the modern <code>borg repo-create -e MODE</code> when available, or the legacy <code>borg init --encryption=MODE</code>. ProxMenux exposes two modes: <code>repokey</code> (default) and <code>none</code>. In <code>repokey</code> mode Borg stores the encryption key inside the repository itself; access requires a passphrase, which ProxMenux prompts for twice with match validation and stores at <code>borg-pass-NAME.txt</code> for saved targets (or in the legacy file described above). A mandatory acknowledgement dialog is shown after the passphrase is saved: the passphrase is the only way to access the encrypted archives, and losing it makes every archive in the repository unrecoverable."
|
||||
},
|
||||
"runtimeEnv": {
|
||||
"heading": "Runtime environment",
|
||||
"intro": "ProxMenux exports the following environment variables before invoking <code>borg</code>. They configure the connection and unlock the repository without embedding secrets in the command line.",
|
||||
"rows": [
|
||||
{ "var": "BORG_RSH", "value": "ssh -i SSH_KEY_PATH -o StrictHostKeyChecking=accept-new", "purpose": "The remote-shell command Borg uses for SSH-served repositories. Set only when a custom key was selected; otherwise unset so Borg uses the default SSH configuration." },
|
||||
{ "var": "BORG_PASSPHRASE", "value": "(passphrase from borg-pass-NAME.txt)", "purpose": "Unlocks the repokey. Set only when the target uses <code>repokey</code> encryption. Never appears in the process argument list." },
|
||||
{ "var": "BORG_ENCRYPT_MODE", "value": "repokey | none", "purpose": "Used by <code>hb_borg_init_if_needed</code> when initialising a repository that does not yet exist. Ignored by <code>borg create</code> on existing repositories." },
|
||||
{ "var": "BORG_RELOCATED_REPO_ACCESS_IS_OK", "value": "yes", "purpose": "Suppresses the interactive prompt Borg raises when the repository URL differs from the URL it was originally reached from (common after a mount-point rename or SSH-host reachable via new address)." },
|
||||
{ "var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK", "value": "yes", "purpose": "Suppresses the interactive prompt Borg raises the first time an unencrypted repository is accessed from a new client." }
|
||||
{
|
||||
"var": "BORG_RSH",
|
||||
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
|
||||
"purpose": "The remote-shell command Borg uses for SSH repositories. A selected key adds the identity options. When a target is first added with a non-default port, ProxMenux also appends -p PORT; saved targets, scheduled jobs and the Monitor rely on the port in the ssh:// URL instead. Without a custom key, and for a newly added target with the default port, the variable is unset so Borg uses the host’s default SSH configuration."
|
||||
},
|
||||
{
|
||||
"var": "BORG_PASSPHRASE",
|
||||
"value": "(passphrase from borg-pass-NAME.txt)",
|
||||
"purpose": "Unlocks the repokey. Set only when the target uses <code>repokey</code> encryption. Never appears in the process argument list."
|
||||
},
|
||||
{
|
||||
"var": "BORG_ENCRYPT_MODE",
|
||||
"value": "repokey | none",
|
||||
"purpose": "Used by <code>hb_borg_init_if_needed</code> when initialising a repository that does not yet exist. Ignored by <code>borg create</code> on existing repositories."
|
||||
},
|
||||
{
|
||||
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Suppresses the interactive prompt Borg raises when the repository URL differs from the URL it was originally reached from (common after a mount-point rename or SSH-host reachable via new address)."
|
||||
},
|
||||
{
|
||||
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
|
||||
"value": "yes",
|
||||
"purpose": "Suppresses the interactive prompt Borg raises the first time an unencrypted repository is accessed from a new client."
|
||||
}
|
||||
]
|
||||
},
|
||||
"archiveFormat": {
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "Same payload, three backends",
|
||||
"body": "Every backup produces the same three payloads (rootfs, manifest, applications). What changes between destinations is how those payloads are stored and how the operator retrieves them for a restore. Each backend is implemented as a separate function in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — but all four share the same staging step (<code>hb_prepare_staging</code>) and the same restore code path. The choice of destination only affects the write and the retrieval; it does not change what a restore does or how it consumes the archive."
|
||||
"body": "Every backup produces the same three payloads (rootfs, manifest, applications). What changes between destinations is how those payloads are stored and how the operator retrieves them for a restore. Each backend is implemented as a separate function in <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — but all three share the same staging step (<code>hb_prepare_staging</code>) and the same restore code path. The choice of destination only affects the write and the retrieval; it does not change what a restore does or how it consumes the archive."
|
||||
},
|
||||
"comparison": {
|
||||
"heading": "Feature comparison",
|
||||
@@ -29,8 +29,8 @@
|
||||
{
|
||||
"feature": "Compression",
|
||||
"local": "zstd (default level) via <code>tar --zstd</code>. gzip fallback.",
|
||||
"pbs": "PBS-managed. The client streams uncompressed; the server chunks + compresses.",
|
||||
"borg": "Borg's built-in (lz4 default). Configurable at repo init."
|
||||
"pbs": "Managed by proxmox-backup-client. ProxMenux does not override compression settings.",
|
||||
"borg": "Borg’s built-in compression. ProxMenux invokes borg create without overriding compression settings."
|
||||
},
|
||||
{
|
||||
"feature": "Deduplication",
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
},
|
||||
"backupCommand": {
|
||||
"heading": "The backup command",
|
||||
"intro": "The upload is a single invocation of <code>proxmox-backup-client backup</code>. ProxMenux runs it inside an <code>env</code> wrapper so credentials never appear in the process argument list.",
|
||||
"intro": "The upload is a single invocation of <code>proxmox-backup-client backup</code>. ProxMenux uses <code>env</code> to pass the password, encryption password and fingerprint to the client as environment variables.",
|
||||
"cmd": "env \\\n PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n proxmox-backup-client backup \\\n hostcfg.pxar:$staging_root \\\n --repository USER@REALM@HOST:DATASTORE \\\n --backup-type host \\\n --backup-id hostcfg-HOSTNAME \\\n --backup-time BACKUP-EPOCH \\\n [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
|
||||
"backupIdTitle": "Backup ID naming",
|
||||
"backupIdBody": "The default backup ID is <code>hostcfg-HOSTNAME</code>. The operator is asked to confirm or edit it before the upload; any characters outside <code>[A-Za-z0-9_-]</code> are stripped and trailing dashes are trimmed. Reusing the same ID across runs is intentional — PBS treats the ID as a <em>group</em>, and every subsequent backup appears as a new backup inside that group, sharing dedup with prior runs.",
|
||||
@@ -61,13 +61,13 @@
|
||||
"modesSharedTitle": "Shared keyfile (import on every host)",
|
||||
"modesSharedBody": "One master keyfile generated once and installed on every host via the <em>Use an existing keyfile</em> option. Management is simpler: a single secret to safeguard, and any host can decrypt the archives of any other (useful for consolidation, cross-host restore drills or centralised backup verification). The trade-off is that a leak of the shared keyfile exposes every host at once. Recommended for homelabs and for fleets where all hosts have the same owner and trust boundary.",
|
||||
"recoveryTitle": "Upload key to PBS — the operator decides",
|
||||
"recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>Nothing gets uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays only at the canonical local path, ProxMenux never touches PBS with any recovery artefact, and the operator handles the offsite copy themselves (the Monitor's <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce <code>pbs-key.recovery.enc</code>. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile ever leaves the host. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
|
||||
"recoveryBody": "Right after the keyfile is chosen, ProxMenux asks a single explicit question — <em>Upload key to PBS?</em> — with two answers. <strong>No recovery artifact is uploaded to PBS until the operator answers Yes.</strong> The default is <em>No, keep local only</em>: the keyfile stays at the canonical local path, ProxMenux uploads no recovery artifact to PBS, and the operator handles the offsite copy themselves (the Monitor’s <em>Download keyfile</em> button in the PBS destination row provides one on demand). Choosing <em>Yes, upload</em> prompts for a recovery passphrase — twice, with match validation — and ProxMenux wraps the keyfile with that passphrase using AES-256-CBC and PBKDF2 (600 000 iterations, random salt) to produce <code>pbs-key.recovery.enc</code>. Every subsequent encrypted backup uploads that envelope to PBS as a paired backup group. Neither the passphrase nor a plaintext copy of the keyfile is sent to PBS during these uploads. The choice can be changed later from the Monitor at any time — the escrow toggle inline in the PBS destination row flips Yes/No and applies immediately (Start uploading, Stop uploading, or Update passphrase, matching the current state).",
|
||||
"blobUploadTitle": "Paired backup group on PBS",
|
||||
"blobUploadBody1": "When the escrow mode is <em>Yes, upload</em>, ProxMenux uploads the recovery envelope to PBS after every encrypted backup as a second, paired backup group with the same name as the host group but ending in <code>-keyrecovery</code>. The two groups sit next to each other in the datastore listing — one for host backups, one for recovery envelopes. <strong>The envelope never leaves the host in plaintext</strong>: encryption happens on the host itself with AES-256-CBC and PBKDF2 before any bytes go on the wire (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS receives only the already-encrypted envelope.",
|
||||
"envelopeSecurityTitle": "Is uploading the keyrecovery file to PBS a security risk?",
|
||||
"envelopeSecurityBody": "The keyrecovery file is encrypted in transit and at rest. The recovery passphrase never leaves the host: encryption happens locally before the upload, and PBS only ever sees the already-encrypted result. A PBS administrator — or anyone with access to the datastore — can download the keyrecovery file, but without the recovery passphrase they cannot read the keyfile inside: it is opaque ciphertext. Reconstructing the keyfile requires both pieces at once, the keyrecovery file and the passphrase, and only the operator holds both.",
|
||||
"blobUploadConstraintTitle": "Why two groups instead of a single encrypted one",
|
||||
"blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by PBS with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
|
||||
"blobUploadConstraintBody": "A single <code>proxmox-backup-client backup</code> invocation encrypts every one of its archives with the same keyfile, or none at all — there is no in-between. The host backup has to be encrypted with the host keyfile, but the recovery envelope cannot ride along in that same upload, because it would end up encrypted with the very keyfile it contains: on a freshly reinstalled host there would be no way to open it (you would need the keyfile to decrypt the keyfile). That is why the two artefacts are uploaded independently and appear as two separate groups: the host backup is encrypted by the PBS client with the keyfile, and the recovery envelope is encrypted by ProxMenux with the passphrase before upload. Two different encryption layers protecting two different assets.",
|
||||
"blobUploadImageAlt": "PBS UI showing the hostcfg-HOSTNAME and hostcfg-HOSTNAME-keyrecovery backup groups adjacent in the datastore listing.",
|
||||
"blobUploadImageCaption": "PBS UI — the paired backup groups. The main group holds the host backups; the -keyrecovery group holds the passphrase-wrapped keyfile.",
|
||||
"recoverTitle": "Recovery on a fresh host",
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
{
|
||||
"id": "clave-cifrado",
|
||||
"term": "Keyfile (encryption key)",
|
||||
"def": "Binary file that Proxmox Backup Server uses to encrypt the <a href=\"#chunk\">chunks</a> of each backup before uploading them. Without this file, no encrypted backup can be read. ProxMenux stores it at <code>/usr/local/share/proxmenux/pbs-key.conf</code> with mode <code>600</code>. This is the asset that has to be protected; the <a href=\"#sobre-recuperacion\">recovery envelope</a> exists precisely so that this file can be rescued if it is lost."
|
||||
"def": "Key file used by proxmox-backup-client to encrypt the <a href=\"#chunk\">chunks</a> before uploading them to PBS. Without the matching key, encrypted backup data cannot be read. ProxMenux stores the file at <code>/usr/local/share/proxmenux/pbs-key.conf</code> with mode <code>600</code>. Protect it: the <a href=\"#sobre-recuperacion\">recovery envelope</a> is designed to recover this file if it is lost."
|
||||
},
|
||||
{
|
||||
"id": "contrasena-keyfile",
|
||||
@@ -156,7 +156,7 @@
|
||||
{
|
||||
"id": "modo-adjunto",
|
||||
"term": "Attach mode",
|
||||
"def": "Scheduled job with no schedule of its own; it fires automatically whenever an existing PVE <code>vzdump</code> task runs. It inherits the schedule and retention from that parent task. Supported for Local and PBS destinations only."
|
||||
"def": "Job without its own timer. A PVE <code>vzdump</code> job-end hook triggers it after guest backups when the destination storage matches. The selected parent supplies the storage and the retention, which is re-read from the parent job on every run, but the hook matches storage rather than parent job ID; another task using that storage may also trigger it. Supported for Local and PBS only."
|
||||
},
|
||||
{
|
||||
"id": "timer-systemd",
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "One archive, three payloads",
|
||||
"body": "Every backup produces a directory layout with three well-defined payloads under a single staging root. The archive uploaded to the destination (local <code>.tar.zst</code>, PBS backup or Borg archive) contains this exact layout. The restore reads the three payloads independently, in a specific order that guarantees correctness: <strong>rootfs</strong> is copied first to lay down configuration, <strong>the manifest</strong> is consulted to detect drift and decide what to skip, and <strong>the application inventory</strong> drives the post-boot reinstall pass. No cross-payload dependencies — each one can be inspected or extracted independently."
|
||||
"body": "Every backup produces a directory layout with three well-defined payloads under a single staging root. The archive uploaded to the destination (local <code>.tar.zst</code>, PBS backup or Borg archive) contains this exact layout. The restore uses all three: <strong>the manifest</strong> is consulted before applying changes to detect drift and decide what to skip; <strong>rootfs</strong> supplies the configuration files, applied live or deferred until reboot; and <strong>the application inventory</strong> drives package installation and the post-boot component reinstall. Each payload can be inspected or extracted independently."
|
||||
},
|
||||
"layout": {
|
||||
"heading": "Archive layout",
|
||||
@@ -26,7 +26,7 @@
|
||||
"heading": "The rootfs payload",
|
||||
"intro": "The <code>rootfs/</code> tree is a <strong>plain filesystem copy</strong> produced by <code>rsync</code> from the source host. It contains a curated <strong>default profile</strong> of paths that matter for a Proxmox restore, plus any <strong>custom paths</strong> added by the user to the backup job or interactive session. The set is deliberately narrow: only paths that either <em>hold configuration</em> or <em>hold state that Proxmox cannot regenerate on its own</em>.",
|
||||
"defaultProfileTitle": "The default profile",
|
||||
"defaultProfileBody": "The default profile is defined by <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. It covers eight categories that together describe a working Proxmox host:",
|
||||
"defaultProfileBody": "The default profile is defined by <code>hb_default_profile_paths</code> in <code>lib_host_backup_common.sh</code>. It covers eight fixed categories, plus conditional ZFS state, that together describe a working Proxmox host:",
|
||||
"categoriesTitle": "Path categories",
|
||||
"categoryRows": [
|
||||
{
|
||||
@@ -125,7 +125,7 @@
|
||||
},
|
||||
"applications": {
|
||||
"heading": "The application inventory",
|
||||
"intro": "Two files under <code>metadata/</code> catalogue everything installed on the source that is not part of the base Proxmox VE package set. The restore uses them to reproduce the exact set of user-installed software on the target, using either APT or ProxMenux's own installers depending on how the software was originally installed.",
|
||||
"intro": "Two inventories catalogue the software installed on the source beyond the base Proxmox VE package set: the package list under <code>metadata/</code> and the component registry inside rootfs, detailed below. The restore uses them to reproduce user-installed software with APT or ProxMenux’s own installers, depending on how it was originally installed.",
|
||||
"packagesTitle": "packages.manual.list",
|
||||
"packagesBody": "A plain-text list produced by <code>apt-mark showmanual</code>: every APT package that was <em>explicitly installed</em> on the source host, sorted alphabetically. This excludes packages installed as dependencies of the base Proxmox VE ISO (they are re-pulled automatically by the target's own APT). Read by <code>_rs_run_complete_extras</code> during restore, filtered through a three-pass <em>cascade-safe</em> filter (<code>dpkg -s</code> for already-installed, sibling-major detection for library packages, <code>apt-get install --simulate</code> for cascade-remove risk), then installed with <code>apt-get install -y</code>.",
|
||||
"componentsTitle": "components_status.json (part of the rootfs)",
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "The restore reproduces the source, not just the files",
|
||||
"body": "Restoring a ProxMenux backup is not an extraction. Files are only the first step: after the filesystem is in place, the restore reads the manifest to detect differences between source and target, filters paths that would break the target's boot, hydrates user-authored tuning that cannot be copied verbatim, and — after the mandatory reboot — reinstalls every component the source had (NVIDIA driver, Coral TPU, GPU tools) against the target's own kernel. What the user picks from the menu is a single archive; what actually happens involves the compatibility check, the path classification, the on-boot dispatcher and the post-boot pass working together to produce a host that behaves like the source."
|
||||
"body": "Restoring a ProxMenux backup involves more than extracting files. Before applying changes, the restore reads the manifest to detect differences between source and target, filters paths that could break the target’s boot and adapts user-authored tuning that cannot be copied verbatim. After the required reboot, it attempts to reinstall the recorded supported components (NVIDIA driver, Coral TPU, GPU tools) for the target’s running kernel. A single selected archive drives the compatibility check, path classification, on-boot dispatcher and post-boot work. Review the per-component results and logs to confirm the outcome."
|
||||
},
|
||||
"threeActions": {
|
||||
"heading": "Three actions on a backup",
|
||||
@@ -52,7 +52,7 @@
|
||||
},
|
||||
{
|
||||
"output": "Rollback plan",
|
||||
"detail": "Computed by <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but not in the backup. The user opts in during the confirmation dialog to have these removed as part of the restore, so the target ends up matching the backup exactly."
|
||||
"detail": "Computed by <code>compute_rollback_plan.sh</code>. Lists VMs, LXCs and components present on the target but absent from the backup. The confirmation dialog offers optional removal of the extra guests before reboot. Component removal remains manual, and guest deletion can fail, so this does not guarantee an exact match with the backup."
|
||||
}
|
||||
],
|
||||
"reportBody": "The check also emits a structured report (<code>HB_COMPAT_RESULTS</code>) categorised as PASS / INFO / WARN / FAIL. WARN and FAIL entries surface in the pre-restore panel; the restore refuses to proceed only when a FAIL is present that the user cannot resolve by clicking Continue."
|
||||
@@ -81,11 +81,11 @@
|
||||
},
|
||||
{
|
||||
"class": "reboot",
|
||||
"detail": "Paths applied <strong>immediately</strong> as well, but whose actual effect only kicks in on the <strong>next boot</strong>: the kernel only reads <code>/etc/default/grub</code> when the bootloader starts, <code>/etc/fstab</code> when filesystems are mounted at boot, <code>/etc/modules</code> when modules are loaded, etc. The file is in place the moment it is applied but the system has to reboot to consume it. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
|
||||
"detail": "Paths deferred to the <strong>next boot</strong>, rather than applied <strong>immediately</strong> by this restore flow. They affect boot-time configuration: bootloader generation reads <code>/etc/default/grub</code>, filesystem mounting uses <code>/etc/fstab</code>, and module loading uses <code>/etc/modules</code>. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/modprobe.d</code>."
|
||||
},
|
||||
{
|
||||
"class": "dangerous",
|
||||
"detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount; writing directly to it bypasses it), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
|
||||
"detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set: <code>/etc/network</code> is written early in the next boot, before networking starts, and <code>/etc/pve</code> is written by the post-boot dispatcher once the cluster filesystem is up. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount holding active cluster configuration), <code>/var/lib/pve-cluster</code> (live cluster data, kept in the recovery directory for manual recovery only), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -131,7 +131,7 @@
|
||||
},
|
||||
{
|
||||
"task": "Component auto-reinstall",
|
||||
"detail": "Reads the restored <code>components_status.json</code> and iterates over the registered installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each installer runs in <code>--auto-reinstall</code> mode, reads its previously-recorded version from the state file, and rebuilds against the target's current kernel. The interactive flow does not do this — reinstalling drivers against a kernel that has not yet booted is meaningless."
|
||||
"detail": "Reads the restored <code>components_status.json</code> and iterates over the registered supported installers (nvidia_driver, coral_driver, amdgpu_top, intel_gpu_tools). Each selected installer runs in <code>--auto-reinstall</code> mode, reads its recorded state and reinstalls for the target’s environment, rebuilding kernel modules when applicable. This is deferred until after reboot so the installers use the kernel then running on the target. Individual failures are recorded and do not stop the next component."
|
||||
},
|
||||
{
|
||||
"task": "Boot sanity check",
|
||||
@@ -145,7 +145,7 @@
|
||||
},
|
||||
"liveProgress": {
|
||||
"heading": "Live progress in the Monitor's Backups tab",
|
||||
"body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>apply_cluster_postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
|
||||
"body": "After the reboot the Backups tab of ProxMenux Monitor renders a live post-restore card that reflects the state of <code>proxmenux-apply-cluster-postboot.service</code> as it runs. The card is driven by <code>/var/lib/proxmenux/restore-state.json</code>, which the dispatcher updates at every milestone (apply cluster config, rebuild initramfs, update bootloader, per-component reinstall, boot sanity check, finalize).",
|
||||
"fields": [
|
||||
{
|
||||
"name": "Status badge",
|
||||
@@ -184,9 +184,9 @@
|
||||
},
|
||||
"postbootExample": {
|
||||
"heading": "What the post-boot looks like on the console",
|
||||
"body": "On the host's physical console, a successful dispatcher run ends with a <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code> line. When that line appears — usually alongside the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code> — the restore is completely finished: components reinstalled, boot artifacts regenerated, cluster reconciled.",
|
||||
"body": "On the host’s physical console, a dispatcher run that exits successfully ends with <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>, often near the <code>OK</code>s for <code>multi-user.target</code> and <code>graphical.target</code>. This marks the end of the dispatcher process. Individual component failures or boot warnings can still have been recorded; check the Monitor’s component states and logs before treating the host as fully restored.",
|
||||
"imageAlt": "Proxmox physical console showing '[ OK ] Finished proxmenux-apply-cluster-postboot.service - ProxMenux Apply Cluster Configs (post-boot).' followed by the OK for multi-user.target and graphical.target, with the host login prompt above.",
|
||||
"imageCaption": "Physical console after a successful post-boot. The 'Finished proxmenux-apply-cluster-postboot.service' line is the signal that the restore flow is fully complete — the same event the 'Host restore finished' notification surfaces in the Monitor."
|
||||
"imageCaption": "Physical console after the dispatcher process finishes. 'Finished proxmenux-apply-cluster-postboot.service' marks process completion, also reported by 'Host restore finished' in the Monitor. Component results and warnings still need review."
|
||||
},
|
||||
"tenMinutes": {
|
||||
"heading": "Why the last ten minutes matter",
|
||||
@@ -228,11 +228,11 @@
|
||||
"detail": "Cheap. The user learns the run completed the moment the notification fires."
|
||||
}
|
||||
],
|
||||
"outroBody": "The window matters because the user can log in during this time and see missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected). This is expected — the reinstall is still running in the background. The completion notification signals when everything is ready."
|
||||
"outroBody": "During this window a login may show missing tools (<code>nvidia-smi</code> not found, <code>coral</code> not detected) because reinstall work is still running in the background. The completion notification marks the end of that work; check component results, warnings and logs to distinguish success from individual failures."
|
||||
},
|
||||
"destructiveRollback": {
|
||||
"heading": "The optional destructive rollback",
|
||||
"body": "A restore is additive by default: if the target has VMs, LXCs or components that are not in the backup, they survive. This preserves work but can leave stale hostpci entries, orphan components or VMs the user no longer wants. When drift is detected between target and backup, the confirmation dialog offers a second yes/no: <em>Execute destructive rollback?</em>. Accepting it triggers <code>_rs_execute_rollback</code>, which deletes the VMs, LXCs and components that exist on the target but not in the backup. The rollback runs BEFORE the reboot so that the pending restore machinery sees a clean state. This is opt-in — the default is No, and the user sees exactly what would be removed listed by name (VMID and CTID) before deciding."
|
||||
"body": "A restore is additive by default: extra VMs, LXCs and components on the target remain. When differences are detected, the confirmation dialog offers <em>Execute destructive rollback?</em>, defaulting to No. Accepting calls <code>_rs_execute_rollback</code> before reboot to attempt deletion of listed extra VMs and LXCs. Components are flagged for manual uninstall because automatic uninstall is not implemented. Guest deletion failures are reported and processing continues, so an exact match with the backup is not guaranteed. Review the listed names and VMIDs/CTIDs before choosing this destructive option."
|
||||
},
|
||||
"logs": {
|
||||
"heading": "Where the logs live",
|
||||
|
||||
@@ -22,7 +22,7 @@
|
||||
},
|
||||
"attachBadge": {
|
||||
"title": "Attach mode — recommended when a PVE vzdump task already exists",
|
||||
"body": "When a PVE vzdump backup task is already configured for the VMs and LXCs on this node, attaching the host backup to that task guarantees the host configuration is captured in the <strong>same window</strong> as the guests. On restore, the guest configs come from the host backup (they live under <code>/etc/pve</code>), and the guest disks come from the vzdump backup taken alongside — both sets are consistent with each other, so a full-node recovery can reproduce the host and re-attach every guest without version drift."
|
||||
"body": "When a PVE vzdump backup task is already configured for the VMs and LXCs on this node, attaching the host backup runs it after the guest backup job, in the <strong>same backup cycle</strong>. On restore, guest configurations come from the host backup (under <code>/etc/pve</code>) and guest disks come from the vzdump backups taken in that cycle. This helps coordinate a full-node recovery, but is not an atomic snapshot: changes made during the backup cycle can leave differences between host configuration and guest disk state."
|
||||
},
|
||||
"frequencyBadge": {
|
||||
"title": "Recommended frequency",
|
||||
@@ -31,29 +31,63 @@
|
||||
"modes": {
|
||||
"heading": "The two modes",
|
||||
"rows": [
|
||||
{ "mode": "New scheduled job", "backends": "Local, PBS, Borg", "schedule": "Own <code>OnCalendar</code> expression (systemd calendar syntax — e.g. <code>daily</code>, <code>Mon..Fri 03:00</code>).", "retention": "Prompted separately: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applied by the runner after each successful backup." },
|
||||
{ "mode": "Attach to a PVE vzdump job", "backends": "Local, PBS (Borg has no PVE-side scheduler)", "schedule": "Inherited from the parent PVE job. No systemd timer is installed on the ProxMenux side.", "retention": "Inherited from the parent's <code>prune-backups</code> configuration (mapped one-to-one to the runner's <code>KEEP_*</code> variables via <code>hb_pve_prune_to_keep_env</code>)." }
|
||||
{
|
||||
"mode": "New scheduled job",
|
||||
"backends": "Local, PBS, Borg",
|
||||
"schedule": "Own <code>OnCalendar</code> expression (systemd calendar syntax — e.g. <code>daily</code>, <code>Mon..Fri 03:00</code>).",
|
||||
"retention": "Prompted separately: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Applied by the runner after each successful backup."
|
||||
},
|
||||
{
|
||||
"mode": "Attach to a PVE vzdump job",
|
||||
"backends": "Local, PBS (Borg has no PVE-side scheduler)",
|
||||
"schedule": "Inherited from the parent PVE job. No systemd timer is installed on the ProxMenux side.",
|
||||
"retention": "Inherited from the parent's <code>prune-backups</code> configuration (mapped one-to-one to the runner's <code>KEEP_*</code> variables via <code>hb_pve_prune_to_keep_env</code>)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"attachDetail": {
|
||||
"heading": "How attach mode works",
|
||||
"intro": "PVE writes <code>vzdump</code> tasks to <code>/etc/pve/jobs.cfg</code> — one stanza per task, each pointing at a storage where the VM and LXC dumps land. Attach mode requires that storage to be a backend ProxMenux understands (Local or PBS); when the task fires, ProxMenux runs alongside it.",
|
||||
"intro": "PVE writes <code>vzdump</code> tasks to <code>/etc/pve/jobs.cfg</code> — one stanza per task, each pointing at a storage where the VM and LXC dumps land. Attach mode requires a backend ProxMenux understands (Local or PBS). The host backup runs from the job-end hook after the guest backup job finishes.",
|
||||
"steps": [
|
||||
{ "step": "1", "detail": "During job creation, ProxMenux lists compatible parent PVE tasks via <code>hb_pve_list_vzdump_jobs_for_backend</code>. The user picks one." },
|
||||
{ "step": "2", "detail": "The job's <code>.env</code> is written with <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> and the inherited <code>KEEP_*</code> values; no systemd timer is created." },
|
||||
{ "step": "3", "detail": "<code>hb_install_vzdump_hook</code> registers a script-hook in <code>/etc/vzdump.conf</code>. When PVE runs any vzdump task, the hook script fires; if the <code>$STOREID</code> passed to it matches an attached job's <code>PVE_STORAGE</code>, the runner is invoked for that job." },
|
||||
{ "step": "4", "detail": "The archive lands in the same storage the vzdump dumps just wrote to: <code>path/dump/</code> for Local, or the PBS repository configured on the PVE storage entry." }
|
||||
{
|
||||
"step": "1",
|
||||
"detail": "During job creation, ProxMenux lists compatible parent PVE tasks via <code>hb_pve_list_vzdump_jobs_for_backend</code>. The user picks one."
|
||||
},
|
||||
{
|
||||
"step": "2",
|
||||
"detail": "The job's <code>.env</code> is written with <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> and the inherited <code>KEEP_*</code> values; no systemd timer is created."
|
||||
},
|
||||
{
|
||||
"step": "3",
|
||||
"detail": "<code>hb_install_vzdump_hook</code> registers a script-hook in <code>/etc/vzdump.conf</code>. In the job-end phase of any vzdump task, it compares the supplied <code>$STOREID</code> with each enabled attached job’s <code>PVE_STORAGE</code> and invokes the runner for matching jobs. The match is by storage, not by the selected parent job ID."
|
||||
},
|
||||
{
|
||||
"step": "4",
|
||||
"detail": "The archive lands in the same storage the vzdump dumps just wrote to: <code>path/dump/</code> for Local, or the PBS repository configured on the PVE storage entry."
|
||||
}
|
||||
],
|
||||
"outroBody": "Attach mode has one operational implication: disabling or deleting the parent PVE task also disables the host backup — there is no timer of its own to fall back on. The job entry stays on disk so it can be re-attached later."
|
||||
"outroBody": "Attach mode has no timer of its own. Disabling or deleting the selected parent PVE task stops that task’s trigger, but another vzdump task using the same storage can still trigger the attached host backup. Disable or delete the ProxMenux job itself to prevent that. The job entry remains on disk when disabled and can be re-enabled or re-attached later."
|
||||
},
|
||||
"storageLayout": {
|
||||
"heading": "Files that make up a job",
|
||||
"intro": "Every scheduled job is fully described by three or four files on disk. Reading them gives the full configuration of the job without relying on the interface.",
|
||||
"rows": [
|
||||
{ "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env", "content": "Backend, backup ID or destination, schedule (New mode) or PVE parent (Attach mode), enabled flag, retention <code>KEEP_*</code> values, credentials pointers." },
|
||||
{ "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths", "content": "One absolute path per line — the frozen selection resolved from the profile at job-creation time. Editing the file re-runs the job with the new selection on the next timer fire." },
|
||||
{ "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service", "content": "New mode only. The service invokes <code>run_scheduled_backup.sh JOB_ID</code>. The timer schedules it with <code>Persistent=true</code> (missed fires run at next boot) and a small <code>RandomizedDelaySec=120</code> to spread load when multiple jobs share the same OnCalendar expression." },
|
||||
{ "path": "/etc/vzdump.conf script-hook", "content": "Attach mode only. Installed once by <code>hb_install_vzdump_hook</code>; matches every attached job's <code>PVE_STORAGE</code> against the <code>$STOREID</code> PVE passes to the hook script." }
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
|
||||
"content": "Backend, backup ID or destination, schedule (New mode) or PVE parent (Attach mode), enabled flag, retention <code>KEEP_*</code> values, credentials pointers."
|
||||
},
|
||||
{
|
||||
"path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
|
||||
"content": "One absolute path per line — the frozen selection resolved from the profile at job-creation time. Editing the file re-runs the job with the new selection on the next timer fire."
|
||||
},
|
||||
{
|
||||
"path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
|
||||
"content": "New mode only. The service invokes <code>run_scheduled_backup.sh JOB_ID</code>. The timer schedules it with <code>Persistent=true</code> (missed fires run at next boot) and a small <code>RandomizedDelaySec=120</code> to spread load when multiple jobs share the same OnCalendar expression."
|
||||
},
|
||||
{
|
||||
"path": "/etc/vzdump.conf script-hook",
|
||||
"content": "Attach mode only. Installed once by <code>hb_install_vzdump_hook</code>; matches every attached job's <code>PVE_STORAGE</code> against the <code>$STOREID</code> PVE passes to the hook script."
|
||||
}
|
||||
]
|
||||
},
|
||||
"runner": {
|
||||
@@ -69,11 +103,26 @@
|
||||
"heading": "Managing jobs",
|
||||
"intro": "The scheduler menu (Scripts TUI) and the Monitor Backups tab expose the same actions on any job.",
|
||||
"rows": [
|
||||
{ "action": "Run now", "detail": "Invokes the runner immediately, bypassing the timer / vzdump hook. Useful to verify a job configuration without waiting for the next scheduled fire." },
|
||||
{ "action": "Enable / Disable", "detail": "New mode: <code>systemctl enable/disable --now</code> the timer. Attach mode: flips the <code>ENABLED</code> flag in the job env — the hook script honours it on the next PVE fire." },
|
||||
{ "action": "Edit", "detail": "Reopens the destination, schedule, profile and retention prompts and rewrites the job files. Preserves the job ID." },
|
||||
{ "action": "Delete", "detail": "Removes the job env, paths file, systemd timer + service (New mode), and disables the hook binding (Attach mode). Does not touch archives already on the destination." },
|
||||
{ "action": "View log", "detail": "Streams <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — one log file per run. The runner also emits a compact status line to journald under the systemd service." }
|
||||
{
|
||||
"action": "Run now",
|
||||
"detail": "Invokes the runner immediately, bypassing the timer / vzdump hook. Useful to verify a job configuration without waiting for the next scheduled fire."
|
||||
},
|
||||
{
|
||||
"action": "Enable / Disable",
|
||||
"detail": "New mode: <code>systemctl enable/disable --now</code> the timer. Attach mode: flips the <code>ENABLED</code> flag in the job env — the hook script honours it on the next PVE fire."
|
||||
},
|
||||
{
|
||||
"action": "Edit",
|
||||
"detail": "Reopens the destination, schedule, profile and retention prompts and rewrites the job files. Preserves the job ID."
|
||||
},
|
||||
{
|
||||
"action": "Delete",
|
||||
"detail": "Removes the job env, paths file, systemd timer + service (New mode), and disables the hook binding (Attach mode). Does not touch archives already on the destination."
|
||||
},
|
||||
{
|
||||
"action": "View log",
|
||||
"detail": "Streams <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — one log file per run. The runner also emits a compact status line to journald under the systemd service."
|
||||
}
|
||||
]
|
||||
},
|
||||
"notifications": {
|
||||
@@ -83,9 +132,21 @@
|
||||
"whereNext": {
|
||||
"heading": "Where to go next",
|
||||
"items": [
|
||||
{ "label": "Creating backups", "href": "/docs/backup-restore/creating-backups", "tail": " — the interactive flow that shares the backend with the scheduler." },
|
||||
{ "label": "Destinations", "href": "/docs/backup-restore/destinations", "tail": " — per-backend configuration used by both the interactive flow and the scheduler." },
|
||||
{ "label": "Restoring", "href": "/docs/backup-restore/restoring", "tail": " — the flow that consumes what jobs produce." }
|
||||
{
|
||||
"label": "Creating backups",
|
||||
"href": "/docs/backup-restore/creating-backups",
|
||||
"tail": " — the interactive flow that shares the backend with the scheduler."
|
||||
},
|
||||
{
|
||||
"label": "Destinations",
|
||||
"href": "/docs/backup-restore/destinations",
|
||||
"tail": " — per-backend configuration used by both the interactive flow and the scheduler."
|
||||
},
|
||||
{
|
||||
"label": "Restoring",
|
||||
"href": "/docs/backup-restore/restoring",
|
||||
"tail": " — the flow that consumes what jobs produce."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
},
|
||||
"iommu": {
|
||||
"heading": "IOMMU groups — why the whole card leaves at once",
|
||||
"body": "PCI passthrough is done per <strong>IOMMU group</strong>, which is the smallest unit the CPU's IOMMU can isolate. Everything inside a group moves together. If your SATA controller shares its IOMMU group with the USB controller, passing the SATA card to a VM also takes the USB ports with it — often undesirable.",
|
||||
"body": "The isolation boundary for PCI passthrough is the <strong>IOMMU group</strong>, the smallest unit the CPU’s IOMMU can isolate. Devices in the same group cannot be isolated from each other. If a SATA controller shares its group with a USB controller, passing through SATA may also require releasing USB from the host, or may prevent passthrough. It does not automatically assign every device in the group to the VM.",
|
||||
"outro": "ProxMenux shows the IOMMU group next to each device and warns you when a group carries more than just the controller you want. You can still proceed if the extra devices in the group are acceptable (all disk controllers, for example), or back out if they are not."
|
||||
},
|
||||
"prereqs": {
|
||||
@@ -97,7 +97,7 @@
|
||||
"busyBody": "Another process still holds the PCI device. Most common causes: a previous VM that crashed without releasing it, or the host kernel reclaimed it on the last boot. Run <code>lspci -nnk -s <addr></code> to see which driver is bound; it should be <code>vfio-pci</code>. A full host reboot usually clears this.",
|
||||
"noDisksTitle": "Guest sees the controller but not the disks",
|
||||
"noDisksBody": "The controller model lacks an in-guest driver. Linux almost never hits this; Windows does — install the vendor driver (e.g. LSI / Broadcom for older SAS HBAs) while the card is detached, then reboot with the card attached.",
|
||||
"sharedTitle": "Shared IOMMU group also exports an unrelated device",
|
||||
"sharedTitle": "The IOMMU group includes an unrelated device",
|
||||
"sharedBody": "Options: (a) move the card to a different PCIe slot to change its group, (b) enable <em>ACS override</em> in the kernel to split groups (security trade-off — research before applying), or (c) pick a different card in a cleaner group."
|
||||
},
|
||||
"related": {
|
||||
|
||||
@@ -46,19 +46,19 @@
|
||||
"mode": "1. Wipe all",
|
||||
"part": "Destroyed",
|
||||
"data": "Signatures wiped",
|
||||
"useCase": "Starting fresh: everything on the disk goes, ready for a new layout."
|
||||
"useCase": "Removes the partition table and the filesystem and RAID metadata, zeroes the first and last 16 MiB and, on drives that support discard, trims the whole disk. The rest of the data is not overwritten and may still be recoverable on HDDs; this is not a secure erase."
|
||||
},
|
||||
{
|
||||
"mode": "2. Remove FS labels",
|
||||
"part": "Preserved",
|
||||
"data": "Preserved",
|
||||
"useCase": "Clears stale ZFS / LVM / RAID signatures so the disk stops being auto-claimed, without touching the data."
|
||||
"useCase": "Removes stale ZFS / LVM / RAID signatures so the disk is no longer auto-claimed. Bulk user data is not overwritten, but removing signatures can make it inaccessible."
|
||||
},
|
||||
{
|
||||
"mode": "3. Zero all data",
|
||||
"part": "Preserved",
|
||||
"data": "Destroyed (zeroed)",
|
||||
"useCase": "Sanitise before handing the disk over, keeping the existing partition layout."
|
||||
"useCase": "Overwrite the existing partitions with zeros while keeping the partition table. Unallocated space and SSD spare areas are not covered; this is not a complete device sanitization guarantee."
|
||||
},
|
||||
{
|
||||
"mode": "4. Full format",
|
||||
|
||||
@@ -52,7 +52,7 @@
|
||||
"intro": "For every selected image ProxMenux asks:",
|
||||
"items": [
|
||||
"<strong>Interface</strong> — <code>scsi</code> (default), <code>virtio</code>, <code>sata</code> or <code>ide</code>. Matches how the guest will see the disk.",
|
||||
"<strong>SSD emulation</strong> — only offered for non-VirtIO interfaces. Adds <code>ssd=1</code> so the guest advertises the disk as solid-state (useful for OS-level TRIM / alignment).",
|
||||
"<strong>SSD emulation</strong> — only offered for non-VirtIO interfaces. Adds <code>ssd=1</code> so the guest recognizes a solid-state disk. Discard/TRIM support must be configured separately.",
|
||||
"<strong>Bootable</strong> — if yes, ProxMenux adds the disk to the boot order so it becomes the primary boot device of the VM."
|
||||
]
|
||||
},
|
||||
@@ -73,7 +73,7 @@
|
||||
"noImagesTitle": "\"No compatible disk images found\"",
|
||||
"noImagesBody": "The script scanned the directory but found no <code>.img</code> / <code>.qcow2</code> / <code>.vmdk</code> / <code>.raw</code> file. Check the extension (case matters), that the file sits directly in the selected directory (no sub-directories are searched) and that permissions allow root to read it.",
|
||||
"slowTitle": "Import is slow",
|
||||
"slowBody": "VMDK → QCOW2 → raw conversions are CPU- and I/O-bound. Import speed depends on the source read speed, the target storage write speed and CPU for decompression. Prefer raw or qcow2 sources when possible.",
|
||||
"slowBody": "Conversions between VMDK, QCOW2 and raw can be limited by CPU and I/O. Import speed depends on source reads, target writes and any decompression work. Prefer raw or qcow2 sources when possible.",
|
||||
"uefiTitle": "Imported disk boots into UEFI shell",
|
||||
"uefiBody": "The image was built for legacy (SeaBIOS) but the VM uses OVMF (or vice versa). Either switch the VM's BIOS in Proxmox to match the image, or rebuild the image in the correct mode before importing."
|
||||
},
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
"At least one physical disk not in use by the host or any other guest."
|
||||
],
|
||||
"warnTitle": "Privileged container required",
|
||||
"warnBody": "Direct device passthrough to an LXC container only works if the container is <strong>privileged</strong>. If the script detects <code>unprivileged: 1</code> in the config it offers to convert it in place (edits <code>/etc/pve/lxc/<CTID>.conf</code>). Cancel if you cannot accept the security trade-off of a privileged container."
|
||||
"warnBody": "This script requires a <strong>privileged</strong> container for its direct disk attachment. If it detects <code>unprivileged: 1</code>, it offers to edit <code>/etc/pve/lxc/<CTID>.conf</code> in place. This changes the security model and does not remap existing file ownership. Back up the container and verify ownership before accepting, or rebuild it as privileged."
|
||||
},
|
||||
"steps": {
|
||||
"heading": "Step-by-step",
|
||||
@@ -83,9 +83,9 @@
|
||||
"troubleshoot": {
|
||||
"heading": "Troubleshooting",
|
||||
"unprivTitle": "\"Cannot continue with an unprivileged container\"",
|
||||
"unprivBody": "You declined the conversion offer. Either re-run and accept the conversion, or convert the container manually by editing <code>/etc/pve/lxc/<CTID>.conf</code> and replacing <code>unprivileged: 1</code> with <code>unprivileged: 0</code>. You can also rebuild the container as privileged if you prefer not to convert in place.",
|
||||
"unprivBody": "You declined the conversion, so the script stopped without changing anything. To continue, run it again and accept: the script stops the container, backs up its configuration to <code>/etc/pve/lxc/<CTID>.conf.bak</code> and replaces <code>unprivileged: 1</code> with <code>unprivileged: 0</code>. That flag change alone does not convert the UID/GID ownership of existing files, so back up the container and fix the ownership first; alternatively, restore or rebuild the container as privileged.",
|
||||
"permsTitle": "Permissions inside the container are wrong",
|
||||
"permsBody": "Mounts from the host into a privileged container land as <code>root:root</code>. If the service inside the CT runs as a different user (e.g. <code>www-data</code> for Nextcloud), <code>chown</code>/<code>chmod</code> inside the container to match its UID/GID after the first mount."
|
||||
"permsBody": "Existing file ownership is retained when a partition is mounted into a privileged container; a newly formatted filesystem is often owned by <code>root:root</code>. If the service runs as another user (e.g. <code>www-data</code> for Nextcloud), inspect its UID/GID and adjust the required files with <code>chown</code>/<code>chmod</code>. Changes also affect the underlying disk."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "What this does",
|
||||
"body": "This is a raw-disk passthrough: the guest OS sees the drive as a real block device (with its SMART data and native geometry). The disk is attached via its <code>/dev/disk/by-id/…</code> path — not <code>/dev/sdX</code> — so the assignment does not break if disk controllers enumerate devices in a different order on the next boot."
|
||||
"body": "This attaches a raw physical disk as the backing device for a virtual disk interface. The guest does not automatically receive native SMART data or the physical controller’s features; use controller PCI passthrough when those are required. The disk is attached through its <code>/dev/disk/by-id/…</code> path when one exists, so a changed device enumeration order at boot does not break the assignment; otherwise <code>/dev/sdX</code> is used."
|
||||
},
|
||||
"howRuns": {
|
||||
"heading": "How the script runs",
|
||||
@@ -49,7 +49,7 @@
|
||||
"items": [
|
||||
"<strong>SCSI</strong> — modern default for Linux and Windows with VirtIO-SCSI drivers installed.",
|
||||
"<strong>SATA</strong> — broad compatibility, works out of the box on virtually every guest.",
|
||||
"<strong>VirtIO</strong> — paravirtualised block device, fastest but requires guest drivers.",
|
||||
"<strong>VirtIO</strong> — efficient paravirtualised block device; requires guest drivers.",
|
||||
"<strong>IDE</strong> — for legacy guests that lack any of the above drivers."
|
||||
]
|
||||
},
|
||||
@@ -63,7 +63,7 @@
|
||||
"heading": "Manual equivalent",
|
||||
"body": "The script is a wrapper around <code>qm set</code>. The exact command for a single disk looks like this:",
|
||||
"migrationTitle": "Live migration is not possible",
|
||||
"migrationBody": "A VM with a passthrough disk is <strong>tied to the host that exposes that disk</strong>. Live migration to another Proxmox node will fail because the target node does not see the same <code>/dev/disk/by-id/…</code> path. Use replication or backup/restore instead, or pick virtual disks on shared storage if you need mobility.",
|
||||
"migrationBody": "A VM with a physical passthrough disk is <strong>tied to the host that exposes that disk</strong>. Another node normally lacks the same <code>/dev/disk/by-id/…</code> path and disk data. Back up and transfer that data separately, or use managed virtual disks on shared or supported replicated storage for mobility; do not assume Proxmox storage replication covers this device.",
|
||||
"shareTitle": "Do not share a physical disk between VMs",
|
||||
"shareBody": "Attaching the same physical disk to two VMs at the same time will corrupt data on next write. ProxMenux detects this situation and blocks it, but if you bypass the script (direct <code>qm set</code>), make sure only one guest ever mounts the disk."
|
||||
},
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Proxmox Disk Manager — Attach Disks to VMs / LXC, SMART Tests, Wipe | ProxMenux",
|
||||
"description": "Manage physical disks on a Proxmox VE host with ProxMenux: pass disks through to VMs or LXC containers (qm set scsi/sata/virtio, pct mp), import qcow2 / vmdk / vdi disk images, pass through whole HBAs or NVMe controllers, safely wipe disks and run SMART self-tests.",
|
||||
"description": "Manage physical disks on a Proxmox VE host with ProxMenux: attach disks to VMs or LXC containers (qm set scsi/sata/virtio, pct mp), import img / qcow2 / vmdk / raw disk images, pass through whole HBAs or NVMe controllers, wipe disks with safety checks and run SMART self-tests.",
|
||||
"ogTitle": "Proxmox Disk Manager — Attach Disks to VMs / LXC, SMART Tests, Wipe",
|
||||
"ogDescription": "Attach disks to VMs / LXC, import disk images, PCI passthrough for controllers, safe wipe and SMART tests on Proxmox VE.",
|
||||
"twitterTitle": "Proxmox Disk Manager | ProxMenux",
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "What this menu is for",
|
||||
"body": "Every option here operates on <strong>physical disks already visible to the Proxmox host</strong>. The menu is split in three groups — <strong>VM</strong> (attach disks or import images into a virtual machine), <strong>LXC</strong> (attach disks to a container), and <strong>Utilities</strong> (safe format, SMART health). Safety checks apply everywhere: system disks and disks already in use are hidden or blocked."
|
||||
"body": "These tools work with <strong>physical disks visible to the Proxmox host and image files stored on it</strong>. The menu has three groups: <strong>VM</strong> (attach disks or import images), <strong>LXC</strong> (attach disks to a container), and <strong>Utilities</strong> (formatting and SMART health). Attachment and wipe operations hide or block system disks and disks already in use; SMART checks can inspect those disks without wiping them."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Opening the menu",
|
||||
@@ -32,7 +32,7 @@
|
||||
"Add Controller or NVMe to VM"
|
||||
],
|
||||
"lxcTitle": "LXC",
|
||||
"lxcBody": "Tools that operate on existing containers. Direct device passthrough needs a privileged container; the script offers to convert it if necessary.",
|
||||
"lxcBody": "Tools for existing LXC containers. This script requires a privileged container and offers to change the flag when needed. Read the conversion and file-ownership cautions on the tool page first.",
|
||||
"lxcItems": [
|
||||
"Import Disk to LXC"
|
||||
],
|
||||
@@ -69,7 +69,7 @@
|
||||
},
|
||||
"lxc": {
|
||||
"heading": "LXC",
|
||||
"intro": "Tools that operate on existing LXC containers. Direct device passthrough requires a privileged container; the script offers to convert the container if needed.",
|
||||
"intro": "Tools for existing LXC containers. This script requires a privileged container and offers to change the flag when needed. Read the conversion and file-ownership cautions on the tool page first.",
|
||||
"options": [
|
||||
{
|
||||
"icon": "Boxes",
|
||||
@@ -98,8 +98,8 @@
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"title": "Safety rules shared by every option",
|
||||
"intro": "ProxMenux filters out anything that could harm the host:",
|
||||
"title": "Safety rules for disk attachment and wiping",
|
||||
"intro": "Attachment and wipe operations filter out devices that could harm the host:",
|
||||
"items": [
|
||||
"The <strong>system disk</strong> (root pool, swap, active ZFS / LVM / RAID members) is always hidden.",
|
||||
"Disks <strong>mounted</strong> anywhere on the host are hidden or blocked at execution.",
|
||||
|
||||
@@ -55,11 +55,11 @@
|
||||
}
|
||||
],
|
||||
"tipTitle": "Long tests survive terminal close",
|
||||
"tipBody": "A long test is queued <em>inside the drive</em> — it does not depend on the ProxMenux process staying alive. You can close the terminal, reboot the Proxmox host (the test picks up where it left off on some drives) or just come back later and use <strong>Check test progress</strong> to see the result."
|
||||
"tipBody": "A long test runs <em>inside the drive</em> and does not depend on the ProxMenux process staying alive. You can close the terminal and return later to <strong>Check test progress</strong>. A host reboot, controller reset or power loss may interrupt the test and its result collector; do not assume it will resume automatically."
|
||||
},
|
||||
"json": {
|
||||
"heading": "JSON export for the Monitor",
|
||||
"intro": "Every run writes a timestamped JSON file to <code>/usr/local/share/proxmenux/smart/<disk>/</code>. The structure is:",
|
||||
"intro": "Status, short-test and progress actions write a timestamped JSON file to <code>/usr/local/share/proxmenux/smart/<disk>/</code>; long-test results are collected in the background. The full-report action only displays its report. The structure is:",
|
||||
"outro": "The ProxMenux Monitor picks these up to render health trends per disk; old files are rotated out automatically once the retention limit is reached."
|
||||
},
|
||||
"steps": {
|
||||
@@ -89,7 +89,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Review results",
|
||||
"bodyRich": "Status and report are printed to the terminal and written to JSON. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
|
||||
"bodyRich": "Status, test and progress output is shown in the terminal; <strong>Full report</strong> opens in a scrollable dialog. JSON is exported for the actions described above, not for Full report. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
|
||||
"img": "/disk/smart/quick-status.png",
|
||||
"alt": "Quick health status output",
|
||||
"caption": "Quick health status output (SATA — smartctl -H + -A)"
|
||||
@@ -106,7 +106,7 @@
|
||||
"noSmartTitle": "\"Could not read SMART data from /dev/sdX\"",
|
||||
"noSmartBody": "The disk is probably behind a RAID / SAS controller that does not pass SMART through. With megaraid-based cards, try <code>smartctl -d megaraid,N /dev/sdX</code>. For HBAs in IT mode the direct invocation works.",
|
||||
"longTitle": "Long test never completes",
|
||||
"longBody": "The test is queued on the drive firmware and pauses if the disk is under heavy load. Running it overnight on an idle system usually works. You can also check <code>smartctl -c</code> to see percentage remaining; if it is stuck at a fixed LBA, the disk is failing at that sector."
|
||||
"longBody": "The drive runs the test in firmware, and heavy I/O can delay completion. Try an idle period such as overnight. For SATA, <code>smartctl -c</code> shows the remaining percentage, and for SAS, <code>smartctl -l selftest</code>; inspect the self-test log for completion status and any failing LBA. A reported read failure needs investigation; slow progress alone does not prove a bad sector."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
@@ -124,7 +124,7 @@
|
||||
{
|
||||
"href": "/docs/help-info/zfs-commands",
|
||||
"label": "ZFS Management commands",
|
||||
"tail": " — zpool scrub for the storage-layer equivalent of SMART tests."
|
||||
"tail": " — zpool scrub verifies ZFS data checksums and complements hardware SMART tests."
|
||||
},
|
||||
{
|
||||
"href": "/docs/monitor/dashboard/storage",
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Live monitoring tools",
|
||||
"description": "Three interactive launchers for real-time network observation and bandwidth measurement: iftop, iptraf-ng and iperf3. Each tool is auto-installed from apt on first use, runs in the foreground, and is exited with the documented keystroke. Read-only against the host configuration — they only observe traffic.",
|
||||
"description": "Three interactive launchers for real-time network observation and bandwidth measurement: iftop, iptraf-ng and iperf3. Each tool is auto-installed from apt on first use, runs in the foreground, and is exited with the documented keystroke. They do not change the host network configuration; iperf3 generates test traffic.",
|
||||
"section": "Network"
|
||||
},
|
||||
"intro": {
|
||||
|
||||
@@ -192,7 +192,7 @@
|
||||
"list": {
|
||||
"items": [
|
||||
"A Dockerfile without a published image: the image has to be built and published in an OCI registry first.",
|
||||
"A Compose file with several services: it is blocked because it describes more than one image. This option installs a single container.",
|
||||
"A Compose file with several services is blocked: this option installs one service in one container at a time, even when several services use the same image.",
|
||||
"<code>configs</code>, external secrets or device formats that cannot be translated unambiguously.",
|
||||
"Shell substitutions such as <code>$(command)</code>: the resulting value has to be written instead.",
|
||||
"<code>docker run</code> options that are not recognised, and <code>--env-file</code>: an explicit Compose file is read instead."
|
||||
|
||||
@@ -215,7 +215,7 @@
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Backup, restore and another host",
|
||||
"intro": "A backup made with vzdump or Proxmox Backup Server includes the container, its disks and the copy of its contract. What the installation keeps on the host is not part of it. <strong>Manage installed OCI applications</strong> detects the containers restored on a host that has no contract for them, a new Proxmox installation or another host, and offers to register them again.",
|
||||
"intro": "A backup made with vzdump or Proxmox Backup Server includes the container, the container disks selected for backup and the copy of its contract. What the installation keeps on the host is not part of it. <strong>Manage installed OCI applications</strong> detects the containers restored on a host that has no contract for them, a new Proxmox installation or another host, and offers to register them again.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
@@ -462,7 +462,7 @@
|
||||
],
|
||||
[
|
||||
"Container disks",
|
||||
"Proxmox moves them with the container. HA needs them on shared storage."
|
||||
"Proxmox moves them with the container. HA needs their data available on the target node, through shared storage or a supported replication setup."
|
||||
],
|
||||
[
|
||||
"Host directories and devices",
|
||||
|
||||
@@ -179,7 +179,7 @@
|
||||
["OCI rootfs", "Yes", "The CT backup; it can also be rebuilt from the image and the contract"],
|
||||
["Container disk with <code>backup=1</code>", "Yes", "The CT backup"],
|
||||
["Host directory", "No", "The backup of the host storage"],
|
||||
["Instance contract", "No", "<code>/usr/local/share/proxmenux/oci/instances/VMID/</code> on the host"],
|
||||
["Instance contract", "Yes, the copy carried inside the CT", "<code>/.proxmenux/oci-record.json</code> inside the CT; additional host and cluster copies are kept separately"],
|
||||
["Multi-container application", "Each member in its own backup", "The backups of every member, plus the stack contract and its bridge on the host"]
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Automated Post-Install Script | ProxMenux Documentation",
|
||||
"description": "The ProxMenux Automated post-install script applies a curated set of 14 safe, hardware-aware optimizations to a fresh Proxmox VE host with zero prompts. Reversible configuration changes are registered for later restoration.",
|
||||
"description": "The ProxMenux Automated post-install script runs a fixed set of 14 hardware-aware optimizations on a fresh Proxmox VE host. It has no feature-selection checklist, but the system update, banner removal, some Log2RAM installations and rebooting can ask for confirmation. Reversible configuration changes are registered for later restoration.",
|
||||
"ogTitle": "Automated Post-Install Script | ProxMenux Documentation",
|
||||
"ogDescription": "14 curated optimizations applied to a fresh Proxmox VE host with zero prompts. Hardware-aware, with reversible configuration changes tracked."
|
||||
"ogDescription": "14 fixed, hardware-aware optimizations for a fresh Proxmox VE host, with confirmations for some actions and reversible configuration changes tracked."
|
||||
},
|
||||
"header": {
|
||||
"title": "Automated Post-Install Script",
|
||||
"description": "One click, zero prompts — ProxMenux applies a curated set of 14 safe optimizations that almost every Proxmox host benefits from. Reversible configuration changes are registered for Uninstall Optimizations; package upgrades are not described as reversible.",
|
||||
"description": "ProxMenux runs a fixed set of 14 baseline optimizations without a feature-selection checklist. Some actions still ask for confirmation. Reversible configuration changes are registered for Uninstall Optimizations; package upgrades are not described as reversible.",
|
||||
"section": "Post-Install · Automated"
|
||||
},
|
||||
"intro": {
|
||||
@@ -43,7 +43,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "Skip language packages",
|
||||
"what": "Writes /etc/apt/apt.conf.d/99-disable-translations to stop downloading locale-specific packages. Faster, lighter apt updates.",
|
||||
"what": "Writes /etc/apt/apt.conf.d/99-disable-translations to stop downloading translated package-description indexes, reducing the data fetched by apt updates.",
|
||||
"category": "Basic Settings",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
@@ -97,7 +97,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "Logrotate tuning",
|
||||
"what": "Daily rotation with size cap 10M, 7 rotations, compression and copytruncate — Log2RAM-friendly.",
|
||||
"what": "Sets daily and then size 10M globally, keeps 7 rotations, enables compression and copytruncate. The later size criterion takes precedence; per-log rules may override it. Suitable for Log2RAM, but rotation frequency depends on the rules and timer.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
],
|
||||
"officialTitle": "The official Proxmox recommendation",
|
||||
"officialBody": "Proxmox's own upgrade guidance is to run, in this exact order:",
|
||||
"officialOutro": "That single line is all you need on any current Proxmox release. The challenge isn't the command itself — it's making sure the repositories on the host are sane <em>before</em> running it.",
|
||||
"officialOutro": "For routine updates within the installed Proxmox VE major version, this is the usual command. Check the host’s repositories and review the proposed package changes <em>before</em> proceeding. Upgrading to another major version requires the official migration procedure.",
|
||||
"doesTitle": "What the ProxMenux option does — verified against the script",
|
||||
"doesIntro": "The ProxMenux update wraps the exact apt commands above and adds a number of pre/post steps you would otherwise have to remember by hand. Every item below is what the dispatcher script actually does (see <link>Proxmox System Update</link> for the full breakdown):",
|
||||
"doesItems": [
|
||||
@@ -59,7 +59,7 @@
|
||||
},
|
||||
"languages": {
|
||||
"heading": "Skip downloading additional languages",
|
||||
"intro": "On every <code>apt update</code>, Debian by default pulls translation files for every locale it ships — a lot of traffic and disk space for something you'll rarely see. This option tells APT to only fetch the main metadata. Before disabling, ProxMenux <strong>makes sure the host's own locale is actually generated</strong> (reads <code>/etc/default/locale</code> or <code>/etc/environment</code>, appends to <code>/etc/locale.gen</code> if missing, and runs <code>locale-gen</code>). So you don't lose your shell locale as a side effect.",
|
||||
"intro": "During <code>apt update</code>, APT can download translated package descriptions as well as the main metadata. This option disables those translation downloads to save bandwidth and disk space. Before disabling them, ProxMenux <strong>makes sure the host’s own locale is actually generated</strong> (reads <code>/etc/default/locale</code> or <code>/etc/environment</code>, appends to <code>/etc/locale.gen</code> if missing, and runs <code>locale-gen</code>). So you do not lose your shell locale as a side effect.",
|
||||
"writtenTitle": "What gets written",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
"revertBody": "Deleting <code>/etc/apt/apt.conf.d/99-disable-translations</code> (either manually or from the Uninstall menu) restores the default behaviour and APT downloads language files again."
|
||||
|
||||
@@ -7,12 +7,12 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Customizable Post-Install Script",
|
||||
"description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~35 individual tools into 10 categories, each with its own checklist dialog. Same engine as Automated, but with full control over what gets applied.",
|
||||
"description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~35 individual tools into 10 categories in one checklist dialog. Same engine as Automated, but with full control over what gets applied.",
|
||||
"section": "Post-Install · Customizable"
|
||||
},
|
||||
"intro": {
|
||||
"title": "When to pick Customizable",
|
||||
"body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist per category so you can pre-select, deselect or mix-and-match optimizations. Items can be applied again later, and reversible configuration changes are tracked for <link>Uninstall Optimizations</link>. Package upgrades are not presented as reversible."
|
||||
"body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist grouped by category so you can pre-select, deselect or mix-and-match optimizations. Items can be applied again later, and reversible configuration changes are tracked for <link>Uninstall Optimizations</link>. Package upgrades are not presented as reversible."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "How it compares to Automated",
|
||||
@@ -20,7 +20,7 @@
|
||||
},
|
||||
"categoriesSection": {
|
||||
"heading": "The 10 categories",
|
||||
"body": "The Customizable script groups optimizations into 10 categories. Each category has its own checklist dialog and its own documentation page — open one of the cards below for the per-option rationale, defaults and verification steps."
|
||||
"body": "The Customizable script groups optimizations into 10 categories in one checklist dialog. Each category has its own documentation page — open one of the cards below for the per-option rationale, defaults and verification steps."
|
||||
},
|
||||
"categories": [
|
||||
{
|
||||
@@ -33,7 +33,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Virtualization",
|
||||
"description": "Prepare the host for advanced virtualization. Auto-installs the guest agent on templates and enables IOMMU/VFIO for PCI passthrough of GPUs, controllers and TPUs."
|
||||
"description": "Prepare the host for advanced virtualization. Installs a matching guest agent when Proxmox itself runs inside a supported VM, and enables IOMMU/VFIO for PCI passthrough of GPUs, controllers and TPUs."
|
||||
},
|
||||
{
|
||||
"name": "Network",
|
||||
@@ -53,7 +53,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Monitoring",
|
||||
"description": "Integrate the host with OVH Real-Time Monitoring. Only appears when ProxMenux detects an OVH server."
|
||||
"description": "Integrate the host with OVH Real-Time Monitoring. Installs RTM only when ProxMenux detects an OVH server; on other hosts the option makes no changes."
|
||||
},
|
||||
{
|
||||
"name": "Performance",
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
"breakTitle": "Can break after Proxmox updates",
|
||||
"breakBody": "Proxmox regularly ships UI updates that overwrite <code>proxmoxlib.js</code>. When that happens, the banner comes back. You can re-apply this option after every Proxmox update to re-patch the file, or just accept the nag until you reapply. ProxMenux also installs an APT hook that auto-re-patches on package upgrades — see <link>Uninstall Optimizations</link> for how that hook is reversed.",
|
||||
"legalTitle": "Legal note (always worth repeating)",
|
||||
"legalBody": "This option only hides the UI nag. It does <strong>not</strong> grant you enterprise support, access to the enterprise repository, or any rights to ship Proxmox commercially without a subscription. If you run Proxmox in a revenue-generating environment, buy a subscription — it supports the project and gets you the stable enterprise channel."
|
||||
"legalBody": "This option only hides the UI notice. It does <strong>not</strong> grant enterprise support or access to the enterprise repository, and it does not change the software license. Proxmox VE is released under the GNU AGPLv3. A subscription supports the project and provides access to the enterprise update channel; choose the appropriate support level for your environment."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Verification",
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Community scripts",
|
||||
"body": "The menu also exposes two third-party scripts from the <a>community-scripts</a> project: <em>Proxmox VE Post Install</em> and <em>Proxmox VE Microcode</em>. These are wrappers that <code>wget | bash</code> the original authors' scripts. They are not maintained by ProxMenux. See <link>External Repositories</link> for details and trust considerations before running them."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "On Proxmox Backup Server",
|
||||
"body": "On a Proxmox Backup Server host, the same menu opens from <strong>Settings post-install Proxmox</strong> in the PBS menu. Automated, Customizable, Apply Available Updates and Uninstall Optimizations work as on Proxmox VE, with these differences:",
|
||||
"items": [
|
||||
"<strong>Repositories and upgrade:</strong> when the server has no subscription and only the Enterprise PBS repository is active, ProxMenux asks before switching to the PBS no-subscription repository. The switch goes through the server's own repository API, the same one behind <em>Administration > Repositories</em>. With an active subscription, or with a no-subscription or test repository already configured, the sources stay as they are.",
|
||||
"<strong>Customizable list:</strong> the options that only apply to Proxmox VE are not listed: guest agent, VFIO IOMMU, Open vSwitch, vzdump backup speed, pigz, Appliance Manager, Ceph, High Availability and OVH Real Time Monitoring.",
|
||||
"<strong>Subscription banner:</strong> the patch applies to the Proxmox Backup Server web interface, and Uninstall Optimizations restores it.",
|
||||
"<strong>Figurine:</strong> installs without the Proxmox VE aliases.",
|
||||
"<strong>Community scripts:</strong> the section offers <em>Proxmox Backup Server Post Install</em> and <em>Proxmox Backup Server Microcode</em> in place of the Proxmox VE scripts."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
"items": [
|
||||
|
||||
@@ -30,8 +30,8 @@
|
||||
"verifyTitle": "Verification",
|
||||
"verifyBody": "On a real OVH host, after a reboot you should see the <a>RTM dashboard</a> in your OVH Manager populated with live data for the host. On the Proxmox side, the RTM collector is a systemd service — check it directly:",
|
||||
"troubleTitle": "Troubleshooting",
|
||||
"revertTitle": "Not reversible from the Uninstall menu",
|
||||
"revertBody": "There is no dedicated uninstall entry for RTM. On a real OVH host, remove the packages manually with <code>apt purge ovh-*</code> and delete any puppet manifests under <code>/etc/puppet/</code> that RTM installed. On a non-OVH host, nothing was ever installed, so there's nothing to revert."
|
||||
"revertTitle": "Remove RTM from the Uninstall menu",
|
||||
"revertBody": "When RTM is registered as installed, Uninstall Optimizations offers an OVH Real-Time Monitoring entry. It runs <code>apt-get purge -y ''ovh-rtm*'' ''rtm'' ''rtm-*''</code>, removes /etc/rtm, and marks RTM as uninstalled. Puppet artefacts may still need manual cleanup; review any RTM-specific manifests under <code>/etc/puppet/</code>. On a non-OVH host, no RTM packages were installed, so there is nothing to remove."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -74,7 +74,7 @@
|
||||
"impactTitle": "Impact is workload-dependent",
|
||||
"impactBody": "BBR shines on high-latency or lossy links (cross-continent replication, VPN tunnels, mobile clients). On a LAN between two machines on the same switch, the difference is often within noise. TFO helps short, repeated HTTP connections the most.",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
"revertBody": "BBR/TFO are tracked. <link>Uninstall Optimizations</link> removes the two sysctl files (<code>/etc/sysctl.d/99-tcp-bbr.conf</code> and <code>99-tcp-fastopen.conf</code>) and reloads sysctl so the kernel returns to <code>cubic</code> and <code>tcp_fastopen=1</code>. Manual equivalent:"
|
||||
"revertBody": "BBR/TFO are tracked. <link>Uninstall Optimizations</link> removes the two sysctl files (<code>/etc/sysctl.d/99-kernel-bbr.conf</code> and <code>99-tcp-fastopen.conf</code>) and reloads the remaining sysctl configuration. Removing a file does not itself reset its live kernel values. Defaults such as <code>cubic</code> and <code>tcp_fastopen=1</code> return after a reboot unless another configuration overrides them. Manual equivalent:"
|
||||
},
|
||||
"names": {
|
||||
"heading": "Interface Names (persistent)",
|
||||
@@ -83,13 +83,13 @@
|
||||
"whyItems": [
|
||||
"Adding or removing PCIe devices can shift the bus numbering, turning <code>enp3s0</code> into <code>enp4s0</code>. If your <code>/etc/network/interfaces</code> references the old name, the bridge vanishes on reboot.",
|
||||
"BIOS / firmware updates sometimes change how devices enumerate, with the same effect.",
|
||||
"LXC containers with <code>hotplug</code> NICs and bonded links can race on boot and end up named inconsistently. Pinning fixes that."
|
||||
"The helper writes <code>.link</code> files for physical NICs, including bond member ports, using the MAC currently reported in sysfs; for bond members this may be the bond’s shared MAC, so check their names after a reboot. It skips virtual interfaces such as LXC veth devices and the bond devices themselves; it does not fix naming races for virtual <code>hotplug</code> NICs."
|
||||
],
|
||||
"writtenTitle": "What gets written",
|
||||
"writtenIntro": "One file per physical NIC, at <code>/etc/systemd/network/10-proxmenux-<iface>.link</code>. Each file starts with the header <code># Managed by ProxMenux — do not edit</code> so ProxMenux can distinguish its own files from user- or package-provided <code>.link</code> files.",
|
||||
"writtenOutro": "<code>.link</code> files from other packages or hand-written by the user are left in place — only files carrying the ProxMenux header are managed. On re-run, the function reconciles its own set: it re-reads <code>MACAddress=</code> from every <code>10-proxmenux-*.link</code> and drops any whose MAC no longer appears under <code>/sys/class/net/</code>. Files written by an earlier ProxMenux release in the old <code>10-<iface>.link</code> format are migrated automatically the first time.",
|
||||
"pveTitle": "PVE 9 vs PVE 8",
|
||||
"pveBody": "On Proxmox VE 9 (<code>systemd-networkd</code> native), the script reloads udev rules after writing the <code>.link</code> files so new hotplug NICs pick up the correct name without a reboot. On PVE 8 (<code>ifupdown2</code>), interface naming is resolved at boot anyway — a reboot is required for the changes to take effect. The script sets the reboot flag either way so Customizable prompts you.",
|
||||
"pveBody": "The script uses systemd <code>.link</code> files for persistent names. On Proxmox VE 9 it also reloads udev rules after writing them, so a pinned NIC that is re-added or re-probed can pick up its rule without rebooting. Existing interfaces should be checked after a reboot on both PVE 8 and PVE 9. This does not switch the host away from <code>ifupdown2</code>. The script sets the reboot flag in either case so Customizable prompts you.",
|
||||
"reviewTitle": "Review existing /etc/network/interfaces first",
|
||||
"reviewBody": "If your host has legacy configuration in <code>/etc/network/interfaces</code> that references NIC names generated by the kernel's default scheme, pinning <em>today's</em> names is exactly what you want. But if you've already manually customised the config around specific names, double-check the pinning matches what the interfaces file expects before rebooting.",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
|
||||
@@ -133,7 +133,7 @@
|
||||
},
|
||||
"log2ram": {
|
||||
"title": "Install Log2RAM (SSD/NVMe wear reduction)",
|
||||
"intro": "Log2RAM mounts <code>/var/log</code> on a tmpfs ramdisk and periodically syncs the contents back to the underlying disk. On a hypervisor journald churn hits the root SSD every few seconds; moving the writes to RAM reduces wear and disk I/O without losing logs — the periodic sync flushes them to disk and a clean shutdown flushes them too.",
|
||||
"intro": "Log2RAM mounts <code>/var/log</code> on a tmpfs ramdisk and periodically syncs it to the underlying disk. Buffering frequent journald writes in RAM can reduce root SSD wear and disk I/O. Periodic sync and a clean shutdown save logs to disk, but an abrupt power loss can lose entries written since the last sync.",
|
||||
"upstreamLabel": "Upstream project:",
|
||||
"upstreamUrl": "https://github.com/azlux/log2ram",
|
||||
"upstreamLinkLabel": "azlux/log2ram on GitHub",
|
||||
@@ -149,7 +149,7 @@
|
||||
"Registers itself in <code>installed_tools.json</code> so it can be reverted from Uninstall Optimizations."
|
||||
],
|
||||
"howUseLabel": "How to use:",
|
||||
"howUseBody": "On the Automated flow Log2RAM applies unattended when an SSD/NVMe root is detected. On the Customizable flow the script prompts for size, sync interval and whether to enable the 90% auto-sync guard.",
|
||||
"howUseBody": "On the Automated flow Log2RAM installs unattended when an SSD/NVMe root is detected. The Customizable flow asks for size, sync interval and whether to enable the auto-sync guard. Its prompt currently says 90%, but the generated guard uses the 80% cleanup and 92% aggressive thresholds described above.",
|
||||
"verifyLabel": "Verify and manage from the shell:",
|
||||
"verifyCode": "# Service state and configured timers\nsystemctl status log2ram\nsystemctl list-timers log2ram*\n\n# Current ramdisk usage — /var/log IS the tmpfs itself\ndf -h /var/log\n\n# Force a sync now (tmpfs → disk); does NOT shrink the tmpfs\nlog2ram write\n\n# Trigger the auto-sync guard on demand (vacuum + sync when usage is high)\n/usr/local/bin/log2ram-check.sh\n\n# Current config: SIZE, mail settings, path\ncat /etc/log2ram.conf\n\n# ProxMenux-specific cron jobs\ncat /etc/cron.d/log2ram /etc/cron.d/log2ram-auto-sync\n\n# Recent Log2RAM activity\njournalctl -u log2ram -n 50 --no-pager"
|
||||
},
|
||||
@@ -172,6 +172,6 @@
|
||||
},
|
||||
"autoApplication": {
|
||||
"title": "Automatic Application",
|
||||
"body": "These optional features are applied only when specifically selected during the post-install process. Each feature can be individually chosen based on your specific needs and preferences."
|
||||
"body": "In the Customizable flow, select each optional feature according to your needs. Log2RAM is also part of the Automated flow with hardware detection; ZRAM remains Customizable-only. Review the individual sections for prompts and prerequisites."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
"heading": "Use pigz for faster gzip compression",
|
||||
"intro": "Standard <code>gzip</code> compresses data using a <strong>single CPU core</strong>. On modern Proxmox hosts with 8, 16 or 32 cores, that is a huge bottleneck during <code>vzdump</code> VM/CT backups, log rotation, and anything else that pipes through <code>gzip</code>. <a>pigz</a> is a drop-in parallel replacement: same gzip-compatible output, but it spreads the work across every core.",
|
||||
"doesTitle": "What ProxMenux does",
|
||||
"doesIntro": "Four steps, all idempotent:",
|
||||
"doesIntro": "Five steps, all idempotent:",
|
||||
"doesItems": [
|
||||
"Sets <code>pigz: 1</code> in <code>/etc/vzdump.conf</code> so Proxmox's backup tool uses pigz natively.",
|
||||
"Installs the <code>pigz</code> apt package if not already present.",
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user