Mirrors/ProxMenux
1
0
Fork 0
mirror of https://github.com/MacRimi/ProxMenux.git synced 2026-07-26 18:38:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

update 1.2.4

Browse Source
This commit is contained in:
MacRimi
2026-07-21 18:47:19 +02:00
parent fd951f134c
commit 2330179036
4 changed files with 43 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
web/data/changelog/es.md
View File

@@ -53,12 +53,13 @@ Esta versión suma dos mejoras visibles en el propio dashboard — un botón par
---
## 🛡 Flujo de actualización — El prompt de update de ProxMenux ahora conoce la terminal del Monitor
## 🛡 Flujo de actualización — Monitor-terminal-aware para el update y para el cambio de canal
- **La terminal WebSocket del Monitor expone ahora `PROXMENUX_TERMINAL=monitor`** en el entorno de cada shell que abre, y cada proceso hijo lo hereda. Esto le da a `menu` (y a cualquier cosa que le importe) una vía fiable y determinista para saber que la sesión actual vive dentro del proceso del Monitor — una sesión que quedaría cortada a mitad de instalación si el servicio del Monitor se reiniciara.
- **Cuando `menu` arranca y detecta que hay una nueva versión de ProxMenux Y la sesión corre dentro de la terminal del Monitor, el clásico prompt yes/no de update se sustituye por un msgbox informativo.** El msgbox nombra la nueva versión y muestra el comando de una línea para ejecutar el update desde SSH o la consola del host Proxmox. Como el flow ya ha decidido que el path de update in-terminal es inseguro, hay un solo botón OK — no hay yes/no que pudiera disparar el update destructivo por accidente.
- **Tras pulsar OK, `menu` continúa con normalidad.** El operador sigue usando ProxMenux desde la misma terminal sin restricciones; solo el update en sí queda enrutado a otro sitio. No hay bloqueo ni acción forzada.
- **Las sesiones SSH, la consola del host Proxmox y cualquier entorno donde `PROXMENUX_TERMINAL` no sea `monitor` mantienen el prompt yes/no anterior** y pueden actualizar como siempre. El cambio solo afecta al caso en el que actualizar en el sitio rompería la sesión activa.
- **La terminal WebSocket del Monitor expone ahora `PROXMENUX_TERMINAL=monitor`** en el entorno de cada shell que abre, y cada proceso hijo lo hereda. Esto le da a `menu` (y a cualquier otro flow que le importe) una vía fiable y determinista para saber que la sesión actual vive dentro del proceso del Monitor — una sesión que quedaría cortada a mitad de instalación si el servicio del Monitor se reiniciara.
- **Prompt de update de `menu`** — cuando hay una nueva versión de ProxMenux disponible y la sesión corre dentro de la terminal del Monitor, el clásico prompt yes/no se sustituye por un msgbox informativo. El msgbox nombra la nueva versión y muestra el comando canónico de una línea (`bash -c "$(wget -qLO - …)"`) para ejecutar el update desde SSH o la consola del host Proxmox. Como el flow ya ha decidido que el path in-terminal es inseguro, hay un solo botón OK — no hay yes/no que pudiera disparar el update destructivo por accidente.
- **Ajustes → Canal de release** — el mismo guard se aplica en `apply_release_channel()` de `config_menu.sh`. Seleccionar Stable ↔ Beta desde la terminal del Monitor muestra un msgbox informativo con el comando `wget` exacto para el canal destino (usando la misma URL que el flow habría descargado por su cuenta) y vuelve al menú en lugar de ejecutar el installer en el sitio.
- **Tras pulsar OK, ambos flows continúan con normalidad.** El operador sigue usando ProxMenux desde la misma terminal sin restricciones; solo el paso destructivo queda enrutado a otro sitio. No hay bloqueo ni acción forzada.
- **Las sesiones SSH, la consola del host Proxmox y cualquier entorno donde `PROXMENUX_TERMINAL` no sea `monitor` mantienen el comportamiento anterior** y pueden actualizar o cambiar de canal como siempre. El cambio solo afecta al caso en el que hacerlo en el sitio rompería la sesión activa.
- **Nota de bootstrap**: como `PROXMENUX_TERMINAL=monitor` lo añade el AppImage que ship-ea esta release, el guard solo empieza a proteger sesiones una vez que el host está en 1.2.4 o posterior. La primera actualización a 1.2.4, si se dispara desde la terminal del Monitor, aún puede caer en el comportamiento antiguo — a partir de 1.2.4 el guard queda en su sitio.
---