Puente HTTP y Fedora MirrorManager¶

Identificador Técnico: [TECH-005]

Integración con MirrorManager¶

Fedora gestiona su infraestructura de distribución global mediante MirrorManager (mirrormanager2). Para registrar formalmente a MxOS como el primer espejo oficial en México, se requiere:

Exposición de puntos finales HTTP y HTTPS estables y de alta velocidad.
Soporte para el protocolo de verificación de sincronización (archivo report_mirror).
Respuesta rápida en peticiones GET y HEAD para metadatos de repositorio.

Topología del Puente Inverso¶

En el servidor cabecera de MxOS (ejemplo: mirrors.mx-os.mx), un servidor web de alto rendimiento (Caddy o Nginx) actúa como terminador TLS y proxy inverso directo hacia el gateway HTTP de Kubo:

Petición DNF Upstream (Internet)
             |
             v
+---------------------------------------+
| Caddy o Nginx (mirrors.mx-os.mx:443)  |
| Certificados Let's Encrypt y TLS 1.3  |
+---------------------------------------+
             |
             | proxy_pass http://127.0.0.1:8080/ipns/mirrors.mx-os.mx/
             v
+---------------------------------------+
| Gateway HTTP de Kubo (IPFS Local)    |
+---------------------------------------+
             |
             v
+---------------------------------------+
| Enjambre P2P de Nodos Guardianes      |
+---------------------------------------+

Configuración de Ejemplo para Caddy¶

El servidor web delega la entrega de archivos estáticos al gateway local de IPFS:

mirrors.mx-os.mx {
    encode zstd gzip

    # Proxy transparente hacia el gateway de IPFS
    reverse_proxy http://127.0.0.1:8080 {
        rewrite /ipns/mirrors.mx-os.mx{path}
        header_up Host {upstream_hostport}
    }

    log {
        output stdout
        format filter {
            wrap json
            fields {
                common_log delete
            }
        }
    }
}

Beneficio Operativo¶

Este desacoplamiento permite que los clientes externos utilicen el espejo como si fuera un servidor web convencional, mientras que por debajo, el servidor cabecera obtiene los bloques faltantes desde la red comunitaria de nodos guardianes, reduciendo drásticamente la carga de salida del nodo central.