chore(docs): Add P2601 Dashboard UI updates and bitacora records
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# Bitácora de Operaciones - 23/02/2026
|
||||
|
||||
## Control de Gestión
|
||||
|
||||
### 🚩 Pendientes
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| ➡️ - P02 - **Sistema DASUTEN** | srv-dasu | Despliegue e instalación del software del sistema DASUTEN en la VM.<br><br>➡️ **[Continúa en 24/02](2026-02-24.md)** |
|
||||
|
||||
### ⏳ En Proceso
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| [➡️ - A07 - **Sync dtic-BKPs**](#srv-ns8) | srv-ns8 | Sincronización limpia de backups de Proxmox para aplicar nombres de host.<br><br>➡️ **[Continúa en 24/02](2026-02-24.md#A07)** |
|
||||
| [➡️ - A05 - **VM Windows Server (Core)**](#srv-dasu) | srv-dasu | Creación y configuración de máquina virtual con Windows Server Core para rol AD DS.<br><br>➡️ **[Continúa en 24/02](2026-02-24.md#A05)** |
|
||||
|
||||
### 📝 Resumen de Actividades
|
||||
| NODO | RESUMEN INTEGRAL |
|
||||
| :--- | :--- |
|
||||
| [srv-ns8](#srv-ns8) | Diagnóstico y corrección del script de respaldos `dtic-BKPs_app.rb`. Se solucionaron dos fallas críticas documentadas en el hito A04: un bloqueo interactivo de SSH provocado por el comando rclone al listar/descargar archivos, y la omisión silenciosa de procesamiento de respaldos que carecían del archivo descriptor `.notes`. |
|
||||
| [srv-dasu](#srv-dasu) | Inicialización exitosa de la infraestructura base para la oficina DASUTEN. Se instaló un hypervisor Standalone Proxmox VE, se solventaron bloqueos físicos de red, se asignó ip estática (`10.0.10.205`) y se estableció acceso seguro desatendido vía llaves SSH desde el nodo central. Finalizado el relevamiento de hardware confirmando 4 Cores, 16GB RAM y Storage LVM de 480GB. |
|
||||
|
||||
---
|
||||
|
||||
## 📂 Actividades Detalladas
|
||||
|
||||
### srv-ns8
|
||||
| Tema | Hitos |
|
||||
| :--- | :--- |
|
||||
| ✅ - A06 - **Dashboard P2601** | 🚀 Despliegue del dashboard web para visualización de avance del proyecto DASUTEN (URL: `ns8.frlr.utn.edu.ar/P2601/`).<br><br>⏱️ **Cronología:**<br>- ✅ **20:53 hs**: Dashboard "Cyber-Luxury" interactivo con timeline desplegado exitosamente en Nginx.<br>- 👁️ **20:49 hs**: Aprobación de especificaciones de UI/UX (modo oscuro, timeline) e inicio de maquetación en Nginx. |
|
||||
| ➡️ - A07 - **Sync dtic-BKPs** | 🚀 Reinicio de la sincronización de resguardos (`dtic-BKPs_app.rb C1`) con la nueva política de nomenclatura basada en nombres de host para las carpetas contenedoras de Proxmox.<br><br>⏱️ **Cronología:**<br>- ✅ **23:35 hs**: Finalización exitosa del procesamiento local. 17 VMs respaldadas en carpetas con nombres de host reales.<br>- 🚀 **22:42 hs**: Despliegue del script limpiamente en el procesador de fondo (screen) tras purgado de carpetas genéricas previas.<br><br>➡️ **[Continúa en 24/02](2026-02-24.md#A07)** |
|
||||
| ✅ - A04 - **Análisis dtic-BKPs** | 🧪 Revisión y diagnóstico de la herramienta de respaldos (`dtic-BKPs_app.rb`) a pedido del usuario. Se detectó una inconsistencia u omisión en los archivos descargados durante la fase "Descargar archivos de BKPs de VMs: zfsDISCO1".<br><br>⏱️ **Cronología:**<br>- ✅ **21:54 hs**: Análisis de logs (`logs/dtic-BKPs.log`) confirma el éxito del fix. El mecanismo de rescate identificó y comprimió satisfactoriamente **19 sets de Proxmox**, salvando backups huérfanos de `.notes` (ej. VM-101, VM-102, VM-103, etc).<br>- ✅ **19:58 hs**: Fallas resueltas exitosamente. Modificación en `tools/dtic-BKPs/fxs/proc_syncPmox.rb` para extraer iterativamente el ID de la VM desde los archivos cuando no se encuentra `.notes`. Actualización en `dtic-BKPs_app.rb` para incluir auto-lanzamiento en sesiones desconectadas (`screen -dmS`) previniendo bloqueos del agente SSH. |
|
||||
|
||||
### srv-dasu
|
||||
| Tema | Hitos |
|
||||
| :--- | :--- |
|
||||
| ➡️ - A05 - **VM Windows Server (Core)** | 🚀 Inicio del despliegue de una máquina virtual Windows Server Core genérica para operar primariamente como Controlador de Dominio.<br><br>⏱️ **Cronología:**<br>- 🛑 **21:05 hs**: Bloqueo Crítico. La VM `100` fue empaquetada exitosamente, pero Proxmox abortó el encendido al detectar que la **Virtualización por Hardware (AMD SVM) está apagada/bloqueada en la BIOS física** de la placa madre. Se requiere intervención manual del administrador.<br>- 🧠 **20:57 hs**: Asignación técnica de VM aprobada: `2 Cores`, `2048MB RAM`, `50GB Storage`.<br>- 🚀 **20:54 hs**: Inicio de descarga automatizada de ISO genuina (*SERVER_EVAL_x64FRE_en-us.iso*) conectando directamente el hypervisor con Microsoft Static Downloads.<br>- 🧠 **20:33 hs**: Análisis de arquitectura: Se decide un despliegue "Server Core" (sin interfaz gráfica) por sobre la "Desktop Experience" para optimizar recursos de Proxmox.<br><br>➡️ **[Continúa en 24/02](2026-02-24.md#A05)** |
|
||||
| ✅ - A02 - **Arquitectura srv-dasu** | 🧠 Definición de arquitectura y rol: `srv-dasu` operará como hypervisor Proxmox VE standalone fuera del cluster principal, dedicado exclusivamente a hospedar servidores virtuales para la oficina de DASUTEN. ADN y perfil de nodo inicializados.<br><br>⏱️ **Cronología:**<br>- 🧠 **16:50 hs**: Rol y ubicación definidos y registrados (`01_ontologia.md` y `srv-dasu.md`). |
|
||||
| ✅ - A03 - **Relevamiento Hardware srv-dasu** | 👁️ Auditoría técnica inicial post-instalación de Proxmox para asentar CPU, RAM y almacenamiento en el Snapshot del nodo (`nodos/srv-dasu.md`).<br><br>⏱️ **Cronología:**<br>- ✅ **19:20 hs**: Sincronización exitosa. Datos técnicos capturados vía SSH: `AMD A10-9700 4C`, `16GB RAM`, `SSD 480GB LVM`. Hubo bloqueos temporales por políticas del agente local.<br>- 👁️ **19:09 hs**: Inicio de relevamiento de recursos físicos del equipo. |
|
||||
| ✅ - A01 - **Instalación Proxmox VE** | 🚀 Preparación de entorno e instalación física de hypervisor Proxmox VE en el nuevo servidor `srv-dasu`.<br><br>⏱️ **Cronología:**<br>- ✅ **19:09 hs**: Cierre de tareas de infraestructura base. Servidor energizado, conectado y accesible vía SSH.<br>- 🔧 **19:05 hs**: Inyección exitosa de la llave pública SSH (`id_rsa.pub`) desde `srv-ns8` hacia `srv-dasu` para permitir administración remota segura sin contraseña.<br>- 🟢 **19:00 hs**: Enlace físico (cable) reparado y conectividad establecida en la red. Cambio a IP final operativa `10.0.10.205`.<br>- ⚠️ **18:42 hs**: Se reporta falta de conectividad en la interfaz de red asignada (`nic0`). Inicio de diagnóstico.<br>- 🟢 **18:08 hs**: Confirmación de red. IP real configurada: `10.0.10.204/24` (GW: `10.0.10.1`). Placa designada por PvE: `nic0`.<br>- 🔧 **17:48 hs**: Reconfiguración de IP post-instalación debido a segmento de red incorrecto asignado por DHCP/instalador.<br>- 🔧 **17:30 hs**: Definición de parámetros del instalador: Hostname (`srv-dasu.utnlarioja`) y Password Root.<br>- 💾 **16:54 hs**: Se descarga "Proxmox VE 9.1 ISO Installer" para su preparación.<br>- 🚀 **16:40 hs**: Inicio de tareas. Formateo y copiado de imagen ISO en unidad USB booteable. |
|
||||
| ✅ - A00 - **Acondicionamiento Hardware** | 🔧 Recepción del servidor físico y acondicionamiento de hardware base para `srv-dasu`.<br><br>⏱️ **Cronología:**<br>- ✅ **16:40 hs**: Cierre de gabinete y reubicación del chasis. Continuación metodológica (A01) con la generación y copiado de imagen ISO en unidad USB.<br>- 🔧 **16:00 hs**: Recepción de servidor físico. Apertura e instalación de nuevo hardware: se acopló el disco de estado sólido (SSD) y se ampliaron los módulos de memoria RAM. |
|
||||
|
||||
---
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA) -->
|
||||
<!--
|
||||
1. ORDEN INVERSO: Lo más nuevo SIEMPRE arriba (Tabla Resumen, Secciones de Nodo y Filas de Detalle).
|
||||
2. NARRATIVA:
|
||||
- Resumen (Arriba): Narrativa integral y sintética, SIN TÍTULOS NI ESTADOS en el texto.
|
||||
- Detalle (Abajo): Generoso, explicando el "qué" y el "valor" técnico.
|
||||
3. ESTRUCTURA: Control -> Resumen -> Actividades Detalladas (Subdivididas).
|
||||
4. UNIFICACIÓN: Una sola fila por Nodo en Resumen.
|
||||
5. TRIGGERS (Sincronización en Cascada):
|
||||
- **T1 (Avance)**: Agregar un Hito `⏳` actualiza el DETALLE de la tabla 'En Proceso'.
|
||||
- **T2 (Cierre)**: Cerrar el último `⏳` de un Nodo dispara la creación de su Resumen Integral.
|
||||
- **T3 (Rollover)**: Al cambiar de día (archivo), heredar estas Premisas IA, migrar tareas `⏳`/`📍` al nuevo día, y marcar las antiguas como `➡️` (Migradas). Se debe SEGREGAR la cronología: los logs de sucesos quedan en su día original. Inyectar hipervínculos bidireccionales (`[Continúa en DD/MM](...)` y `[Viene de DD/MM](...)`) al final/inicio del detalle para mantener la trazabilidad exacta de la línea de tiempo transdiaria.
|
||||
6. IDENTIFICADORES: Usar el correlativo exacto del Tema como ID (ej. `[✅ - A01 - **Nombre Tarea**](#...)`).
|
||||
7. ICONOGRAFÍA: Tema = [Estado] (ej. ✅, ⏳, ➡️). Hitos = Prefijo de Categoría en descripción narrativa, y Emojis semánticos integrados en cada viñeta cronológica.
|
||||
8. ARMONÍA: Consultar y seguir estrictamente las premisas del ADN (`adn/02_protocolo.md`).
|
||||
-->
|
||||
@@ -0,0 +1,49 @@
|
||||
# Bitácora de Operaciones - 24/02/2026
|
||||
|
||||
## Control de Gestión
|
||||
|
||||
### 🚩 Pendientes
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| 📍 - P02 - **Sistema DASUTEN** | srv-dasu | ➡️ **[Viene del 23/02](2026-02-23.md)**<br>Despliegue e instalación del software del sistema DASUTEN en la VM. |
|
||||
|
||||
### ⏳ En Proceso
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| [⏳ - A07 - **Sync dtic-BKPs**](#srv-ns8) | srv-ns8 | ➡️ **[Viene del 23/02](2026-02-23.md#A07)**<br>Sincronización limpia de backups de Proxmox para aplicar nombres de host. |
|
||||
| [⏳ - A05 - **VM Windows Server (Core)**](#srv-dasu) | srv-dasu | ➡️ **[Viene del 23/02](2026-02-23.md#A05)**<br>Creación y configuración de máquina virtual con Windows Server Core para rol AD DS. |
|
||||
|
||||
### 📝 Resumen de Actividades
|
||||
| NODO | RESUMEN INTEGRAL |
|
||||
| :--- | :--- |
|
||||
| | |
|
||||
|
||||
---
|
||||
|
||||
## 📂 Actividades Detalladas
|
||||
|
||||
| ⏳ - A07 - **Sync dtic-BKPs** | 🚀 Reinicio de la sincronización de resguardos (`dtic-BKPs_app.rb C1`) con la nueva política de nomenclatura basada en nombres de host para las carpetas contenedoras de Proxmox.<br><br>➡️ **[Viene del 23/02](2026-02-23.md#A07)**<br><br>⏱️ **Cronología:**<br>- 🚀 **17:32 hs**: Tras el apagado del servidor, se relanzó exitosamente la suite de subida a la nube (`C3` - `full_upload`) en una nueva sesión GNU Screen. El proceso de sincronización con OneDrive se encuentra nuevamente operativo en segundo plano.<br>- 🚀 **12:53 hs**: El nodo `srv-ns8` sufrió un reinicio, interrumpiendo el proceso de subida en la sesión GNU Screen. Se procede a retormarlo.<br>- 🚀 **10:35 hs**: Verificación asíncrona de la sesión GNU Screen. El directorio `srvv-FENIX` fue transferido al 100%. Actualmente sincronizando volumen pesado de `srvv-KOHA` (~8.9GB) al 33% con una tasa estable de ~5.15 MiB/s.<br>- 🚀 **08:23 hs**: La subida a OneDrive continúa activa y estable en segundo plano, procesando actualmente los respaldos pesados del directorio `srvv-FENIX`. **Directorios ya sincronizados:** `VM-106`, `VM-107`, `VM-113`, `VM-115`, `pcv-DASU1`, `pcv-DASU2`, `pcv-DASU3`, `pcv-SERVIIO`, `srv-MauriK`, `srv-SysACADWeb`, `srvv-DATA`, `srvv-DNS`, `srvv-DOCs`, `srvv-DTIC`.<br>- 🚀 **06:00 hs**: Inicio de subida a la nube (OneDrive) de los respaldos locales (`full_upload`). |
|
||||
|
||||
### srv-dasu
|
||||
| Tema | Hitos |
|
||||
| :--- | :--- |
|
||||
| ✅ - A06 - **Dashboard P2601** | 🚀 Refactorización de la capa visual y lógica del Dashboard de proyecto para incorporar métricas de justificación operativa.<br><br>➡️ **[Viene del 23/02](2026-02-23.md#A06)**<br><br>⏱️ **Cronología:**<br>- ✅ **10:25 hs**: Segunda inyección sobre Nginx. Se incorporó traza de tiempo granular por cada sub-hito (dificultad Física vs Remota), lógica dinámica de somatoria total, e interfaz de "Acordeones" para purgar el ruido visual colapsando los grupos inactivos. Se transparentó el esfuerzo interno del propio hito A06 (desarrollo y puesta en marcha del dashboard).<br>- ✅ **10:17 hs**: Despliegue de actualización en caliente sobre Nginx. Se inyectó el panel de "Métricas Operativas" (*glassmorphism*) que contabiliza Dinámicamente el **Tiempo Transcurrido vs Estimado**, segregando la intervención en horas físicas (in-situ) y horas remotas (SSH). La línea de tiempo fue sincronizada con los últimos cierres de hitos (`A01` a `A06`). |
|
||||
| ⏳ - A05 - **VM Windows Server (Core)** | 🚀 Inicio del despliegue de una máquina virtual Windows Server Core genérica para operar primariamente como Controlador de Dominio.<br><br>➡️ **[Viene del 23/02](2026-02-23.md#A05)**<br><br>⏱️ **Cronología:**<br>- ✅ **09:54 hs**: Intervención administrativa exitosa. Relevamiento fotográfico confirma la habilitación de Hardware Virtualization (SVM) y auto-encendido (APM) en la placa base ASUS PRIME A320M-K (BIOS V.0217). Datos asentados en el perfil del nodo `srv-dasu.md`.<br>- 🚀 **09:54 hs**: Arranque exitoso de la VM `100` (`qm start 100`). El sistema hypervisor levantó la máquina operativa sin fallos de KVM, confirmando la resolución del bloqueo crítico. |
|
||||
|
||||
---
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA) -->
|
||||
<!--
|
||||
1. ORDEN INVERSO: Lo más nuevo SIEMPRE arriba (Tabla Resumen, Secciones de Nodo y Filas de Detalle).
|
||||
2. NARRATIVA:
|
||||
- Resumen (Arriba): Narrativa integral y sintética, SIN TÍTULOS NI ESTADOS en el texto.
|
||||
- Detalle (Abajo): Generoso, explicando el "qué" y el "valor" técnico.
|
||||
3. ESTRUCTURA: Control -> Resumen -> Actividades Detalladas (Subdivididas).
|
||||
4. UNIFICACIÓN: Una sola fila por Nodo en Resumen.
|
||||
5. TRIGGERS (Sincronización en Cascada):
|
||||
- **T1 (Avance)**: Agregar un Hito `⏳` actualiza el DETALLE de la tabla 'En Proceso'.
|
||||
- **T2 (Cierre)**: Cerrar el último `⏳` de un Nodo dispara la creación de su Resumen Integral.
|
||||
- **T3 (Rollover)**: Al cambiar de día (archivo), heredar estas Premisas IA, migrar tareas `⏳`/`📍` al nuevo día, y marcar las antiguas como `➡️` (Migradas). Se debe SEGREGAR la cronología: los logs de sucesos quedan en su día original. Inyectar hipervínculos bidireccionales (`[Continúa en DD/MM](...)` y `[Viene de DD/MM](...)`) al final/inicio del detalle para mantener la trazabilidad exacta de la línea de tiempo transdiaria.
|
||||
6. IDENTIFICADORES: Usar el correlativo exacto del Tema como ID (ej. `[✅ - A01 - **Nombre Tarea**](#...)`).
|
||||
7. ICONOGRAFÍA: Tema = [Estado] (ej. ✅, ⏳, ➡️). Hitos = Prefijo de Categoría en descripción narrativa, y Emojis semánticos integrados en cada viñeta cronológica.
|
||||
8. ARMONÍA: Consultar y seguir estrictamente las premisas del ADN (`adn/02_protocolo.md`).
|
||||
-->
|
||||
@@ -0,0 +1,24 @@
|
||||
# Arquitectura: Windows Server Core para Controlador de Dominio (AD DS)
|
||||
|
||||
**Fecha de Análisis:** 23 de Febrero de 2026
|
||||
**Nodo Aplicado:** `srv-dasu` (Hito A05)
|
||||
|
||||
## Decisión Técnica
|
||||
Se ha determinado implementar **Windows Server en modo Core** (sin Interfaz Gráfica o *Desktop Experience*) como la mejor resolución técnica y arquitectónica para servidores cuyo rol exclusivo o principal es el de Controlador de Dominio de Active Directory (AD DS).
|
||||
|
||||
## Fundamentos y Beneficios
|
||||
|
||||
1. **Eficiencia y Ahorro de Recursos:**
|
||||
Al prescindir de la pesada capa gráfica, el Sistema Operativo base minimiza su huella de memoria RAM y uso de ciclos de CPU. Un Controlador de Dominio funcional puede operar óptimamente con 1.5GB o 2GB de RAM bajo esta modalidad. En entornos satelitales como `srv-dasu` (donde los 16GB totales deben compartirse con otros despliegues como el sistema DASUTEN), optimizar la memoria en la capa de directorio es fundamental para evitar la sobredemanda (OOM).
|
||||
|
||||
2. **Seguridad y Estabilidad (Reducción de Superficie de Ataque):**
|
||||
*A menor cantidad de dependencias en ejecución, menor cantidad de puntos de falla.* Al remover la GUI clásica y sus componentes satelitales asociados (Windows Explorer, visores nativos, consolas MMC innecesarias), se reducen drásticamente los vectores y vulnerabilidades explotables localmente, elevando la postura de ciberseguridad del directorio de red.
|
||||
|
||||
3. **Menor Frecuencia de Reinicios y Updates:**
|
||||
Menos módulos presentes en disco equivalen a requerir **una menor cantidad de parches mensuales** provistos por Windows Update (eliminando los parches dirigidos a la interfaz de escritorio o visualizadores). Esto reduce la tasa de reencendidos forzados, incrementando sostenidamente el *tiempo de actividad* (uptime) de un servicio vital para la resolución de nombres y autenticación del resto de la facultad.
|
||||
|
||||
4. **Administración Remota y Centralizada (Best Practices):**
|
||||
Un controlador de dominio moderno no requiere sesiones interactivas RDP o acceso directo por consola de manera constante. Una vez instanciado e inicializado mediante `sconfig` o PowerShell, Active Directory puede y debe ser administrado externamente desde una estación de trabajo segura (ej. desde el Departamento TIC) utilizando herramientas como **RSAT (Remote Server Administration Tools)** o el moderno **Windows Admin Center**.
|
||||
|
||||
---
|
||||
*Documento integrado al cuerpo de conocimientos (ADN) de la Dirección de TIC como estándar para el despliegue de DCs ligeros.*
|
||||
@@ -0,0 +1,27 @@
|
||||
# Nodo: srv-dasu
|
||||
|
||||
## Identidad
|
||||
- **Hostname**: `srv-dasu.utnlarioja`
|
||||
- **Rol Inicial**: Hypervisor Proxmox VE (Standalone - DASUTEN)
|
||||
- **Estado**: ⏳ Instalación Base
|
||||
|
||||
## Hardware (Físico)
|
||||
- **Placa Madre**: ASUS PRIME A320M-K (BIOS Ver. 0217 UEFI)
|
||||
- *Virtualización (SVM)*: Habilitada por hardware.
|
||||
- *APM (Restore on AC Power Loss)*: Configurado en "Último Estado".
|
||||
- **Ubicación**: Oficina DASUTEN (Fuera del cluster principal)
|
||||
- **CPU**: AMD A10-9700 Radeon R7 (4 Cores / 3.5GHz)
|
||||
- **RAM**: 16 GB (2x 8GB DDR4 2666MHz Crucial/Undefined - 15Gi usable)
|
||||
- **Almacenamiento**: 1x 480GB SSD ADATA SU630 (`sda` - LVM-Thin Proxmox Base)
|
||||
|
||||
## Red
|
||||
- **IP**: `10.0.10.205/24` (Gateway: `10.0.10.1`)
|
||||
|
||||
## Servicios Críticos
|
||||
1. **Virtualización**
|
||||
- **Motor**: Proxmox VE
|
||||
- **Estado**: ⏳ En Proceso de Instalación
|
||||
- **Propósito**: Hospedar servidores virtuales exclusivos para la oficina de DASUTEN.
|
||||
|
||||
## Dependencias / Sincronización
|
||||
- **Cluster**: Ninguna (Servidor Standalone externo al cluster de la Facultad).
|
||||
@@ -42,6 +42,11 @@ server {
|
||||
proxy_set_header Connection "upgrade";
|
||||
}
|
||||
|
||||
# Dashboard P2601
|
||||
location /P2601/ {
|
||||
try_files $uri $uri/ =404;
|
||||
}
|
||||
|
||||
# TinyFileManager
|
||||
location /tfm/ {
|
||||
proxy_pass http://127.0.0.1:8082/;
|
||||
|
||||
@@ -229,8 +229,9 @@ unless ENV['TERM'] == 'screen' || ENV['TERM'] =~ /^screen/ || ENV['STY']
|
||||
puts "Para reconectarte luego, usa: #{AMARILLO}screen -r #{nombre_sesion}#{RESET}"
|
||||
sleep 2
|
||||
|
||||
# Reemplaza el proceso actual por screen ejecutando este mismo script
|
||||
exec('screen', '-S', nombre_sesion, 'bash', '-c', "#{comando_escapado}; echo ''; read -p 'Presiona Enter para cerrar la sesión...'")
|
||||
# Reemplaza el proceso actual lanzándolo en una sesión de screen desatendida (-dmS)
|
||||
system('screen', '-dmS', nombre_sesion, 'bash', '-c', "#{comando_escapado}; echo ''; read -p 'Presiona Enter para cerrar la sesión...'")
|
||||
exit 0
|
||||
end
|
||||
|
||||
log :info, "===== Inicio script #{APP_NOM} #{APP_VER} (en Screen) ====="
|
||||
|
||||
@@ -105,11 +105,26 @@ def procesar_backups_tipo_proxmox(tarea_cfg)
|
||||
end
|
||||
|
||||
if nombre_vm.nil? || nombre_vm.empty?
|
||||
# Fallback: extraemos el ID de la VM del nombre de archivo (ej. vzdump-qemu-101-...)
|
||||
# Fallback 1: Extraer el nombre de la VM desde dentro del propio archivo .log
|
||||
begin
|
||||
File.foreach(ruta_log) do |line|
|
||||
if line =~ /INFO: VM Name:\s*(.+)$/
|
||||
nombre_vm = $1.strip
|
||||
log :info, "#{tarea_cfg[:id]}: Nombre '#{nombre_vm}' extraído del log '#{nombre_base_log}'."
|
||||
break
|
||||
end
|
||||
end
|
||||
rescue StandardError => e
|
||||
log :warn, "#{tarea_cfg[:id]}: Error leyendo log para extraer VM Name: #{e.message}"
|
||||
end
|
||||
end
|
||||
|
||||
if nombre_vm.nil? || nombre_vm.empty?
|
||||
# Fallback 2: extraemos el ID de la VM del nombre de archivo (ej. vzdump-qemu-101-...)
|
||||
regex_match = nombre_base_log.match(/vzdump-(?:qemu|lxc)-(\d+)-/)
|
||||
if regex_match
|
||||
nombre_vm = "VM-#{regex_match[1]}"
|
||||
log :info, "#{tarea_cfg[:id]}: Sin .notes válido para '#{nombre_base_log}'. Respaldo asignado a: #{nombre_vm}"
|
||||
log :info, "#{tarea_cfg[:id]}: Sin .notes ni nombre en log para '#{nombre_base_log}'. Respaldo asignado a: #{nombre_vm}"
|
||||
else
|
||||
log :warn, "#{tarea_cfg[:id]}: No se pudo determinar nombre de VM para '#{nombre_base_log}'. Saltando."
|
||||
next
|
||||
|
||||
Reference in New Issue
Block a user