takana

2,745 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
SergioandClaude Opus 5	d611f8577d	[[user]] en la receta: la otra mitad del SDD 30 — un demonio que no corre como root necesita cuenta El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta. Los USUARIOS se quedaron donde estaban las Cards: `/etc/passwd` de la imagen es `takana_bootstrap::PRODUCT_PASSWD`, un literal con `root` y `sshd`, y añadir un tercero era editar Rust y recompilar takana. No es simetría por elegancia, es un servicio que no arranca: `gitea` se niega a correr como root, su Card hace `setuidgid gitea`, y sin la cuenta arranca, muere y reintenta para siempre con un log que dice `unknown user` — no «a la imagen le falta una cuenta». [[user]] name = "gitea" uid = 916 home = "/var/lib/gitea" El uid se declara, no se asigna, por la misma razón que el ULID de la Card: un «primero libre a partir de 1000» hace que dos imágenes del mismo perfil salgan con dueños distintos y el rootfs deje de reproducir SIN QUE NADA FALLE — los ficheros se ven iguales y `ls -l` dice otro número. Fuera de `hash_inputs`, medido: el hash de gitea no se movió (`b3:391a613e…` antes y después). `takana users <recetas…> [--merge <rootfs>]` es el gemelo de `service-cards`, y fusiona por clave, no por línea entera — componer dos veces no duplica, y `grep -q` de la línea completa no serviría porque la misma cuenta con otro GECOS se leería como nueva. Tres decisiones con su control: · Una cuenta ya presente con OTRA línea es CONFLICTO y no se pisa: sale ≠0. Pisarla es cambiarle el uid a ficheros que ya son de alguien, y eso se descubre dentro de la VM. · Se planea todo y sólo entonces se escribe. Fichero a fichero, un conflicto en `passwd` dejaba el `group` ya escrito: media cuenta es peor que ninguna, porque parece que está. Comprobado con el caso exacto — `group` sin la cuenta, `passwd` con otro uid — y los DOS ficheros quedan intactos. · Un `passwd` ausente es un error, no un fichero a crear: crearlo dejaría una imagen SIN `root`. La validación rechaza lo que rompe tarde: `root`/`sshd`/`nobody` y sus uids, uid fuera de 100..=65533, `home` relativo y un `:` en cualquier campo — que partiría la línea y fallaría lejos. Y `--user-paths` NO es `--service-paths` con otro nombre: aquél lista los servicios HABILITADOS, éste los paquetes INSTALADOS que declaran cuentas. `postgres` instalado y sin levantar necesita su usuario igual, porque los ficheros de la imagen ya son suyos. `scripts/servidor-image.sh` lo aplica entre hidratar el perfil y sellar la imagen, y aborta si hay conflicto: un rootfs con el uid equivocado produce ficheros de un dueño que no existe. Verde: 6 tests del módulo, core 234, cli 88, bootstrap 42, `targets.py --selftest` 7/7. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn	2026-09-14 15:39:52 +00:00
SergioandClaude Opus 5	2613fe3951	servidor-image.sh: la imagen del perfil servidor, armada por script — y netup pasa a ser raíz El ensamblado dejaba de ser reproducible en cuanto se cerraba la terminal: cuatro pasos, tres de ellos con una trampa que no se ve. Ahora es un script, con las trampas escritas en su cabecera: 1. El kernel. `linux.toml` NO sirve para hcloud (apaga SCSI y el disco de Hetzner es virtio-SCSI). Va `linux-generic`, que sí trae `CONFIG_SCSI_VIRTIO=y` — dato que no está en la receta, lo pone `make defconfig`, y sólo se ve en el `.config` que el artefacto publica. 2. El init se pisa. La clausura del perfil trae busybox y su `/sbin/init` gana por hidratarse después. El script lo restaura e IMPRIME la reparación (`../bin/busybox → /usr/bin/arje-zero`), que es la diferencia entre arreglarlo y creer que estaba bien. 3. EXDEV. Comprueba con `findmnt` que STORE y WORKDIR estén en el MISMO montaje y aborta con un mensaje que dice qué hacer, en vez de fallar fichero por fichero a mitad de un `cp -al`. 4. La clave es obligatoria. Sin `AUTHKEYS` no arma nada: una instalación remota sin `authorized_keys` deja una máquina viva e INALCANZABLE, que es peor que una que no arrancó. Y el cmdline va SIN `init=`, a propósito: así corre el wrapper que escribe `install-image.sh`, que es quien monta `/store` y `/var/lib/hammer`. `netup` entra como raíz de `perfil.servidor` aunque su binario ya venga dentro del `product-rootfs`. La razón es concreta y se pagó hoy: el del producto está congelado en el artefacto sellado del bootstrap, así que el arreglo de la ruta on-link NO llegaba a la imagen. Declarado como raíz, la hidratación lo proyecta encima y la imagen lleva el vigente — verificado por sha256: la imagen trae `a23df20e…` y el product-rootfs `a84b0a0d…`. `recipes/netup.toml` re-pineado a `be383ea4` (el commit del arreglo). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x	2026-09-10 20:15:39 +00:00

Author

SHA1

Message

Date

SergioandClaude Opus 5

