Files
takana/docs
SergioandClaude Opus 5 a1ccce2b65 squid mudado — y la jaula arrancaba DEGRADADA cuando la arranca un init
El proxy de salida sirve desde la caja: `squid 7.7` en 2.29.29.217:1137 con la config, el `passwd`
de los tres usuarios y las dos ACL de gioser tal cual, dentro de una instancia qorpa y supervisado
por arje. El de gioser sigue vivo e intacto (7.6). Es un servicio con gente encima: el access.log
del origen mostraba CONNECT a api.anthropic.com y a claude.ai en el minuto anterior a mudarlo.

Control en los dos sentidos: desde una IP no autorizada, 407 igual que el original; desde localhost,
que su propia config permite, TCP_TUNNEL/200 a claude.ai y api.anthropic.com.

EL MURO QUE VALE, y es un bug de qorpa: **el rango de subuid se buscaba por `$USER`**. Una shell
interactiva lo trae; un init NO. Bajo arje la tarjeta arranca con PATH y HOME, el nombre salia
vacio, no habia rango, y la jaula caia al userns de UN SOLO ID — con lo que squid moria en
`setgid(15): (22) Invalid argument` y el supervisor lo reintentaba 80 veces. El aviso de qorpa
estaba impreso y era correcto («no hay rango para "" en /etc/subuid»), pero lo que se ve en el bucle
es el error de squid: **la degradacion silenciosa la paga el de mas abajo**. Y el MISMO comando a
mano funcionaba, porque la shell si pone `$USER`: el sintoma dependia de quien lo arrancaba.

⇒ `nombre_de_usuario()` deriva el nombre del UID REAL leyendo /etc/passwd y el entorno queda como
ultimo recurso, con la mitad pura (`nombre_en_passwd`) probada, control negativo incluido: un uid
que no esta NO inventa un nombre — devolver algo ahi haria buscar un rango ajeno.

Los otros tres muros quedan documentados en §6.27: provisionar ANTES de montar la config (pacman
aborta si el paquete no puede escribir sus defaults), `/dev/shm` que bwrap crea 0755 y squid no
puede usar al bajar a `proxy`, y el pidfile que en una jaula con `--unshare-pid` SIEMPRE parece
fresco porque cada corrida tiene su propio PID 2.

Y la pregunta que corresponde —¿no va en una receta?— con su respuesta: si, y sigue pendiente. La
jaula fue la via urgente. La diferencia con php-fpm importa: PHP no queremos que entre al corpus,
squid es C y su sitio natural es una receta como la de gitea.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 18:59:13 +00:00
..

Documentación de diseño de takana

Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.

Software Design Documents (SDD)

# Documento Qué cubre
00 Visión y filosofía Por qué existe, qué problema resuelve, la actitud de ingeniería
01 Arquitectura general El modelo de dos mundos, componentes, flujo de datos
02 El laboratorio de build Sandbox, zig cc, recetas, CAS, grafo de dependencias
03 Hidratación y store Store content-addressed, hardlinks a FHS, patchelf, rollback
04 Overlay de experimentación overlayfs en caliente, try/commit/discard
05 Diario de mutaciones fanotify, log append-only, config-sin-ser-declarativa
06 Formato .swm Manifiesto de mutación compartible, esquema, firma
07 Bus de init y de agente /run/init.control, /run/agent.sock, protocolo
08 Integración de la IA El bucle agéntico, seguridad, intención → .swm
09 Modelo de confianza Reproducibilidad, verificar-no-confiar, log de transparencia
10 Roadmap Fases, MVP, primer entregable
11 Bootstrap from-scratch Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned
12 arje como init real del Stage 1 Contrato de runtime: seed card, hammerd supervisado, CRASHED real
16 harkaq: la jaula de takana Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad
26 atuq: el envoltorio Gecko Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no
30 Los servicios que trae un paquete [[service]] en la receta → Card de arje; por qué arje-absorb no cubre una distro construida desde fuente; los tres árboles de servicios y cuál es el canónico

Runbooks (operativos)

Runbook Para qué
Validar Stage 1 booteando en QEMU stage0stage1→initramfs→QEMU; criterios de éxito y troubleshooting

Architecture Decision Records (ADR)

Decisiones tomadas, con su contexto y consecuencias. Ver adr/.

# Decisión
0001 Rust para el tooling y daemons
0002 Validar sobre Alpine antes de la distro propia
0003 zig cc como compilador por defecto del lab
0004 No escribir nuestro propio Nix
0005 Hidratación por hardlinks
0006 Commits fijados, no HEAD vivo
0007 arje como init propio del track posterior
0008 Bootstrap en 3 stages, zig como semilla
0009 Código direccionado por contenido (estilo Unison)
0010 Arranque por grafo: el menú de boot como navegación del grafo
0011 Etapa Escritorio: campaña KDE Plasma 6
0012 El árbol de fuentes es caché y workspace a la vez — PENDIENTE, dilema abierto