Interner Paketspiegel oder -Cache für Linux-Clients: apt-cacher-ng und das reposync-Plugin von dnf

Worum es geht

Zwei unterschiedliche Ansätze lösen dasselbe Problem: Viele Linux-Clients im selben Netzwerk laden dieselben Pakete wiederholt aus dem Internet herunter. Apt-Cacher NG ist ein Caching-Proxy für Softwarepakete, die von den Paketverwaltungsmechanismen von Unix-/Linux-Distributionen von Mirror-Servern über HTTP bezogen werden: Debian- und Ubuntu-Clients richten ihre APT-Konfiguration darauf aus. Der Proxy holt ein Paket einmal ab und liefert spätere Anfragen nach derselben Datei aus seinem lokalen Cache. Das reposync-Plugin von DNF funktioniert umgekehrt: Es synchronisiert die Pakete eines entfernten DNF-Repositorys in ein lokales Verzeichnis und erzeugt so eine vollständige lokale Kopie eines gewählten Repositorys (oder einer gefilterten Teilmenge). Clients der RHEL-Familie verweisen mit baseurl direkt darauf, statt dass bei Bedarf zwischengespeichert wird.

Warum es wichtig ist

Beide Ansätze reduzieren wiederholte Downloads derselben Pakete auf einen einzigen Abruf aus dem Internet. Das zählt besonders dort, wo die Bandbreite begrenzt oder volumenabhängig abgerechnet wird oder wo viele Hosts gleichzeitig aktualisieren, etwa bei einer Flotte von Containern oder VMs, die gemeinsam neu gebaut werden. Ein lokaler Mirror oder Cache hält die Paketinstallation zudem bei einem Ausfall des Upstreams am Laufen, sofern die benötigten Pakete bereits einmal abgerufen wurden. Keiner der beiden Ansätze darf dazu dienen, die Signaturprüfung zu umgehen: APT prüft die signierten Repository-Metadaten und die darin aufgeführten Paket-Hashes, DNF prüft die Paketsignaturen (gpgcheck). Beides geschieht auf dem Client anhand bereits als vertrauenswürdig geführter Schlüssel, unabhängig davon, woher die Bytes physisch stammen.

So wird es angewendet

• Für Debian/Ubuntu apt-cacher-ng auf einem Server installieren und die Clients in einem APT-Konfigurationsschnipsel mit Acquire::http::proxy "http://CacheServerIp:3142"; darauf ausrichten (der Dienst lauscht auf TCP 3142). Quellen mit http:// auf den Clients müssen nicht angepasst werden. Quellen mit https:// übernehmen diese Proxy-Einstellung als Tunnel, die apt-cacher-ng (ohne Caching) nur durchreicht, wenn PassThroughPattern sie zulässt. Andernfalls Acquire::https::Proxy "DIRECT"; setzen oder die Quellen auf die cachefähige Form http://HTTPS///host/... umschreiben.
• Für Systeme der RHEL-Familie dnf reposync --repoid=<repo> --download-metadata -p /srv/mirror (DNF-4-Syntax, wie unter RHEL 8/9/10) regelmässig nach Zeitplan ausführen; mit --delete werden Pakete entfernt, die upstream nicht mehr vorhanden sind. --download-metadata macht die Kopie unmittelbar als Repository nutzbar; ohne diese Option sind die Metadaten mit createrepo_c zu erzeugen. Das Verzeichnis über HTTP bereitstellen und die Repo-Dateien der Clients per baseurl darauf verweisen lassen.
• In jeder Repo-Definition eines Clients, die auf den Mirror zeigt, gpgcheck=1 und den ursprünglichen gpgkey= des Herstellers ausdrücklich setzen. Ein lokaler Mirror ist eine Optimierung des Transports, keine Vertrauensgrenze. Die Option --gpgcheck von reposync kann zusätzlich Pakete entfernen, die bereits während der Synchronisation die Signaturprüfung nicht bestehen.
• reposync-Mirrors per Timer einplanen. Apt-cacher-ng speichert bei Bedarf zwischen und braucht für die Aktualität keinen Zeitplan, sondern nur ein regelmässiges Bereinigen überholter Dateien (das Debian-Paket richtet dafür einen täglichen Cron-Job ein).

Stolpersteine

• Ein reposync-Mirror wird bereitgestellt, aber nie erneut ausgeführt: Die Clients erhalten ein eingefrorenes Repository und verpassen unbemerkt Sicherheitsupdates.
• Übersehen, dass ein Caching-Proxy weiterhin eigenen ausgehenden Internetzugang braucht; er vermeidet redundante Abrufe, macht die Konnektivität aber nicht ganz überflüssig.
• Eines der Werkzeuge wird als Ersatz für die GPG-Prüfung statt als Ergänzung dazu behandelt.