Metodología de Replicación y Construcción de MxOS

Guía Maestra del Pipeline de Distribución Soberana (CentOS 10)

Autores:
Organización:

Fundación MxOS, A.C.

Fecha:

Septiembre 2026

Estado:

Estándar Activo

Visión Panorámica y Soberanía Tecnológica

La Fundación MxOS concibe el sistema operativo no como un producto estático, sino como una cadena de suministro verificable, reproducible y soberana. Cualquier institución, comunidad o equipo de ingeniería debe ser capaz de replicar la totalidad de la infraestructura de desarrollo y distribución sin depender de servicios propietarios ni de cajas negras.

El pipeline maestro de construcción de MxOS toma como base el ecosistema de CentOS Stream 10 y se articula en cuatro etapas secuenciales:

Etapa

Componente

Función Técnica

Repositorio / Proyecto

1

Ingesta Soberana

Sincronización dist-git, espejado de fuentes y mantenimiento de fork.

rpms-sync

2

Granja de Compilación

Construcción determinista en chroots Mock orquestada con Koji Hub.

ansible-koji

3

Hospedaje de Repositorios

Composición atómica, firma GPG con Sigul y aislamiento de canales DNF.

operaciones/servidores

4

Generación de Medios

Ensamblaje declarativo de imágenes de estación de trabajo en paridad 1:1.

mxos-mkosi y mxos-kiwi

Etapa 1: Ingesta Soberana de Fuentes (CentOS Stream Ingestion)

El código fuente de CentOS Stream no se obtiene de un único repositorio estático; presenta una dualidad arquitectónica que debe gestionarse metódicamente.

  1. La Dualidad de Fuentes de Upstream: * GitLab dist-git (gitlab.com/redhat/centos-stream/rpms): Alberga las especificaciones declarativas (.spec), parches locales de Red Hat y el archivo de metadatos sources con las sumas criptográficas SHA512 de los tarballs de código fuente. * Koji Stream Central (koji.stream.centos.org): El entorno de compilación donde residen las dependencias de arranque (Cyclic Bootstrap), los artefactos mínimos de buildroot y los side tags efímeros (c10s-build-side-XXXX) que resuelven roturas de ABI en compilaciones masivas.

  2. Espejado y Soberanía del Lookaside Cache: El servicio automatizado rpms-sync clona los árboles de dist-git hacia la forja soberana (git.mx-os.mx/rpms) y descarga de inmediato los tarballs referenciados en sources hacia el servidor de fuentes de la Fundación (sources.mx-os.mx). Esto garantiza la reproducibilidad histórica incluso si upstream retira versiones antiguas.

  3. Mantenimiento del Fork y Versionamiento: * Las ramas de upstream (c10s) son de solo lectura y reflejan a CentOS prístino. * El desarrollo propio se mantiene en ramas de distribución (c10s-mxos) utilizando un flujo estricto de rebase lineal (sin merge commits). * El versionamiento RPM respeta el algoritmo de ordenamiento EVR mediante la fórmula:

    Release: %{upstream_release}%{?dist}.mxos.%{patch_iteration}
# En specs con rpmautospec:
Release: %autorelease -e mxos.%{patch_iteration}

    • Antes de compilar en Koji, cada versión se sella con una etiqueta Git inmutable y firmada (v%{version}-%{release}).

See also

Para consultar el protocolo exhaustivo de rebase, validación en Mock local y la política Upstream-First, consulte el Protocolo de Mantenimiento del Fork y Ciclo de Vida RPM o el archivo in-repo rpms-sync/FLUJO.rst.

Etapa 2: Granja de Compilación y Gobernanza de Binarios (Koji Hub & Mock)

