update 1.2.4

CHANGELOG.md

@@ -54,12 +54,13 @@ This release adds two in-dashboard improvements — a one-click Proxmox update t
 
 ---
 
-## 🛡 Update flow — ProxMenux update prompt is now Monitor-terminal-aware
+## 🛡 Update flow — Monitor-terminal-aware for update and channel switch
 
-- **The Monitor's WebSocket terminal now exposes `PROXMENUX_TERMINAL=monitor`** in the environment of every shell it opens, and every child inherits it. This gives `menu` (and anything else that cares) a reliable, deterministic way to tell that the current session lives inside the Monitor process — a session that would be cut mid-install if the Monitor service was restarted.
-- **When `menu` starts and detects that a new ProxMenux version is available AND the session is running inside the Monitor terminal, the classic yes/no update prompt is replaced by an informational msgbox.** The msgbox names the new version and shows the one-line command to run the update from SSH or the Proxmox host console. Because the flow has already decided the in-terminal update path is unsafe (see the [msgbox-ack rule](memory/feedback_whiptail_msgbox_ack.md)), there's a single OK button — no yes/no that could trigger the destructive update by accident.
-- **After OK, `menu` continues normally**. The operator keeps using ProxMenux from the same terminal without restrictions; only the update itself is routed elsewhere. There is no lockdown and no forced action.
-- **SSH sessions, the Proxmox host console, and any environment where `PROXMENUX_TERMINAL` isn't `monitor` keep the previous yes/no prompt** and can update as always. The change only affects the case where updating in place would break the running session.
+- **The Monitor's WebSocket terminal now exposes `PROXMENUX_TERMINAL=monitor`** in the environment of every shell it opens, and every child inherits it. This gives `menu` (and any other flow that cares) a reliable, deterministic way to tell that the current session lives inside the Monitor process — a session that would be cut mid-install if the Monitor service was restarted.
+- **`menu` update prompt** — when a new ProxMenux version is available and the session is running inside the Monitor terminal, the classic yes/no update prompt is replaced by an informational msgbox. The msgbox names the new version and shows the canonical one-liner (`bash -c "$(wget -qLO - …)"`) to run the update from SSH or the Proxmox host console. Because the flow has already decided the in-terminal update path is unsafe (see the [msgbox-ack rule](memory/feedback_whiptail_msgbox_ack.md)), there's a single OK button — no yes/no that could trigger the destructive update by accident.
+- **Settings → Release Channel** — the same guard is applied in `config_menu.sh`'s `apply_release_channel()`. Selecting Stable ↔ Beta from the Monitor terminal shows an informational msgbox with the exact `wget` one-liner for the target channel (using the same URL the flow would have downloaded itself) and returns to the menu instead of running the installer in place.
+- **After OK, both flows continue normally**. The operator keeps using ProxMenux from the same terminal without restrictions; only the destructive step is routed elsewhere. There is no lockdown and no forced action.
+- **SSH sessions, the Proxmox host console, and any environment where `PROXMENUX_TERMINAL` isn't `monitor` keep the previous behaviour** and can update or switch channels as always. The change only affects the case where doing it in place would break the running session.
 - **Bootstrap note**: because `PROXMENUX_TERMINAL=monitor` is added by the AppImage this release ships, the guard only starts protecting sessions once the host is on 1.2.4 or newer. The very first update to 1.2.4, if triggered from the Monitor terminal, can still hit the old behaviour — from 1.2.4 forward the guard is in place.
 
 ---

menu

@@ -160,7 +160,7 @@ $(translate 'This session is running in the Monitor terminal. Updating from here
 
 $(translate 'Run the update from an SSH session or the Proxmox host console with:')
 
-  bash <(curl -fsSL ${INSTALL_URL}) --update
+  bash -c \"\$(wget -qLO - ${INSTALL_URL})\"
 
 $(translate 'You can keep using ProxMenux from this terminal.')"
         whiptail --title "$PROMPT_TITLE" --msgbox "$WS_INFO" 20 78
@@ -206,7 +206,7 @@ This session is running in the Monitor terminal. Updating from here would restar
 
 Run the update from an SSH session or the Proxmox host console with:
 
-  bash <(curl -fsSL $REPO_DEVELOP/install_proxmenux_beta.sh) --update
+  bash -c \"\$(wget -qLO - $REPO_DEVELOP/install_proxmenux_beta.sh)\"
 
 You can keep using ProxMenux from this terminal." 20 78
         return 0

scripts/menus/config_menu.sh

@@ -243,9 +243,37 @@ EOF
 
 apply_release_channel() {
     local target_channel="$1"
-    local current_channel installer_file installer_status
+    local current_channel installer_file installer_status installer_url
 
     current_channel=$(get_release_channel)
+
+    if [ "$target_channel" = "beta" ]; then
+        installer_url="$BETA_INSTALLER_URL"
+    else
+        installer_url="$STABLE_INSTALLER_URL"
+    fi
+
+    # Running inside the Monitor's WebSocket terminal: the installer stops
+    # the Monitor service, which kills this shell mid-install and leaves
+    # the channel switch broken. Inform and route to SSH / host console.
+    if [[ "${PROXMENUX_TERMINAL:-}" == "monitor" ]]; then
+        show_proxmenux_logo
+        msg_title "$(translate "Changing Release Channel")"
+        whiptail --title "$(translate "Release Channel")" --msgbox "\
+$(translate "Switching to") $(release_channel_label "$target_channel") $(translate "requires running the official installer, which restarts the Monitor service.")
+
+$(translate "This session is running in the Monitor terminal. Running it from here would cut the connection mid-install and leave the switch in a broken state.")
+
+$(translate "Run the release-channel switch from an SSH session or the Proxmox host console with:")
+
+  bash -c \"\$(wget -qLO - ${installer_url})\"
+
+$(translate "You can keep using ProxMenux from this terminal.")" 22 78
+        msg_success "$(translate "Press Enter to return to menu...")"
+        read -r
+        exec bash "$LOCAL_SCRIPTS/menus/config_menu.sh"
+    fi
+
     installer_file=$(mktemp /tmp/proxmenux-${target_channel}-installer.XXXXXX) || return 1
 
     show_proxmenux_logo

web/data/changelog/es.md

@@ -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.
 
 ---