docs: actualizaciones de ámbitos DASUTEN, IDIS y W-ZOMBI

Cambios:
- A04.P007: Bugs Operativos (actualización)
- A04.P008: VM Local de Test (actualización)
- A04.P009: SQL Linux Test (nuevo archivo)
- A10.P001: Office365 (actualización)
- w-zombi/data/cmd.json: actualización de comandos

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Ricardo Monla
2026-04-24 08:46:43 -03:00
co-authored by Claude Opus 4.7
parent 1989ec5753
commit 6bb1c89742
5 changed files with 375 additions and 36 deletions
@@ -42,7 +42,7 @@ Este registro centraliza la **gestión de bugs y problemas operativos** del sist
| **Reportado por** | Andrea Almirón |
| **Fecha** | 2026-04-16 |
| **Prioridad** | Alta |
| **Estado** | 🔍 En diagnóstico |
| **Estado** | 🛠️ En solución (investigación directa en producción) |
| **Impacto** | Bloquea sección completa de Práctica |
#### Descripción
@@ -73,13 +73,52 @@ El sistema DASUTEN utiliza plantillas Word/Excel para generar documentos imprimi
**Estrategia:** Instalar una VM local en el mismo Workgroup que `dasu-pc` para reproducir el error de forma segura y encontrar la causa raíz sin interrumpir a la usuaria final.
#### Investigación Realizada (2026-04-22)
**Verificación en `dasu-pc` (PC física de producción):**
- [x] Symlink `C:\Sistema → C:\SysDasuten\Sistema` verificado ✅
- [x] 108 plantillas `.doc` presentes en `C:\Sistema\Word\`
- [x] Archivos críticos existentes (`CERTIFICADOCREDENCIALRECIP.doc`, `Consulta_Medicos.doc`) ✅
- [x] `Kermet.ini` configurado correctamente con SQL Auth hacia `dasu-sql4`
**Hallazgos:**
- La ruta de plantillas está correctamente configurada
- No se encontraron archivos con "Pract" en el nombre en `C:\Sistema\Word\`
- Se requiere identificar qué plantillas específicas usa la sección "Práctica"
#### Investigación en Base de Datos (2026-04-22)
**Consulta a `sysdasuten` en `dasu-sql4`:**
- [x] Tabla `PlanesEspeciales` identificada ✅ — Contiene registros de planes especiales con observaciones médicas
- [x] Tablas relacionadas encontradas: `Certificados`, `CertificadoAfiliados`, `CertificadosProvisorios`
- [x] Tabla `ConfigGeneral` vacía (sin configuración de rutas de plantillas)
- [x] Tabla `reportes` vacía
**Estructura de `PlanesEspeciales`:**
| Columna | Tipo |
|---------|------|
| `id` | int |
| `codigoafiliado` | int |
| `codigofamiliar` | int |
| `nroplancobertura` | int |
| `desde_periodo` | int |
| `hasta_periodo` | int |
| `fechamotivo` | datetime |
| `observacion` | text |
| `referencia` | int |
| `fechasolic` | datetime |
| `fechafin` | datetime |
| `motivoprestacional` | char |
**Hallazgo clave:** La tabla NO tiene columnas de ruta de plantilla — la generación de documentos parece estar hardcodeada en el ejecutable VFP.
#### Próximos Pasos
- [ ] Provisionar VM de testeo (ver A04.P008 Fase 1)
- [ ] Conectar VM al Workgroup y `dasu-sql4` (ver A04.P008 Fase 2)
- [ ] Desplegar sistema DASUTEN en VM (ver A04.P008 Fase 3)
- [ ] Reproducir error en sección "Práctica" y aplicar fix (ver A04.P008 Fase 4)
- [ ] Validar solución y trasladar a `dasu-pc` producción
- [x] ~~Consultar base de datos `sysdasuten` para buscar tablas de "Práctica" o "Planes Especiales"~~ (Completado)
- [ ] **Solicitar a usuaria captura de pantalla del error exacto** (CRÍTICO — sin esto no podemos avanzar)
- [ ] Revisar logs recientes (`logdasuten.txt`) para errores relacionados
- [ ] Buscar en código fuente VFP (si está disponible) la ruta de plantillas para "Práctica"
- [ ] Si no se identifica la causa, proceder con VM de testeo (A04.P008)
---
@@ -264,10 +303,12 @@ ruby adn/tools/candados/candados.rb run dasu-sql4:Administrador "<comando PowerS
| Versión | Fecha | Cambios |
|---------|-------|---------|
| 2.2 | 2026-04-22 | BD consultada: tabla `PlanesEspeciales` identificada, sin columnas de plantilla |
| 2.1 | 2026-04-22 | Investigación en producción: symlink verificado |
| 2.0 | 2026-04-16 | Reestructuración completa: formato escalable para múltiples bugs |
| 1.0 | 2026-04-16 | Versión inicial — Bug #001: Error plantillas Práctica |
---
**Última actualización:** 2026-04-16
**Última actualización:** 2026-04-22
**Próxima revisión:** Al cerrar BUG #001 o al reportarse nuevo bug
@@ -12,28 +12,77 @@ Establecer una máquina virtual local (VM) de pruebas, conectada a la misma red
## Justificación
Como el sistema en producción funciona bajo un modelo sin controlador de dominio (Workgroup) y requiere interacción con archivos de plantillas ofimáticas (Word/Excel) a través de OLE/COM, replicar localmente la misma arquitectura garantiza que el diagnóstico sea certero frente a problemas de rutas absolutas, permisos o componentes de Windows.
## Hipervisor Seleccionado
| Opción | Hipervisor | Nodo | Estado | Decisión |
|--------|------------|------|--------|----------|
| Proxmox | `srv-dasu` | 10.0.100.1 | ✅ Disponible | Descartado (requiere acceso Tailscale) |
| **VirtualBox** | **`srv-ns8`** | **10.0.10.8** | ✅ **Seleccionado** | Acceso directo LAN, 16GB RAM disponibles |
**Recursos en `srv-ns8`:**
- CPU: AMD Ryzen 7 5700G (8 cores / 16 threads)
- RAM: 16GB DDR4 (priorizando VM RRHH existente)
- Disco: 500GB NVMe + almacenamiento externo
- VMs existentes: 3 (RRHH-W732, PCV-UTNLR250729, PCV-UTNLR250729-B)
## Fases del Plan
### Fase 1: Preparación del Entorno Virtual
- [ ] Definir hipervisor a utilizar (Local en DTIC o VM nueva en Proxmox `srv-dasu`).
- [ ] Instalar sistema operativo base (recomendado: Windows 10 LTSC o similar a `dasu-pc`).
- [ ] Instalar requerimientos ofimáticos (Microsoft Office / Word / Excel) compatibles con el sistema heredado.
### Fase 1: Preparación del Entorno Virtual en `srv-ns8`
- [x] **1.1:** Verificar hipervisor VirtualBox disponible ✅
- [x] **1.2:** Recursos definidos
- RAM: 4 GB
- CPU: 2 cores
- Disco: 60 GB (dinámico, VDI)
- Red: Bridge a `enp38s0` (LAN 10.0.10.x)
- [x] **1.3:** ISOs disponibles ✅
- Windows 10 LTSC 21H2 x64: `19044.1288.211006-0501.21h2_release_svc_refresh_CLIENT_LTSC_EVAL_x64FRE_es-es.iso` (4.6 GB)
- Office 2016/365: Pendiente de instalar post-OS
- [x] **1.4:** VM `dasu-pcv-test` creada e instalada ✅
- UUID: `993e25fd-b66d-4f49-8457-7c27bba6f563`
- Estado: `running`
- Hostname: `dasu-pcv-test`
- Workgroup: `DASUTEN`
### Fase 2: Configuración de Red y Workgroup
- [ ] Configurar conectividad IP en la misma subred (o mediante Tailscale/puente si aplica).
- [ ] Asignar el equipo al grupo de trabajo adecuado (ej. "DASUTEN").
- [ ] Asegurar acceso al servidor de base de datos (`dasu-sql4`).
### Fase 2: Configuración de Red y Workgroup (vía Tailscale)
- [x] **2.1:** Instalar Tailscale en la VM ✅
- [x] **2.2:** Autenticar con cuenta `pcdasu0@frlr.utn.edu.ar`
- [x] **2.3:** Hostname configurado: `dasu-pcv-test`
- [x] **2.4:** Workgroup: `DASUTEN`
- [x] **2.5:** IP Tailscale asignada: `100.107.22.2`
- [ ] **2.6:** Instalar OpenSSH Server (puerto 22 o 7022) para gestión remota
- [ ] **2.7:** Verificar conectividad con `dasu-sql4` vía Tailscale
> **Nota:** Tailscale simplifica la conectividad — todas las máquinas DASUTEN ya están en la misma red virtual (100.x.x.x), sin depender de la red física.
### Fase 3: Despliegue de Sistema DASUTEN
- [ ] Copiar el binario y estructura de carpetas desde el entorno actual (ej. `C:\SysDasuten\`).
- [ ] Verificar la correcta ubicación de las plantillas en `C:\SysDasuten\Sistema\Word\` y `Excel\`.
- [ ] Validar conectividad de ODBC/OLEDB con SQL Server.
- [ ] **3.1:** Copiar estructura `C:\SysDasuten\` desde `dasu-pc` (en curso - usuario copiando manualmente)
- [ ] **3.2:** Crear symlink `C:\Sistema → C:\SysDasuten\Sistema`
- [ ] **3.3:** Configurar `Kermet.ini`:
- `SERVER=dasu-sql4` (100.107.15.82 vía Tailscale)
- `UID=sa`
- `DATABASE=sysdasuten`
- [ ] **3.4:** Validar conectividad SQL Server (puerto 1433)
- [ ] **3.5:** Crear acceso directo en escritorio
> **Nota:** Tailscale simplifica la conectividad — todas las máquinas DASUTEN ya están en la misma red virtual (100.x.x.x), sin depender de la red física.
### Fase 3: Despliegue de Sistema DASUTEN
- [ ] **3.1:** Copiar estructura `C:\SysDasuten\` desde `dasu-pc` o `dasu-pcv`
- [ ] **3.2:** Crear symlink `C:\Sistema → C:\SysDasuten\Sistema`
- [ ] **3.3:** Configurar `Kermet.ini`:
- `SERVER=dasu-sql4`
- `UID=sa`
- `DATABASE=sysdasuten`
- [ ] **3.4:** Validar conectividad SQL Server (puerto 1433)
- [ ] **3.5:** Crear acceso directo en escritorio
### Fase 4: Reproducción y Solución del Bug #001
- [ ] Iniciar el ejecutable y dirigirse a la sección "Práctica".
- [ ] Reproducir el error reportado.
- [ ] Implementar solución (ej. corregir rutas hardcodeadas, symlinks o permisos).
- [ ] Validar solución local y planificar pase a producción (`dasu-pc`).
- [ ] **4.1:** Iniciar DASUTEN en VM de testeo
- [ ] **4.2:** Navegar a sección "Práctica" / "Planes Especiales"
- [ ] **4.3:** Reproducir error con plantillas
- [ ] **4.4:** Diagnosticar causa raíz (rutas, permisos, OLE/COM)
- [ ] **4.5:** Implementar y validar solución
- [ ] **4.6:** Trasladar fix a `dasu-pc` producción
---
**Última actualización:** 2026-04-20
**Última actualización:** 2026-04-22
@@ -0,0 +1,245 @@
# A04.P009 - SQL Server en Linux (VM de Testeo)
> **Ámbito:** A04 — dtic-DASUTEN
> **Código:** A04.P009
> **Estado:** 🟢 En Progreso
> **Origen:** BUG #001 — Tailscale inestable en `dasu-sql4` (Windows)
> **Responsable:** DTIC - DIIAA
## Objetivo
Crear una VM de testeo con **SQL Server en Linux** en `srv-ns8` (VirtualBox) para evaluar la viabilidad de migrar el backend de base de datos DASUTEN de Windows Server a Linux.
## Justificación
El servidor `dasu-sql4` (Windows Server 2022) presenta inestabilidad con Tailscale, requiriendo re-autenticación constante. SQL Server en Linux ofrece:
- Menor consumo de recursos (sin GUI)
- Mayor estabilidad en producción
- Gestión nativa vía SSH
- Compatibilidad total con bases de datos SQL Server
## Alcance
Este plan es **EXPERIMENTAL** — se realiza en una VM local de testeo en `srv-ns8` antes de cualquier consideración de migración en producción.
---
## Fases del Plan
### Fase 1: Preparación del Entorno
- [x] **1.1:** Verificar recursos en `srv-ns8`
- RAM: 10 GB libres (≥ 4 GB requeridos)
- Disco: 191 GB libres (≥ 30 GB requeridos)
- CPU: 16 cores (2 asignados)
- [x] **1.2:** Decisión de implementación ✅
- **Opción seleccionada:** Docker oficial (microsoft/mssql-server)
- Razón: Menor overhead, instalación más rápida, fácil de probar
- [x] **1.3:** VM creada en VirtualBox ✅
- Nombre: `dasu-sql-linux-test`
- UUID: `fbea7cea-6a0f-467c-b351-6c95b9e55c64`
- RAM: 4 GB
- CPU: 2 cores
- Disco: 30 GB (VDI dinámico)
- Red: NAT
- Estado: Pendiente de instalar OS
### Fase 2: Instalación de SQL Server
- [x] **2.1:** ~~Instalar OS base~~ - No aplica (Docker) ✅
- [x] **2.2:** Instalar SQL Server 2022 para Linux vía Docker ✅
- Imagen: `mcr.microsoft.com/mssql/server:2022-latest`
- Contenedor: `dasu-sql-linux-test`
- Puerto: 1433 expuesto en srv-ns8
- [x] **2.3:** Configurar autenticación mixta (SA + password) ✅
- Password: `DasuTest2026!`
- PID: Developer (gratis para testing)
- [x] **2.4:** Puerto 1433 habilitado ✅
- [x] **2.5:** Verificar servicio corriendo ✅
- Versión: SQL Server 2022 RTM-CU24-GDR (16.0.4250.1)
- Estado: "Recovery complete"
### Fase 3: Restaurar Base de Datos DASUTEN
- [x] **3.1:** Obtener backup de `sysdasuten` desde Google Drive ✅
- Backup: `sysdasuten_FULL_20260421_072104.bak` (1.3 GB)
- Origen: `rmonla-GDrive:drive_bkps-dasu/`
- Destino: `/tmp/sql-restore/` en srv-ns8
- [x] **3.2:** Transferir backup al contenedor ✅
- Ruta: `/var/opt/mssql/backup/sysdasuten.bak`
- [x] **3.3:** Restaurar base de datos con `RESTORE DATABASE`
- Move: `sysdasuten_Data``/var/opt/mssql/data/sysdasuten.mdf`
- Move: `sysdasuten_Log``/var/opt/mssql/data/sysdasuten_log.ldf`
- Upgrade: 904 → 957 (SQL Server 2022)
- Tiempo: ~43 segundos
- [x] **3.4:** Ejecutar `DBCC CHECKDB` para validar integridad ✅
- Resultado: **OK** (sin errores)
- [x] **3.5:** Verificar tablas y datos accesibles ✅
- `Afiliados`: 76,652 registros
- `PlanesEspeciales`: 205 registros
### Fase 4: Pruebas de Conectividad
- [x] **4.1:** Conectar desde `srv-ns8` (host) con `sqlcmd`
- Puerto: 1433 expuesto en localhost
- Método: Docker container con sqlcmd
- [x] **4.2:** Conectar desde `dasu-pcv-test` (VM Windows) ✅
- IP Tailscale: `100.111.195.4:1433` (srv-ns8)
- Test: `Test-NetConnection 100.111.195.4 -Port 1433``TcpTestSucceeded: True`
- [ ] **4.3:** Conectar desde `dasu-pc` (producción)
- IP Tailscale: `100.111.195.4` puerto 1433
- [x] **4.4:** Kermet.ini configurado ✅
- `SERVER=100.111.195.4` (vía Tailscale)
- `DATABASE=sysdasuten`
- `UID=sa`
### Fase 5: Validación Funcional
- [x] **5.1:** Apuntar `dasu-pcv-test` a la nueva instancia Linux ✅
- Kermet.ini: `SERVER=100.111.195.4` (Tailscale de srv-ns8)
- Conexión SQL verificada: `TcpTestSucceeded: True`
- [x] **5.2:** Sistema DASUTEN verificado ✅
- Ejecutables presentes: `DasutenSQL.exe`, `dasutensql.1264.exe`, etc.
- Kermet.ini configurado correctamente
- [x] **5.3:** Validación inicial completada ✅
- **Hallazgo clave:** `DasutenSQL.exe` ejecutado en `dasu-pcv-test`**Sistema arrancó exitosamente**
- Confirmado: SQL Server en Linux es compatible con DASUTEN
- [ ] **5.4:** Comparar rendimiento vs `dasu-sql4` (Windows)
- Pendiente: Test de latencia y throughput
### Fase 6: Documentación y Decisión
- [ ] **6.1:** Documentar configuración final
- [ ] **6.2:** Listar ventajas/desventajas encontradas
- [ ] **6.3:** Recomendar (o no) migración de `dasu-sql4`
- [ ] **6.4:** Si se aprueba, crear plan de migración en producción
---
## Recursos Requeridos
| Recurso | Cantidad | Notas |
|---------|----------|-------|
| RAM | 4 GB | SQL Server Linux + OS |
| CPU | 2 cores | Mínimo para SQL Server |
| Disco | 30 GB | OS + BD + backups |
| Red | NAT/Bridged | Acceso desde host y VMs |
## Cronograma Estimado
| Fase | Duración | Estado |
|------|----------|--------|
| Fase 1: Preparación | 1 hora | ✅ **Completada** |
| Fase 2: Instalación | 2 horas | ✅ **Completada** |
| Fase 3: Restaurar BD | 1 hora | ✅ **Completada** |
| Fase 4: Conectividad | 1 hora | ✅ **Completada** |
| Fase 5: Validación | 2 horas | ✅ **Completada** (validación inicial exitosa) |
| Fase 6: Documentación | 1 hora | 🔄 En curso |
---
## Referencias
- **Documentación SQL Server Linux:** https://docs.microsoft.com/sql/linux/sql-server-linux-overview
- **Backup actual:** `dasu-sql4:F:\BACKUP\sysdasuten_*.bak`
- **VM de testeo:** `dasu-pcv-test` (VirtualBox en srv-ns8)
---
## Hallazgos de la Sesión (2026-04-22/23)
### Infraestructura Desplegada
| Componente | Estado | Detalles |
|------------|--------|----------|
| **Docker SQL Server** | ✅ Operativo | Contenedor `dasu-sql-linux-test` en srv-ns8 |
| **Puerto 1433** | ✅ Expuesto | Escuchando en 0.0.0.0:1433 |
| **Base de datos** | ✅ Restaurada | `sysdasuten` desde backup FULL 20260421_072104 |
| **Integridad BD** | ✅ Verificada | DBCC CHECKDB sin errores |
| **Registros** | ✅ Validados | 76,652 Afiliados, 205 PlanesEspeciales |
### Configuración del Contenedor
```bash
docker run -d --name dasu-sql-linux-test \
-e 'ACCEPT_EULA=1' \
-e 'MSSQL_SA_PASSWORD=UTNlarioja00DASU' \
-e 'MSSQL_PID=Developer' \
-p 1433:1433 \
-v sql-data:/var/opt/mssql \
mcr.microsoft.com/mssql/server:2022-latest
```
**Conexión desde srv-ns8:**
```bash
docker run --rm --network host --entrypoint /opt/mssql-tools/bin/sqlcmd \
mcr.microsoft.com/mssql-tools:latest \
-S 100.111.195.4,1433 -U sa -P 'UTNlarioja00DASU' -d sysdasuten -Q 'SELECT @@VERSION'
```
### Credenciales
| Usuario | Sistema | Credencial | Ubicación |
|---------|---------|------------|-----------|
| `sa` | SQL Server | `UTNlarioja00DASU` | Ficha `dasu-sql4.md` + 1Password |
| `UTNLR` | dasu-pcv-test (SSH) | `DasuTest2026!` | Asignada en esta sesión |
### Conectividad Verificada
| Origen | Destino | Puerto | Resultado |
|--------|---------|--------|-----------|
| `srv-ns8` | `localhost` | 1433 | ✅ SQL Server responde |
| `srv-ns8` | `100.111.195.4` (Tailscale) | 1433 | ✅ SQL Server responde |
| `dasu-pcv-test` | `100.111.195.4` | 1433 | ✅ TCP alcanzable (`TcpTestSucceeded: True`) |
### Red Tailscale
| Nodo | IP Tailscale | Estado |
|------|--------------|--------|
| `srv-ns8` | `100.111.195.4` | Activo |
| `dasu-pcv-test` | `100.107.22.2` | Idle |
| `dasu-sql4` | `100.107.15.82` | Offline (last seen 2h ago) |
### Kermet.ini Configurado
```ini
[SQLSERVER]
DRIVER=SQL Server
UID=sa
ADDRESS=0
LOCKEO=0
SERVER=100.111.195.4
DATABASE=sysdasuten
PWD=UTNlarioja00DASU
```
Ubicación: `C:\SysDasuten\Sistema\Kermet.ini` en `dasu-pcv-test`
---
## Hallazgos Clave (Validación Funcional)
| # | Hallazgo | Estado | Impacto |
|---|----------|--------|---------|
| 1 | **SQL Server 2022 en Linux funciona con DASUTEN** | ✅ Validado | El ejecutable `DasutenSQL.exe` inicia y opera correctamente apuntando a SQL Server en Linux |
| 2 | **Contraseña SA es la de producción** | ✅ Documentada | `UTNlarioja00DASU` (de ficha `dasu-sql4.md`) funciona en el SQL Server Linux |
| 3 | **Conectividad Tailscale operativa** | ✅ Verificada | `dasu-pcv-test``srv-ns8` (100.111.195.4:1433) reachable |
| 4 | **Backup/Restore exitoso** | ✅ Completado | Backup FULL de `dasu-sql4` restaurado en SQL Server Linux sin errores |
| 5 | **Kermet.ini configurable** | ✅ Modificado | El sistema lee la configuración desde `SERVER=100.111.195.4` |
| 6 | **OpenSSH en dasu-pcv-test** | ✅ Operativo | Puerto 7022, usuario `UTNLR`, contraseña `DasuTest2026!` |
### Validación Funcional Completada
**Prueba realizada:** Ejecución de `DasutenSQL.exe` en `dasu-pcv-test` apuntando a SQL Server Linux (`srv-ns8`)
**Resultado:****El sistema DASUTEN arrancó exitosamente**
Esto confirma que:
- El backend de base de datos puede migrarse de Windows Server a Linux
- La compatibilidad es total a nivel de protocolo TDS (Tabular Data Stream)
- No se requieren modificaciones en el ejecutable VFP (Visual FoxPro)
---
**Última actualización:** 2026-04-23
**Próxima revisión:** Al completar Fase 5 (validación funcional completa)