Cómo crear un espejo RPM bajo demanda

Cómo crear un espejo RPM bajo demanda

Me gustaría crear un repositorio RPM para paquetes de Fedora en mi red local. Debido a limitaciones de almacenamiento, quiero que el repositorio esté vacío inicialmente y descargar los paquetes una vez que se acceda a ellos.

Fondo

Trabajo mucho con máquinas virtuales locales. Cada vez que creo una nueva máquina virtual e instalo Fedora, se descargan muchos paquetes de Internet y la mayoría de los paquetes descargados son los mismos. Para acelerar el proceso, me gustaría que los RPM se almacenen en caché en un servidor ubicado en la misma red.

Se han respondido preguntas similares con una combinación de createrepo& reposync. No me gusta esta reposyncparte porque no quiero clonar todo el repositorio desde el principio cuando solo necesito algunos de los paquetes.

Solución ideal

Me gustaría que el servidor de mi red local actúe como repositorio RPM para mis instalaciones de Fedora. Debería pasar los metadatos de lo que esté configurado en /etc/yum.repo.d/*. El servidor debe entregar el RPM solicitado si está presente en el caché local, o descargarlo y luego entregarlo.

Un enfoque menos ambicioso sería configurar un único repositorio RPM en lugar de https://mirrors.fedoraproject.org/...utilizar simplemente un proxy http.

Actualización: 02 de noviembre de 2015

Ya tengo un nginx ejecutándose en la red, así que jugué con una combinación de proxy_passy proxy_cache. Funciona un poco, pero en mi humilde opinión tiene más inconvenientes que beneficios:

  • una configuración separada para cada repositorio configurado en /etc/yum.repo.d/*.
  • No se puede usar metadatadebido https://mirrors.fedoraproject.org/a espejos alternativos.

Dejé nginx y lo instalé squid, como se sugiere en los comentarios. squidfunciona muy bien para mí. Con la store_id_programconfiguración, incluso puedo usar los espejos alternativos y seguir accediendo al caché, sin importar de dónde vino originalmente el RPM.

Respuesta1

Aquí puede encontrar squid.conf ajustado para el almacenamiento en caché de rpm:

https://github.com/spacewalkproject/spacewalk/blob/master/proxy/installer/squid.conf

Sólo debes modificar la configuración de la memoria y el puerto.

Respuesta2

No estoy seguro de haber encontrado una buena solución para esto, pero terminé escribiendo un pequeño programa Go rápido. Actúa como un proxy de almacenamiento en caché y mantiene alrededor de RPM, pero actúa como proxy en sentido ascendente de los archivos de la base de datos, por lo que siempre es correcto. Está configurado para CentOS, Fedora EPEL y Arch Linux por ahora.

Puedes verlo enhttps://github.com/yobert/remirror

Respuesta3

apt-cacher-ngFunciona genial. Lo estamos usando algunas veces y funciona bien. Y recuerde usar solo espejos http (y no https) cuando lo use para hacerlo más eficiente (naturalmente, no puede ver ni almacenar en caché el tráfico https):

Para configurar los repositorios oficiales de Fedora para que solo usen espejos http, puede agregar &protocol=httpal final de la metalinkURL de configuración, por ejemplo, para fedorael repositorio se convertirá en:

metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&protocol=http

https://www.unix-ag.uni-kl.de/~bloch/acng/

Un proxy de almacenamiento en caché. Especializado para archivos de paquetes de distribuidores de Linux, principalmente para distribuciones Debian (y basadas en Debian), pero no limitado a ellas. Consulte la documentación de Apt-Cacher para saber para qué sirve.

Respuesta4

Yum wiki contiene página conrevisión de soluciones de almacenamiento en caché

Algo de ello sobre el tema:

  • Instalar "Espejo inteligente", y registrarse conAdministrador de espejos.

    Pros
        Zero configuration, on the client side.
        Post setup it mostly just works and everything should be immediate.
        Only downloads what is required by the users.
        Fully automated server side, once setup/working. 
    Cons
        Requires setting up a local Squid + Apache-httpd + IntelligentMirror to serve the data.
        If the server is down then metalinks/MM will route you to an external mirror.
        Only intelligently caches packages, not metadata. 
    
  • (beta) compatibilidad con avahi-packages-server.py y yum avahi (consulte:http://james.fedorapeople.org/yum/avahi)

    Pros
        Zero configuration client.
        Zero configuration server.
        Only downloads what is required by the users. 
    Cons
        Not upstream yet (still beta).
        A client that doesn't run the avahi server side doesn't share it's downloads (so all clients need to run the "server").
        Requires working avahi on the network. 
    

información relacionada