sergio/takana

1# gitea — el servidor git que hoy corre en gioser y que la mudanza tiene que levantar del otro lado.
2#
3# ══ POR QUÉ EL TARBALL DE RELEASE Y NO `repo` + `commit` ═══════════════════════════════════════
4# El clon del repo NO alcanza para construir un gitea que sirva: la UI se compila con Node
5# (`make frontend` ⇒ `public/assets/`) y las deps Go no están vendoreadas en git. El tarball
6# `gitea-src-<ver>.tar.gz` que publica upstream trae las dos cosas ya hechas — medido sobre el de
7# 1.27.0: `public/assets/` 764 entradas, `vendor/` 11246, `templates/` 663 — así que se construye
8# con el lab tal cual, sin Node y sin red (`GOFLAGS=-mod=vendor GOPROXY=off`). Es también lo que
9# hacen Alpine y nixpkgs. La URL es locator y no entra en `hash_inputs` (ADR 0013): lo que ancla
10# la identidad es el `sha256`.
11#
12# ══ LOS TRES TAGS, Y POR QUÉ SIN ELLOS EL BINARIO SELLA Y NO SIRVE ═════════════════════════════
13# La receta anterior (1.26.4, sin tags, CGO off) producía un gitea que construye, reproduce y
14# **no puede abrir la base de datos**. Medido contra el binario sellado `b3:35bb4f04…`:
15#
16#     $ gitea --config app.ini migrate
17#     Error: sqlite3 requires: -tags sqlite,sqlite_unlock_notify
18#     this Gitea binary was not built with SQLite3 support
19#
20# y `gitea --version` decía `version development` (sin el `-X main.Version`). gioser guarda sus 28
21# repos con `DB_TYPE = sqlite3`, así que ese artefacto no sirve para la mudanza: es
22# [[subcomando-sin-driver]] otra vez — sellado, con contenido, reproducible e inútil.
23#
24#   · `sqlite` + `sqlite_unlock_notify` → el driver de mattn, que es C ⇒ obliga a `cgo = true`.
25#   · `bindata`                         → embebe `public/` y `templates/` en el binario. Sin él el
26#                                         servidor los busca en disco y la receta sólo publica el
27#                                         ejecutable: arrancaría sin UI.
28#
29# ⚠ La versión se PASA por `-ldflags -X`: no se deduce del árbol. Y no es cosmética — gitea migra
30# el esquema hacia adelante al arrancar y se planta si la DB trae migraciones más nuevas que el
31# binario, así que el pin tiene que ir por delante del que corre en el origen (gioser: 1.27.0).
32name    = "gitea"
33version = "1.27.0"
34license = "MIT"
35
36[source]
37tarball = "https://github.com/go-gitea/gitea/releases/download/v1.27.0/gitea-src-1.27.0.tar.gz"
38sha256  = "012df875bfa7764ade92301ac5e4225fc2c2aab7b3b40b4d6e7149a926253496"
39
40[build]
41compiler = "zig-cc"
42target   = "x86_64-linux-musl"
43link     = "static"
44flags    = []
45cgo      = true   # driver sqlite3 (mattn) con C bundled — necesita cgo, igual que usql/sq
46
47[deps]
48build = ["go"]
49
50[build.phases]
51configure = "true"
52compile   = """
53export GOCACHE=/src/.gocache GOTMPDIR=/src/.gotmp GOPATH=/tmp/gopath GOTOOLCHAIN=local \
54  CGO_ENABLED=1 CC="zig cc -mcpu=baseline" CXX="zig c++ -mcpu=baseline" GOFLAGS=-mod=vendor GOPROXY=off
55mkdir -p /src/.gotmp /out/usr/bin
56go build -trimpath -tags 'bindata sqlite sqlite_unlock_notify' \
57  -ldflags '-buildid= -linkmode=external -extldflags=-static -X "main.Version=1.27.0" -X "main.Tags=bindata sqlite sqlite_unlock_notify"' \
58  -o /out/usr/bin/gitea .
59"""
60install   = "true"
61
62# ── LA CUENTA QUE ESTE PAQUETE NECESITA (SDD 30) ────────────────────────────────────────────────
63# Fuera de `hash_inputs`: declarar esto NO re-hashea gitea.
64#
65# El `uid` se DECLARA y no se asigna, igual que el ULID de la Card: un «primero libre a partir de
66# 1000» hace que dos imágenes del mismo perfil salgan con dueños distintos y el rootfs deje de
67# reproducir **sin que nada falle** — los ficheros se ven iguales y `ls -l` dice otro número.
68#
69# ⚠ **969 NO es un número arbitrario: es el uid que gitea tiene EN GIOSER**, y alinearlo es lo que
70# hace barata la mudanza. Los 2,0 G de `/var/lib/gitea` llegan con su uid NUMÉRICO puesto; si el
71# destino usara otro, o se chownean 2 G (lento, y hay que acordarse) o gitea no puede leer sus
72# propios datos — y eso no falla al copiar, falla al arrancar. Medido en el ensayo con datos reales
73# (SDD 28 §6.13): los ficheros llegaron como `1001` y hubo que chownear a mano.
74# `shell = /bin/false` por defecto: una cuenta de servicio a la que alguien pueda entrar es una
75# puerta que nadie declaró.
76[[user]]
77name = "gitea"
78uid  = 969
79home = "/var/lib/gitea"
80
81# ── EL SERVICIO QUE ESTE PAQUETE TRAE (SDD 30) ──────────────────────────────────────────────────
82# Fuera de `hash_inputs`: declarar esto NO re-hashea gitea.
83#
84# ⚠ GITEA SE NIEGA A CORRER COMO ROOT, y no es un aviso: es un `[F]` y sale. Medido:
85#
86#     [F] Gitea is not supposed to be run as root. If you need to use privileged TCP ports
87#         please instead use `setcap` and the `cap_net_bind_service` permission.
88#
89# Por eso el `argv` hace `setuidgid gitea` (applet de busybox, comprobado presente) en vez de
90# encarnar el binario directo. Existe `GITEA_I_AM_BEING_UNSAFE_RUNNING_AS_ROOT`; el nombre de la
91# variable ya dice por qué no se usa.
92#
93# ══ LAS DOS GUARDAS, Y POR QUÉ FALLAN RUIDOSAMENTE ═════════════════════════════════════════════
94# Un servidor git sin su `app.ini` y sin su usuario **arranca igual** y se planta más tarde, o peor:
95# arranca con la config de instalación y ofrece el asistente de «crear administrador» a quien pase.
96# Las dos cosas que faltan son del SITIO, no del paquete —vienen de la mudanza junto con los datos—
97# así que la receta no las inventa: comprueba que estén y muere con un mensaje que las nombra.
98#
99#   · `/etc/gitea/app.ini`  ⇒ es config del sitio: dice dónde está la DB y con qué dominio se sirve.
100#   · el usuario `gitea`    ⇒ dueño de `/var/lib/gitea`. **HOY NO EXISTE EN EL PRODUCTO**: el
101#     `/etc/passwd` de la imagen es la constante `takana_bootstrap::PRODUCT_PASSWD` y sólo trae
102#     `root` y `sshd`. El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta; los
103#     USUARIOS siguen donde estaban las Cards. Mientras eso no se declare, el usuario entra con los
104#     datos del sitio (el origen ya lo tiene: `gitea:x:…:/var/lib/gitea`).
105#
106# `arje` no tiene readiness por unidad, así que —igual que el card de `sshd`— lo que haya que esperar
107# o comprobar va DENTRO del `argv`, a la vista, y no escondido en un wrapper.
108#
109# ⚠ TODO con ruta ABSOLUTA (`/bin/grep`, `/usr/bin/setuidgid`), y no por estilo: el `sh` de busybox
110# de la imagen NO está compilado con `FEATURE_SH_STANDALONE`, así que **no despacha sus propios
111# applets** — los resuelve por `PATH`, y PID 1 no garantiza ninguno. Medido: `exec setuidgid …` a
112# secas muere con `sh: exec: line 0: setuidgid: not found`, y el servicio quedaría reintentando para
113# siempre por un `PATH` vacío. En la imagen los symlinks existen (`/usr/bin/setuidgid -> busybox`);
114# nombrarlos completos es lo que hace que eso no dependa del entorno que herede el proceso.
115#
116# ══ LOS DOS QUE SÓLO APARECEN CON EL ENTORNO DE VERDAD (medidos 2026-09-14 en el worker) ═══════
117# arje pasa un `envp` EXPLÍCITO y no hereda el del padre. Corriendo la card con `env -i` —que es lo
118# que de verdad va a pasar— salieron dos fallos que con una shell normal no se ven nunca:
119#
120#   1. `PATH` en el `envp`. **gitea lanza `git` como SUBPROCESO** (`git.InitFull`). Sin `PATH` muere
121#      con `git not found: executable file not found in $PATH`, que se lee como «falta git» cuando
122#      git está instalado y es raíz de `perfil.base`. El envp vacío no es «limpio»: es sin PATH.
123#   2. `cd /var/lib/gitea` en el `argv`. El cwd se HEREDA, y gitea corre `git config` en él: con el
124#      cwd del padre el arranque muere con `fatal: error reading '/root/.git'` — un mensaje que
125#      habla de git y de root, y no de que a la card le falte un directorio de trabajo. `Service` no
126#      tiene campo `cwd`, así que va en el argv, a la vista.
127#
128# ⚠ Y `app.ini` tiene que ser ESCRIBIBLE por `gitea`: si le falta un secreto (p. ej. `JWT_SECRET`)
129# lo genera y lo guarda **en el propio fichero**; con el ini de root muere con `permission denied`.
130# En una instalación mudada ya vienen todos, pero el modo correcto es `gitea:gitea 0660`.
131#
132# ══ VERIFICADO DE PUNTA A PUNTA ════════════════════════════════════════════════════════════════
133# Con este argv exacto y `env -i`: escucha en su puerto, `GET /` responde **200**, y el proceso
134# corre como **gitea**. Las dos guardas probadas por separado: sin `app.ini` ⇒ 78 con su mensaje;
135# con `app.ini` y sin el usuario ⇒ 78 con el suyo.
136[[service]]
137label      = "gitea"
138id         = "01M2EKDA00NKYGE2BB5DFH1EFF"
139exec       = "/bin/busybox"
140argv = ["sh", "-c", "test -f /etc/gitea/app.ini || { echo 'gitea: falta /etc/gitea/app.ini — es config del SITIO, viene con los datos' >&2; exit 78; }; /bin/grep -q '^gitea:' /etc/passwd || { echo 'gitea: no existe el usuario `gitea` en /etc/passwd y gitea NO corre como root' >&2; exit 78; }; cd /var/lib/gitea || exit 78; exec /usr/bin/setuidgid gitea /usr/bin/gitea web --config /etc/gitea/app.ini"]
141# ⚠ **`GOMEMLIMIT` — medido el 2026-10-20, y la causa NO era un leak.**
142# gitea llevaba 10 días corriendo con **4,29 GB de RSS** en una caja de 7,7 GB (54 %), con el swap
143# en 3,7 GB y un pico virtual de 12 GB. El sospechoso habitual estaba descartado:
144# `REPO_INDEXER_ENABLED` NO está puesto, así que el indexador de código —el que normalmente se come
145# la RAM en gitea— está apagado.
146#
147# Lo que había era **ningún techo de memoria en ningún nivel**: `rlimits.mem_bytes` a `null`, el
148# cgroup `arje.slice/gitea` declarado pero SIN crear en `/sys/fs/cgroup`, y ni `GOMEMLIMIT` ni
149# `GOGC` en este `envp`. Sin límite, el runtime de Go conserva mapeada la arena que ya liberó: el
150# RSS se queda en la marca de agua más alta que tocó y no vuelve.
151#
152# ⚠ Y la marca de agua la explica la CARGA, no un defecto de gitea: medido sobre los logs de un día,
153# **621.000 peticiones desde 66.401 IPs distintas** con user-agents de navegador falsos, recorriendo
154# combinatoriamente `/src` (274k), `/commits` (102k), `/blame` (81k) y `/raw` (56k) de
155# `tawasuyu/tawasuyu`. 600.000 de ellas con status 200, o sea renderizadas: resaltado de sintaxis y
156# `blame`, que es lo más caro que gitea sabe hacer. Es scraping de forja, no tráfico.
157#
158# ⇒ `GOMEMLIMIT` es un límite **BLANDO**: el GC aprieta más para no pasarse, y el proceso **no
159# muere**. Es deliberadamente lo contrario de `rlimits.mem_bytes`, que sería duro y haría que arje
160# la reiniciara en bucle cada vez que un `blame` grande tocara el techo — peor que el problema.
161#
162# 2 GiB deja ~5,7 GB para el resto (los builds del corpus piden 2-3 GB en pico). El coste es más CPU
163# en GC bajo esta carga; es el intercambio correcto en una caja que, llena, **no se degrada: se cae
164# entera**.
165#
166# ⚠ Esto trata el SÍNTOMA. La causa es el saqueo, y su sitio es el proxy (hoy `saywa`): limitar o
167# cortar `/blame`, `/commits` y `/raw` a anónimos. Eso es decisión de política del sitio, no de esta
168# receta.
169envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/gitea"], ["GITEA_WORK_DIR", "/var/lib/gitea"], ["USER", "gitea"], ["GOMEMLIMIT", "2GiB"]]
170networking = "full"
171cgroup     = "arje.slice/gitea"
172restart    = { initial_ms = 1000, max_ms = 30000 }