Agent 2.16.1: IP de LAN en el modal del Fleet + pestaña Tools retirada + auto-update inmediato

Descripción general

Mini-tanda funcional lanzada el 22-07-2026 tras el análisis de la sesión del Agente (decisiones de Edu). Tres cambios: (1) la columna IP del modal del Fleet por fin muestra la dirección de la máquina en su red local, (2) la pestaña Tools de la página local se retira (fail-closed, nunca funcionó), y (3) la orden de auto-update se empuja al conectar, no a los 30 segundos.

Cambios principales

1. IP de LAN en el modal del Fleet (nuevo dato en agent_status)

Problema: El campo AgentInstance.ip_address existía desde siempre pero ningún código lo escribía. La columna IP del modal Fleet quedaba vacía.

Solución:

• El Local Agent ahora reporta su IP de LAN en el mensaje agent_status inicial
• La IP se extrae vía socket UDP connect (sin enviar tráfico real) — la interfaz de salida de la máquina
• El servidor valida la IP con ipaddress antes de persistirla en AgentInstance.ip_address
• Esto es diferente a la IP del WebSocket (pública del router), que no identifica la máquina en su red local

Archivos:

• terminal/models.py — campo ip_address en AgentInstance (ya existía, ahora rellenado)
• Local Agent (código C#) — extracción de IP en agent_status
• Endpoint server-side que recibe agent_status — validación con ipaddress

Tests: 3 tests nuevos en agent_status + ip_address validation

2. Retirada de la pestaña Tools de localhost:5050

Problema: La página local del Agente tenía una pestaña “Tools” cuyas acciones (tracert, ping, etc.) exigían un Bearer token local. Desde 2.1.2/2.6.0 (vector DNS-rebinding cerrado), esa página no puede inyectar el token — todas las acciones fallaban con “Local auth token required”.

Solución:

• La pestaña Tools se retira por completo (~500 líneas de HTML+CSS+JS eliminadas)
• Las mismas herramientas funcionan desde CreaRack (que sí puede inyectar el token)
• El acceso a Metrics UI (página exenta que sí funciona en local) se conserva, movido al footer junto a “Licenses”

Decisión de UX: “menos lío, menos código, menos mantenimiento” (opción C de Edu)

Archivos:

• terminal/agent/assets/debug.html — eliminación de pestaña + JS asociado

3. Auto-update se ofrece en agent_status inicial, no espera heartbeat

Problema (lección del flapping #203): La orden de auto-update solo se empujaba al procesar el heartbeat del Agente, que tarda 30 segundos en enviarse. Con un WebSocket inestable (viviendo ~6,6 segundos), la orden nunca llegaba — el 2.16.0 hubo que instalarlo reiniciando el Agente a mano.

Solución:

• La orden de auto-update se empuja también en el agent_status inicial (llega nada más conectar)
• Se utiliza un helper único _maybe_push_agent_update compartido entre heartbeat y agent_status (mismo dedup, no duplica órdenes)
• Un WS inestable ya no puede bloquear su propia cura

Archivos:

• Local Agent (código C#) — _maybe_push_agent_update en el handler de agent_status y heartbeat

Tests: 3 tests nuevos en agent_status + dedup

4. Build script: publicación por NetBird

Problema: El firewall de s222 cerró el puerto :22 público (100.96.156.31), y el scp a la IP pública 116.203.31.166 muere con “Connection closed”. El build del 2.16.0 acabó verde pero sin publicar — se subieron los artefactos a mano.

Solución:

• build_agent.bat cambia de IP pública a NetBird (100.96.156.31)
• El peer crearack-prod es accesible solo con VPN activa
• El scp ahora funciona

Archivos:

• build_agent.bat — línea 400, IP remota

Impacto usuario

Versiones afectadas

• Local Agent: v2.16.1 (build reproducible, código puro → paquete sin recompilar onedir)
• CreaRack Pro (SaaS): v1.62.2

Validación

• 6 tests nuevos (3 para ip_address + 3 para push en agent_status)
• 123 tests del área verdes en Docker
• Ayuda viva crearack--terminal--local-agent actualizada en el mismo ciclo

Véase también

• [[entity—terminal—model—agentinstance]]
• [[crearack—terminal—local-agent]]
• [[incident—20260422—flapping-agente-ws]]
• [[feature—terminal—agent-2-16-0-throttle-ws-flapping]]
• [[crearack—monitoring—fleet-manager]]