☰

Como criar um espelho RPM sob demanda

tag-icon • tag-icon fedora rpm squid
Como criar um espelho RPM sob demanda

Gostaria de criar um repositório RPM para pacotes do Fedora na minha rede local. Devido às limitações de armazenamento, quero que o repositório esteja vazio inicialmente e baixe os pacotes assim que forem acessados.

Fundo

Eu trabalho muito com VMs locais. Sempre que eu crio uma nova VM e instalo o Fedora, muitos pacotes são baixados da Internet, e a maioria dos pacotes baixados são iguais. Para acelerar o processo, gostaria que os RPMs fossem armazenados em cache em um servidor localizado na mesma rede.

Perguntas semelhantes foram respondidas com uma combinação de createrepo& reposync. Não gosto dessa reposyncparte, pois não quero clonar todo o repositório antecipadamente quando preciso apenas de alguns pacotes.

Solução Ideal

Gostaria que o servidor da minha rede local atuasse como um repositório RPM para minhas instalações do Fedora. Ele deve passar pelos metadados de tudo o que estiver configurado no /etc/yum.repo.d/*. O servidor deve entregar o RPM solicitado se estiver presente no cache local, ou então baixá-lo e entregá-lo.

Uma abordagem menos ambiciosa seria configurar um único repositório RPM em vez de https://mirrors.fedoraproject.org/...usar apenas um proxy http.

Atualização: 02 de novembro de 2015

Já tenho um nginx rodando na rede, então brinquei com uma combinação de proxy_passe proxy_cache. Até que funciona, mas IMHO tem mais desvantagens do que benefícios:

  • uma configuração separada para cada repositório configurado no /etc/yum.repo.d/*.
  • não posso usar metadatafrom https://mirrors.fedoraproject.org/por causa de espelhos alternativos.

Larguei o nginx e instalei squid, como sugerido nos comentários. squidfunciona muito bem para mim. Com a store_id_programconfiguração, posso até usar os espelhos alternativos e ainda acessar o cache, não importa de onde veio o RPM originalmente.

Responder1

Aqui você pode encontrar o squid.conf ajustado para cache rpm:

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

Você apenas deve modificar a configuração de memória e porta.

Responder2

Não tenho certeza se você encontrou uma boa solução para isso, mas acabei escrevendo um pequeno programa Go rápido. Ele atua como um proxy de cache e mantém RPMs, mas faz proxy upstream para arquivos de banco de dados, portanto está sempre correto. Por enquanto, está configurado para CentOS, Fedora EPEL e Arch Linux.

Você pode ver isso emhttps://github.com/yobert/remirror

Responder3

apt-cacher-ngfunciona bem. Estamos usando-o algumas vezes e funciona bem. E lembre-se de usar apenas espelhos http (e não https) ao usá-lo para torná-lo mais eficiente (naturalmente, ele não pode ver e armazenar em cache o tráfego https):

Para configurar os repositórios oficiais do Fedora para usarem apenas espelhos http, você pode adicionar &protocol=httpno final da metalinkurl de configuração, por exemplo, para fedorao repositório, ele se tornará:

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

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

Um proxy de cache. Especializado em arquivos de pacotes de distribuidores Linux, principalmente para distribuições Debian (e baseadas em Debian), mas não limitado a elas. Veja a documentação do Apt-Cacher para saber para que serve.

Responder4

Yum wiki contém página comrevisão de soluções de cache

Algumas delas no tópico:

  • Instalar "Espelho Inteligente", e cadastre-se comGerenciador de espelhos.

    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) suporte avahi-packages-server.py e yum avahi (veja: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.

informação relacionada