gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

⎇ main scripts/servidor/claude-caja.sh Shell · 192 lines · 13.0 KB History raw

fix(qorpa): la jaula le borraba a claude la variable que lo saca de la pantalla alterna a185cd521 · Sergio ·

1#!/bin/sh
2# claude — entrar al agente en esta caja. El CLI es glibc y la caja es musl: corre enjaulado
3# (ADR 0015), con el repo, el store, el lab, la memoria y las llaves concedidos y nada más.
4#
5# ── UNA JAULA POR PERSONA, Y SIN PRIVILEGIO ─────────────────────────────────────────────────────
6# `root` usa la instancia `claude`; cada usuario usa `claude-<usuario>`. No es purismo: la instancia
7# concede el HOME de quien entra —su `.claude`, o sea sus credenciales y su memoria— y una sola
8# instancia obligaría a compartirlo. Medido: con la instancia de root, `sergio` muere en
9# `bwrap: Can't mkdir /root/.claude: Permission denied`.
10#
11# ⚠ Y NO se eleva con `doas`/`sudo`: en esta caja **el setuid no toma** («doas: Operation not
12# permitted», con `NoNewPrivs: 0` y `/` sin `nosuid` — queda como deuda entender por qué). No hace
13# falta: `qorpa run` levanta la jaula con user namespaces y anda **sin privilegio**, siempre que el
14# directorio de la instancia sea del usuario.
15#
16# ⚠ Y LOS BUILDS **SÍ CORREN DENTRO DE LA JAULA** — medido el 2026-09-18 por el agente de adentro,
17# y corrige lo que decía este comentario. Dos recetas construidas y SELLADAS desde la jaula, con el
18# hash forzado para que no hubiera caché:
19#   · `anew` (Go, estática)  — fetch → `go mod vendor` → compile → sealed, 6,8 s
20#   · `lz4`  (C, estática)   — `make` + `make install` escribiendo `/out` → sealed, 4,4 s
21# Con `root = false` el bwrap anidado se levanta y `/proc` monta. Lo que NO se probó es una receta
22# cuyo `install` fije DUEÑOS: ahí sí muerde que el anidado no pueda mapear el uid 0, porque `sergio`
23# no tiene rango en `/etc/subuid` (sólo lo tiene `root`) y `newuidmap`/`newgidmap` no son setuid.
24#
25# ⚠ SE INTENTÓ CERRARLO Y **NO ALCANZÓ** (2026-09-18). Se hicieron las dos cosas obvias:
26#   · rango para `sergio` en `/etc/subuid` y `/etc/subgid` (165536:65536);
27#   · `newuidmap`/`newgidmap` en setuid root **y además** con capacidades (`cap_setuid=ep`).
28# El error se MOVIÓ —ya no dice «no hay rango para sergio»— pero sigue sin mapear:
29#
30#     ⚠ sin mapeo por rango (newuidmap: open of uid_map failed: Permission denied)
31#
32# Lo que quedó descartado, medido: **el setuid sí eleva en esta caja** —sonda en C compilada con el
33# `cc` nuevo: `uid=1001 euid=0`—, `/` no está `nosuid`, y el `uid_map` del proceso es suyo
34# (`-rw-r--r-- sergio:sergio`). O sea que no es ni el rango que faltaba ni el bit que no tomaba.
35# ⚠ Y un detalle que cuesta un rato si no se sabe: **`chown` BORRA el bit setuid**, así que hay que
36# chownear primero y poner el bit después; la primera sonda salió sin bit por ese orden.
37# La causa de fondo queda SIN DETERMINAR, y se dice así en vez de inventarla.
38#
39# Mientras tanto el camino que sí anda es pedírselo al ANFITRIÓN por ssh:
40#
41#   ssh -p 22022 root@127.0.0.1 'cd /opt/takana && flock -o work/.farm-build.lock takana build <r>'
42#
43# ⚠ Y UNA JAULA QUE TE MAPEA A ROOT ROMPE AL PROPIO AGENTE: con `root = true` el CLI se ve uid 0 y
44# **rechaza `--dangerously-skip-permissions`** («cannot be used with root/sudo privileges»). Por eso
45# las instancias de PERSONA van con `root = false` (queda uid 1001 adentro) y con `/store` en `rw`,
46# que es lo que la de `root` ya tenía y a la de `sergio` le faltaba: sin eso el agente lee el store
47# y no puede sellar nada.
48set -eu
49
50# ⚠ `/usr/bin/claude` ES UN ENLACE A ESTE FICHERO, y lo es por algo (2026-09-18): antes era una
51# COPIA, así que arreglar el guion en el repo no cambiaba nada para quien escribe `claude` — el
52# usuario reportó dos veces «sigue abriendo en /opt/takana» con el arreglo ya pusheado y tirado en la
53# caja. Un instalado que es copia DERIVA en silencio y sólo se nota por el síntoma viejo.
54#
55#   ln -sf /opt/takana/scripts/servidor/claude-caja.sh /usr/bin/claude
56_yo="$(id -un)"
57_hogar="${HOME:-/root}"
58_base="claude"
59[ "$_yo" != "root" ] && _base="claude-$_yo"
60
61# ── VARIAS SESIONES A LA VEZ ────────────────────────────────────────────────────────────────────
62# El kernel niega DOS overlays sobre el mismo `upper` —la capa mutable se corrompería— y eso no se
63# discute. Pero «un solo Claude» era empaquetado nuestro, no del kernel: instancias distintas tienen
64# `upper` distintos y conviven. Así que si la de siempre está ocupada, se usa la siguiente.
65#
66# ⚠ La instancia nueva NO se aprovisiona: se CLONA la capa ya hecha. Con un mapa de un solo id
67# —lo que hay hoy, ver §6.55— `pacman` no puede chownear su descarga y el `provision` muere en
68# «failed to chown temporary download directory». Copiar el `upper` cuesta ~1 s y 169 M y no depende
69# de eso. Cuando el mapeo por rango funcione, `takana qorpa provision` vuelve a ser el camino.
70BASEDIR=${BASEDIR:-/var/lib/hammer/qorpa/instances}
71_libre() { ! pgrep -f "[q]orpa run $1 " >/dev/null 2>&1; }
72
73_inst="$_base"; _n=2
74while ! _libre "$_inst"; do
75  _inst="$_base-$_n"; _n=$((_n+1))
76  # ⚠ ACÁ HABÍA UN TOPE DURO DE 10 Y SE FUE (2026-09-25, a pedido del operador).
77  #
78  # Lo que decía el comentario viejo sigue siendo cierto: el kernel sólo prohíbe DOS overlays
79  # sobre el mismo `upper`, y de eso ya se encarga el bucle clonando la capa siguiente. El techo
80  # real es la RAM. Lo que estaba mal era el `exit 1`: un número elegido a dedo que le decía «no»
81  # con la máquina a medio usar.
82  #
83  # Y contaba TODAS las jaulas del usuario sin decir CUÁLES. Medido el 25-sep, que es la queja que
84  # lo tumbó: el operador tenía 4 tabs de un proyecto abiertos y 6 sesiones de OTRO proyecto que no
85  # estaba mirando, y el mensaje sólo sabía decir «hay 10 — cerrá alguna». Él contó su grupo de
86  # tabs, el script contaba global, y ninguno de los dos estaba equivocado. Contar sin mostrar qué
87  # se cuenta es lo que hacía que el tope se leyera como capricho: no había forma de saber que las
88  # otras seis existían, ni que se llevaban 1,9 G y tenían el swap al 70 %.
89  #
90  # Ahora avisa UNA vez, con la evidencia medida y con el proyecto de cada jaula, y DEJA PASAR.
91  # El modo de falla de pasarse es el OOM (INFORME-CAIDA-2026-08-17, la caída fue con ocho
92  # adentro), y decidirlo con los números a la vista es del operador, no de esta línea.
93  if [ "$_n" -gt 11 ] && [ -z "${_avisado:-}" ]; then
94    _avisado=1
95    {
96      echo "claude: van $((_n - 2)) jaulas de $_base abiertas. No te freno — mirá la máquina y decidí:"
97      awk '/^MemAvailable:/{a=$2} /^SwapTotal:/{st=$2} /^SwapFree:/{sf=$2}
98           END{printf "  RAM libre %d M · swap %d/%d M (%d%%) · ~310 M por sesión ⇒ entran ~%d más\n",
99                      a/1024, (st-sf)/1024, st/1024, (st ? 100*(st-sf)/st : 0), a/1024/310}' /proc/meminfo
100      echo "  las que ya están (jaula · proyecto):"
101      pgrep -af "[q]orpa run $_base" 2>/dev/null | while read -r _pid _resto; do
102        _hijo=$(pgrep -P "$_pid" 2>/dev/null | head -1)
103        printf "    %-22s %s\n" \
104          "$(printf '%s' "$_resto" | awk '{print $4}')" \
105          "$(readlink "/proc/${_hijo:-0}/cwd" 2>/dev/null || echo '?')"
106      done
107    } >&2
108  fi
109  # Corte de seguridad, NO política: si `pgrep` contestara «ocupada» para siempre —un `/proc`
110  # inconsistente, un nombre que casa de más— sin el `exit 1` de antes esto era un bucle infinito.
111  # 64 está tan por encima de cualquier uso real que sólo lo alcanza una falla.
112  [ "$_n" -gt 65 ] && { echo "claude: 64 jaulas de $_base y todas ocupadas — eso es una falla de conteo, no uso. Mirá \`pgrep -af \"qorpa run $_base\"\`." >&2; exit 1; }
113done
114if [ ! -d "$BASEDIR/$_inst" ]; then
115  echo "claude: abro una sesión más ($_inst) — clonando la capa, ~1 s" >&2
116  # ⚠ SIN RETROREFERENCIAS: acá había un `sed` con `\1` y el fichero terminó guardando el
117  # BYTE 0x01 en su lugar, así que el sha salía como el carácter de control y `qorpa create`
118  # moría con «ninguna imagen empieza por "\u{1}"». `awk` parte por comillas y no tiene
119  # nada que una herramienta pueda reinterpretar.
120  _sha=$(awk -F\" '/^base *=/ {sub(/^sha256:/,"",$2); print $2; exit}' "$BASEDIR/$_base/instance.toml")
121  [ -n "$_sha" ] || { echo "claude: no pude leer el sha de la imagen en $BASEDIR/$_base/instance.toml" >&2; exit 1; }
122  takana qorpa create "$_inst" --base "$_sha" >/dev/null || { echo "claude: no pude crear $_inst" >&2; exit 1; }
123  cp "$BASEDIR/$_base/instance.toml" "$BASEDIR/$_inst/instance.toml"
124  rm -rf "$BASEDIR/$_inst/upper"
125  cp -a "$BASEDIR/$_base/upper" "$BASEDIR/$_inst/upper"
126  mkdir -p "$BASEDIR/$_inst/work"
127fi
128
129# El `cd` no es comodidad: la memoria del agente se indexa POR RUTA DE TRABAJO. Desde `/` —que es
130# donde `qorpa run` deja el shell— la sesión usa el proyecto `-` y el agente empieza sin saber nada
131# aunque su memoria esté en disco.
132#
133# ⚠ **Y ABRE DONDE ESTÁS PARADO, no en un sitio fijo** (2026-09-18). Antes el destino era
134# `/opt/takana` cableado, así que `cd /work/sergio/takana && claude` abría… `/opt/takana`: el agente
135# contestaba sobre OTRO árbol —el del root— y encima con la memoria de ese proyecto. Se reportó como
136# «entro al repo y claude sigue en /opt/takana», y era literal. Ahora el defecto es `$PWD`; el
137# cableado queda sólo para cuando no hay `PWD` utilizable.
138#
139# `PROY` sigue existiendo para abrirlo sobre otro árbol a propósito:
140#
141#   PROY=/work/sergio/tawasuyu claude
142# ⚠ El `shift 2` no es adorno: sin él, el HOME y el proyecto que se pasan como posicionales se
143# cuelan COMO ARGUMENTOS del agente. Medido: la primera versión abrió la sesión con el prompt
144# «/home/sergio», y el agente contestó —con razón— que eso es una ruta, no un comando.
145# ⚠ El `cd` de adentro FALLA RUIDOSAMENTE: la jaula sólo monta los directorios concedidos, así que
146# desde una ruta no concedida el `cd` no encuentra nada. Antes eso se tragaba con `&&` y el agente
147# arrancaba en `/` sin decir por qué; ahora lo dice y sale.
148_proy="${PROY:-$PWD}"
149[ -d "$_proy" ] || _proy=/opt/takana
150
151# ── LO QUE SHUMA DECLARA Y LA JAULA BORRABA ─────────────────────────────────────────────────────
152# `bwrap` entra con `--clearenv` (ADR 0015: el ambiente también es una concesión), así que TODO lo
153# que el agente de shuma puso en el PTY se perdía en la frontera. Medido el 2026-09-28 sobre las
154# tres sesiones vivas: **7 variables adentro**, y ninguna de las del renderer.
155#
156# La que más cuesta es `CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN`, que `shuma_config::agente::
157# vars_del_renderer` pone en CADA PTY del agente justamente para que no pase esto: sin ella el CLI
158# se va a **pantalla alterna**, y ahí el cliente no puede hacer dos cosas —las dos reportadas como
159# defecto el 28-sep—:
160#   · el reconocimiento en vuelo del cromo de claude no se dispara ni una vez ⇒ «me sale plano»;
161#   · la cosecha del historial **saltea el alt-screen a propósito** (`TuiSession::ingerir`,
162#     `if screen.alternate_screen() { return }`) ⇒ al volver a la pestaña sólo está la pantalla
163#     viva, «sólo poquito output, lo último escrito».
164# O sea: el arreglo estaba puesto del lado del agente desde el 2026-09-04 y esta línea lo anulaba.
165#
166# `COLORTERM` va por lo mismo (sin él el CLI degrada a 256 colores) y `SHUMA_SESSION` porque es lo
167# que le deja a un hook enlazar a ESTA sesión y no a otra.
168#
169# Viaja como UN posicional con tokens `K=V` separados por espacios, y se expande **sin comillas** a
170# propósito: `env` recibe un argumento por token. Ninguno de estos valores lleva espacios (un `1`,
171# `truecolor`, un ULID); el día que haga falta uno que sí, esto pide otra forma de pasarlo.
172_lleva=
173for _v in CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY COLORTERM SHUMA_SESSION; do
174  eval "_val=\${$_v:-}"
175  [ -n "$_val" ] && _lleva="$_lleva $_v=$_val"
176done
177
178exec takana qorpa run "$_inst" -- sh -c \
179  'hogar="$1"; proy="$2"; yo="$3"; lleva="$4"; shift 4
180   cd "$proy" 2>/dev/null || { echo "claude: adentro de la jaula no existe \"$proy\" — ¿está concedido ese directorio en la instancia? (ver grants.dirs)" >&2; exit 1; }
181   # `/work/<usuario>/bin` trae el toolchain del CORPUS (make, python3, rustc, cargo, takana…):
182   # musl estáticos del store, que corren dentro de la imagen glibc. Lo arma jaula-herramientas.sh.
183   # ⚠ EL PATH DEL LAB, que ningún doc decía y muerde en el primer build (2026-09-18, reportado por
184   # el agente de adentro): `takana build` invoca `go` y `zig` por nombre, y en la imagen de la jaula
185   # no están. Muere con `spawn go mod vendor: No such file or directory`, que no menciona el PATH.
186   # Viven en el lab, que ya está concedido.
187   # shellcheck disable=SC2086  # `$lleva` se parte en tokens K=V a propósito — ver arriba
188   exec env HOME="$hogar" TERM="${TERM:-xterm-256color}" \
189        PATH="/work/$yo/bin:/work/dev-fs/tools/go/bin:/work/dev-fs/tools/zig:$PATH" \
190        $lleva \
191        /work/claude-cli/2.1.240 "$@"' \
192  _ "$_hogar" "$_proy" "$_yo" "$_lleva" "$@"