Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-09-14 10:47:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

update ROADMAP.md

Browse Source 
The document now points to the ProxMenux Roadmap project on GitHub, where per-item status, ownership and descriptions live. The previous version-milestone plan (v1.2.2-beta / v1.2.3-beta / v1.3.0) is retired in favour of pillar-based tracking on the board.

ROADMAP.es.md removed — it mirrored the same outdated content and the public docs site keeps the Spanish surface for users who need it.
This commit is contained in:
MacRimi
2026-08-10 11:59:47 +02:00
parent 7b2d9a3268
commit 2901b22be6
2 changed files with 9 additions and 460 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ROADMAP.es.md
-196
View File
@@ -1,196 +0,0 @@
# <img src="https://raw.githubusercontent.com/MacRimi/ProxMenux/main/images/logo.png" alt="ProxMenux logo" width="40"/> ProxMenux — Roadmap
> Última actualización: **2026-05-20** · Versión actual: **1.2.1.2-beta**
> 🇬🇧 English version: [ROADMAP.md](ROADMAP.md)
Este documento es la hoja de ruta para llevar ProxMenux y
ProxMenux Monitor a un estado **listo para producción**. Está basado
en las dos infografías que un colaborador preparó y enriquecido con
una auditoría real del código actual.
## 🖼️ Infografías de origen
Las dos infografías son obra de
**[@pitiriguisvi](https://github.com/pitiriguisvi)** y resumen
visualmente las dos grandes áreas de trabajo — gracias por dedicarle
el tiempo:
| ProxMenux Monitor (Dashboard) | ProxMenux (Scripts) |
|---|---|
| <img src="images/proxmenux_phases_1.png" alt="Fases ProxMenux Monitor" width="380"/> | <img src="images/proxmenux_phases_2.png" alt="Fases ProxMenux" width="380"/> |
| *Mejoras recomendadas para hacerlo más seguro, útil y apto para producción* | *Mejoras recomendadas para hacerlo más seguro, auditable y apto para producción* |
**¿Qué se muestra?:**
* La tabla **Estado actual** refleja lo que YA existe hoy.
* El **Plan por versión** marca qué entra en cada release.
* La sección **Cambios publicados** se va rellenando a medida que
se cierren items, con la versión en la que se entregó.
Símbolos:
* 🟢 — Hecho y en producción
* 🟡 — Parcial (existe la base, falta UI o feature completa)
* 🔴 — Pendiente
---
## 🎯 Visión
> *"La prioridad no es añadir más métricas ni más scripts, sino mejorar
> seguridad, alertas, permisos, auditabilidad e integración real con
> Proxmox."*
ProxMenux ya es una herramienta para gestionar los nodos. El siguiente salto es convertirlo en una
herramienta **apta para entornos de producción y para clientes**:
* El operador tiene que poder dar **acceso de solo lectura** a
terceros sin miedo a que toquen nada.
* Tiene que existir un **historial auditable** de qué pasó y quién
lo hizo.
* Los cambios destructivos tienen que poder **previsualizarse y
revertirse**.
* La instalación tiene que poder operarse en **modo conservador**
cuando el nodo no es un laboratorio.
---
## 📊 Estado actual
### ProxMenux Monitor (Dashboard)
#### 1️⃣ Modo solo lectura
| Item | Estado | Notas |
|---|---|---|
| Separar monitorizar de controlar | 🔴 | El dashboard mezcla ambos hoy |
| Dashboard 100 % read-only | 🟡 | El scope `read_only` existe en los API tokens, falta exponerlo al usuario web |
| Sin acciones de start/stop por defecto | 🔴 | Requiere lo anterior |
| Ideal para clientes y producción | 🔴 | Llega cuando el modo solo lectura esté completo |
#### 2️⃣ Permisos y tokens
| Item | Estado | Notas |
|---|---|---|
| Roles viewer / operator / admin | 🔴 | Single-user hoy |
| Tokens con scopes | 🟡 | 2 scopes (`read_only`, `full_admin`), no granulares |
| Caducidad configurable | 🟡 | Hoy fija en 365 días |
| Tokens de solo lectura para NA / homepage | 🟢 | Cubierto por `scope=read_only` |
#### 3️⃣ Seguridad web
| Item | Estado | Notas |
|---|---|---|
| Bind a localhost o LAN | 🔴 | El backend escucha en `0.0.0.0:8008` |
| HTTPS y proxy inverso guiado | 🟢 | Documentado, ACME + self-signed CA trust |
| Allowlist IP opcional | 🔴 | No existe |
| Rate limits y bloqueo anti-fuerza bruta | 🟡 | Hay cooldown en login; no es un panel configurable. Fail2Ban es opcional |
#### 4️⃣ Logs y auditoría
| Item | Estado | Notas |
|---|---|---|
| Registrar login, logout e intentos fallidos | 🟡 | Se notifica `auth_fail`; no hay panel histórico |
| Guardar IP, usuario y token usado | 🟡 | Llega a notificación, no se persiste para auditar |
| Auditar accesos sobre VM/LXC | 🔴 | Las acciones de control no se registran |
| Historial claro con resultado y error | 🔴 | No hay pestaña "Audit" |
#### 5️⃣ Alertas útiles
| Item | Estado | Notas |
|---|---|---|
| CPU, RAM, disco y temperatura altos | 🟢 | Health Monitor + thresholds configurables |
| Snapshot / backup confirmado | 🟢 | Eventos `vzdump_complete` |
| SMART warnings y predicción | 🟢 | `disk_failure_predicted` + tiers de `disk_io_error` (1.2.1.2) |
| Telegram, Gotify, ntfy, email, webhook | 🟢 | 7 canales activos |
#### 6️⃣ PBS y cluster
| Item | Estado | Notas |
|---|---|---|
| Último backup por VM/LXC | 🔴 | No se muestra en ningún sitio; tampoco hay integración con PBS para listar/consultar backups |
| VMs sin backup y jobs fallidos | 🟡 | Detección **pasiva** de líneas `vzdump .* finished` en syslog (notificación), pero **no hay vista** de "VMs sin job de backup" ni integración con la API de jobs de PVE |
| Quorum, nodos, estado global | 🟡 | Detección **pasiva** de `quorum lost` / `split brain` en syslog. **No hay** panel de cluster ni consulta activa a la API (`pvecm status`, `/cluster/status`) |
| Dashboard de salud del entorno | 🔴 | El Health tab es del **nodo local**. No existe vista multi-nodo del cluster |
---
### ProxMenux (Scripts y Post-install)
#### 1️⃣ Seguridad operativa
| Item | Estado | Notas |
|---|---|---|
| Dry-run / previsualización antes de aplicar | 🔴 | No existe como flag general |
| Avisos delante de cambios críticos | 🟡 | Algunos diálogos, no uniforme |
| Verificación posterior de la acción | 🟡 | `update_component_status` registra el resultado |
| Confirmación reforzada en tareas sensibles | 🟡 | Hay `whiptail --yesno` en algunos scripts; no es regla |
#### 2️⃣ Rollback y recuperación
| Item | Estado | Notas |
|---|---|---|
| Restaurar última configuración válida | 🟢 | Sistema `backup_restore/` completo (host backup + `apply_pending_restore`) |
| Menú de recuperación antes de fallos | 🟡 | Existe el restore manual, falta un wizard preventivo |
| Revertir red / postinstall / grupos | 🟡 | El backup snapshotea, no hay rollback granular por subsistema |
| Empaquetado para diagnóstico (`bug-report`) | 🔴 | No existe el bundle |
#### 3️⃣ Scripts externos
| Item | Estado | Notas |
|---|---|---|
| Listas, hashes y firma | 🔴 | Se ejecutan sin verificación |
| Fijar versión / commit / hash | 🔴 | Helper-scripts traídos en vivo del upstream |
| Etiquetar nivel de riesgo | 🟡 | El menú nuevo añadió "richer context"; falta etiqueta formal |
| Mostrar script antes de ejecutarlo | 🔴 | Sin paso de preview |
#### 4️⃣ Logs y trazabilidad
| Item | Estado | Notas |
|---|---|---|
| Registrar acción, usuario y fecha | 🟡 | Logs en `/var/log/proxmenux/`, no estructurados |
| Guardar comandos y archivos modificados | 🔴 | No hay tracking de qué tocó cada script |
| Errores claros con código de salida | 🟡 | Algunos scripts sí; no es regla |
| Historial de cambios reciente | 🔴 | No hay UI "qué hizo ProxMenux en este host" |
#### 5️⃣ Modo producción
| Item | Estado | Notas |
|---|---|---|
| Perfil conservador para todo el nodo | 🔴 | El concepto no existe |
| Bloquear acciones destructivas por defecto | 🔴 | Tampoco |
| Limitar cambios de red sin confirmación | 🟡 | Algunos scripts piden confirmación |
| Más validaciones y avisos | 🟡 | Mejoras incrementales, no como modo |
#### 6️⃣ Entornos reales
| Item | Estado | Notas |
|---|---|---|
| Salida tipo "esto pasó" clara y multilingüe | 🟡 | `translate()` + `msg_*` funcionan; falta resumen final |
| Visibilidad de quorum / almacenamiento | 🔴 | El Monitor lo muestra, pero los **scripts** no inspeccionan ni reportan el estado de quorum/almacenamiento antes de actuar |
| Postinstall Proxmox Backup Server | 🔴 | No existe un script de instalación/configuración de PBS (sí existe el `Proxmox_Backup_Client.AppImage` que es el cliente, no el servidor) |
| Detector de fallos rápido para escenarios | 🟡 | Health Monitor; falta "preflight" antes de cada cambio |
---
## 📦 Cambios publicados
> Esta sección se actualiza con cada release.
> Aquí se anota qué pasó de pendiente (🔴 / 🟡) a hecho (🟢)
> y en qué versión.
| Fecha | Versión | Item | Notas |
|---|---|---|---|
| — | — | — | Aún no hay items cerrados de este roadmap |
---
## 🙏 Agradecimientos
* **[@pitiriguisvi](https://github.com/pitiriguisvi)** — autor de las
dos infografías originales sobre las que se construye este roadmap.
---
## 💬 Cómo aportar
Cualquier persona puede:
* Comentar en el item que considere prioritario o que falte.
* Proponer un nuevo item con el formato de la tabla
(categoría + descripción + por qué importa).
* Sugerir mover items entre versiones si el orden no encaja con
su uso real.
El roadmap es vivo y se reordena. La única regla es: **los items
solo cambian de estado 🔴/🟡 → 🟢 cuando hay código que los respalda
en una release publicada**.
ROADMAP.md
+9 -264
View File
@@ -1,272 +1,17 @@
# <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)
The roadmap is a live board on GitHub, not a fixed document.
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.
→ [**ProxMenux Roadmap project**](https://github.com/users/MacRimi/projects/1)
## 🖼️ Source infographics
Every item is tracked there with its current status, priority and — where already claimed — the person working on it.
The two infographics that seeded this roadmap are the work of
**[@pitiriguisvi](https://github.com/pitiriguisvi)** and summarise
the two main areas of work visually — thank you for the time and
for giving us such a clear starting point:
## Contributing an item
| 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* |
1. Pick something from the board that has no owner yet.
2. Announce the intent in [Contributor Coordination](https://github.com/MacRimi/ProxMenux/discussions/categories/contributor-coordination) so nobody duplicates the work.
3. Open the PR when it is ready.
**How we use this document:**
## Suggesting a new item
* 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 | 🔴 | Not shown anywhere; no PBS integration to list/query backups either |
| VMs with no backup and failed jobs | 🟡 | **Passive** syslog detection of `vzdump .* finished` (notification only); **no view** of "VMs without a backup job" and no PVE jobs-API integration |
| Quorum, nodes, global state | 🟡 | **Passive** syslog detection of `quorum lost` / `split brain`. **No** cluster panel and no active API queries (`pvecm status`, `/cluster/status`) |
| Environment health dashboard | 🔴 | The Health tab is **local-node only**. No multi-node cluster view exists |
---
### 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 | 🔴 | The Monitor shows it, but the **scripts** don't inspect or report quorum/storage state before acting |
| Proxmox Backup Server post-install | 🔴 | No PBS install/configuration script (the `Proxmox_Backup_Client.AppImage` is the client, not the server) |
| 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 |
---
## 🙏 Acknowledgements
* **[@pitiriguisvi](https://github.com/pitiriguisvi)** — author of the
two original infographics this roadmap is built on.
---
## 💬 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**.
Open a new topic in the same Discussions category. If it fits the direction of the project, it moves onto the board from there.