mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-08-03 06:16:21 +00:00
Update 1.2.2.3 beta
This commit is contained in:
@@ -52,7 +52,7 @@
|
||||
"heading": "Cifrado del lado del cliente",
|
||||
"intro": "El cifrado por keyfile del lado del cliente de PBS cifra los chunks en el host de origen antes de la subida. ProxMenux habilita esta funcionalidad con una restricción añadida: la passphrase de recuperación es obligatoria cuando se activa el cifrado. La passphrase no protege el keyfile local; protege la copia de escrow del keyfile que ProxMenux sube a PBS para recuperación ante desastre.",
|
||||
"keyfileTitle": "Keyfile",
|
||||
"keyfileBody": "Tanto el wizard de la CLI como el modal Web del Monitor exponen la configuración de cifrado como una elección de tres opciones: <em>generar un keyfile nuevo</em>, <em>importar uno existente</em> u <em>omitir</em>. <em>Generar</em> ejecuta <code>proxmox-backup-client key create --kdf none</code> y escribe el keyfile en <code>/usr/local/share/proxmenux/pbs-key.conf</code> (<code>chmod 600</code>). <em>Importar</em> toma un keyfile que el usuario ya tiene (habitualmente el mismo que usa en sus otros hosts) y lo instala en la misma ruta tras validarlo con <code>proxmox-backup-client key info</code>. Las copias posteriores en el mismo host reutilizan cualquier keyfile instalado tras un único diálogo de confirmación. Si algún paso falla, la copia se cancela y la salida de error de la herramienta se muestra en un diálogo.",
|
||||
"keyfileBody": "El diálogo de cifrado sigue un flujo yes/no en dos pasos. El primer paso pregunta si se desea cifrar el backup: <em>No</em> continúa sin cifrado; <em>Yes</em> pasa al segundo paso. El segundo paso depende de si ya hay un keyfile instalado en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si lo hay, se reutiliza silenciosamente y el backup continúa. Si no lo hay, aparece un menú de dos opciones: <em>Generate a new keyfile</em>, que ejecuta <code>proxmox-backup-client key create --kdf none</code>, o <em>Import an existing keyfile</em>, que toma una ruta indicada por el operador, la valida con <code>proxmox-backup-client key info</code> y la instala en la ruta canónica. Ambas ramas se ejecutan solo tras confirmar la passphrase de recuperación — cancelar cualquier diálogo antes de ese punto deja el disco intacto.",
|
||||
"modesTitle": "Keyfile por host o compartido",
|
||||
"modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.",
|
||||
"modesPerHostTitle": "Keyfile por host (por defecto)",
|
||||
@@ -60,7 +60,7 @@
|
||||
"modesSharedTitle": "Keyfile compartido (importar en cada host)",
|
||||
"modesSharedBody": "Un keyfile maestro generado una vez e instalado en cada host mediante la opción <em>Importar</em>. La gestión es más simple: un único secreto que proteger, un único blob de recuperación sirve para todos los hosts, y cualquier host puede desencriptar los archives de cualquier otro (útil para consolidación, simulacros de restore cruzado o verificación centralizada de backups). El trade-off es que una filtración del keyfile compartido expone todos los hosts a la vez. Recomendado para homelabs y para flotas donde todos los hosts tienen el mismo propietario y límite de confianza.",
|
||||
"recoveryTitle": "Passphrase de recuperación y blob de escrow",
|
||||
"recoveryBody": "Tras crear el keyfile, ProxMenux pregunta dos veces por una passphrase de recuperación (con validación de coincidencia) y ejecuta <code>openssl</code> para producir <code>pbs-key.recovery.enc</code> — el keyfile cifrado con la passphrase. Se escribe una copia en <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> para almacenamiento offsite. Cancelar el diálogo de la passphrase borra el keyfile recién creado.",
|
||||
"recoveryBody": "La passphrase de recuperación se solicita ANTES de escribir ningún keyfile en disco. ProxMenux la pide dos veces con validación de coincidencia; solo cuando el operador la confirma, se crea (o importa) el keyfile y <code>openssl</code> produce <code>pbs-key.recovery.enc</code> — el keyfile cifrado con la passphrase. Se escribe una copia en <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> como respaldo offsite. Cancelar el diálogo de la passphrase deja el disco intacto — no se crea ningún keyfile y no hay nada que limpiar.",
|
||||
"blobUploadTitle": "Grupo emparejado en PBS",
|
||||
"blobUploadBody1": "Tras una copia PBS que usó el keyfile, el blob de escrow se sube como un segundo grupo de copia: <code>host/hostcfg-HOSTNAME-keyrecovery/BACKUP-TIME</code>. El prefijo compartido <code>hostcfg-HOSTNAME</code> coloca ambos grupos adyacentes en la interfaz de PBS; el sufijo <code>-keyrecovery</code> etiqueta la relación. La subida se ejecuta sin <code>--keyfile</code> (el blob ya está protegido con passphrase por openssl) y sólo cuando la copia actual usó el keyfile.",
|
||||
"blobUploadConstraintTitle": "Por qué dos grupos",
|
||||
|
||||
@@ -143,6 +143,39 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"liveProgress": {
|
||||
"heading": "Progreso en vivo en la pestaña Backups del Monitor",
|
||||
"body": "Tras el reboot, la pestaña Backups del Monitor de ProxMenux muestra una tarjeta de progreso en vivo que refleja el estado de <code>apply_cluster_postboot.service</code> a medida que avanza. La tarjeta lee <code>/var/lib/proxmenux/restore-state.json</code>, que el dispatcher actualiza en cada hito (aplicar configuración del cluster, reconstruir initramfs, actualizar bootloader, reinstalación por componente, verificación de arranque, finalización).",
|
||||
"fields": [
|
||||
{
|
||||
"name": "Insignia de estado",
|
||||
"detail": "Una de estas tres: <em>Restauración en curso</em>, <em>Restauración completa</em> o <em>Restauración fallida</em>. Mientras se ejecuta, la tarjeta consulta el fichero de estado cada 2 segundos; una vez terminada, cada 30 segundos."
|
||||
},
|
||||
{
|
||||
"name": "Barra de progreso + contador de pasos",
|
||||
"detail": "Muestra <code>N/M steps</code> con la etiqueta del paso actual. Durante la ejecución se calcula un <em>tiempo estimado</em> restante a partir de los pasos completados y el tiempo transcurrido."
|
||||
},
|
||||
{
|
||||
"name": "Lista de componentes",
|
||||
"detail": "Una fila por cada driver reinstalado (NVIDIA, Intel GPU tools, AMD tools, Coral TPU) con estado <code>installing</code> / <code>ok</code> / <code>failed</code> y un enlace al log por componente en <code>/var/log/proxmenux/component-*.log</code>."
|
||||
},
|
||||
{
|
||||
"name": "Avisos de arranque",
|
||||
"detail": "El dispatcher verifica si falta <code>/lib/modules/<kernel></code>, si no hay ESP configurada y si hay un symlink <code>/vmlinuz</code> colgado. Cualquier aviso aparece aquí en un banner coloreado."
|
||||
},
|
||||
{
|
||||
"name": "Delta de rollback",
|
||||
"detail": "Lista VMs, LXCs y componentes que existen en el destino pero no estaban en el backup restaurado — las mismas entradas que aparecen en el diálogo de rollback destructivo pre-restore. Cada fila incluye el comando de limpieza manual."
|
||||
},
|
||||
{
|
||||
"name": "Tail del log",
|
||||
"detail": "Las últimas 600 líneas de <code>proxmenux-cluster-postboot-<ts>.log</code>, con un filtro <em>Issues only</em> que deja solo las líneas con <code>error</code>, <code>warning</code>, <code>failed</code>, <code>✗</code> o <code>traceback</code>."
|
||||
}
|
||||
],
|
||||
"dismissBody": "Cuando la restauración termina como <em>complete</em> o <em>failed</em>, el botón Dismiss colapsa la tarjeta. El fichero de estado se conserva y el botón History la reabre junto con cualquier restauración anterior (se archivan las últimas 20 en <code>/var/lib/proxmenux/restore-history/</code>).",
|
||||
"imageAlt": "Pestaña Backups del Monitor de ProxMenux mostrando la tarjeta de progreso en vivo con pasos, estado por componente y tail del log.",
|
||||
"imageCaption": "La tarjeta de la pestaña Backups mientras el post-boot dispatcher está en ejecución."
|
||||
},
|
||||
"postbootExample": {
|
||||
"heading": "Cómo se ve el post-boot en la consola",
|
||||
"body": "En la consola física del host la ejecución exitosa del dispatcher termina con una línea <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>. Cuando esa línea aparece — normalmente acompañada de los <code>OK</code> del <code>multi-user.target</code> y del <code>graphical.target</code> — la restauración ha terminado por completo: componentes reinstalados, boot artifacts regenerados, cluster reconciliado.",
|
||||
|
||||
Reference in New Issue
Block a user