Una vez que el paquete cuenta con su etiqueta Git inmutable en Forgejo, la compilación de paquetes binarios RPM se delega a una granja dedicada basada en Koji, el estándar de ingeniería de Fedora y Enterprise Linux.

  1. Arquitectura del Cluster Koji: * Koji Hub: Servicio central en Python que expone una interfaz XML-RPC sobre HTTPS, respaldado por una base de datos PostgreSQL. * Koji Builders (kojid): Daemons de ejecución que instancian entornos chroot aislados y desechables mediante Mock, garantizando que ninguna compilación se contamine con paquetes del host. * Servidor de Firma Sigul: Infraestructura aislada con módulos criptográficos (HSM o llaves protegidas) que firma los RPMs sin exponer la clave privada a los constructores.

  2. Gobernanza de Tags y Buildroots: Koji organiza el ciclo de vida mediante etiquetas jerárquicas: * c10s-build: Define el repositorio base de dependencias para los chroots de Mock. * c10s-candidate: Almacena los paquetes recién compilados pendientes de validación o pruebas de integración. * c10s-build-side-XXXX: Permite compilar simultáneamente cadenas de herramientas completas antes de promoverlas al buildroot general.

  3. Automatización con Ansible: Toda la granja de compilación se despliega de forma declarativa e idéntica mediante los playbooks de Ansible del proyecto ansible-koji.

See also

Para desplegar los nodos de Koji Hub, configurar los certificados SSL de los constructores y registrar usuarios, consulte la Guía de Despliegue de Koji Hub.

Etapa 3: Composición, Firma y Hospedaje de Repositorios (DNF/RPM)

Los paquetes aprobados en Koji se estructuran en repositorios DNF oficiales para su consumo por estaciones de trabajo y servidores.

  1. Composición Atómica de Canales: Mediante utilerías como createrepo_c y compositores de Koji, los paquetes se agrupan en los repositorios estándar: * BaseOS: Núcleo mínimo del sistema operativo, kernel, systemd y utilerías esenciales de arranque. * AppStream: Aplicaciones de usuario, herramientas de desarrollo y entornos gráficos. * CRB (CodeReady Builder): Bibliotecas de desarrollo y paquetes -devel necesarios para compilar software adicional.

  2. Firma Criptográfica: Cada paquete binario y los metadatos del repositorio (repomd.xml) se firman con la clave pública institucional de la Fundación MxOS.

  3. Aislamiento Estricto de Repositorios: Para evitar que una actualización menor de upstream sobrescriba las personalizaciones de identidad o parches de seguridad de MxOS (vendor clobbering o aleteo), los sistemas cliente de MxOS únicamente consumen repositorios compuestos y hospedados por la Fundación. La sincronización con upstream ocurre en la Etapa 1 mediante el pipeline de CI/CD, jamás directamente en el gestor DNF del usuario final.

Etapa 4: Ensamblaje de Medios y Sistemas Operativos con Paridad

Con los repositorios DNF poblados y firmados, el paso final consiste en ensamblar los sistemas operativos ejecutables: imágenes de disco crudas (RAW/GPT), instaladores ISO y entornos de arranque en red (PXE/iPXE).

Para garantizar la autonomía tecnológica y mitigar el riesgo de bloqueo por proveedor de herramientas (toolchain lock-in), MxOS implementa una estrategia de paridad funcional 1:1 mediante dos motores de generación independientes:

Dimensión

Enfoque mkosi (mxos-mkosi)

Enfoque KIWI NG (mxos-kiwi)

Motor Base

Herramienta nativa de systemd (systemd-repart + DNF).

Motor declarativo independiente kiwi-ng (v11+).

Configuración

Archivos INI modulares (mkosi.conf, mkosi.repart/).

Archivo XML declarativo (config.xml) y hooks Bash (config.sh).

Gestor de Arranque

systemd-boot con Unified Kernel Images (UKI) y dracut.

systemd-boot con Unified Kernel Images (UKI) y dracut.

Esquema de Disco

Particionado GPT, subvolúmenes Btrfs comprimidos con zstd.

Particionado GPT, subvolúmenes Btrfs comprimidos con zstd.

Identidad Visual

Plymouth spinner temático de MxOS, wallpapers y temas de GNOME.

Plymouth spinner temático de MxOS, wallpapers y temas de GNOME.

Ambos proyectos producen imágenes de disco idénticas (mxos-centos10.raw) verificables en máquinas virtuales locales mediante comandos acelerados por hardware:

# En mxos-mkosi o mxos-kiwi:
make run
# o alternativamente:
./run.bash

See also