location /docs/ en ns8.conf pasa por proxy_pass a gemma-docs-web.service
(WEBrick, 127.0.0.1:4567) — renderiza on-demand la documentación de
referencia de GEMMA (Protocolos, Guías, etc.) desde su .md, sin archivos
intermedios. Parte de P164 (dtic-GEMMA).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Manifiesto fundacional del ámbito A11 dtic-GEMMA:
- A11_dtic-GEMMA.md: Espíritu, misión y principios de operación
- A11.P001_Operativa-GEMMA.md: Protocolo de operativa diaria
Contexto:
- GEMMA opera como "número 2" del operador humano
- Ejecuta tareas desde simples (registro en bitácora) hasta complejas (orquestar backups)
- Todas las operaciones usan herramientas del ecosistema ADN
- Trazabilidad total vía bitácora
Actualizaciones:
- docs/contexto/IA.md: Agregada referencia al ámbito A11
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bug 2 — proc_dasuten.rb:
- Separa nodo operacional (srvv-fenix, srv-ns8, etc.) del nodo de bitácora
- Registro siempre bajo nodo=dtic-BKPs / ámbito=dtic-DIIAA
- Agrega constantes NODO_BITACORA y AMBITO_BITACORA
Bug 3 — ejecutor.rb (detectar_nodo_id):
- Ignoraba el parámetro 'nodo' y siempre usaba Socket.gethostname
- Fix: usa el nombre pasado para lookup en DB
- Fallback a hostname local solo si nodo es nil/empty o no existe en DB
- Segundo fallback a hostname si el nodo pasado tampoco existe en DB
DB: creado nodo 'dtic-BKPs' (ID:49, tipo:servicio, ámbito:dtic-DIIAA)
Refs: A04.P006 — Pipeline DASUTEN / A03 BKPs
- La firma del método no aceptaba :ambito_id causando 'unknown keyword'
- Los drones (ejecutor.rb) pasaban ambito_id al crear eventos en bitácora web
- El error silenciaba el registro → eventos de drones no aparecían en bitácora
- Solución: agregar ambito_id: nil a firma, columna INSERT y params
Refs: A04.P006 — Pipeline DASUTEN Full backup 2026-04-21
BACKEND (ambitos.js):
- Nuevo endpoint GET /api/ambitos/:codigo/proyecto
- Devuelve estructura compatible con frontend existente
- Planes con hitos, métricas y nodos (igual que proyectos)
FRONTEND (ProyectoDashboard.tsx):
- Cambiado default de 'P2601' a 'A04'
- Fetch desde /ambitos/${codigo}/proyecto en lugar de /proyectos
- Mantiene compatibilidad con interfaz existente
DATOS ACTUALIZADOS:
- 29 hitos totales
- 21 completados ✅
- 8 pendientes/legacy ⏳🛑
- 6 planes: A04.P001 a A04.P006
- 60 horas totales (14.5h presencial + 45.5h remoto)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- adn/tools/db/migrations/004_create_planes.sql (NUEVO)
Migración para tabla 'planes' dentro de ámbitos
Reemplaza concepto anterior de 'fases' por 'planes'
Incluye vista resumen_planes para métricas
- servicios/nginx/dtic-bitacoras/tools/sync_dashboard_to_db.js
Actualizado para usar Ámbito A04 (dtic-DASUTEN) en vez de 'P2601'
Planes A04.P001 a A04.P006 en vez de 'fases 1-13'
Migración automática de DB si tablas no existen
27 hitos organizados por plan (Legacy + Workgroup + Backups)
- docs/ambito/dtic-DASUTEN/_hist/260415_dashboard_P2601_actualizacion.md
Documentación completa de la actualización
Incluye estructura de datos, métricas y referencias
**Estructura ADN aplicada:**
- Ámbito: A04 (dtic-DASUTEN)
- Planes: A04.P001 (Red) a A04.P006 (Backups)
- Hitos: 21 completados ✅, 3 pausados ⏸️, 6 legacy 🛑
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- docs/ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md (NUEVO)
Documento completo sobre el enfoque con Domain Controller (23/02-27/03/26)
Incluye: arquitectura descartada, causas del fracaso, timeline, lecciones
- docs/ambito/dtic-DASUTEN/A04.P005_DASUTEN-sin-DC.md
Agregada sección "Contexto Histórico" con referencia al caso de estudio
- docs/ambito/dtic-DASUTEN/A04_dtic-DASUTEN.md
Agregada sección completa sobre el enfoque DC descartado
- docs/contexto/IA.md
Agregada sección "Caso de Estudio: Enfoque con Domain Controller"
Incluye tabla de recursos, señales de alerta y lecciones para futuros proyectos
**Principio aplicado:** "La arquitectura más simple que funciona es mejor que
la arquitectura 'correcta' que apenas se sostiene."
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se corrigió actualizar_heartbeat_web() para que filtre el output
antes de actualizar la Bitácora Web.
Antes: Mostraba ~400 líneas con logs de PostgreSQL
Ahora: Muestra solo ~15 líneas de progreso relevante del dron
El filtrado se aplica en dos lugares:
1. Al acumular líneas (filtrar_lineas_relevantes)
2. Al actualizar heartbeat web (filtrar_output_relevante)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se implementó filtrado de output para que la Bitácora Web muestre
solo las líneas relevantes del progreso del dron, no los ~40 logs
repetitivos de conexión a PostgreSQL.
Cambios:
- filtrar_lineas_relevantes(): Filtra líneas de PostgreSQL en tiempo real
- filtrar_output_relevante(): Filtra y mantiene últimas 20 líneas para heartbeat
- Heartbeat web: Ahora muestra solo progreso del dron, no conexiones DB
Beneficio: La Bitácora Web ahora muestra información útil y legible
en lugar de cientos de líneas de logs técnicos repetitivos.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se implementó mejora en la salida de comandos para hacerla más intuitiva:
Cambios realizados:
- bkps.rb: Encabezado y cierre visual con box drawing para tareas DASUTEN
- ejecutor.rb: Barra de progreso con timer en tiempo real durante ejecución
- A04.P006: Actualizado con resultados del test completo 2026-04-15
Nueva salida visual:
- Encabezado con contexto del pipeline (nombre, hora de inicio)
- Timer en vivo durante la ejecución ([1m 23s] ejecutando...)
- Cierre con estado (✅/❌) y duración total
Resultados del test completo (Pipeline FULL):
- 6 pasos completados exitosamente en 13m 15s
- DBCC CHECKDB: Integridad OK
- Todos los drones atómicos funcionaron correctamente
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Mejora en el sistema de latidos de los drones para mostrar el progreso
acumulado en lugar de solo la última línea.
Cambios realizados:
- ejecutor.rb: Acumulación de output en array accumulated_out[]
- actualizar_heartbeat_web(): Muestra últimas 15 líneas en bloque ```text
- A01.P009: Documentada Fase F1.5b con ejemplo técnico
- A04.P006: Actualizado plan DASUTEN con mejora y lección aprendida
Beneficio: Visibilidad completa del progreso de drones multi-paso
(ej: [1/3], [2/3], [3/3] en pipelines de backup/restore)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Se actualiza el nombre completo de la oficina:
- Antes: DASUTEN (Departamento de Acción Social Universitaria Tecnológica Nacional)
- Ahora: D.A.S.U.Te.N (Dirección de Acción Social de la Universidad Tecnológica Nacional)
Cambio aplicado en:
- 02_informe_tecnico_DASUTEN.md (sección Resumen Ejecutivo)
- 01_informe_ejecutivo_DASUTEN.md (ya tenía el nombre correcto)
Se copian los informes actualizados al directorio de versiones:
- 01_v0.4.md — Informe ejecutivo con pipeline de backups implementado
- 02_v0.3.md — Informe técnico con anexo G de drones atómicos
Cambios desde versiones anteriores:
- Estado 100% completado (vs 95%)
- Impresión resuelta mediante symlink
- Pipeline de backups documentado (6 drones atómicos)
- Módulo DasuExecutor incorporado
- Integración con bkps.rb detallada
Agregada sección sobre el módulo dasu_executor.rb:
- Funciones disponibles y su propósito
- Ejemplo de uso
- Beneficios de mantenibilidad
Agregada lección aprendida sobre refactorización.
- Arquitectura actualizada: backup directo a X: sin paso intermedio
- Tabla de drones actualizada con nuevos outputs
- Agregada lección aprendida sobre simplificación
Cambios realizados:
1. dasuten_exportar_srvv-fenix.rb:
- Genera backup en disco local: E:\BK_SQL\sysdasuten\
- Copia automáticamente a unidad de red X: (share srv-ns8)
- Usa PowerShell para copiar al share mapeado
- Verifica ambos destinos
2. dasuten_transferir_srvv-fenix-srv-ns8.rb:
- Simplificado: ya no descarga desde fenix vía SMB
- El backup ya está en /mnt/ns8Disco2/bkps-dasuten/
- Copia local: share → /var/tmp/ (para rclone upload)
Flujo actualizado:
1. SQL Server → E:\BK_SQL\sysdasuten\archivo.bak (local fenix)
2. PowerShell → X:\archivo.bak (share srv-ns8)
3. Transfer dron → /var/tmp/archivo.bak (para rclone)
4. Upload dron → Google Drive
Requisito en srvv-fenix:
net use X: \\10.0.10.8\bkps-dasuten /user:rmonla <password>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios realizados:
1. srv-ns8 - Share SMB configurado:
- Path: /mnt/ns8Disco2/bkps-dasuten
- Share name: bkps-dasuten
- Usuario: rmonla
- Acceso: \\10.0.10.8\bkps-dasuten
2. dasuten_transferir_srvv-fenix-srv-ns8.rb:
- Elimina copia automática al share
- Agrega nota sobre cómo copiar manualmente desde fenix
- Mantiene backup en /var/tmp/ para upload a Drive
Uso desde srvv-fenix (Windows):
net use X: \\10.0.10.8\bkps-dasuten /user:rmonla <password>
copy E:\BK_SQL\sysdasuten\archivo.bak X:\
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios realizados:
1. dasuten_transferir_srvv-fenix-srv-ns8.rb:
- Agrega paso [3/3] para copiar al directorio compartido
- Directorio: /mnt/ns8Disco2/bkps-dasuten/
- Mantiene copia temporal en /var/tmp/ para upload a Drive
- Output incluye backup_ns8 con ruta completa
Flujo actualizado:
srvv-fenix (E:\BK_SQL\sysdasuten\)
↓ SMB
srv-ns8 (/var/tmp/) ← temporal para upload
↓ copia local
srv-ns8 (/mnt/ns8Disco2/bkps-dasuten/) ← share permanente
Resultado:
- Backup original se preserva en fenix
- Copia en share ns8 para resguardo local
- Copia temporal para upload a Google Drive
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios realizados:
1. dasuten_exportar_srvv-fenix.rb (FULL):
- Nuevo formato: E:\BK_SQL\sysdasuten\sysdasuten_FULL_YYYYMMDD_HHMMSS.bak
- Crea directorio con xp_create_subdir si no existe
- Usa compresión nativa de SQL Server (WITH COMPRESSION)
- Output: backup_tipo='full'
2. dasuten_exportar_diferencial_srvv-fenix.rb (DIF):
- Nuevo formato: E:\BK_SQL\sysdasuten\sysdasuten_DIF_YYYYMMDD_HHMMSS.bak
- Crea directorio si no existe
- Usa compresión nativa (WITH DIFFERENTIAL, COMPRESSION)
- Output: backup_tipo='differential'
3. dasuten_download_drive-dasu-sql4.rb:
- Lee nombre de archivo desde upload_output JSON
- Guarda como F:\BACKUP\{nombre_real_del_archivo}.bak
- Soporta formatos FULL y DIF
4. dasuten_restaurar_dasu-sql4.rb:
- Lee backup_local desde download_output JSON
- Busca patrón sysdasuten_FULL_*.bak si no hay output
- Encuentra el más reciente por LastWriteTime
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Soporte para comando `relay` en el CLI (start/stop/status/ps1)
- Redirige tráfico HTTPS a través de puerto `socat` en host relay (ej: srv-dasu)
- Permite a las PCs de LAN interna que no corren VPN conectar con NS8 W-ZOMBI en Tailscale.
- Se integra de forma robusta con la tool de `wzombi`
Bugs corregidos:
- /cmd no existía en server (solo /cmd.json) — agregada ruta explícita
- PS1 client pedía /cmd sin Content-Type JSON — cambiado a /cmd.json
- JSON fallback: ConvertFrom-Json si Invoke-RestMethod no parsea
- Send-Log con UTF-8 encoding explícito
- Validación extra: chequea $cmdData.id y $cmdData.cmd antes de ejecutar
- Log bilateral: registra comando enviado Y resultado recibido
- ZOMBI CONECTADO log al iniciar
- abort: detiene al primer fallo (default)
- continue: salta el fallo y sigue con el siguiente
- retry: reintenta N veces antes de abortar (--retries N)
- Resumen final con conteo de éxitos/fallos/saltados
Configuración de nginx para servir el Generador de Notas:
Cambios realizados:
- servicios/nginx/conf.d/ns8.conf: Agregados locations /notas/ y /notas/plantillas/
- servicios/nginx/conf.d/notas.conf: Configuración modular creada
Acceso web:
- https://ns8.frlr.utn.edu.ar/notas/ - Generador de Notas
- https://ns8.frlr.utn.edu.ar/notas/plantillas/ - Plantillas markdown
Documentación actualizada:
- A08.P001_Sistema-Web-Notas.md: Fase 4 completada
- A08_dtic-NOTAS.md: Tabla de nodos y acceso web
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nuevo ámbito A08 para gestión de notas e informes formales:
Arquitectura:
- Separación contenido (archivos .md) de presentación (web HTML)
- Plantillas configurables para diferentes tipos de notas
- Vista previa con membrete institucional UTN-FRLR
- Impresión/PDF via window.print() con CSS @media print
Archivos creados:
- docs/ambito/dtic-NOTAS/A08_dtic-NOTAS.md (manifiesto)
- docs/ambito/dtic-NOTAS/A08.P001_Sistema-Web-Notas.md (plan)
- docs/ambito/dtic-NOTAS/app/index.html (interfaz)
- docs/ambito/dtic-NOTAS/app/styles.css (estilos institucionales)
- docs/ambito/dtic-NOTAS/app/app.js (lógica + marked.js CDN)
- docs/ambito/dtic-NOTAS/plantillas/nota-simple.md
- docs/ambito/dtic-NOTAS/contenido/2026/ejemplo-nota.md
Migración:
- dtic-NOTAs/ movido a docs/ambito/dtic-NOTAS/dtic-NOTAs/
- Histórico 2019-2025 preservado en .Hist/
- Convención de nombres documentada: Nota-<AÑO><NUMERO>_<Asunto>.<ext>
Uso:
1. Abrir docs/ambito/dtic-NOTAS/app/index.html en navegador
2. Seleccionar plantilla o cargar archivo .md
3. Completar datos de nota
4. Generar vista previa e imprimir
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementación 22:10:
- Registro DMARC agregado con p=none (monitoreo)
- Reportes de agregado y forense a dtic@frlr.utn.edu.ar
- Alineación estricta (adkim=s, aspf=s)
Estado:
- SPF: ✅ v=spf1 mx ip4:190.114.205.2 include:spf.protection.outlook.com -all
- DKIM: ✅ Selectores 1 y 2 respondiendo
- DMARC: ✅ p=none con reportes
Gmail: Período de calentamiento 24-72 horas para mejora de reputación.
Documentación actualizada:
- Plan A07.P002: Triada completa
- A07_dtic-DNS: Estado actualizado
- IA.md: Actualización
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Actualización post-verificación 22:00:
Documentación actualizada:
- A07.P002: Fase 4 actualizada con observaciones de spam
- A07_dtic-DNS: Estado cambiado a 'En Monitoreo'
- IA.md: Lección agregada sobre Gmail spam y causas
Próximo paso: Agregar registro DMARC p=none
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Crear plan A07.P002_Resolver-DKIM-Gmail.md
- Diagnóstico inicial: registros selector1/2._domainkey NO existen
- SPF configurado correctamente (include:spf.protection.outlook.com)
- DMARC no configurado (opcional, no bloqueante)
Acciones requeridas:
1. Agregar 2 registros CNAME en DNS de la UTN
2. Esperar propagación (15-30 min)
3. Habilitar DKIM en Microsoft 365 Admin Center
Dron enviado: dron_172429_2784151_e8aa34 (evento AUTO registrado)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Armonía Integral post-creación del ámbito dtic-DNS:
- Agregar referencia a docs/ambito/dtic-DNS/ en docs/contexto/IA.md
- Registrar evento #1417 en bitácora web (ámbito dtic-DNS operativo)
- Crear ámbito 'dtic-DNS' en base de datos (ID: 8)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Crear ámbito A07_dtic-DNS con manifiesto y plan A07.P001
- Implementar CLI dns.rb con 7 subcomandos (status, zona, registros, buscar, backup, reload, corefile)
- Detectar servidor srvv-dns: CoreDNS en Docker (10.0.10.2, VM 112 en srv-pmox1)
- Documentar zona frlr.utn.edu.ar con 20+ registros (A, CNAME, MX, TXT, SRV)
- Actualizar ficha nodos/srvv-dns.md con información técnica completa
- Agregar script reparar.sh para ns8-apps (pendiente de ejecución)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios:
- ejecutor.rb: Corregir lectura de output con Open3
- bitacora_db.rb: Agregar métodos crear_evento/actualizar_evento (public)
- dron_db.rb: Corregir conversión de PG::Result a Hash (.first.to_h)
- vigilante.rb: Corregir formato de fecha en dashboard
- migrations/004: Crear tabla bitacoras.events para Bitácora Web
Pruebas:
- dron lanzar --evento AUTO --nota "Test" -- echo "hola" ✅
- dron flota ✅
- dron salud ✅
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios:
- Estado: En Planificación → En Implementación (Fase 1 completa)
- Documentar atomisidad como principio de codificación
- Actualizar tabla de herramientas existentes
- Marcar Fase 0 y Fase 1 como ✅ completas
- Actualizar diagrama de flujo con Dron::Base
- Actualizar componentes implementados
- Agregar sección de entregables Fase 1
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Principio "Menos es Más": código común centralizado en un solo lugar.
Cambios:
- Nuevo módulo Dron::Base con funcionalidad compartida:
- logger: Logger compartido (evita crear múltiples instancias)
- db_query: Ejecución de SQL con resultados
- db_exec: Ejecución de SQL sin resultados
- formato_duracion: Utilitario para formatear segundos
- slice_safe: Slice seguro de strings
- blank?: Verificación de strings vacíos/nulos
- Todos los módulos atómicos (ejecutor, vigilante, sanador, bitacora)
ahora usan Base.logger, Base.db_query, Base.db_exec
Beneficios:
- Un solo lugar para corregir errores comunes
- Menos duplicación de código (~40% menos líneas)
- Consistencia en manejo de logs y DB
- Fácil extensión: nuevos drones heredan funcionalidad automática
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementación del sistema AtomicDrones basado en "Menos es Más":
- Refactorización de dron.rb a dispatcher + módulos atómicos
- Nuevos módulos: ejecutor, vigilante, sanador, bitacora
- DronDB para acceso a datos en PostgreSQL
- Tablas: dron_logs, dron_avances, dron_metricas
- Views: vw_dron_estado, vw_dron_zombies, vw_dron_metricas_semanal
- Health check con detección de zombies (heartbeat > 5min)
- Dashboard compacto de la flota
- Saneamiento con reintentos (backoff exponencial) y limpieza
Comandos soportados:
- dron lanzar: Ejecutar comando como dron
- dron flota: Dashboard de la flota
- dron salud: Health check activo
- dron estado <ID>: Estado detallado
- dron sanear: Saneamiento completo
- dron limpiar: Limpieza de antiguos
- dron reintentar: Re-intentar fallidos
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Actualización del plan A01.P009 para definir la arquitectura de
registros y comunicación de drones mediante la Bitácora Web.
Arquitectura de registros:
- CAPA 1 (Interna): Tablas dron_logs, dron_avances, dron_metricas
- NO visibles directamente en la web
- Almacenan detalle paso-a-paso de cada dron
- Usadas por dron_vigilante para monitoreo
- CAPA 2 (Visible): Bitácora Web (events consolidados)
- Resumen legible de flujos/orquestaciones
- Estado: ⏳ En ejecución | ✅ Completado | ❌ Fallido
- URL: http://localhost:5174/bitacoras/
Dron Vigilante:
- Escanea flota y detecta zombies (heartbeat > 5min)
- Registra avances en bitacoras.dron_avances
- Consolida resumen en bitacoras.events (visible en web)
- Alerta anomalías (>5 fallos en 1h)
Nueva Fase 0 (Prioritaria):
- F0.T1-T3: Migraciones de tablas internas
- F0.T4: dron_db.rb para acceso a datos
- F0.T5: Hooks DB-First para auto-registro
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nuevo plan A01.P009 que define la arquitectura de drones como engranajes
especializados que forman una maquinaria integral mediante composición.
Filosofía de diseño:
- AtomicDrones: Cada dron hace UNA cosa y la hace bien
- Inteligencia de Colmena: Soluciones complejas emergen de drones simples
- No FrankenDrones: Rechazar monolitos que intentan hacer todo mal
Tipos de drones definidos:
- 🛠️ Ejecutor: Ejecuta comando y reporta resultado
- 👁️ Vigilante: Monitorea estado de otros drones
- 🩹 Sanador: Repara drones zombies/fallidos
- 📅 Planificador: Lanza drones según cron
- 📨 Mensajero: Notifica resultados
- 🎼 Orquestador: Compone múltiples drones en flujo
Fases de implementación:
- Fase 1: Atomicidad (separación de responsabilidades)
- Fase 2: Composición (orquestación de flujos)
- Fase 3: Planificación (drones programados)
- Fase 4: Inteligencia de Colmena (comunicación por eventos)
- Fase 5: Observabilidad (dashboard y métricas)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Despliegue de clave RSA al servidor SSH en nodo pcv-dasu0.
- Ejecución de Rename-Computer con DomainCredential via PowerShell Remoto.
- Actualización de nombre en Proxmox VE (VM 102).
- Comprobación de propagación DNS exitosa.
- Actualización de fichas de nodo y planes.
- Renombramiento resuelto vía WinRM/Invoke-Command desde dasu-srvv-sql.
- SSHD de dc-dasuten estaba instalado pero fallaba al iniciar; solucionado interactuando desde sql.
- qm set 100 --name ejecutado.
- Ficha de nodo y referencias en documentacion actualizadas.
Completado:
- Clave RSA generada en srv-dasu (rmonla@srv-dasu) y desplegada en VMs
- sshpass instalado en srv-dasu para deploy inicial de claves
- Rename-Computer con credenciales de dominio (DomainCredential)
- Proxmox display name actualizado (qm set 101 --name)
- Ficha nodos/sql-dasuten.md → nodos/dasu-srvv-sql.md
- Referencias actualizadas en P2601 manifiesto y plan AD-Join
