fix/windows-actualizacion-silenciosa #25

hreyes · 2026-07-31T17:12:23Z

hreyes commented

2026-07-31 17:12:23 +00:00

No description provided.

hreyes added 3 commits 2026-07-31 17:12:23 +00:00

fix(cras-install): dejar de dar por buena una actualizacion que no surtio efecto 9a4124d636

El run de Windows terminaba en verde sobre un servidor que seguia con la version
anterior. La verificacion no podia detectarlo:

- El sello config\.version ausente se toleraba SIEMPRE. Los agentes anteriores a
  1.1.1 no lo escribian, asi que al actualizar uno de esos `deployed` llegaba
  vacio y no se comprobaba ninguna version — justo la combinacion que importa.
  Ahora, en una ACTUALIZACION, un sello ausente es un fallo: el binario nuevo lo
  escribe en ensure_runtime_layout(), asi que su ausencia significa que lo que
  corre no es el que se instalo. La tolerancia se queda solo en instalacion nueva.
- `Get-Process -Name` responde "hay un proceso con ese nombre", no "corre el
  binario que instale". Se compara la RUTA del ejecutable; si no es legible no se
  concluye que sea ajeno, porque un proceso de SYSTEM no la expone sin elevacion.
- Se interroga la tarea programada a fondo: su accion dice DONDE arranca el
  agente de verdad y se asienta en la bitacora (el dato que habria explicado esto
  en diez segundos), y cuando el agente no reporta su ruta —nada anterior a 1.1.1
  lo hace— se usa la de la tarea en vez del default.

Y dos correcciones de lo anterior:

- needsElevation exigia admin en cuanto la tarea EXISTIA, bloqueando de entrada
  toda actualizacion sobre un servidor ya instalado. Ahora depende de que la
  tarea corra como SYSTEM, que es lo que de verdad obliga a elevar; y el token
  filtrado por UAC deja de rechazarse por adelantado: se intenta y se reporta lo
  que responda el servidor.
- -UpdateInPlace se pasaba siempre, pero solo existe desde 1.1.3 y install.ps1
  usa [CmdletBinding()], asi que con un artefacto anterior fallaba con
  NamedParameterNotFound sin ejecutar una linea. Se le pregunta a PowerShell por
  el param() del propio artefacto en vez de mantener una tabla de versiones.

Verificar comparte las dos sondas nuevas para que no pueda contradecir al
instalador, y gana un chequeo de "el arranque apunta a la instalacion".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fix(cras-install): realinear la tarea de Windows desde el panel, y decir por que fallo 3572aa974b

La actualizacion ya fallaba ruidosamente en vez de mentir, pero el arreglo no
podia llegar al servidor: el install.ps1 que se ejecuta viaja DENTRO del zip, y
el artefacto 1.1.3 se construyo antes de que el instalador aprendiera a
realinear la tarea. Verificado sobre el zip: trae -UpdateInPlace y cero
Sync-AgentTaskPath. Un instalador ya publicado no se arregla hacia atras.

- alignWindowsTask realinea la accion de la tarea por SSH tras instalar el
  binario, conservando disparador, principal, ajustes y argumentos, y asienta la
  ruta ANTERIOR y la nueva para que el cambio sea reversible si la ruta declarada
  estuviera mal. Si no se puede corregir, aborta con 409 nombrando ambas: seguir
  significaria arrancar a sabiendas el binario viejo. Funciona con cualquier
  artefacto ya distribuido.
- restartWindowsAgent rearranca y espera a que corra el binario del prefijo, no
  cualquier proceso con ese nombre. Vive en cras-install y no en
  cras-agent-control porque este es el modulo de abajo; al reves habria un ciclo.

Y el diagnostico deja de ser una tarea para el operador. El error de sello
ausente decia "revisa a que binario apunta el arranque automatico" cuando el
panel YA lo sabe, y la bitacora del run donde si estaba no la encontraba nadie
("no se donde verlo"). Ahora se sondea tarea y proceso ANTES de evaluar el sello
y el mensaje nombra a que apunta la tarea, desde donde corre el proceso, y la
cola de CloudRestoreAS-crash.log — que runner.py escribe precisamente para esto
y que nunca se leia. El banner de error apunta al run por numero.

startOnWindows deja de esperar por nombre y usa la misma sonda de ruta, para que
Verificar no pueda contradecir al instalador.

PowerShell generado validado con PowerShell real: los seis scripts parsean, y el
de realineacion ejercitado contra una tarea simulada reapunta la accion Exec,
conserva los argumentos y respeta las acciones que no son Exec.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

refactor(cras-install): una sola comparacion de rutas de Windows, y hacer visible el destino 9b05361a00

La pregunta "son la misma ruta?" estaba resuelta tres veces con tres criterios:
normalizeWindowsPath recortaba comillas multiples, probeWindowsAgentProcess una
sola, y cras-verify ninguna. Coincidian en los casos reales, pero este modulo ya
lleva escrito lo que cuesta esa duplicacion — probeLinuxElevation e inspectLinux
tuvieron copias paralelas y las dos pantallas acabaron diciendo cosas distintas
del mismo servidor. Ahora es sameWindowsPath() + windowsAgentExe(), usadas en los
tres sitios.

Lo que NO se hace, y queda documentado en el codigo: comparar por prefijo.
C:\Aduanasoft\CloudRestoreAS es prefijo de cadena de
C:\Aduanasoft\CloudRestoreAS-win, y esa combinacion existe en produccion.

Pruebas del par peligroso en las dos direcciones. Comprobado que MUERDEN:
sustituyendo la igualdad por startsWith, falla la comparacion a nivel de carpeta.
Las de rutas completas de .exe no fallan, y eso tambien es informacion — son
estructuralmente inmunes porque el caracter que difiere llega antes del final, asi
que el riesgo vive solo en la comparacion de directorios.

Y el formulario dice a que carpeta va a instalar. Antes la ruta solo aparecia
dentro del aviso de "instalar limpio", que se pinta unicamente si el panel ya
conoce la version instalada: en un servidor con ruta personalizada y version
desconocida el operador no la veia hasta que el run fallaba. Se distingue "ruta
registrada" de "por omision" — no si la capturo el agente o una persona, porque
ambas viven en la misma columna y el panel no puede saberlo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

hreyes added 1 commit 2026-07-31 17:16:13 +00:00

Merge branch 'development' into fix/windows-actualizacion-silenciosa c7f5bf53a1

La PR #24 aplasto el commit 9a4124d de esta rama en a895044, con otro hash, asi
que git vio dos historias para el mismo contenido y marco conflicto en
cras-install.ts, cras-verify.ts y cras-install.test.ts.

Comprobado antes de resolver: la version de development de los tres archivos es
IDENTICA byte a byte a la de 9a4124d, o sea que la PR se mezclo sin cambios de
revision. Los dos commits posteriores de esta rama (3572aa9 y 9b05361) son
refinamientos encima de ese mismo contenido, asi que resolver a favor de esta
rama no pierde nada.

Verificado despues del merge: 346 pruebas, typecheck limpio, y siguen presentes
alignWindowsTask, restartWindowsAgent, readWindowsCrashLog y la comparacion de
rutas compartida entre el instalador y Verificar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>