☰

So erstellen Sie einen RPM-Spiegel auf Abruf

tag-icon • tag-icon fedora rpm squid
So erstellen Sie einen RPM-Spiegel auf Abruf

Ich möchte in meinem lokalen Netzwerk ein RPM-Repository für Fedora-Pakete erstellen. Aufgrund von Speicherbeschränkungen soll das Repository zunächst leer sein und Pakete sollen heruntergeladen werden, sobald auf sie zugegriffen wird.

Hintergrund

Ich arbeite viel mit lokalen VMs. Immer wenn ich eine neue VM erstelle und Fedora installiere, werden viele Pakete aus dem Internet heruntergeladen, und die meisten der heruntergeladenen Pakete sind gleich. Um den Prozess zu beschleunigen, möchte ich, dass die RPMs auf einem Server im selben Netzwerk zwischengespeichert werden.

Ähnliche Fragen wurden mit einer Kombination aus createrepo& beantwortet reposync. Mir gefällt dieser Teil nicht reposync, da ich nicht das ganze Repository im Voraus klonen möchte, wenn ich nur einige der Pakete benötige.

Ideale Lösung

Ich möchte, dass der Server in meinem lokalen Netzwerk als RPM-Repository für meine Fedora-Installationen fungiert. Er sollte die Metadaten von dem, was in konfiguriert ist, weitergeben /etc/yum.repo.d/*. Der Server sollte das angeforderte RPM bereitstellen, wenn es im lokalen Cache vorhanden ist, oder es herunterladen und dann bereitstellen.

Ein weniger anspruchsvoller Ansatz wäre, stattdessen ein einzelnes RPM-Repository zu konfigurieren https://mirrors.fedoraproject.org/...und nur einen HTTP-Proxy zu verwenden.

Update: 02.11.2015

proxy_passIch habe bereits einen nginx im Netzwerk laufen, also habe ich mit einer Kombination aus und herumgespielt proxy_cache. Es funktioniert irgendwie, hat aber meiner Meinung nach mehr Nachteile als Vorteile:

  • eine separate Konfiguration für jedes in konfigurierte Repo /etc/yum.repo.d/*.
  • kann aufgrund alternativer Spiegel nicht verwendet metadatawerden https://mirrors.fedoraproject.org/.

Ich habe das Nginx-Ding fallengelassen und installiert squid, wie in den Kommentaren vorgeschlagen. squidFunktioniert bei mir super. Mit der store_id_programKonfiguration kann ich sogar die alternativen Spiegel verwenden und trotzdem auf den Cache zugreifen, egal woher das RPM ursprünglich kam.

Antwort1

Hier finden Sie eine fein abgestimmte squid.conf für das RPM-Caching:

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

Sie müssen lediglich die Speicher- und Porteinstellungen ändern.

Antwort2

Ich bin mir nicht sicher, ob Sie eine gute Lösung dafür gefunden haben, aber ich habe am Ende ein kurzes kleines Go-Programm geschrieben. Es fungiert als Caching-Proxy und behält RPMs bei, leitet aber Upstream-Proxys an Datenbankdateien weiter, sodass es immer korrekt ist. Es ist derzeit für CentOS, Fedora EPEL und Arch Linux konfiguriert.

Sie finden es unterhttps://github.com/yobert/remirror

Antwort3

apt-cacher-ngfunktioniert super. Wir verwenden es seit einiger Zeit und es funktioniert gut. Und denken Sie daran, nur HTTP-Mirrors (und keine HTTPS-Mirrors) zu verwenden, wenn Sie es verwenden, um es effizienter zu machen (natürlich kann es keinen HTTPS-Verkehr sehen und zwischenspeichern):

Um die offiziellen Fedora-Repositories so zu konfigurieren, dass nur HTTP-Mirrors verwendet werden, können Sie &protocol=httpam Ende der metalinkKonfigurations-URL Folgendes hinzufügen. Für fedoradas Repository wird es dann beispielsweise:

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

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

Ein Caching-Proxy. Spezialisiert auf Paketdateien von Linux-Distributoren, hauptsächlich für Debian-Distributionen (und Debian-basierte Distributionen), aber nicht darauf beschränkt. Lesen Sie die Dokumentation von Apt-Cacher, um zu erfahren, wofür es gut ist.

Antwort4

Yum Wiki enthält Seite mitÜberprüfung von Caching-Lösungen

Einiges zum Thema:

  • Installieren "IntelligentMirror", und registrieren Sie sich beiSpiegelManager.

    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) avahi-packages-server.py und Yum Avahi-Unterstützung (siehe: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.

verwandte Informationen