mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +00:00
Merge remote-tracking branch 'origin/develop' into HEAD
# Conflicts: # web/messages/es/docs/backup-restore/cross-kernel.json # web/messages/es/docs/backup-restore/destinations/pbs.json
This commit is contained in:
MacRimi
@@ -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,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,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."
|
||||
}
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user