diff --git a/web/app/[locale]/docs/monitor/architecture/page.tsx b/web/app/[locale]/docs/monitor/architecture/page.tsx index 1002abe5..7a6aa18d 100644 --- a/web/app/[locale]/docs/monitor/architecture/page.tsx +++ b/web/app/[locale]/docs/monitor/architecture/page.tsx @@ -165,13 +165,13 @@ export default async function MonitorArchitecturePage({ "`} - name: "ProxMenux Monitor Update" unique_id: proxmenux_monitor_update value_template: > - {{ 'update available' if (value_json.stable or value_json.beta) else 'up to date' }} + {{ 'update available' if (value_json.update_available.stable or value_json.update_available.beta) else 'up to date' }} + json_attributes_path: "$.update_available" json_attributes: - stable - stable_version diff --git a/web/messages/en/docs/monitor/access-auth.json b/web/messages/en/docs/monitor/access-auth.json index a610df40..ce9f1106 100644 --- a/web/messages/en/docs/monitor/access-auth.json +++ b/web/messages/en/docs/monitor/access-auth.json @@ -18,7 +18,7 @@ }, "reaching": { "heading": "Reaching the dashboard", - "intro": "ProxMenux Monitor binds to 0.0.0.0:8008. There are three common ways to reach it:", + "intro": "ProxMenux Monitor listens on TCP 8008 on all interfaces (::, IPv4 and IPv6). There are three common ways to reach it:", "outro": "Direct access matches the default systemd unit. Reverse-proxy and Secure Gateway access are described below. Trust for client IPs in X-Forwarded-For requires PROXMENUX_TRUST_PROXY=1 and a proxy you control. The presence of X-Forwarded-Proto or X-Forwarded-Host alone does not enable proxy trust. On ports 80/443 the frontend uses relative /api/* URLs; on any other port it calls port 8008 on the same host name." }, "firstLaunch": { @@ -158,7 +158,7 @@ "authJsonTitle": "auth.json — what it contains and how it's protected", "authJsonBody": "Everything ProxMenux Monitor needs to authenticate you lives in a single file: /root/.config/proxmenux-monitor/auth.json, mode 0600, owner root. The file holds hashes (PBKDF2) and signing material (jwt_secret, totp_secret) — never a plaintext password. Treat it like any other root-only secret: if you back up or replicate the host, encrypt the destination, and never commit it to version control.", "rotateTitle": "Rotating jwt_secret invalidates all existing JWTs", - "rotateBody": "If auth.json is regenerated (manual delete, reinstall, restore from a backup with a different secret) the jwt_secret changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI flags affected API tokens with an Invalid — regenerate badge so the user knows to revoke and re-mint them; Home Assistant / scripts / any external client needs a fresh token after that.", + "rotateBody": "If auth.json is regenerated (manual delete, reinstall, restore from a backup with a different secret) the jwt_secret changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI marks affected API tokens in red, with a badge telling you to revoke them and generate new ones; Home Assistant / scripts / any external client needs a fresh token after that.", "recoverTitle": "Recovering a lost password", "recoverIntro": "There is no online \"forgot password\" flow — by design, since the dashboard runs on the user's own host and the recovery path is shell access to that host. ProxMenux ships a guided reset inside the configuration menu so you don't have to hand-edit auth.json:", "survivesTitle": "What survives the reset", @@ -288,10 +288,10 @@ "generateTitle": "Generate a token", "generateIntro": "From the dashboard:", "generateSteps": [ - "Navigate to the Security tab → API Access Tokens section.", + "Navigate to the Security tab → API Tokens section.", "Type a descriptive name (e.g. \"Home Assistant\").", "Re-enter your password. If 2FA is on, also the current 6-digit code.", - "Click Generate Token. The token appears once — copy it immediately." + "Click Generate new token, then Generate token. The token appears once — copy it immediately." ], "generateCli": "From the command line:", "useTitle": "Use a token", diff --git a/web/messages/en/docs/monitor/ai-assistant.json b/web/messages/en/docs/monitor/ai-assistant.json index 1412d29d..ecfb04b2 100644 --- a/web/messages/en/docs/monitor/ai-assistant.json +++ b/web/messages/en/docs/monitor/ai-assistant.json @@ -118,7 +118,7 @@ "imageCaption": "The in-app modal — six cards, one per provider, with the same descriptions documented below.", "groq": { "heading": "Groq", - "tagline": "Very fast, generous free tier (30 req/min). Ideal to start.", + "tagline": "Very fast, with a generous free tier. A good place to start.", "items": [ "API key: console.groq.com/keys", "Examples from the bundled model list: allam-2-7b, qwen/qwen3.8-27b, openai/gpt-oss-20b, openai/gpt-oss-120b.", @@ -165,7 +165,7 @@ }, "ollama": { "heading": "Ollama (Local)", - "tagline": "Uses models exposed by your configured Ollama server. Local models execute there; Ollama cloud models forward requests to a cloud provider. Local execution avoids a hosted API charge but still uses your hardware and electricity.", + "tagline": "Uses models on your Ollama server. Fully local, private and free to run.", "items": [ "No API key. Set the Ollama URL field to your server (default http://localhost:11434 or whatever host runs your Ollama instance).", "Models: not filtered. The Monitor reads whichever models you have pulled on the Ollama side via ollama pull <model>. The dropdown is populated from GET /api/tags on your Ollama server.", @@ -234,7 +234,7 @@ }, "detailLevel": { "heading": "Detail level per channel", - "intro": "Each of the four channels (Telegram, Discord, Gotify, Email) has its own detail-level dropdown. Three values are available, mapped to specific output token caps and to specific instructions in the default prompt:", + "intro": "Each of the six channels (Telegram, Discord, Gotify, Email, Pushover, Apprise) has its own detail-level dropdown. Three values are available, mapped to specific output token caps and to specific instructions in the default prompt:", "headerLevel": "Level", "headerLabel": "UI label", "headerCap": "Output cap", @@ -261,7 +261,7 @@ ], "defaultsIntro": "Defaults the Monitor applies on first install:", "defaults": [ - "Telegram, Discord, Gotify — standard.", + "Telegram, Discord, Gotify, Pushover, Apprise — standard.", "Email — detailed. Email is the channel where you typically want the full picture for archival." ], "emailTitle": "Email detail level appends the original", diff --git a/web/messages/en/docs/monitor/api-reference.json b/web/messages/en/docs/monitor/api-reference.json index eb5e3ff4..e2c180ab 100644 --- a/web/messages/en/docs/monitor/api-reference.json +++ b/web/messages/en/docs/monitor/api-reference.json @@ -76,7 +76,7 @@ { "endpoint": "/api/system-info", "method": "GET", - "use": "Extended system snapshot used by the dashboard header (overall metrics + boot time)." + "use": "Lightweight header info: hostname, uptime and cached health status. Public, no token needed." }, { "endpoint": "/api/hardware", @@ -401,7 +401,7 @@ { "endpoint": "/api/logs", "method": "GET", - "use": "Filtered journal entries. Query: ?level=&service=&limit=." + "use": "Filtered journal entries. Query: ?priority=&service=&limit=&since_days= (priority 0-7, since_days up to 90)." }, { "endpoint": "/api/logs/download", @@ -411,7 +411,7 @@ { "endpoint": "/api/events", "method": "GET", - "use": "Internal event stream — the same one that feeds notifications." + "use": "Recent Proxmox cluster tasks and events from pvesh get /cluster/tasks. Query: ?limit= (default 50)." }, { "endpoint": "/api/task-log/", @@ -462,7 +462,7 @@ { "endpoint": "/api/notifications/send", "method": "POST", - "use": "Emit a custom event. Body: '{'\"event_type\":\"custom\",\"severity\":\"WARNING\",\"title\":\"...\",\"body\":\"...\",\"data\":'{''}''}'." + "use": "Emit a custom event. Body: '{'\"event_type\":\"custom\",\"severity\":\"WARNING\",\"title\":\"...\",\"message\":\"...\",\"data\":'{''}''}'." }, { "endpoint": "/api/notifications/test-ai", diff --git a/web/messages/en/docs/monitor/architecture.json b/web/messages/en/docs/monitor/architecture.json index d8415fa6..36c75d1e 100644 --- a/web/messages/en/docs/monitor/architecture.json +++ b/web/messages/en/docs/monitor/architecture.json @@ -64,7 +64,7 @@ "items": [ "User=root — the supported service runs with root privileges for host operations such as SMART access, pvesh and ZFS management. Its web-terminal processes inherit those privileges.", "Restart=on-failure with a 10-second back-off — non-zero exits relaunch automatically.", - "After=network.target — orders startup after that target; it does not guarantee an assigned IP, DNS or external connectivity." + "After=network.target pve-cluster.service: orders startup after the network target and the Proxmox cluster filesystem; it does not guarantee an assigned IP, DNS or external connectivity." ], "inspectTitle": "Inspect the live unit" }, diff --git a/web/messages/en/docs/monitor/dashboard/hardware.json b/web/messages/en/docs/monitor/dashboard/hardware.json index e47b2bb7..b61f7c63 100644 --- a/web/messages/en/docs/monitor/dashboard/hardware.json +++ b/web/messages/en/docs/monitor/dashboard/hardware.json @@ -168,7 +168,7 @@ "ups": { "heading": "UPS Status", "subHeading": "(conditional)", - "body": "Renders when a NUT (Network UPS Tools) server is configured and reachable. Shows: state (online / on battery / charging / low battery), battery charge percentage, runtime estimate, load percentage, input voltage, model and firmware. The same data feeds the Security & Certificates category of the Health Monitor — a UPS that goes on-battery surfaces immediately." + "body": "Renders when a NUT (Network UPS Tools) server is configured and reachable. Shows: state (online / on battery / charging / low battery), battery charge percentage, runtime estimate, load percentage, input voltage, model and firmware." }, "dataCollected": { "heading": "How the data is collected", diff --git a/web/messages/en/docs/monitor/dashboard/index.json b/web/messages/en/docs/monitor/dashboard/index.json index c0bbdbd2..be2a5c9a 100644 --- a/web/messages/en/docs/monitor/dashboard/index.json +++ b/web/messages/en/docs/monitor/dashboard/index.json @@ -50,7 +50,7 @@ }, { "name": "Terminal", - "owns": "Browser shell to host or to any VM/CT, powered by xterm.js over WebSockets." + "owns": "Browser shell on the Proxmox host, powered by xterm.js over WebSockets. LXC consoles open from the VMs & LXCs tab." }, { "name": "Security", diff --git a/web/messages/en/docs/monitor/dashboard/settings.json b/web/messages/en/docs/monitor/dashboard/settings.json index 9d10a0ce..d63054aa 100644 --- a/web/messages/en/docs/monitor/dashboard/settings.json +++ b/web/messages/en/docs/monitor/dashboard/settings.json @@ -41,7 +41,7 @@ "heading": "Network Units", "imageAlt": "Network Units card with Network Unit Display dropdown set to Bytes", "imageCaption": "Choose between bits per second and bytes per second for every network rate displayed in the dashboard.", - "body": "Choose how network throughput is displayed across the dashboard: bits per second (Mbps / Gbps) or bytes per second (MB/s / GB/s). Bits is the default because it's what NIC vendors and ISPs label their products with; bytes is what most file-transfer tools report. The setting affects every chart, badge and tooltip that shows network rate — applied immediately, no reload needed." + "body": "Choose how network throughput is displayed across the dashboard: bits per second (Mbps / Gbps) or bytes per second (MB/s / GB/s). Bytes is the default, as most file-transfer tools report; bits is what NIC vendors and ISPs label their products with. The choice is stored in the browser, so each browser keeps its own. The setting affects every chart, badge and tooltip that shows network rate — applied immediately, no reload needed." }, "health": { "heading": "Health Monitor", @@ -203,7 +203,7 @@ "heading": "LXC Update Detection", "imageAlt": "LXC Update Detection card with a single switch — when enabled, the Monitor periodically scans running Debian/Ubuntu/Alpine LXC containers for pending package updates.", "imageCaption": "The toggle for the periodic apt list --upgradable / apk list -u scan across every running CT. Default is ON. The matching notification toggle in Notifications → Services only appears while detection is enabled.", - "intro": "A dedicated toggle for the LXC update scan, sitting between the Health Monitor Thresholds and the Notifications card. When ON, ProxMenux walks every running CT on the host and queries the in-container package manager for pending updates; results land in the Hardware tab badge counts and feed the lxc_updates_available notification. When OFF, the scan stops entirely (no pct exec calls) and any existing LXC entries in managed_installs.json are purged immediately, so the dashboard and the /api/managed-installs endpoint stop reporting LXC update state without waiting for the next 24h cycle.", + "intro": "A dedicated toggle for the LXC update scan, sitting between the Health Monitor Thresholds and the Notifications card. When ON, ProxMenux walks every running CT on the host and queries the in-container package manager for pending updates; results land in the VMs & LXCs tab badge counts and feed the lxc_updates_available notification. When OFF, the scan stops entirely (no pct exec calls) and any existing LXC entries in managed_installs.json are purged immediately, so the dashboard and the /api/managed-installs endpoint stop reporting LXC update state without waiting for the next 24h cycle.", "whatRunsTitle": "What the scan actually runs", "whatRunsIntro": "For each CT in running state with a supported package manager:", "whatRunsItems": [ @@ -249,7 +249,7 @@ "body1": "This section of the Settings tab is where ProxMenux Monitor notifications and the AI rewriter are turned on. Pressing Enable Notifications starts the dispatch background thread, registers a Proxmox VE webhook target on the host so PVE-emitted events flow into the same pipeline, and unfolds the channel form so you can connect Telegram, Discord, Email, Gotify and the rest. The AI rewriter sits inside the same panel as a collapsible advanced section.", "body2": "Both surfaces have a lot of moving parts — channels, per-event toggles, Rich messages, the Display Name, the dispatch pipeline (dedup, cooldown, aggregation, quiet hours), the PVE webhook integration, AI providers, prompt modes — and live on their own dedicated pages rather than being repeated here:", "items": [ - "Notifications — channel walk-throughs (Telegram, Discord, Gotify, Email + Gmail / Microsoft app passwords, ntfy, Slack, Teams, generic webhook), per-event categories, Rich messages, Display Name, dispatch pipeline, PVE webhook integration, history and API.", + "Notifications — channel walk-throughs (Telegram, Discord, Gotify, Email + Gmail / Microsoft app passwords, Pushover, and Apprise for ntfy, Slack, Teams and other services), per-event categories, Rich messages, Display Name, dispatch pipeline, PVE webhook integration, history and API.", "AI Assistant — providers (OpenAI, Anthropic, Gemini, Groq, OpenRouter, Ollama), model selection, prompt modes (default / custom), output language, per-channel detail levels and AI suggestions." ] }, @@ -294,8 +294,8 @@ }, { "card": "Network Units", - "endpoint": "/api/settings", - "source": "Persisted in the dashboard's SQLite settings table." + "endpoint": "localStorage", + "source": "Browser preference proxmenux-network-unit." }, { "card": "Health Monitor durations", diff --git a/web/messages/en/docs/monitor/dashboard/storage.json b/web/messages/en/docs/monitor/dashboard/storage.json index 4675b60a..51943536 100644 --- a/web/messages/en/docs/monitor/dashboard/storage.json +++ b/web/messages/en/docs/monitor/dashboard/storage.json @@ -10,7 +10,7 @@ }, "intro": { "title": "Backed by three sources", - "body": "Proxmox storages come from pvesm status; ZFS state from zpool status; physical disks from lsblk + smartctl (and nvme for NVMe-specific fields). The tab refreshes every ~60 seconds; the per-disk drill-in triggers a fresh SMART read on demand." + "body": "Proxmox storages come from pvesm status; ZFS state from zpool status; physical disks from lsblk + smartctl (and nvme for NVMe-specific fields). The tab refreshes every ~30 seconds; the per-disk drill-in triggers a fresh SMART read on demand." }, "thresholds": { "title": "Status colours and thresholds applied here", diff --git a/web/messages/en/docs/monitor/dashboard/system-logs.json b/web/messages/en/docs/monitor/dashboard/system-logs.json index 98b15096..29812109 100644 --- a/web/messages/en/docs/monitor/dashboard/system-logs.json +++ b/web/messages/en/docs/monitor/dashboard/system-logs.json @@ -18,7 +18,7 @@ "Total Entries — number of log records inside the active filter window.", "Errors — count of severity ≤ 3 (err / crit / alert / emerg).", "Warnings — count of severity 4 (warning).", - "Backups — count of vzdump / PBS task entries in the same window." + "Backups: number of backup archives on the configured backup storages." ] }, "subtabs": { @@ -26,10 +26,10 @@ "logsTitle": "Logs", "logsIntro": "The system journal, served by journalctl on the backend. Filters available in the toolbar:", "logsFilters": [ - "Severity — emerg / alert / crit / err / warning / notice / info / debug, or any combination.", - "Time range — last 5 min / 15 min / 1 h / 6 h / 24 h / 7 d / custom.", - "Free-text search — substring or regex (journalctl --grep).", - "Unit filter — restrict to a specific systemd unit (pveproxy.service, nginx.service, …)." + "Level: all, error, warning or info.", + "Time range: 1 day / 3 days / 1 week / 2 weeks / 1 month, or a custom number of days (up to 90).", + "Free-text search: case-insensitive substring over message, service, PID, hostname and unit, applied in the browser.", + "Service filter: restrict to one service (the journal SYSLOG_IDENTIFIER)." ], "logsRowsAfter": "Each row shows timestamp, severity badge, source unit and the message. Long messages collapse with a \"show more\" toggle. The Download action bundles the current filter into a single .txt file via GET /api/logs/download — useful when you want to share a slice of journal with someone.", "logDetailsModalTitle": "Log Details modal", @@ -50,10 +50,10 @@ "maxLevelStoreTitle": "Journald MaxLevelStore", "maxLevelStoreBody": "On a fresh Proxmox install, journald defaults to MaxLevelStore=warning, which silently drops info-level messages. The Monitor detects this on startup and adds a drop-in (/etc/systemd/journald.conf.d/proxmenux-loglevel.conf) raising the threshold to info so informational and more severe messages are stored. This does not include debug messages.", "backupsTitle": "Backups", - "backupsBody": "Proxmox task history filtered to backup-related entries. One row per task (vzdump, PBS transfers, Garbage Collect, Verify) with the status (OK / WARNINGS / ERROR), guest involved, source storage, duration and the UPID. Click a row to load the full task log via GET /api/task-log/<upid> — the same data Proxmox exposes through Datacenter → Tasks, scoped to backups.", + "backupsBody": "The backup archives on every backup-capable storage (dir, NFS, CIFS, PBS), read with pvesh get /nodes/localhost/storage/<id>/content. Cards at the top show the VM and LXC counts and the total size; below, one row per archive with type, storage, size and date. Restore lives in the Proxmox web UI.", "notificationsTitle": "Notifications", - "notificationsBody1": "Every notification dispatched by the Monitor — Telegram, Discord, Email, Gotify, ntfy, Slack, Teams, webhook. Each row: timestamp, channel, event type, severity, the rendered title, the rendered body, and (if AI is enabled) a toggle to view the AI rewrite next to the original.", - "notificationsBody2": "Use this tab to verify a channel is actually delivering and to compare what the AI rewrite produced vs the template baseline. Channel configuration lives in the Notifications deep page." + "notificationsBody1": "Proxmox notification activity: journal lines from Proxmox services that mention notifications, email, webhooks or alerts, the targets in /etc/pve/notifications.cfg, and backup tasks from the cluster task list. Backup task rows can download the full task log. The history of what the Monitor itself dispatched lives in Settings → Notifications → Notification history.", + "notificationsBody2": "Use this tab to check what Proxmox's own notification system is doing. Monitor channel configuration lives in the Notifications deep page." }, "dataCollected": { "heading": "How the data is collected", @@ -64,7 +64,7 @@ { "subtab": "Logs (live filter)", "endpoint": "/api/logs", - "source": "journalctl --output json --since <range> with severity / unit / search filters applied server-side." + "source": "journalctl with priority, service and day-range filters applied server-side; text search runs in the browser." }, { "subtab": "Download", @@ -74,17 +74,17 @@ { "subtab": "Backups", "endpoint": "/api/backups", - "source": "PVE task history filtered by vzdump, PBS transfers, Garbage Collect, Verify." + "source": "Backup archives listed from each backup storage with pvesh get /nodes/localhost/storage/<id>/content." }, { - "subtab": "Backup task drill-in", + "subtab": "Backup task log (Notifications)", "endpoint": "/api/task-log/<upid>", "source": "Plain-text full task log read from /var/log/pve/tasks/<index>/<upid>." }, { - "subtab": "Notifications history", - "endpoint": "/api/notifications/history", - "source": "SQLite notification_history table fed by the dispatch loop." + "subtab": "Notifications", + "endpoint": "/api/notifications", + "source": "journalctl --grep over Proxmox units, /etc/pve/notifications.cfg and backup tasks from pvesh get /cluster/tasks." } ], "apiIntro": "Both the live filter and the downloads are also reachable via the API:", diff --git a/web/messages/en/docs/monitor/dashboard/system-overview.json b/web/messages/en/docs/monitor/dashboard/system-overview.json index 98fc5884..c5c45a02 100644 --- a/web/messages/en/docs/monitor/dashboard/system-overview.json +++ b/web/messages/en/docs/monitor/dashboard/system-overview.json @@ -46,7 +46,7 @@ "thresholdsIntro": "Every ring, bar, and sparkline on the four metric cards follows the same classification — green below Warning, amber from Warning to Critical, red at Critical and above. Recommended defaults shipped with ProxMenux:", "thresholdsItems": [ "CPU usage — Warning 85 %, Critical 95 %.", - "Memory — Warning 85 %, Critical 95 % (Swap also fires Critical at 5 % used — a healthy Proxmox host should rarely touch swap).", + "Memory: Warning 85 %, Critical 95 %. Swap fires Critical only when swap use is above 80 % and available RAM is below 15 %.", "CPU temperature — Warning 80 °C, Critical 90 °C." ], "thresholdsOutro": "Every value is configurable per host — Settings → Health Monitor Thresholds is the single source of truth and explains how to tune them.", @@ -58,7 +58,7 @@ "intro": "The CPU Usage and Memory cards on the Overview tab are clickable. Clicking either opens a sortable list of the top 25 processes — ordered by CPU usage when opened from the CPU card, by resident memory when opened from the Memory card.", "listTitle": "The list dialog", "listItems": [ - "Auto-refresh — the list updates every 5 seconds while the dialog is open and stops polling as soon as it closes.", + "Auto-refresh — the list updates every 3 seconds while the dialog is open and stops polling as soon as it closes.", "Filter — the search box narrows the list by command, user or PID.", "Inline bar — the primary metric column draws a small bar scaled to the highest value in the filtered list, so ranking stays visible even when no process is near 100 %.", "Mobile layout — under 640 px the PID and User columns hide so Command, CPU % and Memory still fit on a phone screen without horizontal scroll." @@ -79,7 +79,7 @@ }, "middle": { "heading": "Middle: node metrics charts", - "body1": "Below the top row sits the NodeMetricsCharts component — historical CPU, memory and disk-I/O graphs sourced from Proxmox's own RRD store via /api/node/metrics. A timeframe selector switches between 1 hour / 24 hours / 7 days / 30 days / 1 year; data resolution drops as the window grows so the chart stays smooth.", + "body1": "Below the top row sits the NodeMetricsCharts component — historical CPU, memory and disk-I/O graphs sourced from Proxmox's own RRD store via /api/node/metrics. A timeframe selector switches between 1 hour / 24 hours / 7 days / 30 days; data resolution drops as the window grows so the chart stays smooth.", "body2": "These are the same graphs that the Proxmox web UI renders for a node, just consolidated into the Monitor's dark theme and aligned with the other panels." }, "bottom": { diff --git a/web/messages/en/docs/monitor/dashboard/vms-lxcs.json b/web/messages/en/docs/monitor/dashboard/vms-lxcs.json index b258a399..4cb0e36e 100644 --- a/web/messages/en/docs/monitor/dashboard/vms-lxcs.json +++ b/web/messages/en/docs/monitor/dashboard/vms-lxcs.json @@ -117,7 +117,7 @@ "Destination tag — the storage where it lives (PBS-Cloud, PBS-Local, NFS-Backup, …) coloured by status.", "Size — final on-disk size of the backup." ], - "backupsOutro": "The + Create Backup button at the top right kicks off a new run on the storage marked as \"Backup target\" in the Proxmox storage config. Restore lives in the Proxmox web UI — the Monitor exposes the \"is this guest backed up recently?\" view, not the recovery flow.", + "backupsOutro": "The + Create Backup button at the top right opens a dialog to choose the storage, mode (snapshot / suspend / stop), protection and notes before starting a vzdump. Restore lives in the Proxmox web UI — the Monitor exposes the \"is this guest backed up recently?\" view, not the recovery flow.", "firewallTitle": "Tab 7 — Firewall", "firewallIntro": "Reads the per-guest Proxmox firewall log straight from the host (no extra service, no polling). The tab is always present in the navigation strip; the panel decides what to render depending on whether the firewall is enabled for that guest and whether any rule is actually logging:", "firewallItems": [ diff --git a/web/messages/en/docs/monitor/health-monitor.json b/web/messages/en/docs/monitor/health-monitor.json index c4c3c725..8a338e0d 100644 --- a/web/messages/en/docs/monitor/health-monitor.json +++ b/web/messages/en/docs/monitor/health-monitor.json @@ -153,8 +153,8 @@ "pillTitle": "The pill mirrors the worst category", "pillBody": "The dashboard header colour is the highest severity across the ten categories: any CRITICAL → red, else any WARNING → yellow, else any INFO → blue, else green. The same logic drives the favicon dot and the PWA badge.", "updateNowTitle": "Update Now button in the Overview header", - "updateNowBody1": "When the System Updates category reports one or more pending updates, the Overview header renders an Update Now button next to the health pill. The button opens a modal that runs the same host-side flow as ProxMenux → Settings post-install Proxmox → Proxmox System Update: repo hygiene, apt full-upgrade via the safe worker update-pve-safe.sh, automatic DKMS rebuild of ProxMenux-managed drivers when a new kernel lands, autoremove / autoclean and a reboot prompt if the kernel changed. Progress lines stream in the modal as the worker prints them.", - "updateNowBody2": "When the run finishes, closing the modal calls GET /api/health/details?refresh=1, which invalidates the health-endpoint cache before serving. The pending-updates row and the pill severity are recomputed from the new package state on the spot, so the badge disappears without waiting for the next five-minute cycle. When the host is already up to date, the button is hidden — no visual noise on a healthy system." + "updateNowBody1": "When the System Updates category reports one or more pending updates, the Overview header renders an Update Now button next to the health pill. The button opens a modal that runs the same host-side flow as ProxMenux → Utilities and Tools → Proxmox System Update: repo hygiene, apt full-upgrade via the safe worker update-pve-safe.sh, automatic DKMS rebuild of ProxMenux-managed drivers when a new kernel lands, autoremove / autoclean and a reboot prompt if the kernel changed. Progress lines stream in the modal as the worker prints them.", + "updateNowBody2": "When the run finishes, closing the modal calls GET /api/health/full?refresh=1, which invalidates the health-endpoint cache before serving. The pending-updates row and the pill severity are recomputed from the new package state on the spot, so the badge disappears without waiting for the next five-minute cycle. When the host is already up to date, the button is hidden — no visual noise on a healthy system." }, "dismiss": { "heading": "Dismissing alerts and the Suppression Duration", diff --git a/web/messages/en/docs/monitor/index.json b/web/messages/en/docs/monitor/index.json index a2635a76..347bf877 100644 --- a/web/messages/en/docs/monitor/index.json +++ b/web/messages/en/docs/monitor/index.json @@ -119,7 +119,7 @@ }, "serviceControl": { "heading": "Service control", - "intro": "Day-to-day, the Monitor is managed exactly like any other systemd service. It is also exposed as two entries inside the ProxMenux TUI under Settings:", + "intro": "Day-to-day, the Monitor is managed exactly like any other systemd service. It is also exposed as three entries inside the ProxMenux TUI under Settings:", "codeComment": "# Manual control", "footer": "See Settings → ProxMenux Monitor for the in-menu toggle and status verification flow." },