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…

TOML 815Rust 56Shell 37Markdown 291229 Definiciones

⎇ d611f8577d0ebb0f265143be9007a5b94a7dd1fc recipes/gitea.toml TOML · 140 líneas · 9.2 KB Historia crudo

[[user]] en la receta: la otra mitad del SDD 30 — un demonio que no corre como root necesita cuenta d611f8577 · Sergio ·

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" CXX="zig c++" 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# 916 es el uid que Alpine reserva para `git`/gitea en sus `setup-*`; no hace falta que coincida con
70# nada, hace falta que no se mueva. `shell = /bin/false` por defecto: una cuenta de servicio a la que
71# alguien pueda entrar es una puerta que nadie declaró.
72[[user]]
73name = "gitea"
74uid  = 916
75home = "/var/lib/gitea"
76
77# ── EL SERVICIO QUE ESTE PAQUETE TRAE (SDD 30) ──────────────────────────────────────────────────
78# Fuera de `hash_inputs`: declarar esto NO re-hashea gitea.
79#
80# ⚠ GITEA SE NIEGA A CORRER COMO ROOT, y no es un aviso: es un `[F]` y sale. Medido:
81#
82#     [F] Gitea is not supposed to be run as root. If you need to use privileged TCP ports
83#         please instead use `setcap` and the `cap_net_bind_service` permission.
84#
85# Por eso el `argv` hace `setuidgid gitea` (applet de busybox, comprobado presente) en vez de
86# encarnar el binario directo. Existe `GITEA_I_AM_BEING_UNSAFE_RUNNING_AS_ROOT`; el nombre de la
87# variable ya dice por qué no se usa.
88#
89# ══ LAS DOS GUARDAS, Y POR QUÉ FALLAN RUIDOSAMENTE ═════════════════════════════════════════════
90# Un servidor git sin su `app.ini` y sin su usuario **arranca igual** y se planta más tarde, o peor:
91# arranca con la config de instalación y ofrece el asistente de «crear administrador» a quien pase.
92# Las dos cosas que faltan son del SITIO, no del paquete —vienen de la mudanza junto con los datos—
93# así que la receta no las inventa: comprueba que estén y muere con un mensaje que las nombra.
94#
95#   · `/etc/gitea/app.ini`  ⇒ es config del sitio: dice dónde está la DB y con qué dominio se sirve.
96#   · el usuario `gitea`    ⇒ dueño de `/var/lib/gitea`. **HOY NO EXISTE EN EL PRODUCTO**: el
97#     `/etc/passwd` de la imagen es la constante `takana_bootstrap::PRODUCT_PASSWD` y sólo trae
98#     `root` y `sshd`. El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta; los
99#     USUARIOS siguen donde estaban las Cards. Mientras eso no se declare, el usuario entra con los
100#     datos del sitio (el origen ya lo tiene: `gitea:x:…:/var/lib/gitea`).
101#
102# `arje` no tiene readiness por unidad, así que —igual que el card de `sshd`— lo que haya que esperar
103# o comprobar va DENTRO del `argv`, a la vista, y no escondido en un wrapper.
104#
105# ⚠ TODO con ruta ABSOLUTA (`/bin/grep`, `/usr/bin/setuidgid`), y no por estilo: el `sh` de busybox
106# de la imagen NO está compilado con `FEATURE_SH_STANDALONE`, así que **no despacha sus propios
107# applets** — los resuelve por `PATH`, y PID 1 no garantiza ninguno. Medido: `exec setuidgid …` a
108# secas muere con `sh: exec: line 0: setuidgid: not found`, y el servicio quedaría reintentando para
109# siempre por un `PATH` vacío. En la imagen los symlinks existen (`/usr/bin/setuidgid -> busybox`);
110# nombrarlos completos es lo que hace que eso no dependa del entorno que herede el proceso.
111#
112# ══ LOS DOS QUE SÓLO APARECEN CON EL ENTORNO DE VERDAD (medidos 2026-09-14 en el worker) ═══════
113# arje pasa un `envp` EXPLÍCITO y no hereda el del padre. Corriendo la card con `env -i` —que es lo
114# que de verdad va a pasar— salieron dos fallos que con una shell normal no se ven nunca:
115#
116#   1. `PATH` en el `envp`. **gitea lanza `git` como SUBPROCESO** (`git.InitFull`). Sin `PATH` muere
117#      con `git not found: executable file not found in $PATH`, que se lee como «falta git» cuando
118#      git está instalado y es raíz de `perfil.base`. El envp vacío no es «limpio»: es sin PATH.
119#   2. `cd /var/lib/gitea` en el `argv`. El cwd se HEREDA, y gitea corre `git config` en él: con el
120#      cwd del padre el arranque muere con `fatal: error reading '/root/.git'` — un mensaje que
121#      habla de git y de root, y no de que a la card le falte un directorio de trabajo. `Service` no
122#      tiene campo `cwd`, así que va en el argv, a la vista.
123#
124# ⚠ Y `app.ini` tiene que ser ESCRIBIBLE por `gitea`: si le falta un secreto (p. ej. `JWT_SECRET`)
125# lo genera y lo guarda **en el propio fichero**; con el ini de root muere con `permission denied`.
126# En una instalación mudada ya vienen todos, pero el modo correcto es `gitea:gitea 0660`.
127#
128# ══ VERIFICADO DE PUNTA A PUNTA ════════════════════════════════════════════════════════════════
129# Con este argv exacto y `env -i`: escucha en su puerto, `GET /` responde **200**, y el proceso
130# corre como **gitea**. Las dos guardas probadas por separado: sin `app.ini` ⇒ 78 con su mensaje;
131# con `app.ini` y sin el usuario ⇒ 78 con el suyo.
132[[service]]
133label      = "gitea"
134id         = "01M2EKDA00NKYGE2BB5DFH1EFF"
135exec       = "/bin/busybox"
136argv = ["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"]
137envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/gitea"], ["GITEA_WORK_DIR", "/var/lib/gitea"], ["USER", "gitea"]]
138networking = "full"
139cgroup     = "arje.slice/gitea"
140restart    = { initial_ms = 1000, max_ms = 30000 }