d611f8577d

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

El SDD 30 sacó las Cards de una constante de Rust y las puso en la receta. Los USUARIOS se quedaron
donde estaban las Cards: `/etc/passwd` de la imagen es `takana_bootstrap::PRODUCT_PASSWD`, un literal
con `root` y `sshd`, y añadir un tercero era editar Rust y recompilar takana.

No es simetría por elegancia, es un servicio que no arranca: `gitea` se niega a correr como root, su
Card hace `setuidgid gitea`, y sin la cuenta arranca, muere y reintenta para siempre con un log que
dice `unknown user` — no «a la imagen le falta una cuenta».

    [[user]]
    name = "gitea"
    uid  = 916
    home = "/var/lib/gitea"

**El uid se declara, no se asigna**, por la misma razón que el ULID de la Card: un «primero libre a
partir de 1000» hace que dos imágenes del mismo perfil salgan con dueños distintos y el rootfs deje
de reproducir SIN QUE NADA FALLE — los ficheros se ven iguales y `ls -l` dice otro número. Fuera de
`hash_inputs`, medido: el hash de gitea no se movió (`b3:391a613e…` antes y después).

`takana users <recetas…> [--merge <rootfs>]` es el gemelo de `service-cards`, y fusiona **por clave,
no por línea entera** — componer dos veces no duplica, y `grep -q` de la línea completa no serviría
porque la misma cuenta con otro GECOS se leería como nueva. Tres decisiones con su control:

· Una cuenta ya presente con OTRA línea es CONFLICTO y no se pisa: sale ≠0. Pisarla es cambiarle el
  uid a ficheros que ya son de alguien, y eso se descubre dentro de la VM.
· Se planea todo y sólo entonces se escribe. Fichero a fichero, un conflicto en `passwd` dejaba el
  `group` ya escrito: media cuenta es peor que ninguna, porque parece que está. Comprobado con el
  caso exacto — `group` sin la cuenta, `passwd` con otro uid — y los DOS ficheros quedan intactos.
· Un `passwd` ausente es un error, no un fichero a crear: crearlo dejaría una imagen SIN `root`.

La validación rechaza lo que rompe tarde: `root`/`sshd`/`nobody` y sus uids, uid fuera de
100..=65533, `home` relativo y un `:` en cualquier campo — que partiría la línea y fallaría lejos.

Y `--user-paths` NO es `--service-paths` con otro nombre: aquél lista los servicios HABILITADOS,
éste los paquetes INSTALADOS que declaran cuentas. `postgres` instalado y sin levantar necesita su
usuario igual, porque los ficheros de la imagen ya son suyos.

`scripts/servidor-image.sh` lo aplica entre hidratar el perfil y sellar la imagen, y aborta si hay
conflicto: un rootfs con el uid equivocado produce ficheros de un dueño que no existe.

Verde: 6 tests del módulo, core 234, cli 88, bootstrap 42, `targets.py --selftest` 7/7.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn

2026-09-14 15:39:52 +00:00

SergioandClaude Opus 5

2613fe3951

servidor-image.sh: la imagen del perfil servidor, armada por script — y netup pasa a ser raíz

El ensamblado dejaba de ser reproducible en cuanto se cerraba la terminal: cuatro pasos, tres de
ellos con una trampa que no se ve. Ahora es un script, con las trampas escritas en su cabecera:

1. **El kernel.** `linux.toml` NO sirve para hcloud (apaga SCSI y el disco de Hetzner es virtio-SCSI).
   Va `linux-generic`, que sí trae `CONFIG_SCSI_VIRTIO=y` — dato que no está en la receta, lo pone
   `make defconfig`, y sólo se ve en el `.config` que el artefacto publica.
2. **El init se pisa.** La clausura del perfil trae busybox y su `/sbin/init` gana por hidratarse
   después. El script lo restaura e IMPRIME la reparación (`../bin/busybox → /usr/bin/arje-zero`),
   que es la diferencia entre arreglarlo y creer que estaba bien.
3. **EXDEV.** Comprueba con `findmnt` que STORE y WORKDIR estén en el MISMO montaje y aborta con un
   mensaje que dice qué hacer, en vez de fallar fichero por fichero a mitad de un `cp -al`.
4. **La clave es obligatoria.** Sin `AUTHKEYS` no arma nada: una instalación remota sin
   `authorized_keys` deja una máquina viva e INALCANZABLE, que es peor que una que no arrancó.

Y el cmdline va SIN `init=`, a propósito: así corre el wrapper que escribe `install-image.sh`, que
es quien monta `/store` y `/var/lib/hammer`.

**`netup` entra como raíz de `perfil.servidor`** aunque su binario ya venga dentro del
`product-rootfs`. La razón es concreta y se pagó hoy: el del producto está congelado en el artefacto
sellado del bootstrap, así que el arreglo de la ruta on-link NO llegaba a la imagen. Declarado como
raíz, la hidratación lo proyecta encima y la imagen lleva el vigente — verificado por sha256: la
imagen trae `a23df20e…` y el product-rootfs `a84b0a0d…`.

`recipes/netup.toml` re-pineado a `be383ea4` (el commit del arreglo).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x

2026-09-10 20:15:39 +00:00