diff --git a/ROADMAP.es.md b/ROADMAP.es.md deleted file mode 100644 index 84e87b73..00000000 --- a/ROADMAP.es.md +++ /dev/null @@ -1,196 +0,0 @@ -# ProxMenux logo 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) | -|---|---| -| Fases ProxMenux Monitor | Fases ProxMenux | -| *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**. diff --git a/ROADMAP.md b/ROADMAP.md index 8d484e25..7452dc7c 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,272 +1,17 @@ # ProxMenux logo 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) | -|---|---| -| ProxMenux Monitor phases | ProxMenux phases | -| *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.