mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-01 10:22:08 +00:00
Merge remote-tracking branch 'origin/develop' into HEAD
This commit is contained in:
MacRimi
@@ -5,7 +5,12 @@ serves every published page under locale-prefixed URLs:
|
||||
|
||||
- `/en/<path>` — English, the source of truth
|
||||
- `/es/<path>` — Spanish
|
||||
- `/de/<path>` — German
|
||||
- `/fr/<path>` — French
|
||||
- `/it/<path>` — Italian
|
||||
- `/pt/<path>` — Portuguese
|
||||
- `/sk/<path>` — Slovak, with English fallback where needed
|
||||
- `/sv/<path>` — Swedish
|
||||
|
||||
We use [`next-intl`](https://next-intl.dev) for the i18n plumbing. Anyone
|
||||
can translate the docs without writing TypeScript: most of the work is
|
||||
@@ -148,6 +153,18 @@ Example:
|
||||
|
||||
### 4. Test locally
|
||||
|
||||
From the repository root, check the available catalogs without using a
|
||||
translation provider:
|
||||
|
||||
```bash
|
||||
python3 .github/scripts/check_web_docs_catalogs.py
|
||||
```
|
||||
|
||||
For a full locale-completion change, add `--require-complete` to also require
|
||||
every English file and leaf. This validates schema, placeholders, rich-text
|
||||
tags, literal code and rendering metadata; it does not replace linguistic
|
||||
review. Partial translations can continue to use the English fallback.
|
||||
|
||||
```bash
|
||||
cd web
|
||||
npm run dev
|
||||
@@ -311,7 +328,10 @@ registers a renderer for them.
|
||||
If you want to add a language that isn't in the project yet:
|
||||
|
||||
1. Create `messages/<locale>/common.json` and the page catalogs. The automated
|
||||
builder can provide the initial baseline.
|
||||
builder can provide the initial baseline when explicitly dispatched. It
|
||||
does not run on merge: changing English and its translations together must
|
||||
not trigger machine retranslation of the reviewed text. Offline validation
|
||||
still runs automatically for website changes.
|
||||
2. Review the shared navigation and a representative set of documentation
|
||||
pages with a native speaker.
|
||||
3. Add the locale code to `routing.ts` only when the locale is ready to be
|
||||
|
||||
@@ -24,23 +24,27 @@ export async function generateMetadata({ params }: { params: Promise<{ locale: s
|
||||
}
|
||||
}
|
||||
|
||||
async function getCodeOfConductContent(notFoundMsg: string, loadFailedMsg: string) {
|
||||
async function getCodeOfConductContent(notFoundMsg: string, loadFailedMsg: string, translatedMarkdown?: string) {
|
||||
try {
|
||||
const codeOfConductPath = path.join(process.cwd(), "..", "CODE_OF_CONDUCT.md")
|
||||
|
||||
if (!fs.existsSync(codeOfConductPath)) {
|
||||
if (!translatedMarkdown && !fs.existsSync(codeOfConductPath)) {
|
||||
console.error("CODE_OF_CONDUCT.md file not found.")
|
||||
return `<p class='text-red-600'>${notFoundMsg}</p>`
|
||||
}
|
||||
|
||||
const fileContents = fs.readFileSync(codeOfConductPath, "utf8")
|
||||
const fileContents = translatedMarkdown || fs.readFileSync(codeOfConductPath, "utf8")
|
||||
|
||||
const result = await remark()
|
||||
.use(gfm.default || gfm)
|
||||
.use(html)
|
||||
.process(fileContents)
|
||||
|
||||
return result.toString()
|
||||
// Repository-relative policy links otherwise resolve under the docs URL.
|
||||
return result.toString().replaceAll(
|
||||
'href="./SECURITY.md"',
|
||||
'href="https://github.com/MacRimi/ProxMenux/blob/main/SECURITY.md"',
|
||||
)
|
||||
} catch (error) {
|
||||
console.error("Error reading the CODE_OF_CONDUCT.md file", error)
|
||||
return `<p class='text-red-600'>${loadFailedMsg}</p>`
|
||||
@@ -71,7 +75,11 @@ export default async function CodeOfConductPage({ params }: { params: Promise<{
|
||||
const { locale } = await params
|
||||
setRequestLocale(locale)
|
||||
const t = await getTranslations({ locale, namespace: "docs.about.codeOfConduct" })
|
||||
const codeOfConductContent = await getCodeOfConductContent(t("errors.notFound"), t("errors.loadFailed"))
|
||||
const translatedMarkdown = t.has("contentMarkdown") ? t.raw("contentMarkdown") : undefined
|
||||
const codeOfConductContent = await getCodeOfConductContent(
|
||||
t("errors.notFound"), t("errors.loadFailed"),
|
||||
typeof translatedMarkdown === "string" ? translatedMarkdown : undefined,
|
||||
)
|
||||
const cleanedInlineCode = cleanInlineCode(codeOfConductContent)
|
||||
const parsedContent = wrapCodeBlocksWithCopyable(cleanedInlineCode)
|
||||
|
||||
|
||||
@@ -89,10 +89,12 @@ export default async function PostInstallPage({
|
||||
docs: { postInstall: {
|
||||
routes: Route[]
|
||||
related: { items: RelatedItem[] }
|
||||
pbs?: { items: string[] }
|
||||
} }
|
||||
}
|
||||
const routes = messages.docs.postInstall.routes
|
||||
const relatedItems = messages.docs.postInstall.related.items
|
||||
const pbsItems = messages.docs.postInstall.pbs?.items ?? []
|
||||
|
||||
const code = (chunks: React.ReactNode) => <code>{chunks}</code>
|
||||
const strong = (chunks: React.ReactNode) => <strong>{chunks}</strong>
|
||||
@@ -210,6 +212,14 @@ export default async function PostInstallPage({
|
||||
{t.rich("community.body", { em, code, a: communityAnchor, link: externalRepoLink })}
|
||||
</p>
|
||||
|
||||
<h2 className="text-2xl font-semibold mt-10 mb-4 text-gray-900">{t("pbs.heading")}</h2>
|
||||
<p className="mb-4 text-gray-800 leading-relaxed">{t.rich("pbs.body", { strong })}</p>
|
||||
<ul className="list-disc pl-6 mb-4 text-gray-800 leading-relaxed space-y-2">
|
||||
{pbsItems.map((_, i) => (
|
||||
<li key={i}>{t.rich(`pbs.items.${i}`, { strong, em })}</li>
|
||||
))}
|
||||
</ul>
|
||||
|
||||
<h2 className="text-2xl font-semibold mt-10 mb-4 text-gray-900">{t("related.heading")}</h2>
|
||||
<ul className="list-disc pl-6 text-gray-800 leading-relaxed space-y-1">
|
||||
{relatedItems.map((item) => (
|
||||
|
||||
+5
-4
@@ -8,13 +8,14 @@ const inter = Inter({ subsets: ["latin"] })
|
||||
* Minimal root layout — the localized layout under [locale]/ does the
|
||||
* real work (provider, navbar, etc.) but cannot own <html>/<body> tags
|
||||
* because Next.js requires those at the root level. Lang is set to the
|
||||
* default locale here and refined client-side from inside the locale
|
||||
* layout so the page still renders correctly with JS disabled (defaults
|
||||
* to English) and switches to the active locale once hydrated.
|
||||
* default locale here; scripts/localize-export.mjs sets the exported
|
||||
* document's language before search indexing, and LocaleHtmlSync keeps
|
||||
* it in sync during client navigation. The root-only hydration suppression
|
||||
* allows that intentional lang attribute change in the static export.
|
||||
*/
|
||||
export default function RootLayout({ children }: { children: React.ReactNode }) {
|
||||
return (
|
||||
<html lang="en" className="dark">
|
||||
<html lang="en" className="dark" suppressHydrationWarning>
|
||||
<body className={`${inter.className} bg-background text-foreground antialiased`}>
|
||||
{children}
|
||||
</body>
|
||||
|
||||
@@ -29,7 +29,12 @@ export function LanguageSwitcher() {
|
||||
const labels: Record<string, string> = {
|
||||
en: t("en"),
|
||||
es: t("es"),
|
||||
de: t("de"),
|
||||
fr: t("fr"),
|
||||
it: t("it"),
|
||||
pt: t("pt"),
|
||||
sk: t("sk"),
|
||||
sv: t("sv"),
|
||||
}
|
||||
|
||||
return (
|
||||
|
||||
+1
-1
@@ -19,7 +19,7 @@ import { defineRouting } from "next-intl/routing"
|
||||
* `CONTRIBUTING-TRANSLATIONS.md`.
|
||||
*/
|
||||
export const routing = defineRouting({
|
||||
locales: ["en", "es", "sk"],
|
||||
locales: ["en", "es", "de", "fr", "it", "pt", "sk", "sv"],
|
||||
defaultLocale: "en",
|
||||
localePrefix: "always",
|
||||
})
|
||||
|
||||
@@ -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."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -28,7 +28,12 @@
|
||||
"switcher": "Language",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina"
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
|
||||
@@ -8,5 +8,6 @@
|
||||
"errors": {
|
||||
"notFound": "Error: CODE_OF_CONDUCT.md file not found.",
|
||||
"loadFailed": "Error: Unable to load the Code of Conduct content."
|
||||
}
|
||||
},
|
||||
"contentMarkdown": "# 📝 Code of Conduct & Best Practices\n\nThis document defines the **principles and guidelines** for the use of **ProxMenux**, aiming to foster **respect, collaboration, and security** in development.\n\n## 📌 1. Code Attribution & Recognition\n\n- If **scripts, code snippets, or ideas** from other repositories or developers are used, the original author will always be credited. \n- A comment will be added in the code or documentation mentioning the source and linking to the original repository if possible. \n- When using code with a specific **license**, its terms must be respected. \n\n### ✅ Example of proper attribution in code:\n\n```bash\n# Script based on the work of [Author] at [Repository Link]\n```\n\n## 🔒 2. Security & Code Responsibility\n\n- All code in this repository follows secure development best practices.\n- Contributions introducing intentional vulnerabilities or unsafe practices are not allowed.\n- Scripts should never compromise system security or user data.\n- Before implementation, contributions should be reviewed to ensure security and stability.\n\n### ⚠️ Responsible Disclosure of Vulnerabilities\n\nIf you discover a security vulnerability, DO NOT report it in public Issues or forums.\n\nInstead, please report it privately via email:\n\n📧 proxmenux@macrimi.pro\n\nFor detailed information on security vulnerabilities and how to report them, please refer to our [Security Policy](./SECURITY.md).\n\n## 🤝 3. Community Guidelines\n\nTo maintain a respectful and professional environment, all users must follow these guidelines:\n\n- ✅ Be respectful and constructive in discussions.\n- ❌ No harassment, hate speech, or offensive behavior will be tolerated.\n- ✅ Provide feedback professionally, avoiding personal attacks.\n- ❌ Violating these guidelines may result in warnings or bans, depending on severity.\n\n\n##\n\nWith this document, we promote ethical code use, security awareness, and a respectful community.\n\n📢 Let's build something great, together!\n\n"
|
||||
}
|
||||
|
||||
@@ -45,7 +45,7 @@
|
||||
},
|
||||
"q4": {
|
||||
"question": "Can I customise ProxMenux?",
|
||||
"p1Rich": "The core scripts can't be modified directly because they're hosted on GitHub and refreshed by the auto-update flow. What you <em>can</em> customise:",
|
||||
"p1Rich": "Local changes to the core scripts can be overwritten by the update flow, so avoid editing those files directly. What you <em>can</em> customise:",
|
||||
"items": [
|
||||
"The console banner via the <strong>FastFetch</strong> tool in the Post-Install options.",
|
||||
"Which optional components are installed (Monitor, Fail2Ban, Lynis…) — pick during install or via the relevant menu later."
|
||||
@@ -63,15 +63,15 @@
|
||||
},
|
||||
"q7": {
|
||||
"question": "Can I contribute to ProxMenux?",
|
||||
"p1Rich": "<strong>Absolutely.</strong> ProxMenux is open source and collaborative. Contributions can be code (bash, Next.js / TypeScript, the translation Python venv), testing, documentation, design, or just ideas.",
|
||||
"p1Rich": "<strong>Absolutely.</strong> ProxMenux is open source and collaborative. Contributions can be code (Bash, Next.js/TypeScript and Python translation tools), testing, documentation, design, or just ideas.",
|
||||
"item1Rich": "Discuss ideas in <discusslink>GitHub Discussions</discusslink> before opening a feature request.",
|
||||
"item2Rich": "For PRs, read the <coclink>Code of Conduct & Best Practices</coclink> first.",
|
||||
"item3Rich": "See the <contriblink>Contributors page</contriblink> for current testers and reviewers."
|
||||
},
|
||||
"q8": {
|
||||
"question": "Does ProxMenux modify critical system files?",
|
||||
"p1Rich": "<strong>No.</strong> ProxMenux installs:",
|
||||
"item1Rich": "Dependencies via apt: <code>dialog</code>, <code>curl</code>, <code>jq</code>, <code>git</code> (and <code>python3</code> + <code>googletrans</code> on the Translation install).",
|
||||
"p1Rich": "<strong>Installing ProxMenux adds the following components.</strong>",
|
||||
"item1Rich": "Dependencies via apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> and <code>git</code>. Translations use pre-built JSON catalogs; the installer does not add a translation virtualenv to the host.",
|
||||
"item2Rich": "The script tree at <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "The launcher at <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "Optional: the Monitor systemd service at <code>proxmenux-monitor.service</code>.",
|
||||
@@ -83,12 +83,12 @@
|
||||
},
|
||||
"q10": {
|
||||
"question": "How do I uninstall ProxMenux?",
|
||||
"p1Rich": "From inside ProxMenux: <strong>Settings → Uninstall ProxMenux</strong>. The uninstaller removes the script tree, the launcher and the Monitor service, optionally removes selected dependencies, and restores <code>/root/.bashrc</code> and <code>/etc/motd</code> backups taken at install time.",
|
||||
"p1Rich": "From inside ProxMenux: <strong>Settings → Uninstall ProxMenux</strong>. The uninstaller removes the script tree, the launcher and the Monitor service, optionally removes selected dependencies, and restores <code>/root/.bashrc</code> and <code>/etc/motd</code> from install-time backups if those backups exist.",
|
||||
"p2Rich": "Full step-by-step: <uninstalllink>Uninstall ProxMenux</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal flags the install URL — is it safe?",
|
||||
"p1Rich": "A 1/95 detection by heuristic engines (e.g. <em>Chong Lua Dao</em>) is a known false positive. The installer uses the standard <code>curl | bash</code> pattern and downloads legitimate binaries (like <code>jq</code> from its official GitHub release), which aggressive scanners flag based on <em>behaviour</em> rather than actual malicious code.",
|
||||
"p1Rich": "The 1/95 result reported in Issue #162, from <em>Chong Lua Dao</em>, was identified by the maintainer as a false positive. The installer uses the <code>curl | bash</code> pattern and can download <code>jq</code> from its official GitHub release. Such <em>behaviour</em> can trigger heuristic scanners; the historical report is not a verdict on every future download.",
|
||||
"p2Rich": "ProxMenux is 100% open source and the install script is reviewable line by line: <scriptlink>install_proxmenux.sh</scriptlink>. More context in <issuelink>Issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Live monitoring tools",
|
||||
"description": "Three interactive launchers for real-time network observation and bandwidth measurement: iftop, iptraf-ng and iperf3. Each tool is auto-installed from apt on first use, runs in the foreground, and is exited with the documented keystroke. Read-only against the host configuration — they only observe traffic.",
|
||||
"description": "Three interactive launchers for real-time network observation and bandwidth measurement: iftop, iptraf-ng and iperf3. Each tool is auto-installed from apt on first use, runs in the foreground, and is exited with the documented keystroke. They do not change the host network configuration; iperf3 generates test traffic.",
|
||||
"section": "Network"
|
||||
},
|
||||
"intro": {
|
||||
|
||||
@@ -192,7 +192,7 @@
|
||||
"list": {
|
||||
"items": [
|
||||
"A Dockerfile without a published image: the image has to be built and published in an OCI registry first.",
|
||||
"A Compose file with several services: it is blocked because it describes more than one image. This option installs a single container.",
|
||||
"A Compose file with several services is blocked: this option installs one service in one container at a time, even when several services use the same image.",
|
||||
"<code>configs</code>, external secrets or device formats that cannot be translated unambiguously.",
|
||||
"Shell substitutions such as <code>$(command)</code>: the resulting value has to be written instead.",
|
||||
"<code>docker run</code> options that are not recognised, and <code>--env-file</code>: an explicit Compose file is read instead."
|
||||
|
||||
@@ -215,7 +215,7 @@
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Backup, restore and another host",
|
||||
"intro": "A backup made with vzdump or Proxmox Backup Server includes the container, its disks and the copy of its contract. What the installation keeps on the host is not part of it. <strong>Manage installed OCI applications</strong> detects the containers restored on a host that has no contract for them, a new Proxmox installation or another host, and offers to register them again.",
|
||||
"intro": "A backup made with vzdump or Proxmox Backup Server includes the container, the container disks selected for backup and the copy of its contract. What the installation keeps on the host is not part of it. <strong>Manage installed OCI applications</strong> detects the containers restored on a host that has no contract for them, a new Proxmox installation or another host, and offers to register them again.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
@@ -462,7 +462,7 @@
|
||||
],
|
||||
[
|
||||
"Container disks",
|
||||
"Proxmox moves them with the container. HA needs them on shared storage."
|
||||
"Proxmox moves them with the container. HA needs their data available on the target node, through shared storage or a supported replication setup."
|
||||
],
|
||||
[
|
||||
"Host directories and devices",
|
||||
|
||||
@@ -179,7 +179,7 @@
|
||||
["OCI rootfs", "Yes", "The CT backup; it can also be rebuilt from the image and the contract"],
|
||||
["Container disk with <code>backup=1</code>", "Yes", "The CT backup"],
|
||||
["Host directory", "No", "The backup of the host storage"],
|
||||
["Instance contract", "No", "<code>/usr/local/share/proxmenux/oci/instances/VMID/</code> on the host"],
|
||||
["Instance contract", "Yes, the copy carried inside the CT", "<code>/.proxmenux/oci-record.json</code> inside the CT; additional host and cluster copies are kept separately"],
|
||||
["Multi-container application", "Each member in its own backup", "The backups of every member, plus the stack contract and its bridge on the host"]
|
||||
]
|
||||
}
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Community scripts",
|
||||
"body": "The menu also exposes two third-party scripts from the <a>community-scripts</a> project: <em>Proxmox VE Post Install</em> and <em>Proxmox VE Microcode</em>. These are wrappers that <code>wget | bash</code> the original authors' scripts. They are not maintained by ProxMenux. See <link>External Repositories</link> for details and trust considerations before running them."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "On Proxmox Backup Server",
|
||||
"body": "On a Proxmox Backup Server host, the same menu opens from <strong>Settings post-install Proxmox</strong> in the PBS menu. Automated, Customizable, Apply Available Updates and Uninstall Optimizations work as on Proxmox VE, with these differences:",
|
||||
"items": [
|
||||
"<strong>Repositories and upgrade:</strong> when the server has no subscription and only the Enterprise PBS repository is active, ProxMenux asks before switching to the PBS no-subscription repository. The switch goes through the server's own repository API, the same one behind <em>Administration > Repositories</em>. With an active subscription, or with a no-subscription or test repository already configured, the sources stay as they are.",
|
||||
"<strong>Customizable list:</strong> the options that only apply to Proxmox VE are not listed: guest agent, VFIO IOMMU, Open vSwitch, vzdump backup speed, pigz, Appliance Manager, Ceph, High Availability and OVH Real Time Monitoring.",
|
||||
"<strong>Subscription banner:</strong> the patch applies to the Proxmox Backup Server web interface, and Uninstall Optimizations restores it.",
|
||||
"<strong>Figurine:</strong> installs without the Proxmox VE aliases.",
|
||||
"<strong>Community scripts:</strong> the section offers <em>Proxmox Backup Server Post Install</em> and <em>Proxmox Backup Server Microcode</em> in place of the Proxmox VE scripts."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
"items": [
|
||||
|
||||
@@ -91,7 +91,7 @@
|
||||
},
|
||||
"hardening": {
|
||||
"heading": "SSH hardening: MaxAuthTries",
|
||||
"intro": "Lynis control <strong>SSH-7408</strong> recommends <code>MaxAuthTries 3</code> in <code>sshd_config</code>. With Fail2Ban's <code>maxretry = 2</code> on the SSH jail, a malicious client never reaches three attempts anyway — but the explicit setting satisfies the audit and adds defence in depth (e.g. if Fail2Ban is stopped for maintenance).",
|
||||
"intro": "Lynis control <strong>SSH-7408</strong> recommends <code>MaxAuthTries 3</code> in <code>sshd_config</code>. The SSH jail uses <code>maxretry = 2</code> to trigger a ban after repeated failures, while MaxAuthTries limits attempts within a connection. The explicit SSH setting adds defence in depth, including when Fail2Ban is stopped for maintenance.",
|
||||
"installerIntro": "The installer:",
|
||||
"items": [
|
||||
"Reads the current <code>MaxAuthTries</code> value (or defaults to 6 if absent).",
|
||||
@@ -125,7 +125,7 @@
|
||||
"troubleshoot": {
|
||||
"heading": "Troubleshooting",
|
||||
"neverBansTitle": "Fail2Ban runs but never bans anything",
|
||||
"neverBansBody": "Check the auth log files actually receive entries: <code>tail -f /var/log/ssh-auth.log</code> and try a wrong-password SSH attempt from a different machine. If the log stays empty, the logger service is not running: <code>systemctl status ssh-auth-logger.service</code>. If it's active but the log is empty, check that the journald drop-in took effect: <code>journalctl --dump-catalog | head</code> — events at <em>info</em> level should be visible.",
|
||||
"neverBansBody": "Check that <code>tail -f /var/log/ssh-auth.log</code> receives an entry after a wrong-password SSH attempt from another machine. If it stays empty, inspect <code>systemctl status ssh-auth-logger.service</code>. If the logger is active, inspect recent SSH events with <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> and check whether the journald drop-in permits the <em>info</em> level.",
|
||||
"monitorEmptyTitle": "ProxMenux Monitor jail has no entries even after failed logins",
|
||||
"monitorEmptyBody": "The <code>[proxmenux]</code> jail reads <code>/var/log/proxmenux-auth.log</code>, which is written by the ProxMenux Monitor Flask app — not by a journald logger. If you don't run the Monitor, the file stays empty and the jail never fires. That's expected; the jail config is harmless. If you do run the Monitor and the log is empty, check the Flask logging config.",
|
||||
"selfBanTitle": "I banned myself",
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
"items": [
|
||||
"Auto-detected — no path to type",
|
||||
"Picks the ACME-uploaded cert if present, falls back to the self-signed default",
|
||||
"Renewal happens through Proxmox; the Monitor follows automatically on next start"
|
||||
"Proxmox handles renewal; the Monitor validates and loads it on the next new TLS connection"
|
||||
]
|
||||
},
|
||||
"custom": {
|
||||
@@ -143,7 +143,7 @@
|
||||
},
|
||||
"trustCa": {
|
||||
"heading": "Trust the Proxmox self-signed CA",
|
||||
"intro1Rich": "If you prefer to keep the default Proxmox-generated certificate (no ACME), you can stop the browser warning by importing the cluster's root CA into the OS or browser trust store. The Monitor will keep auto-detecting the same <code>/etc/pve/local/pveproxy-ssl.pem</code>; the only thing that changes is that the device viewing the dashboard now recognises the issuer.",
|
||||
"intro1Rich": "To keep the default Proxmox-generated certificate without ACME, import the cluster root CA into the OS or browser trust store. The Monitor detects <code>/etc/pve/local/pve-ssl.pem</code> as the fallback certificate. This makes the client trust its issuer; the URL must still match a name in the certificate.",
|
||||
"intro2Rich": "The CA file lives at <code>/etc/pve/pve-root-ca.pem</code> on every node. In a cluster the path is on the shared <code>pmxcfs</code> filesystem so all nodes share the same root, and a single import covers the whole datacenter. Copy it to your machine:",
|
||||
"code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
|
||||
"thenImport": "Then import it on the client side:",
|
||||
|
||||
@@ -28,7 +28,12 @@
|
||||
"switcher": "Idioma",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina"
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
|
||||
@@ -1,12 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Código de conducta | ProxMenux Documentation",
|
||||
"title": "Código de conducta | Documentación de ProxMenux",
|
||||
"description": "Código de conducta y buenas prácticas de ProxMenux para colaboradores, testers y usuarios.",
|
||||
"ogTitle": "Código de conducta | ProxMenux Documentation",
|
||||
"ogTitle": "Código de conducta | Documentación de ProxMenux",
|
||||
"ogDescription": "Expectativas sobre responsabilidad del código, divulgación de problemas de seguridad y alcance de los PRs para el proyecto ProxMenux."
|
||||
},
|
||||
"errors": {
|
||||
"notFound": "Error: archivo CODE_OF_CONDUCT.md no encontrado.",
|
||||
"loadFailed": "Error: no se pudo cargar el contenido del código de conducta."
|
||||
}
|
||||
},
|
||||
"contentMarkdown": "# 📝 Código de conducta y buenas prácticas\n\nEste documento define los **principios y las pautas** de uso de **ProxMenux** para promover el **respeto, la colaboración y la seguridad** durante el desarrollo.\n\n## 📌 1. Autoría del código y reconocimiento\n\n- Si se utilizan **scripts, fragmentos de código o ideas** de otros repositorios o desarrolladores, se reconocerá siempre la autoría original.\n- Se añadirá un comentario en el código o la documentación que indique la fuente y, si es posible, enlace al repositorio original.\n- Al utilizar código con una **licencia** concreta, se deben respetar sus condiciones.\n\n### ✅ Ejemplo de reconocimiento de autoría en el código:\n\n```bash\n# Script basado en el trabajo de [Autor] en [Enlace al repositorio]\n```\n\n## 🔒 2. Seguridad y responsabilidad del código\n\n- Todo el código de este repositorio sigue las buenas prácticas de desarrollo seguro.\n- No se permiten contribuciones que introduzcan vulnerabilidades intencionadas o prácticas inseguras.\n- Los scripts nunca deben comprometer la seguridad del sistema ni los datos de los usuarios.\n- Las contribuciones deben revisarse antes de implementarlas para comprobar su seguridad y estabilidad.\n\n### ⚠️ Divulgación responsable de vulnerabilidades\n\nSi descubres una vulnerabilidad de seguridad, NO la notifiques en incidencias o foros públicos.\n\nComunícala en privado por correo electrónico:\n\n📧 proxmenux@macrimi.pro\n\nPara más información sobre las vulnerabilidades y cómo notificarlas, consulta nuestra [política de seguridad](./SECURITY.md).\n\n## 🤝 3. Normas de la comunidad\n\nPara mantener un entorno respetuoso y profesional, todos los usuarios deben seguir estas pautas:\n\n- ✅ Sé respetuoso y constructivo en las discusiones.\n- ❌ No se tolerarán el acoso, el discurso de odio ni las conductas ofensivas.\n- ✅ Aporta comentarios de forma profesional, sin ataques personales.\n- ❌ El incumplimiento puede dar lugar a advertencias o expulsiones, según la gravedad.\n\n##\n\nEste documento promueve un uso ético del código, la conciencia de seguridad y una comunidad respetuosa.\n\n📢 ¡Construyamos algo grande juntos!\n"
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Contribuir a ProxMenux | ProxMenux Documentation",
|
||||
"title": "Contribuir a ProxMenux | Documentación de ProxMenux",
|
||||
"description": "Cómo contribuir a ProxMenux — modelo de ramas (main / develop / feature/*), flujo de pull requests, plantilla de cabecera de script con atribución de autor y enlace opcional de patrocinio, política de diseño UI en dos fases, funciones de mensajes y el camino desde una rama de función hasta un release estable.",
|
||||
"ogTitle": "Contribuir a ProxMenux",
|
||||
"ogDescription": "Modelo de ramas, flujo de trabajo, atribución en la cabecera del script y política de diseño UI en dos fases que los colaboradores deben seguir."
|
||||
@@ -129,7 +129,7 @@
|
||||
"intro": "Todas definidas en <code>utils.sh</code>. Úsalas como el valor por defecto para cualquier salida visible para el usuario — visuales coherentes entre scripts es la idea. Si tu script necesita una función nueva que no encaja en el conjunto existente (un nuevo nivel de severidad, un nuevo helper de layout, etc.), propónla en tu Pull Request — se revisará y se añadirá a <code>utils.sh</code> si es útil de forma amplia.",
|
||||
"headerFunction": "Función",
|
||||
"headerWhen": "Cuándo usar",
|
||||
"headerSpinner": "Spinner",
|
||||
"headerSpinner": "Indicador de progreso",
|
||||
"rows": [
|
||||
{
|
||||
"function": "msg_info \"text\"",
|
||||
@@ -163,7 +163,7 @@
|
||||
},
|
||||
{
|
||||
"function": "msg_success \"text\"",
|
||||
"whenRich": "Prompt final \"Press Enter to return\" al final de la fase 2.",
|
||||
"whenRich": "Mensaje final «Press Enter to return» al terminar la fase 2.",
|
||||
"spinner": "Para"
|
||||
},
|
||||
{
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Colaboradores | ProxMenux Documentation",
|
||||
"description": "Reconocimiento a las personas que hacen posible ProxMenux — testers, revisores y desarrolladores que dan forma a cada release.",
|
||||
"ogTitle": "Colaboradores | ProxMenux Documentation",
|
||||
"title": "Colaboradores | Documentación de ProxMenux",
|
||||
"description": "Reconocimiento a las personas que hacen posible ProxMenux: quienes prueban, revisan y desarrollan cada versión.",
|
||||
"ogTitle": "Colaboradores | Documentación de ProxMenux",
|
||||
"ogDescription": "Conoce a los colaboradores detrás de ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Colaboradores",
|
||||
"description": "El proyecto ProxMenux crece y prospera gracias a la contribución de sus colaboradores. Este es el merecido reconocimiento a su trabajo — probando builds antes del release, cazando regresiones, revisando PRs y dando forma a la dirección de las nuevas funciones.",
|
||||
"description": "ProxMenux crece gracias a sus colaboradores. Esta página reconoce su trabajo: probar versiones antes de publicarlas, detectar regresiones, revisar PR y ayudar a orientar las nuevas funciones.",
|
||||
"section": "Acerca de"
|
||||
},
|
||||
"beyond": {
|
||||
"title": "Más allá de esta lista",
|
||||
"body": "Mucha más gente contribuye vía reportes de bugs, ideas de funciones en Discussions, pruebas beta y traducciones. La lista completa de colaboradores de código vive en el <extlink>grafo de colaboradores de GitHub</extlink>. La página de abajo destaca a las personas que han estado más activamente involucradas en probar y revisar releases de ProxMenux."
|
||||
"body": "Muchas más personas contribuyen notificando errores, proponiendo funciones en Discussions, probando versiones beta y traduciendo el proyecto. La lista completa de colaboradores del código está en el <extlink>gráfico de colaboradores de GitHub</extlink>. Esta página destaca a quienes participan más activamente en las pruebas y la revisión de las versiones de ProxMenux."
|
||||
},
|
||||
"testers": {
|
||||
"heading": "Testers y revisores",
|
||||
"intro": "Estas personas fueron de las primeras en contribuir al proyecto, probando, reportando incidencias y proponiendo mejoras que ayudaron a que ProxMenux haya crecido hasta convertirse en lo que es hoy.",
|
||||
"heading": "Pruebas y revisión",
|
||||
"intro": "Estas personas estuvieron entre las primeras en contribuir al proyecto. Sus pruebas, avisos de errores y propuestas de mejora ayudaron a convertir ProxMenux en lo que es hoy.",
|
||||
"roles": {
|
||||
"testing": "Pruebas",
|
||||
"testingReviewer": "Pruebas y revisor"
|
||||
"testingReviewer": "Pruebas y revisión"
|
||||
},
|
||||
"youtube": "YouTube"
|
||||
},
|
||||
"contribute": {
|
||||
"heading": "¿Quieres colaborar?",
|
||||
"intro": "Cualquier contribución es bienvenida — código, pruebas, diseño, documentación o simplemente compartir tus ideas:",
|
||||
"tester": "<strong>Tester</strong> — prueba el <beta>canal beta</beta> y reporta qué funciona y qué no antes de los releases estables.",
|
||||
"tester": "<strong>Pruebas</strong>: prueba el <beta>canal beta</beta> y comunica qué funciona y qué no antes de que se publiquen las versiones estables.",
|
||||
"developer": "<strong>Desarrollador</strong> — Bash + Next.js (TypeScript) + un poco de Python para el venv de traducción. Los PRs son bienvenidos en <gh>GitHub</gh>.",
|
||||
"designer": "<strong>Diseñador</strong> — mejoras de UI, iconos, capturas para la documentación.",
|
||||
"ideas": "<strong>Ideas</strong> — abre un hilo en <disc>GitHub Discussions</disc> antes de abrir una incidencia de petición de función."
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "FAQ | ProxMenux Documentation",
|
||||
"title": "Preguntas frecuentes | Documentación de ProxMenux",
|
||||
"description": "Preguntas frecuentes sobre ProxMenux: qué es, instalación, compatibilidad (solo PVE 8+), personalización, actualizaciones, seguridad, uso en producción, seguridad de archivos del sistema, contribuir, desinstalación.",
|
||||
"ogTitle": "FAQ | ProxMenux Documentation",
|
||||
"ogTitle": "Preguntas frecuentes | Documentación de ProxMenux",
|
||||
"ogDescription": "Preguntas frecuentes sobre instalación, compatibilidad, seguridad y contribución a ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
@@ -24,7 +24,7 @@
|
||||
"q1": {
|
||||
"question": "¿Qué es ProxMenux y para qué sirve?",
|
||||
"p1Rich": "<strong>ProxMenux</strong> es una herramienta interactiva basada en menús diseñada para hacer <strong>Proxmox VE</strong> accesible a todos los usuarios, independientemente de su experiencia técnica. Simplifica la ejecución de comandos, permitiendo a los usuarios realizar acciones en su sistema sin necesidad de conocimientos avanzados de Linux.",
|
||||
"p2": "Para usuarios menos experimentados, ProxMenux ofrece una forma intuitiva de ejecutar comandos mediante una interfaz de menús estructurada, reduciendo la necesidad de entrada manual por terminal. Para administradores con experiencia, recorta pulsaciones para flujos repetitivos (hardening post-instalación, passthrough de GPU, importación de VMs OVF, rotaciones de snapshots ZFS).",
|
||||
"p2": "Para quienes tienen menos experiencia, ProxMenux ofrece menús estructurados que reducen la necesidad de escribir comandos a mano. A los administradores con experiencia les ahorra pasos en tareas repetitivas: reforzar la seguridad tras instalar, pasar una GPU, importar VM en formato OVF o gestionar la rotación de snapshots ZFS.",
|
||||
"p3": "Proxmox VE se usa ampliamente para:",
|
||||
"items": [
|
||||
"Virtualización de nivel empresarial",
|
||||
@@ -34,7 +34,7 @@
|
||||
},
|
||||
"q2": {
|
||||
"question": "¿Cómo instalo ProxMenux?",
|
||||
"p1Rich": "Sigue la <installlink>guía de instalación</installlink>. En corto:",
|
||||
"p1Rich": "Sigue la <installlink>guía de instalación</installlink>. En resumen:",
|
||||
"stableInstall": "bash -c \"$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)\"",
|
||||
"p2": "Una vez instalado, simplemente arráncalo con:",
|
||||
"menuCmd": "menu"
|
||||
@@ -45,7 +45,7 @@
|
||||
},
|
||||
"q4": {
|
||||
"question": "¿Puedo personalizar ProxMenux?",
|
||||
"p1Rich": "Los scripts del núcleo no se pueden modificar directamente porque están alojados en GitHub y se refrescan con el flujo de auto-actualización. Lo que <em>sí</em> puedes personalizar:",
|
||||
"p1Rich": "Las actualizaciones pueden sobrescribir los cambios locales en los scripts principales, así que evita editar esos archivos directamente. Lo que <em>sí</em> puedes personalizar:",
|
||||
"items": [
|
||||
"El banner de la consola vía la herramienta <strong>FastFetch</strong> en las opciones de post-instalación.",
|
||||
"Qué componentes opcionales se instalan (Monitor, Fail2Ban, Lynis…) — elige durante la instalación o vía el menú correspondiente más tarde."
|
||||
@@ -53,8 +53,8 @@
|
||||
},
|
||||
"q5": {
|
||||
"question": "¿Cómo actualizo ProxMenux?",
|
||||
"p1Rich": "Cuando hay una nueva versión disponible, ProxMenux la detecta en el siguiente lanzamiento de <code>menu</code> y te pide actualizar. Aceptar reemplaza los archivos de utilidad y las configuraciones en sitio. No hace falta descarga manual.",
|
||||
"p2Rich": "Los usuarios estables reciben releases estables; los usuarios beta reciben releases beta. Cuando se publica una versión estable, ProxMenux notifica a los usuarios beta en el siguiente lanzamiento y ofrece cambiar automáticamente — mira la página del <betalink>programa beta</betalink>."
|
||||
"p1Rich": "Cuando hay una nueva versión, ProxMenux la detecta la próxima vez que ejecutas <code>menu</code> y te propone actualizar. Si aceptas, sustituye los archivos de la herramienta y su configuración en la instalación existente; no necesitas descargar nada a mano.",
|
||||
"p2Rich": "Los usuarios de la versión estable reciben las actualizaciones estables y los de la beta, las actualizaciones beta. Cuando se publica una versión estable, la beta avisa al volver a abrir el menú y ofrece cambiar automáticamente a la estable. Consulta el <betalink>programa beta</betalink>."
|
||||
},
|
||||
"q6": {
|
||||
"question": "¿Dónde puedo reportar incidencias?",
|
||||
@@ -63,19 +63,19 @@
|
||||
},
|
||||
"q7": {
|
||||
"question": "¿Puedo contribuir a ProxMenux?",
|
||||
"p1Rich": "<strong>Absolutamente.</strong> ProxMenux es de código abierto y colaborativo. Las contribuciones pueden ser código (bash, Next.js / TypeScript, el venv de Python de traducción), pruebas, documentación, diseño o simplemente ideas.",
|
||||
"p1Rich": "<strong>Por supuesto.</strong> ProxMenux es un proyecto de código abierto y colaborativo. Puedes contribuir con código (Bash, Next.js/TypeScript y herramientas de traducción en Python), pruebas, documentación, diseño o ideas.",
|
||||
"item1Rich": "Discute ideas en <discusslink>GitHub Discussions</discusslink> antes de abrir una petición de función.",
|
||||
"item2Rich": "Para PRs, lee primero el <coclink>código de conducta y buenas prácticas</coclink>.",
|
||||
"item3Rich": "Mira la <contriblink>página de colaboradores</contriblink> para los testers y revisores actuales."
|
||||
},
|
||||
"q8": {
|
||||
"question": "¿ProxMenux modifica archivos críticos del sistema?",
|
||||
"p1Rich": "<strong>No.</strong> ProxMenux instala:",
|
||||
"item1Rich": "Dependencias vía apt: <code>dialog</code>, <code>curl</code>, <code>jq</code>, <code>git</code> (y <code>python3</code> + <code>googletrans</code> en la instalación con traducción).",
|
||||
"p1Rich": "<strong>La instalación de ProxMenux añade los siguientes componentes.</strong>",
|
||||
"item1Rich": "Dependencias mediante apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> y <code>git</code>. Las traducciones usan catálogos JSON pregenerados; el instalador no añade al host un entorno virtual de traducción.",
|
||||
"item2Rich": "El árbol de scripts en <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "El lanzador en <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "Opcional: el servicio systemd del Monitor en <code>proxmenux-monitor.service</code>.",
|
||||
"p2Rich": "ProxMenux <em>no</em> toca la configuración del núcleo de Proxmox a menos que se lo pidas explícitamente vía un menú dedicado (p. ej. el flujo de reparación de red edita <code>/etc/network/interfaces</code> — pero solo después de que confirmes y se haga un backup)."
|
||||
"p2Rich": "ProxMenux <em>no</em> modifica la configuración principal de Proxmox salvo que lo solicites expresamente desde un menú específico. Por ejemplo, la reparación de red edita <code>/etc/network/interfaces</code>, pero solo después de tu confirmación y de hacer un backup."
|
||||
},
|
||||
"q9": {
|
||||
"question": "¿Es seguro usar ProxMenux en producción?",
|
||||
@@ -83,12 +83,12 @@
|
||||
},
|
||||
"q10": {
|
||||
"question": "¿Cómo desinstalo ProxMenux?",
|
||||
"p1Rich": "Desde dentro de ProxMenux: <strong>Settings → Desinstalar ProxMenux</strong>. El desinstalador elimina el árbol de scripts, el lanzador y el servicio del Monitor, opcionalmente elimina las dependencias seleccionadas y restaura los backups de <code>/root/.bashrc</code> y <code>/etc/motd</code> tomados en el momento de la instalación.",
|
||||
"p1Rich": "Desde ProxMenux: <strong>Ajustes → Desinstalar ProxMenux</strong>. El desinstalador elimina el árbol de scripts, el lanzador y el servicio Monitor, permite eliminar dependencias seleccionadas y restaura <code>/root/.bashrc</code> y <code>/etc/motd</code> desde los backups hechos al instalar, si existen.",
|
||||
"p2Rich": "Paso a paso completo: <uninstalllink>Desinstalar ProxMenux</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal marca la URL de instalación — ¿es seguro?",
|
||||
"p1Rich": "Una detección 1/95 por motores heurísticos (p. ej. <em>Chong Lua Dao</em>) es un falso positivo conocido. El instalador usa el patrón estándar <code>curl | bash</code> y descarga binarios legítimos (como <code>jq</code> desde su release oficial en GitHub), que los escáneres agresivos marcan basándose en el <em>comportamiento</em> y no en código realmente malicioso.",
|
||||
"p1Rich": "El resultado de 1/95 notificado en el issue #162, de <em>Chong Lua Dao</em>, fue identificado por el mantenedor como un falso positivo. El instalador usa el patrón <code>curl | bash</code> y puede descargar <code>jq</code> desde su versión oficial de GitHub. Este <em>comportamiento</em> puede activar análisis heurísticos; aquel informe histórico no determina la seguridad de futuras descargas.",
|
||||
"p2Rich": "ProxMenux es 100% código abierto y el script de instalación es revisable línea por línea: <scriptlink>install_proxmenux.sh</scriptlink>. Más contexto en la <issuelink>Issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Acerca de | ProxMenux Documentation",
|
||||
"title": "Acerca del proyecto | Documentación de ProxMenux",
|
||||
"description": "Acerca de ProxMenux: objetivos del proyecto, colaboradores, FAQ y código de conducta. Herramienta de gestión basada en menús, de código abierto, para Proxmox VE 8+, construida y mantenida por MacRimi con un pequeño equipo de testers y colaboradores.",
|
||||
"ogTitle": "Acerca de | ProxMenux Documentation",
|
||||
"ogTitle": "Acerca del proyecto | Documentación de ProxMenux",
|
||||
"ogDescription": "Acerca de ProxMenux — herramienta de gestión basada en menús, de código abierto, para Proxmox VE 8+."
|
||||
},
|
||||
"header": {
|
||||
@@ -27,7 +27,7 @@
|
||||
"icon": "Users",
|
||||
"href": "/docs/about/contributors",
|
||||
"title": "Colaboradores",
|
||||
"description": "Reconocimiento a las personas que hacen posible ProxMenux — testers, revisores y desarrolladores que dan forma a cada release."
|
||||
"description": "Reconocimiento a las personas que hacen posible ProxMenux: quienes prueban, revisan y desarrollan cada versión."
|
||||
},
|
||||
{
|
||||
"icon": "ScrollText",
|
||||
@@ -38,7 +38,7 @@
|
||||
]
|
||||
},
|
||||
"involved": {
|
||||
"heading": "Implicarse",
|
||||
"heading": "Participa",
|
||||
"intro": "Tres lugares para participar en el proyecto:",
|
||||
"cards": [
|
||||
{
|
||||
|
||||
@@ -157,7 +157,7 @@
|
||||
"<strong>Filesystems runtime del kernel y sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> y <code>/run</code> son pseudo-filesystems que produce el kernel y udev; no se persisten en ningún sitio.",
|
||||
"<strong>Binarios de paquetes bajo <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — los reinstala el APT del destino a partir de <code>packages.manual.list</code>.",
|
||||
"<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — estado runtime por host, no se restaura.",
|
||||
"<strong><code>/home/USUARIO</code></strong> — no está en el perfil por defecto. Añadirlo como ruta custom cuando un sistema tenga directorios home de usuario que deban sobrevivir a una restauración."
|
||||
"<strong><code>/home/USER</code></strong> — no está en el perfil por defecto. Añadirlo como ruta custom cuando un sistema tenga directorios home de usuario que deban sobrevivir a una restauración."
|
||||
],
|
||||
"customPathsTitle": "Cómo se tratan las rutas custom",
|
||||
"customPathsBody": "Una ruta custom añadida en línea en modo Custom o persistida en <code>backup-extra-paths.txt</code> pasa por el mismo pipeline de <code>rsync</code> que las rutas del perfil por defecto. Se aplican las exclusiones globales. Si la ruta custom está bajo <code>/root/</code> o <code>/usr/local/share/proxmenux/</code>, siguen aplicando las exclusiones específicas de arriba. Cada ruta archivada — default o custom — queda registrada en <code>metadata/paths_archived.txt</code>. Las rutas que no existen en el origen se registran en <code>metadata/missing_paths.txt</code> sin detener la copia."
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "Cada salto de kernel se maneja de forma distinta",
|
||||
"body": "Cuando la restauración detecta que la copia y el destino tienen versiones mayores distintas de kernel, el flujo se ramifica en función de la dirección del salto — si la copia es más antigua o más reciente que el destino — porque los dos casos tienen modos de fallo opuestos. Las copias más recientes que el destino se restauran limpiamente tal cual (verificado empíricamente en múltiples pruebas de banco). Las copias más antiguas que el destino necesitan un filtro para evitar romper el arranque del destino con configuración escrita para un kernel que desde entonces ha cambiado."
|
||||
"body": "El kernel de un host Proxmox se identifica mediante una versión como <code>6.17.13-2-pve</code>. Los dos primeros números (<strong>6.17</strong> en este ejemplo) definen la versión principal: cuando cambian, algunos archivos de configuración del kernel anterior podrían no ser válidos para el nuevo. Si la restauración detecta versiones principales distintas en la copia y en el destino, el proceso toma un camino u otro según la dirección del salto: si el kernel de la copia es anterior o posterior al del destino. Los dos casos presentan riesgos opuestos. Las copias con un kernel más reciente que el del destino se restauran tal cual, sin problemas según las pruebas realizadas con varios saltos de kernel. Las copias con un kernel anterior al del destino necesitan un filtro para evitar que una configuración del kernel antiguo impida arrancar el sistema de destino."
|
||||
},
|
||||
"directionCheck": {
|
||||
"heading": "La comprobación de dirección",
|
||||
@@ -78,7 +78,7 @@
|
||||
"intro": "Para desarrolladores que quieran trazar o extender el comportamiento cross-kernel:",
|
||||
"rows": [
|
||||
{ "component": "Detección de dirección", "location": "<code>hb_compat_check</code> en <code>lib_host_backup_common.sh</code>. Fija <code>HB_COMPAT_KERNEL_DIRECTION</code>." },
|
||||
{ "component": "Lista de rutas del subconjunto seguro", "location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\tmotivo</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>." },
|
||||
{ "component": "Lista de rutas del subconjunto seguro", "location": "<code>hb_unsafe_paths_cross_version</code> en <code>lib_host_backup_common.sh</code>. Emite líneas <code>path\\treason</code> usadas tanto por el filtro CLI como por el endpoint Web <code>/api/host-backups/restore/prepare</code>." },
|
||||
{ "component": "Fases de hidratación", "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> en <code>backup_host.sh</code>. Orquestados por <code>_rs_apply_bk_older_hydration</code>." },
|
||||
{ "component": "Forzado de reflow post-arranque", "location": "<code>apply_pending_restore.sh</code> lee <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> y fuerza <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>." },
|
||||
{ "component": "Preview Web", "location": "<code>/api/host-backups/restore/prepare</code> en <code>flask_server.py</code>. Fuentea la librería helper, ejecuta <code>_rs_apply_bk_older_hydration</code> en modo plan, devuelve las acciones al modal Web." }
|
||||
|
||||
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "El contenido interno de la copia es el mismo en cualquier destino",
|
||||
"body": "Con independencia de dónde se guarde la copia, dentro siempre están los mismos tres bloques descritos en <em>Cómo funciona</em>: el sistema de ficheros (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al extraer una copia local <code>.tar.zst</code>, restaurar un archivo <code>.pxar</code> desde PBS o descomprimir un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Esto significa que el proceso de restauración lee siempre los mismos ficheros y no le importa desde qué destino provenga la copia."
|
||||
"body": "Los tres destinos contienen la misma estructura <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descrita en <em>Cómo funciona</em>. Extraer un <code>.tar.zst</code> de un archivo local, restaurar un <code>.pxar</code> desde PBS o extraer un archivo de Borg con <code>borg extract</code> produce el mismo árbol de directorios. El proceso de restauración (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lee los mismos tres componentes sin necesitar saber de qué destino proceden."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extraer una copia fuera de ProxMenux",
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
},
|
||||
"repoSelection": {
|
||||
"heading": "Selección del repositorio",
|
||||
"intro": "ProxMenux descubre repositorios PBS desde dos fuentes en cada copia. El usuario elige uno desde un menú unificado; esa elección determina, para esa ejecución concreta, contra qué servidor y datastore se envía la copia, con qué contraseña se autentica y con qué huella (<em>fingerprint</em>) valida el certificado.",
|
||||
"intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada copia de seguridad. El usuario elige uno en un menú unificado; esa elección determina los valores de <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "storage.cfg de Proxmox (auto-descubierto)",
|
||||
@@ -46,7 +46,7 @@
|
||||
"backupIdTitle": "Nombrado del backup ID",
|
||||
"backupIdBody": "El backup ID por defecto es <code>hostcfg-HOSTNAME</code>. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de <code>[A-Za-z0-9_-]</code> se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un <em>grupo</em>, y cada copia posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
|
||||
"pxarTitle": "Qué se incluye dentro del archivo .pxar",
|
||||
"pxarBody": "Al construir el archivo <code>.pxar</code> se empaqueta el directorio de trabajo completo: el sistema de ficheros del host (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al restaurar, ProxMenux compara la información del manifiesto con la del host destino para detectar si son equivalentes, si cambia el hardware o si se trata de un equipo distinto, y ajustar el proceso en consecuencia. Las copias antiguas —hechas con versiones anteriores de ProxMenux que empaquetaban solo el sistema de ficheros— siguen restaurándose sin problema: el flujo de restauración detecta ese formato heredado y lo reorganiza automáticamente."
|
||||
"pxarBody": "El origen del <code>.pxar</code> es todo el directorio <code>staging_root</code>, con <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Las versiones anteriores utilizaban <code>$staging_root/rootfs</code> como origen; esto dejaba <code>metadata/</code> fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Las copias antiguas creadas solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de <code>_rs_check_layout</code>, que vuelve a colocar el árbol plano <code>etc/var/root/usr</code> dentro de una estructura <code>rootfs/</code>."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Cifrado del lado del cliente",
|
||||
@@ -61,9 +61,9 @@
|
||||
"modesSharedTitle": "Clave compartida (importar la misma en cada host)",
|
||||
"modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
|
||||
"recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux pregunta si se quiere subir una copia de esa clave a PBS como red de seguridad, con dos opciones. <strong>No</strong> (por defecto) mantiene la clave solo en el host; ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, la acción <em>Descargar</em> en la fila del destino PBS la exporta en el acto). <strong>Sí</strong> pide una passphrase de recuperación —dos veces, para comprobar que coincidan—; con esa passphrase, la clave se envuelve localmente con AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) en un fichero <code>pbs-key.recovery.enc</code>. A partir de ese momento, cada copia cifrada sube también ese fichero envuelto a PBS. Ni la passphrase ni la clave en claro salen del host. La respuesta se puede cambiar después desde el Monitor en cualquier momento; el interruptor está inline en la fila del destino PBS y el botón que aparece se adapta al estado (empezar a subir, dejar de subir, o cambiar la passphrase).",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — <em>¿Subir clave a PBS?</em> — con dos respuestas. <strong>No se sube nada a PBS hasta que el usuario responde Sí.</strong> La opción por defecto es <em>No, mantener solo local</em>: la clave se queda solo en su ruta local, ProxMenux no toca PBS con nada relacionado con la recuperación y el usuario gestiona por su cuenta la copia externa (desde el Monitor, el botón <em>Descargar archivo clave</em> de la fila del destino PBS la exporta en el acto). Al elegir <em>Sí, subir</em> se pide una passphrase de recuperación —dos veces, para comprobar que coincidan— y ProxMenux envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) en un fichero <code>pbs-key.recovery.enc</code>. A partir de ese momento, cada backup cifrado sube también ese fichero envuelto a PBS como un grupo de backup asociado. Ni la passphrase ni la clave en claro salen del host. La respuesta se puede cambiar después desde el Monitor en cualquier momento: el interruptor de la fila del destino PBS cambia entre Sí y No y se aplica al momento (empezar a subir, dejar de subir o cambiar la passphrase, según el estado).",
|
||||
"blobUploadTitle": "Grupo emparejado en PBS",
|
||||
"blobUploadBody1": "Cuando el usuario ha respondido Sí, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore: uno con las copias del host, otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: se cifra en el host con AES-256-CBC y PBKDF2 antes de enviar un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el sobre ya cifrado.",
|
||||
"blobUploadBody1": "Cuando la custodia está configurada como <em>Sí, subir</em>, ProxMenux sube el archivo de recuperación protegido a PBS después de cada copia cifrada. Lo guarda en un segundo grupo de copia asociado, con el mismo nombre que el grupo del host y el sufijo <code>-keyrecovery</code>. Los dos grupos aparecen juntos en la lista del almacén de datos: uno para las copias del host y otro para los archivos de recuperación. <strong>El archivo de recuperación nunca sale del host en texto plano</strong>: se cifra en el propio host con AES-256-CBC y PBKDF2 antes de enviar ningún dato (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS solo recibe el archivo ya cifrado.",
|
||||
"envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
|
||||
"envelopeSecurityBody": "El sobre viaja y se guarda cifrado en todo momento. La passphrase de recuperación no sale nunca del host: el cifrado ocurre en local antes de la subida y PBS solo recibe el resultado ya cifrado. Un administrador de PBS —o cualquiera con acceso al datastore— puede descargar el sobre, pero sin la passphrase no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas a la vez, el sobre y la passphrase, y solo el usuario tiene ambas.",
|
||||
"blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
|
||||
@@ -73,7 +73,7 @@
|
||||
"recoverTitle": "Recuperación en un equipo recién instalado",
|
||||
"recoverBody": "Cuando la clave no está en su sitio —tras reinstalar el host desde cero o después de eliminarla a propósito— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS elegido tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/<NAME>.enc</code>, se copia sola a la ruta canónica. Segundo, si en PBS hay un grupo <code>-keyrecovery</code>, se descarga la copia más reciente y se pide la passphrase de recuperación para abrirla. Tercero, si ninguna de las dos anteriores funciona o el usuario las descarta, el diálogo pide la ruta absoluta donde ha dejado la clave en este host, y se copia a la ruta canónica. El Monitor expone el mismo flujo dentro del modal de la copia. Si al Restaurar, Descargar o Ver contenido falta la clave, aparece un panel ámbar arriba del modal con las mismas tres vías de importación. Si la clave está instalada pero no es la correcta para esa copia, PBS devuelve un error de tipo <code>wrong key — manifest's key XX does not match provided key YY</code> y el modal muestra un panel estructurado con el fingerprint que PBS espera (el que quedó grabado en el manifest de la copia), para que el usuario sepa qué clave concreta necesita importar.",
|
||||
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
|
||||
"monitorManagementBody": "En la página de configuración de copias, la fila de cada destino PBS incluye los controles de la clave. Tres acciones directas: <em>Descargar</em> exporta la clave actual al navegador. <em>Subir</em> reemplaza la clave instalada por otra que aporta el usuario (la anterior solo se sobrescribe cuando la nueva ha llegado correctamente a su sitio). <em>Eliminar</em> retira la clave del host. Justo al lado está el interruptor del sobre de recuperación: un Sí/No para subir o no la clave a PBS, un campo de passphrase que aparece al elegir Sí, y un botón que se adapta al estado actual (empezar a subir, dejar de subir, o cambiar la passphrase). Los controles del Monitor y el diálogo del shell hacen lo mismo por dentro, así que el resultado en disco y en PBS es idéntico se use la que se use."
|
||||
"monitorManagementBody": "El Monitor muestra los controles del archivo de clave en cada fila de destino PBS de la página de configuración de copias. Hay tres acciones: <em>Descargar</em> envía el archivo de clave actual al navegador del usuario; <em>Subir</em> sustituye el archivo de clave instalado por uno proporcionado por el usuario (el anterior solo se sobrescribe cuando el nuevo se ha guardado correctamente en la ruta canónica); y <em>Eliminar</em> borra el archivo de clave del host. Junto a estas acciones hay un único control de custodia para la recuperación: las opciones Sí y No de <em>¿Subir la clave a PBS?</em>, un campo para la frase de contraseña al elegir Sí y un botón contextual para aplicar el cambio, con el texto <em>Iniciar subida</em>, <em>Detener subida</em> o <em>Actualizar frase de contraseña</em> según el estado actual. Todas las acciones utilizan los mismos endpoints de Flask que el menú de terminal, por lo que el resultado en disco y el estado en PBS son idénticos desde ambas interfaces."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperación del lado de la restauración",
|
||||
|
||||
@@ -112,7 +112,7 @@
|
||||
{
|
||||
"id": "repositorio-pbs",
|
||||
"term": "Repositorio PBS",
|
||||
"def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>usuario@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
|
||||
"def": "Combinación de servidor Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuario al que se suben las copias. Se identifica con el formato <code>user@realm@host:datastore</code>. Un mismo servidor PBS puede alojar varios repositorios."
|
||||
},
|
||||
{
|
||||
"id": "datastore",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validación por esquema",
|
||||
"schemaBody": "ProxMenux incluye una plantilla que describe qué campos debe contener el manifiesto y qué forma tiene cada uno. Cuando se genera una copia se puede comprobar automáticamente que el manifiesto respeta esa plantilla, de modo que si un colector produjera un JSON malformado o con un campo mal escrito se detectaría en el momento. Es una comprobación destinada al desarrollo del propio ProxMenux: si el sistema no la tiene instalada, la copia sigue funcionando con normalidad y el manifiesto se genera igual."
|
||||
"schemaBody": "El manifiesto se valida con <code>scripts/backup_restore/schema/manifest.schema.json</code>. Ejecutar <code>build_manifest.sh --validate</code> activa una validación JSON Schema en Python (requiere <code>python3</code> y <code>jsonschema</code>). Si el módulo no está instalado, se omite la comprobación sin mostrar ningún aviso: esta validación es principalmente una ayuda para el desarrollo, no una dependencia necesaria durante la ejecución."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "El inventario de aplicaciones",
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
},
|
||||
{
|
||||
"action": "Descargar",
|
||||
"detail": "Exporta el archivo como un fichero portable <code>.tar.zst</code> (tar comprimido con zstd). Se puede extraer en cualquier sistema Linux con <code>tar --zstd -xf FICHERO.tar.zst</code>, o desde macOS/Windows con herramientas que soporten zstd (7-Zip, PeaZip, Keka…). El árbol extraído contiene <code>manifest.json</code>, <code>metadata/</code> y <code>rootfs/</code>, exactamente el mismo layout que consume la restauración. Es útil para inspección offline o para restaurar en un host que no tiene acceso al destino original (PBS, Borg)."
|
||||
"detail": "Exporta el archivo como un fichero portable <code>.tar.zst</code> (tar comprimido con zstd). Se puede extraer en cualquier sistema Linux con <code>tar --zstd -xf FILE.tar.zst</code>, o desde macOS/Windows con herramientas que soporten zstd (7-Zip, PeaZip, Keka…). El árbol extraído contiene <code>manifest.json</code>, <code>metadata/</code> y <code>rootfs/</code>, exactamente el mismo layout que consume la restauración. Es útil para inspección offline o para restaurar en un host que no tiene acceso al destino original (PBS, Borg)."
|
||||
},
|
||||
{
|
||||
"action": "Restaurar",
|
||||
|
||||
@@ -110,7 +110,7 @@
|
||||
},
|
||||
"apply": {
|
||||
"title": "Aplicar cambios del host + workloads",
|
||||
"body": "Una vez confirmas, el script escribe los cambios del lado del host — <code>vfio.conf</code>, blacklist, módulos y (para NVIDIA) la regla udev por BDF en <code>/etc/udev/rules.d/10-proxmenux-vfio-bind.rules</code> más el estado BDF en <code>/etc/proxmenux/vfio-bind.bdfs</code>. También aplica la política de conflicto elegida a cada VM/LXC afectada. Si la config del host realmente cambió, ejecuta <code>update-initramfs -u -k all</code> — si no, salta ese paso."
|
||||
"body": "Tras confirmar, el script escribe los cambios en el host: <code>vfio.conf</code>, la lista de módulos bloqueados, los módulos y, para NVIDIA, la regla udev por BDF en <code>/etc/udev/rules.d/10-proxmenux-vfio-bind.rules</code> y el estado BDF en <code>/etc/proxmenux/vfio-bind.bdfs</code>. También aplica la política de conflictos elegida a cada VM/LXC afectado. Si la configuración del host ha cambiado, ejecuta <code>update-initramfs -u -k all</code> y después <code>proxmox-boot-tool refresh</code>; si no ha cambiado, omite ambos comandos."
|
||||
},
|
||||
"reboot": {
|
||||
"title": "Reiniciar",
|
||||
|
||||
@@ -257,7 +257,7 @@
|
||||
"<strong>Hecho.</strong> El 2FA está ahora activo. La próxima vez que te logues, el panel pide primero la contraseña; una vez aceptada pide el código actual de 6 dígitos."
|
||||
],
|
||||
"setupStep4Sub": [
|
||||
"<em>Camino fácil:</em> en la app, pulsa <em>Añadir cuenta</em> → <em>Escanear código QR</em>, apunta la cámara al QR en la pantalla. La app nombra la entrada automáticamente (algo como <code>ProxMenux Monitor (tu-usuario)</code>) y empieza a mostrar un código de 6 dígitos que se refresca cada 30 segundos.",
|
||||
"<em>Camino fácil:</em> en la app, pulsa <em>Añadir cuenta</em> → <em>Escanear código QR</em>, apunta la cámara al QR en la pantalla. La app nombra la entrada automáticamente (algo como <code>ProxMenux Monitor (your-username)</code>) y empieza a mostrar un código de 6 dígitos que se refresca cada 30 segundos.",
|
||||
"<em>Plan B manual</em> (cuando escanear no es posible — p. ej. configurando en el mismo móvil con el que abriste el panel): pulsa <em>Añadir cuenta</em> → <em>Introducir clave de setup</em>. Escribe cualquier nombre (p. ej. <em>Proxmox Monitor</em>), pega la cadena Base32 del diálogo, deja <em>Tipo</em> como <em>Basado en tiempo</em>, guarda."
|
||||
],
|
||||
"testTitle": "Prueba antes de hacer logout",
|
||||
@@ -319,7 +319,7 @@
|
||||
"heading": "Secure Gateway (Tailscale)",
|
||||
"intro": "Los reverse proxies son la respuesta clásica a \"llegar al panel desde fuera\" pero requieren un dominio público, certificado y un puerto abierto en el borde. <strong>Secure Gateway</strong> es la alternativa cero-puertos que viene dentro del propio Monitor — una app desplegable preconstruida que levanta un LXC Alpine ejecutando <a>Tailscale</a> como subnet router. Una vez unido a tu tailnet, cada dispositivo en él puede llegar al Monitor en la propia IP LAN del host — desde un portátil de vacaciones, un móvil con 5G u otro nodo — sin exponer TCP 8008 a internet.",
|
||||
"calloutTitle": "Por qué esto es cómodo",
|
||||
"calloutBody": "La URL se mantiene igual que en la LAN — <code>http://<ip-lan-proxmox>:8008</code> funciona donde Tailscale funcione. Sin certificados, sin DNS, sin port forwarding. El propio Monitor ve la petición viniendo de una IP de tailnet (típicamente <code>100.x.y.z</code>), así que el log de auth y el hook de Fail2Ban siguen funcionando como en la LAN.",
|
||||
"calloutBody": "La URL se mantiene igual que en la LAN — <code>http://<proxmox-lan-ip>:8008</code> funciona donde Tailscale funcione. Sin certificados, sin DNS, sin port forwarding. El propio Monitor ve la petición viniendo de una IP de tailnet (típicamente <code>100.x.y.z</code>), así que el log de auth y el hook de Fail2Ban siguen funcionando como en la LAN.",
|
||||
"deployBody": "El flujo de despliegue es una sola pantalla — elige el storage LXC del host, pega un auth-key de Tailscale (generado en <a>login.tailscale.com/admin/settings/keys</a>), elige qué subnets anunciar, pulsa Deploy. El LXC tarda ~30 segundos en arrancar y se registra en el tailnet automáticamente.",
|
||||
"outro": "El despliegue paso a paso, la configuración de subnet-routes, las ACLs de Tailscale y el modo Exit Node se documentan por separado en <link>Dashboard → Security → Secure Gateway</link> — ahí vive el wizard de despliegue en la UI del panel. Esta página solo cubre el patrón de acceso."
|
||||
},
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
"heading": "Convenciones",
|
||||
"items": [
|
||||
"Todas las peticiones y respuestas son JSON salvo que se indique explícitamente (la descarga de logs es texto plano, <code>/api/prometheus</code> es text/plain en formato OpenMetrics, el log de tareas es texto plano).",
|
||||
"Los endpoints que modifican estado con éxito devuelven <code>'{'\"success\": true, ...'}'</code>. Las respuestas de error usan un estado HTTP no-2xx con <code>'{'\"success\": false, \"error\": \"'<'motivo'>'\"'}'</code>.",
|
||||
"Los endpoints que modifican estado con éxito devuelven <code>'{'\"success\": true, ...'}'</code>. Las respuestas de error usan un estado HTTP no-2xx con <code>'{'\"success\": false, \"error\": \"'<'reason'>'\"'}'</code>.",
|
||||
"Los endpoints de listado aceptan <code>limit</code>, <code>offset</code>, <code>since</code> opcionales y filtros específicos por categoría vía query string.",
|
||||
"Los campos de tiempo se devuelven como segundos epoch Unix o ISO-8601 con zona horaria explícita, nunca como cadenas de locale."
|
||||
]
|
||||
@@ -174,7 +174,7 @@
|
||||
"syncVsAsyncBody": "Las acciones a nivel de sistema (power del host, PVE update, self-update de ProxMenux) pueden tardar minutos — corren en su propia unit systemd transitoria y exponen un endpoint <code>.../status</code> más un <code>DELETE</code> para cancelar. Las acciones VM / LXC (start, stop, shutdown, reboot, backup) son rápidas y usan el estilo fire-and-return que la UI del Monitor ya expone: el POST devuelve el resultado directo. Ambos estilos comparten el mismo modelo de autenticación (JWT o token de API de larga duración).",
|
||||
"curlTitle": "Ejemplo con curl",
|
||||
"curlBody": "Disparar una actualización de PVE y hacer polling hasta que termine — exactamente la misma secuencia que ejecutaría una automatización de Home Assistant o un playbook de Ansible:",
|
||||
"curlCode": "TOKEN=<tu token full_admin>\n\ncurl -sSf -X POST \\\n -H \"Authorization: Bearer $TOKEN\" \\\n https://<host>:8008/api/system/pve-update/run\n\nwhile true; do\n state=$(curl -sSf -H \"Authorization: Bearer $TOKEN\" \\\n https://<host>:8008/api/system/pve-update/status | jq -r .state)\n [ \"$state\" != \"running\" ] && break\n sleep 30\ndone\necho \"estado final: $state\"",
|
||||
"curlCode": "TOKEN=<your full_admin token>\n\ncurl -sSf -X POST \\\n -H \"Authorization: Bearer $TOKEN\" \\\n https://<host>:8008/api/system/pve-update/run\n\nwhile true; do\n state=$(curl -sSf -H \"Authorization: Bearer $TOKEN\" \\\n https://<host>:8008/api/system/pve-update/status | jq -r .state)\n [ \"$state\" != \"running\" ] && break\n sleep 30\ndone\necho \"final state: $state\"",
|
||||
"haTitle": "Snippet de integración con Home Assistant",
|
||||
"haBody": "Un sensor <code>rest</code> hace polling del estado y un <code>rest_command</code> dispara la actualización. Conecta ambos a un botón del dashboard y a las automatizaciones que quieras:",
|
||||
"haCode": "# configuration.yaml\nsensor:\n - platform: rest\n resource: https://pve.local:8008/api/system/pve-update/status\n name: pve_update_state\n value_template: \"{{ value_json.state }}\"\n scan_interval: 60\n headers:\n Authorization: \"Bearer !secret proxmenux_token\"\n\nrest_command:\n pve_update:\n url: https://pve.local:8008/api/system/pve-update/run\n method: POST\n headers:\n Authorization: \"Bearer !secret proxmenux_token\"\n\n # Encender VM 100 (funciona igual para LXC — mismo endpoint)\n vm_100_start:\n url: https://pve.local:8008/api/vms/100/control\n method: POST\n content_type: 'application/json'\n payload: '{\"action\": \"start\"}'\n headers:\n Authorization: \"Bearer !secret proxmenux_token\"\n\n # Backup de la VM 100 al storage 'pbs-main'\n vm_100_backup:\n url: https://pve.local:8008/api/vms/100/backup\n method: POST\n content_type: 'application/json'\n payload: '{\"storage\": \"pbs-main\", \"mode\": \"snapshot\", \"compress\": \"zstd\"}'\n headers:\n Authorization: \"Bearer !secret proxmenux_token\""
|
||||
|
||||
@@ -101,7 +101,7 @@
|
||||
],
|
||||
"sourcesHeading": "Fuentes para la versión disponible",
|
||||
"sources": [
|
||||
"<strong>Repositorio de GitHub</strong>: último lanzamiento o etiqueta de un repositorio público <code>propietario/nombre</code>.",
|
||||
"<strong>Repositorio de GitHub</strong>: último lanzamiento o etiqueta de un repositorio público <code>owner/name</code>.",
|
||||
"<strong>HTTP JSON</strong>: un punto final público y una ruta como <code>data.version</code> o <code>releases[0].tag_name</code>.",
|
||||
"<strong>Docker Hub</strong>: etiquetas versionadas filtradas con una expresión regular. La vista previa muestra etiquetas reales coincidentes antes de guardar.",
|
||||
"Las etiquetas móviles como <code>latest</code>, <code>stable</code> o <code>lts</code> no contienen una versión. Esas imágenes se siguen por digest desde las actualizaciones de imágenes Docker."
|
||||
|
||||
@@ -110,8 +110,8 @@
|
||||
"No incluyas <code>pct exec</code>; ProxMenux ya entra en el contenedor y ejecuta el comando como root."
|
||||
],
|
||||
"exampleLead": "Ejemplo de procedimiento completo dentro del contenedor:",
|
||||
"example": "cd /opt/mi-app && ./update.sh",
|
||||
"callout": "Un comando de versión como <code>miapp --version</code> solo lee una versión; no instala nada. Los comandos se ejecutan con privilegios administrativos y deben revisarse con el mismo cuidado que un comando de shell como root."
|
||||
"example": "cd /opt/my-app && ./update.sh",
|
||||
"callout": "Un comando de versión como <code>myapp --version</code> solo lee una versión; no instala nada. Los comandos se ejecutan con privilegios administrativos y deben revisarse con el mismo cuidado que un comando de shell como root."
|
||||
},
|
||||
"bulk": {
|
||||
"heading": "Actualización en bloque",
|
||||
@@ -142,7 +142,7 @@
|
||||
"La espera tras una versión solo se aplica a las apps seleccionadas con seguimiento. Las apps sin seguimiento ejecutan su actualizador cuando vence la programación.",
|
||||
"El estado de la última ejecución diferencia entre éxito, finalización parcial, error, retención de seguridad y ausencia de elementos pendientes. Después de la primera ejecución programada, <strong>Actualizaciones → Actualizaciones programadas → Ver log</strong> abre la salida completa capturada del actualizador y de los scripts secundarios que haya ejecutado.",
|
||||
"Después de cada ejecución, ProxMenux comprueba el marcador estándar de Debian que indica si es necesario reiniciar. Cuando hace falta, la pestaña Actualizaciones y la notificación de finalización lo indican; el aviso se elimina cuando ese LXC se inicia o reinicia.",
|
||||
"En el host Proxmox, los logs de las ejecuciones programadas se guardan en <code>/usr/local/share/proxmenux/logs/lxc-updates/</code> con el nombre <code><VMID>-scheduled-<id-de-ejecución>.log</code>. Se conservan los diez últimos logs de cada LXC y los archivos más antiguos se eliminan automáticamente.",
|
||||
"En el host Proxmox, los logs de las ejecuciones programadas se guardan en <code>/usr/local/share/proxmenux/logs/lxc-updates/</code> con el nombre <code><VMID>-scheduled-<run-id>.log</code>. Se conservan los diez últimos logs de cada LXC y los archivos más antiguos se eliminan automáticamente.",
|
||||
"Este historial corresponde a las actualizaciones programadas. Una actualización manual muestra su salida en tiempo real en la ventana de ejecución del Monitor y no crea un log de ejecución programada en ese directorio.",
|
||||
"Las programaciones externas detectadas de Proxmox VE Helper-Scripts se muestran aparte para hacer visible cualquier automatización coincidente."
|
||||
],
|
||||
@@ -186,7 +186,7 @@
|
||||
},
|
||||
{
|
||||
"problem": "Una actualización programada indica que es necesario reiniciar",
|
||||
"resolution": "Abre <strong>Ver log</strong> para revisar la ejecución completada y reinicia ese LXC. ProxMenux elimina el aviso mediante el evento de ciclo de vida existente cuando el contenedor vuelve a arrancar."
|
||||
"resolution": "Abre Ver registro para revisar la ejecución completada y después reinicia ese LXC. ProxMenux borra el aviso cuando el evento de ciclo de vida detecta el nuevo arranque."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
"headingHref": "https://gethomepage.dev",
|
||||
"intro": "Homepage es un panel de aplicaciones totalmente estático y personalizable. ProxMenux Monitor se enchufa vía el widget <code>customapi</code> integrado — pega una entrada de servicio en <code>services.yaml</code>, reinicia Homepage y la tarjeta aparece con números en vivo.",
|
||||
"iconCalloutTitle": "El logo oficial de ProxMenux está en dashboardicons.com",
|
||||
"iconCalloutBody": "Las guías de abajo usan <code>icon: proxmenux.png</code>. Homepage resuelve automáticamente los nombres de archivo simples contra <a1>dashboardicons.com</a1> — una librería de iconos curada para paneles autoalojados. La entrada de ProxMenux vive en <a2>dashboardicons.com/icons/external/proxmenux</a2> y Homepage la descarga en el primer render. La misma búsqueda funciona para miles de otras herramientas (Telegram, Discord, Grafana, Tailscale, etc.) — basta con escribir <code>icon: <nombre>.png</code> en cualquier entrada de servicio.",
|
||||
"iconCalloutBody": "Las guías de abajo usan <code>icon: proxmenux.png</code>. Homepage resuelve automáticamente los nombres de archivo simples contra <a1>dashboardicons.com</a1> — una librería de iconos curada para paneles autoalojados. La entrada de ProxMenux vive en <a2>dashboardicons.com/icons/external/proxmenux</a2> y Homepage la descarga en el primer render. La misma búsqueda funciona para miles de otras herramientas (Telegram, Discord, Grafana, Tailscale, etc.) — basta con escribir <code>icon: <name>.png</code> en cualquier entrada de servicio.",
|
||||
"imageAlt": "Panel Homepage mostrando tres tarjetas de ProxMenux Monitor (EDGE, VOID, DREAM) con uptime, CPU, RAM y temperatura para cada host Proxmox",
|
||||
"imageCaption": "Tres instancias de ProxMenux Monitor renderizadas como tarjetas Homepage — uptime, CPU, RAM y temperatura de CPU leídas en vivo desde <code>/api/system</code> en cada host cada 10 s.",
|
||||
"basicTitle": "Widget básico — sin autenticación",
|
||||
@@ -94,7 +94,7 @@
|
||||
"twoColTipBody": "Reemplaza cualquier par de tarjetas (p. ej. <em>Sistema</em> + <em>VMs</em>, o <em>Almacenamiento</em> + <em>Red</em>) con un único <code>horizontal-stack</code> envolviendo ambas, para que siempre se rendericen lado a lado independientemente del ancho de pantalla:",
|
||||
"twoColTipOutro": "En móvil la fila se mantiene comprimida; el auto layout de HA (sin horizontal-stack) refluye mejor a anchos estrechos.",
|
||||
"step6Title": "6 · Automatizaciones",
|
||||
"step6Body": "Tres automatizaciones que cubren los escenarios reactivos más comunes — reemplaza <code>notify.mobile_app_<tu_movil></code> por el servicio notify que uses:",
|
||||
"step6Body": "Tres automatizaciones que cubren los escenarios reactivos más comunes — reemplaza <code>notify.mobile_app_<your_phone></code> por el servicio notify que uses:",
|
||||
"logoTitle": "Sobre el logo de ProxMenux",
|
||||
"logoBody": "La tarjeta picture-entity en la parte superior del YAML Lovelace descarga el logo oficial de ProxMenux desde <a1>dashboardicons.com</a1> — una librería de iconos gratuita curada para paneles autoalojados. La entrada de ProxMenux vive en <a2>dashboardicons.com/icons/external/proxmenux</a2>. Home Assistant descarga el SVG sobre HTTPS en el primer render y lo cachea.",
|
||||
"logoBrokenTitle": "Si la tarjeta del logo muestra una imagen rota",
|
||||
@@ -120,7 +120,7 @@
|
||||
"tokenTipTitle": "Token vía archivo o env, no inline",
|
||||
"tokenTipBody": "Para despliegues en producción evita poner el token inline. Prometheus soporta <code>credentials_file: /etc/prometheus/secrets/proxmenux.token</code> como alternativa — guarda el token en un archivo 0600 y deja que Prometheus lo lea.",
|
||||
"step2Title": "2 · Verifica el scrape con un par de queries",
|
||||
"step2Body": "Antes de configurar Grafana, confirma que Prometheus realmente tiene los datos. Abre la propia UI de Prometheus en <code>http://<host-prometheus>:9090</code>, pulsa <em>Query</em> y ejecuta cualquiera de estas — deberías obtener números en vivo de tu host Proxmox:",
|
||||
"step2Body": "Antes de configurar Grafana, confirma que Prometheus realmente tiene los datos. Abre la propia UI de Prometheus en <code>http://<prometheus-host>:9090</code>, pulsa <em>Query</em> y ejecuta cualquiera de estas — deberías obtener números en vivo de tu host Proxmox:",
|
||||
"headerQuery": "Query",
|
||||
"headerConfirms": "Qué confirma",
|
||||
"verifyRows": [
|
||||
|
||||
@@ -44,7 +44,7 @@
|
||||
"Arranca el hilo de fondo de despacho. El hilo hace polling de la cola de eventos y camina cada evento por la pipeline diagramada arriba."
|
||||
],
|
||||
"activeAlt": "Tarjeta de notificaciones activada con pestañas de canales, nombre visible y opciones avanzadas de IA",
|
||||
"activeCaption": "Estado activo: pestañas Telegram, Gotify, Discord, Email, Pushover y Apprise, nombre visible, categorías por canal y opciones avanzadas de IA."
|
||||
"activeCaption": "Estado activo: pestañas de canales en la parte superior (Telegram / Gotify / Discord / correo electrónico / Pushover / Apprise), campo Nombre para mostrar, lista de categorías de cada canal y sección desplegable <em>Avanzado: mejora con IA</em>."
|
||||
},
|
||||
"sources": {
|
||||
"heading": "Fuentes de eventos",
|
||||
@@ -119,7 +119,7 @@
|
||||
"groupItems": [
|
||||
"Añade el bot al grupo como miembro (y hazlo admin si el grupo lo requiere para publicar).",
|
||||
"Envía cualquier mensaje en el grupo.",
|
||||
"Abre <code>https://api.telegram.org/bot<TU_TOKEN>/getUpdates</code> en un navegador. Busca <code>chat.id</code> en la respuesta JSON — para grupos es un número negativo, para supergrupos empieza con <code>-100</code>.",
|
||||
"Abre <code>https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates</code> en un navegador. Busca <code>chat.id</code> en la respuesta JSON — para grupos es un número negativo, para supergrupos empieza con <code>-100</code>.",
|
||||
"Para supergrupos con <em>Topics</em> activado, anota también el <code>message_thread_id</code> del tema al que quieres apuntar — eso va en el campo opcional <em>Topic ID</em>."
|
||||
],
|
||||
"groupAlt": "Formulario de canal Telegram con Bot Token (enmascarado), Chat ID negativo prefijado con -100 indicando un supergrupo, y Topic ID 3 configurado para entregar a un tema específico",
|
||||
@@ -203,7 +203,7 @@
|
||||
"stepsTitle": "Pasos",
|
||||
"steps": [
|
||||
"Elige el servicio destino en la <a>wiki de Apprise</a> y copia la plantilla de URL para él. Cada página de servicio muestra el esquema exacto a usar (<code>ntfy://</code>, <code>matrix://</code>, <code>pover://</code>, <code>slack://</code>…) más cualquier token, canal u hostname requerido.",
|
||||
"Rellena los placeholders con tus propias credenciales. Por ejemplo, un topic de ntfy.sh tiene aspecto de <code>ntfy://ntfy.sh/mi-topic</code>; una URL de Pushover tiene aspecto de <code>pover://user@token</code>; una URL de Matrix tiene aspecto de <code>matrix://user:pass@host:port/#room</code>.",
|
||||
"Sustituye los marcadores por tus credenciales. Ejemplos: ntfy.sh <code>ntfy://ntfy.sh/my-topic</code>; Pushover <code>pover://user@token</code>; Matrix <code>matrix://user:pass@host:port/#room</code>.",
|
||||
"Pega la URL final en el campo <em>Apprise URL</em> en la pestaña Apprise del panel Notifications y guarda.",
|
||||
"Pulsa <em>Send Test</em> para verificar que la URL es alcanzable y las credenciales se aceptan."
|
||||
],
|
||||
@@ -295,7 +295,7 @@
|
||||
"rows": [
|
||||
{
|
||||
"stage": "1. Deduplicación por huella",
|
||||
"what": "Cada evento genera una huella (<code>event_type + campos clave de data</code>). Las huellas idénticas dentro de una ventana corta se consideran duplicados del primero.",
|
||||
"what": "Cada evento genera una huella (<code>event_type + key fields from data</code>). Las huellas idénticas dentro de una ventana corta se consideran duplicados del primero.",
|
||||
"tunable": "No — lógica interna del dispatcher."
|
||||
},
|
||||
{
|
||||
@@ -339,7 +339,7 @@
|
||||
"<strong>Llamadores remotos.</strong> Cinco capas se apilan encima del rate-limiting: un shared secret en la cabecera <code>X-Webhook-Secret</code>, un timestamp de frescura en <code>X-ProxMenux-Timestamp</code> (rechazado si se desvía más allá de la ventana configurada), una búsqueda de caché de replay y una allowlist de IP opcional. El shared secret vive en la tabla de ajustes SQLite del Monitor — no en <code>/etc/pve/priv/notifications.cfg</code> — y se genera en el primer setup. Este camino existe para integraciones personalizadas que hacen POST desde fuera del host; el destino configurado por PVE nunca lo ejercita."
|
||||
],
|
||||
"practiceTitle": "En la práctica",
|
||||
"practiceBody": "El setup de PVE escribe el destino como <code>http://127.0.0.1:8008</code>, así que las notificaciones emitidas por PVE siempre pasan por el camino loopback con seguridad solo rate-limit. El camino de llamador remoto con shared secret es opt-in para integraciones personalizadas — apunta un servicio externo a <code>https://<host-monitor>:<port>/api/notifications/webhook</code> y suministra la cabecera <code>X-Webhook-Secret</code> para usarlo.",
|
||||
"practiceBody": "El setup de PVE escribe el destino como <code>http://127.0.0.1:8008</code>, así que las notificaciones emitidas por PVE siempre pasan por el camino loopback con seguridad solo rate-limit. El camino de llamador remoto con shared secret es opt-in para integraciones personalizadas — apunta un servicio externo a <code>https://<monitor-host>:<port>/api/notifications/webhook</code> y suministra la cabecera <code>X-Webhook-Secret</code> para usarlo.",
|
||||
"actionsIntro": "El Monitor gestiona este destino a través de tres acciones en la pestaña Settings:",
|
||||
"actionsItems": [
|
||||
"<strong>Setup</strong> — corre automáticamente cuando activas Notifications. Crea la entrada en <code>/etc/pve/notifications.cfg</code>. El archivo solo se escribe cuando su contenido tiene que cambiar, y se guarda un backup del anterior en <code>/usr/local/share/proxmenux/backups/pve-notifications/</code> (los tres más recientes). No se escribe nada mientras <code>/etc/pve</code> no está montado: un Monitor que arranca durante un reinicio de <code>pve-cluster</code> registra la entrada cuando vuelve.",
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Backup y reinicio de interfaces | ProxMenux Documentation",
|
||||
"title": "Backup y reinicio de interfaces | Documentación de ProxMenux",
|
||||
"description": "Snapshot manual, navegación y restauración de backups de /etc/network/interfaces almacenados en /var/backups/proxmenux/. Incluye un reinicio del servicio de red con confirmación y una vista rápida de la configuración en vivo.",
|
||||
"ogTitle": "Backup y reinicio de interfaces | ProxMenux Documentation",
|
||||
"ogTitle": "Backup y reinicio de interfaces | Documentación de ProxMenux",
|
||||
"ogDescription": "Snapshot y restauración de la configuración de red de Proxmox; reinicia el servicio de red con confirmación."
|
||||
},
|
||||
"header": {
|
||||
@@ -27,7 +27,7 @@
|
||||
"heading": "Crear backup de red",
|
||||
"body": "Copia el <code>/etc/network/interfaces</code> actual al directorio de backups con un timestamp nuevo. Ya está — sin análisis, sin prompts, solo un snapshot.",
|
||||
"whenTitle": "Cuándo hacer un backup manual",
|
||||
"whenBody": "Antes de editar <code>/etc/network/interfaces</code> a mano, antes de instalar un paquete que pueda tocar la stack de red (p. ej. NetworkManager, Open vSwitch) o antes de cualquier cambio de hardware. Las reparaciones guiadas ya hacen snapshot automáticamente — esta opción es para los momentos <em>manuales</em>."
|
||||
"whenBody": "Antes de editar <code>/etc/network/interfaces</code> a mano, antes de instalar un paquete que pueda modificar la pila de red (p. ej. NetworkManager, Open vSwitch) o antes de cualquier cambio de hardware. Las reparaciones guiadas ya hacen un backup automáticamente; esta opción es para las operaciones <em>manuales</em>."
|
||||
},
|
||||
"restore": {
|
||||
"heading": "Restaurar backup de red",
|
||||
@@ -96,7 +96,7 @@
|
||||
"tail": " — la razón más habitual por la que un backup acaba aquí."
|
||||
},
|
||||
{
|
||||
"label": "Análisis de config y limpieza guiada",
|
||||
"label": "Análisis de configuración y limpieza guiada",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": " — también escribe en <code>/var/backups/proxmenux/</code> automáticamente."
|
||||
},
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Análisis de bridges y reparación guiada | ProxMenux Documentation",
|
||||
"title": "Análisis de bridges y reparación guiada | Documentación de ProxMenux",
|
||||
"description": "Detecta bridges vmbrX con puertos físicos ausentes o inválidos (típico tras una re-enumeración PCI), los reporta con comandos de shell propuestos y ofrece una reparación guiada de 5 pasos con backup obligatorio.",
|
||||
"ogTitle": "Análisis de bridges y reparación guiada | ProxMenux Documentation",
|
||||
"ogTitle": "Análisis de bridges y reparación guiada | Documentación de ProxMenux",
|
||||
"ogDescription": "Auditar y reparar los puertos de bridge de Proxmox tras cambios de hardware, con flujo guiado y rollback seguro."
|
||||
},
|
||||
"header": {
|
||||
@@ -35,7 +35,7 @@
|
||||
"bridgeLabel": "Analizar (solo lectura)",
|
||||
"bridgeDetail": "ip link show enp3s0\n→ no existe",
|
||||
"targetLabel": "Informe + sugerencia",
|
||||
"targetDetail": "❌ enp3s0: NOT FOUND\nReemplazar por: eno1\n(aún sin cambios)"
|
||||
"targetDetail": "❌ enp3s0: NO ENCONTRADO\nReemplazar por: eno1\n(aún sin cambios)"
|
||||
}
|
||||
},
|
||||
"diagram2": {
|
||||
@@ -50,7 +50,7 @@
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Paso 1: análisis (solo lectura)",
|
||||
"intro": "Seleccionar <strong>Analizar configuración de bridges</strong> aborta inmediatamente si el host no usa la stack clásica de Debian/Proxmox. Si no, recorre cada bridge y reporta:",
|
||||
"intro": "Al seleccionar <strong>Analizar configuración de bridges</strong>, la herramienta se detiene inmediatamente si el host no usa la pila clásica de Debian/Proxmox. En caso contrario, recorre todos los bridges e informa de:",
|
||||
"items": [
|
||||
"Nombre del bridge, estado actual (UP / DOWN), IP asignada.",
|
||||
"Cada puerto declarado y si existe actualmente (<code>ip link show <port></code>).",
|
||||
@@ -76,7 +76,7 @@
|
||||
},
|
||||
{
|
||||
"title": "3. Previsualizar los cambios propuestos",
|
||||
"body": "Lista exactamente qué bridges se van a tocar y qué sustituciones de puerto se van a hacer. Si el análisis decide que en realidad no hay que arreglar nada (race condition: el puerto volvió), el flujo sale limpio con <em>\"No changes needed.\"</em>",
|
||||
"body": "Lista exactamente qué bridges se modificarán y qué sustituciones de puertos se harán. Si el análisis determina que no hay nada que reparar porque el puerto ha reaparecido entre las comprobaciones, el proceso termina con <em>«No se necesitan cambios»</em>.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
@@ -90,7 +90,7 @@
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"restartTitle": "Reiniciar networking ≠ un undo gratis",
|
||||
"restartTitle": "Reiniciar la red ≠ deshacer los cambios sin riesgo",
|
||||
"restartBody": "La reparación se escribe en disco independientemente de si reinicias el servicio. <code>systemctl restart networking</code> aplica el cambio <em>ahora</em>, lo que puede cortar tu sesión SSH si el nuevo puerto es incorrecto. Si rechazas el reinicio, el cambio sigue surtiendo efecto en el siguiente reinicio — confirma antes la nueva config o haz rollback con el comando impreso."
|
||||
},
|
||||
"edits": {
|
||||
@@ -99,8 +99,8 @@
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Solución de problemas",
|
||||
"unsupportedTitle": "El análisis aborta con \"Unsupported Network Stack\"",
|
||||
"unsupportedBody": "El host usa netplan, systemd-networkd o NetworkManager. La herramienta solo soporta <code>/etc/network/interfaces</code>. Cambia el host a la stack clásica primero, o edita la configuración con las herramientas nativas del gestor (p. ej. <code>netplan apply</code>).",
|
||||
"unsupportedTitle": "El análisis se detiene con «Unsupported Network Stack»",
|
||||
"unsupportedBody": "El host usa netplan, systemd-networkd o NetworkManager. La herramienta solo admite <code>/etc/network/interfaces</code>. Cambia primero el host a la pila clásica o edita la configuración con las herramientas nativas del gestor (p. ej. <code>netplan apply</code>).",
|
||||
"noSuggestTitle": "No se imprime sugerencia para un puerto inválido",
|
||||
"noSuggestBody": "El host no tiene ninguna interfaz física libre (todas están ya en otro bridge o no existen). El análisis cae a sugerir <code>bridge-ports none</code> para que el bridge al menos pueda levantar sin puerto. Añade una NIC o migra puertos entre bridges manualmente antes de volver a ejecutar.",
|
||||
"stillDownTitle": "La reparación termina pero el bridge sigue DOWN",
|
||||
@@ -118,7 +118,7 @@
|
||||
"tail": " — fija los nombres a direcciones MAC para que esto deje de pasar."
|
||||
},
|
||||
{
|
||||
"label": "Análisis de config y limpieza guiada",
|
||||
"label": "Análisis de configuración y limpieza guiada",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": " — para bloques <code>iface</code> huérfanos (la otra mitad del mismo problema)."
|
||||
},
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Análisis de config y limpieza guiada | ProxMenux Documentation",
|
||||
"title": "Análisis de configuración y limpieza guiada | Documentación de ProxMenux",
|
||||
"description": "Detecta bloques iface en /etc/network/interfaces que referencian NICs físicas que ya no están en el host. Los reporta y ofrece una eliminación guiada de 5 pasos con backup obligatorio y previsualización por bloque.",
|
||||
"ogTitle": "Análisis de config y limpieza guiada | ProxMenux Documentation",
|
||||
"ogTitle": "Análisis de configuración y limpieza guiada | Documentación de ProxMenux",
|
||||
"ogDescription": "Encuentra y elimina bloques de interfaz huérfanos dejados por cambios de hardware, con previsualización completa y rollback."
|
||||
},
|
||||
"header": {
|
||||
"title": "Análisis de config y limpieza guiada",
|
||||
"title": "Análisis de configuración y limpieza guiada",
|
||||
"description": "Recorre cada bloque iface en /etc/network/interfaces y verifica que la NIC física subyacente sigue existiendo. Reporta los bloques huérfanos dejados por cambios de hardware y ofrece una eliminación guiada con backup, previsualización y confirmación por bloque.",
|
||||
"section": "Red"
|
||||
},
|
||||
@@ -18,7 +18,7 @@
|
||||
"heading": "En qué se diferencia del análisis de bridges",
|
||||
"headerAspect": "Aspecto",
|
||||
"headerBridge": "Análisis de bridges",
|
||||
"headerConfig": "Análisis de config",
|
||||
"headerConfig": "Análisis de configuración",
|
||||
"rows": [
|
||||
{
|
||||
"aspect": "Mira",
|
||||
@@ -45,7 +45,7 @@
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Paso 1: análisis (solo lectura)",
|
||||
"intro": "Aborta inmediatamente si el host no usa la stack clásica. Si no, lista cada interfaz configurada que no sea loopback y reporta su estado:",
|
||||
"intro": "Se detiene inmediatamente si el host no usa la pila clásica. En caso contrario, lista todas las interfaces configuradas salvo loopback e indica su estado:",
|
||||
"virtTitle": "Las interfaces virtuales están protegidas",
|
||||
"virtBody": "Los bridges (<code>vmbrX</code>) y los bonds (<code>bondX</code>) son construcciones virtuales. Pueden no existir legítimamente en el momento de la inspección (p. ej. un bridge aún sin puertos), por lo que el análisis nunca propone eliminarlos — solo NICs físicas."
|
||||
},
|
||||
@@ -60,7 +60,7 @@
|
||||
},
|
||||
{
|
||||
"title": "2. Confirmar la lista a eliminar",
|
||||
"body": "Lista exactamente qué bloques de interfaz física se van a eliminar. Si, entre el análisis y la limpieza, las NICs han reaparecido (p. ej. has reasentado una tarjeta), el flujo sale con <em>\"No cleanup needed.\"</em>",
|
||||
"body": "Lista exactamente qué bloques de interfaz física se eliminarán. Si las NIC han reaparecido entre el análisis y la limpieza, por ejemplo al volver a insertar una tarjeta, el proceso termina con <em>«No se necesita limpieza»</em>.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
@@ -91,7 +91,7 @@
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Solución de problemas",
|
||||
"notFoundTitle": "El análisis muestra mi NIC nueva como \"NOT FOUND\"",
|
||||
"notFoundTitle": "El análisis muestra mi NIC nueva como «NO ENCONTRADO»",
|
||||
"notFoundBody": "El kernel ve el dispositivo con un nombre distinto al que hay en el fichero. Ejecuta <code>ip link show</code> para obtener el nombre real. Este es exactamente el caso en el que <link>Nombres persistentes de interfaz</link> evitaría el problema de aquí en adelante.",
|
||||
"tooMuchTitle": "La limpieza eliminó demasiado (un bloque que quería conservar)",
|
||||
"tooMuchBody": "Restaura desde el backup impreso en el paso 5:",
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Diagnóstico | ProxMenux Documentation",
|
||||
"description": "Tres comprobaciones de diagnóstico puntuales de solo lectura: Mostrar tabla de rutas, Test de conectividad y Diagnóstico avanzado. Pura inspección — nunca escribe en /etc/network/interfaces y nunca ejecuta un comando modificador (con una excepción explícita y opt-in para purgar NetworkManager cuando se detecta).",
|
||||
"ogTitle": "Diagnóstico | ProxMenux Documentation",
|
||||
"title": "Diagnóstico | Documentación de ProxMenux",
|
||||
"description": "Tres comprobaciones de diagnóstico puntuales de solo lectura: Mostrar tabla de rutas, Test de conectividad y Diagnóstico avanzado. Pura inspección: nunca escribe en /etc/network/interfaces ni ejecuta comandos modificadores, con una excepción explícita que requiere tu aceptación para purgar NetworkManager si se detecta.",
|
||||
"ogTitle": "Diagnóstico | Documentación de ProxMenux",
|
||||
"ogDescription": "Diagnóstico de red de solo lectura para el host Proxmox: rutas, alcanzabilidad, estadísticas avanzadas."
|
||||
},
|
||||
"header": {
|
||||
@@ -21,12 +21,12 @@
|
||||
"connectivity": {
|
||||
"heading": "Test de conectividad",
|
||||
"intro": "Envía dos sondas ICMP a tres destinos en secuencia y reporta cada uno. Luego ejecuta un <code>nslookup google.com</code> para verificar la resolución DNS independientemente de ICMP.",
|
||||
"headerTest": "Test",
|
||||
"headerTest": "Prueba",
|
||||
"headerTarget": "Destino",
|
||||
"headerConfirms": "Qué confirma",
|
||||
"rows": [
|
||||
{
|
||||
"test": "Google DNS",
|
||||
"test": "DNS de Google",
|
||||
"target": "8.8.8.8",
|
||||
"confirms": "Alcanzabilidad externa por IP anycast conocida"
|
||||
},
|
||||
@@ -36,7 +36,7 @@
|
||||
"confirms": "Segunda opinión independiente si Google bloquea ICMP"
|
||||
},
|
||||
{
|
||||
"test": "Gateway",
|
||||
"test": "Pasarela",
|
||||
"target": "(ruta por defecto)",
|
||||
"confirms": "Conectividad L2 / L3 con el router local"
|
||||
},
|
||||
@@ -53,7 +53,7 @@
|
||||
"heading": "Diagnóstico avanzado",
|
||||
"intro": "Agrega estadísticas de red a nivel global y ejecuta una batería de comprobaciones de problemas comunes. Reporta el número de conexiones activas, puertos en escucha, total de interfaces y señala dos antipatrones explícitamente:",
|
||||
"items": [
|
||||
"<strong>NetworkManager corriendo en un host Proxmox.</strong> NetworkManager y el <code>ifupdown</code> de Proxmox entran en conflicto — los dos intentan gestionar interfaces, lo que provoca bridges que flapean o se niegan a levantar. Si se detecta, la herramienta ofrece un prompt interactivo para detenerlo, deshabilitarlo y purgarlo (es el <em>único</em> diagnóstico que puede modificar el sistema, y solo tras consentimiento explícito).",
|
||||
"<strong>NetworkManager ejecutándose en un host Proxmox.</strong> NetworkManager y el <code>ifupdown</code> de Proxmox entran en conflicto: ambos intentan gestionar las interfaces, lo que provoca bridges con caídas intermitentes o que no se activan. Si se detecta, la herramienta ofrece una confirmación interactiva para detenerlo, deshabilitarlo y purgarlo (es el <em>único</em> diagnóstico que puede modificar el sistema, y solo tras consentimiento explícito).",
|
||||
"<strong>Direcciones IP duplicadas en distintas interfaces.</strong> Dos interfaces con la misma IPv4 causan conectividad intermitente extremadamente difícil de depurar desde dentro de la VM. Se detecta vía <code>ip -4 addr show | sort | uniq -d</code>."
|
||||
],
|
||||
"nmTitle": "El prompt de NetworkManager es la única acción modificadora aquí",
|
||||
@@ -80,7 +80,7 @@
|
||||
"tail": " — cuando un vmbrX se queda sin su puerto físico."
|
||||
},
|
||||
{
|
||||
"label": "Análisis de config y limpieza guiada",
|
||||
"label": "Análisis de configuración y limpieza guiada",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — cuando una NIC antigua sigue declarada pero ya no está."
|
||||
},
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Gestión de red en Proxmox — bridges, bonds, diagnóstico, reparación | ProxMenux",
|
||||
"description": "Diagnóstico de solo lectura, flujos de analizar-y-sugerir y reparaciones guiadas para la stack de red Debian / Proxmox (/etc/network/interfaces). Inspecciona bridges y bonds, ejecuta herramientas de monitorización en vivo, persiste nombres de interfaz, hace backup y reinicia la red de forma segura — con backups obligatorios y previsualizaciones paso a paso.",
|
||||
"description": "Diagnóstico de solo lectura, análisis con propuestas y reparaciones guiadas para la pila de red Debian / Proxmox (/etc/network/interfaces). Inspecciona bridges y bonds, ejecuta herramientas de monitorización en vivo, fija nombres de interfaz, crea backups y reinicia la red de forma segura, con backups obligatorios y vistas previas paso a paso.",
|
||||
"ogTitle": "Gestión de red en Proxmox — bridges, bonds, diagnóstico, reparación",
|
||||
"ogDescription": "Diagnóstico, análisis y reparaciones guiadas para la stack de red de Proxmox con backups obligatorios y previsualizaciones paso a paso.",
|
||||
"ogDescription": "Diagnóstico, análisis y reparaciones guiadas para la pila de red de Proxmox con backups obligatorios y vistas previas paso a paso.",
|
||||
"twitterTitle": "Gestión de red en Proxmox | ProxMenux",
|
||||
"twitterDescription": "Bridges, bonds, diagnóstico y reparaciones guiadas para la stack de red de Proxmox con backups obligatorios."
|
||||
"twitterDescription": "Bridges, bonds, diagnóstico y reparaciones guiadas para la pila de red de Proxmox con backups obligatorios."
|
||||
},
|
||||
"header": {
|
||||
"title": "Gestión de red",
|
||||
"description": "Diagnóstico de solo lectura, informes de analizar-y-sugerir y reparaciones guiadas para la stack clásica de red Debian/Proxmox. Cada flujo destructivo hace primero un backup y previsualiza los cambios exactos antes de aplicarlos.",
|
||||
"description": "Diagnóstico de solo lectura, informes de análisis con propuestas y reparaciones guiadas para la pila de red clásica de Debian/Proxmox. Cada operación destructiva hace primero un backup y muestra los cambios exactos antes de aplicarlos.",
|
||||
"section": "Red"
|
||||
},
|
||||
"intro": {
|
||||
@@ -52,8 +52,8 @@
|
||||
]
|
||||
}
|
||||
},
|
||||
"classicTitle": "Solo stack clásica",
|
||||
"classicBody": "Cada función de análisis y reparación comprueba el gestor de red activo antes de tocar nada. Si el host usa <strong>netplan</strong>, <strong>systemd-networkd</strong> o <strong>NetworkManager</strong>, la herramienta aborta inmediatamente con un mensaje claro — el menú solo soporta la stack clásica de Debian/Proxmox en <code>/etc/network/interfaces</code>. Es intencional: editar un fichero de netplan con reglas escritas para <code>ifupdown</code> corrompería silenciosamente la configuración.",
|
||||
"classicTitle": "Solo la pila de red clásica",
|
||||
"classicBody": "Cada función de análisis y reparación comprueba el gestor de red activo antes de tocar nada. Si el host usa <strong>netplan</strong>, <strong>systemd-networkd</strong> o <strong>NetworkManager</strong>, la herramienta se detiene inmediatamente con un mensaje claro: el menú solo admite la pila clásica de Debian/Proxmox en <code>/etc/network/interfaces</code>. Es intencional: editar un fichero de netplan con reglas escritas para <code>ifupdown</code> corrompería silenciosamente la configuración.",
|
||||
"backups": {
|
||||
"heading": "Dónde van los backups",
|
||||
"intro": "Cada reparación guiada, restauración o backup manual escribe una copia con timestamp de <code>/etc/network/interfaces</code> en <code>/var/backups/proxmenux/</code>:",
|
||||
@@ -61,7 +61,7 @@
|
||||
},
|
||||
"readOnlySection": {
|
||||
"heading": "Inspección de solo lectura",
|
||||
"body": "El punto de partida cuando algo huele raro. Pura inspección — nunca escribe en <code>/etc/network/interfaces</code> y nunca ejecuta un comando modificador (con una única excepción explícita y opt-in para purgar NetworkManager cuando se detecta). Seguro de usar por SSH en cualquier momento.",
|
||||
"body": "El punto de partida cuando algo parece ir mal. Pura inspección: nunca escribe en <code>/etc/network/interfaces</code> ni ejecuta comandos que modifiquen el sistema (con una única excepción explícita, que requiere tu aceptación, para purgar NetworkManager cuando se detecta). Se puede usar por SSH en cualquier momento de forma segura.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Diagnóstico",
|
||||
@@ -82,7 +82,7 @@
|
||||
"description": "Detecta bridges vmbrX con puertos ausentes o inválidos (típico tras una re-enumeración PCI). Muestra primero un informe; solo repara cuando aceptas el flujo guiado de 5 pasos."
|
||||
},
|
||||
{
|
||||
"title": "Análisis de config y limpieza guiada",
|
||||
"title": "Análisis de configuración y limpieza guiada",
|
||||
"description": "Encuentra interfaces físicas declaradas en /etc/network/interfaces que ya no existen (configs huérfanas que dejan cambios de hardware). Las reporta y ofrece una eliminación guiada."
|
||||
}
|
||||
]
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Herramientas de monitorización en vivo | ProxMenux Documentation",
|
||||
"title": "Herramientas de monitorización en vivo | Documentación de ProxMenux",
|
||||
"description": "Tres lanzadores interactivos de monitorización de red: iftop (ancho de banda en tiempo real por par de hosts), iptraf-ng (monitor de tráfico multimodo) e iperf3 (test de ancho de banda, modo servidor / cliente). Cada uno se instala la primera vez que se usa.",
|
||||
"ogTitle": "Herramientas de monitorización en vivo | ProxMenux Documentation",
|
||||
"ogTitle": "Herramientas de monitorización en vivo | Documentación de ProxMenux",
|
||||
"ogDescription": "Monitorización interactiva de red y test de ancho de banda para el host Proxmox: iftop, iptraf-ng, iperf3."
|
||||
},
|
||||
"header": {
|
||||
"title": "Herramientas de monitorización en vivo",
|
||||
"description": "Tres lanzadores interactivos para observación de red en tiempo real y medición de ancho de banda: iftop, iptraf-ng e iperf3. Cada herramienta se autoinstala desde apt la primera vez que se usa, corre en primer plano y se sale con la tecla documentada. De solo lectura sobre la configuración del host — solo observan el tráfico.",
|
||||
"description": "Tres lanzadores interactivos para observar la red en tiempo real y medir el ancho de banda: iftop, iptraf-ng e iperf3. Cada herramienta se instala automáticamente desde apt la primera vez que se usa, se ejecuta en primer plano y se cierra con la tecla indicada. No cambian la configuración de red del host; iperf3 genera tráfico de prueba.",
|
||||
"section": "Red"
|
||||
},
|
||||
"intro": {
|
||||
@@ -69,7 +69,7 @@
|
||||
}
|
||||
],
|
||||
"exit": "<strong>Salir:</strong> pulsa <kbd>x</kbd> desde cualquier vista (o <kbd>Q</kbd> desde el menú principal). ProxMenux muestra un diálogo recordatorio antes de lanzarlo.",
|
||||
"logTitle": "El logging captura a fichero",
|
||||
"logTitle": "Guardar las capturas en un fichero",
|
||||
"logBody": "Cada modo ofrece registrar las estadísticas capturadas en <code>/var/log/iptraf-ng/</code>. Útil si necesitas un registro de un pico de tráfico — déjalo corriendo, vuelca al fichero, revisa el fichero después en lugar de intentar leer la pantalla en vivo."
|
||||
},
|
||||
"iperf3": {
|
||||
@@ -81,24 +81,24 @@
|
||||
"headerCli": "CLI equivalente",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Server",
|
||||
"mode": "Servidor",
|
||||
"behaviour": "Escucha en TCP 5201 e imprime resultados de cada test entrante. Se detiene con Ctrl+C.",
|
||||
"cli": "iperf3 -s"
|
||||
},
|
||||
{
|
||||
"mode": "Client",
|
||||
"mode": "Cliente",
|
||||
"behaviour": "Pide la IP / hostname del servidor, conecta, ejecuta un test por defecto de 10 segundos e imprime el informe.",
|
||||
"cli": "iperf3 -c <target>"
|
||||
}
|
||||
],
|
||||
"workflowIntro": "Flujo típico para probar un enlace 10 GbE entre dos hosts Proxmox:",
|
||||
"workflow": [
|
||||
"En el host A, abre el menú Red → <em>Test de ancho de banda (iperf3)</em> → elige <strong>Server</strong>.",
|
||||
"En el host B, abre la misma entrada de menú → elige <strong>Client</strong> → introduce la IP del host A.",
|
||||
"En el host A, abre el menú Red → <em>Test de ancho de banda (iperf3)</em> → elige <strong>Servidor</strong>.",
|
||||
"En el host B, abre la misma entrada de menú → elige <strong>Cliente</strong> → introduce la IP del host A.",
|
||||
"Espera 10 segundos. Compara la tasa reportada con el máximo teórico del enlace."
|
||||
],
|
||||
"sample": "Salida de ejemplo del cliente:",
|
||||
"flagsTitle": "Flags útiles a mano (desde una shell)",
|
||||
"flagsTitle": "Opciones útiles para ejecutar a mano desde una shell",
|
||||
"flagsBody": "<code>-t 60</code> test más largo (60s en lugar de los 10s por defecto), <code>-P 4</code> 4 streams en paralelo (satura más rápido), <code>-R</code> dirección inversa (servidor → cliente), <code>-u -b 100M</code> test UDP a 100 Mbit/s (para mediciones de jitter / pérdida de paquetes), <code>-p 5202</code> usa un puerto distinto (varios tests en paralelo). <code>man iperf3</code> para el set completo.",
|
||||
"firewallTitle": "Abre el puerto del firewall en el servidor",
|
||||
"firewallBody": "El servidor escucha en TCP <strong>5201</strong> por defecto. Si corres el servidor dentro de un host Proxmox con un firewall estricto (a nivel de datacenter o de host), permite entrada TCP 5201 desde la IP del cliente durante el test y luego ciérralo. Lo mismo aplica a <code>nftables</code> / <code>iptables</code> en hosts bare metal."
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Nombres persistentes de interfaz | ProxMenux Documentation",
|
||||
"title": "Nombres persistentes de interfaz | Documentación de ProxMenux",
|
||||
"description": "Fija los nombres de interfaz de Proxmox (eno1, enp3s0, …) a direcciones MAC mediante ficheros .link de systemd para que los nombres sobrevivan a la re-enumeración PCI, actualizaciones de kernel y al añadir / quitar otras NICs.",
|
||||
"ogTitle": "Nombres persistentes de interfaz | ProxMenux Documentation",
|
||||
"ogTitle": "Nombres persistentes de interfaz | Documentación de ProxMenux",
|
||||
"ogDescription": "Evita que los nombres de interfaz de Proxmox cambien al modificar el hardware. Usa ficheros .link de systemd basados en la dirección MAC."
|
||||
},
|
||||
"header": {
|
||||
@@ -16,7 +16,7 @@
|
||||
},
|
||||
"problem": {
|
||||
"heading": "El problema que resuelve",
|
||||
"intro": "Linux deriva los nombres de interfaz por defecto a partir de la topología PCI — <code>eno1</code> = onboard, <code>enp3s0</code> = la tarjeta en el bus PCI 3, slot 0, etc. El esquema de naming es determinista <em>dado el mismo layout de hardware</em>. Cambia el layout y los nombres se mueven:",
|
||||
"intro": "Linux obtiene los nombres de interfaz predeterminados a partir de la topología PCI: <code>eno1</code> = integrada en placa, <code>enp3s0</code> = la tarjeta en el bus PCI 3, slot 0, etc. El esquema de nombres es determinista <em>con la misma disposición de hardware</em>. Si cambia la disposición, cambian los nombres:",
|
||||
"items": [
|
||||
"Añade una GPU delante de una NIC existente → el número de bus de la NIC puede cambiar → el nombre cambia.",
|
||||
"Mueve una tarjeta a otro slot PCIe → el nombre cambia.",
|
||||
@@ -46,7 +46,7 @@
|
||||
"headerWhy": "Por qué",
|
||||
"rows": [
|
||||
{
|
||||
"type": "NIC onboard / PCIe",
|
||||
"type": "NIC integrada / PCIe",
|
||||
"behaviour": "Se escribe fichero <code>.link</code>",
|
||||
"why": "Respaldada por un dispositivo PCI real — el caso para el que está la herramienta"
|
||||
},
|
||||
@@ -56,7 +56,7 @@
|
||||
"why": "Tiene una MAC real y se beneficia de la estabilidad de nombre"
|
||||
},
|
||||
{
|
||||
"type": "Bridges (vmbrX)",
|
||||
"type": "Puentes (vmbrX)",
|
||||
"behaviour": "Se omite",
|
||||
"why": "Virtual; el nombre viene de <code>/etc/network/interfaces</code>"
|
||||
},
|
||||
@@ -87,7 +87,7 @@
|
||||
"intro": "Si <code>/etc/systemd/network/</code> ya contiene ficheros <code>.link</code> (de una ejecución anterior u otra herramienta), se copian a un directorio de backup con timestamp antes de generar los nuevos:",
|
||||
"outro": "Para hacer rollback: copia los ficheros desde el directorio de backup y reinicia.",
|
||||
"rebootTitle": "Tiene efecto en el siguiente reinicio, no inmediatamente",
|
||||
"rebootBody": "Los cambios en ficheros <code>.link</code> solo se aplican en el arranque, cuando udev re-enumera los dispositivos. La herramienta reporta <em>\"Changes will apply after reboot\"</em> por este motivo. Renombrar una interfaz en vivo es arriesgado y no se intenta: un <code>vmbr0</code> activo con miembros tendría que reconfigurarse atómicamente, por eso la operación se difiere al siguiente arranque limpio."
|
||||
"rebootBody": "Los cambios en ficheros <code>.link</code> solo se aplican en el arranque, cuando udev vuelve a enumerar los dispositivos. Por eso la herramienta indica <em>«Los cambios se aplicarán después del reinicio»</em>. No intenta renombrar una interfaz en vivo por el riesgo que supone: un <code>vmbr0</code> activo con interfaces miembro tendría que reconfigurarse de forma atómica, así que la operación se aplaza al siguiente arranque limpio."
|
||||
},
|
||||
"afterReboot": {
|
||||
"heading": "Tras el reinicio",
|
||||
@@ -100,11 +100,11 @@
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Solución de problemas",
|
||||
"emptyTitle": "\"No physical interfaces found\" tras ejecutar la herramienta",
|
||||
"emptyTitle": "«No se encontraron interfaces físicas» tras ejecutar la herramienta",
|
||||
"emptyBody": "El host no tiene interfaces respaldadas por PCI / phy80211 visibles para el kernel. Confirma con <code>ls -l /sys/class/net/</code> — cada entrada debería tener un symlink <code>device</code> (PCI) o una entrada <code>phy80211</code> (Wi-Fi). Si faltan ambos para lo que debería ser una NIC real, el driver no está cargado.",
|
||||
"noChangeTitle": "Tras el reinicio, los nombres no han cambiado como esperaba",
|
||||
"noChangeBody": "Comprueba que el fichero está presente y bien formado: <code>cat /etc/systemd/network/10-<iface>.link</code>. Después mira los logs de udev: <code>journalctl -u systemd-udevd -b | grep -i link</code>. Una causa habitual es un parámetro de kernel <code>net.ifnames=0</code> residual que deshabilita el naming predictivo por completo — quítalo de <code>/etc/default/grub</code>, ejecuta <code>update-grub</code> y reinicia.",
|
||||
"undoTitle": "Quiero deshacer el naming persistente",
|
||||
"undoTitle": "Quiero deshacer los nombres persistentes",
|
||||
"undoBody": "O bien borra los ficheros <code>.link</code> (<code>rm /etc/systemd/network/10-*.link</code>) o restaura desde el directorio de backup generado en la ejecución anterior. Reinicia para aplicar."
|
||||
},
|
||||
"related": {
|
||||
@@ -116,7 +116,7 @@
|
||||
"tailRich": " — el camino de recuperación cuando los nombres <em>ya</em> se han movido."
|
||||
},
|
||||
{
|
||||
"label": "Análisis de config y limpieza guiada",
|
||||
"label": "Análisis de configuración y limpieza guiada",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — para eliminar bloques huérfanos dejados por los cambios de nombre."
|
||||
},
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Cómo se traduce una imagen OCI | ProxMenux",
|
||||
"description": "Del repositorio de la imagen y su archivo Compose a una plantilla revisable, un plan de despliegue y un LXC nativo de Proxmox VE, sin Docker dentro."
|
||||
"title": "Cómo se adapta una imagen OCI | ProxMenux",
|
||||
"description": "Del repositorio de la imagen y su archivo Compose a una plantilla que puedes revisar, un plan de despliegue y un LXC nativo de Proxmox VE, sin Docker dentro."
|
||||
},
|
||||
"header": {
|
||||
"title": "Cómo se traduce una imagen OCI",
|
||||
"description": "Del repositorio de la imagen y su archivo Compose a una plantilla revisable, un plan de despliegue y un LXC nativo, sin instalar Docker dentro.",
|
||||
"title": "Cómo se adapta una imagen OCI",
|
||||
"description": "Del repositorio de la imagen y su archivo Compose a una plantilla que puedes revisar, un plan de despliegue y un LXC nativo, sin instalar Docker dentro.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "pipeline",
|
||||
"title": "La cadena de traducción",
|
||||
"title": "El proceso de adaptación",
|
||||
"blocks": [
|
||||
{
|
||||
"mermaid": {
|
||||
@@ -20,7 +20,7 @@
|
||||
"repo": "Repositorio de la imagen",
|
||||
"converter": "Conversor",
|
||||
"template": "Plantilla JSON",
|
||||
"blockers": "¿Sin bloqueos?",
|
||||
"blockers": "¿Sin impedimentos?",
|
||||
"no": "No",
|
||||
"yes": "Sí",
|
||||
"review": "Revisión / overlay",
|
||||
@@ -30,7 +30,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "El conversor lee la imagen y el archivo Compose que publica su proyecto y escribe una plantilla JSON. Una plantilla con bloqueos sin traducir pasa por revisión, donde un overlay curado los resuelve, antes de publicarse en el catálogo. Solo las plantillas sin bloqueos se ofrecen para instalar."
|
||||
"p": "El conversor lee la imagen y el archivo Compose publicados por el proyecto y genera una plantilla JSON. Si quedan requisitos que no se han podido adaptar y que impiden la instalación, la plantilla pasa por una revisión: un archivo de ajustes revisados, llamado overlay, los resuelve antes de publicarla en el catálogo. Solo se ofrecen para instalar las plantillas que no tienen impedimentos pendientes."
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -41,10 +41,26 @@
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{ "icon": "archive", "title": "Identidad de la imagen", "body": "Repositorio, etiqueta rolling, arquitectura, digest resuelto y revisión del origen." },
|
||||
{ "icon": "braces", "title": "Contrato del contenedor", "body": "Entrypoint, Cmd, entorno, usuario, directorio de trabajo, señal de parada, puertos y volúmenes." },
|
||||
{ "icon": "layers", "title": "Traducción a Proxmox VE", "body": "Recursos, seguridad, puntos de montaje, dispositivos, sysctls, healthchecks y las adaptaciones que necesita cada uno, con su motivo." },
|
||||
{ "icon": "shield", "title": "Compatibilidad", "body": "Claves admitidas, bloqueos sin traducir y el estado de cada validación." }
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Identidad de la imagen",
|
||||
"body": "Repositorio, etiqueta de actualización continua, arquitectura, digest resuelto y revisión de origen."
|
||||
},
|
||||
{
|
||||
"icon": "braces",
|
||||
"title": "Contrato del contenedor",
|
||||
"body": "Entrypoint, Cmd, entorno, usuario, directorio de trabajo, señal de parada, puertos y volúmenes."
|
||||
},
|
||||
{
|
||||
"icon": "layers",
|
||||
"title": "Adaptación a Proxmox VE",
|
||||
"body": "Recursos, seguridad, puntos de montaje, dispositivos, sysctls, comprobaciones de estado y las adaptaciones necesarias en cada caso, con su justificación."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Compatibilidad",
|
||||
"body": "Claves compatibles, requisitos pendientes de adaptar que impiden la instalación y estado de cada validación."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -56,12 +72,32 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Origen", "Ejemplo", "Resultado nativo"],
|
||||
"headers": [
|
||||
"Origen",
|
||||
"Ejemplo",
|
||||
"Resultado nativo"
|
||||
],
|
||||
"rows": [
|
||||
["Metadatos OCI", "<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>", "Proxmox VE los importa al crear el CT"],
|
||||
["Docker Compose", "<code>environment</code>, <code>volumes</code>, <code>devices</code>", "entradas de entorno del LXC, <code>mpN</code> y <code>devN</code>"],
|
||||
["Perfil de ProxMenux", "GPU, healthcheck, credenciales", "preguntas y adaptaciones revisadas"],
|
||||
["Usuario", "VMID, almacenamiento, red", "el contrato de la instancia"]
|
||||
[
|
||||
"Metadatos OCI",
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
|
||||
"Proxmox VE los importa al crear el CT"
|
||||
],
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
|
||||
"Entradas de entorno de LXC, <code>mpN</code> y <code>devN</code>"
|
||||
],
|
||||
[
|
||||
"Perfil de ProxMenux",
|
||||
"GPU, comprobación de estado, credenciales",
|
||||
"Preguntas y adaptaciones revisadas"
|
||||
],
|
||||
[
|
||||
"Usuario",
|
||||
"VMID, almacenamiento, red",
|
||||
"El contrato de la instancia"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -69,18 +105,39 @@
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Qué ocurre durante una instalación",
|
||||
"title": "Qué ocurre durante la instalación",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Resolver", "body": "Se consulta el registro, se selecciona la arquitectura del host y se fija el digest efectivo de la etiqueta rolling." },
|
||||
{ "title": "Descargar y verificar", "body": "Skopeo descarga la imagen como archivo OCI, y cada capa se comprueba contra su digest y se descomprime antes de crear nada. Una descarga dañada se repite una vez antes de detener la instalación." },
|
||||
{ "title": "Construir", "body": "<code>pct create</code> construye el rootfs a partir del archivo y conserva los metadatos oficiales de proceso de la imagen." },
|
||||
{ "title": "Conectar", "body": "Se añaden los volúmenes, la red, el entorno, los dispositivos y los perfiles de seguridad declarados." },
|
||||
{ "title": "Consola", "body": "La salida de consola del contenedor se guarda en el host, y la consola de Proxmox VE abre un shell cuando la imagen incluye uno." },
|
||||
{ "title": "Comprobar", "body": "El primer arranque espera una dirección y la respuesta del servicio; un fallo no se presenta como instalación correcta." },
|
||||
{ "title": "Registrar", "body": "La configuración efectiva se escribe en el contrato de la instancia que usan las actualizaciones y las recreaciones." }
|
||||
{
|
||||
"title": "Resolver la referencia",
|
||||
"body": "Se consulta el registro, se selecciona la arquitectura del host y se fija el digest concreto al que apunta la etiqueta de actualización continua."
|
||||
},
|
||||
{
|
||||
"title": "Descargar y verificar",
|
||||
"body": "Skopeo descarga la imagen como un archivo OCI. Antes de crear nada, se verifica el digest de cada capa y se descomprimen todas las capas. Si la descarga está dañada, se vuelve a descargar una vez antes de detener la instalación."
|
||||
},
|
||||
{
|
||||
"title": "Crear el sistema de archivos",
|
||||
"body": "<code>pct create</code> crea el rootfs a partir del archivo y conserva los metadatos oficiales del proceso de la imagen."
|
||||
},
|
||||
{
|
||||
"title": "Conectar los recursos",
|
||||
"body": "Se aplican los volúmenes, la red, el entorno, los dispositivos y los perfiles de seguridad declarados."
|
||||
},
|
||||
{
|
||||
"title": "Consola",
|
||||
"body": "La salida de consola del contenedor se guarda en el host. La consola de Proxmox VE abre una shell si la imagen incluye una."
|
||||
},
|
||||
{
|
||||
"title": "Comprobar",
|
||||
"body": "En el primer arranque se espera a que el contenedor tenga una dirección y el servicio responda. Si falla, la instalación no se da por completada correctamente."
|
||||
},
|
||||
{
|
||||
"title": "Registrar la configuración",
|
||||
"body": "La configuración efectiva se guarda en el contrato de la instancia que utilizan las actualizaciones y las recreaciones."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -89,7 +146,7 @@
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Ejemplo: una imagen con /config y /downloads",
|
||||
"intro": "Una definición habitual de Compose y la configuración de Proxmox VE en la que se convierte. Las rutas que espera la aplicación no cambian.",
|
||||
"intro": "Una definición Compose habitual y la configuración de Proxmox VE que se genera a partir de ella. Las rutas que espera la aplicación no cambian.",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
@@ -99,14 +156,14 @@
|
||||
"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 (extracto)",
|
||||
"title": "/etc/pve/lxc/VMID.conf (fragmento)",
|
||||
"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> es un segundo disco que pertenece al contenedor, con el nombre <code>vm-VMID-disk-N</code> en el almacenamiento elegido. Se monta en <code>/config</code> y, con <code>backup=1</code>, forma parte del backup del contenedor. <code>mp1</code> no crea ningún disco: enlaza el directorio del host <code>/srv/downloads</code> con <code>/downloads</code> dentro del LXC. El puerto 8080 no se mapea: el LXC tiene una dirección propia y el servicio responde en ella."
|
||||
"p": "<code>mp0</code> es un segundo disco que pertenece al contenedor, con el nombre <code>vm-VMID-disk-N</code> en el almacenamiento seleccionado. Se monta en <code>/config</code> y, con <code>backup=1</code>, forma parte del backup del contenedor. <code>mp1</code> no crea ningún disco: monta el directorio del host <code>/srv/downloads</code> en <code>/downloads</code> dentro del LXC. El puerto 8080 no se mapea: el LXC tiene su propia dirección y el servicio responde en ella."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Instalar una imagen que no está en el catálogo | ProxMenux",
|
||||
"description": "Traducción de una imagen OCI desde un archivo Compose, una URL, un comando docker run o una referencia de imagen, con revisión de lo que ProxMenux puede reproducir antes de instalarla."
|
||||
"title": "Instalar una imagen fuera del catálogo | ProxMenux",
|
||||
"description": "Adapta una imagen OCI a partir de un archivo Compose, una URL, un comando docker run o una referencia de imagen, y revisa qué puede reproducir ProxMenux antes de instalarla."
|
||||
},
|
||||
"header": {
|
||||
"title": "Instalar una imagen que no está en el catálogo",
|
||||
"description": "Una imagen propia se traduce desde su archivo Compose, un comando docker run o solo su referencia, y el resultado se presenta para revisión antes de crear ningún LXC.",
|
||||
"title": "Instalar una imagen que no esté en el catálogo",
|
||||
"description": "Tu imagen se adapta a partir de su archivo Compose, de un comando docker run o de su referencia. El resultado se muestra para que lo revises antes de crear ningún LXC.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
@@ -14,8 +14,8 @@
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "El mismo conversor, el mismo instalador",
|
||||
"body": "La opción <strong>Instalar una imagen que no está en el catálogo</strong> utiliza el conversor y el instalador de las plantillas del catálogo. La diferencia es que el contrato se genera en ese momento a partir de la definición aportada y se valida antes de crear ningún LXC."
|
||||
"title": "El mismo conversor y el mismo instalador",
|
||||
"body": "La opción <strong>Instalar una imagen que no esté en el catálogo</strong> utiliza el mismo conversor y el mismo instalador que las plantillas del catálogo. La diferencia es que el contrato se genera en ese momento a partir de la definición proporcionada y se valida antes de crear ningún LXC."
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -23,45 +23,92 @@
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "Cómo se describe la imagen",
|
||||
"intro": "La primera pantalla pregunta cómo se describe la imagen. Cuatro formas aportan una definición que se traduce, una quinta usa solo el nombre de la imagen y tres reciben un oci-compose ya escrito.",
|
||||
"intro": "La primera pantalla pregunta cómo vas a describir la imagen. Cuatro opciones reciben una definición que se adapta, una quinta usa solo el nombre de la imagen y otras tres leen un oci-compose ya escrito.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Opción", "Qué lee"],
|
||||
"headers": [
|
||||
"Opción",
|
||||
"Qué lee"
|
||||
],
|
||||
"rows": [
|
||||
["Pegar su archivo Compose en la terminal", "El YAML se pega en la terminal y termina con Ctrl+D."],
|
||||
["Leer su archivo Compose desde un archivo de este host", "Una ruta del nodo, <code>/root/docker-compose.yml</code> por defecto. El archivo debe existir y ocupar como máximo 256 KiB."],
|
||||
["Descargar su archivo Compose desde una dirección", "Una dirección <code>http://</code> o <code>https://</code> que sirva el YAML sin procesar. Se descargan como máximo 256 KiB."],
|
||||
["Pegar su comando docker run en la terminal", "El comando que publica el proyecto. Se traducen puertos, entorno, volúmenes, dispositivos, capacidades, usuario, memoria compartida y el resto de opciones admitidas."],
|
||||
["Solo la referencia de la imagen, sin archivo Compose", "Una referencia como <code>ghcr.io/user/application:latest</code>. Se consulta el registro y se conservan los metadatos OCI de la imagen."],
|
||||
["Pegar un oci-compose en la terminal", "El JSON se pega en la terminal y termina con Ctrl+D. No se traduce: se comprueba y se instala tal como está escrito."],
|
||||
["Leer un oci-compose desde un archivo de este host", "Un archivo JSON del nodo, <code>/root/oci-compose.json</code> por defecto, de 2 MiB como máximo."],
|
||||
["Descargar un oci-compose desde una dirección", "Una dirección <code>http://</code> o <code>https://</code> que sirva el archivo JSON. Se descargan como máximo 2 MiB."]
|
||||
[
|
||||
"Pegar su archivo Compose en la terminal",
|
||||
"Pega el YAML en la terminal y termina con Ctrl+D."
|
||||
],
|
||||
[
|
||||
"Leer su archivo Compose desde este host",
|
||||
"Una ruta del nodo; la predeterminada es <code>/root/docker-compose.yml</code>. El archivo debe existir y no superar los 256 KiB."
|
||||
],
|
||||
[
|
||||
"Descargar su archivo Compose desde una dirección",
|
||||
"Una dirección <code>http://</code> o <code>https://</code> que sirva el YAML sin procesar. Se descargan como máximo 256 KiB."
|
||||
],
|
||||
[
|
||||
"Pegar su comando docker run en la terminal",
|
||||
"El comando publicado por el proyecto. Se adaptan los puertos, el entorno, los volúmenes, los dispositivos, las capabilities, el usuario, la memoria compartida y las demás opciones compatibles."
|
||||
],
|
||||
[
|
||||
"Solo la referencia de imagen, sin archivo Compose",
|
||||
"Una referencia como <code>ghcr.io/user/application:latest</code>. Se consulta el registro y se conservan los metadatos OCI de la imagen."
|
||||
],
|
||||
[
|
||||
"Pegar un oci-compose en la terminal",
|
||||
"Pega el JSON en la terminal y termina con Ctrl+D. No se convierte: se valida y se instala tal como está escrito."
|
||||
],
|
||||
[
|
||||
"Leer un oci-compose desde este host",
|
||||
"Un archivo JSON del nodo, <code>/root/oci-compose.json</code> por defecto, de un máximo de 2 MiB."
|
||||
],
|
||||
[
|
||||
"Descargar un oci-compose desde una dirección",
|
||||
"Una dirección <code>http://</code> o <code>https://</code> que sirva el archivo JSON. Se descargan como máximo 2 MiB."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-source-menu.png",
|
||||
"alt": "Menú que pregunta cómo se describe una imagen que no está en el catálogo",
|
||||
"caption": "Las formas de describir una imagen que no está en el catálogo."
|
||||
"alt": "Menú para elegir cómo describir una imagen que no está en el catálogo",
|
||||
"caption": "Formas de describir una imagen fuera del catálogo."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "reference-only",
|
||||
"title": "Qué aporta solo la referencia de la imagen",
|
||||
"intro": "Una imagen lleva sus metadatos de proceso, pero no todo lo que un archivo Compose suele añadir a su alrededor.",
|
||||
"title": "Qué aporta una referencia de imagen por sí sola",
|
||||
"intro": "La imagen contiene los metadatos de su proceso, pero no todo el entorno que suele añadir un archivo Compose.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Se lee de la imagen", "No está en la imagen", "Consecuencia"],
|
||||
"headers": [
|
||||
"Se lee de la imagen",
|
||||
"No está en la imagen",
|
||||
"Consecuencia"
|
||||
],
|
||||
"rows": [
|
||||
["<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> y entorno integrado", "Variables que solo aparecen en la documentación", "Se añaden durante la instalación o con Modificar"],
|
||||
["Volúmenes declarados por la imagen", "Directorios del host que solo nombra un archivo Compose", "Las rutas adicionales se añaden antes de instalar"],
|
||||
["Puertos <code>EXPOSE</code>", "La URL, el protocolo o un healthcheck funcional", "Se confirman el puerto y la forma de comprobar el servicio"],
|
||||
["Arquitecturas y digest del registro", "Dispositivos, privilegios o dependencias externas", "Ninguno se activa sin una definición que lo pida"]
|
||||
[
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> y el entorno incorporado",
|
||||
"Variables que solo figuran en la documentación",
|
||||
"Se añaden durante la instalación o desde Modificar"
|
||||
],
|
||||
[
|
||||
"Volúmenes declarados por la imagen",
|
||||
"Directorios del host que solo se indican en Compose",
|
||||
"Las rutas adicionales se añaden antes de instalar"
|
||||
],
|
||||
[
|
||||
"Puertos <code>EXPOSE</code>",
|
||||
"La URL, el protocolo o la comprobación funcional del servicio",
|
||||
"Se confirman el puerto y la forma de comprobar el servicio"
|
||||
],
|
||||
[
|
||||
"Arquitecturas y digest del registro",
|
||||
"Dispositivos, privilegios o dependencias externas",
|
||||
"No se habilitan sin una definición que los solicite"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -69,29 +116,44 @@
|
||||
},
|
||||
{
|
||||
"id": "review",
|
||||
"title": "Revisión antes de instalar",
|
||||
"intro": "Tras traducir la definición, ProxMenux muestra lo que ha entendido antes de pedir VMID, recursos o almacenamiento.",
|
||||
"title": "Revisar antes de instalar",
|
||||
"intro": "Tras adaptar la definición, ProxMenux muestra cómo la ha interpretado antes de preguntar el VMID, los recursos o el almacenamiento.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Analizar", "body": "Se leen servicios, imagen, puertos, rutas, entorno, dispositivos, seguridad y healthcheck." },
|
||||
{ "title": "Consultar el registro", "body": "La imagen debe existir en su registro, y se enumeran las arquitecturas que publica. Un registro privado se lee con la cuenta guardada para él." },
|
||||
{ "title": "Enumerar lo que no se aplica", "body": "Se enumeran las etiquetas, las redes Docker, los ajustes de Swarm y el resto de claves que no tienen efecto en un LXC." },
|
||||
{ "title": "Bloquear lo que no puede traducirse", "body": "Una clave sin equivalencia segura aparece en <strong>Lo que no puede traducirse</strong> y la instalación no continúa. Nada se descarta en silencio." },
|
||||
{ "title": "Pedir los secretos", "body": "Las variables cuyo nombre corresponde a una contraseña, un token o una clave se convierten en preguntas sensibles de la instalación." }
|
||||
{
|
||||
"title": "Analizar",
|
||||
"body": "Se leen servicios, imagen, puertos, rutas, entorno, dispositivos, seguridad y comprobaciones de estado."
|
||||
},
|
||||
{
|
||||
"title": "Consultar el registro",
|
||||
"body": "La imagen debe existir en el registro y se muestran las arquitecturas publicadas. Si el registro es privado, se utiliza la cuenta guardada para él."
|
||||
},
|
||||
{
|
||||
"title": "Enumerar lo que no se aplica",
|
||||
"body": "Se enumeran las etiquetas, redes de Docker, ajustes de Swarm y otras claves que no tienen efecto en un LXC."
|
||||
},
|
||||
{
|
||||
"title": "Bloquear opciones sin equivalente seguro",
|
||||
"body": "Las claves sin equivalente seguro aparecen en <strong>Opciones sin equivalente</strong> e impiden continuar con la instalación. No se descartan silenciosamente."
|
||||
},
|
||||
{
|
||||
"title": "Solicitar secretos",
|
||||
"body": "Las variables cuyo nombre indica una contraseña, token o clave se solicitan como datos sensibles durante la instalación."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-review.png",
|
||||
"alt": "Resumen de lo que ProxMenux ha entendido de un archivo Compose",
|
||||
"caption": "El resumen que se muestra antes de que la instalación pida VMID y recursos."
|
||||
"alt": "Resumen de cómo ProxMenux ha interpretado el archivo Compose",
|
||||
"caption": "Resumen mostrado antes de que el instalador pregunte el VMID y los recursos."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Tras aceptar el resumen, el recorrido es el del catálogo: nombre, modo predeterminado o avanzado, VMID, CPU, memoria, red, arranque con el nodo, rutas persistentes, rutas adicionales, dispositivos compatibles y resumen final."
|
||||
"p": "Tras aceptar el resumen se sigue el mismo asistente que en el catálogo: nombre, modo predeterminado o avanzado, VMID, CPU, memoria, red, arranque con el nodo, rutas persistentes, rutas adicionales, dispositivos compatibles y resumen final."
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -118,68 +180,79 @@
|
||||
{
|
||||
"id": "oci-compose",
|
||||
"title": "Un oci-compose escrito a mano",
|
||||
"intro": "Un oci-compose es el archivo JSON desde el que se instala una aplicación. El catálogo guarda uno por cada aplicación, y el mismo formato puede escribirse a mano e instalarse con esta opción.",
|
||||
"intro": "Un oci-compose es el archivo JSON a partir del cual se instala una aplicación. El catálogo conserva uno por aplicación. Puedes escribir el mismo formato a mano e instalarlo con esta opción.",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "El que se escribe a mano indica lo que decide su autor: la imagen, sus puertos, variables y volúmenes, y lo que pregunta la instalación. ProxMenux completa el resto al leer el archivo. Puede decir lo que un archivo Compose no puede: el texto de una pregunta, una contraseña generada durante la instalación, un perfil de GPU, el propietario de cada volumen, la comprobación del primer arranque o las credenciales que se muestran al terminar."
|
||||
"p": "Al escribirlo a mano, el autor decide la imagen, los puertos, las variables, los volúmenes y las preguntas de la instalación. ProxMenux completa el resto al leer el archivo. Permite expresar lo que Compose no incluye: el texto de una pregunta, una contraseña generada durante la instalación, un perfil de GPU, el propietario de cada volumen, la comprobación del primer arranque o las credenciales mostradas al final."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Comprobar",
|
||||
"body": "Un archivo con errores no se instala. Cada error indica el campo en el que está, y un archivo que no es JSON válido indica la línea y la columna."
|
||||
"body": "Los archivos con errores no se instalan. Cada error indica el campo afectado; si el JSON no es válido, se muestran la línea y la columna."
|
||||
},
|
||||
{
|
||||
"title": "Revisar",
|
||||
"body": "Un archivo válido muestra lo que instala: imagen, dirección web, puertos, rutas persistentes, las variables que pide la instalación y los archivos que escribe."
|
||||
"body": "Si el archivo es válido, se muestra lo que instalará: imagen, dirección web, puertos, rutas persistentes, variables que solicitará el instalador y archivos que escribirá."
|
||||
},
|
||||
{
|
||||
"title": "Instalar",
|
||||
"body": "La instalación es la de cualquier aplicación del catálogo, con ajustes por defecto o avanzados."
|
||||
"body": "Se utiliza el mismo instalador que para cualquier aplicación del catálogo, con ajustes predeterminados o avanzados."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Un archivo que decide privilegios",
|
||||
"body": "Un oci-compose decide qué se monta en el contenedor y con qué privilegios. El resumen lo indica antes de instalar: instala solo archivos que vengan de una fuente de confianza."
|
||||
"title": "Un archivo que decide los privilegios",
|
||||
"body": "El oci-compose determina qué se monta dentro del contenedor y con qué privilegios. La revisión lo muestra antes de instalar: utiliza únicamente archivos de fuentes de confianza."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "El formato se describe bloque a bloque, con dos ejemplos completos, en el <readmeLink>README del motor OCI</readmeLink>. El registro de una instalación se lee de la misma forma: solo se usa la plantilla con la que se instaló, y ninguna de las respuestas de esa instalación."
|
||||
"p": "El <readmeLink>README del motor OCI</readmeLink> explica el formato bloque a bloque e incluye dos ejemplos completos. También se puede leer el registro de una instalación: solo se utiliza la plantilla original, sin incorporar ninguna de las respuestas de aquella instalación."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "private-registries",
|
||||
"title": "Imágenes en registros privados",
|
||||
"intro": "Una imagen en un registro privado, como un paquete privado de GitHub o un repositorio privado de Docker Hub, se lee con una cuenta guardada en ProxMenux.",
|
||||
"title": "Imágenes de registros privados",
|
||||
"intro": "Las imágenes de registros privados, como un paquete privado de GitHub o un repositorio privado de Docker Hub, se consultan con una cuenta guardada en ProxMenux.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "El registro rechaza la imagen", "body": "Cuando el registro responde que la imagen necesita una cuenta, la revisión ofrece iniciar sesión en ese registro y vuelve a leer la imagen." },
|
||||
{ "title": "Iniciar sesión", "body": "Un usuario y una contraseña o un token de acceso que puedan descargar la imagen. El registro los comprueba y solo se guardan si los acepta." },
|
||||
{ "title": "Instalar y mantener al día", "body": "La instalación descarga la imagen con esa cuenta, y también las actualizaciones, Modificar, Recrear, la vigilancia y la comprobación de actualizaciones del Monitor, en cualquier nodo del clúster." }
|
||||
{
|
||||
"title": "El registro deniega el acceso a la imagen",
|
||||
"body": "Si el registro indica que la imagen requiere una cuenta, la revisión ofrece iniciar sesión en ese registro y vuelve a consultar la imagen."
|
||||
},
|
||||
{
|
||||
"title": "Iniciar sesión",
|
||||
"body": "Un usuario y una contraseña o token con permiso para descargar la imagen. El registro los comprueba y solo se guardan si los acepta."
|
||||
},
|
||||
{
|
||||
"title": "Instalar y mantener al día",
|
||||
"body": "Esa cuenta se utiliza para descargar la imagen durante la instalación y también en las actualizaciones, Modificar, Recrear, la vigilancia y la comprobación de actualizaciones del Monitor, en cualquier nodo del clúster."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{ "p": "<strong>Cuentas de registro</strong>, en el menú principal de OCI manager Apps, lista las cuentas guardadas por registro y usuario, nunca su secreto. Desde cada cuenta se puede comprobar, descargar o instalar una imagen, y actualizar o eliminar la cuenta." },
|
||||
{
|
||||
"p": "<strong>Cuentas de registros</strong>, en el menú principal de OCI manager Apps, muestra las cuentas guardadas por registro y usuario, nunca sus secretos. Desde cada cuenta puedes comprobar, descargar o instalar una imagen, actualizar las credenciales o eliminarlas."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"GitHub (<code>ghcr.io</code>): el usuario es la cuenta de GitHub, y la contraseña un token de acceso personal con el permiso <code>read:packages</code>.",
|
||||
"Docker Hub (<code>docker.io</code>): el usuario es la cuenta de Docker Hub, y la contraseña un token de acceso con permiso de lectura.",
|
||||
"Otros registros, también uno con su propio puerto como <code>registry.example.com:5000</code>: el usuario y la contraseña o token que da ese registro."
|
||||
"GitHub (<code>ghcr.io</code>): el usuario es la cuenta de GitHub y la contraseña es un token de acceso personal con permiso <code>read:packages</code>.",
|
||||
"Docker Hub (<code>docker.io</code>): el usuario es la cuenta de Docker Hub y la contraseña es un token con permiso de lectura.",
|
||||
"Otros registros, incluidos los que usan un puerto propio como <code>registry.example.com:5000</code>: el usuario y la contraseña o token que proporcione ese registro."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Dónde se guardan",
|
||||
"body": "En <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, legible solo por root, en la misma carpeta donde Proxmox guarda las contraseñas de sus almacenamientos. <code>/etc/pve</code> lo comparten todos los nodos del clúster, así que una cuenta añadida en un nodo se usa en todos. El backup del host lo incluye, y al desinstalar ProxMenux se elimina de todos los nodos."
|
||||
"title": "Dónde se guardan las cuentas",
|
||||
"body": "En <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, accesible solo por root, en la misma carpeta donde Proxmox guarda las contraseñas de almacenamiento. <code>/etc/pve</code> se comparte entre los nodos del clúster, de modo que una cuenta añadida en un nodo se utiliza en todos. El backup del host incluye ese archivo y desinstalar ProxMenux lo elimina de todos los nodos."
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -191,11 +264,11 @@
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Un Dockerfile sin imagen publicada: la imagen debe construirse y publicarse antes en un registro OCI.",
|
||||
"Un archivo Compose con varios servicios: queda bloqueado porque describe más de una imagen. Esta opción instala un único contenedor.",
|
||||
"<code>configs</code>, secretos externos o formatos de dispositivo que no pueden traducirse sin ambigüedad.",
|
||||
"Sustituciones del shell como <code>$(command)</code>: debe escribirse el valor resultante.",
|
||||
"Opciones de <code>docker run</code> no reconocidas y <code>--env-file</code>: se lee en su lugar un archivo Compose explícito."
|
||||
"Un Dockerfile sin imagen publicada: primero hay que construir la imagen y publicarla en un registro OCI.",
|
||||
"Un archivo Compose con varios servicios: se bloquea porque esta opción instala un único servicio por contenedor, aunque varios servicios utilicen la misma imagen.",
|
||||
"<code>configs</code>, secretos externos o formatos de dispositivo que no puedan adaptarse de forma inequívoca.",
|
||||
"Sustituciones de shell como <code>$(command)</code>: hay que escribir directamente el valor resultante.",
|
||||
"Opciones de <code>docker run</code> no reconocidas y <code>--env-file</code>: utiliza un archivo Compose con los valores explícitos."
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -19,9 +19,18 @@
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{ "label": "Inventario del host", "detail": "/dev/dri/renderD128\nGID 993 · Intel" },
|
||||
{ "label": "ProxMenux", "detail": "fabricante y\npermisos comprobados" },
|
||||
{ "label": "LXC", "detail": "mismo dispositivo\nGID efectivo" }
|
||||
{
|
||||
"label": "Inventario del host",
|
||||
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "fabricante y\npermisos comprobados"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "mismo dispositivo\nGID efectivo"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -33,12 +42,32 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Origen", "Qué se lee", "Qué hace el instalador"],
|
||||
"headers": [
|
||||
"Origen",
|
||||
"Qué se lee",
|
||||
"Qué hace el instalador"
|
||||
],
|
||||
"rows": [
|
||||
["Docker Compose", "<code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> y peticiones NVIDIA", "Cada requisito se convierte en una petición de dispositivo que se muestra para revisión"],
|
||||
["Perfil del catálogo", "El soporte de GPU, Coral, OpenCL, USB o FUSE que tiene realmente la aplicación", "Solo se ofrecen las opciones validadas para esa imagen"],
|
||||
["Metadatos y documentación de la imagen", "VA-API, Selkies, mods de LinuxServer o el runtime NVIDIA", "Se añaden las variables y la preparación documentadas"],
|
||||
["Selección del usuario", "Solo CPU, Intel/AMD, OpenCL, NVIDIA o un dispositivo opcional", "La selección se guarda en el contrato de la instancia"]
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> y peticiones NVIDIA",
|
||||
"Cada requisito se convierte en una petición de dispositivo que se muestra para revisión"
|
||||
],
|
||||
[
|
||||
"Perfil del catálogo",
|
||||
"El soporte de GPU, Coral, OpenCL, USB o FUSE que tiene realmente la aplicación",
|
||||
"Solo se ofrecen las opciones validadas para esa imagen"
|
||||
],
|
||||
[
|
||||
"Metadatos y documentación de la imagen",
|
||||
"VA-API, Selkies, mods de LinuxServer o el runtime NVIDIA",
|
||||
"Se añaden las variables y la preparación documentadas"
|
||||
],
|
||||
[
|
||||
"Selección del usuario",
|
||||
"Solo CPU, Intel/AMD, OpenCL, NVIDIA o un dispositivo opcional",
|
||||
"La selección se guarda en el contrato de la instancia"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -57,16 +86,52 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Tipo", "Identificación", "Validación"],
|
||||
"headers": [
|
||||
"Tipo",
|
||||
"Identificación",
|
||||
"Validación"
|
||||
],
|
||||
"rows": [
|
||||
["Intel/AMD DRM", "<code>/dev/dri/renderD*</code> y <code>/sys/class/drm/NODO/device/vendor</code>", "Un dispositivo de caracteres con fabricante <code>0x8086</code> (Intel) o <code>0x1002</code> (AMD)"],
|
||||
["OpenCL AMD", "El render node, más <code>/dev/kfd</code> cuando el perfil lo necesita", "Existencia, tipo, fabricante, permisos y compatibilidad declarada"],
|
||||
["AMD ROCm", "El nodo de render, <code>/dev/kfd</code> y la generación que declara el driver de cómputo en <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>", "Una generación para la que la imagen ROCm de la aplicación trae kernels, las GPU RDNA2 que incluye y las posteriores, se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta: ROCm no las soporta oficialmente, la aplicación las presenta como la generación de su familia (<code>HSA_OVERRIDE_GFX_VERSION</code>) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece e Immich deja el reconocimiento en la CPU"],
|
||||
["NVIDIA", "<code>nvidia-smi</code> y <code>nvidia-container-cli</code>", "GPU, UUID, bus PCI, versión del driver, Toolkit, nodos <code>/dev/nvidia*</code>, binarios y librerías"],
|
||||
["Coral PCIe/M.2", "<code>/dev/apex_N</code> y su enlace en <code>/sys/dev/char/MAJOR:MINOR</code>", "Nodo de caracteres, major/minor, propietario, GID y permisos"],
|
||||
["USB y serie", "<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> o <code>/dev/bus/usb/BBB/DDD</code>", "Nodo de caracteres; en USB también fabricante, producto y número de serie cuando sysfs los publica"],
|
||||
["KVM, TUN, FUSE, vídeo y SCSI genérico", "<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> o <code>/dev/sgN</code>", "Ruta admitida, tipo de nodo y permisos efectivos"],
|
||||
["Unidad óptica", "<code>/dev/srN</code>", "Un dispositivo de bloques"]
|
||||
[
|
||||
"Intel/AMD DRM",
|
||||
"<code>/dev/dri/renderD*</code> y <code>/sys/class/drm/NODE/device/vendor</code>",
|
||||
"Un dispositivo de caracteres con fabricante <code>0x8086</code> (Intel) o <code>0x1002</code> (AMD)"
|
||||
],
|
||||
[
|
||||
"OpenCL AMD",
|
||||
"El render node, más <code>/dev/kfd</code> cuando el perfil lo necesita",
|
||||
"Existencia, tipo, fabricante, permisos y compatibilidad declarada"
|
||||
],
|
||||
[
|
||||
"AMD ROCm",
|
||||
"El nodo de render, <code>/dev/kfd</code> y la generación que declara el driver de cómputo en <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"Una generación para la que la imagen ROCm de la aplicación trae kernels, las GPU RDNA2 que incluye y las posteriores, se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta: ROCm no las soporta oficialmente, la aplicación las presenta como la generación de su familia (<code>HSA_OVERRIDE_GFX_VERSION</code>) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece e Immich deja el reconocimiento en la CPU"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"<code>nvidia-smi</code> y <code>nvidia-container-cli</code>",
|
||||
"GPU, UUID, bus PCI, versión del driver, Toolkit, nodos <code>/dev/nvidia*</code>, binarios y librerías"
|
||||
],
|
||||
[
|
||||
"Coral PCIe/M.2",
|
||||
"<code>/dev/apex_N</code> y su enlace en <code>/sys/dev/char/MAJOR:MINOR</code>",
|
||||
"Nodo de caracteres, major/minor, propietario, GID y permisos"
|
||||
],
|
||||
[
|
||||
"USB y serie",
|
||||
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> o <code>/dev/bus/usb/BBB/DDD</code>",
|
||||
"Nodo de caracteres; en USB también fabricante, producto y número de serie cuando sysfs los publica"
|
||||
],
|
||||
[
|
||||
"KVM, TUN, FUSE, vídeo y SCSI genérico",
|
||||
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> o <code>/dev/sgN</code>",
|
||||
"Ruta admitida, tipo de nodo y permisos efectivos"
|
||||
],
|
||||
[
|
||||
"Unidad óptica",
|
||||
"<code>/dev/srN</code>",
|
||||
"Un dispositivo de bloques"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -79,12 +144,30 @@
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "La plantilla ofrece sus perfiles", "body": "Por ejemplo solo CPU, Intel/AMD VA-API, OpenCL AMD, OpenCL Intel o NVIDIA. Las opciones pertenecen a la imagen, no a un menú común." },
|
||||
{ "title": "Se elige un perfil", "body": "Define los nodos de dispositivo, el entorno, los mods o el runtime que necesita la aplicación." },
|
||||
{ "title": "Se propone una ruta", "body": "Para DRM, <code>/dev/dri/renderD128</code>, que puede cambiarse en un host con varios render nodes. Para USB o serie se selecciona el nodo concreto." },
|
||||
{ "title": "Validación", "body": "Se comprueban existencia, tipo, fabricante admitido, permisos y GID. Una discrepancia detiene la operación." },
|
||||
{ "title": "Se escribe el contrato", "body": "Ruta, modo, GID, acceso de escritura y perfil quedan registrados para las actualizaciones y las recreaciones." },
|
||||
{ "title": "Conexión y prueba", "body": "<code>pct set</code> añade la entrada <code>devN</code> y después se comprueba el acceso dentro del LXC. Las imágenes de LinuxServer se comprueban también como usuario <code>abc</code>." }
|
||||
{
|
||||
"title": "La plantilla ofrece sus perfiles",
|
||||
"body": "Por ejemplo solo CPU, Intel/AMD VA-API, OpenCL AMD, OpenCL Intel o NVIDIA. Las opciones pertenecen a la imagen, no a un menú común."
|
||||
},
|
||||
{
|
||||
"title": "Se elige un perfil",
|
||||
"body": "Define los nodos de dispositivo, el entorno, los mods o el runtime que necesita la aplicación."
|
||||
},
|
||||
{
|
||||
"title": "Se propone una ruta",
|
||||
"body": "Para DRM, <code>/dev/dri/renderD128</code>, que puede cambiarse en un host con varios render nodes. Para USB o serie se selecciona el nodo concreto."
|
||||
},
|
||||
{
|
||||
"title": "Validación",
|
||||
"body": "Se comprueban existencia, tipo, fabricante admitido, permisos y GID. Una discrepancia detiene la operación."
|
||||
},
|
||||
{
|
||||
"title": "Se escribe el contrato",
|
||||
"body": "Ruta, modo, GID, acceso de escritura y perfil quedan registrados para las actualizaciones y las recreaciones."
|
||||
},
|
||||
{
|
||||
"title": "Conexión y prueba",
|
||||
"body": "<code>pct set</code> añade la entrada <code>devN</code> y después se comprueba el acceso dentro del LXC. Las imágenes de LinuxServer se comprueban también como usuario <code>abc</code>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -98,10 +181,22 @@
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{ "title": "Intel/AMD VA-API", "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0" },
|
||||
{ "title": "Coral PCIe/M.2", "code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0" },
|
||||
{ "title": "Un dispositivo USB concreto", "code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0" },
|
||||
{ "title": "OpenCL AMD", "code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0" }
|
||||
{
|
||||
"title": "Intel/AMD VA-API",
|
||||
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Coral PCIe/M.2",
|
||||
"code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Un dispositivo USB concreto",
|
||||
"code": "dev0: path=/dev/bus/usb/003/004,mode=0660,gid=GID,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "OpenCL AMD",
|
||||
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=GID,deny-write=0\ndev1: path=/dev/kfd,mode=0660,gid=GID,deny-write=0"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -116,13 +211,37 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Perfil", "Traducción", "Se ofrece cuando"],
|
||||
"headers": [
|
||||
"Perfil",
|
||||
"Configuración resultante",
|
||||
"Se ofrece cuando"
|
||||
],
|
||||
"rows": [
|
||||
["Intel/AMD VA-API", "Render node de <code>/dev/dri</code>", "La aplicación admite aceleración de vídeo"],
|
||||
["OpenCL", "Render node, <code>/dev/kfd</code> si hace falta y el mod oficial", "La imagen o el perfil lo documentan"],
|
||||
["NVIDIA", "Dispositivos y librerías del driver del host", "El host tiene un driver operativo y NVIDIA Container Toolkit"],
|
||||
["Coral", "<code>/dev/apex_0</code> o el bus USB", "El perfil declara soporte de Coral (Frigate)"],
|
||||
["USB, serie, FUSE", "Un dispositivo concreto, un árbol validado o una función LXC", "El contrato lo pide"]
|
||||
[
|
||||
"Intel/AMD VA-API",
|
||||
"Render node de <code>/dev/dri</code>",
|
||||
"La aplicación admite aceleración de vídeo"
|
||||
],
|
||||
[
|
||||
"OpenCL",
|
||||
"Render node, <code>/dev/kfd</code> si hace falta y el mod oficial",
|
||||
"La imagen o el perfil lo documentan"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"Dispositivos y librerías del driver del host",
|
||||
"El host tiene un driver operativo y NVIDIA Container Toolkit"
|
||||
],
|
||||
[
|
||||
"Coral",
|
||||
"<code>/dev/apex_0</code> o el bus USB",
|
||||
"El perfil declara soporte de Coral (Frigate)"
|
||||
],
|
||||
[
|
||||
"USB, serie, FUSE",
|
||||
"Un dispositivo concreto, un árbol validado o una función LXC",
|
||||
"El contrato lo pide"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -145,7 +264,9 @@
|
||||
"p": "Estos dos comandos, en el host, muestran si el driver y el Toolkit están disponibles:"
|
||||
},
|
||||
{
|
||||
"shell": { "code": "nvidia-smi -L\nnvidia-container-cli --version" }
|
||||
"shell": {
|
||||
"code": "nvidia-smi -L\nnvidia-container-cli --version"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "En un host cuyo driver se instaló por otros medios, el Toolkit se instala desde el repositorio estable oficial:"
|
||||
@@ -159,7 +280,9 @@
|
||||
"p": "El inventario que usa OCI manager Apps es la salida de:"
|
||||
},
|
||||
{
|
||||
"shell": { "code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs" }
|
||||
"shell": {
|
||||
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
@@ -170,10 +293,26 @@
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{ "icon": "cpu", "title": "Inventario desde el driver", "body": "<code>nvidia-container-cli</code> enumera los nodos de dispositivo, los binarios, el firmware y las librerías del driver instalado." },
|
||||
{ "icon": "refresh", "title": "Sin versión fija", "body": "La plantilla no nombra archivos de librería. El perfil se genera a partir del host actual." },
|
||||
{ "icon": "shield", "title": "Montajes de solo lectura", "body": "Las librerías del host se montan en solo lectura en lugar de copiarse dentro del contenedor." },
|
||||
{ "icon": "hardDrive", "title": "Cambios de driver", "body": "Tras un cambio de driver, el inventario se genera de nuevo antes de que arranquen los LXC afectados." }
|
||||
{
|
||||
"icon": "cpu",
|
||||
"title": "Inventario desde el driver",
|
||||
"body": "<code>nvidia-container-cli</code> enumera los nodos de dispositivo, los binarios, el firmware y las librerías del driver instalado."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Sin versión fija",
|
||||
"body": "La plantilla no nombra archivos de librería. El perfil se genera a partir del host actual."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Montajes de solo lectura",
|
||||
"body": "Las librerías del host se montan en solo lectura en lugar de copiarse dentro del contenedor."
|
||||
},
|
||||
{
|
||||
"icon": "hardDrive",
|
||||
"title": "Cambios de driver",
|
||||
"body": "Tras un cambio de driver, el inventario se genera de nuevo antes de que arranquen los LXC afectados."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -209,12 +348,32 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Petición", "Traducción", "Alcance"],
|
||||
"headers": [
|
||||
"Petición",
|
||||
"Configuración resultante",
|
||||
"Alcance"
|
||||
],
|
||||
"rows": [
|
||||
["<code>/dev/dvb</code>, <code>/dev/snd</code> o <code>/dev/bus/usb</code>", "Cada nodo de caracteres del árbol recibe su propia entrada <code>devN</code> con el modo y el GID del host", "Solo el árbol pedido, no el resto de <code>/dev</code>"],
|
||||
["<code>/dev/fuse</code>", "El nodo y, cuando el perfil lo necesita, la función <code>fuse=1</code>", "FUSE por sí solo no publica montajes a otros LXC"],
|
||||
["<code>/dev/net/tun</code>", "Una entrada <code>devN</code> en la misma ruta dentro del LXC", "La configuración de la VPN o de la red queda en la aplicación"],
|
||||
["<code>/dev/kvm</code>", "Una entrada <code>devN</code> validada", "Solo se ofrece cuando el contrato lo pide"]
|
||||
[
|
||||
"<code>/dev/dvb</code>, <code>/dev/snd</code> o <code>/dev/bus/usb</code>",
|
||||
"Cada nodo de caracteres del árbol recibe su propia entrada <code>devN</code> con el modo y el GID del host",
|
||||
"Solo el árbol pedido, no el resto de <code>/dev</code>"
|
||||
],
|
||||
[
|
||||
"<code>/dev/fuse</code>",
|
||||
"El nodo y, cuando el perfil lo necesita, la función <code>fuse=1</code>",
|
||||
"FUSE por sí solo no publica montajes a otros LXC"
|
||||
],
|
||||
[
|
||||
"<code>/dev/net/tun</code>",
|
||||
"Una entrada <code>devN</code> en la misma ruta dentro del LXC",
|
||||
"La configuración de la VPN o de la red queda en la aplicación"
|
||||
],
|
||||
[
|
||||
"<code>/dev/kvm</code>",
|
||||
"Una entrada <code>devN</code> validada",
|
||||
"Solo se ofrece cuando el contrato lo pide"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "OCI manager Apps | ProxMenux",
|
||||
"description": "Imágenes OCI oficiales ejecutadas como contenedores LXC nativos de Proxmox VE, con datos persistentes, dispositivos, aplicaciones multicontenedor y actualizaciones transaccionales."
|
||||
"description": "Ejecuta imágenes OCI oficiales como contenedores LXC nativos de Proxmox VE, con datos persistentes, acceso a dispositivos, aplicaciones con varios contenedores y actualizaciones transaccionales."
|
||||
},
|
||||
"header": {
|
||||
"title": "OCI manager Apps",
|
||||
"description": "Las imágenes OCI oficiales se ejecutan como contenedores LXC nativos de Proxmox VE. La imagen sigue siendo la que publica su responsable; ProxMenux reproduce el entorno que Docker Compose habría creado a su alrededor.",
|
||||
"description": "Las imágenes OCI oficiales se ejecutan como contenedores LXC nativos de Proxmox VE. Se utiliza la misma imagen que publica su desarrollador; ProxMenux reproduce el entorno que Docker Compose habría creado a su alrededor.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
@@ -15,34 +15,43 @@
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Una imagen OCI, un LXC nativo",
|
||||
"body": "Dentro de los contenedores no se ejecuta ningún motor Docker. Proxmox VE importa el sistema de archivos de la imagen y sus metadatos OCI, y la aplicación pasa a ser el proceso principal de un LXC nativo, gestionado con las mismas herramientas que cualquier otro contenedor del nodo."
|
||||
"body": "No se ejecuta Docker Engine dentro de los contenedores. Proxmox VE importa el sistema de archivos de la imagen y sus metadatos OCI; la aplicación pasa a ser el proceso principal de un LXC nativo, administrado con las mismas herramientas que cualquier otro contenedor del nodo."
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{ "label": "Origen", "detail": "Imagen OCI\nCompose y documentación" },
|
||||
{ "label": "ProxMenux", "detail": "Contrato JSON\nvalidación y plan" },
|
||||
{ "label": "Proxmox VE", "detail": "LXC nativo\nvolúmenes y dispositivos" }
|
||||
{
|
||||
"label": "Origen",
|
||||
"detail": "Imagen OCI\nCompose y documentación"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "Contrato JSON\nvalidación y planificación"
|
||||
},
|
||||
{
|
||||
"label": "Proxmox VE",
|
||||
"detail": "LXC nativo\nvolúmenes y dispositivos"
|
||||
}
|
||||
],
|
||||
"caption": "La aplicación no se reconstruye: su entorno se reproduce de forma declarativa."
|
||||
"caption": "Se utiliza la aplicación original; su entorno se define de forma declarativa y se reproduce."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "where",
|
||||
"title": "Dónde se encuentra",
|
||||
"intro": "OCI manager Apps se abre desde la opción <strong>OCI manager Apps (Technology Preview)</strong> del menú principal de ProxMenux, en el nodo Proxmox y como root. Su primera pantalla ofrece:",
|
||||
"title": "Dónde encontrarlo",
|
||||
"intro": "OCI manager Apps se abre desde la opción <strong>OCI manager Apps (Technology Preview)</strong> del menú principal de ProxMenux, en el nodo Proxmox y como root. La primera pantalla ofrece:",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"<strong>Buscar aplicaciones</strong>: búsqueda por nombre en todo el catálogo.",
|
||||
"<strong>Todas las aplicaciones</strong>: el catálogo completo, con el número de aplicaciones.",
|
||||
"<strong>Gestionar aplicaciones OCI instaladas</strong>: actualizar, modificar, eliminar o recuperar lo instalado.",
|
||||
"<strong>Cuentas de registro</strong>: las cuentas con las que se instalan y actualizan imágenes de registros privados.",
|
||||
"<strong>Instalar una imagen que no está en el catálogo</strong>: traducción de un archivo Compose, un comando <code>docker run</code> o una referencia de imagen.",
|
||||
"<strong>Buscar aplicaciones</strong>: busca por nombre en todo el catálogo.",
|
||||
"<strong>Todas las aplicaciones</strong>: muestra el catálogo completo y su número de aplicaciones.",
|
||||
"<strong>Gestionar aplicaciones OCI instaladas</strong>: actualiza, modifica, elimina o recupera las aplicaciones que ya has instalado.",
|
||||
"<strong>Cuentas de registros</strong>: administra las cuentas utilizadas para instalar y actualizar imágenes de registros privados.",
|
||||
"<strong>Instalar una imagen que no esté en el catálogo</strong>: adapta un archivo Compose, un comando <code>docker run</code> o una referencia de imagen.",
|
||||
"Las categorías del catálogo, cada una con su número de aplicaciones."
|
||||
]
|
||||
}
|
||||
@@ -50,40 +59,72 @@
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/main-menu.png",
|
||||
"alt": "Pantalla principal de OCI manager Apps con la búsqueda, todas las aplicaciones, la gestión, la imagen propia y las categorías del catálogo",
|
||||
"alt": "Pantalla principal de OCI manager Apps con búsqueda, listado completo, gestión de aplicaciones, imágenes fuera del catálogo y categorías.",
|
||||
"caption": "Pantalla principal de OCI manager Apps."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Al seleccionar una aplicación se muestra su descripción, la imagen que ejecuta y dos modos de instalación: <strong>Instalar con la configuración predeterminada</strong>, que pregunta solo lo que decide toda instalación (almacenamiento, dónde van los datos, dirección e inicio), e <strong>Instalar con la configuración avanzada</strong>, que abre cada decisión en orden: VMID y recursos, el almacenamiento de cada ruta, el bridge y los dispositivos."
|
||||
"p": "Al seleccionar una aplicación se muestran su descripción, la imagen que utiliza y dos modos de instalación. <strong>Instalar con ajustes predeterminados</strong> solo pregunta lo esencial de cada instalación: almacenamiento, ubicación de los datos, dirección y arranque. <strong>Instalar con ajustes avanzados</strong> recorre todas las decisiones en orden: VMID y recursos, almacenamiento de cada ruta, puente de red y dispositivos."
|
||||
},
|
||||
{
|
||||
"p": "Una aplicación probada en real muestra <strong>Verificado</strong> en esa vista y aparece marcada con ✓ en las listas, tanto si se probó en el laboratorio de ProxMenux como si la probó la comunidad."
|
||||
"p": "Las aplicaciones que se han probado realmente muestran <strong>Verificado</strong> en esa vista y una marca ✓ en las listas, tanto si la prueba se hizo en el laboratorio de ProxMenux como si la realizó la comunidad."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "beta",
|
||||
"title": "Por qué es una Technology Preview",
|
||||
"title": "Por qué lleva la etiqueta Technology Preview",
|
||||
"blocks": [
|
||||
{ "p": "OCI manager Apps lleva la etiqueta <strong>Technology Preview</strong> que Proxmox VE da a los contenedores de aplicación creados a partir de imágenes OCI, introducidos en Proxmox VE 9.1. Se refiere a aquello sobre lo que funciona OCI manager Apps, no al motor de ProxMenux: el comportamiento de esos contenedores todavía puede cambiar entre versiones de Proxmox VE. La etiqueta se mantiene hasta que Proxmox VE dé ese soporte por estable." },
|
||||
{ "p": "El motor de OCI manager Apps (instalación, actualización, modificación, recreación, backups, restauración, migración y vigilancia) está probado en el laboratorio de ProxMenux. Cada aplicación se prueba por separado: las que se han probado de verdad muestran <strong>Verified</strong> y llevan una ✓ en las listas." }
|
||||
{
|
||||
"p": "OCI manager Apps mantiene la etiqueta <strong>Technology Preview</strong> que Proxmox VE asigna a los contenedores de aplicaciones creados a partir de imágenes OCI, cuyo soporte se introdujo en Proxmox VE 9.1. La etiqueta se refiere a la tecnología sobre la que funciona OCI manager Apps, no al motor de ProxMenux: el comportamiento de estos contenedores puede cambiar entre versiones de Proxmox VE. Se mantendrá hasta que Proxmox VE considere estable ese soporte."
|
||||
},
|
||||
{
|
||||
"p": "El motor de OCI manager Apps se prueba en el laboratorio de ProxMenux: instalación, actualización, modificación, recreación, backups, restauración, migración y vigilancia. Cada aplicación se verifica por separado. Las que se han probado realmente muestran <strong>Verificado</strong> y llevan un ✓ en las listas."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "translation",
|
||||
"title": "Lo que Docker expresa y en qué lo convierte OCI manager Apps",
|
||||
"title": "Cómo describe Docker los requisitos y cómo los aplica OCI manager Apps",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Necesidad", "Docker la expresa como", "OCI manager Apps la convierte en"],
|
||||
"headers": [
|
||||
"Requisito",
|
||||
"Cómo lo expresa Docker",
|
||||
"Cómo lo aplica OCI manager Apps"
|
||||
],
|
||||
"rows": [
|
||||
["Ejecutar la aplicación", "<code>image</code>, <code>entrypoint</code>, <code>command</code>", "rootfs OCI y proceso principal del LXC"],
|
||||
["Conservar la configuración", "<code>volumes: /config</code>", "un disco <code>mpN</code> persistente incluido en el backup, o un directorio del host"],
|
||||
["Publicar el servicio", "<code>ports</code>", "una dirección propia del LXC y la URL de acceso al servicio"],
|
||||
["Usar hardware", "<code>devices</code>, <code>group_add</code>", "entradas <code>devN</code> con el GID efectivo del host y un perfil validado"],
|
||||
["Conectar dependencias", "<code>networks</code>, <code>depends_on</code>", "un bridge privado, direcciones fijas, orden de arranque y healthchecks"],
|
||||
["Actualizar", "<code>pull</code> y recrear", "un rootfs nuevo con el mismo contrato persistente"]
|
||||
[
|
||||
"Ejecutar la aplicación",
|
||||
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
|
||||
"El rootfs de la imagen OCI y el proceso principal del LXC"
|
||||
],
|
||||
[
|
||||
"Conservar la configuración",
|
||||
"<code>volumes: /config</code>",
|
||||
"Un volumen persistente <code>mpN</code> incluido en el backup, o bien un directorio del host."
|
||||
],
|
||||
[
|
||||
"Publicar el servicio",
|
||||
"<code>ports</code>",
|
||||
"Una dirección propia para el LXC y la URL de acceso al servicio."
|
||||
],
|
||||
[
|
||||
"Usar hardware",
|
||||
"<code>devices</code>, <code>group_add</code>",
|
||||
"Entradas <code>devN</code> con el GID efectivo del host y un perfil validado."
|
||||
],
|
||||
[
|
||||
"Conectar las dependencias",
|
||||
"<code>networks</code>, <code>depends_on</code>",
|
||||
"Un puente de red privado, direcciones fijas, orden de arranque y comprobaciones de estado."
|
||||
],
|
||||
[
|
||||
"Actualizar",
|
||||
"Descargar con <code>pull</code> y recrear",
|
||||
"Un rootfs nuevo que mantiene el mismo contrato de persistencia."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -91,15 +132,31 @@
|
||||
},
|
||||
{
|
||||
"id": "kept",
|
||||
"title": "Qué se mantiene y qué cambia",
|
||||
"title": "Qué se conserva y qué cambia",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{ "icon": "archive", "title": "Se mantiene", "body": "La imagen oficial, sus rutas internas, su entorno, su proceso de arranque y su documentación funcional." },
|
||||
{ "icon": "boxes", "title": "Se adapta", "body": "El entorno de ejecución: red, persistencia, dispositivos, permisos y dependencias usan primitivas LXC nativas de Proxmox VE." },
|
||||
{ "icon": "shield", "title": "No se traduce", "body": "Una clave de Compose sin equivalencia segura figura como bloqueo. Las plantillas con bloqueos no se ofrecen, y las opciones sensibles se confirman durante la instalación." },
|
||||
{ "icon": "refresh", "title": "Se registra", "body": "Digest de la imagen, recursos, rutas, red, dispositivos y pertenencia a una pila quedan en el contrato de la instancia, que las actualizaciones y las recreaciones reproducen." }
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Se conserva",
|
||||
"body": "La imagen oficial, sus rutas internas, su entorno, su proceso de arranque y su documentación de uso."
|
||||
},
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Se adapta",
|
||||
"body": "El entorno de ejecución: la red, la persistencia, los dispositivos, los permisos y las dependencias utilizan los mecanismos nativos de LXC de Proxmox VE."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Sin equivalente",
|
||||
"body": "Una opción de Compose sin una equivalencia segura se registra como un impedimento para la instalación. Las plantillas con impedimentos no se ofrecen para instalar, y las opciones sensibles requieren confirmación durante el asistente."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Se registra",
|
||||
"body": "El digest de la imagen, los recursos, las rutas, la red, los dispositivos y la pertenencia a una pila se guardan en el contrato de la instancia. Las actualizaciones y recreaciones reproducen ese contrato."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -112,13 +169,41 @@
|
||||
{
|
||||
"next": {
|
||||
"items": [
|
||||
{ "label": "Cómo se traduce una imagen OCI", "href": "/docs/oci-manager/architecture", "tail": "de la imagen y su archivo Compose a un LXC nativo." },
|
||||
{ "label": "Instalar una imagen que no está en el catálogo", "href": "/docs/oci-manager/custom-image", "tail": "Compose, docker run o una referencia de imagen." },
|
||||
{ "label": "Datos, rutas y red", "href": "/docs/oci-manager/storage-network", "tail": "discos del contenedor, directorios del host, montajes Rclone y direcciones." },
|
||||
{ "label": "Dispositivos y aceleración", "href": "/docs/oci-manager/hardware", "tail": "GPU, NVIDIA, Coral, USB y otros dispositivos." },
|
||||
{ "label": "Aplicaciones multicontenedor", "href": "/docs/oci-manager/stacks", "tail": "aplicación, base de datos y caché como LXC coordinados." },
|
||||
{ "label": "Instalar, actualizar y modificar", "href": "/docs/oci-manager/lifecycle", "tail": "el contrato de la instancia y sus operaciones." },
|
||||
{ "label": "En ProxMenux Monitor", "href": "/docs/oci-manager/monitor", "tail": "versiones, actualizaciones, salida de consola y terminal." }
|
||||
{
|
||||
"label": "Cómo se adapta una imagen OCI",
|
||||
"href": "/docs/oci-manager/architecture",
|
||||
"tail": "De la imagen y su archivo Compose a un LXC nativo."
|
||||
},
|
||||
{
|
||||
"label": "Instalar una imagen que no esté en el catálogo",
|
||||
"href": "/docs/oci-manager/custom-image",
|
||||
"tail": "Un archivo Compose, un comando docker run o una referencia de imagen."
|
||||
},
|
||||
{
|
||||
"label": "Datos, rutas y red",
|
||||
"href": "/docs/oci-manager/storage-network",
|
||||
"tail": "Volúmenes del contenedor, directorios del host, montajes con rclone y direcciones."
|
||||
},
|
||||
{
|
||||
"label": "Dispositivos y aceleración",
|
||||
"href": "/docs/oci-manager/hardware",
|
||||
"tail": "GPU, NVIDIA, Coral, USB y otros dispositivos."
|
||||
},
|
||||
{
|
||||
"label": "Aplicaciones con varios contenedores",
|
||||
"href": "/docs/oci-manager/stacks",
|
||||
"tail": "Aplicación, base de datos y caché en varios LXC coordinados."
|
||||
},
|
||||
{
|
||||
"label": "Instalar, actualizar y modificar",
|
||||
"href": "/docs/oci-manager/lifecycle",
|
||||
"tail": "El contrato de la instancia y sus operaciones."
|
||||
},
|
||||
{
|
||||
"label": "En ProxMenux Monitor",
|
||||
"href": "/docs/oci-manager/monitor",
|
||||
"tail": "Versiones, actualizaciones, salida de consola y terminal."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
},
|
||||
{
|
||||
"code": {
|
||||
"code": "instances/\n└── 105/\n └── oci-compose.json\n ├── imagen y digest resuelto\n ├── recursos y red\n ├── entorno (secretos protegidos)\n ├── discos del contenedor y directorios del host\n ├── perfil de hardware y dispositivos\n ├── log de consola y modo de terminal\n └── pertenencia a una pila y ciclo de vida"
|
||||
"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"
|
||||
}
|
||||
},
|
||||
{
|
||||
@@ -86,7 +86,7 @@
|
||||
"registry": "Registro OCI",
|
||||
"update": "Actualizar la instancia",
|
||||
"resolve": "Resolver la etiqueta",
|
||||
"verify": "Verificar el archivo y preflight",
|
||||
"verify": "Verificar el archivo y realizar las comprobaciones previas",
|
||||
"backup": "Detener y respaldar el CT",
|
||||
"import": "Importar el rootfs nuevo",
|
||||
"reapply": "Aplicar de nuevo el contrato",
|
||||
@@ -215,7 +215,7 @@
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Backup, restauración y otro host",
|
||||
"intro": "Un backup hecho con vzdump o Proxmox Backup Server incluye el contenedor, sus discos y la copia de su contrato. Lo que la instalación guarda en el host no forma parte de él. <strong>Gestionar aplicaciones OCI instaladas</strong> detecta los contenedores restaurados en un host que no tiene su contrato, un Proxmox recién instalado u otro host, y ofrece registrarlos de nuevo.",
|
||||
"intro": "Un backup hecho con vzdump o Proxmox Backup Server incluye el contenedor, los discos del contenedor seleccionados para el backup y la copia de su contrato. Lo que la instalación guarda en el host no forma parte de él. <strong>Gestionar aplicaciones OCI instaladas</strong> detecta los contenedores restaurados en un host que no tiene su contrato, un Proxmox recién instalado u otro host, y ofrece registrarlos de nuevo.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
@@ -462,7 +462,7 @@
|
||||
],
|
||||
[
|
||||
"Discos del contenedor",
|
||||
"Proxmox los mueve con el contenedor. HA necesita que estén en un almacenamiento compartido."
|
||||
"Proxmox los mueve con el contenedor. HA necesita sus datos disponibles en el nodo de destino, mediante almacenamiento compartido o una configuración de replicación compatible."
|
||||
],
|
||||
[
|
||||
"Directorios del host y dispositivos",
|
||||
|
||||
@@ -52,7 +52,7 @@
|
||||
},
|
||||
{
|
||||
"id": "app",
|
||||
"title": "App",
|
||||
"title": "Aplicación",
|
||||
"intro": "La pestaña <appLink>App</appLink> ofrece la aplicación instalada como una detección, con el nombre, el logo, el puerto y el esquema del registro. Al registrarla se abre el editor con el método <strong>Imagen OCI (instalada por ProxMenux)</strong>, que no necesita configuración.",
|
||||
"blocks": [
|
||||
{
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
"description": "Cómo convierte OCI manager Apps una aplicación con su base de datos y su caché en LXC nativos coordinados: plan, red privada, hook de dependencias, validación y actualizaciones transaccionales."
|
||||
},
|
||||
"header": {
|
||||
"title": "Aplicaciones multicontenedor",
|
||||
"title": "Aplicaciones con varios contenedores",
|
||||
"description": "Una aplicación con su base de datos, su caché y otros servicios se convierte en varios LXC nativos coordinados, que se instalan y actualizan como uno solo.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
@@ -21,7 +21,14 @@
|
||||
{
|
||||
"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": "Plan de la pila", "app": "LXC de la aplicación", "appNet": "LAN + privada", "db": "LXC PostgreSQL", "cache": "LXC Valkey", "private": "privada" }
|
||||
"labels": {
|
||||
"plan": "Plan de la pila",
|
||||
"app": "LXC de la aplicación",
|
||||
"appNet": "LAN + privada",
|
||||
"db": "LXC PostgreSQL",
|
||||
"cache": "LXC Valkey",
|
||||
"private": "privada"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -35,14 +42,42 @@
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Elemento del plan", "Contenido", "Comprobado antes de crear nada"],
|
||||
"headers": [
|
||||
"Elemento del plan",
|
||||
"Contenido",
|
||||
"Comprobado antes de crear nada"
|
||||
],
|
||||
"rows": [
|
||||
["Miembros", "Aplicación principal, base de datos, caché, aprendizaje automático y demás dependencias", "VMID únicos, roles conocidos y exactamente un miembro principal"],
|
||||
["Imágenes", "Referencia rolling, arquitectura y digest resuelto de cada servicio", "Todas existen, admiten la arquitectura y superan la verificación de integridad OCI"],
|
||||
["Red", "Bridge privado, subred, una dirección fija por servicio y acceso LAN para el miembro principal", "Sin colisión con bridges o subredes existentes y sin direcciones repetidas"],
|
||||
["Persistencia", "Discos del contenedor, directorios del host, propietarios y backup", "Rutas sin solapamientos, almacenamiento disponible y permisos declarados"],
|
||||
["Secretos", "Contraseña de la base de datos, claves de la aplicación y credenciales iniciales", "Se generan una vez y solo se entregan a los miembros que los usan"],
|
||||
["Ciclo de vida", "Orden de arranque, orden de parada y una comprobación de salud por miembro", "La aplicación principal arranca la última y se detiene la primera"]
|
||||
[
|
||||
"Miembros",
|
||||
"Aplicación principal, base de datos, caché, aprendizaje automático y demás dependencias",
|
||||
"VMID únicos, roles conocidos y exactamente un miembro principal"
|
||||
],
|
||||
[
|
||||
"Imágenes",
|
||||
"Referencia rolling, arquitectura y digest resuelto de cada servicio",
|
||||
"Todas existen, admiten la arquitectura y superan la verificación de integridad OCI"
|
||||
],
|
||||
[
|
||||
"Red",
|
||||
"Bridge privado, subred, una dirección fija por servicio y acceso LAN para el miembro principal",
|
||||
"Sin colisión con bridges o subredes existentes y sin direcciones repetidas"
|
||||
],
|
||||
[
|
||||
"Persistencia",
|
||||
"Discos del contenedor, directorios del host, propietarios y backup",
|
||||
"Rutas sin solapamientos, almacenamiento disponible y permisos declarados"
|
||||
],
|
||||
[
|
||||
"Secretos",
|
||||
"Contraseña de la base de datos, claves de la aplicación y credenciales iniciales",
|
||||
"Se generan una vez y solo se entregan a los miembros que los usan"
|
||||
],
|
||||
[
|
||||
"Ciclo de vida",
|
||||
"Orden de arranque, orden de parada y una comprobación de salud por miembro",
|
||||
"La aplicación principal arranca la última y se detiene la primera"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -55,13 +90,34 @@
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Reservar todos los VMID", "body": "Se comprueban el inventario de Proxmox VE y el registro de instancias. No se adopta un CT existente ni se reutiliza un contrato que todavía pertenece a otra instancia." },
|
||||
{ "title": "Preparar todas las imágenes", "body": "Todas las imágenes se resuelven, descargan y verifican antes de crear el primer contenedor." },
|
||||
{ "title": "Crear cada rootfs", "body": "Se importan los metadatos OCI oficiales y se añaden la identidad de instancia de ProxMenux y el rol del miembro." },
|
||||
{ "title": "Red privada", "body": "Se crean un bridge y una subred y cada miembro recibe su dirección fija; solo el miembro principal recibe además la interfaz de la LAN." },
|
||||
{ "title": "Persistencia", "body": "Cada base de datos y configuración recibe su propio disco del contenedor; solo los datos destinados a compartirse usan directorios del host." },
|
||||
{ "title": "Entorno", "body": "Se escriben los endpoints internos, los secretos compartidos y las variables de servicio. La aplicación llega a sus dependencias en sus direcciones privadas reservadas." },
|
||||
{ "title": "Registro", "body": "Cada miembro registra su configuración nativa, los cambios del rootfs que las actualizaciones deben reproducir y su relación con la pila." }
|
||||
{
|
||||
"title": "Reservar todos los VMID",
|
||||
"body": "Se comprueban el inventario de Proxmox VE y el registro de instancias. No se adopta un CT existente ni se reutiliza un contrato que todavía pertenece a otra instancia."
|
||||
},
|
||||
{
|
||||
"title": "Preparar todas las imágenes",
|
||||
"body": "Todas las imágenes se resuelven, descargan y verifican antes de crear el primer contenedor."
|
||||
},
|
||||
{
|
||||
"title": "Crear cada rootfs",
|
||||
"body": "Se importan los metadatos OCI oficiales y se añaden la identidad de instancia de ProxMenux y el rol del miembro."
|
||||
},
|
||||
{
|
||||
"title": "Red privada",
|
||||
"body": "Se crean un bridge y una subred y cada miembro recibe su dirección fija; solo el miembro principal recibe además la interfaz de la LAN."
|
||||
},
|
||||
{
|
||||
"title": "Persistencia",
|
||||
"body": "Cada base de datos y configuración recibe su propio disco del contenedor; solo los datos destinados a compartirse usan directorios del host."
|
||||
},
|
||||
{
|
||||
"title": "Entorno",
|
||||
"body": "Se escriben los endpoints internos, los secretos compartidos y las variables de servicio. La aplicación llega a sus dependencias en sus direcciones privadas reservadas."
|
||||
},
|
||||
{
|
||||
"title": "Registro",
|
||||
"body": "Cada miembro registra su configuración nativa, los cambios del rootfs que las actualizaciones deben reproducir y su relación con la pila."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -74,20 +130,48 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Servicio", "Comprobación", "Qué demuestra"],
|
||||
"headers": [
|
||||
"Servicio",
|
||||
"Comprobación",
|
||||
"Qué demuestra"
|
||||
],
|
||||
"rows": [
|
||||
["PostgreSQL", "<code>pg_isready</code> en el CT con el host, el usuario y la base de datos esperados", "El servidor acepta conexiones para la base de datos configurada"],
|
||||
["Redis / Valkey", "<code>redis-cli</code> o <code>valkey-cli</code> <code>PING</code> contra su dirección privada", "El broker escucha y responde"],
|
||||
["Aprendizaje automático de Immich", "HTTP <code>GET /ping</code>, más una comprobación del runtime GPU seleccionado", "El servicio responde y la aceleración pedida no ha pasado a CPU"],
|
||||
["Nextcloud", "<code>GET /status.php</code> con <code>installed=true</code>, <code>maintenance=false</code> y <code>needsDbUpgrade=false</code>", "La inicialización terminó sin migraciones pendientes"],
|
||||
["Paperless-ngx / Tandoor", "HTTP en la dirección de la LAN y el puerto real del servicio", "El frontend y sus dependencias sirven la aplicación"],
|
||||
["Aplicación principal", "El endpoint de su plantilla, por ejemplo <code>/api/server/ping</code> en Immich", "La pila completa funciona a través de la aplicación que usa las dependencias"]
|
||||
[
|
||||
"PostgreSQL",
|
||||
"<code>pg_isready</code> en el CT con el host, el usuario y la base de datos esperados",
|
||||
"El servidor acepta conexiones para la base de datos configurada"
|
||||
],
|
||||
[
|
||||
"Redis / Valkey",
|
||||
"<code>redis-cli</code> o <code>valkey-cli</code> <code>PING</code> contra su dirección privada",
|
||||
"El broker escucha y responde"
|
||||
],
|
||||
[
|
||||
"Aprendizaje automático de Immich",
|
||||
"HTTP <code>GET /ping</code>, más una comprobación del runtime GPU seleccionado",
|
||||
"El servicio responde y la aceleración pedida no ha pasado a CPU"
|
||||
],
|
||||
[
|
||||
"Nextcloud",
|
||||
"<code>GET /status.php</code> con <code>installed=true</code>, <code>maintenance=false</code> y <code>needsDbUpgrade=false</code>",
|
||||
"La inicialización terminó sin migraciones pendientes"
|
||||
],
|
||||
[
|
||||
"Paperless-ngx / Tandoor",
|
||||
"HTTP en la dirección de la LAN y el puerto real del servicio",
|
||||
"El frontend y sus dependencias sirven la aplicación"
|
||||
],
|
||||
[
|
||||
"Aplicación principal",
|
||||
"El endpoint de su plantilla, por ejemplo <code>/api/server/ping</code> en Immich",
|
||||
"La pila completa funciona a través de la aplicación que usa las dependencias"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "running no significa healthy",
|
||||
"title": "En ejecución no significa que funcione correctamente",
|
||||
"body": "El estado running solo indica que existe el proceso del LXC. Cuando el servicio ofrece una comprobación mejor, se usa una comprobación exec o HTTP con un tiempo límite. Si un miembro se detiene o no supera su comprobación, la pila no se declara instalada."
|
||||
}
|
||||
}
|
||||
@@ -103,8 +187,14 @@
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{ "title": "Configuración del CT principal", "code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh" },
|
||||
{ "title": "Contrato privado (ejemplo)", "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}" }
|
||||
{
|
||||
"title": "Configuración del CT principal",
|
||||
"code": "hookscript: local:snippets/proxmenux-stack-dependencies.sh"
|
||||
},
|
||||
{
|
||||
"title": "Contrato privado (ejemplo)",
|
||||
"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}"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -121,12 +211,30 @@
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Proxmox VE llama a pre-start", "body": "Antes de arrancar el CT principal, el hook se ejecuta con su VMID y la fase del ciclo de vida." },
|
||||
{ "title": "Un bloqueo por pila", "body": "<code>flock</code> sobre <code>/run/lock/proxmenux-stack-VMID.lock</code> impide dos secuencias de arranque a la vez." },
|
||||
{ "title": "Se lee y valida el contrato", "body": "Se exigen un esquema conocido, dependencias numéricas, etiquetas, una comprobación exec, http o running y un tiempo límite positivo." },
|
||||
{ "title": "Dependencias en orden", "body": "Cada CT debe existir; uno detenido se arranca y uno que ya está en marcha no se reinicia." },
|
||||
{ "title": "Espera de salud", "body": "La comprobación se ejecuta cada dos segundos y se confirma además que el CT sigue en marcha." },
|
||||
{ "title": "Arranca el CT principal", "body": "Cuando todas las dependencias están listas, pre-start termina y Proxmox VE arranca la aplicación." }
|
||||
{
|
||||
"title": "Proxmox VE llama a pre-start",
|
||||
"body": "Antes de arrancar el CT principal, el hook se ejecuta con su VMID y la fase del ciclo de vida."
|
||||
},
|
||||
{
|
||||
"title": "Un bloqueo por pila",
|
||||
"body": "<code>flock</code> sobre <code>/run/lock/proxmenux-stack-VMID.lock</code> impide dos secuencias de arranque a la vez."
|
||||
},
|
||||
{
|
||||
"title": "Se lee y valida el contrato",
|
||||
"body": "Se exigen un esquema conocido, dependencias numéricas, etiquetas, una comprobación exec, http o running y un tiempo límite positivo."
|
||||
},
|
||||
{
|
||||
"title": "Dependencias en orden",
|
||||
"body": "Cada CT debe existir; uno detenido se arranca y uno que ya está en marcha no se reinicia."
|
||||
},
|
||||
{
|
||||
"title": "Esperar a que el servicio esté listo",
|
||||
"body": "La comprobación se ejecuta cada dos segundos y se confirma además que el CT sigue en marcha."
|
||||
},
|
||||
{
|
||||
"title": "Arranca el CT principal",
|
||||
"body": "Cuando todas las dependencias están listas, pre-start termina y Proxmox VE arranca la aplicación."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -138,11 +246,27 @@
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Tipo", "Ejemplo", "Arranques posteriores"],
|
||||
"headers": [
|
||||
"Tipo",
|
||||
"Ejemplo",
|
||||
"Arranques posteriores"
|
||||
],
|
||||
"rows": [
|
||||
["Pila dependiente", "Immich, Nextcloud, aplicación con PostgreSQL", "El hook del CT principal arranca las dependencias y las espera"],
|
||||
["Suite de aplicaciones", "Suite Arr", "Sin miembro principal: cada LXC sigue su propio <code>onboot</code>"],
|
||||
["Aplicación simple", "Jellyfin", "Proxmox VE arranca directamente ese LXC"]
|
||||
[
|
||||
"Pila dependiente",
|
||||
"Immich, Nextcloud, aplicación con PostgreSQL",
|
||||
"El hook del CT principal arranca las dependencias y las espera"
|
||||
],
|
||||
[
|
||||
"Suite de aplicaciones",
|
||||
"Suite Arr",
|
||||
"Sin miembro principal: cada LXC sigue su propio <code>onboot</code>"
|
||||
],
|
||||
[
|
||||
"Aplicación simple",
|
||||
"Jellyfin",
|
||||
"Proxmox VE arranca directamente ese LXC"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -176,21 +300,51 @@
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Cualquier miembro", "body": "El contrato del miembro indica el VMID principal y la lista completa de miembros." },
|
||||
{ "title": "La pila es reproducible", "body": "Se validan identidades, contratos, hook, adaptaciones y la existencia de una reproducción coordinada para esa receta." },
|
||||
{ "title": "Primero las imágenes", "body": "La aplicación no se detiene hasta que todos los digests están resueltos, descargados y verificados." },
|
||||
{ "title": "Detener y respaldar el conjunto", "body": "Los backups nativos verificados se toman con la pila detenida, de modo que aplicación y bases de datos corresponden al mismo momento." },
|
||||
{ "title": "Actualizar y comprobar cada miembro", "body": "Adaptación, red, montajes, secretos y dispositivos se aplican de nuevo antes de la comprobación de salud de cada miembro." },
|
||||
{ "title": "Publicar o recuperar todo", "body": "Los contratos nuevos solo se publican cuando todos los miembros pasan. Si uno falla, se restauran todos." }
|
||||
{
|
||||
"title": "Cualquier miembro",
|
||||
"body": "El contrato del miembro indica el VMID principal y la lista completa de miembros."
|
||||
},
|
||||
{
|
||||
"title": "La pila es reproducible",
|
||||
"body": "Se validan identidades, contratos, hook, adaptaciones y la existencia de una reproducción coordinada para esa receta."
|
||||
},
|
||||
{
|
||||
"title": "Primero las imágenes",
|
||||
"body": "La aplicación no se detiene hasta que todos los digests están resueltos, descargados y verificados."
|
||||
},
|
||||
{
|
||||
"title": "Detener y respaldar el conjunto",
|
||||
"body": "Los backups nativos verificados se toman con la pila detenida, de modo que aplicación y bases de datos corresponden al mismo momento."
|
||||
},
|
||||
{
|
||||
"title": "Actualizar y comprobar cada miembro",
|
||||
"body": "Adaptación, red, montajes, secretos y dispositivos se aplican de nuevo antes de la comprobación de salud de cada miembro."
|
||||
},
|
||||
{
|
||||
"title": "Publicar o recuperar todo",
|
||||
"body": "Los contratos nuevos solo se publican cuando todos los miembros pasan. Si uno falla, se restauran todos."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Modificar", "Qué cambia", "Qué se conserva"],
|
||||
"headers": [
|
||||
"Modificar",
|
||||
"Qué cambia",
|
||||
"Qué se conserva"
|
||||
],
|
||||
"rows": [
|
||||
["Rutas y dispositivos extra", "Se añaden al contenedor de la aplicación o se eliminan de él, y el contenedor se reinicia. No se reconstruye nada", "Los datos de la aplicación, su base de datos y los demás contenedores"],
|
||||
["Qué ejecuta el reconocimiento (Immich)", "El contenedor Machine learning toma la imagen y los dispositivos de la CPU o de una GPU del host. Toda la aplicación se detiene y se actualiza, como en una actualización", "La caché de modelos, la biblioteca y la base de datos. Si algo falla, se restauran los contenedores y la opción anteriores"]
|
||||
[
|
||||
"Rutas y dispositivos extra",
|
||||
"Se añaden al contenedor de la aplicación o se eliminan de él, y el contenedor se reinicia. No se reconstruye nada",
|
||||
"Los datos de la aplicación, su base de datos y los demás contenedores"
|
||||
],
|
||||
[
|
||||
"Qué ejecuta el reconocimiento (Immich)",
|
||||
"El contenedor Machine learning toma la imagen y los dispositivos de la CPU o de una GPU del host. Toda la aplicación se detiene y se actualiza, como en una actualización",
|
||||
"La caché de modelos, la biblioteca y la base de datos. Si algo falla, se restauran los contenedores y la opción anteriores"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -220,7 +374,7 @@
|
||||
"stop": "Detener, primero el principal",
|
||||
"backup": "Backup verificado de cada CT",
|
||||
"replace": "Sustituir el rootfs",
|
||||
"healthy": "¿Todos sanos?",
|
||||
"healthy": "¿Todos funcionan correctamente?",
|
||||
"yes": "Sí",
|
||||
"no": "No",
|
||||
"commit": "Publicar los contratos",
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Datos, rutas y red | ProxMenux",
|
||||
"description": "Cómo conserva OCI manager Apps los datos de un contenedor OCI: discos del contenedor, directorios del host, montajes Rclone, direcciones y redes privadas."
|
||||
"description": "Cómo conserva OCI manager Apps los datos de un contenedor OCI: discos del contenedor, directorios del host, montajes con rclone, direcciones y redes privadas."
|
||||
},
|
||||
"header": {
|
||||
"title": "Datos, rutas y red",
|
||||
"description": "Qué vive en el rootfs, qué sobrevive a su sustitución, cómo se comparten datos entre contenedores y cómo obtiene cada contenedor su dirección.",
|
||||
"description": "Qué se guarda en el rootfs, qué sobrevive a su sustitución, cómo se comparten datos entre contenedores y cómo obtiene cada uno su dirección.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
@@ -14,8 +14,8 @@
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "La persistencia se decide antes de que exista el LXC",
|
||||
"body": "Los volúmenes que publican la imagen y su archivo Compose se leen antes de crear el contenedor. Cada ruta que debe sobrevivir a una actualización se convierte en un punto de montaje independiente del rootfs, de modo que el rootfs solo contiene lo que pertenece a la imagen y puede sustituirse."
|
||||
"title": "La persistencia se decide antes de crear el LXC",
|
||||
"body": "Antes de crear el contenedor se leen los volúmenes declarados por la imagen y por su archivo Compose. Cada ruta que deba conservarse tras una actualización se convierte en un punto de montaje independiente del rootfs. Así, el rootfs solo contiene lo que pertenece a la imagen y puede sustituirse."
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -23,17 +23,35 @@
|
||||
{
|
||||
"id": "questions",
|
||||
"title": "Qué pregunta el instalador",
|
||||
"intro": "La plantilla aporta las rutas que necesita la aplicación. Cada una se sitúa en un disco del contenedor o en un directorio del host, y pueden añadirse más rutas antes del resumen.",
|
||||
"intro": "La plantilla proporciona las rutas que necesita la aplicación. Cada una se ubica en un disco del contenedor o en un directorio del host, y se pueden añadir más rutas antes del resumen.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Rutas requeridas", "body": "Se enumeran <code>/config</code>, <code>/data</code>, bibliotecas, descargas y cualquier volumen que declare la aplicación." },
|
||||
{ "title": "Ubicación", "body": "Cada ruta se sitúa en un disco del contenedor o en un directorio existente del host." },
|
||||
{ "title": "Almacenamiento y tamaño", "body": "Un disco del contenedor se crea en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación por defecto usa <code>local-lvm</code>; la instalación avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. Aparece como <code>vm-VMID-disk-N</code> y se conecta como <code>mpN</code>." },
|
||||
{ "title": "Directorio del host", "body": "Un directorio del host se indica por su ruta. Si no existe, se crea con el propietario que mapea el contenedor." },
|
||||
{ "title": "Rutas adicionales", "body": "Antes de instalar pueden añadirse más pares de ruta del host o volumen y ruta del contenedor." },
|
||||
{ "title": "Resumen", "body": "La relación completa se muestra antes de crear el CT y se guarda en su contrato de instancia." }
|
||||
{
|
||||
"title": "Rutas necesarias",
|
||||
"body": "Se enumeran <code>/config</code>, <code>/data</code>, bibliotecas, descargas y todos los volúmenes declarados por la aplicación."
|
||||
},
|
||||
{
|
||||
"title": "Ubicación",
|
||||
"body": "Cada ruta se ubica en un disco del contenedor o en un directorio del host ya existente."
|
||||
},
|
||||
{
|
||||
"title": "Almacenamiento y tamaño",
|
||||
"body": "Se crea un disco del contenedor en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación predeterminada usa <code>local-lvm</code>; la avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. El disco aparece como <code>vm-VMID-disk-N</code> y se conecta como <code>mpN</code>."
|
||||
},
|
||||
{
|
||||
"title": "Directorio del host",
|
||||
"body": "El directorio del host se indica mediante su ruta. Si no existe, se crea con el usuario al que se mapea el del contenedor como propietario."
|
||||
},
|
||||
{
|
||||
"title": "Rutas adicionales",
|
||||
"body": "Antes de instalar se pueden añadir más pares de ruta o volumen del host y ruta dentro del contenedor."
|
||||
},
|
||||
{
|
||||
"title": "Resumen",
|
||||
"body": "Antes de crear el CT se muestra la correspondencia completa de rutas y se guarda en el contrato de la instancia."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -45,44 +63,85 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Propiedad", "Disco del contenedor", "Directorio del host"],
|
||||
"headers": [
|
||||
"Propiedad",
|
||||
"Disco del contenedor",
|
||||
"Directorio del host"
|
||||
],
|
||||
"rows": [
|
||||
["En la configuración", "<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>", "<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"],
|
||||
["Backup del contenedor (vzdump)", "Incluido, con <code>backup=1</code>", "No incluido"],
|
||||
["Tamaño", "Fijo; crece con un redimensionado del punto de montaje", "El espacio libre del sistema de archivos o dataset del host"],
|
||||
["Otros contenedores", "Solo lo monta su propio contenedor", "El mismo directorio puede montarse en varios contenedores"],
|
||||
["Snapshots y restauración", "Los gestiona Proxmox VE junto con el CT", "Se gestionan en el almacenamiento del host"],
|
||||
["Al eliminar la aplicación", "Se elimina con el contenedor", "Se conserva, con su contenido"],
|
||||
["Al mover el CT a otro nodo", "Se mueve con el CT", "La misma ruta debe existir en el otro nodo"]
|
||||
[
|
||||
"En la configuración",
|
||||
"<code>mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G</code>",
|
||||
"<code>mpN: /mnt/oci-shared/media,mp=/data/media</code>"
|
||||
],
|
||||
[
|
||||
"Backup del contenedor (vzdump)",
|
||||
"Incluido, con <code>backup=1</code>",
|
||||
"No incluido"
|
||||
],
|
||||
[
|
||||
"Tamaño",
|
||||
"Fijo; se amplía redimensionando el punto de montaje",
|
||||
"El espacio libre del sistema de archivos o dataset del host"
|
||||
],
|
||||
[
|
||||
"Otros contenedores",
|
||||
"Solo lo monta el contenedor al que pertenece",
|
||||
"El mismo directorio se puede montar en varios contenedores"
|
||||
],
|
||||
[
|
||||
"Snapshots y restauración",
|
||||
"Los gestiona Proxmox VE junto con el CT",
|
||||
"Se gestionan en el almacenamiento del host"
|
||||
],
|
||||
[
|
||||
"Al eliminar la aplicación",
|
||||
"Se elimina con el contenedor",
|
||||
"Se conserva con su contenido"
|
||||
],
|
||||
[
|
||||
"Al mover el CT a otro nodo",
|
||||
"Se mueve con el CT",
|
||||
"La misma ruta debe existir en el otro nodo"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "El rootfs queda reservado para los binarios y el contenido de la imagen. Una actualización o una recreación lo sustituye sin tocar ninguno de los dos tipos de punto de montaje."
|
||||
"p": "El rootfs se reserva para los binarios y el contenido de la imagen. Una actualización o recreación lo sustituye sin tocar ninguno de los dos tipos de punto de montaje."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Ejemplo: un contenedor con las dos ubicaciones",
|
||||
"title": "Ejemplo: un contenedor con ambas ubicaciones",
|
||||
"blocks": [
|
||||
{
|
||||
"code": {
|
||||
"title": "Jellyfin instalado como CT 151 en local-lvm (extracto)",
|
||||
"code": "rootfs: local-lvm:vm-151-disk-0,size=8G\n# Disco del contenedor, incluido en el backup del CT\nmp0: local-lvm:vm-151-disk-1,mp=/config,backup=1,size=16G\n\n# Directorio del host, fuera del backup del CT\nmp1: /mnt/oci-shared/media,mp=/data/media"
|
||||
"title": "Jellyfin instalado como CT 151 en local-lvm (fragmento)",
|
||||
"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": "Una actualización o una recreación sustituye solo el rootfs: <code>mp0</code> conserva usuarios, bibliotecas y ajustes, y <code>mp1</code> sigue mostrando los mismos archivos multimedia. Restaurar el backup del CT devuelve <code>/config</code>; el directorio multimedia se restaura, si hace falta, desde el backup del almacenamiento del host."
|
||||
"p": "Una actualización o recreación solo sustituye el rootfs: <code>mp0</code> conserva usuarios, bibliotecas y ajustes, y <code>mp1</code> sigue mostrando los mismos archivos multimedia. Al restaurar el backup del CT se recupera <code>/config</code>; si hace falta restaurar el directorio multimedia, se utiliza el backup del almacenamiento del host."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{ "label": "Contrato", "detail": "/config" },
|
||||
{ "label": "Ubicación", "detail": "disco del contenedor\no directorio del host" },
|
||||
{ "label": "LXC", "detail": "siempre /config\npara la aplicación" }
|
||||
{
|
||||
"label": "Contrato",
|
||||
"detail": "/config"
|
||||
},
|
||||
{
|
||||
"label": "Ubicación",
|
||||
"detail": "Disco del contenedor\no directorio del host"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "Siempre /config\npara la aplicación"
|
||||
}
|
||||
],
|
||||
"caption": "La aplicación ve la ruta que publica la imagen; solo cambia dónde se guarda."
|
||||
"caption": "La aplicación ve la ruta declarada por la imagen; solo cambia dónde se almacena."
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -94,33 +153,48 @@
|
||||
{
|
||||
"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": "Directorio del host", "config": "configuración propia" }
|
||||
"labels": {
|
||||
"host": "Directorio del host",
|
||||
"config": "Configuración propia"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Cada contenedor guarda su configuración en su propio disco. La biblioteca o las descargas son un único directorio del host montado en la misma ruta interna de todos los contenedores, de modo que la ruta en la que escribe una aplicación es la misma en la que lee otra."
|
||||
"p": "Cada contenedor guarda su configuración en su propio disco. La biblioteca o las descargas se guardan en un único directorio del host, montado en la misma ruta interna en todos los contenedores. Así, una ruta en la que escribe una aplicación es la misma desde la que lee otra."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "rclone",
|
||||
"title": "Almacenamiento en la nube con la aplicación Rclone",
|
||||
"intro": "La aplicación Rclone del catálogo ofrece, además de su instalación, <strong>Activar un montaje en un contenedor Rclone OCI existente</strong>. Monta un remoto ya creado y autorizado en la interfaz web de Rclone y lo publica en el host, donde otros contenedores pueden usarlo como directorio del host.",
|
||||
"title": "Almacenamiento en la nube mediante la aplicación rclone",
|
||||
"intro": "Además de instalarla, la ficha de rclone en el catálogo permite <strong>Activar un montaje en un contenedor OCI de rclone existente</strong>. Se monta un remoto ya creado y autorizado en la interfaz web de rclone y se publica en el host. Otros contenedores pueden usarlo como un directorio del host.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{ "title": "Contenedor y remoto", "body": "El VMID del contenedor Rclone, el nombre exacto del remoto y, opcionalmente, una ruta dentro de él." },
|
||||
{ "title": "Nombre y caché", "body": "El nombre del montaje y el modo de caché VFS: <code>off</code>, <code>minimal</code>, <code>writes</code> o <code>full</code> (por defecto)." },
|
||||
{ "title": "Vistas publicadas", "body": "Una raíz común, <code>/mnt/oci-shared</code> por defecto, contiene una vista de lectura y escritura en <code>/mnt/oci-shared/remotes/NOMBRE</code> y una de solo lectura en <code>/mnt/oci-shared/remotes-ro/NOMBRE</code>." },
|
||||
{ "title": "Activación", "body": "Tras una confirmación, el CT se detiene, se configuran su orden de arranque y un hookscript de Proxmox VE, y se vuelve a iniciar. La operación espera hasta que las dos vistas están montadas en el host." }
|
||||
{
|
||||
"title": "Contenedor y remoto",
|
||||
"body": "El VMID del contenedor de rclone, el nombre exacto del remoto y, opcionalmente, una ruta dentro de él."
|
||||
},
|
||||
{
|
||||
"title": "Nombre del montaje y caché",
|
||||
"body": "El nombre del montaje y el modo de caché VFS: <code>off</code>, <code>minimal</code>, <code>writes</code> o <code>full</code> (predeterminado)."
|
||||
},
|
||||
{
|
||||
"title": "Vistas publicadas",
|
||||
"body": "Una raíz común, <code>/mnt/oci-shared</code> de forma predeterminada, contiene una vista de lectura y escritura en <code>/mnt/oci-shared/remotes/NAME</code> y otra de solo lectura en <code>/mnt/oci-shared/remotes-ro/NAME</code>."
|
||||
},
|
||||
{
|
||||
"title": "Activación",
|
||||
"body": "Tras confirmar, se detiene el CT, se configuran su comando de arranque y un hookscript de Proxmox VE y se vuelve a iniciar. La operación espera a que ambas vistas estén montadas en el host."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Si el montaje no llega a activarse",
|
||||
"body": "Se restaura la configuración anterior del contenedor y se vuelve a iniciar, de modo que una activación fallida deja Rclone como estaba."
|
||||
"title": "Si el montaje no se activa",
|
||||
"body": "Se restaura la configuración anterior del contenedor y se vuelve a iniciar. Así, si la activación falla, rclone queda como estaba."
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -128,41 +202,58 @@
|
||||
{
|
||||
"id": "network",
|
||||
"title": "Direcciones y redes",
|
||||
"intro": "Una aplicación simple necesita una dirección. Una aplicación multicontenedor necesita además una red estable entre sus miembros.",
|
||||
"intro": "Una aplicación de un solo contenedor necesita una dirección. Una aplicación con varios contenedores también necesita una red estable entre sus miembros.",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{ "icon": "network", "title": "Aplicación simple", "body": "Se eligen el bridge y DHCP o una dirección CIDR fija. El LXC tiene una dirección propia y el resumen muestra las URL completas de los servicios." },
|
||||
{ "icon": "waypoints", "title": "Aplicación multicontenedor", "body": "Se busca una subred libre, se crea un bridge privado persistente y cada miembro (aplicación, base de datos, caché) recibe en él una dirección fija." }
|
||||
{
|
||||
"icon": "network",
|
||||
"title": "Aplicación de un contenedor",
|
||||
"body": "Se elige el puente de red y DHCP o una dirección fija en formato CIDR. El LXC tiene su propia dirección y el resumen muestra las URL completas de los servicios."
|
||||
},
|
||||
{
|
||||
"icon": "waypoints",
|
||||
"title": "Aplicación con varios contenedores",
|
||||
"body": "Se busca una subred libre, se crea un puente privado persistente y cada miembro —aplicación, base de datos y caché— recibe una dirección fija en él."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{ "label": "LAN", "detail": "dirección accesible\nsolo el servicio principal" },
|
||||
{ "label": "LXC principal", "detail": "web / API\nLAN + red privada" },
|
||||
{ "label": "Red privada", "detail": "PostgreSQL · Valkey · ML\ndirecciones fijas" }
|
||||
{
|
||||
"label": "LAN",
|
||||
"detail": "Dirección accesible\nsolo para el servicio principal"
|
||||
},
|
||||
{
|
||||
"label": "LXC principal",
|
||||
"detail": "Web / API\nLAN + red privada"
|
||||
},
|
||||
{
|
||||
"label": "Red privada",
|
||||
"detail": "PostgreSQL · Valkey · ML\ndirecciones fijas"
|
||||
}
|
||||
],
|
||||
"caption": "Las dependencias se comunican por la red privada y no tienen dirección en la LAN."
|
||||
"caption": "Las dependencias se comunican por la red privada y no tienen una dirección en la LAN."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "El contrato de la pila guarda el bridge, la subred, las direcciones y las relaciones entre servicios. La actualización de la aplicación reutiliza la misma topología en todos sus miembros. ProxMenux Monitor abre el contenedor principal en su dirección de la LAN, no en la de la red privada."
|
||||
"p": "El contrato de la pila guarda el puente, la subred, las direcciones y las relaciones entre servicios. Al actualizar la aplicación se reutiliza la misma topología para todos sus miembros. ProxMenux Monitor abre el contenedor principal en su dirección de la LAN, no en la de la red privada."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "ownership",
|
||||
"title": "Propietarios",
|
||||
"title": "Propietarios de archivos y directorios",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Los directorios nuevos se crean con el UID y el GID que mapea el LXC no privilegiado.",
|
||||
"Los directorios existentes no cambian de propietario de forma recursiva.",
|
||||
"Los sockets, los archivos del sistema y las rutas sensibles no se ofrecen como directorios del host genéricos."
|
||||
"Los directorios nuevos se crean con el UID y el GID a los que se mapea el LXC sin privilegios.",
|
||||
"No se cambia recursivamente el propietario de los directorios existentes.",
|
||||
"Los sockets, archivos del sistema y rutas sensibles no se ofrecen como directorios genéricos del host."
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -174,13 +265,37 @@
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": ["Elemento", "En el vzdump del CT", "Dónde se conserva"],
|
||||
"headers": [
|
||||
"Elemento",
|
||||
"En el backup vzdump del CT",
|
||||
"Dónde se conserva"
|
||||
],
|
||||
"rows": [
|
||||
["rootfs OCI", "Sí", "El backup del CT; también puede reconstruirse desde la imagen y el contrato"],
|
||||
["Disco del contenedor con <code>backup=1</code>", "Sí", "El backup del CT"],
|
||||
["Directorio del host", "No", "El backup del almacenamiento del host"],
|
||||
["Contrato de la instancia", "No", "<code>/usr/local/share/proxmenux/oci/instances/VMID/</code> en el host"],
|
||||
["Aplicación multicontenedor", "Cada miembro en su propio backup", "Los backups de cada miembro, más el contrato de la pila y su bridge en el host"]
|
||||
[
|
||||
"Rootfs OCI",
|
||||
"Sí",
|
||||
"En el backup del CT; también se puede reconstruir a partir de la imagen y el contrato"
|
||||
],
|
||||
[
|
||||
"Disco del contenedor con <code>backup=1</code>",
|
||||
"Sí",
|
||||
"El backup del CT"
|
||||
],
|
||||
[
|
||||
"Directorio del host",
|
||||
"No",
|
||||
"El backup del almacenamiento del host"
|
||||
],
|
||||
[
|
||||
"Contrato de la instancia",
|
||||
"Sí, la copia que guarda el CT",
|
||||
"<code>/.proxmenux/oci-record.json</code> dentro del CT; las copias adicionales del host y del clúster se guardan por separado"
|
||||
],
|
||||
[
|
||||
"Aplicación con varios contenedores",
|
||||
"Cada miembro en su propio backup",
|
||||
"Los backups de todos los miembros, más el contrato de la pila y su puente de red en el host"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Community scripts",
|
||||
"body": "El menú también expone dos scripts de terceros del proyecto <a>community-scripts</a>: <em>Proxmox VE Post Install</em> y <em>Proxmox VE Microcode</em>. Son wrappers que hacen <code>wget | bash</code> de los scripts de los autores originales. No los mantiene ProxMenux. Mira <link>External Repositories</link> para detalles y consideraciones de confianza antes de ejecutarlos."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "En Proxmox Backup Server",
|
||||
"body": "En un host Proxmox Backup Server, el mismo menú se abre desde <strong>Settings post-install Proxmox</strong> en el menú de PBS. Automatizado, Personalizable, Apply Available Updates y Uninstall Optimizations funcionan igual que en Proxmox VE, con estas diferencias:",
|
||||
"items": [
|
||||
"<strong>Repositorios y actualización:</strong> cuando el servidor no tiene suscripción y solo está activo el repositorio Enterprise de PBS, ProxMenux pregunta antes de cambiar al repositorio sin suscripción de PBS. El cambio se hace con la API de repositorios del propio servidor, la misma que usa <em>Administration > Repositories</em>. Con una suscripción activa, o con un repositorio sin suscripción o de pruebas ya configurado, las fuentes se mantienen como están.",
|
||||
"<strong>Lista personalizable:</strong> no aparecen las opciones que solo se aplican a Proxmox VE: agente de invitado, VFIO IOMMU, Open vSwitch, velocidad de backups vzdump, pigz, Appliance Manager, Ceph, alta disponibilidad y OVH Real Time Monitoring.",
|
||||
"<strong>Banner de suscripción:</strong> el parche se aplica a la interfaz web de Proxmox Backup Server, y Uninstall Optimizations lo restaura.",
|
||||
"<strong>Figurine:</strong> se instala sin los alias de Proxmox VE.",
|
||||
"<strong>Scripts de la comunidad:</strong> la sección ofrece <em>Proxmox Backup Server Post Install</em> y <em>Proxmox Backup Server Microcode</em> en lugar de los scripts de Proxmox VE."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Relacionado",
|
||||
"items": [
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
"<code>SystemMaxUse=64M</code> / <code>RuntimeMaxUse=60M</code> — caps duros sobre el uso de disco/memoria del journal.",
|
||||
"<code>Compress=yes</code>, <code>Seal=no</code> — comprimir logs, saltar el forward-secure sealing (ahorra CPU).",
|
||||
"<code>MaxLevelStore=info</code> — almacenar info y superiores (requerido para el visor de logs del ProxMenux Monitor y para que Fail2Ban detecte fallos de autenticación SSH/Proxmox desde el journal).",
|
||||
"Rate-limits: <code>1000 eventos / 30 s</code> para prevenir flooding de logs.",
|
||||
"Límite de frecuencia: <code>1000 events / 30 s</code> para evitar una avalancha de registros.",
|
||||
"<code>ForwardToSyslog=no</code>, <code>ForwardToWall=no</code> — no duplicar mensajes a syslog ni broadcastear a consolas."
|
||||
],
|
||||
"tipTitle": "Por qué importa MaxLevelStore=info",
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Fail2Ban | ProxMenux Documentation",
|
||||
"title": "Fail2Ban | Documentación de ProxMenux",
|
||||
"description": "Instala Fail2Ban con tres jails afinados para Proxmox (SSH agresivo, Proxmox UI 8006, ProxMenux Monitor 8008). Incluye el arreglo de journald MaxLevelStore, servicios de log propios para fiabilidad, backend nftables/iptables autodetectado y hardening de SSH MaxAuthTries.",
|
||||
"ogTitle": "Fail2Ban | ProxMenux Documentation",
|
||||
"ogDescription": "Protección contra fuerza bruta para SSH y las UIs web de Proxmox, con arreglos específicos de journald y backend para Proxmox."
|
||||
"ogTitle": "Fail2Ban | Documentación de ProxMenux",
|
||||
"ogDescription": "Protección contra fuerza bruta para SSH y las interfaces web de Proxmox, con correcciones de journald y del backend específicas para Proxmox."
|
||||
},
|
||||
"header": {
|
||||
"title": "Fail2Ban",
|
||||
"description": "Instala Fail2Ban con una configuración específica para Proxmox: tres jails (SSH agresivo, Proxmox UI en puerto 8006, ProxMenux Monitor en puerto 8008 + proxy inverso), un arreglo del nivel de log de journald para que los eventos de autenticación SSH se almacenen de verdad, dos servicios logger journal-a-archivo que rodean un problema conocido del backend systemd de Fail2Ban, backend de firewall autodetectado y hardening de SSH MaxAuthTries.",
|
||||
"description": "Instala Fail2Ban con configuración para Proxmox: tres jails (SSH agresivo, Proxmox en 8006 y ProxMenux Monitor en 8008 y proxy inverso), corrección del nivel de journald para guardar fallos SSH, dos servicios que copian el journal a archivos para evitar un problema del backend systemd de Fail2Ban, detección del backend de firewall y refuerzo SSH mediante MaxAuthTries.",
|
||||
"section": "Seguridad"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Qué hace",
|
||||
"body": "Instala Fail2Ban desde los repos de Debian y escribe una configuración completa afinada para Proxmox que protege tres superficies de ataque (SSH, Proxmox UI, ProxMenux Monitor) por defecto. Detecta una instalación existente y ofrece un menú de gestión (reinstalar / eliminar) en lugar de volver a ejecutar el instalador."
|
||||
"body": "Instala Fail2Ban desde los repositorios Debian y escribe una configuración para Proxmox que protege SSH, Proxmox UI y ProxMenux Monitor desde el primer momento. Si detecta una instalación existente, ofrece un menú para reinstalar o eliminar."
|
||||
},
|
||||
"firstLaunch": {
|
||||
"heading": "Diálogo de primer lanzamiento",
|
||||
"body": "En un host sin Fail2Ban, el script muestra un diálogo de confirmación que resume todo lo que va a instalar y configurar. Cancelar sale sin cambios; confirmar arranca el flujo de instalación.",
|
||||
"imageAlt": "Diálogo de confirmación de instalación de Fail2Ban listando los tres jails, el arreglo de journald y el hardening de SSH"
|
||||
"body": "Sin Fail2Ban instalado, el script muestra un diálogo con lo que instalará y configurará. Cancelar termina sin cambios; confirmar inicia la instalación.",
|
||||
"imageAlt": "Confirmación de instalación de Fail2Ban con las tres jails, corrección de journald y refuerzo SSH"
|
||||
},
|
||||
"jails": {
|
||||
"heading": "Los tres jails",
|
||||
"headerJail": "Jail",
|
||||
"headerProtects": "Protege",
|
||||
"headerRetries": "Reintentos / Ventana",
|
||||
"headerBan": "Tiempo de ban",
|
||||
"headerBan": "Tiempo de bloqueo",
|
||||
"rows": [
|
||||
{
|
||||
"jail": "[sshd]",
|
||||
@@ -49,12 +49,12 @@
|
||||
},
|
||||
"journald": {
|
||||
"heading": "Por qué importa el arreglo de journald",
|
||||
"intro": "Proxmox entrega <code>/etc/systemd/journald.conf</code> con <codeNw>MaxLevelStore=warning</codeNw>. journald descarta cada mensaje de log <em>por debajo</em> de warning antes de almacenarlo. SSH y PAM emiten fallos de autenticación a niveles <em>info</em> / <em>notice</em>, así que:",
|
||||
"intro": "Proxmox incluye <code>/etc/systemd/journald.conf</code> con <codeNw>MaxLevelStore=warning</codeNw>. journald descarta los mensajes de nivel <em>inferior</em> a warning antes de guardarlos. SSH y PAM emiten fallos de autenticación en los niveles <em>info</em> / <em>notice</em>, por lo que:",
|
||||
"diagram": {
|
||||
"sshLabel": "SSH / PAM",
|
||||
"sshDetail": "fallo de autenticación\n(nivel info / notice)",
|
||||
"journaldLabel": "journald",
|
||||
"journaldDetail": "MaxLevelStore=warning\n→ evento descartado en silencio",
|
||||
"journaldDetail": "MaxLevelStore=warning\n→ evento descartado sin aviso",
|
||||
"fail2banLabel": "Fail2Ban",
|
||||
"fail2banDetail": "no ve nada\n→ nunca banea nada",
|
||||
"arrowLabel": "Proxmox por defecto"
|
||||
@@ -65,8 +65,8 @@
|
||||
},
|
||||
"loggers": {
|
||||
"heading": "Por qué dos servicios logger propios",
|
||||
"intro1": "Fail2Ban puede leer directamente del journal de systemd (<code>backend = systemd</code>), pero en Proxmox este backend tiene problemas conocidos de fiabilidad con los procesos worker de <code>pvedaemon</code> (los eventos de autenticación aparecen en el journal pero Fail2Ban no siempre los recoge) e intermitentemente con <code>sshd</code>.",
|
||||
"intro2": "La solución alternativa: ProxMenux crea dos pequeños servicios systemd que hacen <code>journalctl -f</code> de las unidades relevantes y añaden cada línea a un archivo. Fail2Ban entonces lee esos archivos con el sólido como una roca <code>backend = auto</code> (modo archivo):",
|
||||
"intro1": "Fail2Ban puede leer directamente el journal de systemd (<code>backend = systemd</code>), pero en Proxmox este backend presenta problemas de fiabilidad con procesos worker de <code>pvedaemon</code> (los eventos aparecen en el journal pero Fail2Ban no siempre los recoge) y ocasionalmente con <code>sshd</code>.",
|
||||
"intro2": "ProxMenux crea dos pequeños servicios systemd que siguen las unidades correspondientes con <code>journalctl -f</code> y añaden cada línea a un archivo. Fail2Ban lee esos archivos con el fiable <code>backend = auto</code> (modo archivo):",
|
||||
"headerService": "Servicio",
|
||||
"headerSource": "Unidad origen",
|
||||
"headerOutput": "Archivo de salida",
|
||||
@@ -91,12 +91,12 @@
|
||||
},
|
||||
"hardening": {
|
||||
"heading": "Hardening de SSH: MaxAuthTries",
|
||||
"intro": "El control de Lynis <strong>SSH-7408</strong> recomienda <code>MaxAuthTries 3</code> en <code>sshd_config</code>. Con el <code>maxretry = 2</code> de Fail2Ban en el jail SSH, un cliente malicioso nunca llega a tres intentos de todas formas — pero el ajuste explícito satisface la auditoría y añade defensa en profundidad (p. ej. si Fail2Ban está parado por mantenimiento).",
|
||||
"intro": "El control Lynis <strong>SSH-7408</strong> recomienda <code>MaxAuthTries 3</code> en <code>sshd_config</code>. La jail SSH usa <code>maxretry = 2</code> para bloquear tras fallos repetidos; MaxAuthTries limita los intentos dentro de una conexión. Este ajuste SSH añade defensa en profundidad, también cuando Fail2Ban está detenido por mantenimiento.",
|
||||
"installerIntro": "El instalador:",
|
||||
"items": [
|
||||
"Lee el valor actual de <code>MaxAuthTries</code> (o por defecto 6 si está ausente).",
|
||||
"Lo guarda en <code>/usr/local/share/proxmenux/sshd_maxauthtries_backup</code>.",
|
||||
"Edita <code>sshd_config</code> en sitio — reemplaza la línea existente, descomenta la línea comentada o la añade.",
|
||||
"Edita <code>sshd_config</code> directamente: sustituye la línea existente, descomenta la comentada o añade una nueva.",
|
||||
"Recarga <code>sshd</code> (reload, no restart, para mantener vivas las sesiones existentes)."
|
||||
],
|
||||
"outro": "Al desinstalar, el valor original guardado se restaura y se recarga <code>sshd</code> otra vez."
|
||||
@@ -109,7 +109,7 @@
|
||||
"rows": [
|
||||
{
|
||||
"action": "Reinstalar",
|
||||
"what": "Vuelve a ejecutar el instalador completo — reescribe todos los jails con los valores por defecto actuales de ProxMenux. Úsalo cuando una actualización de ProxMenux suba los valores recomendados."
|
||||
"what": "Repite la instalación completa y reescribe todas las jails con los valores actuales de ProxMenux. Úsalo cuando una actualización cambie las recomendaciones."
|
||||
},
|
||||
{
|
||||
"action": "Eliminar",
|
||||
@@ -125,7 +125,7 @@
|
||||
"troubleshoot": {
|
||||
"heading": "Solución de problemas",
|
||||
"neverBansTitle": "Fail2Ban corre pero nunca banea nada",
|
||||
"neverBansBody": "Comprueba que los archivos de log de autenticación reciben entradas de verdad: <code>tail -f /var/log/ssh-auth.log</code> y prueba un intento SSH con contraseña incorrecta desde otra máquina. Si el log se queda vacío, el servicio logger no está corriendo: <code>systemctl status ssh-auth-logger.service</code>. Si está activo pero el log está vacío, comprueba que el drop-in de journald surtió efecto: <code>journalctl --dump-catalog | head</code> — eventos a nivel <em>info</em> deberían ser visibles.",
|
||||
"neverBansBody": "Comprueba que <code>tail -f /var/log/ssh-auth.log</code> recibe una entrada tras intentar acceder por SSH con contraseña incorrecta desde otra máquina. Si sigue vacío, consulta <code>systemctl status ssh-auth-logger.service</code>. Si el logger está activo, mira los eventos SSH recientes con <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> y comprueba que el drop-in de journald admite el nivel <em>info</em>.",
|
||||
"monitorEmptyTitle": "El jail del Monitor de ProxMenux no tiene entradas ni siquiera tras logins fallidos",
|
||||
"monitorEmptyBody": "El jail <code>[proxmenux]</code> lee <code>/var/log/proxmenux-auth.log</code>, que lo escribe la app Flask del Monitor de ProxMenux — no un logger de journald. Si no usas el Monitor, el archivo se queda vacío y el jail nunca dispara. Eso es lo esperado; la configuración del jail es inocua. Si sí usas el Monitor y el log está vacío, comprueba la configuración de logging de Flask.",
|
||||
"selfBanTitle": "Me he baneado a mí mismo",
|
||||
@@ -143,7 +143,7 @@
|
||||
"related": {
|
||||
"heading": "Relacionado",
|
||||
"monitorLabel": "ProxMenux Monitor → pestaña de Seguridad",
|
||||
"monitorTail": " — misma instalación accesible desde el panel, más estado en vivo de los jails, IPs baneadas y ajuste por jail de reintentos / tiempo de ban desde el navegador.",
|
||||
"monitorTail": " — instalación desde el panel, estado de las jails en directo, IP bloqueadas y ajuste de reintentos y duración de bloqueo por jail desde el navegador.",
|
||||
"lynisLabel": "Lynis",
|
||||
"lynisTail": " — ejecuta una auditoría de seguridad antes/después para confirmar que el control SSH-7408 se satisface.",
|
||||
"securityLabel": "Resumen de Seguridad",
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Seguridad de Proxmox — Fail2Ban, auditoría de hardening con Lynis | ProxMenux",
|
||||
"description": "Dos herramientas de seguridad instalables para Proxmox VE: Fail2Ban (prevención de intrusiones para SSH, la UI web de Proxmox y el Monitor de ProxMenux) y Lynis (escáner de auditoría y hardening de seguridad instalado desde GitHub upstream).",
|
||||
"ogTitle": "Seguridad de Proxmox — Fail2Ban, auditoría de hardening con Lynis",
|
||||
"ogDescription": "Fail2Ban y Lynis para Proxmox VE — prevención de intrusiones más una auditoría de hardening instaladas y gestionadas por ProxMenux.",
|
||||
"title": "Seguridad de Proxmox — Fail2Ban y auditoría de refuerzo con Lynis | ProxMenux",
|
||||
"description": "Dos herramientas de seguridad para Proxmox VE: Fail2Ban (prevención de intrusiones para SSH, la interfaz web de Proxmox y ProxMenux Monitor) y Lynis (auditor de seguridad y refuerzo del sistema instalado desde el repositorio original en GitHub).",
|
||||
"ogTitle": "Seguridad de Proxmox — Fail2Ban y auditoría de refuerzo con Lynis",
|
||||
"ogDescription": "Fail2Ban y Lynis para Proxmox VE: prevención de intrusiones y auditoría de refuerzo, instaladas y gestionadas por ProxMenux.",
|
||||
"twitterTitle": "Seguridad de Proxmox | ProxMenux",
|
||||
"twitterDescription": "Fail2Ban y Lynis para Proxmox VE — prevención de intrusiones y auditoría de hardening."
|
||||
"twitterDescription": "Fail2Ban y Lynis para Proxmox VE: prevención de intrusiones y auditoría de refuerzo."
|
||||
},
|
||||
"header": {
|
||||
"title": "Seguridad",
|
||||
"description": "Dos herramientas de seguridad complementarias para Proxmox VE: una defensa activa (Fail2Ban — banea IPs que atacan SSH o las UIs web) y una auditoría offline (Lynis — escanea el sistema en busca de huecos de hardening y da una puntuación 0–100). Ambas se instalan y gestionan mediante su propio menú dedicado, con detección de una instalación existente antes de cualquier acción.",
|
||||
"description": "Dos herramientas complementarias para Proxmox VE: defensa activa (Fail2Ban bloquea IP que atacan SSH o las interfaces web) y auditoría local (Lynis busca carencias de seguridad y da una puntuación de 0 a 100). Cada una tiene su propio menú de instalación y gestión, que detecta instalaciones existentes antes de actuar.",
|
||||
"section": "Seguridad"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Defensa activa vs. auditoría offline",
|
||||
"body": "Estas dos herramientas responden a preguntas distintas. <strong>Fail2Ban</strong> responde a <em>\"¿hay algo atacándonos ahora mismo?\"</em> vigilando los logs de autenticación y baneando las IPs ofensoras. <strong>Lynis</strong> responde a <em>\"¿cómo de hardened está este host?\"</em> ejecutando una auditoría de un tirón e imprimiendo recomendaciones concretas. Úsalas juntas: Lynis te dice qué arreglar, Fail2Ban gestiona el abuso en vivo."
|
||||
"title": "Defensa activa y auditoría local",
|
||||
"body": "Responden a preguntas distintas. <strong>Fail2Ban</strong> contesta <em>«¿nos están atacando ahora?»</em> vigilando registros de autenticación y bloqueando las IP responsables. <strong>Lynis</strong> contesta <em>«¿qué nivel de refuerzo tiene este host?»</em> mediante una auditoría puntual con recomendaciones concretas. Usa ambas: Lynis indica qué mejorar y Fail2Ban responde a los ataques en curso."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Abrir el menú",
|
||||
"body": "Desde el menú principal de ProxMenux, selecciona <strong>Seguridad</strong>. Verás esto:",
|
||||
"body": "Desde el menú principal de ProxMenux, selecciona <strong>Seguridad</strong>. Verás lo siguiente:",
|
||||
"imageAlt": "Menú de Seguridad con opciones de Fail2Ban y Lynis"
|
||||
},
|
||||
"pick": {
|
||||
@@ -28,7 +28,7 @@
|
||||
"cards": {
|
||||
"fail2ban": {
|
||||
"title": "Fail2Ban",
|
||||
"body": "Prevención de intrusiones activa. Vigila los logs de autenticación de SSH y las UIs web y banea IPs tras fallos repetidos.",
|
||||
"body": "Prevención activa de intrusiones. Vigila los registros de autenticación de SSH y las interfaces web y bloquea IP tras fallos repetidos.",
|
||||
"bullets": [
|
||||
"Tres jails: SSH, Proxmox UI (8006), ProxMenux Monitor (8008)",
|
||||
"Arregla los valores por defecto de journald de Proxmox que bloquean los logs de autenticación",
|
||||
@@ -38,28 +38,28 @@
|
||||
},
|
||||
"lynis": {
|
||||
"title": "Lynis",
|
||||
"body": "Auditor de seguridad offline. Escanea el host e imprime una puntuación de hardening más pistas concretas de remediación.",
|
||||
"body": "Auditor local de seguridad. Analiza el host y muestra una puntuación de refuerzo y recomendaciones concretas para corregir problemas.",
|
||||
"bullets": [
|
||||
"Instalado desde el GitHub upstream de CISOfy (siempre el último)",
|
||||
"Puntuación de hardening 0–100 + lista de warnings y sugerencias",
|
||||
"Acciones de ejecutar auditoría y actualizar dentro del menú",
|
||||
"De solo lectura por diseño — nunca cambia el sistema"
|
||||
"Instalado desde el repositorio original de CISOfy en GitHub (última versión)",
|
||||
"Puntuación de refuerzo 0–100 y lista de advertencias y sugerencias",
|
||||
"Acciones de auditoría y actualización desde el menú",
|
||||
"De solo lectura: nunca modifica el sistema"
|
||||
]
|
||||
}
|
||||
},
|
||||
"workflowTip": {
|
||||
"title": "Flujo de trabajo que usa ambos",
|
||||
"body": "Ejecuta primero una auditoría de Lynis para ver tu puntuación de partida y las recomendaciones principales. Aplica los arreglos que quieras. Después instala Fail2Ban — implementa una de las recomendaciones más comunes de Lynis (protección contra fuerza bruta SSH) automáticamente y ajusta <code>MaxAuthTries</code> en <code>sshd_config</code> para satisfacer el control SSH-7408. Vuelve a ejecutar Lynis después para confirmar que la puntuación mejoró."
|
||||
"body": "Ejecuta primero una auditoría Lynis para ver la puntuación inicial y las recomendaciones principales. Aplica las correcciones que elijas. Instala Fail2Ban: implementa automáticamente la protección contra fuerza bruta SSH y ajusta <code>MaxAuthTries</code> en <code>sshd_config</code> para cumplir el control SSH-7408. Vuelve a ejecutar Lynis para comprobar la mejora."
|
||||
},
|
||||
"fail2banSection": {
|
||||
"heading": "Fail2Ban",
|
||||
"body": "ProxMenux instala Fail2Ban con una configuración afinada específicamente para Proxmox. Más allá del jail estándar de SSH, añade protección para la UI web de Proxmox y el Monitor de ProxMenux, y rodea dos rarezas específicas de Proxmox: un valor por defecto de journald que descarta eventos de autenticación, y el problema del backend systemd que impide a Fail2Ban leer de forma fiable ciertas fuentes del journal. La página de detalle cubre el flujo de instalación completo, los tres jails, el arreglo de journald, el cambio de hardening SSH y la chuleta de solución de problemas.",
|
||||
"optionTitle": "Fail2Ban — instalar y gestionar",
|
||||
"optionDescription": "Tres jails preconfigurados (sshd agresivo, Proxmox UI puerto 8006, ProxMenux Monitor puerto 8008 + proxy inverso), backend nftables/iptables autodetectado, arreglo de journald y hardening de SSH MaxAuthTries."
|
||||
"optionDescription": "Tres jails preconfiguradas (sshd agresivo, Proxmox en 8006, ProxMenux Monitor en 8008 y proxy inverso), detección de nftables/iptables, corrección de journald y refuerzo SSH mediante MaxAuthTries."
|
||||
},
|
||||
"lynisSection": {
|
||||
"heading": "Lynis",
|
||||
"body": "ProxMenux clona Lynis desde <code>github.com/CISOfy/lynis</code> en <code>/opt/lynis</code> y lo expone como <code>/usr/local/bin/lynis</code>. El paquete de Debian se evita intencionadamente porque va varias versiones mayores por detrás de upstream. La página de detalle cubre el flujo de instalar / auditar / actualizar / desinstalar, cómo leer el informe y cómo actuar sobre los hallazgos.",
|
||||
"body": "ProxMenux clona Lynis de <code>github.com/CISOfy/lynis</code> en <code>/opt/lynis</code> y lo expone como <code>/usr/local/bin/lynis</code>. Evita el paquete Debian porque va varias versiones principales por detrás del proyecto original. La página detallada explica instalación, auditoría, actualización, desinstalación, lectura del informe y aplicación de sus recomendaciones.",
|
||||
"optionTitle": "Lynis — instalar, auditar y gestionar",
|
||||
"optionDescription": "Instala el último Lynis desde el repo oficial de CISOfy en GitHub (no el paquete más antiguo de Debian), ejecuta auditorías del sistema con puntuación de hardening y actualiza vía git pull."
|
||||
},
|
||||
|
||||
@@ -1,37 +1,37 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Lynis | ProxMenux Documentation",
|
||||
"description": "Instala Lynis desde el repositorio oficial de CISOfy en GitHub (siempre el último), ejecuta una auditoría del sistema con puntuación de hardening 0–100, actualiza vía git pull. De solo lectura por diseño — nunca modifica el sistema.",
|
||||
"ogTitle": "Lynis | ProxMenux Documentation",
|
||||
"ogDescription": "Instala y ejecuta el auditor de seguridad Lynis en Proxmox VE. Instalación desde GitHub upstream, auditoría, actualización."
|
||||
"title": "Lynis | Documentación de ProxMenux",
|
||||
"description": "Instala Lynis desde el repositorio oficial CISOfy de GitHub, ejecuta una auditoría con puntuación de refuerzo de 0 a 100 y actualiza mediante git pull. Auditor de solo lectura: no modifica el sistema.",
|
||||
"ogTitle": "Lynis | Documentación de ProxMenux",
|
||||
"ogDescription": "Instala y ejecuta el auditor de seguridad Lynis en Proxmox VE. Instalación desde el repositorio original GitHub, auditoría y actualización."
|
||||
},
|
||||
"header": {
|
||||
"title": "Lynis",
|
||||
"description": "Clona el último Lynis desde el repositorio oficial de CISOfy en GitHub, lo expone como /usr/local/bin/lynis y ofrece acciones de ejecutar auditoría / actualizar / reinstalar / desinstalar desde el menú. Auditor de solo lectura por diseño — nunca modifica el sistema, solo reporta.",
|
||||
"description": "Clona el último Lynis del repositorio oficial CISOfy en GitHub, lo expone como /usr/local/bin/lynis y ofrece auditoría, actualización, reinstalación y desinstalación desde el menú. El auditor es de solo lectura: informa sin modificar el sistema.",
|
||||
"section": "Seguridad"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Qué hace",
|
||||
"body": "Instala Lynis (el auditor de seguridad de código abierto de CISOfy) desde GitHub upstream en <code>/opt/lynis</code> y crea un wrapper en <code>/usr/local/bin/lynis</code> para que esté en tu <code>PATH</code>. Detecta una instalación existente al arrancar y muestra un menú de gestión (auditoría / actualizar / reinstalar / eliminar) en su lugar."
|
||||
"body": "Instala Lynis, el auditor de código abierto de CISOfy, desde su repositorio GitHub en <code>/opt/lynis</code> y crea un script lanzador en <code>/usr/local/bin/lynis</code> para incluirlo en <code>PATH</code>. Si detecta una instalación existente al abrirlo, muestra un menú de auditoría, actualización, reinstalación o eliminación."
|
||||
},
|
||||
"manageMenu": {
|
||||
"heading": "Menú de gestión (tras la instalación)",
|
||||
"heading": "Menú de gestión (tras instalar)",
|
||||
"intro": "Una vez instalado Lynis, cada invocación posterior abre el menú de gestión en lugar de volver a ejecutar el instalador. Desde aquí lanzas una auditoría, actualizas vía git pull, reinstalas o desinstalas:",
|
||||
"imageAlt": "Menú de gestión de Lynis con opciones de auditoría, actualizar, reinstalar y eliminar"
|
||||
},
|
||||
"whyUpstream": {
|
||||
"heading": "Por qué GitHub upstream, no apt",
|
||||
"intro": "Debian entrega Lynis vía apt, pero el paquete suele ir varias versiones mayores por detrás de upstream. Los controles más nuevos, los arreglos para nuevos vectores de ataque y las recomendaciones refinadas solo aterrizan en el repo de GitHub. El propio Lynis es un script de shell autocontenido — sin compilación, sin dependencias más allá de <code>git</code> para la instalación — así que clonar el repo es el método de instalación canónico recomendado por la propia CISOfy.",
|
||||
"heading": "Por qué el repositorio oficial de GitHub y no apt",
|
||||
"intro": "Debian distribuye Lynis mediante apt, pero el paquete suele ir varias versiones principales por detrás del proyecto original. GitHub recibe antes los controles, correcciones de nuevos vectores de ataque y mejoras de las recomendaciones. Lynis es un script de shell autocontenido, sin compilación ni dependencias de instalación aparte de <code>git</code>; por eso clonar el repositorio es el método recomendado por CISOfy.",
|
||||
"headerSource": "Origen",
|
||||
"headerPath": "Ruta de instalación",
|
||||
"headerPath": "Install path",
|
||||
"headerUpdate": "Método de actualización",
|
||||
"headerFresh": "Frescura de versión",
|
||||
"headerFresh": "Actualidad de la versión",
|
||||
"rows": [
|
||||
{
|
||||
"sourceRich": "<strong>ProxMenux (este script)</strong>",
|
||||
"path": "/opt/lynis/",
|
||||
"update": "git pull (desde el menú)",
|
||||
"fresh": "Última versión upstream"
|
||||
"fresh": "Última versión del proyecto original"
|
||||
},
|
||||
{
|
||||
"sourceRich": "<strong>Debian apt</strong>",
|
||||
@@ -59,13 +59,13 @@
|
||||
"<code>/opt/lynis/lynis</code> — ruta directa (por si el wrapper se eliminó)",
|
||||
"<code>/usr/bin/lynis</code> — versión instalada por apt, si el usuario la instaló así anteriormente"
|
||||
],
|
||||
"outro": "Si se encuentra cualquiera de estas, se abre el menú de gestión. El script <strong>no</strong> desinstala un Lynis instalado por apt — solo el que él mismo gestiona (<code>/opt/lynis</code> + el wrapper)."
|
||||
"outro": "Si encuentra cualquiera de estas rutas, abre el menú de gestión. El script <strong>no</strong> desinstala Lynis instalado por apt; solo el que gestiona en <code>/opt/lynis</code> y su lanzador."
|
||||
},
|
||||
"audit": {
|
||||
"heading": "Ejecutar una auditoría",
|
||||
"intro": "Desde el menú de gestión, elige <strong>Ejecutar auditoría de seguridad ahora</strong>. Esto equivale a ejecutar:",
|
||||
"intro": "En el menú de gestión, elige <strong>Ejecutar auditoría de seguridad ahora</strong>. Equivale a ejecutar:",
|
||||
"code": "lynis audit system --no-colors",
|
||||
"outro": "La auditoría tarda de 30 segundos a unos minutos según el tamaño del host. La salida fluye directamente al terminal — no hay spinner. Lynis imprime secciones por cada categoría de control, marcando cada test como <ok>[ OK ]</ok>, <warn>[ WARNING ]</warn> o <sugg>[ SUGGESTION ]</sugg>. El resumen al final tiene los números titulares:",
|
||||
"outro": "La auditoría tarda de 30 segundos a varios minutos según el tamaño del host. La salida se muestra directamente en el terminal, sin indicador giratorio. Lynis organiza los controles por categoría y marca cada prueba como <ok>[ OK ]</ok>, <warn>[ WARNING ]</warn> o <sugg>[ SUGGESTION ]</sugg>. El resumen final muestra las cifras principales:",
|
||||
"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": {
|
||||
@@ -99,7 +99,7 @@
|
||||
},
|
||||
"update": {
|
||||
"heading": "Actualizar Lynis",
|
||||
"body": "Desde el menú de gestión, <strong>Actualizar Lynis a la última versión</strong> ejecuta <code>git pull --quiet</code> dentro de <code>/opt/lynis</code>. Si el directorio existe pero no es un checkout de Git (p. ej. alguien copió los archivos a mano), el script recae en una reinstalación completa."
|
||||
"body": "En el menú, <strong>Actualizar Lynis a la última versión</strong> ejecuta <code>git pull --quiet</code> en <code>/opt/lynis</code>. Si el directorio existe pero no es una copia Git (por ejemplo, se copiaron archivos manualmente), el script reinstala por completo."
|
||||
},
|
||||
"reinstall": {
|
||||
"heading": "Reinstalar / desinstalar",
|
||||
@@ -108,7 +108,7 @@
|
||||
"rows": [
|
||||
{
|
||||
"actionRich": "<strong>Reinstalar</strong>",
|
||||
"whatRich": "Elimina <code>/opt/lynis</code>, vuelve a clonar desde GitHub, recrea el wrapper. Úsalo si el checkout local está corrupto."
|
||||
"whatRich": "Elimina <code>/opt/lynis</code>, clona de nuevo desde GitHub y recrea el lanzador. Úsalo si la copia local está dañada."
|
||||
},
|
||||
{
|
||||
"actionRich": "<strong>Eliminar</strong>",
|
||||
@@ -128,7 +128,7 @@
|
||||
"notFoundTitle": "lynis: command not found tras la instalación",
|
||||
"notFoundIntro": "El wrapper en <code>/usr/local/bin/lynis</code> no se creó o se eliminó. Arreglo más rápido: reinstalar desde el menú. Arreglo manual:",
|
||||
"notFoundCode": "cat > /usr/local/bin/lynis <<'EOF'\n#!/bin/bash\ncd /opt/lynis && ./lynis \"$@\"\nEOF\nchmod +x /usr/local/bin/lynis",
|
||||
"sshTitle": "La auditoría imprime \"Warning: Test SSH-7408 — MaxAuthTries set incorrectly\"",
|
||||
"sshTitle": "La auditoría muestra \"Warning: Test SSH-7408 — MaxAuthTries set incorrectly\"",
|
||||
"sshIntro": "El demonio SSH permite demasiados intentos de autenticación por conexión. O bien instala <link>Fail2Ban</link> desde ProxMenux (que establece <code>MaxAuthTries=3</code> automáticamente) o edita <code>/etc/ssh/sshd_config</code> a mano:",
|
||||
"sshCode": "sed -i 's/^#?MaxAuthTries.*/MaxAuthTries 3/' /etc/ssh/sshd_config\nsystemctl reload sshd",
|
||||
"scoreTitle": "La puntuación bajó tras una actualización de Proxmox",
|
||||
@@ -140,7 +140,7 @@
|
||||
},
|
||||
"sample": {
|
||||
"heading": "Informe de ejemplo",
|
||||
"intro": "ProxMenux Monitor empaqueta cada ejecución de Lynis en un PDF de varias páginas disponible desde la <link>pestaña de Seguridad</link> en el panel. La primera página es el resumen ejecutivo — puntuación de hardening, info del sistema, vista general de la postura de seguridad. Las páginas siguientes listan cada warning con explicación y cada sugerencia rankeada por impacto, más el inventario de paquetes usado durante la auditoría.",
|
||||
"intro": "ProxMenux Monitor genera un PDF de varias páginas para cada ejecución de Lynis desde la <link>pestaña Seguridad</link>. La primera página resume puntuación de refuerzo, información del sistema y estado de seguridad. Las siguientes detallan cada advertencia, las sugerencias ordenadas por impacto y el inventario de paquetes utilizado en la auditoría.",
|
||||
"imageAlt": "Primera página del PDF del Lynis Security Audit Report — resumen ejecutivo con Hardening Index 71/100, bloque de información del sistema y vista general de la postura de seguridad con firewall, escáner de malware y recuento de paquetes instalados",
|
||||
"captionPrefix": "Primera página de un informe de ejemplo. El PDF completo (",
|
||||
"captionLink": "ejemplo",
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "HTTPS para ProxMenux Monitor — certificado del host Proxmox o rutas personalizadas | ProxMenux",
|
||||
"description": "Sirve ProxMenux Monitor sobre HTTPS usando o bien el certificado del host Proxmox (autodetectado, incluyendo el certificado Let's Encrypt subido vía la pestaña ACME de Proxmox) o un certificado personalizado en cualquier ruta del disco.",
|
||||
"description": "Sirve ProxMenux Monitor por HTTPS con el certificado del host Proxmox (detectado automáticamente, incluido el de Let’s Encrypt instalado mediante ACME de Proxmox) o un certificado personalizado en cualquier ruta del disco.",
|
||||
"ogTitle": "HTTPS para ProxMenux Monitor — certificado del host Proxmox o personalizado",
|
||||
"ogDescription": "Habilita HTTPS en el puerto 8008 con el certificado del host Proxmox o cualquier par .pem / .key personalizado."
|
||||
},
|
||||
"header": {
|
||||
"title": "HTTPS para ProxMenux Monitor",
|
||||
"description": "Activa HTTPS para el Monitor (puerto 8008) usando o bien el certificado del host Proxmox que el Monitor autodetecta, o un certificado personalizado ubicado en cualquier sitio del disco. La opción de Proxmox elige de forma transparente el certificado subido por ACME cuando está presente, así que un certificado Let's Encrypt gestionado por la UI de Proxmox se reutiliza sin un trabajo de renovación extra.",
|
||||
"description": "Activa HTTPS para Monitor en 8008 con el certificado del host Proxmox detectado automáticamente o uno personalizado en disco. La opción Proxmox prefiere el certificado instalado mediante ACME, si existe, y reutiliza el Let’s Encrypt gestionado por Proxmox sin otra tarea de renovación.",
|
||||
"section": "Seguridad"
|
||||
},
|
||||
"intro": {
|
||||
@@ -15,20 +15,20 @@
|
||||
"body": "Cómo cambiar el Monitor de HTTP a HTTPS en el panel Settings → Security, a qué apunta realmente cada fuente de certificado en disco, cómo se comporta la opción de Proxmox cuando el host tiene un certificado Let's Encrypt y cómo establecer rutas personalizadas si gestionas certificados fuera de Proxmox."
|
||||
},
|
||||
"wheresetting": {
|
||||
"heading": "Dónde vive el ajuste",
|
||||
"body": "Abre el Monitor y ve a <strong>Settings → Security → HTTPS / SSL</strong>. El panel muestra el estado actual (HTTP o HTTPS), y en un host sin HTTPS aún lista las fuentes de certificado que el Monitor ha podido detectar.",
|
||||
"heading": "Ubicación del ajuste",
|
||||
"body": "Abre Monitor y ve a <strong>Ajustes → Seguridad → HTTPS / SSL</strong>. El panel muestra HTTP o HTTPS y, si HTTPS no está activo, las fuentes de certificados detectadas.",
|
||||
"imageAlt": "Panel Settings → Security → HTTPS / SSL en el Monitor mostrando el estado HTTPS desactivado, el certificado de Proxmox autodetectado (subject, issuer, expiry) y la opción Use Custom Certificate",
|
||||
"caption": "Panel Settings → Security → HTTPS / SSL antes de la activación. El Monitor saca a la luz el certificado que el propio Proxmox está usando y lo ofrece como una fuente de un solo clic."
|
||||
"caption": "Panel Ajustes → Seguridad → HTTPS / SSL antes de activar HTTPS. Monitor muestra el certificado que usa Proxmox y permite elegirlo con un clic."
|
||||
},
|
||||
"twoways": {
|
||||
"heading": "Dos formas de habilitar HTTPS",
|
||||
"proxmox": {
|
||||
"title": "Usar el certificado de Proxmox",
|
||||
"summary": "Un clic. El Monitor reutiliza el certificado que el propio Proxmox VE sirve en el puerto 8006.",
|
||||
"summary": "Un clic: Monitor reutiliza el certificado que Proxmox VE presenta en el puerto 8006.",
|
||||
"items": [
|
||||
"Autodetectado — no hay ruta que teclear",
|
||||
"Elige el certificado subido por ACME si está presente, recae en el self-signed por defecto",
|
||||
"La renovación pasa por Proxmox; el Monitor sigue automáticamente en el siguiente arranque"
|
||||
"Detectado automáticamente, sin introducir rutas",
|
||||
"Prefiere el certificado ACME si existe; si no, usa el autofirmado predeterminado",
|
||||
"Proxmox renueva; Monitor valida y carga el certificado en la siguiente conexión TLS nueva"
|
||||
]
|
||||
},
|
||||
"custom": {
|
||||
@@ -37,7 +37,7 @@
|
||||
"items": [
|
||||
"Solo rutas absolutas (el proceso del Monitor debe poder leer ambos)",
|
||||
"Útil cuando los certificados vienen de <code>certbot</code>, <code>acme.sh</code> o un wildcard",
|
||||
"La renovación es tuya — reinicia el servicio del Monitor tras que el archivo cambie"
|
||||
"La renovación queda a tu cargo: reinicia Monitor cuando cambien los archivos"
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -54,7 +54,7 @@
|
||||
{
|
||||
"fileRich": "<code>pveproxy-ssl.pem</code><br /><code>pveproxy-ssl.key</code>",
|
||||
"originRich": "Certificado personalizado subido vía la UI de Proxmox — incluyendo el certificado Let's Encrypt emitido en <em>Datacenter → Node → Certificates → ACME</em>.",
|
||||
"when": "Preferido siempre que existan ambos archivos. El Monitor seguirá el certificado que el propio Proxmox está sirviendo."
|
||||
"when": "Se prefiere cuando existen ambos archivos; Monitor usa el certificado presentado por Proxmox."
|
||||
},
|
||||
{
|
||||
"fileRich": "<code>pve-ssl.pem</code><br /><code>pve-ssl.key</code>",
|
||||
@@ -65,17 +65,17 @@
|
||||
},
|
||||
"callout": {
|
||||
"title": "Misma prioridad que el propio Proxmox",
|
||||
"bodyRich": "<code>pveproxy</code> usa la misma regla de selección, así que elegir la opción de Proxmox en el Monitor siempre sirve el certificado que la UI web de Proxmox ya está sirviendo en el puerto 8006. Sin copias, sin pipeline de renovación aparte."
|
||||
"bodyRich": "<code>pveproxy</code> aplica la misma selección: al elegir Proxmox, Monitor usa el certificado que la interfaz de Proxmox presenta en 8006, sin copiarlo ni mantener otro proceso de renovación."
|
||||
}
|
||||
},
|
||||
"letsencrypt": {
|
||||
"heading": "Obtener un certificado Let's Encrypt vía Proxmox ACME",
|
||||
"intro": "Proxmox VE entrega su propio cliente ACME. Pulsar <em>\"Order Certificate Now\"</em> escribe el resultado en <code>/etc/pve/local/pveproxy-ssl.pem</code>, que es exactamente lo que el Monitor lee. La receta de cinco pasos de abajo es el mismo procedimiento que la <extlink1>guía oficial de Proxmox</extlink1> — destilada a los comandos que realmente necesitas ejecutar.",
|
||||
"intro": "Proxmox VE incluye su propio cliente ACME. <em>«Order Certificate Now»</em> guarda el resultado en <code>/etc/pve/local/pveproxy-ssl.pem</code>, que Monitor lee. Los cinco pasos siguientes condensan el procedimiento de la <extlink1>guía oficial de Proxmox</extlink1> en los comandos necesarios.",
|
||||
"prereqs": {
|
||||
"title": "Prerrequisitos",
|
||||
"items": [
|
||||
"El nodo tiene un nombre DNS real (no solo una IP) apuntándole.",
|
||||
"<strong>O bien</strong> puerto 80 alcanzable desde la internet pública (challenge HTTP-01, el más simple), <strong>o bien</strong> un proveedor de DNS con credenciales API (challenge DNS-01 — funciona detrás de NAT, soporta wildcards).",
|
||||
"<strong>O bien</strong> puerto 80 accesible desde Internet (verificación HTTP-01, la más sencilla), <strong>o bien</strong> proveedor DNS con credenciales API (DNS-01, funciona tras NAT y admite comodines).",
|
||||
"Una dirección de email para la cuenta ACME."
|
||||
]
|
||||
},
|
||||
@@ -90,7 +90,7 @@
|
||||
"http01Rich": "<strong>HTTP-01</strong> es el más fácil: está integrado, sin plugin extra. Let's Encrypt se conecta a <code>http://<your-host>/.well-known/acme-challenge/...</code> en el puerto 80, así que el puerto 80 debe estar abierto desde la internet pública a tu nodo — típicamente un port forward en tu router.",
|
||||
"dns01Rich": "<strong>DNS-01</strong> funciona sin exponer el puerto 80 (bueno para homelabs detrás de CG-NAT) y es la única opción para certificados wildcard. Añades un plugin DNS una vez con el token API de tu proveedor. Ejemplo con Cloudflare:",
|
||||
"code": "pvenode acme plugin add dns cf \\\n --api cloudflare \\\n --data CF_Token=YOUR_CLOUDFLARE_API_TOKEN",
|
||||
"outroRich": "Para otros proveedores (Gandi, OVH, AWS Route 53, etc.) consulta <code>pvenode acme plugin add dns --help</code> — Proxmox entrega <extlink2>todos los plugins DNS de acme.sh</extlink2>."
|
||||
"outroRich": "Para otros proveedores (Gandi, OVH, AWS Route 53, etc.), consulta <code>pvenode acme plugin add dns --help</code>. Proxmox incluye <extlink2>todos los plugins DNS de acme.sh</extlink2>."
|
||||
},
|
||||
"step3": {
|
||||
"heading": "Paso 3 — Asocia el dominio a tu nodo",
|
||||
@@ -112,19 +112,19 @@
|
||||
},
|
||||
"gui": {
|
||||
"title": "¿Prefieres la GUI? Los mismos cinco pasos",
|
||||
"bodyRich": "<em>Datacenter → ACME</em> registra la cuenta, <em>Datacenter → ACME → Plugins</em> añade el plugin DNS, <em>Node → Certificates → ACME</em> asocia el dominio y <em>Order Certificates Now</em> ejecuta el paso 4. Los comandos CLI de arriba son útiles para scriptar y para setups headless / solo CLI."
|
||||
"bodyRich": "<em>Datacenter → ACME</em> registra la cuenta; <em>Datacenter → ACME → Plugins</em> añade DNS; <em>Node → Certificates → ACME</em> vincula el dominio; <em>Order Certificates Now</em> ejecuta el paso 4. Los comandos anteriores sirven para automatizar y trabajar sin interfaz gráfica."
|
||||
}
|
||||
},
|
||||
"switchToHttps": {
|
||||
"heading": "Cambiar el Monitor a HTTPS",
|
||||
"bodyRich": "Una vez que <code>/etc/pve/local/pveproxy-ssl.pem</code> está firmado por Let's Encrypt, en el Monitor solo hace falta un clic: abre <strong>Ajustes → Seguridad → HTTPS / SSL</strong>, confirma que el emisor mostrado en el panel del certificado detectado sea <em>Let's Encrypt</em> (y no la CA local de Proxmox) y pulsa <strong>Usar certificado de Proxmox</strong>. El servicio del Monitor se reinicia y la siguiente carga del navegador usa HTTPS en el puerto 8008, sin advertencias porque la cadena es de confianza pública. Las renovaciones posteriores de Proxmox ACME se validan y seleccionan durante la siguiente conexión TLS nueva; no existe un comprobador periódico del certificado ni se reinicia el servicio durante la renovación. <strong>Actualizar certificado</strong> permanece disponible en Seguridad como acción explícita de diagnóstico y recuperación."
|
||||
"bodyRich": "Una vez que <code>/etc/pve/local/pveproxy-ssl.pem</code> está firmado por Let's Encrypt, abre <strong>Ajustes → Seguridad → HTTPS / SSL</strong>, comprueba que el emisor sea <em>Let's Encrypt</em> y no la CA local de Proxmox, y pulsa <strong>Usar certificado de Proxmox</strong>. Monitor se reinicia y la siguiente carga usa HTTPS en 8008 con una cadena de confianza pública. Las renovaciones ACME posteriores se validan y seleccionan en la siguiente conexión TLS nueva, sin sondeo periódico ni reinicio del servicio por renovación. <strong>Actualizar certificado</strong> sigue disponible en Seguridad como acción explícita de diagnóstico y recuperación."
|
||||
},
|
||||
"custom": {
|
||||
"heading": "Certificado personalizado — cuándo usarlo",
|
||||
"intro": "Pulsa <strong>Use Custom Certificate</strong> para introducir dos rutas absolutas:",
|
||||
"intro": "Pulsa <strong>Usar certificado personalizado</strong> e introduce dos rutas absolutas:",
|
||||
"items": [
|
||||
"<strong>Certificado</strong> — cadena completa en PEM (<code>.pem</code> o <code>.crt</code>).",
|
||||
"<strong>Clave privada</strong> — clave correspondiente en PEM (<code>.key</code>)."
|
||||
"<strong>Clave privada</strong>: clave correspondiente en PEM (<code>.key</code>)."
|
||||
],
|
||||
"outro": "Ambos archivos los lee el proceso del Monitor al arrancar. Asegúrate de que se mantengan legibles por el usuario con el que corre la unidad systemd (root por defecto). Ubicaciones comunes cuando ACME se gestiona fuera de 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",
|
||||
@@ -143,15 +143,15 @@
|
||||
},
|
||||
"trustCa": {
|
||||
"heading": "Confiar en la CA self-signed de Proxmox",
|
||||
"intro1Rich": "Si prefieres mantener el certificado por defecto generado por Proxmox (sin ACME), puedes parar el warning del navegador importando la CA raíz del clúster en el almacén de confianza del SO o navegador. El Monitor seguirá autodetectando el mismo <code>/etc/pve/local/pveproxy-ssl.pem</code>; lo único que cambia es que el dispositivo que ve el panel ahora reconoce el issuer.",
|
||||
"intro1Rich": "Para conservar el certificado predeterminado de Proxmox sin ACME, importa la CA raíz del clúster en el almacén de confianza del sistema o navegador. Monitor detecta <code>/etc/pve/local/pve-ssl.pem</code> como certificado alternativo. El cliente confiará en su emisor; la URL aún debe coincidir con un nombre del certificado.",
|
||||
"intro2Rich": "El archivo de la CA vive en <code>/etc/pve/pve-root-ca.pem</code> en cada nodo. En un clúster la ruta está en el sistema de archivos compartido <code>pmxcfs</code>, así que todos los nodos comparten la misma raíz, y una sola importación cubre el datacenter entero. Cópialo a tu máquina:",
|
||||
"code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
|
||||
"thenImport": "Después impórtalo en el lado del cliente:",
|
||||
"items": [
|
||||
"<strong>Linux (todo el sistema):</strong> <code>sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt</code> seguido de <code>sudo update-ca-certificates</code>. Los navegadores que usan el almacén del sistema (Chromium, Edge) lo toman tras reiniciar; Firefox usa su propio almacén y necesita la importación manual de abajo.",
|
||||
"<strong>macOS:</strong> doble clic en el archivo <code>.pem</code>, se abre Keychain Access → añádelo al keychain del <em>Sistema</em> → establece <em>Trust → Always Trust</em>.",
|
||||
"<strong>Windows:</strong> clic derecho en el archivo → <em>Install Certificate</em> → colócalo en <em>Trusted Root Certification Authorities</em>.",
|
||||
"<strong>Firefox (cualquier SO):</strong> <em>Settings → Privacy y Security → Certificates → View Certificates → Authorities → Import</em>, marca <em>Trust this CA to identify websites</em>."
|
||||
"<strong>Linux (todo el sistema):</strong> ejecuta <code>sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt</code> y después <code>sudo update-ca-certificates</code>. Los navegadores que usan el almacén del sistema (Chromium, Edge) lo reconocen tras reiniciar; Firefox usa su propio almacén y requiere la importación manual siguiente.",
|
||||
"<strong>macOS:</strong> abre el archivo <code>.pem</code> con doble clic en Acceso a Llaveros, añádelo al llavero <em>Sistema</em> y configura <em>Confiar → Confiar siempre</em>.",
|
||||
"<strong>Windows:</strong> clic derecho en el archivo → <em>Instalar certificado</em> → guárdalo en <em>Entidades de certificación raíz de confianza</em>.",
|
||||
"<strong>Firefox (cualquier SO):</strong> <em>Ajustes → Privacidad y seguridad → Certificados → Ver certificados → Autoridades → Importar</em>; marca <em>Confiar en esta CA para identificar sitios web</em>."
|
||||
],
|
||||
"standalone": {
|
||||
"title": "Nodos standalone fuera de un clúster",
|
||||
@@ -160,9 +160,9 @@
|
||||
},
|
||||
"disable": {
|
||||
"heading": "Deshabilitar HTTPS",
|
||||
"bodyRich": "Pulsa <strong>Disable HTTPS</strong> en el mismo panel. El servicio del Monitor reinicia de vuelta en HTTP plano — útil si un archivo de certificado personalizado se vuelve no legible y el servicio no vuelve a levantarse. No hay paso de desinstalación aparte; los propios archivos de certificado no se tocan.",
|
||||
"bodyRich": "Pulsa <strong>Deshabilitar HTTPS</strong> en el mismo panel. Monitor reinicia con HTTP sin cifrar, útil si un certificado personalizado no se puede leer y el servicio no arranca. No hay otra desinstalación y los archivos de certificado no se modifican.",
|
||||
"stateCallout": {
|
||||
"title": "Dónde vive el estado",
|
||||
"title": "Dónde se guarda el estado",
|
||||
"bodyRich": "<code>/etc/proxmenux/ssl_config.json</code> almacena las rutas de certificado activas y la fuente (<code>none</code>, <code>proxmox</code>, <code>custom</code>). Borrar el archivo equivale a deshabilitar HTTPS — en el siguiente arranque el Monitor recae en HTTP."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,254 @@
|
||||
{
|
||||
"site": {
|
||||
"name": "ProxMenux",
|
||||
"tagline": "Menu interactif et tableau de bord web pour Proxmox VE"
|
||||
},
|
||||
"nav": {
|
||||
"home": "Accueil",
|
||||
"docs": "Documentation",
|
||||
"documentation": "Documentation",
|
||||
"guides": "Guides",
|
||||
"changelog": "Journal des modifications",
|
||||
"github": "GitHub",
|
||||
"rss": "RSS",
|
||||
"rssTitle": "Flux RSS",
|
||||
"menuOpen": "Ouvrir le menu"
|
||||
},
|
||||
"footer": {
|
||||
"sponsorHeading": "Soutenir le projet",
|
||||
"sponsorBody": "Si vous souhaitez soutenir le projet.",
|
||||
"sponsorAlt": "Soutenez-moi sur Ko-fi",
|
||||
"connectHeading": "Communauté",
|
||||
"connectBody": "Rejoignez les discussions de la communauté sur GitHub pour obtenir de l’aide, partager vos idées et contribuer au projet. Toutes les idées sont les bienvenues !",
|
||||
"joinDiscussion": "Participer à la discussion",
|
||||
"copyrightPrefix": "ProxMenux, un projet collaboratif et open source créé par",
|
||||
"copyrightSuffix": "."
|
||||
},
|
||||
"language": {
|
||||
"switcher": "Langue",
|
||||
"en": "English",
|
||||
"es": "Español",
|
||||
"sk": "Slovenčina",
|
||||
"de": "Deutsch",
|
||||
"fr": "Français",
|
||||
"it": "Italiano",
|
||||
"pt": "Português",
|
||||
"sv": "Svenska"
|
||||
},
|
||||
"resources": {
|
||||
"documentation": {
|
||||
"title": "Documentation",
|
||||
"description": "Présentation du système et guides d’utilisation"
|
||||
},
|
||||
"changelog": {
|
||||
"title": "Journal des modifications",
|
||||
"description": "Informations sur les dernières mises à jour"
|
||||
},
|
||||
"guides": {
|
||||
"title": "Guides",
|
||||
"description": "Tutoriels et guides pas à pas pour les tâches courantes"
|
||||
},
|
||||
"github": {
|
||||
"title": "Dépôt GitHub",
|
||||
"description": "Consultez le code source."
|
||||
}
|
||||
},
|
||||
"docSidebar": {
|
||||
"documentation": "Documentation",
|
||||
"items": {
|
||||
"introduction": "Introduction",
|
||||
"installation": "Installation",
|
||||
"proxmenuxMonitor": "ProxMenux Monitor",
|
||||
"monitorOverview": "Vue d’ensemble",
|
||||
"architecture": "Architecture",
|
||||
"accessAuth": "Accès et authentification",
|
||||
"dashboard": "Tableau de bord",
|
||||
"dashboardSystemOverview": "Onglet Vue d’ensemble du système",
|
||||
"dashboardApps": "Onglet Applications",
|
||||
"dashboardStorage": "Onglet Stockage",
|
||||
"dashboardNetwork": "Onglet Réseau",
|
||||
"dashboardVmsLxcs": "Onglet VM et LXC",
|
||||
"dashboardVmsLxcsApp": "Application",
|
||||
"dashboardVmsLxcsUpdates": "Mises à jour",
|
||||
"dashboardHardware": "Onglet Matériel",
|
||||
"dashboardSystemLogs": "Onglet Journaux système",
|
||||
"dashboardTerminal": "Onglet Terminal",
|
||||
"dashboardSecurity": "Onglet Sécurité",
|
||||
"dashboardSettings": "Onglet Paramètres",
|
||||
"healthMonitor": "Surveillance de l’état du système",
|
||||
"auditReport": "Audit et rapports",
|
||||
"auditReportOverview": "Vue d’ensemble",
|
||||
"auditReportAssessment": "Évaluation et inventaire",
|
||||
"auditReportPolicy": "Politique",
|
||||
"auditReportChanges": "Modifications",
|
||||
"auditReportReports": "Rapports et comparaisons",
|
||||
"auditReportScope": "Périmètre et garanties",
|
||||
"notifications": "Notifications",
|
||||
"aiAssistant": "Assistant IA",
|
||||
"apiReference": "Référence de l’API",
|
||||
"integrations": "Intégrations",
|
||||
"ociManager": "OCI manager Apps",
|
||||
"ociOverview": "Vue d’ensemble",
|
||||
"ociArchitecture": "Comment une image OCI est adaptée",
|
||||
"ociCustomImage": "Image absente du catalogue",
|
||||
"ociStorageNetwork": "Données, chemins et réseau",
|
||||
"ociHardware": "Périphériques et accélération",
|
||||
"ociStacks": "Applications à plusieurs conteneurs",
|
||||
"ociLifecycle": "Installer, mettre à jour et modifier",
|
||||
"ociMonitor": "Dans ProxMenux Monitor",
|
||||
"proxmenuxScripts": "ProxMenux Scripts",
|
||||
"postInstallScript": "Script de post-installation",
|
||||
"postInstallOverview": "Vue d’ensemble",
|
||||
"postInstallAutomated": "Automatique",
|
||||
"postInstallCustomizable": "Personnalisable",
|
||||
"postInstallBasicSettings": "Paramètres de base",
|
||||
"postInstallSystem": "Système",
|
||||
"postInstallVirtualization": "Virtualisation",
|
||||
"postInstallNetwork": "Réseau",
|
||||
"postInstallStorage": "Stockage",
|
||||
"postInstallSecurity": "Sécurité",
|
||||
"postInstallCustomization": "Personnalisation",
|
||||
"postInstallMonitoring": "Surveillance",
|
||||
"postInstallPerformance": "Performances",
|
||||
"postInstallOptional": "Facultatif",
|
||||
"postInstallUpdates": "Appliquer les mises à jour disponibles",
|
||||
"postInstallUninstall": "Supprimer les optimisations",
|
||||
"gpusCoralTpu": "GPU et Coral TPU",
|
||||
"nvidiaHost": "Installer les pilotes NVIDIA sur l’hôte",
|
||||
"coralHost": "Installer Coral TPU sur l’hôte",
|
||||
"addGpuLxc": "Donner accès à un GPU dans un LXC",
|
||||
"addCoralLxc": "Donner accès à Coral TPU dans un LXC",
|
||||
"addGpuVm": "Attribuer un GPU à une VM (passthrough)",
|
||||
"switchGpuMode": "Changer le mode du GPU (VM ↔ LXC)",
|
||||
"createVm": "Créer une VM",
|
||||
"createVmOverview": "Vue d’ensemble",
|
||||
"createVmSystemNas": "Systèmes NAS",
|
||||
"createVmSynology": "VM Synology",
|
||||
"createVmNasOthers": "Autres systèmes NAS",
|
||||
"createVmSystemWindows": "Systèmes Windows",
|
||||
"createVmSystemLinux": "Systèmes Linux",
|
||||
"diskManager": "Gestionnaire de disques",
|
||||
"diskManagerOverview": "Vue d’ensemble",
|
||||
"diskImportVm": "Importer un disque dans une VM",
|
||||
"diskImportImageVm": "Importer une image disque dans une VM",
|
||||
"diskAddController": "Ajouter un contrôleur ou un périphérique NVMe à une VM",
|
||||
"diskImportLxc": "Importer un disque dans un LXC",
|
||||
"diskFormat": "Formater ou effacer un disque physique",
|
||||
"diskSmart": "État SMART et tests du disque",
|
||||
"storageShareManager": "Gestion du stockage et des partages",
|
||||
"storageShareOverview": "Vue d’ensemble",
|
||||
"hostStorage": "Intégration du stockage à l’hôte",
|
||||
"hostNfs": "Ajouter un partage NFS comme stockage Proxmox",
|
||||
"hostSamba": "Ajouter un partage Samba comme stockage Proxmox",
|
||||
"hostIscsi": "Ajouter une cible iSCSI comme stockage Proxmox",
|
||||
"hostLocalDisk": "Ajouter un disque local comme stockage Proxmox",
|
||||
"hostLocalShared": "Créer un répertoire partagé sur l’hôte",
|
||||
"lxcMountPoints": "Points de montage LXC (hôte ↔ CT)",
|
||||
"lxcNetworkSharing": "Partages réseau dans LXC",
|
||||
"lxcNfsClient": "Client NFS dans LXC",
|
||||
"lxcSambaClient": "Client Samba dans LXC",
|
||||
"lxcNfsServer": "Serveur NFS dans LXC",
|
||||
"lxcSambaServer": "Serveur Samba dans LXC",
|
||||
"network": "Réseau",
|
||||
"networkOverview": "Vue d’ensemble",
|
||||
"networkDiagnostics": "Diagnostic",
|
||||
"networkMonitoring": "Outils de surveillance en temps réel",
|
||||
"networkBridge": "Analyse et réparation des ponts réseau",
|
||||
"networkConfig": "Analyse et nettoyage de la configuration",
|
||||
"networkPersistent": "Noms persistants des interfaces",
|
||||
"networkBackup": "Sauvegarde et redémarrage des interfaces",
|
||||
"security": "Sécurité",
|
||||
"securityOverview": "Vue d’ensemble",
|
||||
"securityFail2ban": "Fail2Ban",
|
||||
"securityLynis": "Lynis",
|
||||
"utilities": "Utilitaires",
|
||||
"utilsOverview": "Vue d’ensemble",
|
||||
"utilsUupDump": "Création d’ISO avec UUP Dump",
|
||||
"utilsSystemUtils": "Installation d’utilitaires système",
|
||||
"utilsSystemUpdate": "Mise à jour du système Proxmox",
|
||||
"utilsUpgradePve": "Passer de PVE 8 à PVE 9",
|
||||
"utilsExportVm": "Exporter une VM au format OVA/OVF",
|
||||
"utilsImportVm": "Importer une VM depuis OVA/OVF",
|
||||
"settingsProxmenux": "Paramètres de ProxMenux",
|
||||
"settingsOverview": "Vue d’ensemble",
|
||||
"settingsMonitor": "ProxMenux Monitor",
|
||||
"settingsBeta": "Changer de canal de publication",
|
||||
"settingsVersion": "Afficher les informations de version",
|
||||
"settingsUninstall": "Désinstaller ProxMenux",
|
||||
"commandsReference": "Référence des commandes",
|
||||
"commandsOverview": "Vue d’ensemble",
|
||||
"commandsSystem": "Commandes système utiles",
|
||||
"commandsVmCt": "Gestion des VM et CT",
|
||||
"commandsStorage": "Stockage et disques",
|
||||
"commandsNetwork": "Commandes réseau",
|
||||
"commandsUpdates": "Mises à jour et paquets",
|
||||
"commandsGpu": "Passthrough GPU",
|
||||
"commandsZfs": "Gestion de ZFS",
|
||||
"commandsBackup": "Sauvegarde et restauration",
|
||||
"commandsTools": "Outils système en ligne de commande",
|
||||
"glossary": "Glossaire",
|
||||
"about": "À propos",
|
||||
"aboutOverview": "Vue d’ensemble",
|
||||
"aboutFaq": "FAQ",
|
||||
"aboutContributors": "Contributeurs",
|
||||
"aboutContributing": "Contribuer",
|
||||
"aboutCodeOfConduct": "Code de conduite",
|
||||
"externalRepositories": "Dépôts externes",
|
||||
"backupRestore": "Sauvegarde et restauration",
|
||||
"backupRestoreOverview": "Vue d’ensemble",
|
||||
"backupRestoreHowItWorks": "Fonctionnement",
|
||||
"backupRestoreDestinations": "Destinations",
|
||||
"backupRestoreDestOverview": "Vue d’ensemble",
|
||||
"backupRestoreDestLocal": "Archive locale",
|
||||
"backupRestoreDestPbs": "Proxmox Backup Server",
|
||||
"backupRestoreDestBorg": "Borg",
|
||||
"backupRestoreCreating": "Créer des sauvegardes",
|
||||
"backupRestoreJobs": "Tâches planifiées",
|
||||
"backupRestoreRestoring": "Restaurer",
|
||||
"backupRestoreCrossKernel": "Restauration entre versions du noyau",
|
||||
"backupRestoreGlossary": "Glossaire"
|
||||
}
|
||||
},
|
||||
"hero": {
|
||||
"title": "ProxMenux",
|
||||
"tagline": "Un menu interactif et un tableau de bord web pour Proxmox VE",
|
||||
"description": "ProxMenux réunit un menu interactif et un tableau de bord web pour Proxmox VE. Exécutez des commandes, des scripts et des assistants depuis le terminal, ou consultez l’état de l’hôte, ses métriques et ses notifications dans un navigateur.",
|
||||
"installButton": "Installer maintenant",
|
||||
"whatIsButton": "Qu’est-ce que ProxMenux ?",
|
||||
"logoAlt": "Logo ProxMenux"
|
||||
},
|
||||
"docNav": {
|
||||
"previous": "Précédent",
|
||||
"next": "Suivant"
|
||||
},
|
||||
"tocPanel": {
|
||||
"onThisPage": "Sur cette page"
|
||||
},
|
||||
"supportProject": {
|
||||
"heading": "Soutenez le projet !",
|
||||
"body": "Si <strong>ProxMenux</strong> vous est utile, donnez-lui une ⭐ sur GitHub pour aider d’autres personnes à le découvrir.",
|
||||
"button": "Ajouter une étoile sur GitHub"
|
||||
},
|
||||
"rssLink": {
|
||||
"heading": "Suivez les nouveautés !",
|
||||
"body": "Abonnez-vous à notre flux RSS pour être informé des nouveautés.",
|
||||
"copy": "Copier",
|
||||
"copied": "Copié !",
|
||||
"copyTitle": "Copier l’URL du flux RSS",
|
||||
"openFeed": "Ouvrir le flux RSS",
|
||||
"openTitle": "Ouvrir le flux RSS"
|
||||
},
|
||||
"changelog": {
|
||||
"pageTitle": "Journal des modifications",
|
||||
"meta": {
|
||||
"title": "Journal des modifications de ProxMenux",
|
||||
"titleSuffix": "Notes de version",
|
||||
"latest": "Dernière version",
|
||||
"mostRecent": "Version la plus récente",
|
||||
"description": "Notes de version et historique des mises à jour de ProxMenux, le script à menus pour administrer Proxmox VE.",
|
||||
"descriptionTail": "Nouvelles fonctionnalités, corrections de bugs, mises à jour de sécurité, améliorations de ProxMenux Monitor, compatibilité avec les fournisseurs d’IA, sécurisation du passthrough GPU et bien plus.",
|
||||
"ogDescription": "Notes de version de ProxMenux.",
|
||||
"ogTail": "Abonnez-vous au flux RSS ou revenez consulter les nouvelles versions."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Code de conduite | Documentation ProxMenux",
|
||||
"description": "Code de conduite et bonnes pratiques de ProxMenux pour les contributeurs, les testeurs et les utilisateurs.",
|
||||
"ogTitle": "Code de conduite | Documentation ProxMenux",
|
||||
"ogDescription": "Attentes concernant la responsabilité du code, le signalement des vulnérabilités et le périmètre des PR du projet ProxMenux."
|
||||
},
|
||||
"errors": {
|
||||
"notFound": "Erreur : fichier CODE_OF_CONDUCT.md introuvable.",
|
||||
"loadFailed": "Erreur : Impossible de charger le contenu du Code de conduite."
|
||||
},
|
||||
"contentMarkdown": "# 📝 Code de conduite et bonnes pratiques\n\nCe document définit les **principes et les consignes** d’utilisation de **ProxMenux**, afin de promouvoir le **respect, la collaboration et la sécurité** dans le développement.\n\n## 📌 1. Attribution du code et reconnaissance\n\n- Si des **scripts, extraits de code ou idées** proviennent d’autres dépôts ou développeurs, leur auteur d’origine sera toujours cité.\n- Un commentaire dans le code ou la documentation indiquera la source et, si possible, un lien vers le dépôt original.\n- Lors de l’utilisation de code soumis à une **licence** particulière, ses conditions doivent être respectées.\n\n### ✅ Exemple d’attribution correcte dans le code :\n\n```bash\n# Script fondé sur le travail de [Auteur] dans [Lien du dépôt]\n```\n\n## 🔒 2. Sécurité et responsabilité du code\n\n- Tout le code de ce dépôt suit les bonnes pratiques de développement sécurisé.\n- Les contributions introduisant volontairement des vulnérabilités ou des pratiques dangereuses sont interdites.\n- Les scripts ne doivent jamais compromettre la sécurité du système ni les données des utilisateurs.\n- Avant leur mise en œuvre, les contributions doivent être examinées pour vérifier leur sécurité et leur stabilité.\n\n### ⚠️ Divulgation responsable des vulnérabilités\n\nSi vous découvrez une vulnérabilité de sécurité, ne la signalez PAS dans des issues ou forums publics.\n\nSignalez-la plutôt en privé par e-mail :\n\n📧 proxmenux@macrimi.pro\n\nPour en savoir plus sur les vulnérabilités et leur signalement, consultez notre [politique de sécurité](./SECURITY.md).\n\n## 🤝 3. Règles de la communauté\n\nPour maintenir un cadre respectueux et professionnel, tous les utilisateurs doivent suivre ces règles :\n\n- ✅ Restez respectueux et constructifs dans les discussions.\n- ❌ Le harcèlement, les propos haineux et les comportements offensants ne seront pas tolérés.\n- ✅ Formulez vos retours de manière professionnelle, sans attaques personnelles.\n- ❌ Les manquements peuvent entraîner des avertissements ou des exclusions selon leur gravité.\n\n##\n\nCe document encourage un usage éthique du code, la vigilance en matière de sécurité et une communauté respectueuse.\n\n📢 Construisons ensemble quelque chose de remarquable !\n"
|
||||
}
|
||||
@@ -0,0 +1,293 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Contribution à ProxMenux | ProxMenux Documentation",
|
||||
"description": "Comment contribuer à ProxMenux : modèle de branches (main / develop / feature/*), processus de pull request, en-tête de script avec attribution et lien de soutien facultatif, interface en deux phases, fonctions de message et passage d’une branche de fonctionnalité à une version stable.",
|
||||
"ogTitle": "Contribuer à ProxMenux",
|
||||
"ogDescription": "Modèle de branches, processus, attribution dans l’en-tête et règle d’interface en deux phases à respecter pour contribuer."
|
||||
},
|
||||
"header": {
|
||||
"title": "Contribuer à ProxMenux",
|
||||
"description": "ProxMenux accueille les contributions de la communauté : nouveaux scripts, corrections, amélioration des dialogues, traductions et intégrations. Cette page présente la structure du dépôt, le modèle de branches, le processus de pull request, l’en-tête avec attribution et lien de soutien facultatif, ainsi que les conventions à respecter.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"twoPagesCallout": {
|
||||
"title": "Deux pages connexes, un projet",
|
||||
"body": "Ne confondez pas cette page avec <contributorsLink>Contributeurs</contributorsLink>, qui met à l’honneur les testeurs, relecteurs et développeurs déjà impliqués. Cette page s’adresse à <em>vous</em>, futur contributeur, et explique comment préparer une pull request en vue de son intégration."
|
||||
},
|
||||
"branching": {
|
||||
"heading": "Modèle de branchement",
|
||||
"intro": "ProxMenux utilise un modèle de branchement à trois niveaux :",
|
||||
"headerBranch": "Branche",
|
||||
"headerPurpose": "Objet",
|
||||
"rows": [
|
||||
{
|
||||
"branch": "main",
|
||||
"purposeRich": "Code stable, prêt pour la production. Seules les modifications prêtes à être publiées sont intégrées ici. C’est la version obtenue lors d’une installation normale de ProxMenux."
|
||||
},
|
||||
{
|
||||
"branch": "develop",
|
||||
"purposeRich": "Branche de développement actif : tous les nouveaux changements y sont intégrés en premier. Elle correspond au canal « bêta ». Lorsqu’une version stable est prête, elle est publiée dans <code>main</code> à partir de cette branche."
|
||||
},
|
||||
{
|
||||
"branch": "feature/*",
|
||||
"purposeRich": "Branches temporaires pour une fonctionnalité, une correction ou une amélioration. Créées à partir de <code>develop</code>, puis fusionnées dans <code>develop</code> par pull request après relecture."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Ce que cela signifie pour les utilisateurs",
|
||||
"calloutBody": "Les utilisateurs qui suivent <code>main</code> reçoivent des versions testées. Ceux qui souhaitent les nouveautés plus tôt et acceptent quelques imperfections peuvent suivre <code>develop</code>. Les nouvelles fonctions passent toujours d’abord par <code>develop</code> ; rien n’arrive dans <code>main</code> sans ce cycle."
|
||||
},
|
||||
"workflow": {
|
||||
"heading": "Processus de pull request",
|
||||
"intro": "De l'idée à la version fusionnée en cinq étapes:",
|
||||
"step1Lead": "<strong>Créer une branche de fonction à partir de <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": "Utilisez un nom descriptif de branche : <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
|
||||
"step2Lead": "<strong>Travailler sur vos changements et pousser la branche:</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>Ouvrez une pull request vers <code>develop</code></strong>, pas vers <code>main</code>. Vérifiez sur GitHub que la branche de base est <code>develop</code>. Décrivez le rôle du script, ses modifications et les versions de Proxmox VE utilisées pour les tests.",
|
||||
"step4": "<strong>Après relecture, les modifications sont fusionnées dans <code>develop</code>.</strong> Un responsable vérifie le code, les conventions d’en-tête et la règle d’interface en deux phases. S’il demande des corrections, envoyez de nouveaux commits dans la même branche : la PR se met à jour automatiquement.",
|
||||
"step5": "<strong>Les versions stables passent de <code>develop</code> à <code>main</code>.</strong> Lors d’une publication, <code>main</code> est avancée jusqu’à <code>develop</code> par fast-forward, puis étiquetée. Votre contribution entre dans la prochaine version stable."
|
||||
},
|
||||
"scriptHeader": {
|
||||
"heading": "En-tête de script — métadonnées et description",
|
||||
"intro": "Chaque script de ProxMenux s'ouvre avec deux blocs de commentaires adjacents qui forment ensemble l'en-tête. Ils sont <strong>tous les deux requis</strong> — ensemble, ils font savoir à tout lecteur qui a écrit le script et ce qu'il fait, le tout sans ouvrir le code lui-même.",
|
||||
"bullets": [
|
||||
"<strong>Bloc supérieur : métadonnées.</strong> Auteur, liens GitHub/de soutien facultatifs, responsable, copyright, licence, version et date de mise à jour. C’est aussi la <em>reconnaissance des contributeurs</em> : pour un nouveau script, ajoutez votre nom et, si vous le souhaitez, votre page GitHub et un profil de soutien tel que Ko-fi, GitHub Sponsors ou Buy Me a Coffee.",
|
||||
"<strong>Bloc inférieur : description.</strong> Un court paragraphe en anglais simple explique le rôle du script. Il se lit <em>avant</em> le code et doit se suffire à lui-même : objectif, actions principales, ressources concernées et prérequis."
|
||||
],
|
||||
"licenseCalloutTitle": "La ligne de licence est fixe — GPL-3.0",
|
||||
"licenseCalloutBody": "ProxMenux est publié sous la licence publique générale <strong>GNU v3.0</strong>. Chaque script du projet est livré sous cette même licence; la ligne <code>License</code> dans l'en-tête est toujours la référence GPL-3.0 montrée dans l'exemple ci-dessous — ce n'est pas un choix par script. En contribuant un script, vous acceptez de le publier sous GPL-3.0, ce qui signifie que n'importe qui peut le lire, le modifier et le redistribuer (y compris les modifications) tant qu'ils le conservent sous la même licence. Le texte entier vit à <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": "Les lignes <code>GitHub</code> et <code>Sponsor</code> sont optionnelles — laissez-les dehors si vous ne voulez pas les publier. Tout le reste est nécessaire.",
|
||||
"whyCalloutTitle": "Pourquoi cela est important",
|
||||
"whyCalloutBody": "Contribuer à l’open source est un travail bénévole. Le nom et le lien de soutien éventuel dans le code rendent l’auteur visible à chaque lecture, au lieu de le cacher derrière le projet. La description a un autre rôle : c’est la première chose qu’un futur responsable ou utilisateur curieux lit. Sa clarté détermine souvent si le script inspire confiance ou est évité."
|
||||
},
|
||||
"structure": {
|
||||
"heading": "Structure du projet",
|
||||
"intro": "Où chaque type de script vit dans le dépôt :",
|
||||
"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": "Chaque script charge <code>utils.sh</code> au démarrage avec source pour obtenir les fonctions de message, l’indicateur d’attente, les couleurs et le système de traduction. Les bibliothèques communes dans <code>scripts/global/</code> sont chargées explicitement par les scripts qui les utilisent."
|
||||
},
|
||||
"twoPhase": {
|
||||
"heading": "La règle de conception de l’interface en deux phases",
|
||||
"intro": "C’est la convention la plus importante de ProxMenux et celle qui entraîne le plus souvent des demandes de correction dans les PR. Chaque script est divisé en <strong>exactement deux phases</strong> :",
|
||||
"headerPhase": "Phase",
|
||||
"headerPurpose": "Objet",
|
||||
"headerScreen": "État de l'écran",
|
||||
"rows": [
|
||||
{
|
||||
"phaseRich": "<strong>Phase 1 — Sélection</strong>",
|
||||
"purposeRich": "Recueillir chaque décision de l'utilisateur. Effectuer tout travail préparatoire nécessaire (sondes, scans, vérifications).",
|
||||
"screenRich": "<code>dialog</code> superpositions. Si une sonde entre deux menus prend plus d'une seconde ou deux, montrez un spinner <code>msg_info</code> afin que l'utilisateur sache que le script n'a pas gelé, puis appelez <code>stop_spinner</code> juste avant la boîte de dialogue suivante."
|
||||
},
|
||||
{
|
||||
"phaseRich": "<strong>Phase 2 — Exécution</strong>",
|
||||
"purposeRich": "Exécutez toutes les opérations. Affichez l'historique complet des progrès accumulés à l'écran.",
|
||||
"screenRich": "Messages visibles <code>msg_info</code> / <code>msg_ok</code>; jamais <code>dialog</code>."
|
||||
}
|
||||
],
|
||||
"principle": "Le principe: <strong> collecte tout d'abord, puis exécute tout</strong>. L'utilisateur voit un menu de dialogue propre (phase 1), puis une vue d'exécution propre (phase 2). Pas de mélange — pas de dialogue apparaissant au milieu de l'exécution, pas de bruit de progression pendant la sélection.",
|
||||
"phase1Heading": "Phase 1 — modèle typique",
|
||||
"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": "Règles <strong> pour la phase 1:</strong>",
|
||||
"phase1Rules": [
|
||||
"Si un spinner <code>msg_info</code> est en cours d'exécution et que vous devez ouvrir un menu <code>dialog</code> ou <code>whiptail</code>, appelez d'abord <code>stop_spinner</code> — le spinner ne peut pas coexister avec la superposition dessinée par l'un ou l'autre des outils. Si aucun spinner n'est actif, vous n'avez pas besoin de l'appeler.",
|
||||
"Utilisez <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code> pour donner un contexte visuel à une opération longue en phase 1, par exemple une vérification de plus de cinq secondes. La fonction efface déjà l’écran : n’appelez pas <code>clear</code> avant.",
|
||||
"N'appelez pas <code>show_proxmenux_logo</code> entre les menus de dialogue où il n'y a rien à afficher — le nettoyage de l'écran pour un terminal vide n'est que du bruit visuel.",
|
||||
"Conservez toutes les décisions et les résultats de la sonde dans des variables ou des tableaux parallèles. La récapitulation visible se produit au début de la phase 2, pas dans la phase 1."
|
||||
],
|
||||
"phase2Heading": "Phase 2 — modèle typique",
|
||||
"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>Règles pour la phase 2:</strong> toujours commencer avec <code>show_proxmenux_logo + msg_title</code>; récapituler immédiatement les résultats de la phase 1 sous la forme de lignes <code>msg_ok</code>; n'appelez plus jamais <code>show_proxmenux_logo</code> (il effacerait les progrès accumulés); n'appelez jamais <code>dialog</code> dans la phase 2 — si une décision d'exécution est vraiment inévitable, utilisez <code>whiptail</code> (voir la section suivante)."
|
||||
},
|
||||
"dialogVsWhiptail": {
|
||||
"headingRich": "Quand utiliser <code>dialog</code> vs <code>whiptail</code>",
|
||||
"intro": "Les deux outils dessinent des interfaces utilisateur en mode texte, mais ils se comportent très différemment à l'écran — et ProxMenux les utilise en deux phases distinctes pour une raison.",
|
||||
"headerTool": "Outil",
|
||||
"headerWhen": "Quand l'utiliser",
|
||||
"headerEffect": "Effet sur l'écran",
|
||||
"rows": [
|
||||
{
|
||||
"toolRich": "<strong><code>dialog</code></strong>",
|
||||
"whenRich": "<strong>Toujours dans la phase 1.</strong> Chaque sélection interactive — choisir un VM, un disque, un système de fichiers, confirmer une action — utilise <code>dialog</code>. C'est l'outil d'interface utilisateur par défaut de ProxMenux.",
|
||||
"effectRich": "Prend le contrôle du terminal : efface l’écran, dessine son interface et rétablit l’état précédent à la fermeture. Cela convient à la phase 1, où aucun résultat utile n’est encore affiché."
|
||||
},
|
||||
{
|
||||
"toolRich": "<strong><code>whiptail</code></strong>",
|
||||
"whenRich": "<strong>Seulement en phase 2, en cas de nécessité.</strong> Le cas typique est la proposition de redémarrage en fin d’exécution. N’utilisez pas <code>whiptail</code> pour demander « continuer ? » en cours d’exécution : cette décision devait être prise en phase 1.",
|
||||
"effectRich": "Interface plus légère qui <em>n’efface pas</em> le contexte du terminal. L’historique <code>msg_ok</code>/<code>msg_info</code> de la phase 2 reste visible derrière la boîte de dialogue. Elle convient donc lorsque la progression est déjà affichée."
|
||||
}
|
||||
],
|
||||
"calloutTitle": "Pourquoi la scission est importante",
|
||||
"calloutBody": "Si vous appelez <code>dialog</code> au milieu de la phase 2, chaque ligne <code>msg_ok</code> que l'utilisateur regarde disparaît. Vous effacez la piste de vérification. <code>whiptail</code> évite cela. Donc la règle n'est pas arbitraire — il s'agit de préserver la vision de l'utilisateur de ce que le script a fait jusqu'ici.",
|
||||
"rebootHeading": "Proposition de redémarrage : le cas type de whiptail en phase 2",
|
||||
"rebootIntro": "Si un script peut nécessiter un redémarrage après l’activation d’IOMMU ou la modification du noyau, la question de fin de phase 2 utilise <code>whiptail</code>. Prévoyez toujours une branche « Non » avertissant de ne pas utiliser la ressource concernée avant le redémarrage :",
|
||||
"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": "Référence des fonctions du message",
|
||||
"intro": "Toutes sont définies dans <code>utils.sh</code>. Utilisez-les par défaut pour les sorties visibles afin de garder une présentation cohérente entre scripts. Si une fonction manque, par exemple un niveau de sévérité ou un outil de mise en page, proposez-la dans votre pull request. Elle sera examinée et ajoutée à <code>utils.sh</code> si elle est utile à plusieurs scripts.",
|
||||
"headerFunction": "Fonction",
|
||||
"headerWhen": "Quand utiliser",
|
||||
"headerSpinner": "Indicateur de progression",
|
||||
"rows": [
|
||||
{
|
||||
"function": "msg_info \"text\"",
|
||||
"whenRich": "Opération en cours.",
|
||||
"spinner": "Démarre"
|
||||
},
|
||||
{
|
||||
"function": "stop_spinner",
|
||||
"whenRich": "Fin des travaux préparatoires silencieux dans la phase 1 — tue spinner, efface la ligne.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_ok \"text\"",
|
||||
"whenRich": "Opération réussie. À utiliser aussi pour une fonction activée, même si un redémarrage reste nécessaire.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_warn \"text\"",
|
||||
"whenRich": "Avertissement réel ou état dégradé.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_error \"text\"",
|
||||
"whenRich": "Erreur fatale.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_info2 \"text\"",
|
||||
"whenRich": "Conseil sans blocage, dans une ligne d’information cyan.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_success \"text\"",
|
||||
"whenRich": "Message final « Appuyez sur Entrée pour revenir » en fin de phase 2.",
|
||||
"spinner": "Arrête"
|
||||
},
|
||||
{
|
||||
"function": "msg_title \"text\"",
|
||||
"whenRich": "Titre gras avec espacement intégré. Utilisé au début de la phase 2.",
|
||||
"spinner": "—"
|
||||
},
|
||||
{
|
||||
"function": "show_proxmenux_logo",
|
||||
"whenRich": "Efface l’écran et affiche le logo. À appeler <em>une seule fois</em> au début de la phase 2.",
|
||||
"spinner": "—"
|
||||
}
|
||||
]
|
||||
},
|
||||
"dialogConventions": {
|
||||
"heading": "conventions de dialogue",
|
||||
"bullets": [
|
||||
"Passez toujours <code>--backtitle \"$BACKTITLE\"</code> à chaque appel <code>dialog</code> et <code>whiptail</code>. <code>$BACKTITLE</code> est toujours <code>\"ProxMenux\"</code> — réglé une fois à l'en-tête du script et jamais dépassé. L'utilisateur doit toujours voir le nom du projet comme le contexte de cadrage, jamais le propre titre du script.",
|
||||
"Enveloppez toujours les titres et les messages avec <code>$(translate \"...\")</code>.",
|
||||
"Redirige toujours la sortie <code>dialog</code> avec <code>2>&1 >/dev/tty</code> — le stdout capturé devient la sélection de l'utilisateur, tandis que la boîte de dialogue elle-même s'appuie sur le terminal.",
|
||||
"Utilisez les variables standard de dimension UI (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, etc.) pour un calibrage cohérent entre les scripts.",
|
||||
"Vérifiez toujours les choix vides ou annulés et gérez-les proprement."
|
||||
],
|
||||
"exampleIntro": "Exemple complet — construire un menu de sélection VM et gérer l'annulation:",
|
||||
"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": "Politique de traduction",
|
||||
"intro": "Toutes les chaînes visibles par l'utilisateur doivent être enveloppées avec la fonction <code>translate</code>. ProxMenux les traduit automatiquement dans toutes les langues prises en charge — vous écrivez l'anglais, l'utilisateur lit leur langue maternelle.",
|
||||
"code": "msg_ok \"$(translate \"Operation completed successfully.\")\"\nmsg_error \"$(translate \"Failed to start container\") $CTID.\"\ndialog --title \"$(translate \"Select Storage\")\" ...",
|
||||
"bullets": [
|
||||
"Écrivez les chaînes en anglais : la traduction est gérée automatiquement lors du build.",
|
||||
"Rédigez des chaînes concises. Évitez si possible les variables dans de longues phrases.",
|
||||
"Ne traduisez <strong>pas</strong> les noms de variables, chemins ou identifiants techniques."
|
||||
]
|
||||
},
|
||||
"variableStyle": {
|
||||
"heading": "Conventions de variables et de style",
|
||||
"bullets": [
|
||||
"Utilisez <code>UPPER_CASE</code> pour les variables de niveau script.",
|
||||
"Utiliser <code>lower_case</code> pour les variables de fonction locales (déclarer avec <code>local</code>).",
|
||||
"Entourez les expansions de variables de guillemets : <code>\"$VAR\"</code>, pas <code>$VAR</code>.",
|
||||
"Utiliser <code>[[ ]]</code> pour les conditions, et non <code>[ ]</code> (sauf lorsque POSIX est nécessaire).",
|
||||
"<code>show_proxmenux_logo</code> est le moyen prévu pour effacer l’écran : il le nettoie et affiche le logo du projet pour conserver un contexte visuel. Appelez-le une fois au début de la phase 2, et éventuellement avant une longue attente en phase 1."
|
||||
],
|
||||
"standardNamesIntro": "Noms de variables standard dans l'ensemble du projet :",
|
||||
"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": "Réorienter la sortie de l'outil pendant la phase 2",
|
||||
"redirectIntro": "La phase 2 affiche un journal de lignes <code>msg_info → msg_ok</code>. Si un outil appelé, comme apt, mkfs, qm, pct ou dd, écrit sur stdout/stderr, sa sortie fait défiler les messages et brouille la présentation. L’utilisateur ne distingue plus la progression du script des détails produits par l’outil.",
|
||||
"withoutRedirectIntro": "<strong>Sans redirection</strong> — ce que l'utilisateur voit si vous ne manipulez pas le bruit:",
|
||||
"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>Avec redirection</strong> — à quoi ressemble la même opération lorsque le bruit est envoyé ailleurs:",
|
||||
"withRedirectCode": "ℹ Installing kernel package...\n✓ Kernel installed.\nℹ Configuring kernel command line...\n✓ Configured.\nℹ Refreshing boot loader...\n✓ Boot loader updated.",
|
||||
"twoPatternsIntro": "Deux modèles à choisir :",
|
||||
"discardLead": "<strong>Éliminez la sortie</strong> lorsque vous n'en avez pas besoin — plus rapide et plus simple:",
|
||||
"discardCode": "DEBIAN_FRONTEND=noninteractive apt-get install -y \"$package\" >/dev/null 2>&1",
|
||||
"logLead": "<strong>Envoyez la sortie à un fichier journal</strong> lorsque vous voudrez peut-être l'inspecter plus tard (débogage d'une installation échouée, vérification de ce que dpkg a fait réellement). C'est le modèle préféré pour toute opération apt:",
|
||||
"logCode": "apt-get install -y \"$package\" >> \"$log_file\" 2>&1",
|
||||
"referenceOutro": "Le script <code>scripts/global/update-pve9_2.sh</code> est une implémentation de référence — chaque appel <code>apt-get</code> envoie une sortie vers un fichier journal de sorte que l'utilisateur ne voit que le flux propre <code>msg_info → msg_ok</code>, tandis que le journal sur le disque vous permet de reconstruire exactement ce qu'apt a fait si quelque chose tourne mal."
|
||||
},
|
||||
"dosAndDonts": {
|
||||
"heading": "Faites et ne faites pas",
|
||||
"doHeading": "✅ À faire",
|
||||
"doBullets": [
|
||||
"<code>stop_spinner</code> avant un <code>dialog</code> dans la phase 1 seulement quand un spinner <code>msg_info</code> est en cours d'exécution.",
|
||||
"La phase 2 commence par <code>show_proxmenux_logo + msg_title + msg_ok</code> pour récapituler les résultats de la phase 1.",
|
||||
"Utilisez <code>msg_ok</code> pour des fonctionnalités activées avec succès, même si un redémarrage est nécessaire.",
|
||||
"Utilisez le <code>whiptail</code> (et non le <code>dialog</code>) pour toute invitation après exécution qui doit apparaître dans la phase 2.",
|
||||
"Prévoyez toujours une branche « Non » dans les dialogues de redémarrage pour avertir de ne pas démarrer la ressource concernée avant le redémarrage.",
|
||||
"Protégez la logique VM uniquement en vérifiant <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code> — les contrôleurs et NVMe PCIe ne peuvent pas être ajoutés aux conteneurs LXC.",
|
||||
"Utiliser <code>ensure_repositories</code> de <code>utils-install-functions.sh</code> au lieu de <code>apt-get update</code> inconditionnel.",
|
||||
"Utiliser des tableaux parallèles dans la phase 1 lorsque chaque élément nécessite plusieurs dialogues."
|
||||
],
|
||||
"dontHeading": "❌ À éviter",
|
||||
"dontBullets": [
|
||||
"Appelez <code>dialog</code> alors qu'un spinner est actif.",
|
||||
"Passez la récapitulation de la phase 1 au début de la phase 2.",
|
||||
"Appelez <code>show_proxmenux_logo</code> une deuxième fois — il efface tout ce que la phase 2 a imprimé.",
|
||||
"Utiliser <code>dialog</code> dans la phase 2 (utiliser <code>whiptail</code> pour le cas inévitable rare).",
|
||||
"Utiliser <code>clear</code> seul.",
|
||||
"Enveloppez <code>msg_title</code> dans des lignes vierges <code>echo \"\"</code> — il inclut déjà l'espacement.",
|
||||
"Utilisez <code>msg_warn</code> pour signaler une fonctionnalité activée avec succès — c'est un <code>msg_ok</code>.",
|
||||
"Exécuter sans condition <code>apt-get update</code> — utiliser <code>ensure_repositories</code>."
|
||||
]
|
||||
},
|
||||
"submitting": {
|
||||
"heading": "Soumettre votre contribution",
|
||||
"steps": [
|
||||
"Créez un fork de <code>MacRimi/ProxMenux</code> sur GitHub, puis clonez votre fork.",
|
||||
"Créer une branche <code>feature/*</code> à partir de <code>develop</code> (voir <em>Modèle de branchage</em> ci-dessus).",
|
||||
"Suivez ce guide pour tout script nouveau ou modifié. Écrivez l'en-tête avec votre nom; ajoutez la ligne de sponsor optionnelle si vous voulez.",
|
||||
"Testez le script sur une véritable instance Proxmox VE : phase 1 avec toutes les branches de dialogue, et phase 2 avec chaque opération et son retour arrière propre en cas d’erreur.",
|
||||
"Ouvrez une pull request <strong>vers <code>develop</code></strong> avec une description claire : rôle du script, changements et version Proxmox VE utilisée pour les tests.",
|
||||
"Assurez-vous que votre contribution respecte le <cocLink>Code de conduite</cocLink>."
|
||||
],
|
||||
"securityOutro": "Pour les questions sensibles à la sécurité, suivez le flux de divulgation dans <securityLink>SECURITY.md</securityLink> plutôt que d'ouvrir une question publique."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Où aller ensuite",
|
||||
"items": [
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/blob/main/CONTRIBUTING.md",
|
||||
"label": "CONTRIBUTING.md (guide complet)",
|
||||
"tail": "— la source de vérité pour chaque convention, y compris les modèles matériels avancés."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/contributors",
|
||||
"label": "Contributeurs",
|
||||
"tail": " — les personnes dont le travail a façonné les versions de ProxMenux. Il s’agit d’une autre page."
|
||||
},
|
||||
{
|
||||
"kind": "internal",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"label": "Code de conduite",
|
||||
"tail": "— les normes que chaque contributeur accepte de respecter."
|
||||
},
|
||||
{
|
||||
"kind": "external",
|
||||
"url": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"label": "GitHub Discussions",
|
||||
"tail": "— demander avant de construire si vous n'êtes pas sûr si une idée correspond, ou de trouver des collaborateurs sur une fonctionnalité plus grande."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Contributeurs | Documentation ProxMenux",
|
||||
"description": "Un hommage aux personnes qui rendent ProxMenux possible : testeurs, relecteurs et développeurs qui contribuent à chaque version.",
|
||||
"ogTitle": "Contributeurs | Documentation ProxMenux",
|
||||
"ogDescription": "Rencontrez les contributeurs derrière ProxMenux."
|
||||
},
|
||||
"header": {
|
||||
"title": "Contributeurs",
|
||||
"description": "Le projet ProxMenux grandit grâce à ses contributeurs. Cette page reconnaît leur travail : tester les versions avant leur publication, détecter les régressions, examiner les PR et orienter les nouvelles fonctionnalités.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"beyond": {
|
||||
"title": "Au-delà de cette liste",
|
||||
"body": "De nombreuses autres personnes contribuent en signalant des bugs, en proposant des fonctionnalités dans Discussions, en testant les versions bêta ou en traduisant le projet. La liste complète des contributeurs au code figure dans le <extlink>graphique des contributeurs GitHub</extlink>. La page ci-dessous met en avant les personnes les plus actives dans les tests et la vérification des versions de ProxMenux."
|
||||
},
|
||||
"testers": {
|
||||
"heading": "Testeurs et évaluateurs",
|
||||
"intro": "Ces personnes ont été parmi les premières à contribuer au projet. Leurs tests, signalements de problèmes et suggestions ont aidé ProxMenux à devenir ce qu’il est aujourd’hui.",
|
||||
"roles": {
|
||||
"testing": "Tests",
|
||||
"testingReviewer": "Tests et relecture"
|
||||
},
|
||||
"youtube": "YouTube"
|
||||
},
|
||||
"contribute": {
|
||||
"heading": "Vous voulez contribuer ?",
|
||||
"intro": "Toute contribution est la bienvenue — code, test, conception, documentation, ou tout simplement partager vos idées:",
|
||||
"tester": "<strong>Testeur</strong> — essayez le <beta>canal bêta</beta> et signalez ce qui fonctionne ou non avant la publication des versions stables.",
|
||||
"developer": "<strong>Développeur</strong> — Bash, Next.js (TypeScript) et un peu de Python pour l’environnement virtuel de traduction (venv). Les PR sont les bienvenues sur <gh>GitHub</gh>.",
|
||||
"designer": "<strong>Designer</strong> — Améliorations de l'interface utilisateur, icônes, captures d'écran pour la documentation.",
|
||||
"ideas": "<strong>Idées</strong> — ouvrez un sujet dans <disc>GitHub Discussions</disc> avant de créer une issue pour demander une fonctionnalité."
|
||||
},
|
||||
"coc": {
|
||||
"title": "Lisez d'abord le Code de conduite",
|
||||
"body": "Avant de proposer du code ou de signaler un problème, lisez le <coclink>Code de conduite et les bonnes pratiques</coclink>. Il précise les attentes sur la responsabilité du code, le signalement des vulnérabilités et le périmètre des PR."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Questions fréquentes | Documentation ProxMenux",
|
||||
"description": "Questions fréquentes sur ProxMenux : présentation, installation, compatibilité à partir de PVE 8, personnalisation, mises à jour, sécurité, utilisation en production, fichiers système, contributions et désinstallation.",
|
||||
"ogTitle": "Questions fréquentes | Documentation ProxMenux",
|
||||
"ogDescription": "Questions fréquentes sur l’installation de ProxMenux, sa compatibilité, sa sécurité et les façons de contribuer."
|
||||
},
|
||||
"header": {
|
||||
"title": "Foire aux questions",
|
||||
"description": "Questions courantes sur ProxMenux : présentation, public visé, installation, mise à jour, désinstallation, compatibilité, personnalisation, sécurité et contributions. Si votre question n’est pas ici, consultez GitHub Discussions ou ouvrez une issue.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"quickLinks": {
|
||||
"title": "Liens rapides",
|
||||
"installationLabel": "Installation",
|
||||
"installationSuffix": "— la commande d'installation en une seule ligne + dépendances.",
|
||||
"introductionLabel": "Présentation",
|
||||
"introductionSuffix": " — ce que fait ProxMenux, en cinq minutes.",
|
||||
"uninstallLabel": "Désinstaller",
|
||||
"uninstallSuffix": " — désinstallation propre.",
|
||||
"issuesLabel": "GitHub Issues",
|
||||
"discussionsLabel": "Discussions"
|
||||
},
|
||||
"q1": {
|
||||
"question": "Qu'est-ce que ProxMenux et dans quel cas est-il utilisé?",
|
||||
"p1Rich": "<strong>ProxMenux</strong> est un outil interactif à menus qui rend <strong>Proxmox VE</strong> accessible à tous, quel que soit le niveau technique. Il simplifie l’exécution des commandes et permet d’agir sur le système sans connaissances avancées de Linux.",
|
||||
"p2": "Les utilisateurs moins expérimentés exécutent les commandes depuis des menus structurés, avec moins de saisie manuelle dans le terminal. Les administrateurs expérimentés gagnent du temps sur les tâches répétitives : sécurisation après installation, passthrough GPU, importation de VM OVF et rotation des instantanés ZFS.",
|
||||
"p3": "Proxmox VE est largement utilisé pour:",
|
||||
"items": [
|
||||
"Virtualisation de qualité entreprise",
|
||||
"HomeLab et solutions cloud personnelles",
|
||||
"Serveurs multimédias, automatisation et plus encore"
|
||||
]
|
||||
},
|
||||
"q2": {
|
||||
"question": "Comment installer ProxMenux ?",
|
||||
"p1Rich": "Suivez le <installlink>guide d’installation</installlink>. En résumé :",
|
||||
"stableInstall": "bash -c \"$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)\"",
|
||||
"p2": "Une fois l’installation terminée, lancez simplement :",
|
||||
"menuCmd": "menu"
|
||||
},
|
||||
"q3": {
|
||||
"question": "ProxMenux est-il compatible avec toutes les versions Proxmox ?",
|
||||
"bodyRich": "<strong>Non — ProxMenux nécessite Proxmox VE 8 ou une version ultérieure.</strong> PVE 7 et les versions antérieures ne sont pas pris en charge. Passez d’abord de PVE 7 à 8.x en suivant la procédure officielle Proxmox. ProxMenux peut ensuite gérer le passage de 8 à 9 via <upgradelink>Utilitaires → Mettre à niveau PVE 8 vers PVE 9</upgradelink>."
|
||||
},
|
||||
"q4": {
|
||||
"question": "Puis-je personnaliser ProxMenux ?",
|
||||
"p1Rich": "Les mises à jour peuvent écraser les modifications locales des scripts principaux. Évitez donc de modifier directement ces fichiers. Voici ce que vous <em>pouvez</em> personnaliser :",
|
||||
"items": [
|
||||
"La bannière console via l'outil <strong>FastFetch</strong> dans les options Post-Install.",
|
||||
"Quels composants optionnels sont installés (Monitor, Fail2Ban, Lynis...) — choisissez lors de l'installation ou via le menu correspondant plus tard."
|
||||
]
|
||||
},
|
||||
"q5": {
|
||||
"question": "Comment mettre à jour ProxMenux?",
|
||||
"p1Rich": "Lorsqu’une nouvelle version est disponible, ProxMenux la détecte au prochain lancement de <code>menu</code> et propose la mise à jour. Si vous acceptez, les fichiers et la configuration de l’outil sont remplacés dans l’installation existante ; aucun téléchargement manuel n’est nécessaire.",
|
||||
"p2Rich": "Les utilisateurs de la version stable reçoivent les mises à jour stables, et ceux de la bêta, les mises à jour bêta. Lorsqu’une version stable est publiée, la bêta le signale à la prochaine ouverture du menu et propose de basculer automatiquement. Consultez le <betalink>programme bêta</betalink>."
|
||||
},
|
||||
"q6": {
|
||||
"question": "Où puis-je signaler les problèmes?",
|
||||
"p1Rich": "Signalez les bogues sur <issueslink>GitHub Issues</issueslink>. Indiquez les étapes pour les reproduire, le message d’erreur et, si nécessaire, la sortie de Monitor obtenue avec <code>journalctl -u proxmenux-monitor -n 50</code>.",
|
||||
"p2Rich": "Pour les problèmes de <strong>sécurité</strong>, <strong>ne les divulguez pas publiquement</strong>. Suivez la procédure de signalement responsable du <coclink>code de conduite et des bonnes pratiques</coclink>."
|
||||
},
|
||||
"q7": {
|
||||
"question": "Puis-je contribuer au ProxMenux?",
|
||||
"p1Rich": "<strong>Bien sûr.</strong> ProxMenux est un projet libre et collaboratif. Vous pouvez contribuer au code (Bash, Next.js/TypeScript et outils de traduction en Python), aux tests, à la documentation, au design ou proposer des idées.",
|
||||
"item1Rich": "Discutez des idées dans <discusslink>GitHub Discussions</discusslink> avant d'ouvrir une demande de fonctionnalité.",
|
||||
"item2Rich": "Avant de soumettre une pull request, lisez le <coclink>code de conduite et les bonnes pratiques</coclink>.",
|
||||
"item3Rich": "Consultez la <contriblink>page des contributeurs</contriblink> pour connaître les personnes qui participent actuellement aux tests et aux revues."
|
||||
},
|
||||
"q8": {
|
||||
"question": "Est-ce que ProxMenux modifie les fichiers système critiques?",
|
||||
"p1Rich": "<strong>L’installation de ProxMenux ajoute les composants suivants.</strong>",
|
||||
"item1Rich": "Dépendances via apt : <code>dialog</code>, <code>curl</code>, <code>jq</code> et <code>git</code>. Les traductions utilisent des catalogues JSON préconstruits ; l’installateur n’ajoute aucun environnement virtuel de traduction à l’hôte.",
|
||||
"item2Rich": "L'arborescence des scripts à <code>/usr/local/share/proxmenux/</code>.",
|
||||
"item3Rich": "Le lanceur situé dans <code>/usr/local/bin/menu</code>.",
|
||||
"item4Rich": "En option : le service systemd de Monitor, <code>proxmenux-monitor.service</code>.",
|
||||
"p2Rich": "ProxMenux ne modifie <em>pas</em> la configuration principale de Proxmox, sauf si vous le demandez explicitement depuis un menu dédié. Par exemple, la réparation du réseau modifie <code>/etc/network/interfaces</code>, mais seulement après votre confirmation et la création d’une sauvegarde."
|
||||
},
|
||||
"q9": {
|
||||
"question": "Est-il sûr d'utiliser ProxMenux en production?",
|
||||
"bodyRich": "<strong>Oui.</strong> ProxMenux ne modifie les fichiers principaux de Proxmox que sur demande explicite et peut donc être utilisé en production. Comme pour toute automatisation, testez d’abord dans un environnement contrôlé et prévoyez des sauvegardes avant les opérations destructives : mise à niveau de PVE 8 vers 9, formatage d’un disque, suppression d’une VM, etc."
|
||||
},
|
||||
"q10": {
|
||||
"question": "Comment désinstaller ProxMenux ?",
|
||||
"p1Rich": "Dans ProxMenux : <strong>Paramètres → Désinstaller ProxMenux</strong>. La désinstallation supprime l’arborescence des scripts, le lanceur et le service Monitor, ainsi que les dépendances sélectionnées si vous le souhaitez. Elle restaure <code>/root/.bashrc</code> et <code>/etc/motd</code> depuis les sauvegardes de l’installation, si elles existent.",
|
||||
"p2Rich": "Étape par étape : <uninstalllink>Désinstaller ProxMenux</uninstalllink>."
|
||||
},
|
||||
"q11": {
|
||||
"question": "VirusTotal affiche l'URL d'installation — est-ce sûr?",
|
||||
"p1Rich": "Le résultat de 1/95 attribué à <em>Chong Lua Dao</em> et signalé dans l’issue #162 a été identifié par le mainteneur comme un faux positif. L’installateur utilise le modèle <code>curl | bash</code> et peut télécharger <code>jq</code> depuis sa version officielle sur GitHub. Ce <em>comportement</em> peut déclencher des analyses heuristiques ; ce rapport historique ne préjuge pas de tous les téléchargements futurs.",
|
||||
"p2Rich": "ProxMenux est entièrement open source. Vous pouvez examiner le script d’installation ligne par ligne : <scriptlink>install_proxmenux.sh</scriptlink>. Plus de contexte dans l’<issuelink>issue #162</issuelink>."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,67 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "À propos | Documentation ProxMenux",
|
||||
"description": "À propos de ProxMenux : objectifs du projet, contributeurs, FAQ et code de conduite. Cet outil de gestion open source à menus pour Proxmox VE 8+ est développé et maintenu par MacRimi avec une petite équipe de testeurs et de contributeurs.",
|
||||
"ogTitle": "À propos | Documentation ProxMenux",
|
||||
"ogDescription": "À propos de ProxMenux — un outil de gestion open source à menus pour Proxmox VE 8+."
|
||||
},
|
||||
"header": {
|
||||
"title": "À propos",
|
||||
"description": "Informations sur le projet, FAQ, contributeurs et code de conduite. ProxMenux est un outil de gestion open source à menus pour Proxmox VE 8+, développé et maintenu par MacRimi avec l’aide d’une petite équipe de testeurs et de contributeurs.",
|
||||
"section": "À propos"
|
||||
},
|
||||
"callout": {
|
||||
"title": "Open source, porté par la communauté",
|
||||
"body": "ProxMenux est distribué sous licence GPL-3.0 et développé publiquement sur GitHub. Chaque script peut être examiné et chaque modification retracée. Les contributions sont les bienvenues : signalements de bugs, idées, code et tests."
|
||||
},
|
||||
"section": {
|
||||
"heading": "Dans cette section",
|
||||
"options": [
|
||||
{
|
||||
"icon": "HelpCircle",
|
||||
"href": "/docs/about/faq",
|
||||
"title": "FAQ",
|
||||
"description": "Questions fréquentes : présentation de ProxMenux, installation, compatibilité, personnalisation, mises à jour, sécurité, utilisation en production et désinstallation."
|
||||
},
|
||||
{
|
||||
"icon": "Users",
|
||||
"href": "/docs/about/contributors",
|
||||
"title": "Contributeurs",
|
||||
"description": "Un hommage aux personnes qui rendent ProxMenux possible : testeurs, relecteurs et développeurs qui contribuent à chaque version."
|
||||
},
|
||||
{
|
||||
"icon": "ScrollText",
|
||||
"href": "/docs/about/code-of-conduct",
|
||||
"title": "Code de conduite",
|
||||
"description": "Valeurs du projet, attentes en matière de responsabilité du code et lignes directrices en matière de contribution. Lecture obligatoire avant d'ouvrir un PR ou un rapport."
|
||||
}
|
||||
]
|
||||
},
|
||||
"involved": {
|
||||
"heading": "Participer",
|
||||
"intro": "Trois endroits pour participer au projet :",
|
||||
"cards": [
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/issues/new",
|
||||
"title": "🐛 Signaler un bug",
|
||||
"description": "GitHub Issues — joignez les journaux et les étapes pour reproduire le problème."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/discussions",
|
||||
"title": "💡 Proposer une fonctionnalité",
|
||||
"description": "GitHub Discussions — échangez des idées avant d'ouvrir un PR."
|
||||
},
|
||||
{
|
||||
"href": "https://github.com/MacRimi/ProxMenux/pulls",
|
||||
"title": "🔀 Proposer une PR",
|
||||
"description": "GitHub Pull Requests — lisez d’abord le code de conduite."
|
||||
}
|
||||
]
|
||||
},
|
||||
"support": {
|
||||
"heading": "Soutenir le projet",
|
||||
"introRich": "Si ProxMenux vous fait gagner du temps, le moyen le plus simple de le faire découvrir est de <starlink>donner une ⭐ au dépôt sur GitHub</starlink>. Pour aller plus loin :",
|
||||
"kofiLabel": "Soutien sur Ko-fi",
|
||||
"kofiOutro": "— achète au responsable un café et continue le développement."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Sauvegarde et redémarrage des interfaces | Documentation ProxMenux",
|
||||
"description": "Capture manuelle, navigation et restauration des sauvegardes /etc/network/interfaces stockées sous /var/backups/proxmenux/. Comprend un redémarrage du service réseau avec confirmation et une vue rapide de la configuration en direct.",
|
||||
"ogTitle": "Sauvegarde et redémarrage des interfaces | Documentation ProxMenux",
|
||||
"ogDescription": "Créez un instantané de la configuration réseau Proxmox et restaurez-la ; redémarrez le service réseau avec confirmation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Sauvegarde et redémarrage des interfaces",
|
||||
"description": "Quatre utilitaires qui tournent autour de /etc/network/interfaces: prennent un instantané manuel, visualisent la configuration en direct, restaurent une sauvegarde précédente avec prévisualisation optionnelle et redémarrent le service de réseautage avec un consentement explicite. Même répertoire de sauvegarde utilisé par les flux de réparation guidés.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Gère le même répertoire de sauvegarde utilisé par les flux de réparation guidés (<code>/var/backups/proxmenux/</code>). Permet de prendre un instantané supplémentaire avant tout changement manuel, de parcourir toutes les sauvegardes existantes, et de revenir à l'une d'entre elles — toujours avec une nouvelle sauvegarde pré-restauration prise automatiquement comme deuxième filet de sécurité."
|
||||
},
|
||||
"shared": {
|
||||
"heading": "Le répertoire de sauvegarde partagé",
|
||||
"intro": "Chaque sauvegarde prise n'importe où dans le menu Réseau atterrit au même endroit :",
|
||||
"outro": "Les noms de fichiers sont horodatés, triés par date et jamais écrasés. Le répertoire est créé lors de la première utilisation."
|
||||
},
|
||||
"show": {
|
||||
"heading": "Afficher le fichier de configuration réseau",
|
||||
"body": "Affiche le contenu exact de <code>/etc/network/interfaces</code> dans le terminal. En lecture seule. Utile pour vérifier la configuration avant une sauvegarde ou après une restauration. Il n’existe pas d’outil distinct pour comparer avec la sauvegarde précédente ; examiner le fichier actuel est donc le moyen le plus simple de confirmer son contenu."
|
||||
},
|
||||
"create": {
|
||||
"heading": "Créer une sauvegarde réseau",
|
||||
"body": "Copie le <code>/etc/network/interfaces</code> actuel dans le répertoire de sauvegarde avec un nouvel horodatage. C'est tout — pas d'analyse, pas d'invite, juste un instantané.",
|
||||
"whenTitle": "Quand prendre une sauvegarde manuelle",
|
||||
"whenBody": "Avant de modifier <code>/etc/network/interfaces</code> à la main, d’installer un paquet pouvant toucher la pile réseau (par exemple NetworkManager ou Open vSwitch), ou de changer le matériel. Les réparations guidées créent déjà automatiquement un instantané — cette option sert aux opérations <em>manuelles</em>."
|
||||
},
|
||||
"restore": {
|
||||
"heading": "Restaurer la sauvegarde réseau",
|
||||
"intro": "Liste les sauvegardes de <code>/var/backups/proxmenux/</code>, de la plus récente à la plus ancienne, et guide une restauration avec des garde-fous :",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Choisir une sauvegarde",
|
||||
"body": "Un menu liste chaque sauvegarde par son horodatage. S'il n'y a pas de sauvegardes, le flux sort avec un message clair.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Aperçu facultatif",
|
||||
"body": "Offre d'ouvrir la sauvegarde sélectionnée dans une vue défilante avant de s'engager. Oui par défaut — ne le sautez pas sur un hôte distant.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Sauvegarde avant restauration",
|
||||
"body": "Avant d'écraser <code>/etc/network/interfaces</code>, prend <strong> une autre sauvegarde </strong> de l'état actuel. La restauration d'une sauvegarde est elle-même une action destructrice, de sorte que le nouvel instantané pré-restauration vous permet de revenir si la sauvegarde choisie s'avère être la mauvaise.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer la restauration",
|
||||
"body": "Copie la sauvegarde choisie sur <code>/etc/network/interfaces</code>. Le changement de fichier est sur disque; l'état du noyau en direct reflète toujours la configuration précédente.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Redémarrage facultatif",
|
||||
"body": "Demande s’il faut exécuter <code>systemctl restart networking</code> maintenant. Refusez pour reporter l’application au prochain redémarrage.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"autoBackupTitle": "Une restauration prend sa propre sauvegarde automatiquement",
|
||||
"autoBackupBody": "Sélectionner <em>Restaurer la sauvegarde réseau</em> crée toujours un nouvel instantané de la configuration <em>actuelle</em> avant de l’écraser. Si vous restaurez la mauvaise sauvegarde, le fichier le plus récent dans <code>/var/backups/proxmenux/</code> contient l’état précédent."
|
||||
},
|
||||
"restart": {
|
||||
"heading": "Redémarrer le service réseau",
|
||||
"body": "Exécute <code>systemctl restart networking</code> après confirmation oui/non. Affiche le résultat avec <code>msg_ok</code> / <code>msg_error</code>. La plupart des procédures de ce menu proposent déjà un redémarrage à la fin ; cette option sert après une modification manuelle ou si vous avez refusé le redémarrage proposé auparavant.",
|
||||
"warnTitle": "Brève déconnexion garantie; possibilité de déconnexion permanente",
|
||||
"warnBody": "Redémarrer <code>networking</code> désactive puis reconfigure chaque interface déclarée dans <code>/etc/network/interfaces</code>. Les sessions SSH passant par ces interfaces sont interrompues. Si la nouvelle configuration est invalide, le réseau ne revient pas. N’exécutez cette opération que si :",
|
||||
"warnItems": [
|
||||
"Vous avez la console / IPMI / accès iKVM prêt, <em>ou</em>",
|
||||
"Vous êtes physiquement à côté de la machine, <em> ou</em>",
|
||||
"Vous venez de restaurer avec succès une configuration dont le bon fonctionnement est connu et souhaitez l’appliquer."
|
||||
]
|
||||
},
|
||||
"manualRollback": {
|
||||
"heading": "Retour manuel depuis une console",
|
||||
"intro": "Si vous ne pouvez pas accéder au menu (pas de SSH, plantage de dialog, …) mais disposez d’une console, deux commandes suffisent pour revenir en arrière :",
|
||||
"outro": "C’est la <em>même</em> opération que celle du menu, simplement saisie à la main. Si <code>networking</code> ne démarre toujours pas, consultez <code>journalctl -u networking -b</code> pour identifier l’erreur de syntaxe ou de pilote."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"noneTitle": "« Aucune sauvegarde trouvée » lors de la restauration",
|
||||
"noneBody": "Le répertoire <code>/var/backups/proxmenux/</code> n’existe pas ou ne contient aucun fichier <code>interfaces_backup_*</code>. Exécutez <em>Créer une sauvegarde réseau</em> au moins une fois ou lancez une réparation guidée, qui crée automatiquement une sauvegarde. Vérifiez avec <code>ls /var/backups/proxmenux/</code>.",
|
||||
"unreachTitle": "Le redémarrage du réseau réussit, mais l’hôte reste inaccessible",
|
||||
"unreachBody": "La nouvelle configuration est incorrecte ou n’attribue pas votre adresse IP de gestion. Revenez en arrière depuis la console (voir ci-dessus). Utilisez ensuite <bridgeLink>l’analyse des ponts</bridgeLink> et <configLink>l’analyse de configuration</configLink> pour comprendre le problème avant de réappliquer la configuration.",
|
||||
"emptyTitle": "L’aperçu de restauration affiche un fichier vide",
|
||||
"emptyBody": "Le fichier de sauvegarde est vide (0 octet). Cela arrive si une copie a échoué silencieusement lors d’une exécution précédente. Choisissez une sauvegarde plus ancienne ou relancez <em>Créer une sauvegarde réseau</em> maintenant si la configuration actuelle fonctionne."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— la raison la plus courante pour laquelle une sauvegarde se termine ici."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— écrit également à <code>/var/backups/proxmenux/</code> automatiquement."
|
||||
},
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": " — pour vérifier l’état actuel après une restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Analyse des ponts et réparation guidée | Documentation ProxMenux",
|
||||
"description": "Détecte les ponts vmbrX dont les ports physiques sont absents ou invalides, généralement après une réénumération PCI. Les signale avec des commandes shell proposées et offre une réparation guidée en 5 étapes avec sauvegarde obligatoire.",
|
||||
"ogTitle": "Analyse des ponts et réparation guidée | Documentation ProxMenux",
|
||||
"ogDescription": "Vérifiez et réparez les ports des ponts Proxmox après des changements matériels, avec une procédure guidée permettant un retour en arrière sûr."
|
||||
},
|
||||
"header": {
|
||||
"title": "Analyse des ponts et réparation guidée",
|
||||
"description": "Examine chaque pont vmbrX déclaré dans /etc/network/interfaces, vérifie l’existence de ses ports physiques et propose une réparation étape par étape s’ils sont absents. L’analyse est en lecture seule ; la réparation nécessite un accord, présente un aperçu et crée une sauvegarde.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Lit chaque pont dans <code>/etc/network/interfaces</code>, examine sa ligne <code>bridge-ports</code> et vérifie l’existence de chaque port déclaré, par exemple <code>enp3s0</code>, sur l’hôte. Si un port manque, propose un remplacement et applique la modification avec un consentement explicite selon la procédure <strong>sauvegarder, prévisualiser, appliquer, vérifier</strong>."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Quand vous en avez besoin",
|
||||
"intro": "Linux attribue des noms d'interface prévisibles à partir de la topologie PCI et de l'ordre des fentes. Plusieurs événements les mélangent et laissent <code>/etc/network/interfaces</code> se référant à des noms qui n'existent plus :",
|
||||
"items": [
|
||||
"Ajouter ou retirer une carte PCIe (une carte NIC, un GPU, un HBA, un support NVMe).",
|
||||
"Déplacement d'une carte existante vers une autre fente PCIe.",
|
||||
"Mises à jour du BIOS / UEFI qui réénumèrent les périphériques PCI.",
|
||||
"Migrer le disque de démarrage vers différents matériels."
|
||||
],
|
||||
"outro": "Après le prochain démarrage, le pont tente de se fixer à un port qui n'existe plus, ne parvient pas à monter, et l'hôte perd son réseau. <link>Les noms d'interface persistants</link> empêchent cela de se reproduire — mais si vous êtes déjà verrouillé, cette page est le chemin de récupération."
|
||||
},
|
||||
"bigPicture": {
|
||||
"heading": "La situation générale",
|
||||
"diagram1": {
|
||||
"arrowLabel": "étape 1",
|
||||
"nodes": {
|
||||
"sourceLabel": "/etc/network/interfaces",
|
||||
"sourceDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports enp3s0",
|
||||
"bridgeLabel": "Analyser (lecture seule)",
|
||||
"bridgeDetail": "ip link show enp3s0\n→ n’existe pas",
|
||||
"targetLabel": "Rapport + suggestion",
|
||||
"targetDetail": "❌ enp3s0 : INTROUVABLE\nRemplacer par : eno1\n(pas encore de modification)"
|
||||
}
|
||||
},
|
||||
"diagram2": {
|
||||
"arrowLabel": "appliquer avec sauvegarde",
|
||||
"nodes": {
|
||||
"sourceLabel": "Réparation guidée",
|
||||
"sourceDetail": "1. Sauvegarder\n2. Afficher l’état actuel\n3. Prévisualiser les modifications\n4. Appliquer\n5. Vérifier",
|
||||
"targetLabel": "/etc/network/interfaces (nouveau)",
|
||||
"targetDetail": "auto vmbr0\niface vmbr0 inet static\n bridge-ports eno1"
|
||||
}
|
||||
}
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Étape 1: analyse (lecture seule)",
|
||||
"intro": "Sélectionner <strong>Analyser la configuration des ponts</strong> arrête immédiatement l’outil si l’hôte n’utilise pas la pile classique Debian/Proxmox. Sinon, il examine chaque pont et indique :",
|
||||
"items": [
|
||||
"Nom du pont, état actuel (UP / DOWN), IP assigné.",
|
||||
"Chaque port déclaré et s'il existe actuellement (<code>ip link show <port></code>).",
|
||||
"Pour chaque port invalide : un remplacement proposé (la première interface physique disponible) plus la commande exacte <code>sed</code> pour l'appliquer manuellement.",
|
||||
"Ponts sans <code>bridge-ports</code> du tout et entrées orphelines <code>auto</code> (pas de bloc correspondant <code>iface</code>)."
|
||||
],
|
||||
"readonlyTitle": "Garantie en lecture seule",
|
||||
"readonlyBody": "Jusqu'à ce point, le script n'a pas exécuté une seule commande de modification. Vous pouvez laisser l'analyse ouverte, copier les commandes <code>sed</code> suggérées et les appliquer manuellement si vous préférez — ou accepter l'invite suivante pour entrer dans la réparation guidée."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Étape 2 : réparation guidée (5 étapes)",
|
||||
"intro": "Accessible uniquement si vous acceptez la proposition à la fin de l’analyse. Chaque étape présente l’action prévue et demande une confirmation avant de continuer.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sauvegarde de sécurité",
|
||||
"body": "Copie <code>/etc/network/interfaces</code> vers <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Le chemin exact de sauvegarde est affiché avant la copie et à nouveau après, avec la commande rollback.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Examiner la configuration actuelle",
|
||||
"body": "Ouvre le fichier actuel <code>/etc/network/interfaces</code> dans une boîte de dialogue avec défilement pour voir exactement ce qui va être modifié.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Aperçu des modifications proposées",
|
||||
"body": "Liste précisément les ponts concernés et les remplacements de ports prévus. Si aucune réparation n’est plus nécessaire parce que le port est réapparu entre les vérifications, la procédure se termine avec <em>« Aucune modification nécessaire. »</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer les modifications",
|
||||
"body": "Pour chaque pont touché, exécute <code>sed -i \"/iface $bridge/,/bridge-ports/ s/bridge-ports.*/bridge-ports $new_ports/\"</code> contre <code>/etc/network/interfaces</code>. Si un pont n'avait pas de remplacement valide disponible, la substitution est ignorée et signalée à l'étape 5.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Vérification",
|
||||
"body": "Relit le fichier et confirme l’existence du nouveau port de chaque pont. Affiche la commande de retour en arrière (<code>cp <backup> /etc/network/interfaces</code>). Propose enfin <strong>Redémarrer le réseau</strong> : n’acceptez que si vous disposez d’un accès de secours à la console.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"restartTitle": "Redémarrer le réseau ≠ annuler sans risque",
|
||||
"restartBody": "La réparation est écrite sur le disque, même si vous ne redémarrez pas le service. <code>systemctl restart networking</code> applique la modification <em>maintenant</em>, ce qui peut interrompre votre session SSH si le nouveau port est incorrect. En cas de refus, la modification prendra quand même effet au prochain redémarrage : vérifiez d’abord la configuration ou revenez en arrière avec la commande affichée."
|
||||
},
|
||||
"edits": {
|
||||
"heading": "Ce qui est édité (exactement)",
|
||||
"body": "Uniquement la ligne <code>bridge-ports</code> de chaque pont concerné. Les autres directives (<code>address</code>, <code>netmask</code>, <code>gateway</code>, <code>bridge-stp</code>, …) restent intactes. Le script ne crée ni ne supprime de blocs <code>iface</code> dans cette procédure : c’est le rôle de <link>l’analyse de configuration & du nettoyage</link>."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"unsupportedTitle": "L’analyse s’arrête avec « Pile réseau non prise en charge »",
|
||||
"unsupportedBody": "L'hôte exécute netplan, systemd-networkd ou NetworkManager. L'outil ne prend en charge que <code>/etc/network/interfaces</code>. Passez d'abord l'hôte à la pile classique ou modifiez la configuration avec l'outil natif du gestionnaire (p. ex. <code>netplan apply</code>).",
|
||||
"noSuggestTitle": "Aucune suggestion n'est imprimée pour un port invalide",
|
||||
"noSuggestBody": "L'hôte a zéro interfaces physiques libres (tout est déjà dans un autre pont ou n'existe pas). L'analyse revient à suggérer <code>bridge-ports none</code> afin que le pont puisse au moins monter sans port. Ajouter un NIC ou migrer les ports entre les ponts manuellement avant de recommencer.",
|
||||
"stillDownTitle": "La réparation s'achève mais le pont est toujours DOWN",
|
||||
"stillDownBody": "<code>sed</code> a mis à jour le fichier, mais <code>systemctl restart networking</code> a été refusé. Exécutez-le manuellement une fois que la nouvelle configuration est vérifiée, ou redémarrez. Si le redémarrage a été accepté et que le pont est toujours DOWN, exécutez <code>ip link show</code> pour confirmer l'existence du nouveau port, puis vérifiez <code>journalctl -u networking</code> pour l'erreur réelle (câble débranché, lien non négocié, port déjà membre d'un autre pont).",
|
||||
"lostSshTitle": "J'ai perdu l'accès SSH juste après le redémarrage du réseau",
|
||||
"lostSshIntro": "Utilisez console / IPMI / iKVM pour atteindre l'hôte. Restaurer la sauvegarde :",
|
||||
"lostSshOutro": "Relancez ensuite l’analyse depuis la console pour comprendre pourquoi la suggestion n’a pas fonctionné, généralement parce que le port de remplacement n’est pas branché."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Noms d'interface persistants",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": "— épingler les noms aux adresses MAC afin que ce scénario cesse de se produire."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tailRich": "— pour les blocs orphelins de <code>iface</code> (l'autre moitié du même problème)."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "— les instantanés manuels et le navigateur de restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,122 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Analyse de configuration et nettoyage guidé | Documentation ProxMenux",
|
||||
"description": "Détecte les blocs iface de /etc/network/interfaces qui font référence à des cartes réseau physiques absentes de l’hôte. Les signale et propose une suppression guidée en 5 étapes avec sauvegarde obligatoire et aperçu de chaque bloc.",
|
||||
"ogTitle": "Analyse de configuration et nettoyage guidé | Documentation ProxMenux",
|
||||
"ogDescription": "Trouver et supprimer les blocs d'interface orphelins laissés derrière par les changements matériels, avec prévisualisation complète et retour."
|
||||
},
|
||||
"header": {
|
||||
"title": "Analyse de configuration et nettoyage guidé",
|
||||
"description": "Examine chaque bloc iface de /etc/network/interfaces et vérifie que la carte réseau physique correspondante existe toujours. Signale les blocs orphelins laissés par des changements matériels et propose une suppression guidée avec sauvegarde, aperçu et confirmation de chaque bloc.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Identifie les déclarations <code>iface</code> dont le support NIC n'est plus présent sur l'hôte (typique après le remplacement ou la suppression d'une carte réseau). Ensuite, offre un nettoyage guidé qui supprime <em>seulement</em> les blocs orphelins, avec une sauvegarde, un aperçu par section et une confirmation finale explicite."
|
||||
},
|
||||
"differs": {
|
||||
"heading": "Comment il diffère de l'analyse de pont",
|
||||
"headerAspect": "Aspect",
|
||||
"headerBridge": "Analyse des ponts",
|
||||
"headerConfig": "Analyse de la configuration",
|
||||
"rows": [
|
||||
{
|
||||
"aspect": "Regarde",
|
||||
"bridge": "Ponts (<code>vmbrX</code>) et leur ligne <code>bridge-ports</code>",
|
||||
"config": "Chaque bloc <code>iface</code>, sauf loopback, ponts et agrégations"
|
||||
},
|
||||
{
|
||||
"aspect": "Détecte",
|
||||
"bridge": "Ponts faisant référence à un port inexistant",
|
||||
"config": "Blocs d'interface autonomes pour les NIC qui n'existent pas"
|
||||
},
|
||||
{
|
||||
"aspect": "Action de réparation",
|
||||
"bridge": "Remplace le nom du port dans <code>bridge-ports</code>",
|
||||
"config": "Supprime tout le bloc <code>iface</code>"
|
||||
},
|
||||
{
|
||||
"aspect": "Non compris",
|
||||
"bridge": "Rien — chaque pont est analysé",
|
||||
"config": "Les ponts (<code>vmbrX</code>) et agrégations (<code>bondX</code>) sont toujours conservés : ils sont virtuels et leur absence peut être normale au démarrage"
|
||||
}
|
||||
],
|
||||
"outro": "En pratique, on utilise souvent les deux dans cet ordre : <strong>analyse de configuration</strong> pour supprimer les blocs orphelins, puis <link>analyse des ponts</link> pour réaffecter tout pont qui dépendait de l’interface supprimée."
|
||||
},
|
||||
"step1": {
|
||||
"heading": "Étape 1: analyse (lecture seule)",
|
||||
"intro": "Avorte immédiatement si l'hôte n'est pas sur la pile classique. Sinon, liste toutes les interfaces non loopback configurées et indique son état :",
|
||||
"virtTitle": "Les interfaces virtuelles sont protégées",
|
||||
"virtBody": "Les ponts (<code>vmbrX</code>) et agrégations (<code>bondX</code>) sont virtuels. Leur absence peut être normale au moment de l’inspection, par exemple pour un pont sans port. L’analyse ne propose donc jamais de les supprimer, seulement les cartes réseau physiques."
|
||||
},
|
||||
"step2": {
|
||||
"heading": "Étape 2 : nettoyage guidé (5 étapes)",
|
||||
"intro": "Accessible uniquement si vous acceptez la proposition à la fin de l’analyse. Chaque étape exige une confirmation ; annuler à tout moment quitte sans écrire.",
|
||||
"steps": [
|
||||
{
|
||||
"title": "1. Sauvegarde de sécurité",
|
||||
"body": "Copie <code>/etc/network/interfaces</code> vers <code>/var/backups/proxmenux/interfaces_backup_<TIMESTAMP></code>. Chemin montré avant et après.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "2. Confirmer la liste de suppression",
|
||||
"body": "Liste précisément les blocs d’interface physique à supprimer. Si les cartes réseau réapparaissent entre l’analyse et le nettoyage, par exemple après avoir réinséré une carte, la procédure se termine avec <em>« Aucun nettoyage nécessaire. »</em>",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "3. Aperçu du ou des blocs exacts",
|
||||
"body": "Ouvre une vue défilante de chaque bloc <code>iface</code> qui serait supprimé, mot à mot du fichier. C'est le moment de repérer par exemple un crochet <code>up</code> intéressant que vous voulez préserver.",
|
||||
"tone": "blue"
|
||||
},
|
||||
{
|
||||
"title": "4. Appliquer la suppression",
|
||||
"body": "Pour chaque interface orpheline, exécute <code>sed -i \"/^iface $iface/,/^$/d\" /etc/network/interfaces</code>. Cela supprime de la ligne correspondante <code>iface</code> jusqu'à la ligne blanche suivante.",
|
||||
"tone": "amber"
|
||||
},
|
||||
{
|
||||
"title": "5. Vérification",
|
||||
"body": "Relit le fichier, répertorie ce qui a été supprimé et revérifie les interfaces restantes. Imprime la commande de restauration. <strong>ne redémarre pas</strong> automatiquement le réseau : la suppression d'un bloc inutilisé peut être appliquée en toute sécurité au prochain redémarrage et évite de toucher à l'état actif.",
|
||||
"tone": "emerald"
|
||||
}
|
||||
],
|
||||
"noRestartTitle": "Ne redémarre pas automatiquement le réseau",
|
||||
"noRestartBody": "Contrairement à la réparation de pont, le flux de nettoyage n'offre pas de redémarrer le service. L'élimination d'un bloc d'interface inutilisé n'a aucun effet immédiat sur la configuration en cours d'exécution, de sorte qu'un redémarrage est inutile et serait un risque inutile de connectivité. Le changement prend effet sur le prochain manuel <code>systemctl restart networking</code> ou au prochain redémarrage."
|
||||
},
|
||||
"caveats": {
|
||||
"heading": "Mises en garde importantes",
|
||||
"boundaryTitle": "La limite du bloc est la première ligne vide",
|
||||
"boundaryBody": "Le motif <code>sed</code> supprime de <code>iface <name></code> jusqu’à la ligne vide suivante. Si <code>/etc/network/interfaces</code> ne contient pas de ligne vide entre les blocs, ce qui est rare mais possible après une modification manuelle, le bloc suivant peut aussi être supprimé. C’est pourquoi <strong>l’étape 3 est obligatoire</strong> : examinez l’aperçu avant de confirmer.",
|
||||
"tandemTitle": "Un bloc iface orphelin utilisé par un pont est détecté ici, pas dans l’analyse des ponts",
|
||||
"tandemBody": "Si <code>vmbr0</code> déclare <code>bridge-ports enp3s0</code> et qu’<code>enp3s0</code> a aussi son propre bloc <code>iface enp3s0 inet manual</code>, supprimer <code>enp3s0</code> ici laisse une référence invalide dans <code>vmbr0</code>. Après le nettoyage, lancez <link>l’analyse des ponts</link> pour réaffecter ou retirer le port du pont. Les deux procédures sont conçues pour être utilisées ensemble."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"notFoundTitle": "L’analyse indique « INTROUVABLE » pour ma nouvelle carte réseau",
|
||||
"notFoundBody": "Le noyau voit le périphérique sous un autre nom que celui du fichier. Lancez <code>ip link show</code> pour connaître son nom réel. C’est précisément un cas où les <link>noms d’interface persistants</link> éviteraient le problème à l’avenir.",
|
||||
"tooMuchTitle": "Le nettoyage a trop supprimé, dont un bloc que je voulais garder",
|
||||
"tooMuchBody": "Restaurer à partir de la sauvegarde imprimée dans l'étape 5:",
|
||||
"tooMuchOutro": "Modifier le fichier à la main pour ajouter une ligne blanche claire entre les blocs avant de ré-exécuter le nettoyage, ou supprimer le bloc problématique manuellement.",
|
||||
"bridgeBreakTitle": "Un pont s'arrête après le nettoyage",
|
||||
"bridgeBreakBody": "Le pont utilisait un port dont le bloc <code>iface</code> vient d’être supprimé. Lancez <link>l’analyse des ponts</link> ; la suggestion associera le pont à une interface physique existante."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— le suivi naturel après un nettoyage."
|
||||
},
|
||||
{
|
||||
"label": "Noms d'interface persistants",
|
||||
"href": "/docs/network/persistent-names",
|
||||
"tail": "— empêche les blocs orphelins de s'accumuler après chaque changement matériel."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": "— les instantanés manuels et le navigateur de restauration."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,94 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Diagnostic | Documentation ProxMenux",
|
||||
"description": "Trois diagnostics ponctuels en lecture seule : Afficher la table de routage, Tester la connectivité et Diagnostic avancé. Inspection uniquement — n’écrit jamais dans /etc/network/interfaces et n’exécute aucune commande de modification, à une exception explicite près : la purge de NetworkManager, s’il est détecté, nécessite votre accord.",
|
||||
"ogTitle": "Diagnostic | Documentation ProxMenux",
|
||||
"ogDescription": "Diagnostic réseau en lecture seule pour l'hôte Proxmox : routage, accessibilité, statistiques avancées."
|
||||
},
|
||||
"header": {
|
||||
"title": "Diagnostic",
|
||||
"description": "Trois contrôles ponctuels en lecture seule de l’état actuel du réseau : table de routage, test de connectivité et statistiques avancées. Aucun n’écrit dans /etc/network/interfaces — utilisables en toute sécurité à tout moment, y compris via SSH. Pour la surveillance interactive en direct, consultez Outils de surveillance en direct.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Présente le routage, l’accessibilité et les statistiques agrégées <strong>sans rien modifier</strong>. Permet de vérifier le bon fonctionnement du réseau ou de repérer des adresses IP en double. Pour observer le trafic en continu, voir <monitoringLink>Outils de surveillance en direct</monitoringLink> ; pour consulter le fichier de configuration brut, voir <backupLink>Sauvegarde et redémarrage des interfaces</backupLink>."
|
||||
},
|
||||
"routing": {
|
||||
"heading": "Afficher la table de routage",
|
||||
"body": "Liste chaque route que le noyau utilise actuellement (<code>ip route show</code>) et souligne la passerelle par défaut. Utile pour confirmer que le trafic vers Internet passe par l'interface prévue et qu'aucune route restante n'a priorité."
|
||||
},
|
||||
"connectivity": {
|
||||
"heading": "Tester la connectivité",
|
||||
"intro": "Envoie deux sondes ICMP à trois cibles dans l'ordre et signale chacune. Ensuite, exécute un <code>nslookup google.com</code> pour vérifier la résolution DNS indépendamment de ICMP.",
|
||||
"headerTest": "Essai",
|
||||
"headerTarget": "Cible",
|
||||
"headerConfirms": "Ce qu'il confirme",
|
||||
"rows": [
|
||||
{
|
||||
"test": "Google DNS",
|
||||
"target": "8.8.8.8",
|
||||
"confirms": "Accessibilité externe via une adresse IP anycast connue"
|
||||
},
|
||||
{
|
||||
"test": "Cloudflare DNS",
|
||||
"target": "1.1.1.1",
|
||||
"confirms": "Deuxième avis indépendant si Google bloque ICMP"
|
||||
},
|
||||
{
|
||||
"test": "Passerelle",
|
||||
"target": "(route par défaut)",
|
||||
"confirms": "Connectivité L2 / L3 au routeur local"
|
||||
},
|
||||
{
|
||||
"test": "Résolution DNS",
|
||||
"target": "google.com",
|
||||
"confirms": "Le serveur DNS est accessible et répond"
|
||||
}
|
||||
],
|
||||
"readingTitle": "Lecture du résultat",
|
||||
"readingBody": "Si le test de la passerelle réussit mais que les cibles DNS publiques ne répondent pas, vous avez une connectivité locale mais pas d’accès Internet : vérifiez la connexion en amont de la passerelle. Si la résolution DNS échoue mais que les pings vers <code>8.8.8.8</code> réussissent, le problème vient du résolveur, pas du réseau : vérifiez <code>/etc/resolv.conf</code>."
|
||||
},
|
||||
"advanced": {
|
||||
"heading": "Diagnostic avancé",
|
||||
"intro": "Agrège les statistiques du réseau et effectue une série de vérifications des problèmes courants. Affiche le nombre de connexions actives, les ports en écoute et le nombre total d’interfaces, et signale explicitement deux configurations problématiques :",
|
||||
"items": [
|
||||
"<strong>NetworkManager fonctionne sur un hôte Proxmox.</strong> NetworkManager et <code>ifupdown</code> de Proxmox entrent en conflit : tous deux tentent de gérer les interfaces, ce qui rend les ponts instables ou les empêche de s’activer. Si NetworkManager est détecté, l’outil propose une confirmation interactive pour l’arrêter, le désactiver et le purger (c’est le <em>seul</em> diagnostic pouvant modifier le système, et uniquement après consentement explicite).",
|
||||
"<strong>Adresses IP en double sur différentes interfaces.</strong> Deux interfaces utilisant la même adresse IPv4 provoquent des problèmes de connexion intermittents très difficiles à diagnostiquer depuis la VM. Détection via <code>ip -4 addr show | sort | uniq -d</code>."
|
||||
],
|
||||
"nmTitle": "L'invite NetworkManager est la seule action de modification ici",
|
||||
"nmBody": "Toutes les autres vérifications du diagnostic avancé sont en lecture seule. La suppression de NetworkManager nécessite une confirmation oui/non et exécute <code>systemctl stop / disable</code> + <code>apt-get purge -y network-manager</code>. Si vous refusez, rien ne change."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"gwTitle": "Tester la connectivité signale un échec de la passerelle, mais l’hôte a accès à Internet",
|
||||
"gwBody": "Certains routeurs ne répondent pas aux requêtes ICMP sur leur interface interne même s’ils acheminent correctement le trafic. Testez avec <code>traceroute 8.8.8.8</code> depuis une console : si le deuxième saut correspond à votre FAI et que le test DNS public a réussi, la passerelle fonctionne malgré l’échec du ping.",
|
||||
"dupTitle": "Le diagnostic avancé signale toujours des adresses IP en double après que j’en ai supprimé une",
|
||||
"dupBody": "La vérification examine l'état du noyau en direct, et non le fichier de configuration. Exécutez <code>ip -4 addr show</code> pour confirmer ; si le duplicata est toujours présent, une interface le tient toujours. Utilisez <code>ip addr del <IP>/<mask> dev <iface></code> pour le supprimer de l'état en direct, puis modifiez <code>/etc/network/interfaces</code> si elle est aussi persistante."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Outils de surveillance en direct",
|
||||
"href": "/docs/network/monitoring",
|
||||
"tail": "— les lanceurs interactifs iftop / iptraf-ng / iperf3."
|
||||
},
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": " — lorsqu’un vmbrX n’a plus de port physique."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — lorsqu’une ancienne carte réseau est toujours déclarée mais n’est plus présente."
|
||||
},
|
||||
{
|
||||
"label": "Sauvegarde et redémarrage des interfaces",
|
||||
"href": "/docs/network/backup-restore",
|
||||
"tail": " — pour créer un instantané de la configuration avant toute modification."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,107 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Gestion réseau Proxmox — Ponts, agrégations, diagnostic, réparation | ProxMenux",
|
||||
"description": "Diagnostics en lecture seule, analyses suivies de suggestions et réparations guidées pour la pile réseau Debian / Proxmox (/etc/network/interfaces). Inspectez les ponts et les agrégations, lancez des outils de surveillance en direct, rendez les noms d’interface persistants, sauvegardez et redémarrez le réseau en toute sécurité — avec sauvegardes obligatoires et aperçus étape par étape.",
|
||||
"ogTitle": "Gestion réseau Proxmox — Ponts, agrégations, diagnostic, réparation",
|
||||
"ogDescription": "Diagnostics, analyses et réparations guidées pour la pile réseau Proxmox avec sauvegardes obligatoires et prévisualisations étape par étape.",
|
||||
"twitterTitle": "Gestion réseau Proxmox | ProxMenux",
|
||||
"twitterDescription": "Ponts, agrégations, diagnostics et réparations guidées pour la pile réseau Proxmox avec sauvegardes obligatoires."
|
||||
},
|
||||
"header": {
|
||||
"title": "Gestion du réseau",
|
||||
"description": "Diagnostics en lecture seule, rapports d’analyse suivis de suggestions et réparations guidées pour la pile réseau classique Debian/Proxmox. Toute opération destructive crée d’abord une sauvegarde et affiche les modifications exactes avant de les appliquer.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "À quoi sert ce menu",
|
||||
"body": "Inspectez, diagnostiquez et, au besoin, réparez la configuration réseau de l’hôte Proxmox sans perdre l’accès à distance. Les outils suivent un principe : <strong>lire d’abord, proposer, puis appliquer uniquement avec un consentement explicite et une sauvegarde de sécurité</strong>. Il n’existe pas de bouton « Tout réparer automatiquement »."
|
||||
},
|
||||
"openingMenu": {
|
||||
"heading": "Ouverture du menu",
|
||||
"intro": "Dans le menu principal de ProxMenux, sélectionnez <strong>Réseau</strong>. Vous verrez ceci :",
|
||||
"imageAlt": "Menu de gestion de réseau avec diagnostic, suivi, analyse, réparation, noms persistants et options de sauvegarde"
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Le modèle de sécurité",
|
||||
"body": "Modifier la configuration réseau d’un hôte Proxmox distant est l’un des moyens les plus faciles de perdre son accès. ProxMenux en tient compte pour chaque action. Les outils se répartissent en trois niveaux de comportement : choisissez la carte correspondant à votre objectif :"
|
||||
},
|
||||
"tiers": {
|
||||
"readOnly": {
|
||||
"title": "Lecture seule",
|
||||
"body": "Contrôle pur. Impossible de modifier le système en aucune circonstance.",
|
||||
"items": [
|
||||
"Tableau d'acheminement, tests de connectivité, statistiques avancées",
|
||||
"Surveillance du trafic en temps réel (iftop, iptraf-ng)",
|
||||
"Test de bande passante (iperf3)"
|
||||
]
|
||||
},
|
||||
"analyze": {
|
||||
"title": "Analysez, puis suggérez",
|
||||
"body": "Détecte les problèmes, affiche un rapport avec les commandes shell proposées, puis s’arrête. Vous décidez ensuite de lancer ou non la réparation guidée.",
|
||||
"items": [
|
||||
"Analyse de la configuration des ponts",
|
||||
"Analyse de la configuration du réseau"
|
||||
]
|
||||
},
|
||||
"apply": {
|
||||
"title": "Appliquer avec sauvegarde",
|
||||
"body": "Modifie le système. Crée toujours d’abord une sauvegarde horodatée du fichier concerné et affiche un aperçu avant l’écriture.",
|
||||
"items": [
|
||||
"Noms d’interface persistants (fichiers .link)",
|
||||
"Sauvegarde manuelle, restauration et redémarrage du service"
|
||||
]
|
||||
}
|
||||
},
|
||||
"classicTitle": "Pile classique seulement",
|
||||
"classicBody": "Chaque fonction d'analyse et de réparation vérifie le gestionnaire de réseau actif avant de toucher quoi que ce soit. Si l'hôte exécute <strong>netplan</strong>, <strong>systemd-networkd</strong> ou <strong>NetworkManager</strong>, l'outil avorte immédiatement avec un message clair — le menu ne prend en charge que la pile classique Debian/Proxmox à <code>/etc/network/interfaces</code>. Ceci est intentionnel : l'édition d'un fichier netplan avec des règles écrites pour <code>ifupdown</code> corromprait silencieusement la configuration.",
|
||||
"backups": {
|
||||
"heading": "Où vont les sauvegardes",
|
||||
"intro": "Chaque réparation guidée, restauration ou sauvegarde manuelle écrit une copie horodatée de <code>/etc/network/interfaces</code> à <code>/var/backups/proxmenux/</code> :",
|
||||
"rollbackIntro": "Pour revenir manuellement à la configuration précédente depuis une console :"
|
||||
},
|
||||
"readOnlySection": {
|
||||
"heading": "Contrôle en lecture seule",
|
||||
"body": "Le point de départ lorsque quelque chose semble anormal. Inspection uniquement — n’écrit jamais dans <code>/etc/network/interfaces</code> et n’exécute aucune commande de modification, à une exception explicite près : la purge de NetworkManager, s’il est détecté, nécessite votre accord. Utilisable en toute sécurité via SSH à tout moment.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Diagnostic",
|
||||
"description": "Trois vérifications en lecture seule : Afficher la table d'acheminement, tester la connectivité et les diagnostics avancés. L'inspection pure n'écrit jamais au système."
|
||||
},
|
||||
{
|
||||
"title": "Outils de surveillance en direct",
|
||||
"description": "Trois lanceurs interactifs : iftop (bande passante en temps réel par paire d'hôtes), iptraf-ng (moniteur de trafic multimode) et iperf3 (test de bande passante, serveur / mode client)."
|
||||
}
|
||||
]
|
||||
},
|
||||
"analyzeSection": {
|
||||
"heading": "Analysez, puis suggérez",
|
||||
"body": "À utiliser lorsqu’une inspection ou une panne réelle révèle un problème de configuration. Chaque outil examine la partie concernée de <code>/etc/network/interfaces</code>, affiche un rapport détaillé avec la commande shell exacte qui corrigerait chaque problème, puis <strong>s’arrête</strong>. Si vous acceptez ensuite la réparation guidée facultative, chaque modification est sauvegardée et prévisualisée avant d’être écrite.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Analyse des ponts et réparation guidée",
|
||||
"description": "Détecte les ponts vmbrX dont les ports sont absents ou invalides, par exemple après une réénumération PCI. Affiche d’abord un rapport et ne répare que si vous acceptez la procédure guidée en 5 étapes."
|
||||
},
|
||||
{
|
||||
"title": "Analyse de configuration et nettoyage guidé",
|
||||
"description": "Repère les interfaces physiques déclarées dans /etc/network/interfaces qui n’existent plus, c’est-à-dire les configurations orphelines laissées par des changements matériels. Les signale et propose une suppression guidée."
|
||||
}
|
||||
]
|
||||
},
|
||||
"applySection": {
|
||||
"heading": "Appliquer avec sauvegarde",
|
||||
"body": "Ces outils écrivent sur le disque par leur fonctionnement même. Chacun crée une sauvegarde horodatée du fichier concerné avant l’écriture, et les options destructives, comme la restauration et le redémarrage, exigent une confirmation explicite oui/non. Les <em>noms d’interface persistants</em> prennent effet au prochain redémarrage, pas immédiatement ; leur mise en place peut donc être planifiée en toute sécurité même sur un hôte distant.",
|
||||
"options": [
|
||||
{
|
||||
"title": "Noms d'interface persistants",
|
||||
"description": "Associe les noms d’interface (eno1, enp3s0, …) aux adresses MAC au moyen de fichiers .link de systemd. Les noms restent stables après un changement d’emplacement PCI, une mise à niveau du noyau ou l’ajout ou le retrait d’autres cartes réseau."
|
||||
},
|
||||
{
|
||||
"title": "Sauvegarde et redémarrage des interfaces",
|
||||
"description": "Un instantané manuel de /etc/network/interfaces, parcourir et restaurer les sauvegardes précédentes, afficher la configuration en direct et redémarrer le service de réseautage au besoin."
|
||||
}
|
||||
]
|
||||
},
|
||||
"consoleTitle": "Préparez l'accès à la console",
|
||||
"consoleSubTitle": "Avant toute réparation sur un hôte distant",
|
||||
"consoleBody": "Si vous êtes connecté via SSH et ne disposez que d’un seul accès à l’hôte, prévoyez une solution de secours avant toute modification réseau : console physique / IPMI / iKVM ou autre machine sur le même réseau local. Les réparations guidées sont sûres et proposent toujours une commande de retour en arrière, mais un pont mal configuré ou une liaison interrompue peut tout de même vous priver d’accès jusqu’à ce que vous puissiez atteindre la console."
|
||||
}
|
||||
@@ -0,0 +1,136 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Outils de surveillance en direct | Documentation ProxMenux",
|
||||
"description": "Trois lanceurs interactifs de surveillance du réseau : iftop (bande passante en temps réel par paire d'hôtes), iptraf-ng (moniteur de trafic multimode) et iperf3 (test de bande passante, serveur / mode client). Chacun est installé lors de la première utilisation.",
|
||||
"ogTitle": "Outils de surveillance en direct | Documentation ProxMenux",
|
||||
"ogDescription": "Surveillance réseau interactive et test de bande passante pour l'hôte Proxmox : iftop, iptraf-ng, iperf3."
|
||||
},
|
||||
"header": {
|
||||
"title": "Outils de surveillance en direct",
|
||||
"description": "Trois lanceurs interactifs pour observer le réseau en temps réel et mesurer la bande passante : iftop, iptraf-ng et iperf3. Chaque outil est installé automatiquement via apt au premier usage, fonctionne au premier plan et se quitte avec la touche indiquée. Ils ne modifient pas la configuration réseau de l’hôte ; iperf3 génère du trafic de test.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Trois outils de suivi interactifs, chacun derrière sa propre entrée de menu. La première fois que vous en lancez un, le paquet est installé silencieusement via <code>apt-get</code>. Les lancements suivants commencent instantanément. Aucun de ces outils ne modifie la configuration du réseau hôte."
|
||||
},
|
||||
"when": {
|
||||
"heading": "Quel outil utiliser selon le besoin",
|
||||
"headerQuestion": "Question",
|
||||
"headerUse": "Utiliser",
|
||||
"rows": [
|
||||
{
|
||||
"question": "Qui sature le lien <em> maintenant</em> ?",
|
||||
"use": "iftop"
|
||||
},
|
||||
{
|
||||
"question": "Quelle est la répartition par protocole, quelles tailles de paquets et quels flux TCP circulent ?",
|
||||
"use": "iptraf-ng"
|
||||
},
|
||||
{
|
||||
"question": "Combien de bande passante est disponible entre deux hôtes ?",
|
||||
"use": "iperf3"
|
||||
}
|
||||
]
|
||||
},
|
||||
"iftop": {
|
||||
"heading": "Utilisation du réseau en temps réel (iftop)",
|
||||
"body": "Bande passante en direct par paire d’hôtes (source ↔ destination) — comme <code>top</code> pour le trafic. Affiche les flux les plus importants en haut, avec des moyennes glissantes sur 2/10/40 secondes. L’outil idéal pour savoir <em>« pourquoi ma liaison montante est saturée »</em>.",
|
||||
"exit": "<strong>Quitter :</strong> appuyez sur <kbd>q</kbd>. ProxMenux affiche un rappel avant le lancement.",
|
||||
"keysTitle": "Touches utiles dans iftop",
|
||||
"keysBody": "<kbd>n</kbd> active ou désactive les recherches DNS, <kbd>p</kbd> affiche les numéros de port, <kbd>P</kbd> fige l’affichage, <kbd>t</kbd> change le sens des lignes (envoi / réception / les deux), <kbd>1</kbd>/<kbd>2</kbd>/<kbd>3</kbd> trie par moyenne sur 2 s / 10 s / 40 s. Liste complète dans <code>man iftop</code>."
|
||||
},
|
||||
"iptraf": {
|
||||
"heading": "Outil de surveillance du réseau (iptraf-ng)",
|
||||
"intro": "Un outil de surveillance du trafic à plusieurs modes, piloté par menu. iftop répond à <em>« qui »</em>, tandis qu’iptraf-ng répond à <em>« quoi »</em> : compteurs d’octets et de paquets par protocole, suivi de l’état des connexions TCP, histogrammes de taille des paquets et activité LAN par station.",
|
||||
"menuIntro": "Au lancement, vous obtenez un menu à cinq options :",
|
||||
"headerMode": "Mode",
|
||||
"headerUseFor": "Utilisez-le pour",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "IP traffic monitor",
|
||||
"useFor": "Liste de flux en direct TCP / UDP / ICMP / autre-IP avec compteurs d'octets et état de connexion"
|
||||
},
|
||||
{
|
||||
"mode": "General interface stats",
|
||||
"useFor": "Nombre total de paquets IPv4 / IPv6 / TCP / UDP / ICMP / non IP par carte réseau"
|
||||
},
|
||||
{
|
||||
"mode": "Detailed interface stats",
|
||||
"useFor": "Comme ci-dessus, mais pour une interface, avec la taille du paquet et le détail du taux"
|
||||
},
|
||||
{
|
||||
"mode": "Statistical breakdowns",
|
||||
"useFor": "Histogramme de distribution de la taille du paquet, par port TCP / UDP"
|
||||
},
|
||||
{
|
||||
"mode": "LAN station monitor",
|
||||
"useFor": "Statistiques du trafic par adresse MAC pour le domaine de diffusion local"
|
||||
}
|
||||
],
|
||||
"exit": "<strong>Quitter :</strong> appuyez sur <kbd>x</kbd> depuis n’importe quelle vue ou sur <kbd>Q</kbd> depuis le menu principal. ProxMenux affiche un rappel avant le lancement.",
|
||||
"logTitle": "Enregistrer les captures dans un fichier",
|
||||
"logBody": "Chaque mode propose d’enregistrer les statistiques capturées dans <code>/var/log/iptraf-ng/</code>. Pour conserver une trace d’un pic de trafic, laissez l’outil tourner, enregistrez dans un fichier et examinez-le ensuite plutôt que d’essayer de suivre l’écran en direct."
|
||||
},
|
||||
"iperf3": {
|
||||
"heading": "Test de bande passante (iperf3)",
|
||||
"intro1": "Mesure le débit TCP réel entre deux hôtes. Contrairement à iftop / iptraf-ng, qui observent le trafic existant, iperf3 génère du trafic synthétique pour tester la liaison en charge. Indispensable pour répondre à <em>« Ma liaison 10 GbE atteint-elle vraiment 10 GbE ? »</em> ou <em>« Le goulot d’étranglement vient-il de la carte réseau, du commutateur ou du stockage ? »</em>.",
|
||||
"intro2": "iperf3 est un <strong>outil à deux hôtes</strong> : l’un est le serveur, en écoute sur le port TCP 5201 ; l’autre est le client, qui se connecte, envoie les données et affiche le débit. Le lanceur ProxMenux demande le mode souhaité :",
|
||||
"headerMode": "Mode",
|
||||
"headerBehaviour": "Comportement",
|
||||
"headerCli": "Commande CLI équivalente",
|
||||
"rows": [
|
||||
{
|
||||
"mode": "Serveur",
|
||||
"behaviour": "Écoute sur TCP 5201 et imprime les résultats pour chaque test entrant. Arrête sur Ctrl+C.",
|
||||
"cli": "iperf3 -s"
|
||||
},
|
||||
{
|
||||
"mode": "Client",
|
||||
"behaviour": "Demande l’adresse IP ou le nom d’hôte du serveur, se connecte, lance le test par défaut de 10 secondes et affiche le rapport.",
|
||||
"cli": "iperf3 -c <target>"
|
||||
}
|
||||
],
|
||||
"workflowIntro": "Typiquement pour tester un lien 10 GbE entre deux hôtes Proxmox :",
|
||||
"workflow": [
|
||||
"Sur l’hôte A, ouvrez le menu Réseau → <em>Test de bande passante (iperf3)</em> → choisissez <strong>Serveur</strong>.",
|
||||
"Sur l'hôte B, ouvrez la même entrée de menu → choisissez <strong>Client</strong> → saisissez l'IP de l'hôte A.",
|
||||
"Attendez 10 secondes. Comparez le taux déclaré au maximum théorique du lien."
|
||||
],
|
||||
"sample": "Exemple de sortie client :",
|
||||
"flagsTitle": "Options utiles à utiliser manuellement depuis un shell",
|
||||
"flagsBody": "<code>-t 60</code> test plus long (60 s au lieu de 10 s), <code>-P 4</code> 4 flux parallèles (saturation plus rapide), <code>-R</code> sens inverse (serveur → client), <code>-u -b 100M</code> test UDP à 100 Mbit/s (mesure de la gigue et des pertes de paquets), <code>-p 5202</code> autre port (plusieurs tests en parallèle). Liste complète dans <code>man iperf3</code>.",
|
||||
"firewallTitle": "Ouvrez le port pare-feu sur le serveur",
|
||||
"firewallBody": "Le serveur écoute sur TCP <strong>5201</strong> par défaut. Si vous exécutez le serveur à l'intérieur d'un hôte Proxmox avec un pare-feu strict (datacenter ou niveau hôte), autorisez TCP 5201 entrant à partir de l'IP du client pour la durée du test, puis fermez-le à nouveau. Il en va de même pour <code>nftables</code> / <code>iptables</code> sur les hôtes nus."
|
||||
},
|
||||
"install": {
|
||||
"heading": "Le premier lancement installe le paquet",
|
||||
"body": "Les trois lanceurs vérifient le binaire et exécutent <code>apt-get update -qq && apt-get install -y <pkg></code> s'il manque. L'installation est silencieuse : le menu peut apparaître gelé pour 10–30 secondes la première fois. Les lancements suivants commencent instantanément."
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"hangTitle": "L’installation reste bloquée au premier lancement",
|
||||
"hangBody": "L'hôte n'a pas d'internet ou les repos apt sont inaccessibles. Annuler avec <kbd>Ctrl</kbd>+<kbd>C</kbd>, exécuter <code>apt-get update</code> manuellement pour voir l'erreur réelle (DNS, repo signature, proxy ...), puis revenir au menu.",
|
||||
"refusedTitle": "Client iperf3 : « unable to connect to server: Connection refused »",
|
||||
"refusedBody": "Soit le serveur ne fonctionne pas, soit son pare-feu bloque TCP 5201. Confirmer sur le serveur: <code>ss -tlnp | grep 5201</code> — doit afficher l'écoute iperf3. Si l'écoute, mais que le client échoue, vérifiez le chemin du pare-feu entre les deux hôtes.",
|
||||
"slowTitle": "iperf3 indique un débit bien inférieur à la vitesse attendue de la liaison",
|
||||
"slowBody": "Causes courantes par ordre de probabilité : (1) le processeur d’un hôte limite le débit — essayez <code>iperf3 -c <target> -P 4</code> pour utiliser plusieurs cœurs ; (2) le trajet passe par une liaison plus lente, par exemple un commutateur gigabit entre deux cartes 10 GbE ; (3) MTU différents — vérifiez <code>ip link show</code> aux deux extrémités ; (4) offloading de la carte réseau désactivé — voir le script communautaire <em>Disable NIC Offloading</em> pour une carte Intel e1000e.",
|
||||
"noTrafficTitle": "iftop / iptraf-ng ne montre aucun trafic pour un hôte occupé",
|
||||
"noTrafficBody": "La capture par défaut est sur la première interface détectée. Spécifiez le bon explicitement depuis le shell : <code>iftop -i vmbr0</code> ou <code>iptraf-ng -i vmbr0</code>. Le lanceur de menu utilise la valeur par défaut; pour les interfaces non par défaut, exécuter à partir d'une console."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tail": "— les contrôles en lecture seule (routage, connectivité, statistiques avancées)."
|
||||
},
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tail": "— lorsque la surveillance révèle qu'une interface ou un pont ne fait pas ce qu'il faut."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,130 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Noms d’interface persistants | Documentation ProxMenux",
|
||||
"description": "Associez les noms d’interface Proxmox (eno1, enp3s0, …) aux adresses MAC via des fichiers .link de systemd pour les conserver après une réénumération PCI, une mise à niveau du noyau ou l’ajout ou le retrait d’autres cartes réseau.",
|
||||
"ogTitle": "Noms d’interface persistants | Documentation ProxMenux",
|
||||
"ogDescription": "Empêchez les noms d’interface Proxmox de changer lors des modifications matérielles. Utilise des fichiers .link de systemd associés aux adresses MAC."
|
||||
},
|
||||
"header": {
|
||||
"title": "Noms d'interface persistants",
|
||||
"description": "Génère un fichier .link de systemd par carte réseau physique pour associer le nom attribué par le noyau à son adresse MAC. Après application au prochain redémarrage, les noms d’interface restent stables lorsque vous ajoutez, retirez ou déplacez des cartes PCIe.",
|
||||
"section": "Réseau"
|
||||
},
|
||||
"intro": {
|
||||
"title": "Ce que ça fait",
|
||||
"body": "Pour chaque NIC physique sur l'hôte, écrit un petit fichier sous <code>/etc/systemd/network/10-<iface>.link</code> qui dit : <em>\"le périphérique avec ce MAC doit toujours être appelé ce nom\"</em>. systemd-udevd applique la règle à chaque démarrage, avant que <code>ifupdown</code> ne lise <code>/etc/network/interfaces</code>."
|
||||
},
|
||||
"problem": {
|
||||
"heading": "Le problème que cela résout",
|
||||
"intro": "Linux déduit les noms d’interface par défaut de la topologie PCI — <code>eno1</code> = intégrée à la carte mère, <code>enp3s0</code> = carte sur le bus PCI 3, emplacement 0, etc. Le nommage est déterministe <em>pour une même disposition matérielle</em>. Si cette disposition change, les noms changent :",
|
||||
"items": [
|
||||
"Ajoutez un GPU devant un NIC existant → le numéro de bus NIC peut changer → changement de nom.",
|
||||
"Déplacer une carte vers une autre fente PCIe → nom change.",
|
||||
"BIOS / UEFI mise à jour qui réénumère les appareils → noms peuvent changer.",
|
||||
"Remplacer une carte défectueuse par le même modèle dans une autre fente → nom change."
|
||||
],
|
||||
"outro": "Après un tel changement, <code>/etc/network/interfaces</code> fait toujours référence à l’<em>ancien</em> nom ; le pont ne s’active pas et l’hôte perd le réseau. Les noms persistants évitent que cette situation se reproduise."
|
||||
},
|
||||
"howWorks": {
|
||||
"heading": "Comment ça marche",
|
||||
"arrowLabel": "par NIC",
|
||||
"nodes": {
|
||||
"detectLabel": "Détecter les cartes réseau physiques",
|
||||
"detectDetail": "ls /sys/class/net/\nexclure vmbr / bond /\ndocker / veth / wireguard …",
|
||||
"readLabel": "Lire chaque MAC",
|
||||
"readDetail": "cat /sys/class/net/\n '<'iface'>'/address",
|
||||
"writeLabel": "Écrivez le fichier .link",
|
||||
"writeDetail": "/etc/systemd/network/\n 10-'<'iface'>'.link"
|
||||
},
|
||||
"minimalIntro": "Chaque fichier généré est volontairement minimal :",
|
||||
"minimalOutro": "Au démarrage, systemd-udevd identifie le périphérique par son adresse MAC et lui attribue le nom demandé <em>avant</em> l’intervention d’autres composants (ifupdown, nommage par défaut du noyau). Le préfixe <code>10-</code> garantit le chargement précoce de ces règles, avant le fichier par défaut <code>99-default.link</code>."
|
||||
},
|
||||
"scope": {
|
||||
"heading": "Ce qui est écrit, ce qui est ignoré",
|
||||
"headerType": "Type",
|
||||
"headerBehaviour": "Comportement",
|
||||
"headerWhy": "Pourquoi",
|
||||
"rows": [
|
||||
{
|
||||
"type": "Carte réseau intégrée / PCIe",
|
||||
"behaviour": "fichier <code>.link</code> écrit",
|
||||
"why": "Repose sur un véritable périphérique PCI — le cas auquel l’outil est destiné"
|
||||
},
|
||||
{
|
||||
"type": "Wi-Fi (phy80211)",
|
||||
"behaviour": "fichier <code>.link</code> écrit",
|
||||
"why": "A une vraie MAC et bénéficie de la stabilité des noms"
|
||||
},
|
||||
{
|
||||
"type": "Ponts (vmbrX)",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Virtuel; le nom vient de <code>/etc/network/interfaces</code>"
|
||||
},
|
||||
{
|
||||
"type": "Agrégations (bondX)",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Virtuel ; le nom de l’agrégation est défini par ifupdown"
|
||||
},
|
||||
{
|
||||
"type": "veth / docker0 / br-XXXX",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Créé sur demande par Docker / LXC — matériel non persistant"
|
||||
},
|
||||
{
|
||||
"type": "tap / fwpr / fwln",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Créé sur demande par Proxmox par VM/CT"
|
||||
},
|
||||
{
|
||||
"type": "WireGuard / Cilium / Tailscale",
|
||||
"behaviour": "Ignoré",
|
||||
"why": "Interfaces logicielles gérées par leurs propres démons"
|
||||
}
|
||||
]
|
||||
},
|
||||
"safety": {
|
||||
"heading": "Filet de sécurité : les fichiers .link précédents sont sauvegardés",
|
||||
"intro": "Si <code>/etc/systemd/network/</code> contient déjà des fichiers <code>.link</code> (à partir d'une exécution précédente ou d'un autre outil), ils sont copiés dans un répertoire de sauvegarde horodaté avant que les nouveaux fichiers ne soient générés :",
|
||||
"outro": "Pour revenir en arrière : copiez les fichiers à partir du répertoire de sauvegarde et redémarrez.",
|
||||
"rebootTitle": "Prend effet sur le prochain redémarrage, pas immédiatement",
|
||||
"rebootBody": "Les modifications des fichiers <code>.link</code> ne s’appliquent qu’au démarrage, lorsque udev réénumère les périphériques. L’outil indique donc <em>« Les modifications s’appliqueront après le redémarrage »</em>. Renommer une interface en cours de fonctionnement est risqué et n’est pas tenté : un <code>vmbr0</code> actif avec des interfaces membres devrait être reconfiguré de manière atomique. L’opération est donc reportée au prochain démarrage propre."
|
||||
},
|
||||
"afterReboot": {
|
||||
"heading": "Après le redémarrage",
|
||||
"intro": "Une fois les noms épinglés, le flux de travail des futurs changements matériels est simple :",
|
||||
"items": [
|
||||
"Éteignez, modifiez le matériel (ajout de carte, changement d’emplacement, …), puis démarrez.",
|
||||
"Chaque NIC conserve son nom précédent car son MAC correspond à un fichier <code>.link</code>.",
|
||||
"Si un NIC est remplacé (différent MAC), il obtient un nom de noyau par défaut (<code>enp<bus>s<slot></code>); ré-exécutez ce menu pour ajouter une entrée <code>.link</code> pour le MAC de la nouvelle carte."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Dépannage",
|
||||
"emptyTitle": "\"Aucune interface physique trouvée\" après avoir lancé l'outil",
|
||||
"emptyBody": "Aucune interface reposant sur PCI ou phy80211 n’est visible par le noyau sur l’hôte. Vérifiez avec <code>ls -l /sys/class/net/</code> : chaque entrée doit avoir soit un lien symbolique <code>device</code> (PCI), soit une entrée <code>phy80211</code> (Wi-Fi). Si les deux sont absents pour une véritable carte réseau, le pilote n’est pas chargé.",
|
||||
"noChangeTitle": "Après le redémarrage, les noms n'ont pas changé comme prévu",
|
||||
"noChangeBody": "Vérifiez que le fichier est présent et correctement formé : <code>cat /etc/systemd/network/10-<iface>.link</code>. Consultez ensuite les journaux udev : <code>journalctl -u systemd-udevd -b | grep -i link</code>. Un ancien paramètre du noyau <code>net.ifnames=0</code> désactive entièrement le nommage prévisible : supprimez-le de <code>/etc/default/grub</code>, exécutez <code>update-grub</code>, puis redémarrez.",
|
||||
"undoTitle": "Je veux annuler les noms persistants",
|
||||
"undoBody": "Supprimez les fichiers <code>.link</code> (<code>rm /etc/systemd/network/10-*.link</code>) ou restaurez-les depuis le répertoire de sauvegarde créé lors de l’exécution précédente. Redémarrez pour appliquer les modifications."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Voir aussi",
|
||||
"items": [
|
||||
{
|
||||
"label": "Analyse des ponts et réparation guidée",
|
||||
"href": "/docs/network/bridge-analysis",
|
||||
"tailRich": " — la solution de récupération lorsque les noms ont <em>déjà</em> changé."
|
||||
},
|
||||
{
|
||||
"label": "Analyse de configuration et nettoyage guidé",
|
||||
"href": "/docs/network/config-analysis",
|
||||
"tail": " — pour supprimer les blocs orphelins laissés par les changements de noms."
|
||||
},
|
||||
{
|
||||
"label": "Diagnostic",
|
||||
"href": "/docs/network/diagnostics",
|
||||
"tailRich": "— confirmer les nouveaux noms avec <em>Afficher la table d'acheminement</em> après le redémarrage."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,171 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Comment une image OCI est adaptée | ProxMenux",
|
||||
"description": "Du dépôt de l’image et de son fichier Compose à un modèle vérifiable, un plan de déploiement et un LXC natif de Proxmox VE, sans Docker à l’intérieur."
|
||||
},
|
||||
"header": {
|
||||
"title": "Comment une image OCI est adaptée",
|
||||
"description": "Du dépôt de l’image et de son fichier Compose à un modèle vérifiable, un plan de déploiement et un LXC natif, sans installer Docker à l’intérieur.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "pipeline",
|
||||
"title": "Le processus d’adaptation",
|
||||
"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": "Dépôt de l’image",
|
||||
"converter": "Convertisseur",
|
||||
"template": "Modèle JSON",
|
||||
"blockers": "Aucun point bloquant ?",
|
||||
"no": "Non",
|
||||
"yes": "Oui",
|
||||
"review": "Révision / overlay",
|
||||
"plan": "Plan de déploiement",
|
||||
"lxc": "LXC natif"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le convertisseur lit l’image et le fichier Compose publiés par le projet, puis produit un modèle JSON. Si des exigences n’ont pas pu être adaptées et bloquent l’installation, le modèle est révisé avant sa publication dans le catalogue. Un fichier d’ajustements vérifiés, appelé overlay, permet de résoudre ces points. Seuls les modèles sans point bloquant sont proposés à l’installation."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "template",
|
||||
"title": "Ce que conserve le modèle",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Identité de l’image",
|
||||
"body": "Dépôt, tag mis à jour en continu, architecture, digest résolu et révision de la source."
|
||||
},
|
||||
{
|
||||
"icon": "braces",
|
||||
"title": "Contrat du conteneur",
|
||||
"body": "Entrypoint, Cmd, environnement, utilisateur, répertoire de travail, signal d’arrêt, ports et volumes."
|
||||
},
|
||||
{
|
||||
"icon": "layers",
|
||||
"title": "Adaptation à Proxmox VE",
|
||||
"body": "Ressources, sécurité, points de montage, périphériques, sysctls, contrôles de bon fonctionnement et adaptations nécessaires pour chacun, avec leur justification."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Compatibilité",
|
||||
"body": "Clés prises en charge, exigences non adaptées qui bloquent l’installation et état de chaque validation."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "OCI fournit le processus ; Compose fournit l’environnement",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Source",
|
||||
"Exemple",
|
||||
"Résultat natif"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Métadonnées OCI",
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>",
|
||||
"Proxmox VE les importe à la création du CT"
|
||||
],
|
||||
[
|
||||
"Docker Compose",
|
||||
"<code>environment</code>, <code>volumes</code>, <code>devices</code>",
|
||||
"Entrées d’environnement LXC, <code>mpN</code> et <code>devN</code>"
|
||||
],
|
||||
[
|
||||
"Profil ProxMenux",
|
||||
"GPU, contrôle de bon fonctionnement, identifiants",
|
||||
"Questions et adaptations vérifiées"
|
||||
],
|
||||
[
|
||||
"Utilisateur",
|
||||
"VMID, stockage, réseau",
|
||||
"Le contrat de l’instance"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Ce qui se passe pendant l’installation",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Résoudre la référence",
|
||||
"body": "Le registre est interrogé, l’architecture de l’hôte est sélectionnée et le digest exact désigné par le tag mis à jour en continu est fixé."
|
||||
},
|
||||
{
|
||||
"title": "Télécharger et vérifier",
|
||||
"body": "Skopeo télécharge l’image sous forme d’archive OCI. Avant toute création, chaque couche est vérifiée à l’aide de son digest, puis décompressée. Si le téléchargement est endommagé, il est tenté une seconde fois avant l’arrêt de l’installation."
|
||||
},
|
||||
{
|
||||
"title": "Créer le système de fichiers",
|
||||
"body": "<code>pct create</code> crée le rootfs à partir de l’archive et conserve les métadonnées officielles du processus de l’image."
|
||||
},
|
||||
{
|
||||
"title": "Raccorder les ressources",
|
||||
"body": "Les volumes, le réseau, l’environnement, les périphériques et les profils de sécurité déclarés sont appliqués."
|
||||
},
|
||||
{
|
||||
"title": "Console",
|
||||
"body": "La sortie console du conteneur est conservée sur l’hôte. La console de Proxmox VE ouvre un shell si l’image en contient un."
|
||||
},
|
||||
{
|
||||
"title": "Vérifier",
|
||||
"body": "Au premier démarrage, l’installation attend l’attribution d’une adresse et la réponse du service. En cas d’échec, elle n’est pas signalée comme réussie."
|
||||
},
|
||||
{
|
||||
"title": "Enregistrer la configuration",
|
||||
"body": "La configuration effective est enregistrée dans le contrat de l’instance utilisé lors des mises à jour et des recréations."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "example",
|
||||
"title": "Exemple : une image avec /config et /downloads",
|
||||
"intro": "Une définition Compose courante et la configuration Proxmox VE qui en résulte. Les chemins attendus par l’application ne changent pas.",
|
||||
"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 (extrait)",
|
||||
"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> est un second disque appartenant au conteneur, nommé <code>vm-VMID-disk-N</code> sur le stockage sélectionné. Il est monté dans <code>/config</code> et, avec <code>backup=1</code>, inclus dans la sauvegarde du conteneur. <code>mp1</code> ne crée aucun disque : il monte le répertoire de l’hôte <code>/srv/downloads</code> dans <code>/downloads</code> à l’intérieur du LXC. Le port 8080 n’est pas redirigé : le LXC possède sa propre adresse et le service y répond."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,278 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Installer une image absente du catalogue | ProxMenux",
|
||||
"description": "Adaptez une image OCI à partir d’un fichier Compose, d’une URL, d’une commande docker run ou d’une référence d’image, puis vérifiez ce que ProxMenux peut reproduire avant l’installation."
|
||||
},
|
||||
"header": {
|
||||
"title": "Installer une image absente du catalogue",
|
||||
"description": "Votre image est adaptée à partir de son fichier Compose, d’une commande docker run ou de sa seule référence. Le résultat est présenté pour vérification avant la création du moindre LXC.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "intro",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Le même convertisseur et le même installateur",
|
||||
"body": "L’option <strong>Installer une image absente du catalogue</strong> utilise le même convertisseur et le même installateur que les modèles du catalogue. Le contrat est simplement généré à ce moment-là à partir de la définition fournie, puis validé avant toute création de LXC."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "sources",
|
||||
"title": "Comment décrire l’image",
|
||||
"intro": "Le premier écran demande comment l’image est décrite. Quatre possibilités fournissent une définition à adapter, une cinquième utilise uniquement le nom de l’image et trois autres lisent un oci-compose déjà rédigé.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Contenu lu"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Coller son fichier Compose dans le terminal",
|
||||
"Collez le contenu YAML dans le terminal et terminez avec Ctrl+D."
|
||||
],
|
||||
[
|
||||
"Lire son fichier Compose depuis cet hôte",
|
||||
"Un chemin sur le nœud, <code>/root/docker-compose.yml</code> par défaut. Le fichier doit exister et ne pas dépasser 256 KiB."
|
||||
],
|
||||
[
|
||||
"Télécharger son fichier Compose depuis une adresse",
|
||||
"Une adresse <code>http://</code> ou <code>https://</code> qui fournit le YAML brut. Le téléchargement est limité à 256 KiB."
|
||||
],
|
||||
[
|
||||
"Coller sa commande docker run dans le terminal",
|
||||
"La commande publiée par le projet. Les ports, l’environnement, les volumes, les périphériques, les capabilities, l’utilisateur, la mémoire partagée et les autres options prises en charge sont adaptés."
|
||||
],
|
||||
[
|
||||
"Uniquement la référence de l’image, sans fichier Compose",
|
||||
"Une référence comme <code>ghcr.io/user/application:latest</code>. Le registre est interrogé et les métadonnées OCI de l’image sont conservées."
|
||||
],
|
||||
[
|
||||
"Coller un oci-compose dans le terminal",
|
||||
"Collez le JSON dans le terminal et terminez avec Ctrl+D. Il n’est pas converti : il est vérifié puis installé tel qu’il est rédigé."
|
||||
],
|
||||
[
|
||||
"Lire un oci-compose depuis cet hôte",
|
||||
"Un fichier JSON sur le nœud, <code>/root/oci-compose.json</code> par défaut, de 2 MiB au maximum."
|
||||
],
|
||||
[
|
||||
"Télécharger un oci-compose depuis une adresse",
|
||||
"Une adresse <code>http://</code> ou <code>https://</code> qui fournit le fichier JSON. Le téléchargement est limité à 2 MiB."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-source-menu.png",
|
||||
"alt": "Menu de choix de la description d’une image absente du catalogue",
|
||||
"caption": "Les façons de décrire une image absente du catalogue."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "reference-only",
|
||||
"title": "Ce que fournit la seule référence de l’image",
|
||||
"intro": "L’image contient les métadonnées de son processus, mais pas tout l’environnement habituellement ajouté par un fichier Compose.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Lu depuis l’image",
|
||||
"Absent de l’image",
|
||||
"Conséquence"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>Entrypoint</code>, <code>Cmd</code>, <code>User</code>, <code>WorkingDir</code> et l’environnement intégré",
|
||||
"Variables présentes uniquement dans la documentation",
|
||||
"Ajoutées pendant l’installation ou avec Modifier"
|
||||
],
|
||||
[
|
||||
"Volumes déclarés par l’image",
|
||||
"Répertoires de l’hôte indiqués uniquement dans le fichier Compose",
|
||||
"Les chemins supplémentaires sont ajoutés avant l’installation"
|
||||
],
|
||||
[
|
||||
"Ports <code>EXPOSE</code>",
|
||||
"L’URL, le protocole ou le contrôle de bon fonctionnement",
|
||||
"Le port et la méthode de vérification du service sont confirmés"
|
||||
],
|
||||
[
|
||||
"Architectures et digest dans le registre",
|
||||
"Périphériques, privilèges ou dépendances externes",
|
||||
"Ils ne sont pas activés sans une définition qui les demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "review",
|
||||
"title": "Vérifier avant l’installation",
|
||||
"intro": "Après adaptation de la définition, ProxMenux présente ce qu’il en a compris avant de demander le VMID, les ressources ou le stockage.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Analyser",
|
||||
"body": "Les services, l’image, les ports, les chemins, l’environnement, les périphériques, la sécurité et le contrôle de bon fonctionnement sont lus."
|
||||
},
|
||||
{
|
||||
"title": "Interroger le registre",
|
||||
"body": "L’image doit exister dans le registre et les architectures publiées sont affichées. Un registre privé est consulté avec le compte enregistré pour celui-ci."
|
||||
},
|
||||
{
|
||||
"title": "Lister les options non appliquées",
|
||||
"body": "Les labels, réseaux Docker, paramètres Swarm et autres clés sans effet sur un LXC sont répertoriés."
|
||||
},
|
||||
{
|
||||
"title": "Bloquer les options sans équivalent sûr",
|
||||
"body": "Les clés sans équivalent sûr apparaissent sous <strong>Options sans équivalent</strong> et empêchent la poursuite de l’installation. Aucune n’est ignorée silencieusement."
|
||||
},
|
||||
{
|
||||
"title": "Demander les secrets",
|
||||
"body": "Les variables dont le nom évoque un mot de passe, un jeton ou une clé sont demandées comme données sensibles pendant l’installation."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/custom-review.png",
|
||||
"alt": "Récapitulatif de l’interprétation du fichier Compose par ProxMenux",
|
||||
"caption": "Récapitulatif affiché avant la demande du VMID et des ressources."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Après validation du récapitulatif, le parcours est celui du catalogue : nom, mode par défaut ou avancé, VMID, CPU, mémoire, réseau, démarrage avec le nœud, chemins persistants et supplémentaires, périphériques compatibles et récapitulatif final."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "examples",
|
||||
"title": "Exemples de saisie",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Compose",
|
||||
"code": "services:\n app:\n image: ghcr.io/example/app:latest\n ports:\n - \"8080:8080\"\n volumes:\n - ./config:/config\n - /srv/media:/media\n environment:\n TZ: Europe/Madrid"
|
||||
},
|
||||
{
|
||||
"title": "docker run",
|
||||
"code": "docker run -d \\\n --name app \\\n -p 8080:8080 \\\n -e TZ=Europe/Madrid \\\n -v app-config:/config \\\n -v /srv/media:/media \\\n ghcr.io/example/app:latest"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "oci-compose",
|
||||
"title": "Un oci-compose rédigé à la main",
|
||||
"intro": "Un oci-compose est le fichier JSON à partir duquel une application est installée. Le catalogue en conserve un par application. Le même format peut être rédigé à la main et installé avec cette option.",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Dans un fichier rédigé à la main, l’auteur définit l’image, les ports, les variables, les volumes et les questions de l’installation. ProxMenux complète le reste à la lecture. Le format permet d’exprimer ce que Compose ne prévoit pas : texte d’une question, mot de passe généré à l’installation, profil GPU, propriétaire de chaque volume, contrôle du premier démarrage ou identifiants affichés à la fin."
|
||||
},
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Vérifier",
|
||||
"body": "Un fichier contenant des erreurs n’est pas installé. Chaque erreur indique le champ concerné ; un JSON invalide signale la ligne et la colonne."
|
||||
},
|
||||
{
|
||||
"title": "Examiner",
|
||||
"body": "Un fichier valide affiche ce qu’il installe : image, adresse web, ports, chemins persistants, variables demandées et fichiers écrits pendant l’installation."
|
||||
},
|
||||
{
|
||||
"title": "Installer",
|
||||
"body": "L’installation suit le même parcours que pour toute application du catalogue, avec les paramètres par défaut ou avancés."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Un fichier qui détermine les privilèges",
|
||||
"body": "Un oci-compose détermine ce qui est monté dans le conteneur et avec quels privilèges. La vérification le précise avant l’installation : n’installez que des fichiers de sources fiables."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le <readmeLink>README du moteur OCI</readmeLink> décrit le format bloc par bloc avec deux exemples complets. Un enregistrement d’installation peut aussi être lu de cette façon : seul le modèle d’origine est utilisé, sans aucune des réponses de cette installation."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "private-registries",
|
||||
"title": "Images de registres privés",
|
||||
"intro": "Une image d’un registre privé, comme un paquet privé GitHub ou un dépôt privé Docker Hub, est lue avec un compte enregistré dans ProxMenux.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Le registre refuse l’accès à l’image",
|
||||
"body": "Si le registre indique que l’image nécessite un compte, la vérification propose de s’y connecter, puis lit à nouveau l’image."
|
||||
},
|
||||
{
|
||||
"title": "Se connecter",
|
||||
"body": "Un nom d’utilisateur et un mot de passe ou jeton autorisé à télécharger l’image. Le registre les vérifie ; ils ne sont enregistrés que s’il les accepte."
|
||||
},
|
||||
{
|
||||
"title": "Installer et maintenir à jour",
|
||||
"body": "Ce compte sert au téléchargement pendant l’installation, ainsi qu’aux mises à jour, à Modifier, à Recréer, au watchdog et à la recherche de mises à jour du Monitor, sur chaque nœud du cluster."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "<strong>Comptes de registres</strong>, dans le menu principal d’OCI manager Apps, affiche les comptes enregistrés par registre et utilisateur, jamais leurs secrets. Chaque compte permet de vérifier, télécharger ou installer une image, ainsi que de mettre à jour ou supprimer les identifiants."
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"GitHub (<code>ghcr.io</code>) : l’utilisateur est le compte GitHub et le mot de passe un jeton d’accès personnel avec l’autorisation <code>read:packages</code>.",
|
||||
"Docker Hub (<code>docker.io</code>) : l’utilisateur est le compte Docker Hub et le mot de passe un jeton d’accès avec autorisation de lecture.",
|
||||
"Autres registres, y compris avec un port propre comme <code>registry.example.com:5000</code> : l’utilisateur et le mot de passe ou jeton fournis par ce registre."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Où les comptes sont conservés",
|
||||
"body": "Dans <code>/etc/pve/priv/proxmenux/registry-auth.json</code>, lisible uniquement par root, dans le même dossier que les mots de passe de stockage de Proxmox. <code>/etc/pve</code> est partagé entre tous les nœuds du cluster : un compte ajouté sur un nœud est donc utilisé partout. La sauvegarde de l’hôte inclut ce fichier et la désinstallation de ProxMenux le supprime de tous les nœuds."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "limits",
|
||||
"title": "Définitions qui ne sont pas installées",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Un Dockerfile sans image publiée : l’image doit d’abord être construite et publiée dans un registre OCI.",
|
||||
"Un fichier Compose à plusieurs services : cette option installe un seul service par conteneur, même si plusieurs services utilisent la même image.",
|
||||
"<code>configs</code>, secrets externes ou formats de périphériques impossibles à adapter sans ambiguïté.",
|
||||
"Substitutions shell comme <code>$(command)</code> : il faut saisir directement la valeur résultante.",
|
||||
"Options <code>docker run</code> non reconnues et <code>--env-file</code> : utilisez plutôt un fichier Compose aux valeurs explicites."
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,392 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Dispositifs et accélération ProxMenux",
|
||||
"description": "Comment OCI manager Apps rend les GPU, NVIDIA, Coral, USB, FUSE et autres périphériques accessibles à un conteneur OCI sous forme de ressources natives Proxmox VE validées."
|
||||
},
|
||||
"header": {
|
||||
"title": "Dispositifs et accélération",
|
||||
"description": "GPU, NVIDIA, Coral, USB, FUSE et les dispositifs de blocs deviennent des ressources natives validées Proxmox VE du conteneur.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "principle",
|
||||
"title": "L'appareil dont l'application a besoin, pas l'hôte entier",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Un appareil demandé par le fichier Compose ou par le profil d'application devient une entrée concrète <code>devN</code> ou un montage LXC. Demander un GPU, un périphérique USB ou un Coral ne rend pas le conteneur privilégié."
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Inventaire des hôtes",
|
||||
"detail": "/dev/dri/renderD128\nGID 993 · Intel"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "fournisseur et\npermissions vérifiées"
|
||||
},
|
||||
{
|
||||
"label": "LXC",
|
||||
"detail": "même périphérique\nGID effectif"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "origin",
|
||||
"title": "D'où vient la demande de l'appareil",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Source",
|
||||
"Ce qui est lu",
|
||||
"Ce que fait l'installateur"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Docker Compose",
|
||||
"Demandes <code>devices</code>, <code>group_add</code>, <code>deploy.resources</code> et NVIDIA",
|
||||
"Chaque exigence devient une demande d'appareil présentée pour examen"
|
||||
],
|
||||
[
|
||||
"Profil du catalogue",
|
||||
"La prise en charge réelle des GPU, de Coral, d’OpenCL, d’USB ou de FUSE par l’application",
|
||||
"Seules les options validées pour cette image sont proposées"
|
||||
],
|
||||
[
|
||||
"métadonnées d'images et documentation",
|
||||
"VA-API, Selkies, LinuxServer mods ou le NVIDIA runtime",
|
||||
"Les variables documentées et la préparation sont ajoutées"
|
||||
],
|
||||
[
|
||||
"Sélection de l'utilisateur",
|
||||
"CPU uniquement, Intel/AMD, OpenCL, NVIDIA ou un appareil optionnel",
|
||||
"La sélection est stockée dans le contrat d'instance"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Les périphériques détectés ne sont pas ajoutés automatiquement",
|
||||
"body": "L'hôte est inventorié, mais seuls les appareils déclarés par le fichier Compose ou par un profil compatible sont proposés et attachés. Un GPU, un dongle USB ou un Coral présent sur l'hôte n'est pas exposé à tous les LXC."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "identify",
|
||||
"title": "Comment le périphérique hôte est identifié",
|
||||
"intro": "Avant que le LXC ne soit modifié, l'appareil est lu sur l'hôte et correspond au profil choisi.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Type",
|
||||
"Identité",
|
||||
"Validation"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD DRM",
|
||||
"<code>/dev/dri/renderD*</code> et <code>/sys/class/drm/NODE/device/vendor</code>",
|
||||
"Dispositif de caractères avec fournisseur <code>0x8086</code> (Intel) ou <code>0x1002</code> (AMD)"
|
||||
],
|
||||
[
|
||||
"AMD OpenCL",
|
||||
"Le nœud de rendu, plus <code>/dev/kfd</code> lorsque le profil en a besoin",
|
||||
"Existence, type, fournisseur, autorisations et compatibilité déclarée"
|
||||
],
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Le nœud de rendu, <code>/dev/kfd</code> et la génération indiquée par le pilote de calcul dans <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"Une génération pour laquelle l’image ROCm de l’application contient des noyaux de calcul — les GPU RDNA2 cités et les plus récents — est proposée telle quelle. Les autres GPU de ces familles, comme les Radeon 680M et 780M, sont proposés à titre expérimental et jamais présélectionnés : ROCm ne les prend pas officiellement en charge, l’application les présente comme la génération de leur famille (<code>HSA_OVERRIDE_GFX_VERSION</code>) et l’installateur demande confirmation avant de télécharger l’image plus volumineuse. Une GPU plus ancienne, telle que la partie graphique intégrée d’un Ryzen 5000U, n’est pas proposée et Immich conserve la reconnaissance sur le CPU."
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"<code>nvidia-smi</code> et <code>nvidia-container-cli</code>",
|
||||
"GPU, UUID, PCI bus, version pilote, Toolkit, <code>/dev/nvidia*</code> nœuds, binaires et bibliothèques"
|
||||
],
|
||||
[
|
||||
"Coral PCIe/M.2",
|
||||
"<code>/dev/apex_N</code> et son lien dans <code>/sys/dev/char/MAJOR:MINOR</code>",
|
||||
"Nœud de caractère, majeur/mineur, propriétaire, GID et permissions"
|
||||
],
|
||||
[
|
||||
"USB et série",
|
||||
"<code>/dev/ttyUSB*</code>, <code>/dev/ttyACM*</code> ou <code>/dev/bus/usb/BBB/DDD</code>",
|
||||
"Nœud de caractère; pour USB aussi fournisseur, produit et série lorsque sysfs les publie"
|
||||
],
|
||||
[
|
||||
"KVM, TUN, FUSE, vidéo et SCSI générique",
|
||||
"<code>/dev/kvm</code>, <code>/dev/net/tun</code>, <code>/dev/fuse</code>, <code>/dev/videoN</code> ou <code>/dev/sgN</code>",
|
||||
"Chemin pris en charge, type de nœud et permissions effectives"
|
||||
],
|
||||
[
|
||||
"Lecteur optique",
|
||||
"<code>/dev/srN</code>",
|
||||
"Un périphérique bloc"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "install",
|
||||
"title": "Ce qui se passe pendant l'installation",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Le modèle offre ses profils",
|
||||
"body": "Par exemple CPU seulement, Intel/AMD VA-API, AMD OpenCL, Intel OpenCL ou NVIDIA. Les options appartiennent à l'image, pas à un menu commun."
|
||||
},
|
||||
{
|
||||
"title": "Un profil est choisi",
|
||||
"body": "Il définit les nœuds de périphérique, l'environnement, les mods ou l'exécution dont l'application a besoin."
|
||||
},
|
||||
{
|
||||
"title": "Un chemin est proposé",
|
||||
"body": "Pour DRM, <code>/dev/dri/renderD128</code>, qui peut être modifié sur un hôte avec plusieurs nœuds de rendu. Pour USB ou série, le nœud précis est sélectionné."
|
||||
},
|
||||
{
|
||||
"title": "Validation",
|
||||
"body": "L'existence, le type, le fournisseur autorisé, les autorisations et le GID sont vérifiés. Une inadéquation arrête l'opération."
|
||||
},
|
||||
{
|
||||
"title": "Le contrat est écrit",
|
||||
"body": "Chemin, mode, GID, accès à l'écriture et profil sont enregistrés pour les mises à jour et les recréations de conteneurs."
|
||||
},
|
||||
{
|
||||
"title": "Ajout et vérification",
|
||||
"body": "<code>pct set</code> ajoute l'entrée <code>devN</code> et l'accès est ensuite vérifié à l'intérieur du LXC. Les images LinuxServer sont également vérifiées en tant qu'utilisateur <code>abc</code>."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "config",
|
||||
"title": "Comment il apparaît dans la configuration LXC",
|
||||
"intro": "Valeurs indicatives : <code>dev0</code> et <code>dev1</code> sont les emplacements libres attribués par Proxmox VE ; <code>renderD128</code>, <code>apex_0</code> et le GID dépendent du matériel du nœud.",
|
||||
"blocks": [
|
||||
{
|
||||
"codeGrid": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Intel/AMD VA-API",
|
||||
"code": "dev0: path=/dev/dri/renderD128,mode=0660,gid=993,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Coral PCIe/M.2",
|
||||
"code": "dev0: path=/dev/apex_0,mode=0660,gid=GID,deny-write=0"
|
||||
},
|
||||
{
|
||||
"title": "Un périphérique USB spécifique",
|
||||
"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": "Le GID est lu avec <code>stat</code> sur l'hôte et écrit à l'entrée <code>devN</code>; les groupes <code>render</code> et <code>video</code> ne sont pas supposés avoir un nombre fixe. L'appareil conserve le même chemin <code>/dev</code> à l'intérieur du LXC, où les propres mécanismes de l'application le recherchent."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "profiles",
|
||||
"title": "Profils qu'une image peut offrir",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Profil",
|
||||
"Configuration résultante",
|
||||
"Proposé quand"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Intel/AMD VA-API",
|
||||
"Le noeud de rendu <code>/dev/dri</code>",
|
||||
"L'application prend en charge l'accélération vidéo"
|
||||
],
|
||||
[
|
||||
"OpenCL",
|
||||
"Noeud Render, <code>/dev/kfd</code> au besoin et le mod officiel",
|
||||
"L'image ou le profil le documente"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
"Dispositifs pilotes et bibliothèques de l'hôte",
|
||||
"L’hôte dispose d’un pilote fonctionnel et de NVIDIA Container Toolkit"
|
||||
],
|
||||
[
|
||||
"Coral",
|
||||
"<code>/dev/apex_0</code> ou le bus USB",
|
||||
"Le profil déclare la prise en charge de Coral (Frigate)"
|
||||
],
|
||||
[
|
||||
"USB, série, FUSE",
|
||||
"Un seul appareil, un arbre validé ou une fonction LXC",
|
||||
"Le contrat le demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "nvidia",
|
||||
"title": "NVIDIA",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Prérequis sur le nœud : NVIDIA Container Toolkit",
|
||||
"body": "Un pilote fonctionnel sur Proxmox VE ne suffit pas à donner une GPU NVIDIA à une image OCI. OCI Manager Apps utilise <code>nvidia-container-cli</code>, de NVIDIA Container Toolkit, pour identifier les appareils et obtenir les binaires et les bibliothèques qui correspondent au pilote chargé."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Le <nvidiaLink>installateur NVIDIA de ProxMenux</nvidiaLink> installe NVIDIA Container Toolkit du dépôt officiel NVIDIA avec le pilote. Il vérifie ses quatre paquets, valide <code>nvidia-container-cli</code> et enregistre le résultat dans le journal de changement de <auditLink>Audit & Report</auditLink>."
|
||||
},
|
||||
{
|
||||
"p": "Ces deux commandes sur l'hôte montrent si le pilote et le Toolkit sont disponibles :"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-smi -L\nnvidia-container-cli --version"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Sur un hôte où le pilote a été installé par d'autres moyens, le Toolkit est installé à partir du dépôt stable officiel:"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "apt-get update\napt-get install -y --no-install-recommends ca-certificates curl gnupg2\n\ncurl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \\\n | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg\n\ncurl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \\\n | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \\\n > /etc/apt/sources.list.d/nvidia-container-toolkit.list\n\napt-get update\napt-get install -y nvidia-container-toolkit libnvidia-container-tools"
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "L’inventaire utilisé par OCI manager Apps provient de la sortie de :"
|
||||
},
|
||||
{
|
||||
"shell": {
|
||||
"code": "nvidia-container-cli list --device all --libraries --binaries --firmwares --ipcs"
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "La configuration d'exécution Docker n'est pas impliquée",
|
||||
"body": "Les conteneurs sont des LXC natifs sans démon Docker : <code>nvidia-ctk runtime configure --runtime=docker</code> ne joue donc aucun rôle. ProxMenux interroge directement <code>nvidia-container-cli</code> et écrit les périphériques et montages LXC. Les commandes et plateformes prises en charge sont maintenues dans le <toolkitLink>guide d’installation de NVIDIA Container Toolkit</toolkitLink>."
|
||||
}
|
||||
},
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "cpu",
|
||||
"title": "Inventaire issu du pilote",
|
||||
"body": "<code>nvidia-container-cli</code> énumère les nœuds de périphérique, les binaires, les micrologiciels et les bibliothèques du pilote installé."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Pas de version fixe",
|
||||
"body": "Le modèle ne nomme pas les fichiers de bibliothèque. Le profil est généré à partir de l'hôte actuel."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Montages en lecture seule",
|
||||
"body": "Les bibliothèques hôtes sont montées en lecture seule au lieu d'être copiées dans le conteneur."
|
||||
},
|
||||
{
|
||||
"icon": "hardDrive",
|
||||
"title": "Changements de pilote",
|
||||
"body": "Après un changement de pilote, l'inventaire est généré à nouveau avant le démarrage des LXC touchés."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"code": {
|
||||
"title": "Résultat NVIDIA (simplifié)",
|
||||
"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": "Passer uniquement <code>/dev/nvidia0</code> ne suffit pas. Les composants espace utilisateur du pilote chargé sont montés en lecture seule, et <code>nvidia-smi</code> fonctionne ensuite à l'intérieur du LXC pour comparer GPU, UUID, PCI bus et version avec l'inventaire hôte."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "usb",
|
||||
"title": "Coral USB, série et USB",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "La numérotation USB peut changer",
|
||||
"body": "Un chemin tel que <code>/dev/bus/usb/003/004</code> peut changer lorsque le périphérique est reconnecté ou que l'hôte redémarre. Le profil enregistre le fournisseur, le produit et la série lorsqu'ils sont disponibles, mais une nouvelle adresse de bus n'est pas automatiquement réaffectée."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Un périphérique est donné par son nœud concret : <code>/dev/ttyUSB0</code>, <code>/dev/ttyACM0</code>, <code>/dev/apex_0</code> ou <code>/dev/bus/usb/BBB/DDD</code>. Passer l'intégralité de <code>/dev</code> n'est pas accepté. Coral est proposé uniquement aux applications dont le profil le déclare."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "trees",
|
||||
"title": "Arbres de périphériques et fonctionnalités LXC",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Demande",
|
||||
"Configuration résultante",
|
||||
"Portée"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"<code>/dev/dvb</code>, <code>/dev/snd</code> ou <code>/dev/bus/usb</code>",
|
||||
"Chaque noeud de caractère de l'arbre obtient sa propre entrée <code>devN</code> avec le mode hôte et GID",
|
||||
"Seulement l'arbre demandé, pas le reste de <code>/dev</code>"
|
||||
],
|
||||
[
|
||||
"<code>/dev/fuse</code>",
|
||||
"Le nœud et, lorsque le profil en a besoin, la fonction <code>fuse=1</code>",
|
||||
"FUSE seul ne publie pas de montages sur d'autres LXC"
|
||||
],
|
||||
[
|
||||
"<code>/dev/net/tun</code>",
|
||||
"Une entrée <code>devN</code> sur le même chemin à l'intérieur du LXC",
|
||||
"La configuration VPN ou réseau reste dans l'application"
|
||||
],
|
||||
[
|
||||
"<code>/dev/kvm</code>",
|
||||
"Une entrée <code>devN</code> validée",
|
||||
"Offert seulement lorsque le contrat le demande"
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "security",
|
||||
"title": "Confirmations par niveau de risque",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Les périphériques concrets, les privilèges facultatifs, les privilèges requis, la relaxation AppArmor ou seccomp et l'accès à l'espace de noms PID hôte sont traités comme des cas distincts, et non sous une seule étiquette privilégiée générique. Chaque option présentant un risque est expliquée et confirmée lors de l'installation."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,213 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "OCI manager Apps | ProxMenux",
|
||||
"description": "Exécutez des images OCI officielles dans des conteneurs LXC natifs de Proxmox VE, avec des données persistantes, l’accès aux périphériques, des applications à plusieurs conteneurs et des mises à jour transactionnelles."
|
||||
},
|
||||
"header": {
|
||||
"title": "OCI manager Apps",
|
||||
"description": "Les images OCI officielles s’exécutent dans des conteneurs LXC natifs de Proxmox VE. L’image reste celle publiée par son mainteneur ; ProxMenux reproduit l’environnement que Docker Compose aurait créé autour d’elle.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "model",
|
||||
"blocks": [
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Une image OCI, un LXC natif",
|
||||
"body": "Aucun moteur Docker ne s’exécute dans les conteneurs. Proxmox VE importe le système de fichiers de l’image et ses métadonnées OCI. L’application devient le processus principal d’un LXC natif, administré avec les mêmes outils que les autres conteneurs du nœud."
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Source",
|
||||
"detail": "Image OCI\nCompose et documentation"
|
||||
},
|
||||
{
|
||||
"label": "ProxMenux",
|
||||
"detail": "Contrat JSON\nvalidation et planification"
|
||||
},
|
||||
{
|
||||
"label": "Proxmox VE",
|
||||
"detail": "LXC natif\nvolumes et périphériques"
|
||||
}
|
||||
],
|
||||
"caption": "L’application d’origine est conservée : son environnement est décrit de façon déclarative, puis reproduit."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "where",
|
||||
"title": "Où le trouver",
|
||||
"intro": "Sur le nœud Proxmox, en tant que root, ouvrez <strong>OCI manager Apps (Technology Preview)</strong> dans le menu principal de ProxMenux. Le premier écran propose :",
|
||||
"blocks": [
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"<strong>Rechercher des applications</strong> : rechercher par nom dans tout le catalogue.",
|
||||
"<strong>Toutes les applications</strong> : afficher le catalogue complet et le nombre d’applications.",
|
||||
"<strong>Gérer les applications OCI installées</strong> : mettre à jour, modifier, supprimer ou récupérer les applications déjà installées.",
|
||||
"<strong>Comptes de registres</strong> : gérer les comptes utilisés pour installer et mettre à jour des images provenant de registres privés.",
|
||||
"<strong>Installer une image absente du catalogue</strong> : adapter un fichier Compose, une commande <code>docker run</code> ou une référence d’image.",
|
||||
"Les catégories du catalogue, chacune avec son nombre d’applications."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/main-menu.png",
|
||||
"alt": "Écran principal d’OCI manager Apps avec recherche, catalogue complet, gestion des applications, images hors catalogue et catégories.",
|
||||
"caption": "Écran principal d’OCI manager Apps."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "La sélection d’une application affiche sa description, l’image utilisée et deux modes d’installation. <strong>Installer avec les paramètres par défaut</strong> ne application que les choix essentiels : stockage, emplacement des données, adresse et démarrage. <strong>Installer avec les paramètres avancés</strong> présente toutes les décisions dans l’ordre : VMID et ressources, stockage de chaque chemin, pont réseau et périphériques."
|
||||
},
|
||||
{
|
||||
"p": "Les applications effectivement testées affichent <strong>Vérifié</strong> dans cette vue et portent un ✓ dans les listes, que le test ait été effectué dans le laboratoire ProxMenux ou par la communauté."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "beta",
|
||||
"title": "Pourquoi le label Technology Preview est conservé",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "OCI manager Apps conserve le label <strong>Technology Preview</strong> que Proxmox VE attribue aux conteneurs d’applications créés à partir d’images OCI, dont la prise en charge a été introduite dans Proxmox VE 9.1. Ce label concerne la technologie sur laquelle repose OCI manager Apps, et non le moteur de ProxMenux : le comportement de ces conteneurs peut encore changer entre les versions de Proxmox VE. Le label restera en place jusqu’à ce que Proxmox VE considère cette prise en charge comme stable."
|
||||
},
|
||||
{
|
||||
"p": "Le moteur d’OCI manager Apps est testé dans le laboratoire ProxMenux : installation, mise à jour, modification, recréation, sauvegarde, restauration, migration et watchdog. Chaque application est vérifiée séparément. Celles qui ont été effectivement testées affichent <strong>Vérifié</strong> et portent un ✓ dans les listes."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "translation",
|
||||
"title": "Comment Docker décrit les besoins et comment OCI manager Apps les applique",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Besoin",
|
||||
"Expression dans Docker",
|
||||
"Mise en œuvre par OCI manager Apps"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Exécuter l’application",
|
||||
"<code>image</code>, <code>entrypoint</code>, <code>command</code>",
|
||||
"Le rootfs OCI et le processus principal du LXC"
|
||||
],
|
||||
[
|
||||
"Conserver la configuration",
|
||||
"<code>volumes: /config</code>",
|
||||
"Un volume persistant <code>mpN</code> inclus dans la sauvegarde, ou un répertoire de l’hôte."
|
||||
],
|
||||
[
|
||||
"Rendre le service accessible",
|
||||
"<code>ports</code>",
|
||||
"Une adresse propre au LXC et l’URL d’accès au service."
|
||||
],
|
||||
[
|
||||
"Utiliser du matériel",
|
||||
"<code>devices</code>, <code>group_add</code>",
|
||||
"Des entrées <code>devN</code> avec le GID effectif de l’hôte et un profil validé."
|
||||
],
|
||||
[
|
||||
"Relier les dépendances",
|
||||
"<code>networks</code>, <code>depends_on</code>",
|
||||
"Un pont réseau privé, des adresses fixes, un ordre de démarrage et des contrôles de bon fonctionnement."
|
||||
],
|
||||
[
|
||||
"Mettre à jour",
|
||||
"Télécharger avec <code>pull</code> et recréer",
|
||||
"Un nouveau rootfs avec le même contrat de persistance."
|
||||
]
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "kept",
|
||||
"title": "Ce qui est conservé et ce qui change",
|
||||
"blocks": [
|
||||
{
|
||||
"cards": {
|
||||
"items": [
|
||||
{
|
||||
"icon": "archive",
|
||||
"title": "Conservé",
|
||||
"body": "L’image officielle, ses chemins internes, son environnement, son processus de démarrage et sa documentation d’utilisation."
|
||||
},
|
||||
{
|
||||
"icon": "boxes",
|
||||
"title": "Adapté",
|
||||
"body": "L’environnement d’exécution : le réseau, la persistance, les périphériques, les permissions et les dépendances utilisent les mécanismes LXC natifs de Proxmox VE."
|
||||
},
|
||||
{
|
||||
"icon": "shield",
|
||||
"title": "Sans équivalent",
|
||||
"body": "Une option Compose sans équivalent sûr est signalée comme un point bloquant. Les modèles comportant des points bloquants ne sont pas proposés à l’installation, et les options sensibles doivent être confirmées pendant l’assistant."
|
||||
},
|
||||
{
|
||||
"icon": "refresh",
|
||||
"title": "Enregistré",
|
||||
"body": "Le digest de l’image, les ressources, les chemins, le réseau, les périphériques et l’appartenance à une pile sont enregistrés dans le contrat de l’instance. Les mises à jour et les recréations reproduisent ce contrat."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "pages",
|
||||
"title": "Pages de cette section",
|
||||
"blocks": [
|
||||
{
|
||||
"next": {
|
||||
"items": [
|
||||
{
|
||||
"label": "Comment une image OCI est adaptée",
|
||||
"href": "/docs/oci-manager/architecture",
|
||||
"tail": "De l’image et de son fichier Compose à un LXC natif."
|
||||
},
|
||||
{
|
||||
"label": "Installer une image absente du catalogue",
|
||||
"href": "/docs/oci-manager/custom-image",
|
||||
"tail": "Un fichier Compose, une commande docker run ou une référence d’image."
|
||||
},
|
||||
{
|
||||
"label": "Données, chemins et réseau",
|
||||
"href": "/docs/oci-manager/storage-network",
|
||||
"tail": "Volumes du conteneur, répertoires de l’hôte, montages rclone et adresses."
|
||||
},
|
||||
{
|
||||
"label": "Périphériques et accélération",
|
||||
"href": "/docs/oci-manager/hardware",
|
||||
"tail": "GPU, NVIDIA, Coral, USB et autres périphériques."
|
||||
},
|
||||
{
|
||||
"label": "Applications à plusieurs conteneurs",
|
||||
"href": "/docs/oci-manager/stacks",
|
||||
"tail": "Application, base de données et cache dans des LXC coordonnés."
|
||||
},
|
||||
{
|
||||
"label": "Installer, mettre à jour et modifier",
|
||||
"href": "/docs/oci-manager/lifecycle",
|
||||
"tail": "Le contrat de l’instance et ses opérations."
|
||||
},
|
||||
{
|
||||
"label": "Dans ProxMenux Monitor",
|
||||
"href": "/docs/oci-manager/monitor",
|
||||
"tail": "Versions, mises à jour, sortie console et terminal."
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,499 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Installer, mettre à jour et modifier | ProxMenux",
|
||||
"description": "Le contrat d'instance d'un conteneur OCI et les opérations qui s'appuient dessus : mise à jour, modification, suppression, reprise d'une opération interrompue et remise en service après une restauration sur cet hôte ou un autre."
|
||||
},
|
||||
"header": {
|
||||
"title": "Installer, mettre à jour et modifier",
|
||||
"description": "Chaque instance conserve un contrat reproductible, ce qui permet de remplacer son rootfs sans perdre sa configuration ni ses données persistantes.",
|
||||
"section": "OCI manager Apps"
|
||||
},
|
||||
"sections": [
|
||||
{
|
||||
"id": "contract",
|
||||
"title": "Le contrat d'instance",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Après l'installation, la configuration effective est enregistrée dans <code>/usr/local/share/proxmenux/oci/instances/VMID/oci-compose.json</code>. Il ne s'agit pas d'une copie du fichier Compose d'origine : c'est le contrat reproductible du LXC présent sur cet hôte."
|
||||
},
|
||||
{
|
||||
"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": "Une copie du contrat est conservée dans le conteneur, dans <code>/.proxmenux/oci-record.json</code>, et seul l'utilisateur root du conteneur peut la lire. Une sauvegarde du conteneur emporte donc toujours le contrat en vigueur au moment de la sauvegarde. Une seconde copie est conservée dans <code>/etc/pve/priv/proxmenux/oci</code>, un emplacement partagé par tous les nœuds du cluster et lisible uniquement par root sur l'hôte. Les deux copies sont écrites après chaque installation, mise à jour et modification."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "manage",
|
||||
"title": "Gérer les applications OCI installées",
|
||||
"intro": "Cette option de l'écran principal liste les instances enregistrées avec leur application et image. Chacun d'eux est vérifié par rapport à son contrat avant toute action; un CT qui ne correspond plus à son enregistrement n'est ni modifié ni supprimé. La même mise à jour et le même éditeur sont proposés dans l'onglet Mises à jour de <monitorLink>ProxMenux Monitor</monitorLink>.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Option",
|
||||
"Ce qui change",
|
||||
"Ce qui est gardé"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Mettre à jour l'image avec la configuration enregistrée",
|
||||
"Le rootfs est remplacé par l'image actuellement publiée sur le canal enregistré",
|
||||
"Contrat, disques de conteneur, répertoires hôtes, réseau et appareils"
|
||||
],
|
||||
[
|
||||
"Modifier : éditer les ressources, le réseau, les chemins et le GPU",
|
||||
"L'éditeur s'ouvre avec le contrat actuel; le CT est reconstruit avec les modifications",
|
||||
"Les données des disques de conteneur et des répertoires hôtes"
|
||||
],
|
||||
[
|
||||
"Watchdog : redémarrer l'application lorsqu'elle plante",
|
||||
"Détermine si l'application est relancée lorsqu'elle s'arrête d'elle-même. Rien n'est reconstruit",
|
||||
"L'ensemble de l'installation ; seul le choix est sauvegardé dans le contrat"
|
||||
],
|
||||
[
|
||||
"Supprimer: supprimer l'application et ses conteneurs",
|
||||
"Le LXC, ou chaque membre d'une pile, et leurs contrats sont supprimés",
|
||||
"Répertoires hôtes, avec leur contenu"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Pour une application à plusieurs conteneurs, le menu propose <strong>Mettre à jour tous les conteneurs de l'application</strong>, <strong>Modifier les chemins et périphériques supplémentaires</strong>, <strong>Recréer tous les conteneurs avec leur configuration enregistrée</strong>, le watchdog et la suppression. Modifier ajoute ou supprime les chemins et périphériques supplémentaires du conteneur applicatif sans rien reconstruire et, pour Immich, change le composant qui exécute la reconnaissance. Recréer reconstruit chaque conteneur à partir de l'image utilisée lors de son installation, sans en chercher une plus récente."
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/manage-menu.png",
|
||||
"alt": "Liste des applications OCI installées, avec les options de mise à jour, de modification et de suppression",
|
||||
"caption": "Gérer les applications OCI installées."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "update",
|
||||
"title": "Une mise à jour transactionnelle",
|
||||
"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": "Utilisateur",
|
||||
"registry": "Registre OCI",
|
||||
"update": "Mettre à jour l'instance",
|
||||
"resolve": "Résoudre la balise",
|
||||
"verify": "Vérifier l’archive et effectuer les contrôles préalables",
|
||||
"backup": "Arrêter et sauvegarder le CT",
|
||||
"import": "Importer le nouveau rootfs",
|
||||
"reapply": "Appliquer à nouveau le contrat",
|
||||
"healthy": "sain",
|
||||
"failure": "défaillance",
|
||||
"commit": "Contrat publié avec le nouveau digest",
|
||||
"restored": "instance précédente restaurée"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"list": {
|
||||
"items": [
|
||||
"Lorsque le registre sert encore le digest installé, rien n'est téléchargé et l'instance n'est pas touchée.",
|
||||
"La nouvelle image est vérifiée couche par couche avant l'arrêt du CT. Un téléchargement qui arrive endommagé est récupéré une deuxième fois ; une image déjà mise en cache qui échoue la vérification est à nouveau téléchargée.",
|
||||
"Les paramètres modifiés dans Proxmox VE après l'installation (mémoire, swap, cœurs, limite et priorité du CPU, démarrage avec le nœud) sont conservés et intégrés au nouveau contrat.",
|
||||
"L'interface LAN ajoutée par la suite Arr et les applications à plusieurs conteneurs (<code>net1</code>), ainsi que l'ordre de démarrage (<code>startup</code>), sont réappliqués tels quels au nouveau conteneur.",
|
||||
"Toute autre différence entre le CT et son contrat arrête la mise à jour avant que le CT ne soit arrêté."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"flow": {
|
||||
"nodes": [
|
||||
{
|
||||
"label": "Avant",
|
||||
"detail": "rootfs A\n/config mp0\n/media répertoire de l’hôte"
|
||||
},
|
||||
{
|
||||
"label": "Mise à jour",
|
||||
"detail": "remplace uniquement\nle rootfs"
|
||||
},
|
||||
{
|
||||
"label": "Après",
|
||||
"detail": "rootfs B\n/config mp0\n/media répertoire de l’hôte"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Avant tout arrêt, l'opération vérifie l'espace nécessaire à la sauvegarde : les données utilisées sur les volumes inclus, plus une marge. La sauvegarde est écrite à côté de l'enregistrement de l'application, sur le disque système de l'hôte. Si l'espace y est insuffisant, le menu demande un autre stockage de l'hôte acceptant les sauvegardes. La sauvegarde y est créée puis supprimée à la fin de l'opération. Ce choix est mémorisé pour l'application, y compris pour les mises à jour planifiées. Si aucun stockage n'a assez de place, l'opération est refusée et l'application reste inchangée. L'espace nécessaire à la nouvelle image est également vérifié avant son téléchargement."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "recovery",
|
||||
"title": "Récupération d'une opération interrompue",
|
||||
"intro": "Une mise à jour et un changement utilisent une transaction persistante. Si le processus, le terminal ou le nœud est interrompu après l'arrêt du CT, l'opération n'est pas prise comme terminée.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Marqueur en attente",
|
||||
"body": "À l'ouverture de Gérer les applications OCI installées, l'état enregistré indique que le remplacement n'a jamais été publié."
|
||||
},
|
||||
{
|
||||
"title": "Afficher l’état",
|
||||
"body": "Affiche la phase qui a été atteinte sans changer de conteneur ou de données."
|
||||
},
|
||||
{
|
||||
"title": "Récupérer l'installation précédente",
|
||||
"body": "Restaure la sauvegarde native vérifiée réalisée avant le remplacement, ainsi que le contrat précédent."
|
||||
},
|
||||
{
|
||||
"title": "Piles traitées comme une unité",
|
||||
"body": "Pour une application multi-conteneurs, chaque membre est récupéré du même point de transaction, pas seulement celui sélectionné."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Les répertoires de l’hôte sont exclus du retour arrière",
|
||||
"body": "La sauvegarde couvre le rootfs et les disques du conteneur qui y sont inclus. Un répertoire de l’hôte n’est pas rétabli à son état précédent, car d’autres LXC peuvent utiliser ses données."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "watchdog",
|
||||
"title": "Watchdog: redémarrer une application qui s'arrête",
|
||||
"intro": "Proxmox n'a pas de politique de redémarrage : quand le processus d'un conteneur applicatif se termine, le conteneur reste arrêté. Si le watchdog est activé, une application qui s'arrête d'elle-même est relancée. Il joue pour une application OCI le rôle de <code>restart: unless-stopped</code> dans un fichier Compose.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce qui se passe",
|
||||
"Avec le watchdog activé"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"L’application plante ou son processus se termine",
|
||||
"Le conteneur est relancé en quelques secondes"
|
||||
],
|
||||
[
|
||||
"Il est arrêté ou éteint depuis Proxmox, depuis le Monitor ou avec <code>pct</code>",
|
||||
"Il reste arrêté jusqu’à ce que quelqu’un le démarre"
|
||||
],
|
||||
[
|
||||
"Une sauvegarde, une migration ou une opération ProxMenux travaille dessus",
|
||||
"Rien n'est fait jusqu'à la fin"
|
||||
],
|
||||
[
|
||||
"Il était déjà arrêté au démarrage de l’hôte",
|
||||
"Il reste arrêté ; cela dépend de <strong>Démarrer avec Proxmox</strong>"
|
||||
],
|
||||
[
|
||||
"Il s’arrête systématiquement juste après son démarrage",
|
||||
"Pour une application qui s’arrête quelques secondes après son démarrage ou qui ne démarre pas, cinq tentatives sont effectuées, séparées par des délais de 30 secondes, 1, 2 et 5 minutes. Elle reste ensuite arrêtée et une notification est envoyée"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "L'installateur pose la question dans les deux modes d'installation et propose la valeur déclarée par la recette de l'application. Ce réglage peut ensuite être modifié dans <strong>Gérer les applications OCI installées</strong> ou avec le commutateur <strong>Watchdog</strong> du conteneur dans <monitorLink>ProxMenux Monitor</monitorLink>. Il s'applique à tous les conteneurs d'une application à plusieurs conteneurs. Un seul service de l'hôte, <code>proxmenux-oci-watchdog.service</code>, surveille les applications pour lesquelles il est activé ; son installation figure dans l'onglet Modifications d'Audit & Report."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Ce que l'hôte ne peut pas dire",
|
||||
"body": "Le code de sortie de l'application ne parvient pas à l'hôte. Un arrêt normal et un plantage sont donc indiscernables et entraînent tous deux un redémarrage, comme avec <code>always</code> et <code>unless-stopped</code> dans Docker. Un arrêt demandé en dehors de Proxmox, avec <code>lxc-stop</code> ou <code>systemctl</code>, ne laisse aucune tâche d'arrêt et est interprété comme un arrêt spontané."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "restore",
|
||||
"title": "Sauvegarde, restauration et un autre hôte",
|
||||
"intro": "Une sauvegarde réalisée avec vzdump ou Proxmox Backup Server contient le conteneur, les disques du conteneur sélectionnés pour la sauvegarde et la copie de son contrat. Les éléments conservés par l'installation sur l'hôte n'en font pas partie. <strong>Gérer les applications OCI installées</strong> détecte les conteneurs restaurés sur un hôte dépourvu de leur contrat, après une nouvelle installation de Proxmox ou sur un autre hôte, et propose de les enregistrer à nouveau.",
|
||||
"blocks": [
|
||||
{
|
||||
"steps": {
|
||||
"items": [
|
||||
{
|
||||
"title": "Restaurer les conteneurs dans Proxmox",
|
||||
"body": "Depuis le stockage de sauvegarde, avec l’ID d’origine ou tout autre ID libre. Une application à plusieurs conteneurs nécessite tous ses conteneurs."
|
||||
},
|
||||
{
|
||||
"title": "Ouvrir la gestion des applications OCI installées",
|
||||
"body": "Les conteneurs restaurés sont listés et la récupération est proposée. Le bouton <strong>Récupérer</strong> de l’onglet Mises à jour de <monitorLink>ProxMenux Monitor</monitorLink> ouvre la même récupération."
|
||||
},
|
||||
{
|
||||
"title": "Vérifier avant de changer",
|
||||
"body": "La récupération vérifie que l'hôte a tout ce dont chaque application a besoin. Une application qui ne peut pas être récupérée entière est laissée comme elle a été trouvée, avec la raison."
|
||||
},
|
||||
{
|
||||
"title": "Enregistrer et démarrer",
|
||||
"body": "Le contrat est enregistré sur cet hôte et les éléments que l'installation y conservait sont réécrits. Le démarrage des applications fait l'objet d'une question distincte, à laquelle il faut répondre Non si les conteneurs d'origine fonctionnent encore sur un autre hôte."
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-offer.png",
|
||||
"alt": "Boîte de dialogue qui énumère les conteneurs restaurés et propose de les récupérer",
|
||||
"caption": "La récupération offerte lors de l'ouverture de la gestion des applications OCI installées."
|
||||
}
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce que l'hôte a gardé",
|
||||
"Après la récupération"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Contrat d’instance",
|
||||
"Enregistré à partir de la copie conservée dans le conteneur et vérifié par rapport à la configuration restaurée par Proxmox"
|
||||
],
|
||||
[
|
||||
"Réseau privé d'une application multiconteneurs",
|
||||
"Recréé avec le même pont et sous-réseau ; les adresses fixes des conteneurs ne changent pas"
|
||||
],
|
||||
[
|
||||
"Ordre de démarrage d'une application multi-conteneurs",
|
||||
"Le hookscript de dépendance et son contrat sont à nouveau installés ; les extraits sont activés sur le stockage <code>local</code> quand aucun stockage ne les accepte"
|
||||
],
|
||||
[
|
||||
"Sysctls réseau et fichier host-monitor",
|
||||
"Ecrit à nouveau en <code>/etc/pve/proxmenux</code>"
|
||||
],
|
||||
[
|
||||
"Environnement d’exécution NVIDIA",
|
||||
"Le hook d’un conteneur non privilégié est réinstallé. Un conteneur privilégié reçoit les fichiers de pilote de cet hôte à la place de ceux de son hôte d’origine"
|
||||
],
|
||||
[
|
||||
"Rclone montage",
|
||||
"Le hookscript et les programmes qui publient le montage sont à nouveau écrits, avec les mêmes vues sur l'hôte"
|
||||
],
|
||||
[
|
||||
"Règle du pare-feu d'un moniteur hôte",
|
||||
"Une nouvelle confirmation est demandée pour son port web et le sous-réseau du pont sur cet hôte"
|
||||
],
|
||||
[
|
||||
"<code>lost+found</code> de chaque disque restauré",
|
||||
"Supprimé s’il est vide ; une restauration le crée et certaines applications ne démarrent pas s’il figure dans leurs données"
|
||||
],
|
||||
[
|
||||
"Disques restaurés sur un autre stockage",
|
||||
"Le contrat est mis à jour pour refléter le stockage sur lequel ils se trouvent maintenant"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Un conteneur restauré avec un autre ID conserve son application. Le contrat, son journal de console, ses paramètres sysctl réseau, le hookscript d'un montage Rclone et l'ordre de démarrage d'une application à plusieurs conteneurs sont enregistrés avec les ID des conteneurs sur cet hôte."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ce qui empêche une récupération",
|
||||
"Que faire"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Il manque un conteneur d'une application multiconteneurs",
|
||||
"Restaurer aussi; l'application est récupérée entière"
|
||||
],
|
||||
[
|
||||
"Le sous-réseau privé est déjà utilisé sur cet hôte",
|
||||
"La récupération est annulée et rien n’est modifié : les adresses des conteneurs sont fixes et ne sont pas déplacées vers un autre sous-réseau"
|
||||
],
|
||||
[
|
||||
"Un répertoire hôte n'existe pas",
|
||||
"Monter ou créer avec ses données; une sauvegarde du conteneur n'inclut pas les répertoires hôtes"
|
||||
],
|
||||
[
|
||||
"Un périphérique n'existe pas sur cet hôte",
|
||||
"Connectez-le ou retirez-le du conteneur dans Proxmox"
|
||||
],
|
||||
[
|
||||
"Une application avec NVIDIA sur un hôte sans pilote",
|
||||
"Installez le pilote NVIDIA et le Container Toolkit"
|
||||
],
|
||||
[
|
||||
"La sauvegarde a été effectuée avant l'existence de la copie du contrat",
|
||||
"Le conteneur reste en tant que LXC ordinaire et n'est pas offert à nouveau"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Un conteneur qui revient",
|
||||
"body": "Un conteneur restauré sur lui-même à partir d'une ancienne sauvegarde, retourné à un instantané ou retourné d'un autre noeud porte le contrat de l'état dans lequel il est. Lorsqu'il est sélectionné pour une opération et que son contrat diffère de celui de cet hôte, l'opération ne démarre pas et le conteneur est offert pour récupération."
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/restore-result.png",
|
||||
"alt": "Résultat de la récupération avec le réseau privé, l’ordre de démarrage et les conteneurs enregistrés",
|
||||
"caption": "Résultat d'une reprise, étape par étape."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "remove",
|
||||
"title": "Supprimer une application OCI",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Avant la confirmation, un résumé est établi à partir de la configuration réelle : les conteneurs supprimés, les données supprimées avec eux, le réseau privé libéré et les répertoires de l’hôte conservés. La réponse par défaut est <strong>Non</strong>, car les données des disques supprimés ne pourront pas être récupérées ensuite."
|
||||
},
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Ressource",
|
||||
"À la suppression",
|
||||
"Motifs"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"rootfs et disques du conteneur",
|
||||
"Supprimés",
|
||||
"Ils appartiennent seulement au conteneur"
|
||||
],
|
||||
[
|
||||
"Répertoire de l'hôte",
|
||||
"Conservé, avec son contenu",
|
||||
"D'autres applications peuvent l'utiliser"
|
||||
],
|
||||
[
|
||||
"Fichiers hôtes du conteneur",
|
||||
"Supprimés",
|
||||
"Son journal de console, ses paramètres sysctl réseau, le hookscript du montage Rclone et son inscription dans l’onglet App de ProxMenux Monitor ne servent à aucun autre conteneur"
|
||||
],
|
||||
[
|
||||
"Fichiers partagés par plusieurs installations",
|
||||
"Supprimé avec la dernière installation qui les utilise",
|
||||
"Le fichier de surveillance de l’hôte et le hookscript des dépendances des applications à plusieurs conteneurs"
|
||||
],
|
||||
[
|
||||
"Contrat d’instance",
|
||||
"Supprimé après une suppression réussie",
|
||||
"Aucun CT ne lui est plus associé"
|
||||
],
|
||||
[
|
||||
"Pont privé d'une pile",
|
||||
"Relâché avec la pile",
|
||||
"Il n'y a plus de membres pour se connecter"
|
||||
],
|
||||
[
|
||||
"Réseau partagé par la suite Arr",
|
||||
"Libéré lors de la suppression de la dernière application de la suite",
|
||||
"Chaque application de la suite est indépendante et se supprime séparément"
|
||||
],
|
||||
[
|
||||
"Un seul membre d'une pile",
|
||||
"Non enlevé seul",
|
||||
"Toute l'application est retirée, donc aucune pile n'est laissée incomplète"
|
||||
],
|
||||
[
|
||||
"Un conteneur sur un autre noeud du cluster",
|
||||
"Non enlevé",
|
||||
"Son enregistrement et ses fichiers sur l’hôte se trouvent sur le nœud où il a été installé : il faut le supprimer là-bas, après l’y avoir remigré"
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"figure": {
|
||||
"src": "/oci-manager/remove-summary.png",
|
||||
"alt": "Résumé de suppression avec les conteneurs, les données et les répertoires hôtes touchés",
|
||||
"caption": "Le résumé de suppression, construit à partir de la configuration réelle."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "archives",
|
||||
"title": "Images téléchargées et espace hôte",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "L’archive OCI sert à construire le rootfs ; le CT en cours d’exécution ne la lit pas. Après une installation ou une mise à jour, les archives téléchargées pendant cette opération sont listées avec leur taille et leur suppression est proposée. Les supprimer libère de l’espace sans affecter le conteneur ni ses données."
|
||||
},
|
||||
{
|
||||
"calloutInfo": {
|
||||
"title": "Les mises à jour ne nécessitent pas l'archive",
|
||||
"body": "Sans l'archive, une mise à jour résout le canal enregistré et télécharge le nouveau digest. Avec elle, une archive n'est réutilisée que lorsque sa référence et son intégrité correspondent à ce qui est demandé."
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "registry",
|
||||
"title": "Registre et nettoyage",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "À l'ouverture de <strong>Gérer les applications OCI installées</strong>, les restes des conteneurs absents de tous les nœuds du cluster sont d'abord supprimés : l'enregistrement conservé comme historique après une suppression depuis l'interface Proxmox, et les fichiers de l'hôte laissés par une suppression. Un enregistrement lié à une opération interrompue est conservé, car sa sauvegarde peut encore être nécessaire. Les volumes et répertoires de l'hôte ne sont jamais supprimés par déduction."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "cluster",
|
||||
"title": "Dans un cluster : migration et haute disponibilité",
|
||||
"intro": "Un conteneur OCI est un LXC Proxmox ordinaire : il peut être migré ou géré par HA comme les autres, avec les mêmes limites. Les éléments nécessaires à son démarrage sont conservés à un emplacement accessible à tous les nœuds du cluster.",
|
||||
"blocks": [
|
||||
{
|
||||
"table": {
|
||||
"headers": [
|
||||
"Partie",
|
||||
"Sur un autre noeud du cluster"
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"Journal de console",
|
||||
"Le conteneur crée <code>/var/log/proxmenux/oci</code> avant de démarrer, quel que soit le nœud qui l’exécute. Chaque nœud conserve le journal des démarrages qu’il a effectués."
|
||||
],
|
||||
[
|
||||
"Paramètres sysctl réseau et surveillance de l’hôte",
|
||||
"Conservés dans <code>/etc/pve/proxmenux</code>, partagé par tous les nœuds du cluster, afin qu’un conteneur migré les retrouve."
|
||||
],
|
||||
[
|
||||
"Disques du conteneur",
|
||||
"Proxmox les déplace avec le conteneur. HA nécessite que leurs données soient disponibles sur le nœud cible, via un stockage partagé ou une configuration de réplication prise en charge."
|
||||
],
|
||||
[
|
||||
"Répertoires et périphériques de l'hôte",
|
||||
"Les mêmes règles que n'importe quel LXC : un répertoire hôte doit exister sur le nœud cible et être marqué comme partagé, et un GPU, Coral ou NPU doit y être présent."
|
||||
],
|
||||
[
|
||||
"Enregistrement ProxMenux",
|
||||
"Le contrat reste sur le nœud où l'application a été installée, et chaque nœud lit la copie conservée dans <code>/etc/pve/priv/proxmenux/oci</code>. Une application à un seul conteneur est enregistrée sur son nœud de destination après migration lors de l'ouverture de <strong>Gérer les applications OCI installées</strong> ou du lancement d'une opération la concernant. Une application à plusieurs conteneurs y est proposée à la récupération, car son réseau privé doit être créé sur ce nœud."
|
||||
]
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"calloutWarning": {
|
||||
"title": "Pas pour une disponibilité élevée",
|
||||
"body": "Une application à plusieurs conteneurs relie ses membres par un pont privé du nœud sur lequel elle a été installée ; ses membres restent donc sur ce nœud. Un outil de surveillance de l’hôte, comme Glances en mode hôte ou Netdata, surveille le nœud qui l’exécute ; le déplacer reviendrait à surveiller un autre nœud."
|
||||
}
|
||||
},
|
||||
{
|
||||
"p": "Une sauvegarde restaurée à l'extérieur du cluster obtient les fichiers de <code>/etc/pve/proxmenux</code> que le conteneur utilise lorsque l'application est récupérée."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "channel",
|
||||
"title": "Une étiquette évolutive n’est pas une mise à jour sans surveillance",
|
||||
"blocks": [
|
||||
{
|
||||
"p": "Le catalogue installe l’étiquette évolutive publiée par son responsable, mais le digest effectif est résolu et enregistré, puis modifié uniquement lors d’une mise à jour explicite avec contrôles préalables et retour arrière. <monitorLink>ProxMenux Monitor</monitorLink> compare le digest installé à celui publié par le registre et affiche une indication et une notification lorsqu’une nouvelle image est disponible."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user