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>
isInsideWorkFolder miraba la relación en los dos sentidos, así que también
rechazaba que las carpetas de trabajo colgaran de la de instalación. Ese es el
layout NORMAL, no un error: constants.py del agente define
DIR_ENTRADA = APP_DIR / "Entrada", así que una instalación correcta en
/opt/cloudrestoreas reporta input_folder = /opt/cloudrestoreas/Entrada.
Efecto: ninguna instalación ni actualización podía pasar, en Linux ni en
Windows. Fallaba en resolveInstallPath —antes de abrir el run, así que no
quedaba nada en la bitácora— con un mensaje que decía justo lo contrario de lo
que ocurría: "la ruta está dentro de una carpeta de trabajo". Solo se libraban
las instalaciones fuera de la ruta por omisión, por accidente del nombre.
Se conserva el peligro que el guard existe para atajar: el binario dentro de
Entrada/Procesados, donde el agente lo tomaría por un respaldo a procesar.
La función no tenía ninguna prueba. Se agregan las dos direcciones, el caso
exacto, la normalización de separador/caja/barra final y el prefijo que no es
de carpeta (/srv/entradas vs /srv/entrada).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Un agente anterior a 1.1.0 no reporta su install_path, así que el panel caía al
default de plataforma y ACTUALIZAR abortaba cuando la instalación vivía en otra
carpeta (p. ej. C:\Aduanasoft\CloudRestoreAS-win). Era un huevo-y-gallina: la
ruta se empieza a reportar en 1.1.x, que es justo lo que no se podía instalar.
Se agrega la captura manual de la ruta por servidor. No hace falta esquema nuevo
ni lógica de resolución nueva: el upsert del estado ya usa
install_path = COALESCE(EXCLUDED.install_path, actual), así que el valor
capturado sobrevive los reportes sin ruta del agente viejo, y resolveInstallPath
y cras-verify ya leen esa misma columna. Cuando el servidor quede en 1.1.x su
propio reporte lo sustituye por la ruta real.
De paso, dos fallos de configuración que costaron el diagnóstico:
- GITEA_TOKEN con los `<>` de la plantilla se veía como un 401 opaco de Gitea,
idéntico al de un token revocado. Se valida la forma antes de llamar, el
aviso sale al cargar la pantalla y 401 y 403 dejan de colapsar al mismo
texto. Un rechazo ahora deja línea en los logs: no dejaba ninguna.
- PANEL_PUBLIC_URL sin el puerto apuntaba a otro servicio. Esa URL se siembra
en el config/.env del destino también al ACTUALIZAR, así que rompería un
agente que ya reportaba: se avisa y se aborta antes de tocar el servidor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
