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>
El instalador exigía root o `sudo -n` (NOPASSWD), así que una cuenta con sudo
CON contraseña —el caso de los servidores Linux— no podía actualizarse desde el
panel. La contraseña guardada no ayudaba: se usa para autenticar SSH y a sudo
nunca se le entrega, por decisión de diseño contra el antipatrón de AServers
(`echo '{password}' | sudo -S`, que expone el secreto en argv).
En vez de rodear esa decisión, se quita la necesidad de privilegios. El agente
no necesita root para funcionar: su unit corre como el usuario que instala, y
las rutas de data_folder las escribe SQL Server, no él. install.sh solo pedía
privilegios por dos razones circunstanciales — el PREFIX por omisión en /opt y
el unit en /etc/systemd/system.
Modo nuevo `--user-service`: instala bajo el home y registra un unit de systemd
de usuario. Para sobrevivir al cierre de sesión intenta lingering y, si el
destino no lo permite, cae a @reboot en el crontab del usuario más un vigilante
cada 5 min que sustituye al Restart=always. Con eso, al panel le bastan el
usuario y la contraseña que ya tiene registrados.
Además, la sonda de elevación pasa a ser compartida entre instalar y verificar
(antes eran copias paralelas que ya diferían en la etiqueta) y distingue casos
que se reportaban idénticos:
- `requiretty` en el sudoers ya no se confunde con "sin privilegios": el remedio
es el opuesto, porque agregar NOPASSWD no lo arregla.
- Una regla NOPASSWD acotada a otros comandos se reporta como tal, con la lista.
- Verificar informa si la ruta es escribible y si la instalación sin privilegios
es viable en ese servidor, en vez de solo decir que faltan permisos.
Dos bugs encontrados al probarlo, ambos con prueba:
- `pgrep -f <ruta>` hacía match consigo mismo, porque la propia línea de cron
del vigilante contiene esa ruta. Sin el ancla `^`, el vigilante creía que el
agente corría y no lo rearrancaba nunca.
- `expectedStepCount` comparaba solo con 'service', así que la barra de una
instalación en modo usuario habría llegado al 100 % con un paso pendiente.
`resolveLinuxPrivilege` no tenía ninguna prueba; se agregan seis.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
