"p1":"La pestaña <strong>Actualizaciones</strong> separa la detección de versiones de la acción que instala una actualización. El registro y el seguimiento opcional viven en la <link>pestaña App</link>; los métodos ejecutables se gestionan aquí.",
"p2":"Una aplicación guardada aparece en Actualizaciones aunque solo contenga un enlace web. El seguimiento de versiones es opcional y el actualizador se puede configurar de forma independiente.",
"callout":"Registrar una aplicación no selecciona su actualizador. Si se detecta un actualizador de Helper-Scripts correspondiente a esa app, elige y guarda <strong>Helper-Scripts</strong> o <strong>Comando personalizado</strong>. Detectarlo no garantiza su compatibilidad. La elección pertenece a cada aplicación, aunque varias compartan un LXC."
"lead":"La vía integrada de Proxmox VE Helper-Scripts sigue el mecanismo oficial <helper>update-apps</helper>. El resto de instalaciones usa el método de paquetes, Docker o el comando personalizado correspondiente.",
"officialReference":"Referencia oficial: la <helper>documentación de update-apps de Proxmox VE Helper-Scripts</helper> explica los modos interactivo y desatendido, las copias de seguridad, la simulación, los recursos temporales de compilación, los registros y los códigos de salida.",
"notes":"Tras seleccionar expresamente Helper-Scripts, ejecuta el script oficial de la aplicación identificado mediante el wrapper /usr/bin/update validado. Un marcador o una coincidencia del catálogo no habilitan la ejecución."
"callout":"El comando personalizado <strong>reemplaza</strong> a Helper-Scripts para esa aplicación. Las ejecuciones manuales, en bloque y programadas respetan la elección guardada. Se conservan los comandos existentes y las selecciones antiguas guardadas en planes o programaciones activadas; una programación antigua nunca activa el actualizador de una app recién registrada."
"lead":"Después de registrar Docker en la pestaña App, el motor y el inventario de imágenes aparecen dentro de la misma sección <strong>Docker</strong>.",
"items":[
"El seguimiento de Docker Engine es independiente del contador de paquetes del SO y dispone de su propio botón de actualización.",
"Las imágenes locales con etiqueta se comparan con el registro mediante un digest inmutable. <strong>Comprobar ahora</strong> actualiza el inventario sin descargar imágenes ni reiniciar contenedores.",
"Los servicios Compose se actualizan desde el proyecto declarado. Las imágenes de un mismo grupo se procesan juntas para no recrear repetidamente el proyecto.",
"Un contenedor independiente se recrea con su configuración actual. El flujo protegido conserva datos de reversión y restaura el contenedor anterior si falla la recreación.",
"Cada imagen se puede seleccionar por separado en actualizaciones manuales, en bloque y programadas, salvo las dependencias Compose declaradas que deben acompañar a su servicio principal."
],
"callout":"Los contenedores que se ejecutan dentro de Docker no aparecen como aplicaciones LXC independientes. Sus puertos web publicados se pueden guardar como enlaces de Docker; las actualizaciones de imágenes permanecen en la sección Docker."
"<strong>Configurar</strong> abre el selector cuando no hay un método elegido; <strong>Editar</strong> permite cambiar una elección guardada. Los botones de información explican cada opción, enlazan la documentación oficial y muestran un ejemplo de script personalizado. Seleccionar una opción no la ejecuta.",
"Si el seguimiento de versiones está desactivado pero existe un actualizador, aparece la acción neutra <strong>Ejecutar actualizador</strong>. ProxMenux no afirma que exista una actualización pendiente.",
"Sin un actualizador de Helper-Scripts disponible, se puede configurar un comando personalizado. Desactivar un método no selecciona otro silenciosamente; los planes y las programaciones conservan sus selecciones y se informa de los objetivos no disponibles.",
"heading":"Comandos de actualización personalizados",
"lead":"El comando personalizado cubre instalaciones sin un actualizador integrado verificado y permite reemplazar el procedimiento normal cuando sea necesario.",
"Abre <strong>Configurar</strong> cuando el campo está vacío o <strong>Editar</strong> cuando ya existe un método.",
"En una app integrada o en Docker Engine, el editor muestra el comando utilizado actualmente. Al guardar otro contenido pasa a ser la sustitución explícita de ese registro.",
"El procedimiento completo debe probarse antes en el terminal del LXC. Debe ser no interactivo, usar el directorio correcto y devolver un código distinto de cero cuando falle.",
"No incluyas <code>pct exec</code>; ProxMenux ya entra en el contenedor y ejecuta el comando como root."
"exampleLead":"Ejemplo de procedimiento completo dentro del contenedor:",
"example":"cd /opt/mi-app && ./update.sh",
"callout":"Un comando de versión como <code>miapp --version</code> solo lee una versión; no instala nada. Los comandos se ejecutan con privilegios administrativos y deben revisarse con el mismo cuidado que un comando de shell como root."
"lead":"La actualización en bloque crea una acción reutilizable para un conjunto exacto de objetivos del LXC. Aparece después de las secciones de apps y Docker y antes de <strong>Opciones</strong>.",
"items":[
"Los paquetes del SO son obligatorios. Debe seleccionarse al menos una app, Docker Engine o unidad de imagen Docker adicional.",
"Las aplicaciones y unidades Docker se seleccionan individualmente. Un servicio principal de Compose muestra las dependencias que se actualizarán con él.",
"Los objetivos eliminados o no disponibles se marcan como obsoletos y deben retirarse antes de guardar la configuración.",
"El botón <strong>Aplicar actualizaciones</strong> es morado si algún objetivo seleccionado tiene una actualización verificada, verde si todos están verificados como actualizados y neutro cuando el resultado es desconocido.",
"Eliminar la configuración en bloque no borra los métodos individuales ni la programación."
"lead":"Las mismas opciones se aplican a ejecuciones manuales, en bloque y programadas:",
"items":[
"<strong>Instantánea antes de aplicar</strong> crea una copia vzdump en el almacenamiento seleccionado. Si la copia solicitada falla, la actualización no comienza.",
"<strong>Reiniciar después de aplicar</strong> reinicia el LXC únicamente tras una ejecución correcta.",
"Las selecciones se guardan por LXC y son independientes de la lista de objetivos."
"lead":"La programación usa los mismos objetivos ejecutables y opciones de seguridad que las acciones manuales.",
"items":[
"Selecciona una frecuencia o expresión cron y después objetivos exactos: paquetes del SO, apps individuales, Docker Engine, unidades Docker independientes o grupos de servicios Compose.",
"La espera tras una versión solo se aplica a las apps seleccionadas con seguimiento. Las apps sin seguimiento ejecutan su actualizador cuando vence la programación.",
"El estado de la última ejecución diferencia entre éxito, finalización parcial, error, retención de seguridad y ausencia de elementos pendientes. Después de la primera ejecución programada, <strong>Actualizaciones → Actualizaciones programadas → Ver log</strong> abre la salida completa capturada del actualizador y de los scripts secundarios que haya ejecutado.",
"Después de cada ejecución, ProxMenux comprueba el marcador estándar de Debian que indica si es necesario reiniciar. Cuando hace falta, la pestaña Actualizaciones y la notificación de finalización lo indican; el aviso se elimina cuando ese LXC se inicia o reinicia.",
"En el host Proxmox, los logs de las ejecuciones programadas se guardan en <code>/usr/local/share/proxmenux/logs/lxc-updates/</code> con el nombre <code><VMID>-scheduled-<id-de-ejecución>.log</code>. Se conservan los diez últimos logs de cada LXC y los archivos más antiguos se eliminan automáticamente.",
"Este historial corresponde a las actualizaciones programadas. Una actualización manual muestra su salida en tiempo real en la ventana de ejecución del Monitor y no crea un log de ejecución programada en ese directorio.",
"Las ejecuciones programadas conservan la salida del terminal e indican si todavía es necesario reiniciar para terminar de aplicar los cambios de los paquetes.",
"La caché del LXC se reemplaza con el estado verificado tras la actualización para que insignias y botones no conserven el resultado anterior.",
"Si arranca un LXC parado o restaurado, el evento de ciclo de vida existente vuelve a actualizar ese LXC. El inventario Docker espera a que el daemon esté disponible en lugar de guardar como definitivo un resultado vacío del arranque.",
"Las notificaciones activadas se emiten desde la ejecución finalizada e incluyen fallos parciales y resultados agrupados de imágenes Docker."
"problem":"No se ha identificado un método de actualización",
"resolution":"Abre Configurar, añade el procedimiento oficial no interactivo y pruébalo manualmente antes de programarlo."
},
{
"problem":"Aparece la identidad de Proxmox VE Helper-Scripts, pero no existe una acción",
"resolution":"El LXC conserva datos de identificación antiguos, pero no tiene un wrapper /usr/bin/update verificado. Añade un método solo después de confirmar el procedimiento correcto."
},
{
"problem":"Las imágenes Docker aparecen vacías temporalmente después de arrancar o restaurar",
"resolution":"Espera a que Docker esté disponible o pulsa Comprobar ahora. El inventario reintenta el arranque y no considera definitivo un resultado vacío transitorio."
},
{
"problem":"Un objetivo guardado en bloque ya no está disponible",
"resolution":"Edita la configuración, elimina el objetivo obsoleto y selecciona su sustituto actual si existe."
},
{
"problem":"Falla un comando personalizado",
"resolution":"Ejecútalo en el terminal del LXC y revisa la ruta, las dependencias, los parámetros no interactivos y el código de salida."
"problem":"Una actualización programada indica que es necesario reiniciar",
"resolution":"Abre <strong>Ver log</strong> para revisar la ejecución completada y reinicia ese LXC. ProxMenux elimina el aviso mediante el evento de ciclo de vida existente cuando el contenedor vuelve a arrancar."
