El espejo a ASI esta caido por un RESET de TLS de repositorio-asi, no por el DNS que diagnostica el script: mba-deploy-pod.sh aborta y el pod se queda en su version vieja
Medido el 2026-09-24 06:35 ART desde lezama, corriendo ./mba-deploy-pod.sh sobre 39a2b0ad (dev, v5.6.52). El script sale por su rama gcaba_reachable() y no espeja nada. SINTOMA: el pod de OpenShift (permisos-movilba-dev.gcba.gob.ar) NO se puede actualizar. Nada se empujo; el pod sigue en su version anterior. LO QUE EL SCRIPT DIAGNOSTICA Y NO ES: mba-deploy-pod.sh:38-41 y su mensaje de error atribuyen esta falla a DNS (MOVILBA-297: un resolver publico contesta 200.16.89.97 en vez del interno 10.20.32.4). ESO NO ES LO QUE PASA AHORA, y seguir las dos instrucciones que imprime no arregla nada: resolvectl -> Current DNS Server: 10.10.1.2, que es uno de los dos de GCABA. getent hosts repositorio-asi.buenosaires.gob.ar -> 10.20.32.4, exactamente el valor que el propio script exige. O sea que el DNS esta BIEN y el runbook impreso manda a DM-ear a nw-lezama-cc por un problema que no existe. CAUSA MEDIDA: el handshake de TLS contra 10.20.32.4:443 avanza hasta el Finished del cliente y ahi el servidor RESETEA. curl sale 56 (Recv failure: Connection reset by peer), 5 de 5 intentos, deterministico. El TCP abre en 2ms, asi que la ruta y el firewall estan bien: lo que se cae es la sesion TLS, no la conexion. DESCARTADO, cada uno medido y no supuesto: - No es negociacion de TLS: --http1.1, --tlsv1.2 con --tls-max 1.2, --ciphers DEFAULT@SECLEVEL=1 y --no-alpn dan los cuatro el mismo exit 56. - No es toda la red de GCABA: https://permisos-movilba-dev.gcba.gob.ar/api/health contesta 200 desde el mismo host en el mismo minuto. - No es un tunel nuestro interceptado: lezama tiene UNA sola interfaz (enp1s0, 10.78.42.168/21), ruta directa a 10.20.32.4 via 10.78.40.2, tailscaled inactivo y cero unidades de VPN corriendo. No hay por donde meter una terminacion de TLS de nuestro lado. - No es git: git ls-remote https://... devuelve el mismo Recv failure: Connection reset by peer. LOS OTROS DOS TRANSPORTES TAMBIEN ESTAN CERRADOS: - El puerto 80 contesta, y eso prueba que el GitLab esta VIVO detras de esa IP: HTTP/1.0 302 con Location https://repositorio-asi.buenosaires.gob.ar/users/sign_in/sectrans/movil-ba/movilba.git/info/refs?service=git-receive-pack - el proxy pega /users/sign_in ADELANTE del path del repo, asi que ese redirect no lleva a ningun lado util ni aunque HTTPS anduviera. git con followRedirects=false sale error: 302. - SSH: el 22 de 10.20.32.4 esta filtrado (connection timed out, no refused). CONSECUENCIA: el unico camino al pod es ese push a repositorio-asi, y hoy no existe ninguno que funcione desde lezama. Todo lo que queda de nuestro lado esta descartado arriba, asi que esto es de GCABA. Elazar no tiene acceso de admin a GCABA ni contacta a su IT, asi que NO hay arreglo self-contained que proponer. El item existe para que el proximo carril que corra el script no vuelva a perder el turno persiguiendo el DNS. ARREGLO QUE SI ES NUESTRO Y ESTA PENDIENTE: el mensaje de error de mba-deploy-pod.sh:60-65 afirma una causa unica que ya no es la unica. gcaba_reachable() solo mira si el codigo HTTP es distinto de 000, asi que no distingue no resuelve de resetea el TLS de TCP filtrado, y despues imprime el runbook de DNS para los tres casos. Un control que imprime siempre el mismo diagnostico no diagnostica: tiene que separar al menos esos tres y decir cual vio. NO EJERCITADO: no se probo desde otro host de la red de GCABA, asi que no esta medido si el reset es contra lezama en particular o contra cualquier cliente. Tampoco se busco desde cuando: el ultimo espejo exitoso no se identifico.
Activity
-
Estado y datos operativos que salen del README de docs/gcaba-gitlab-migracion/ (era un README usado de scratchpad; queda solo la documentacion del circuito). MEDICION DEL 25/09/2026 DESDE LEZAMA, que es lo que sostiene este item: - repositorio-asi.buenosaires.gob.ar resuelve a 10.10.32.22 (BigIP) y contesta 302 -> https://repositorio-asi.gcba.gob.ar perdiendo el path; el cert es *.gcba.gob.ar, curl sale 60. - El nombre nuevo resetea la conexion en todo path, http y https (curl 56). git ls-remote falla igual. - El IP viejo documentado, 10.20.32.4, redirige igual. - Consecuencia: el pod permisos-movilba-dev.gcba.gob.ar sigue con su build anterior y devuelve 500 en POST /api/v1/parque/vehiculos/search (42703, v.fecha_ultima_actualizacion) aunque el arreglo este en dev desde 96b1314e (v5.6.71). BLOQUEANTE PARA LOS MAILS DE CREDENCIALES: faltan tres valores de /srv/movilba-web/.env.production (AUTH_KEYCLOAK_ID, AUTH_URL, AUTH_KEYCLOAK_ISSUER) y el usuario de AD OCP_AD_USER. No se pueden leer sin sudo interactivo, asi que los pide Elazar. PENDIENTE DE CODIGO: mba-deploy-pod.sh va a necesitar el GCABA_BASE nuevo y, si cambia el grupo, la ruta nueva del proyecto. Cambio de una linea, probable recien con acceso. Los datos del ticket (referente tecnico, CUIL, mail) y los textos para el analista viven en /data-lezama/movilba/docs/temp/, fuera de git, no en el repo.
-
CORRECCION al bloqueante de credenciales que traje del README: sudo NO lo destraba, y la premisa era falsa. Medido el 28/09/2026 en lezama con sudo: - AUTH_URL: SI esta, /srv/movilba-web/.env.production -> https://app.movilba.com. No es secreto. - AUTH_KEYCLOAK_ID, AUTH_KEYCLOAK_ISSUER, AUTH_KEYCLOAK_SECRET: NO estan en lezama. No figuran en /srv/movilba-web/.env.{production,local} ni en los equivalentes de /srv/dev-movilba-web (listadas las 14 y 4 claves de cada archivo, solo nombres). docs/reference/auth-and-permissions.md:38 lo dice explicito: salen del Secret de OCP en el pod. El unico camino es oc, y oc whoami responde Unauthorized: no hay sesion en este host. - OCP_AD_USER: NO EXISTE. Cero coincidencias en todo el repo y en /srv (.env*, *.sh, *.yaml). Era un nombre inventado en el README, no una variable real de ningun entorno. Conclusion: el ticket de OpenID a ASI-DGSEI-IDENTIDAD pide CLIENT-ID, y ese valor vive en el Secret de OCP. Sin un oc login valido no se puede escribir ese mail. No es un problema de permisos locales.
-
coder04-mba-l-ca
-
audit pass: reviewed uncommitted diff mba-deploy-pod.sh v3.0->v3.1 + README.md paso4; bash -n clean; verified credential.helper keeps GCABA_GITLAB_TOKEN out of URL/argv/versioned files; grepped diff for literal secrets (none); cross-checked README layer table against script's new reachability diagnostics
payload
{"scope":"reviewed uncommitted diff mba-deploy-pod.sh v3.0->v3.1 + README.md paso4; bash -n clean; verified credential.helper keeps GCABA_GITLAB_TOKEN out of URL/argv/versioned files; grepped diff for literal secrets (none); cross-checked README layer table against script's new reachability diagnostics","outcome":"pass","evidence":"no inline secret; auth via env-sourced overlay matches fleet secrets rule; new DNS-collision diagnostic correctly replaces the now-useless old check (both hostnames resolve same IP); NOC ticket cited as existing context, not a new GCABA-IT ask","reportRef":null} -
audit pass: reviewed second uncommitted diff mba-deploy-pod.sh v3.1->v3.2 (PHP leg removal); bash -n clean; ran --help, matches shortened header exactly; grepped for PHP_SYNC/REPO2/YELLOW/with-php/MARIADB (only survivor is the explanatory comment)
payload
{"scope":"reviewed second uncommitted diff mba-deploy-pod.sh v3.1->v3.2 (PHP leg removal); bash -n clean; ran --help, matches shortened header exactly; grepped for PHP_SYNC/REPO2/YELLOW/with-php/MARIADB (only survivor is the explanatory comment)","outcome":"pass","evidence":"matches Elazar's 2026-09-28 no-php-no-external-api decision; no dangling refs; --help sed range 2,9p correctly recalculated for the shortened usage block","reportRef":null} -
audit pass: reviewed docs-only commit 34341419, README plus rotation SQL; confirmed the two long hex values in the migration are SHA-256 hashes not plaintext keys
payload
{"scope":"reviewed docs-only commit 34341419, README plus rotation SQL; confirmed the two long hex values in the migration are SHA-256 hashes not plaintext keys","outcome":"pass","evidence":"no plaintext secret in tracked files, matches hash-only api_keys storage pattern","reportRef":null} -
Taking MOVILBA-577 to replace the stale single-cause ASI reachability message with diagnostics that distinguish DNS, TCP, TLS, and HTTP/reset failures.
-
Current mba-deploy-pod.sh v3.7 still used one boolean curl probe and printed DNS advice for every code=000 result. Candidate now separates resolver failure (getent), TCP:443 failure (/dev/tcp), TLS negotiation (openssl protocol marker), and post-TLS HTTP/no-status failure, with distinct output; missing diagnostic tools fail closed as unclassified. The push remains unreachable/abort on all failure classes. SHA-256 mba-deploy-pod.sh 2982dacd81b881419c05a8c52a4adf9f077abb1f3b49fce265fe6cc03bc7213a. clean. No shell tests or live push/probe run before audit. Unexercised: whether ASI reset is source-IP-specific and exact behavior from another GCABA host.
-
audit-mba-l-cc 2026-10-09. PASS. Author coder04-mba-l-ca. mba-deploy-pod.sh 2982dacd, pin confirmed exact. ## Diff read, per hunk DNS/TCP/TLS/HTTP cascade classifier replacing the one-shot DNS-only advice. Diagnostic-tool availability (timeout/getent/openssl/curl) checked first, unclassified failure if one is missing. GCABA_HOST correctly derived from GCABA_BASE (strip scheme, strip path after first /) - verified it resolves to repositorio-asi.gcba.gob.ar, not the full path. /dev/tcp probe correctly uses bash -c with positional $1 inside a single-quoted script body so the host is the invoked subshell's own $1, not expanded by the outer shell. TLS check greps for a negotiated-protocol marker rather than s_client's exit status, matching the known false-negative-on-clean-close behavior. Original exit-before-push-on-any-failure behavior unchanged. bash -n: syntax OK. ## Independently exercised, not just read Extracted the classifier function into a standalone script and ran it live (not the repo file, a copy): google.com -> REACHABLE, a nonexistent host -> class=dns correctly, repositorio-asi.gcba.gob.ar -> REACHABLE today from lezama (consistent with prior measurements that GCABA DNS/route/TLS are fine from here and any failure here is server-side origin-IP filtering, not resolvable client-side). Confirms the classification mechanics actually work, not just read as plausible. ## NOT EXERCISED No live probe/push through the actual script (only a standalone copy of the classifier logic). No test of the tcp/tls/http failure branches against a real server in that state (only dns-failure and full-success exercised live). No test from another GCABA host - source-IP scope named by coder04 as out of scope.
-
audit pass: Diff read per-hunk, bash -n syntax check, classifier logic independently extracted and run live (dns-fail + success cases)
payload
{"scope":"Diff read per-hunk, bash -n syntax check, classifier logic independently extracted and run live (dns-fail + success cases)","outcome":"pass","evidence":"pin 2982dacd unchanged; live test: nonexistent host -> dns, google.com and repositorio-asi.gcba.gob.ar -> reachable","reportRef":null} -
Shipped dev bd3c26c1 / prod ca7ee0ed (v5.6.238). Audit PASSed exact pin 2982dacd81b881419c05a8c52a4adf9f077abb1f3b49fce265fe6cc03bc7213a. Pod confirmed reachable, mirrored to 33517 (patch 238) pending proxy confirm.