# Bitácora de Operaciones - 25/02/2026

## Control de Gestión

### 🚩 Pendientes
| ID | NODO | DETALLE |
| :--- | :--- | :--- |
| 📍 - P02 - **Sistema DASUTEN** | srv-dasu | ➡️ **[Viene del 24/02](2026-02-24.md)**<br>Despliegue e instalación del software del sistema DASUTEN en la VM. |

### ⏳ En Proceso
| ID | NODO | DETALLE |
| :--- | :--- | :--- |
| [⏳ - DB01 - **VM SQL Server (Core)**](#srv-dasu) | srv-dasu | ➡️ **[Viene del 24/02](2026-02-24.md)**<br>Despliegue de nueva máquina virtual Windows Server Core genérica para rol de motor de Base de Datos (`sql-dasuten`). |

### 📝 Resumen de Actividades
| NODO | RESUMEN INTEGRAL |
| :--- | :--- |
| | |

---

## 📂 Actividades Detalladas

### srv-ns8

#### ✅ - A06 - Dashboard P2601
🚀 Despliegue de métricas web, reestructuración estructural, y evolución de los servicios core expuestos (Apps).
➡️ **[Viene del 19/02](2026-02-19.md)**

| Tiempo | Descripción |
| :--- | :--- |
| �️ 19:51 | Optimización de Capacidad de Subida. Ante un error de tamaño límite al intentar subir la ISO de SQL Server, se incrementa radicalmente la capacidad de carga del gestor `apps`. Se inyecta un archivo `uploads.ini` (10GB max filesize/post, 1024M memory, 3600s timeouts) dentro del contenedor de PHP, junto a la directiva `client_max_body_size 20G` en el proxy reverso Nginx. |
| �🔑 19:11 | Alta de Credenciales en Gestor de Archivos. A pedido del usuario, se inyecta en caliente (sin downtime) el usuario `utnlr` en la instancia `apps` (`TinyFileManager`), validado contra su respectivo vector criptográfico salt (hash bcrypt). En simultáneo, se revoca la política de solo-lectura (`$readonly_users`) permitiendo que este usuario efectúe subidas (`upload`) de archivos. |
| 🔀 18:55 | Reestructuración de Servicio de Archivos. A solicitud del usuario, se renombra y migra la instancia de `TinyFileManager` (TFM). El alias cambia oficialmente de `tfm` a `apps`. Se modifican las variables en código (PHP `FM_SELF_URL`), se renombra el contenedor de Docker (`srvv-apps`) y se reescribe el proxy inverso en Nginx. Adicionalmente, se habilita el acceso vía HTTP puro sobre la IP local (`10.0.10.8`), añadiendo una excepción al bloque redireccional del puerto 80. |

### srv-dasu

#### ⏳ - DB01 - VM SQL Server (Core)
🚀 Despliegue de nueva máquina virtual Windows Server Core genérica para rol de motor de Base de Datos (`sql-dasuten`).
➡️ **[Viene del 24/02](2026-02-24.md)**

| Tiempo | Descripción |
| :--- | :--- |
| ⚙️ 20:31 | Despliegue de Core Relacional (SQL Server). Estando el escenario congelado a ZSTD (Fallback seguro), el usuario despacha interactivamente desde su consola VNC (Proxmox) el comando de aprovisionamiento silencioso (unattended `/Q`) construido ad-hoc por la IA. El proceso instala en este momento el `SQLEngine` directamente sobre los discos de alto rendimiento LUN secundario (`D:\SQL_DATA\*`) bajo el prefijo `MSSQLSERVER`. |
| 🛡️ 20:16 | Resguardo Integral de Infraestructura Core. Petición explícita del usuario para capturar el estado íntegro de los nodos Windows previos a la instalación compleja. La IA lanza desatendidamente un volcado completo comprimido (ZSTD) vía SSH: `vzdump 100 101 --mode snapshot`. Resultados excelentes: VM 100 (`dc-dasuten`, 50GB) respaldada en 1 minuto (archivo de 2.0GB). VM 101 (`sql-dasuten`, 150GB) respaldada en 2.5 minutos (archivo de 3.3GB). Escenario blindado. |
| 💿 20:07 | Suministro del Medio de Instalación SQL (IA). El usuario facilita la imagen ISO de SQL Server 2019 en el nodo `srv-ns8`. Inmediatamente, la IA orquesta la transferencia lateral nativa vía protocolo seguro SCP directo hacia el datastore maestro de Proxmox en `srv-dasu` (`/var/lib/vz/template/iso/`), logrando un volcado íntegro de 1.5GB en escasos segundos gracias al troncal LAN. |
| 👁️ 18:36 | Búsqueda de Inyectables OS (IA). La IA realiza una exploración autónoma en el repositorio de plantillas ISO del Proxmox (`/var/lib/vz/template/iso/`) vía SSH, verificando la ausencia del medio de instalación de SQL Server 2019 para planificar los métodos de aprovisionamiento lógico. |
| 💾 18:35 | Aprovisionamiento de Almacenamiento Dedicado (Usuario + IA). Para garantizar performance y aislamiento del motor de base de datos, la IA inyecta autónomamente en caliente (vía Proxmox SSH) un segundo disco virtual VirtIO SCSI de `100GB`. Acto seguido, el operador inicializa la unidad GPT en Windows, asigna la letra `D:` sorteando la colisión del CD-ROM, y formatea en NTFS bajo la etiqueta `SQL_DATA`. |
| 👑 17:51 | Promoción de Identidad y Rol. El operador utiliza `SConfig` para vincular formalmente la instancia DB01 al Active Directory. Al validar las credenciales de administrador, el servidor queda integrado exitosamente al dominio `dasuten.utnlr` conformando la primera relación de confianza intracluster. Se dispara reinicio para herencia de políticas. |
| 🟢 17:43 | Configuración de Red Base e inyección DNS Aislada. El operador instala los controladores VirtIO NetKVM, y establece la IP `10.0.100.11` a través de SConfig. Se constata comunicación L3 impecable contra el AD DS (`10.0.100.10`) y salida al exterior (`8.8.8.8`). Resoluciones externas (ej: `google.com`) fallan bajo diseño esperado dado que el DNS principal es el `dc-dasuten` aislado, el cual carece temporalmente de reenvío DNS externo (Forwarders). |
| ✅ 17:31 | Finalización OS base e Identidad. El operador completa la instalación de Windows Server Core y configura exitosamente el nombre de host a `sql-dasuten`. Queda pendiente la inyección de controladores VirtIO y el enrutamiento. |
| 👁️ 17:14 | Instalación de OS. El operador inicia la instalación gráfica interactiva de Windows Server 2022 Core a través de la consola VNC de Proxmox en la VM `sql-dasuten`. El sistema se encuentra en proceso de selección de disco (montaje de drivers VirtIO) y copiado de archivos. |
| 🚀 17:01 | Aprovisionamiento de Instancia (IA). Creación desatendida vía SSH ejecutada por la IA de la VM 101 (`sql-dasuten`) con 4GB RAM, 2 Cores y disco virtio-scsi de 50GB. La IA encendió la máquina e inyectó las ISOs necesarias para preparar el terreno a la instalación interactiva. |
| 👁️ 16:00 | Inicio de la jornada presencial y Fase de Research. El operador arriba físicamente al nodo y comienza la investigación arquitectónica para determinar la infraestructura óptima del motor de base de datos (`sql-dasuten`). Se evalúa la viabilidad del binomio Windows Server Core + SQL Server 2019. |

**Justificación Arquitectónica: Windows Server Core + SQL Server 2019**
La decisión técnica de desplegar SQL Server 2019 sobre una variante *Server Core* (sin entorno gráfico/Desktop Experience) se sustenta en tres pilares operacionales críticos para el ecosistema DASUTEN:

1. **Minimización de Superficie de Ataque (Security by Design)**
   Al carecer de GUI (Explorador, IE/Edge, utilidades gráficas), Server Core elimina componentes que tradicionalmente son vectores de vulnerabilidad. Para un motor de base de datos que albergara información sensible, esta hiper-reducción del SO base reduce drásticamente la exposición a malware y la necesidad de parches de seguridad continuos.
2. **Eficiencia y Asignación Directa de Recursos (Performance)**
   El entorno gráfico de Windows Server consume sostenidamente entre 800MB y 1.5GB de memoria RAM por ocioso, más ciclos de CPU para renderizado. Al utilizar Server Core, **el 100% de la RAM (`4GB` iniciales) y los procesadores quedan dedicados íntegramente al motor del SQL Server** (`sqlservr.exe`). Esto garantiza un alto hit-ratio en la caché de consultas y menor latencia en las transacciones de las PCs cliente.
3. **Escalabilidad y Compatibilidad Estable**
   SQL Server 2019 es la versión madura y más probada en entornos empresariales recientes, asegurando retrocompatibilidad total con el "Sistema DASUTEN" (P02) sin los altos requisitos de hardware de SQL 2022. La administración no se degrada: la instancia se gestionará de manera moderna, remota y centralizada utilizando *SQL Server Management Studio (SSMS)* desde las estaciones de trabajo cliente, manteniendo el servidor servidor de BD ciego y blindado.

---
<!-- 🤖 PREMISAS DE TRABAJO (IA) -->
<!-- 
1. ORDEN INVERSO: Lo más nuevo SIEMPRE arriba (Tabla Resumen, Secciones de Nodo e Hitos).
2. NARRATIVA Y ESTRUCTURA JERÁRQUICA:
   - Resumen (Arriba): Narrativa integral y sintética, SIN TÍTULOS NI ESTADOS en el texto.
   - Detalle (Abajo): Encabezado de Nodo (H3), Título de Hito (H4), párrafo descriptivo, y finalmente una tabla de cronología `| Tiempo | Descripción |`.
3. FORMATO DE TIEMPO: Usar formato `[Icono] HH:MM` (ej. `✅ 23:26`). ESTRICTAMENTE PROHIBIDO usar el sufijo "hs" o " hs".
4. ESTADOS Y TRIGGERS (Sincronización en Cascada):
   - **T1 (Avance)**: Agregar un Hito/Cronología 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 activas al nuevo día, y marcar las antiguas como `➡️` (Migradas). Inyectar hipervínculos bidireccionales de trazabilidad transdiaria.
5. ICONOGRAFÍA: Título Principal = [Estado] (ej. ✅, ⏳, ➡️). Eventos cronológicos = Emojis semánticos al inicio de la celda de tiempo.
6. ARMONÍA: Consultar y seguir siempre las normativas vivas del ADN (`adn/02_protocolo.md`).
7. AUTO-REGISTRO IA: Las acciones autónomas de la IA (ej. comandos SSH, inyección de discos, escaneos) **DEBEN** registrarse explícitamente en la cronología como hitos propios (indicando "(IA)" en el título) para garantizar la trazabilidad total de la operación conjunta.
8. AUTO-DOCUMENTACIÓN IA: La IA debe generar y mantener esta sección de "PREMISAS DE TRABAJO (IA)" de forma autónoma, asegurando que refleje las reglas y directrices más actuales para su operación y la del operador humano.
-->