El DNS de `takana-os.net` y `www` quedó apuntado, así que Caddy sacó el
certificado de Let's Encrypt (vence el 2026-12-20) y el sitio responde 200. Un
detalle que costó dos minutos y no estaba escrito: **el vhost se había puesto
ANTES del DNS**, y Caddy no reintenta al instante — se queda en su backoff y el
nombre sigue mudo aunque el registro ya esté. `arjectl restart caddy` fuerza el
reintento; anotado en el README del sitio.
Dos nombres más, y los dos SÓLO redirigen:
takana.gioser.net → 301 a takana-os.net (la página vieja, la de hermanas.py)
git.takana-os.net → 301 a git.gioser.net (⏳ le falta el registro A)
`git.takana-os.net` no sirve gitea y no es por pereza: gitea tiene UN `ROOT_URL`
con el que arma cada enlace absoluto y cada URL de clon que muestra la UI.
Colgarlo de un segundo nombre daría un sitio que se contradice —entrás por uno y
te ofrece clonar del otro— y moverlo de verdad rompe los clones y el CI que ya
apuntan al viejo. `git clone` sigue el 301 sin chistar.
⚠ `publicar-webs.sh` comparaba `takana.gioser.net` contra el fichero en disco, y
eso ya no aplica: ahora es un 301. Se separó el control en dos —`comprobar` por
sha contra el disco, `redirige` por destino— y `takana-os.net` entra en el
primero. Lo que NO entra es el `pull`: su raíz es el árbol de trabajo que los
agentes editan, y tirar de ahí mueve HEAD bajo los pies de otro (CLAUDE.md §2 ter).
⚠ Y la primera versión de `redirige()` preguntaba por `getent hosts` quién
resuelve: **en esta caja `getent` NO EXISTE** —musl/busybox no lo traen— así que
daba 127 para todo y declaraba «no resuelve todavía» hasta de los nombres que
estaban andando. Un control que nunca mira nada se ve igual que uno en verde; es
la lección del reaper otra vez. Ahora se lo pregunta a curl, por su código 6.
Corrido entero: 4 verdes por contenido, 1 por destino, 1 avisando del A que falta.
La página suma los dos verbos que ya se pueden correr contra el repo remoto sin
construir nada (`repo list` y `repo verify`), que es el commit de al lado.
takana-os.net — el sitio del proyecto
Una sola página, autocontenida, en dos idiomas y dos temas. No le pide nada a terceros: las
tipografías de la marca (Chivo e IBM Plex, las dos SIL OFL) viajan acá en fuentes/, subconjuntos
latin y latin-ext, 154 KB en total. Un sitio sobre no depender de binarios ajenos que cargara
las fuentes de Google en cada visita sería una contradicción barata.
index.html |
la página entera: CSS y JS adentro, el símbolo como <symbol> SVG inline |
fuentes.css + fuentes/ |
las ocho caras @font-face, servidas de acá |
simbolo.svg |
el favicon — el martillo tocapu 7×7, derivado de docs/marca/simbolo-fondo-claro.svg |
La paleta y la tipografía salen de docs/marca/README.md y no se inventan acá. La única
desviación, deliberada: en tema claro el texto de acento usa un brasa oscurecido (#9E3F16), porque
el #DF6B2A de la marca sobre alpaca da 2,9:1 y no se lee. Las combinaciones de la página están
medidas: ninguna baja de 4,5:1.
Las dos direcciones que publica
- código →
https://git.gioser.net/sergio/takana(público;git clonepor HTTPS) - paquetes →
https://takana-os.net/repo/, que es el MISMO/srv/repofirmado que sirverepo.gioser.net. Comprobado:takana install age --repo https://repo.gioser.net --trust ./trustresponderelease: trusted (by release).
Y desde el 2026-09-21 se puede mirar el repo sin construir nada, que antes no se podía:
repo list y repo verify aceptan la misma lista de orígenes que install. Hasta ese día sólo
miraban directorios locales y ante una URL respondían «repo vacío» con salida 0 — 173 paquetes
leídos como ninguno.
takana repo list --repo https://takana-os.net/repo # 173 paquete(s)
takana repo verify --repo https://takana-os.net/repo --trust ./trust # release: trusted
Cómo se sirve
Caddy, en la caja takana, vhost takana-os.net, www.takana-os.net. La raíz es
/work/sergio/takana/web/takana-os.net, el árbol de trabajo vivo: publicar es guardar el
fichero. No lo refresca publicar-webs.sh a propósito — un pull sobre el árbol compartido mueve
HEAD bajo los pies de otro agente (CLAUDE.md §2 ter).
Este README no se sirve: son notas de operación, y el matcher del vhost las 404ea.
Los bloques, por si hay que rehacer la caja (caddy validate → arjectl restart caddy, nunca
caddy reload: el Caddyfile lleva admin off, SDD 28 §6.14):
takana-os.net, www.takana-os.net {
import acceso
encode gzip zstd
redir /repo /repo/ permanent
handle_path /repo/* {
root * /srv/repo
file_server browse
}
handle {
root * /work/sergio/takana/web/takana-os.net
@oculto path /.* */.* /README.md
respond @oculto 404
file_server
}
}
git.takana-os.net {
import acceso
redir https://git.gioser.net{uri} permanent
}
takana.gioser.net {
import acceso
redir https://takana-os.net{uri} permanent
}
scripts/servidor/publicar-webs.sh comprueba los cuatro: los dos que sirven ficheros por sha
contra el disco, y los dos que redirigen por destino.
Los nombres
| nombre | qué hace | estado |
|---|---|---|
takana-os.net, www |
el sitio | ✅ con certificado de Let's Encrypt (2026-09-21) |
takana-os.net/repo/ |
el repo de paquetes, el mismo /srv/repo |
✅ |
takana.gioser.net |
301 → takana-os.net |
✅ |
git.takana-os.net |
301 → git.gioser.net |
⏳ vhost puesto, falta el registro A |
git.takana-os.net sólo redirige, y es deliberado: gitea tiene UN ROOT_URL con el que arma cada
enlace y cada URL de clon que muestra, así que colgarlo de un segundo nombre daría un sitio que se
contradice —entrás por uno y te ofrece clonar del otro— y moverlo de verdad rompe los clones y el
CI que ya apuntan al viejo.
Los registros van a 2.29.29.217, la IP de la caja:
takana-os.net. A 2.29.29.217 ✅ puesto
www.takana-os.net. A 2.29.29.217 ✅ puesto
git.takana-os.net. A 2.29.29.217 ⏳ falta
El certificado sale solo en la primera petición tras el DNS — y tarda unos segundos más que el
primer curl: si da error, reintentar antes de ir a mirar logs (SDD 28 §6.14). Si el nombre ya
resolvía cuando Caddy arrancó pero el certificado no llegó, reiniciar caddy fuerza el reintento
sin esperar el backoff: fue lo que hizo falta acá.