Commit Graph

1 Commits

Author SHA1 Message Date
7659806505 fix(cras-verify): validar que el servicio pueda LEER su configuración, y loguear los 401
Dos huecos de diagnóstico que hacían pasar por sano lo que no lo estaba.

1. El check `config` usaba `test -f`, que comprueba existencia y no lectura, así
   que salía verde exactamente en el caso roto: una instalación con sudo deja
   config/.env en 0600 de root mientras el unit corre como una cuenta común, que
   no puede leerlo. El agente no arranca y la pantalla decía "Configuración
   presente: ok".

   Ahora se comprueba lectura y, además, el dueño frente al User= del unit —
   porque la sonda entra con la cuenta SSH, que no siempre es la del servicio, y
   un `test -r` desde la sesión no responde por el agente. El check se renombra a
   "Configuración legible por el servicio", que es lo que de verdad mide, y falla
   nombrando a los dos usuarios para que el remedio sea obvio.

   El cálculo del bit de lectura octal sale a una función pura probada: 0600 no
   deja leer a nadie más que al dueño, se mira el bit 4 y no el valor (620 y 611
   no son lectura), se ignora el dígito de setuid, y un modo ilegible NO se
   interpreta como permisivo — asumir lectura cuando stat devuelve '-' sería el
   error caro.

   La lectura de propiedades del unit se extrae a un helper compartido con el
   instalador. Ya hubo una divergencia por copiar esta lógica: la resolución de
   elevación existía duplicada y las dos pantallas acabaron diciendo cosas
   distintas del mismo servidor.

2. Ningún rechazo de token de servicio dejaba rastro: los seis endpoints solo
   logueaban el 500 de "token no configurado". Con el token rotado, todos los
   agentes quedan mudos —dejan de reportar versión, resolver rutas y registrar
   resultados— y desde el panel se ve igual que un agente apagado; además el
   trace_id que se le devuelve al agente no existía del lado servidor, así que
   era imposible correlacionar.

   Se agrega un helper que loguea el rechazo con trace_id, ruta e instancia, y
   distingue "sin header Authorization" de "token no coincide", que son un agente
   sin configurar y un token rotado: dos problemas con remedios distintos. El
   token NUNCA se registra, ni un fragmento suyo — es el mismo valor en todos los
   agentes, así que un prefijo en los logs ya acota el espacio de búsqueda. Hay
   prueba de eso.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-30 16:16:48 -06:00