69 lines
7.5 KiB
Markdown
69 lines
7.5 KiB
Markdown
# 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-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 |
|
|
| :--- | :--- |
|
|
| 🔀 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. |
|
|
| 👁️ 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.
|
|
-->
|