☰

Как создать зеркало RPM по запросу

tag-icon • tag-icon fedora rpm squid
Как создать зеркало RPM по запросу

Я хотел бы создать RPM-репозиторий для пакетов Fedora в своей локальной сети. Из-за ограничений хранилища я хочу, чтобы репозиторий изначально был пустым и загружал пакеты по мере их обращения.

Фон

Я много работаю с локальными виртуальными машинами. Каждый раз, когда я создаю новую виртуальную машину и устанавливаю Fedora, из интернета загружается множество пакетов, и большинство из загружаемых пакетов одинаковы. Чтобы ускорить процесс, я бы хотел, чтобы RPM-пакеты кэшировались на сервере, расположенном в той же сети.

На подобные вопросы отвечали с помощью комбинации createrepo& reposync. Мне эта часть не нравится reposync, потому что я не хочу клонировать весь репозиторий заранее, когда мне нужны только некоторые пакеты.

Идеальное решение

Я хотел бы, чтобы сервер в моей локальной сети действовал как репозиторий RPM для моих установок Fedora. Он должен передавать метаданные из всего, что настроено в /etc/yum.repo.d/*. Сервер должен доставить запрошенный RPM, если он присутствует в локальном кэше, или же загрузить его и затем доставить.

Менее амбициозный подход — настроить единый репозиторий RPM вместо https://mirrors.fedoraproject.org/...использования HTTP-прокси.

Обновление: 02 ноября 2015 г.

У меня уже есть nginx, работающий в сети, поэтому я поигрался с комбинацией proxy_passи proxy_cache. Это вроде как работает, но IMHO у него больше недостатков, чем преимуществ:

  • отдельная конфигурация для каждого репозитория, настроенного в /etc/yum.repo.d/*.
  • невозможно использовать metadataиз https://mirrors.fedoraproject.org/-за альтернативных зеркал.

Я удалил nginx и установил squid, как было предложено в комментариях. squidУ меня отлично работает. С этой store_id_programконфигурацией я даже могу использовать альтернативные зеркала и по-прежнему попадать в кэш, независимо от того, откуда изначально пришел RPM.

решение1

Здесь вы можете найти настроенный squid.conf для кэширования rpm:

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

Вам просто нужно изменить настройки памяти и порта.

решение2

Не уверен, нашли ли вы хорошее решение для этого, но в итоге я написал быструю маленькую программу Go. Она действует как кэширующий прокси и держит RPM, но проксирует вверх по течению к файлам базы данных, поэтому она всегда корректна. На данный момент она настроена для CentOS, Fedora EPEL и Arch Linux.

Вы можете увидеть это наhttps://github.com/yobert/remirror

решение3

apt-cacher-ngотлично работает. Мы используем его уже некоторое время, и он отлично работает. И помните, что при его использовании следует использовать только http-зеркала (а не https-зеркала), чтобы сделать его более эффективным (естественно, он не видит и не кэширует https-трафик):

Чтобы настроить официальные репозитории Fedora на использование только http-зеркал, можно добавить &protocol=httpв конец metalinkURL-адреса конфигурации, например, для fedoraрепозитория это будет выглядеть так:

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

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

Кэширующий прокси. Специализируется на файлах пакетов от дистрибьюторов Linux, в первую очередь для дистрибутивов Debian (и основанных на Debian), но не ограничивается ими. См. документацию Apt-Cacher, чтобы узнать, для чего он хорош.

решение4

Yum wiki содержит страницу собзор решений кэширования

Некоторые из них по теме:

  • Установить "IntelligentMirror", и зарегистрироватьсяMirrorManager.

    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.

  • (бета) поддержка avahi-packages-server.py и yum avahi (см.: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.

Связанный контент