mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-05-22 00:24:48 +00:00
Add Roadmap
This commit is contained in:
MacRimi
+263
@@ -0,0 +1,263 @@
|
||||
# <img src="https://raw.githubusercontent.com/MacRimi/ProxMenux/main/images/logo.png" alt="ProxMenux logo" width="40"/> ProxMenux — Roadmap
|
||||
|
||||
> Last update: **2026-05-20** · Current version: **1.2.1.2-beta**
|
||||
> 🇪🇸 Versión en español: [ROADMAP.es.md](ROADMAP.es.md)
|
||||
|
||||
This document is our roadmap to bring ProxMenux and ProxMenux Monitor
|
||||
to a **production-ready** state. It is based on the two infographics
|
||||
a community member prepared, enriched with a real audit of the
|
||||
current codebase.
|
||||
|
||||
## 🖼️ Source infographics
|
||||
|
||||
The two infographics that seeded this roadmap are a community
|
||||
contribution and summarise the two main areas of work visually:
|
||||
|
||||
| ProxMenux Monitor (Dashboard) | ProxMenux (Scripts) |
|
||||
|---|---|
|
||||
| <img src="images/proxmenux_phases_1.png" alt="ProxMenux Monitor phases" width="380"/> | <img src="images/proxmenux_phases_2.png" alt="ProxMenux phases" width="380"/> |
|
||||
| *Recommended improvements to make it safer, more useful, and production-ready* | *Recommended improvements to make it safer, auditable, and production-ready* |
|
||||
|
||||
**How we use this document:**
|
||||
|
||||
* The **Current state** table reflects what we already have today.
|
||||
* The **Plan by version** marks what goes into each release.
|
||||
* The **Shipped changes** section gets filled in as we close items,
|
||||
with the version they shipped in.
|
||||
|
||||
Symbols:
|
||||
|
||||
* 🟢 — Done and in production
|
||||
* 🟡 — Partial (foundation exists, UI or full feature missing)
|
||||
* 🔴 — Pending
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Vision
|
||||
|
||||
> *"The priority is not to add more metrics or more scripts, but to
|
||||
> improve security, alerting, permissions, auditability and real
|
||||
> integration with Proxmox."*
|
||||
|
||||
ProxMenux is already a powerful tool for sysadmins running their own
|
||||
node. The next leap is making it a tool **fit for production
|
||||
environments and customers**:
|
||||
|
||||
* The operator must be able to give **read-only access** to third
|
||||
parties without worrying that they will touch anything.
|
||||
* There must be an **auditable history** of what happened and who
|
||||
did it.
|
||||
* Destructive changes must be **previewable and revertible**.
|
||||
* The install must be operable in **conservative mode** when the
|
||||
node is not a lab.
|
||||
|
||||
---
|
||||
|
||||
## 📊 Current state
|
||||
|
||||
### ProxMenux Monitor (Dashboard)
|
||||
|
||||
#### 1️⃣ Read-only mode
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Separate monitoring from control | 🔴 | The dashboard mixes both today |
|
||||
| 100 % read-only dashboard | 🟡 | The `read_only` scope exists for API tokens, but isn't exposed to the web user |
|
||||
| No start/stop actions by default | 🔴 | Depends on the above |
|
||||
| Ideal for clients and production | 🔴 | Lands when read-only mode is complete |
|
||||
|
||||
#### 2️⃣ Permissions and tokens
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| viewer / operator / admin roles | 🔴 | Single-user today |
|
||||
| Tokens with scopes | 🟡 | 2 scopes (`read_only`, `full_admin`), not granular |
|
||||
| Configurable expiry | 🟡 | Currently fixed at 365 days |
|
||||
| Read-only tokens for NA / homepage | 🟢 | Covered by `scope=read_only` |
|
||||
|
||||
#### 3️⃣ Web security
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Bind to localhost or LAN | 🔴 | Backend listens on `0.0.0.0:8008` |
|
||||
| HTTPS and guided reverse proxy | 🟢 | Documented, ACME + self-signed CA trust |
|
||||
| Optional IP allowlist | 🔴 | Does not exist |
|
||||
| Rate limits and brute-force blocking | 🟡 | Login cooldown exists; not a configurable panel. Fail2Ban is optional |
|
||||
|
||||
#### 4️⃣ Logs and auditing
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Log login, logout and failed attempts | 🟡 | `auth_fail` is notified; no historical panel |
|
||||
| Save IP, user and token used | 🟡 | Reaches the notification, not persisted for audit |
|
||||
| Audit access to VM/LXC | 🔴 | Control actions are not recorded |
|
||||
| Clear history with result and error | 🔴 | No "Audit" tab |
|
||||
|
||||
#### 5️⃣ Useful alerts
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| High CPU, RAM, disk and temperature | 🟢 | Health Monitor + configurable thresholds |
|
||||
| Snapshot / backup confirmed | 🟢 | `vzdump_complete` events |
|
||||
| SMART warnings and prediction | 🟢 | `disk_failure_predicted` + `disk_io_error` tiers (1.2.1.2) |
|
||||
| Telegram, Gotify, ntfy, email, webhook | 🟢 | 7 active channels |
|
||||
|
||||
#### 6️⃣ PBS and cluster
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Last backup per VM/LXC | 🟢 | Visible in the VM/CT modal |
|
||||
| VMs with no backup and failed jobs | 🟡 | `vzdump_failed` is notified; aggregated view missing |
|
||||
| Quorum, nodes, global state | 🟢 | Health tab + cluster events |
|
||||
| Environment health dashboard | 🟢 | Health tab |
|
||||
|
||||
---
|
||||
|
||||
### ProxMenux (Scripts and post-install)
|
||||
|
||||
#### 1️⃣ Operational safety
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Dry-run / preview before applying | 🔴 | No general flag |
|
||||
| Warnings before critical changes | 🟡 | Some dialogs, not uniform |
|
||||
| Post-action verification | 🟡 | `update_component_status` records the result |
|
||||
| Reinforced confirmation on sensitive tasks | 🟡 | `whiptail --yesno` in some scripts; not a rule |
|
||||
|
||||
#### 2️⃣ Rollback and recovery
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Restore last valid configuration | 🟢 | Full `backup_restore/` system (host backup + `apply_pending_restore`) |
|
||||
| Recovery menu before failures | 🟡 | Manual restore exists, no preventive wizard |
|
||||
| Revert network / post-install / groups | 🟡 | Backup snapshots, no granular per-subsystem rollback |
|
||||
| Diagnostic bundle (`bug-report`) | 🔴 | No bundle |
|
||||
|
||||
#### 3️⃣ External scripts
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Lists, hashes and signature | 🔴 | Run without verification |
|
||||
| Pin version / commit / hash | 🔴 | Helper-scripts pulled live from upstream |
|
||||
| Risk-level label | 🟡 | New menu added "richer context"; no formal label |
|
||||
| Show script before running it | 🔴 | No preview step |
|
||||
|
||||
#### 4️⃣ Logs and traceability
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Log action, user and date | 🟡 | Logs in `/var/log/proxmenux/`, not structured |
|
||||
| Save commands and modified files | 🔴 | No tracking of what each script touched |
|
||||
| Clear errors with exit code | 🟡 | Some scripts do; not a rule |
|
||||
| Recent-changes history | 🔴 | No "what ProxMenux did on this host" UI |
|
||||
|
||||
#### 5️⃣ Production mode
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Conservative profile for the whole node | 🔴 | Concept does not exist |
|
||||
| Block destructive actions by default | 🔴 | Same |
|
||||
| Limit network changes without confirmation | 🟡 | Some scripts ask for confirmation |
|
||||
| More validations and warnings | 🟡 | Incremental improvements, not as a mode |
|
||||
|
||||
#### 6️⃣ Real environments
|
||||
| Item | Status | Notes |
|
||||
|---|---|---|
|
||||
| Clear, multilingual "this happened" output | 🟡 | `translate()` + `msg_*` work; final summary missing |
|
||||
| Quorum / storage visibility | 🟢 | In the Monitor |
|
||||
| Proxmox Backup Server post-install | 🟢 | PBS script already in place |
|
||||
| Fast failure detector for scenarios | 🟡 | Health Monitor; no "preflight" before each change |
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ Plan by version
|
||||
|
||||
> Items are grouped by **value / effort** ratio, not strict order.
|
||||
> The plan can be reordered based on feedback from the group's
|
||||
> testers.
|
||||
|
||||
### v1.2.2-beta — *Cheap and high-impact*
|
||||
|
||||
Goal: close the gaps that already have a foundation in code and
|
||||
deliver visible security gains without touching architecture.
|
||||
|
||||
* [ ] **Read-only mode for the web user.** Bind the existing JWT
|
||||
`read_only` scope to the interactive session. The UI hides
|
||||
action buttons (start/stop, run scripts, terminal) when the
|
||||
scope is not `full_admin`.
|
||||
* [ ] **Audit log table + dashboard tab.** New SQLite table
|
||||
`audit_log(ts, user, ip, action, target, result, error)`.
|
||||
Hook into `flask_security_routes` and `flask_script_runner`.
|
||||
Render as a simple "Audit" tab.
|
||||
* [ ] **IP allowlist.** New field in `Settings → Security →
|
||||
"Limit access to these IPs"`. `@require_allowed_ip` decorator
|
||||
applied to all blueprints.
|
||||
* [ ] **Configurable API-token expiry.** `expires_at` field on the
|
||||
token metadata; honour it in `verify_token`.
|
||||
|
||||
### v1.2.3-beta — *Medium effort*
|
||||
|
||||
Goal: provide serious operational tools before applying changes.
|
||||
|
||||
* [ ] **Granular token scopes.** Minimum four: `read_only`,
|
||||
`vm_control`, `script_runner`, `full_admin`. The frontend
|
||||
shows which scopes the current token has.
|
||||
* [ ] **Dry-run for post-install scripts.** `--dry-run` flag
|
||||
supported across all `scripts/post_install/` scripts. Output
|
||||
shows exactly what would change without touching the host.
|
||||
* [ ] **Diagnostic bundle (`proxmenux bug-report`).** Tar.gz of
|
||||
`/var/log/proxmenux/`, `journalctl -u proxmenux-monitor`,
|
||||
`dmesg --since=24h`, `dpkg -l | grep -i proxmenux`,
|
||||
`managed_installs.json` and the `errors` / `disk_observations`
|
||||
tables. Tokens and secrets obfuscated in the output.
|
||||
* [ ] **Aggregated "VMs with no backup" view.** New card in the
|
||||
Backups tab listing every VM/CT without a recent backup job,
|
||||
with direct shortcuts to PBS.
|
||||
|
||||
### v1.3.0 — *Major scope*
|
||||
|
||||
Goal: the leap to production. Requires a major release due to data
|
||||
model and UX changes.
|
||||
|
||||
* [ ] **RBAC with viewer / operator / admin roles.** Multi-user,
|
||||
per-user password, per-session role. Migration from
|
||||
`auth.json` to a `users(id, username, password_hash, role,
|
||||
created_at, last_login)` table. Review every blueprint to map
|
||||
endpoints → minimum role.
|
||||
* [ ] **Production mode.** Global flag in `/etc/proxmenux/profile`
|
||||
that toggles:
|
||||
* Reinforced confirmations
|
||||
* More aggressive anti-cascade
|
||||
* Destructive actions hidden or disabled
|
||||
* IP allowlist forced non-empty
|
||||
* `full_admin` tokens disabled in favour of `vm_control` + ack
|
||||
* [ ] **Granular rollback per subsystem.** Building on the existing
|
||||
`backup_restore` infra, allow reverting only "Network", only
|
||||
"Post-install", only "Groups and permissions", etc.
|
||||
* [ ] **Change history visible in the Monitor.** "Changes" tab
|
||||
listing every modification ProxMenux made on the host
|
||||
(file, before / after, responsible script).
|
||||
|
||||
### Probably out of scope
|
||||
|
||||
* **Cryptographic signing of upstream scripts.** Depends on the
|
||||
community-scripts pipeline (we don't control it). Maintaining our
|
||||
own signed mirror would be high effort for limited benefit.
|
||||
Closed unless an external decision changes it.
|
||||
|
||||
---
|
||||
|
||||
## 📦 Shipped changes
|
||||
|
||||
> This section is updated with every release. Without touching the
|
||||
> plan above: here we note which items moved from pending (🔴 / 🟡)
|
||||
> to done (🟢) and in which version.
|
||||
|
||||
| Date | Version | Item | Notes |
|
||||
|---|---|---|---|
|
||||
| — | — | — | No items closed yet from this roadmap |
|
||||
|
||||
---
|
||||
|
||||
## 💬 How to contribute
|
||||
|
||||
Anyone in the group can:
|
||||
|
||||
* Comment on the item they consider a priority or notice missing.
|
||||
* Propose a new item using the table format
|
||||
(category + description + why it matters).
|
||||
* Suggest moving items between versions if the ordering doesn't
|
||||
match their real use.
|
||||
|
||||
The roadmap is alive and gets reordered. The only rule is:
|
||||
**items only change state 🔴/🟡 → 🟢 when there is code backing them
|
||||
in a published release**.
|
||||
Reference in New Issue
Block a user