
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 reposync
parte 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_pass
y 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
metadata
debidohttps://mirrors.fedoraproject.org/
a espejos alternativos.
Dejé nginx y lo instalé squid
, como se sugiere en los comentarios. squid
funciona muy bien para mí. Con la store_id_program
configuració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-ng
Funciona 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=http
al final de la metalink
URL de configuración, por ejemplo, para fedora
el 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.