fix(cras-install): el panel no puede creerse un exito que no ocurrio #30

Merged
acazares merged 1 commits from fix/centinela-instalador into development 2026-07-31 21:49:12 +00:00
Member

La bitacora del run 26 tenia la respuesta: la sonda decia que install.ps1 NO
EXISTE y el paso siguiente, "Ejecutar instalador", salia en verde. Comprobado con
PowerShell real por que:

& 'C:\no-existe.ps1' -Service; exit $LASTEXITCODE   ->   exit 0

$LASTEXITCODE no se fija nunca (no corrio ningun comando nativo), asi que
exit $null da 0. El panel leia 0 y asentaba el paso como exitoso. NADA se
instalaba, y por eso seguia viva la 1.1.0: el agente viejo nunca se detuvo porque
el instalador nunca se ejecuto. Esa evidencia falsa mando el diagnostico a otra
parte durante varios runs.

  • El script emite un CENTINELA CRAS-FIN|<codigo> y el panel lo EXIGE. Sin el, el
    instalador no termino, de lo que de el codigo de salida. Un fallo no es una
    respuesta — la misma leccion que la sonda, ahora en la invocacion.
    Validado con PowerShell real: instalador normal -> CRAS-FIN|0; instalador que
    sale 75 -> CRAS-FIN|75 (la traduccion a "restauracion en curso" sigue viva);
    instalador inexistente -> CRAS-ERROR| y codigo 90 en vez de un 0 silencioso.
  • "El instalador no esta" pasa a ser un hecho aparte de "no pude leerlo", y aborta
    con 502. Antes se colapsaba en desconocido, el run continuaba sabiendolo ya,
    gastaba el intento entero y acababa culpando al agente de no escribir su sello.
  • Se asienta el CONTENIDO del staging tras extraer. Sin eso no se distinguia "el
    instalador no esta", "esta en otra ruta" y "esta pero no se puede leer", que son
    tres arreglos distintos.

Y dos cambios en el endurecimiento del token, cada uno defendible por si solo:

  • Se restringe SOLO panel.env, no la carpeta. La restriccion de la carpeta era un
    extra —su motivo declarado, que el archivo heredara una ACL permisiva al
    crearse, ya lo cubre la ACE del propio archivo— y a cambio dejaba la carpeta con
    ACE NO heredables, de modo que lo creado dentro despues podia quedar sin
    permisos utilizables. Ahi se extrae el artefacto: era candidato serio a explicar
    por que el instalador "no existia".
  • Por SID y no por nombre de grupo. En un Windows en espanol
    BUILTIN\Administrators no resuelve y el icacls falla entero; comprobado.
    S-1-5-32-544 y S-1-5-18 valen en cualquier idioma.

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

La bitacora del run 26 tenia la respuesta: la sonda decia que install.ps1 NO EXISTE y el paso siguiente, "Ejecutar instalador", salia en verde. Comprobado con PowerShell real por que: & 'C:\no-existe.ps1' -Service; exit $LASTEXITCODE -> exit 0 $LASTEXITCODE no se fija nunca (no corrio ningun comando nativo), asi que `exit $null` da 0. El panel leia 0 y asentaba el paso como exitoso. NADA se instalaba, y por eso seguia viva la 1.1.0: el agente viejo nunca se detuvo porque el instalador nunca se ejecuto. Esa evidencia falsa mando el diagnostico a otra parte durante varios runs. - El script emite un CENTINELA `CRAS-FIN|<codigo>` y el panel lo EXIGE. Sin el, el instalador no termino, de lo que de el codigo de salida. Un fallo no es una respuesta — la misma leccion que la sonda, ahora en la invocacion. Validado con PowerShell real: instalador normal -> CRAS-FIN|0; instalador que sale 75 -> CRAS-FIN|75 (la traduccion a "restauracion en curso" sigue viva); instalador inexistente -> CRAS-ERROR| y codigo 90 en vez de un 0 silencioso. - "El instalador no esta" pasa a ser un hecho aparte de "no pude leerlo", y aborta con 502. Antes se colapsaba en `desconocido`, el run continuaba sabiendolo ya, gastaba el intento entero y acababa culpando al agente de no escribir su sello. - Se asienta el CONTENIDO del staging tras extraer. Sin eso no se distinguia "el instalador no esta", "esta en otra ruta" y "esta pero no se puede leer", que son tres arreglos distintos. Y dos cambios en el endurecimiento del token, cada uno defendible por si solo: - Se restringe SOLO panel.env, no la carpeta. La restriccion de la carpeta era un extra —su motivo declarado, que el archivo heredara una ACL permisiva al crearse, ya lo cubre la ACE del propio archivo— y a cambio dejaba la carpeta con ACE NO heredables, de modo que lo creado dentro despues podia quedar sin permisos utilizables. Ahi se extrae el artefacto: era candidato serio a explicar por que el instalador "no existia". - Por SID y no por nombre de grupo. En un Windows en espanol `BUILTIN\Administrators` no resuelve y el icacls falla entero; comprobado. S-1-5-32-544 y S-1-5-18 valen en cualquier idioma. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
hreyes added 1 commit 2026-07-31 21:44:14 +00:00
La bitacora del run 26 tenia la respuesta: la sonda decia que install.ps1 NO
EXISTE y el paso siguiente, "Ejecutar instalador", salia en verde. Comprobado con
PowerShell real por que:

    & 'C:\no-existe.ps1' -Service; exit $LASTEXITCODE   ->   exit 0

$LASTEXITCODE no se fija nunca (no corrio ningun comando nativo), asi que
`exit $null` da 0. El panel leia 0 y asentaba el paso como exitoso. NADA se
instalaba, y por eso seguia viva la 1.1.0: el agente viejo nunca se detuvo porque
el instalador nunca se ejecuto. Esa evidencia falsa mando el diagnostico a otra
parte durante varios runs.

- El script emite un CENTINELA `CRAS-FIN|<codigo>` y el panel lo EXIGE. Sin el, el
  instalador no termino, de lo que de el codigo de salida. Un fallo no es una
  respuesta — la misma leccion que la sonda, ahora en la invocacion.
  Validado con PowerShell real: instalador normal -> CRAS-FIN|0; instalador que
  sale 75 -> CRAS-FIN|75 (la traduccion a "restauracion en curso" sigue viva);
  instalador inexistente -> CRAS-ERROR| y codigo 90 en vez de un 0 silencioso.
- "El instalador no esta" pasa a ser un hecho aparte de "no pude leerlo", y aborta
  con 502. Antes se colapsaba en `desconocido`, el run continuaba sabiendolo ya,
  gastaba el intento entero y acababa culpando al agente de no escribir su sello.
- Se asienta el CONTENIDO del staging tras extraer. Sin eso no se distinguia "el
  instalador no esta", "esta en otra ruta" y "esta pero no se puede leer", que son
  tres arreglos distintos.

Y dos cambios en el endurecimiento del token, cada uno defendible por si solo:

- Se restringe SOLO panel.env, no la carpeta. La restriccion de la carpeta era un
  extra —su motivo declarado, que el archivo heredara una ACL permisiva al
  crearse, ya lo cubre la ACE del propio archivo— y a cambio dejaba la carpeta con
  ACE NO heredables, de modo que lo creado dentro despues podia quedar sin
  permisos utilizables. Ahi se extrae el artefacto: era candidato serio a explicar
  por que el instalador "no existia".
- Por SID y no por nombre de grupo. En un Windows en espanol
  `BUILTIN\Administrators` no resuelve y el icacls falla entero; comprobado.
  S-1-5-32-544 y S-1-5-18 valen en cualquier idioma.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
acazares merged commit bd93f49113 into development 2026-07-31 21:49:12 +00:00
acazares deleted branch fix/centinela-instalador 2026-07-31 21:49:12 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ADUANASOFT/PANEL_BASES_ANEXO24#30
No description provided.