Linux Mirror: Was ist ein Paketspiegel und wie wählen Sie ihn?

Was ist ein Linux Mirror und wozu dient er?

Ein Linux Mirror (Paketspiegel) ist ein Server, der eine exakte Kopie des Software Archivs einer Distribution bereitstellt. Paketmanager wie apt und dnf laden Updates von solchen Spiegeln, nicht von einer zentralen Stelle. Dadurch verteilt sich die Last, Downloads kommen von einem nahen Rechner, und Updates laufen auch bei einem langsamen Hauptarchiv weiter.

In diesem Leitfaden betrachten wir den Linux Mirror aus Sicht von Website Betreibern, Shop Verantwortlichen und Entwicklern. Wir sind ein Team für digitales Marketing und Webprojekte, kein Hostinganbieter. Deshalb stützt sich alles hier auf die offizielle Dokumentation der Distributionen. Prüfen Sie die Anleitung Ihrer eigenen Distribution, bevor Sie Befehle auf einem Produktivsystem ausführen.

Zunächst sehen Sie, wie apt und dnf ihren Spiegel finden. Danach geht es um den Einfluss eines nahen Spiegels auf die Geschwindigkeit, um den Schutz durch GPG Signaturen und um die Frage, wann ein eigener Spiegel sinnvoll ist.

Worin unterscheiden sich Repository, Spiegel und Cache?

Drei Begriffe werden oft vermischt. Ein Repository enthält Pakete und die Indexdateien, die sie beschreiben. Ein Spiegel ist also eine Kopie dieses Repositorys. Dagegen speichert ein Caching Proxy keine vollständige Kopie, sondern merkt sich nur die Pakete, die jemand angefordert hat.

Kurz gesagt: Jeder Spiegel ist ein Repository, aber nicht jedes Repository ist ein Spiegel. Die Dokumentation von Debian nennt Caching Proxys wie apt-cacher-ng, squid und varnish außerdem als eigene Alternative zum vollständigen Spiegeln.

Woher lesen apt und dnf die Adresse des Spiegels?

Konkret lesen beide Paketmanager die Adresse aus kleinen Textdateien. Wenn Sie diese Dateien ändern, ändern Sie also die Quelle Ihrer Updates. Deshalb sind Ort und Format der Dateien wichtig.

• apt liest die Datei /etc/apt/sources.list und das Verzeichnis /etc/apt/sources.list.d/.
• Debian und neuere Ubuntu Versionen nutzen ein zeilenbasiertes Format namens deb822, und diese Dateien enden auf .sources.
• dnf liest Repository Definitionen aus .repo Dateien, die meist in /etc/yum.repos.d/ liegen.
• In einer .repo Datei steht die Adresse in einer Zeile mit baseurl, mirrorlist oder metalink.

Schauen Sie zunächst ins Verzeichnis, um das Format Ihres Systems zu erkennen. Dateinamen und Standardwerte unterscheiden sich je nach Distribution. Vergleichen Sie daher mit der Anleitung zu Ihrer Version.

Wie lesen Sie die sources Datei unter Debian und Ubuntu?

Laut Debian Wiki liegt die Hauptkonfiguration in /etc/apt/sources.list.d/debian.sources. Ubuntu 24.04 LTS und neuer definieren ihre Repositorys in /etc/apt/sources.list.d/ubuntu.sources. Ältere Ubuntu Versionen nutzen allerdings weiterhin /etc/apt/sources.list.

Das folgende Beispiel folgt dem deb822 Aufbau aus der Ubuntu Dokumentation und zeigt auf einen internen Spiegel. Die Domain ist ein Platzhalter, und CODENAME ersetzen Sie durch den Kurznamen Ihrer Version.

Types: deb
URIs: https://mirror.example.com/ubuntu
Suites: CODENAME CODENAME-updates CODENAME-backports
Components: main universe restricted multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Die konkrete Antwort auf die Frage, was ein Linux Mirror auf Ihrem Server ist, steht in einer einzigen Zeile namens URIs. Vier Felder genügen. URIs ist die Adresse des Spiegels, Suites nennt Version und Update Kanäle, und Components listet die Paketgruppen. Signed-By zeigt auf den Schlüssel, dem apt für dieses Repository vertraut.

Zum Umstellen einer älteren Datei empfiehlt das Debian Wiki den Befehl apt modernize-sources. Kopieren Sie die Datei trotzdem vorher an einen sicheren Ort.

Wie funktionieren mirrorlist und metalink bei dnf?

Die Konfigurationsreferenz von dnf beschreibt baseurl als Liste von Repository Adressen, die dnf in der angegebenen Reihenfolge probiert. Eine mirrorlist oder ein metalink funktioniert anders, denn es ist eine einzige Adresse, die eine Liste passender Spiegel zurückgibt. Somit landet jeder Client bei einem Spiegel in seiner Nähe.

Bei öffentlichen Spiegeln sehen Sie daher oft mirrorlist oder metalink. Betreiben Sie dagegen einen internen Spiegel, tragen Sie Ihre eigene Adresse in baseurl ein. Der Unterschied ist einfach: Im ersten Fall pflegt die Distribution die Liste, im zweiten treffen Sie die Auswahl.

Ist ein Repository nicht erreichbar, bricht dnf standardmäßig mit einem Fehler ab. Die Referenz beschreibt jedoch skip_if_unavailable: Ist die Option aktiv, arbeitet dnf weiter und deaktiviert das Repository, das sich nicht synchronisieren ließ. Aktivieren Sie dieses Verhalten auf Produktivservern nur bewusst, weil ein fehlendes Sicherheitsrepository sonst unbemerkt übersprungen wird.

Außerdem nutzt die Option fastestmirror laut Referenz die TCP Latenz, um den nächsten Spiegel zu finden. Mit max_parallel_downloads legen Sie fest, wie viele Pakete gleichzeitig laden. Lesen Sie die Standardwerte Ihrer Distribution, bevor Sie eine der beiden Optionen ändern.

Wie beeinflusst ein naher Spiegel Geschwindigkeit und Verfügbarkeit?

Die Downloadzeit hängt von zwei Dingen ab: vom Netzwerkweg zwischen Ihrem Server und dem Spiegel sowie von der Auslastung des Spiegels in diesem Moment. Ein naher Spiegel liefert daher meist geringere Latenz und einen stabileren Durchsatz. Zur Netzwerkseite lesen Sie unsere Beiträge zu Ping, Latenz und RTT sowie zur Bandbreite beim Webhosting.

Geschwindigkeit ist nicht der einzige Grund, denn die Verfügbarkeit zählt genauso. Fällt ein Spiegel wegen Wartung aus oder ist seine Leitung voll, stocken Ihre Updates. Eine mirrorlist oder ein metalink senkt dieses Risiko, weil die Liste mehrere Spiegel enthält.

Zum Beispiel verzögert ein langsamer Spiegel jede Veröffentlichung, wenn Ihre Deployment Pipeline bei jedem Lauf Pakete lädt. Sogar die Dauer eines Website Updates kann also von der Spiegelwahl abhängen. Wir nennen keine Zahlen, denn der Effekt hängt von Ihrem Netz ab. Zum Messen führen Sie dasselbe Update gegen zwei Spiegel aus und vergleichen die Zeiten.

Warum ist der Linux Mirror für Website Betreiber wichtig?

Betreiben Sie Ihre Website auf einem VPS, arbeitet ein Paketspiegel jeden Tag für Sie, ohne dass Sie ihn bemerken. Schon das erste apt update auf einem frischen Server spricht zum Beispiel mit einem Spiegel. Das Gleiche gilt für Sicherheitspatches, für Docker Images und für Ihre Deployment Aufträge.

Damit wird der Spiegel zu einem Teil Ihres Sicherheits und Veröffentlichungsprozesses. Kommt ein Sicherheitsupdate spät an, bleibt die Schwachstelle länger offen. Wird der Spiegel langsam, dauern Builds länger, und eine dringende Korrektur am Kampagnentag geht zu spät live.

Trotzdem muss nicht jeder Website Betreiber die Spiegel Einstellung anfassen. Bei Shared Hosting gehört diese Ebene allerdings ohnehin Ihrem Anbieter. Verwalten Sie einen eigenen VPS, genügt es oft, den Standard zu kennen und ihn bewusst beizubehalten.

Wie wählen Sie den besten Spiegel für Ihre Server aus?

Verlassen Sie sich daher nicht auf ein einzelnes Kriterium. Die Spiegelliste der Distribution ist der sicherste Ausgangspunkt, denn die dort aufgeführten Spiegel halten Synchronisationsregeln ein. Danach wägen Sie diese Punkte gegen Ihr Netz ab:

• Geografische Nähe: Ein Spiegel im Land oder in der Stadt Ihres Servers hat meist weniger Latenz.
• Protokoll: Wählen Sie nach Möglichkeit einen Spiegel mit HTTPS.
• Aktualität: Der Spiegel sollte sich mit dem Hauptarchiv synchronisieren, ohne zurückzufallen.
• Bandbreite und Kapazität: Zu Stoßzeiten sollte er nicht kriechen.
• Kontinuität: Er sollte einen bekannten Betreiber haben, etwa eine Hochschule oder eine Organisation.

Wir empfehlen keinen bestimmten Betreiber, denn die Wahl hängt von Ihrem Netz ab. Am sinnvollsten ist es, einige Kandidaten aus der offiziellen Liste in Ihrer Nähe auszuwählen und zu messen. Das Netz hinter einem Spiegel prüfen Sie außerdem mit unserem IP Abfrage Tool.

Welche Fehler treten auf, wenn ein Spiegel veraltet ist?

Holt ein Client Updates, bevor der Spiegel die Synchronisation beendet hat, passen Indexdateien und Pakete womöglich nicht zusammen. apt meldet dann meist einen Hash Sum mismatch. Ein 404 Not Found bedeutet dagegen, dass das Paket den Spiegel verlassen hat oder noch nicht angekommen ist.

Warum fällt ein Spiegel zurück? Die Synchronisation läuft in Abständen, daher sind Pakete, die in dieser Lücke ins Hauptarchiv kommen, noch nicht beim Spiegel. Deshalb verkürzen große Spiegel die Lücke mit Push Auslösern. Eine kurze Abweichung ist normal, also ist ein erneuter Versuch zunächst vernünftig.

Die letzte Zeile verdient Aufmerksamkeit, denn eine falsche Uhr lässt einen signierten Index ungültig aussehen. Dieses Thema haben wir in unserem NTP Leitfaden behandelt und wiederholen es hier nicht.

Wie bereiten Sie die Umstellung der Spiegel Einstellung vor?

Wenn Sie die Quellenliste ändern, ändern Sie den Updateweg Ihres Servers. Machen Sie dabei einen Fehler, kommen also keine Sicherheitspatches mehr an. Legen Sie deshalb zuerst ein Backup an, danach prüfen Sie die Änderung in kleinen Schritten. Die Befehle unten sind ein Beispiel für Ubuntu 24.04 und neuer; der Dateiname hängt von Ihrer Version ab.

sudo cp /etc/apt/sources.list.d/ubuntu.sources /root/ubuntu.sources.backup
sudo apt update
apt policy
sudo apt-get -s upgrade

Der erste Befehl kopiert die Datei. Danach aktualisiert apt update die Indizes und zeigt die genutzten Adressen. apt policy zeigt, woher Pakete kommen würden. Der Schalter -s im letzten Befehl steht für Simulation, er listet also auf, was passieren würde, ohne etwas zu installieren.

Geht etwas schief, ist der Rückweg allerdings einfach. Kopieren Sie das Backup zurück und führen Sie apt update erneut aus. Ihr Server kehrt dann zur letzten funktionierenden Konfiguration zurück, und Sie können in Ruhe suchen.

Auf RPM basierten Systemen sind dnf makecache und dnf repolist die Entsprechungen. Das Ausgabeformat kann sich mit der dnf Version ändern. Prüfen Sie daher mit eigenen Augen, ob die erwartete Adresse erscheint, und gehen Sie erst dann zum echten Update über.

Wie bleiben Updates sicher, wenn Sie dem Spiegel nicht vertrauen?

Beim Linux Mirror beruht die Sicherheit auf Signaturen, nicht auf der Ehrlichkeit des Spiegels. Das Dokument SecureApt von Debian beschreibt die Kette. Die Prüfsumme jedes Pakets steht in einer Packages Datei, die Prüfsummen der Packages Dateien stehen in der Datei Release, und eine OpenPGP Signatur der Distribution schützt die Datei Release.

Bei apt update prüft apt diese Signatur (Release.gpg oder InRelease). Kann apt sie nicht prüfen, warnt es Sie und stuft die Pakete dann als nicht vertrauenswürdig ein. Die Seite betont außerdem, dass ein Spiegel kein eigenes Vertrauen braucht, weil die Signatur den Inhalt bestätigt, egal welcher Spiegel ihn liefert.

In der Praxis zerstört ein fremder Spiegel, der ein Paket verändert, die Kette der Prüfsummen, und apt bricht ab. Seien Sie allerdings sorgfältig, wenn Sie selbst einen Schlüssel hinzufügen, denn die einzige verbleibende Schwachstelle ist der Schlüssel, dem Sie vertrauen.

Wie kontrollieren Sie die GPG Prüfung bei apt und dnf?

Bei apt heißt die Einstellung Signed-By. Die offiziellen Schlüsselbunde von Debian und Ubuntu liegen in /usr/share/keyrings/. Das Debian Wiki weist darauf hin, dass der alte Weg über /etc/apt/trusted.gpg und apt-key ab Debian 13 als veraltet gilt. Legen Sie neue Schlüssel daher in einer eigenen Datei pro Repository ab und verweisen Sie mit Signed-By darauf.

Bei dnf prüft gpgcheck die Signaturen der Pakete, und repo_gpgcheck prüft die Metadaten des Repositorys. Zudem enthält die Option gpgkey die Adresse des Signaturschlüssels. Ein Detail ist allerdings wichtig: Die dnf Referenz nennt gpgcheck und repo_gpgcheck standardmäßig ausgeschaltet. Die .repo Dateien der Distributionen schalten sie meist ein, in einer selbst geschriebenen Datei müssen Sie das jedoch ausdrücklich tun.

[example-internal]
name=Example internal mirror
baseurl=https://mirror.example.com/repo/example/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/EXAMPLE-GPG-KEY

Aktivieren Sie repo_gpgcheck nur, wenn das Quell Repository seine Metadaten signiert. Sonst meldet dnf einen Fehler. Sind Sie unsicher, lesen Sie die Dokumentation Ihrer Distribution.

Spielt der Unterschied zwischen HTTP und HTTPS bei einem Spiegel eine Rolle?

Ja, aber halten Sie die beiden Ebenen auseinander. Eine Signatur beweist, dass sich ein Paket nicht verändert hat. HTTPS verschlüsselt dagegen den Übertragungsweg. Die Beispieladresse in der Ubuntu Dokumentation lautet http://archive.ubuntu.com/ubuntu; die Integrität bleibt also dank der signierten Struktur auch über einfaches HTTP erhalten.

HTTPS erschwert es dagegen Dritten im Netz, zu sehen, welche Pakete Sie laden. Außerdem filtern oder verändern manche Firmennetze den Datenverkehr über HTTP. Deshalb empfehlen wir HTTPS, wenn der Spiegel es anbietet.

Veröffentlichen Sie einen eigenen Spiegel, bringt ein SSL Zertifikat etwas Mehraufwand, erleichtert aber die Entscheidung auf der Clientseite. Ob Ihr Zertifikat gültig ist, prüfen Sie mit unserem SSL Check.

Wann lohnt sich ein eigener Linux Mirror im Unternehmensnetz?

Ein eigener Spiegel zahlt sich also nur aus, wenn mehrere Bedingungen zusammentreffen. Für die meisten Websites und kleinen Shops genügen daher öffentliche Spiegel völlig. Ein interner Spiegel schafft dort Wert, wo Paketdownloads für die Organisation ein echter Kostenfaktor oder ein Risiko sind.

• Viele Server laden dieselben Pakete, und Sie wollen die ausgehende Bandbreite schonen.
• Server erreichen das Internet nicht direkt, etwa in einem abgeschotteten Netz hinter einer strengen Firewall.
• Sie wollen Updates zu einem Stichtag einfrieren und in jeder Umgebung dieselben Paketversionen nutzen.
• Ihre Deployment Pipeline muss auch dann laufen, wenn ein externer Spiegel ausfällt.

Kontrolle ist die zweite Seite eines privaten Linux Mirrors: Sie entscheiden, welches Paket wann in Ihr Netz kommt. Diese Macht ist in abgeschotteten Netzen und bei strengen Compliance Vorgaben wertvoll. Allerdings macht sie Sie auch dafür verantwortlich, Updates rechtzeitig zu synchronisieren.

Fragen Sie sich also: Verwalten Sie einen einzelnen Server oder eine ganze Flotte? Für einen einzelnen VPS bedeutet ein interner Spiegel meist mehr Arbeit als Nutzen.

Vollständiger Spiegel, Teilspiegel oder Caching Proxy: was passt?

Die drei Ansätze für einen Linux Mirror dienen unterschiedlichen Bedürfnissen. Die Debian Dokumentation empfiehlt für einen vollständigen Spiegel das Werkzeug ftpsync. Für Organisationen, die nur bestimmte Versionen brauchen, nennt sie debmirror als gute Lösung. Ein Caching Proxy ist ein eigener Weg.

Wie viel Platz braucht ein vollständiger Spiegel? Die Debian Dokumentation verweist dafür auf eine eigene Seite zur Spiegelgröße. Die Größen ändern sich mit jeder Version, daher nennen wir keine Zahl. Bei einem Teilspiegel bestimmen die Zahl der Architekturen und Bereiche, wie schnell die Platte vollläuft.

Für die meisten Firmennetze genügen ein Teilspiegel oder ein Caching Proxy. Ein vollständiger Spiegel lohnt sich erst bei dauerhaftem und breitem Bedarf.

Wie bauen Sie einen Teilspiegel für Debian und Ubuntu?

Für einen Teilspiegel können Sie debmirror nutzen. Das Werkzeug prüft die Signatur der Indexdateien gegen einen lokalen Schlüsselbund. Deshalb müssen Sie zuerst den offiziellen Schlüssel der Distribution in diesen Schlüsselbund importieren. Die Befehle unten fassen die Methode aus der Handbuchseite man debmirror kurz zusammen.

sudo apt install debmirror debian-archive-keyring
gpg --no-default-keyring --keyring trustedkeys.gpg --import /usr/share/keyrings/debian-archive-keyring.gpg
debmirror --method=https --host=mirror.example.com --root=debian --dist=CODENAME --section=main --arch=amd64 /srv/mirror/debian

Der erste Befehl installiert das Werkzeug. Der zweite importiert den offiziellen Schlüssel. Dann lädt der dritte Befehl den Spiegel für die gewählte Version, den Bereich und die Architektur nach /srv/mirror/debian. Im Feld host tragen Sie statt der Beispieldomain die Quelle ein, die Sie aus der offiziellen Liste gewählt haben.

Bei Ubuntu ist die Idee gleich, allerdings unterscheiden sich Schlüsselbund und Verzeichnispfad. Prüfen Sie die Optionen mit man debmirror auf Ihrer Version, bevor Sie etwas ausführen. Die erste Synchronisation kann groß sein, lesen Sie daher die Debian Dokumentation zu den Größen.

Wie bauen Sie mit reposync einen Spiegel auf RPM Systemen?

Bei dnf synchronisiert das Plugin reposync ein entferntes Repository in ein lokales Verzeichnis. Laut Dokumentation lädt es also bereits vorhandene Pakete nicht erneut. Das Plugin gehört zum Paket dnf-plugins-core, und das Repository benennen Sie mit --repoid.

sudo dnf install dnf-plugins-core createrepo_c
sudo dnf reposync --repoid=EXAMPLE-REPO --download-path=/srv/mirror --download-metadata --newest-only --gpgcheck
sudo createrepo_c --update /srv/mirror/EXAMPLE-REPO

Mit --download-metadata ist die geladene Kopie sofort als Repository nutzbar. Die Option --newest-only holt nur die neuesten Pakete. Dagegen entfernt --gpgcheck nach dem Download Pakete, deren Signatur nicht stimmt. Zudem empfiehlt die Dokumentation, zusammen mit --newest-only auch createrepo_c --update auszuführen, damit fehlende Pakete aus den Metadaten verschwinden.

Im letzten Schritt veröffentlichen Sie das Verzeichnis als statische Dateien über einen Webserver wie nginx oder Apache, und Clients tragen diese Adresse als baseurl in ihre .repo Datei ein. Die Repository Kennung (EXAMPLE-REPO) muss vorher im System definiert sein.

Wie richten Sie Client Server auf einen internen Spiegel aus?

Ist der Spiegel bereit, stellen Sie die Clients einzeln oder per Konfigurationsmanagement um. Unter Debian und Ubuntu ändern Sie die Zeile URIs in der sources Datei. Auf RPM Systemen aktualisieren Sie die Zeile baseurl in der .repo Datei.

1. Sichern Sie zuerst die aktuelle Konfiguration.
2. Stellen Sie auf einem Testserver die Zeile URIs oder baseurl auf die interne Adresse um.
3. Führen Sie unter Debian und Ubuntu apt update aus, auf RPM Systemen dnf makecache, und bestätigen Sie, dass kein Fehler auftritt.
4. Achten Sie darauf, dass keine Signaturwarnung erscheint; erscheint eine, prüfen Sie den Schlüssel.
5. Rollen Sie dann auf die anderen Server aus, beginnend mit einer kleinen Gruppe.

Überwachen Sie den Spiegel außerdem. Scheitert eine Synchronisation, bleiben Clients dann bei alten Paketen, und Sie merken es womöglich nicht. Sicherheitsupdates kommen über einen eigenen Kanal, also stellen Sie sicher, dass Ihr Spiegel diesen Kanal ebenfalls abdeckt.

Wie wirken sich Sicherheitsupdates aus, wenn der Spiegel hinterherhinkt?

Distributionen veröffentlichen Sicherheitskorrekturen meist in einem eigenen Kanal. Kopiert Ihr Spiegel diesen Kanal, entsteht eine Verzögerung in Höhe des Synchronisationsintervalls. Bei öffentlichen Spiegeln ist dieses Intervall kurz. Bei Ihrem eigenen Spiegel legen Sie die Häufigkeit allerdings selbst fest.

Zum Beispiel sehen Ihre Clients einen neuen Sicherheitspatch im ungünstigsten Fall bis zu eine Woche zu spät, wenn Sie nur einmal pro Woche synchronisieren. Ist der Patch kritisch, kann diese Wartezeit also untragbar sein. Sie könnten den Sicherheitskanal häufiger und die übrigen Kanäle seltener abgleichen.

Haben Sie außerdem Versionen bewusst eingefroren, planen Sie vorab, wie Sie Sicherheitspatches erhalten. Ein reiner Caching Proxy vermeidet das Problem, weil Patches direkt von der Distribution fließen. Für das größere Serverbild lesen Sie auch unseren Leitfaden zur CSF Firewall.

Was lernen Sie aus den Spiegelregeln von Debian?

Debian verlangt von Betreibern, die in die offizielle Spiegelliste wollen, viermal täglich zu synchronisieren und für die unterstützten Architekturen auch Quelldateien vorzuhalten. Dieselbe Seite beschreibt Push Mirroring: Ein vorgelagerter Spiegel nutzt einen SSH Auslöser, um dem nachgelagerten Spiegel zu sagen, dass er sich aktualisieren soll. So erreichen Änderungen die Spiegel möglichst schnell.

Für Ihren eigenen Spiegel ziehen Sie aus diesen Details drei Lehren. Erstens ist die Synchronisationshäufigkeit eine Entscheidung und kein Zufall. Zweitens müssen Updates in der richtigen Reihenfolge geschrieben werden, weshalb Debian ftpsync statt selbstgebauter rsync Skripte empfiehlt. Drittens brauchen auch Auslöser und Zeitplaner, die Sie einrichten, eine Überwachung.

Kurz gesagt: Ein Spiegel ist keine einmalige Installation, sondern ein Dienst, den Sie dauerhaft betreiben.

Was überwachen Sie, sobald Ihr eigener Spiegel läuft?

Ein Linux Mirror ist kein Ordner, den Sie einmal einrichten und vergessen. Er kann leise kaputtgehen, denn Clients merken es erst, wenn ein Update fehlschlägt. Prüfen Sie daher regelmäßig einige einfache Signale:

• Den Zeitpunkt der letzten erfolgreichen Synchronisation und den nächsten geplanten Lauf.
• Die Plattenbelegung, denn eine Synchronisation bleibt auf einer vollen Platte stecken.
• Steigende Zahlen von 404 und 5xx Fehlern im Webserver Protokoll.
• Das Ablaufdatum Ihres HTTPS Zertifikats.
• Aktualisierungen des Schlüsselbund Pakets, wenn die Distribution ihren Signaturschlüssel wechselt.

Diese Prüfungen automatisieren Sie mit einem geplanten Job und einem Alarmkanal. Wenn aber niemand den Alarm wirklich liest, ist ein öffentlicher Spiegel die ehrlichere Wahl als ein eigener.

Wann überlassen Sie das besser Ihrem Hostinganbieter?

Nicht jede Einstellung am Linux Mirror muss in Ihrer Verantwortung liegen. In manchen Fällen ist es richtig, die Arbeit dem Anbieter zu überlassen:

• Bei Shared Hosting oder einem cPanel Konto haben Sie keinen Administratorzugriff (root), also können und sollten Sie den Paketmanager nicht anfassen.
• Bei einem verwalteten VPS kann eine geänderte Quellenliste Ihren Supportanspruch berühren, fragen Sie daher zuerst den Anbieter.
• Ändern Sie den Spiegel nicht auf dem Server, auf dem Ihr Live Shop läuft, bevor Sie es anderswo getestet haben.
• Können Sie für einen Spiegelserver keinen Speicher, keine Überwachung und keine Sicherheitspatches einplanen, nutzen Sie einen öffentlichen Spiegel oder einen Caching Proxy.

Stellen Sie sich eine weitere Frage: Wer rettet die Website, wenn ich es falsch mache? Lautet die Antwort Support des Anbieters, ist ein vorheriges Gespräch oft die günstigste Versicherung. Das ist auch die vorsichtige Haltung, die wir empfehlen.

Außerdem betreiben manche Anbieter eigene Spiegel. Lesen Sie die Dokumentation Ihres Anbieters und fragen Sie den Support bei Unklarheiten. Für die größere Infrastrukturentscheidung lesen Sie unsere Beiträge zur Auswahl von Webhosting und zur Backup Strategie für Websites.

Gibt es Spiegel auch für Docker, pip und npm?

Ja, die Spiegel Idee beschränkt sich nicht auf Linux Pakete. Auch für die Registries, die Entwickler nutzen, gibt es ähnliche Cache und Spiegel Lösungen. Die Logik bleibt also gleich: Abhängigkeiten aus einer nahen Quelle holen, die Sie kontrollieren können.

Zur Container Seite lesen Sie unseren Docker Leitfaden. Auch beim Bauen von Images laufen Paketinstallationen, daher zeigt sich Ihre Spiegelwahl in der Build Dauer. Jedes Werkzeug hat allerdings eine eigene Konfigurationsdatei, also bestätigen Sie Befehle und Einstellungsnamen in der offiziellen Dokumentation des jeweiligen Werkzeugs.

Das Sicherheitsthema bleibt gleich. Aus welcher Quelle Sie auch laden, lassen Sie die Prüfung von Signaturen oder Prüfsummen eingeschaltet. Außerdem ist der Abschnitt zur Komponentensicherheit in unserem Beitrag zu den OWASP Top 10 ein guter Startpunkt, um über Ihre Abhängigkeitskette nachzudenken.

Wie sieht ein kurzer Fahrplan für Ihre Spiegel Entscheidung aus?

Um die Entscheidung für einen Linux Mirror zu vereinfachen, folgen Sie also dieser Reihenfolge. Jeder Schritt baut auf dem vorigen auf, daher macht das Überspringen die Arbeit schwerer.

1. Finden Sie Ihre aktuelle Spiegeladresse in der sources Datei oder der .repo Datei.
2. Messen Sie Ihre Updatezeit; ist sie langsam, testen Sie einen nahen Kandidaten aus der offiziellen Liste.
3. Bestätigen Sie, dass die Signaturprüfung aktiv ist (Signed-By, gpgcheck).
4. Erfordern Serverzahl und Netzgrenzen es, denken Sie zuerst an einen Caching Proxy und dann an einen Teilspiegel.
5. Bauen Sie einen eigenen Spiegel, überwachen Sie Synchronisation und Plattenbelegung.
6. Bei Shared Hosting oder verwaltetem VPS sprechen Sie mit Ihrem Anbieter.

Zusammengefasst in einem Satz: Ein Linux Mirror verbessert Tempo und Kontinuität, und die Signatur schützt das Vertrauen. Bei einem kleinen Setup ist ein öffentlicher Spiegel mit aktiver Signaturprüfung oft die beste Balance.

Möchten Sie Infrastruktur und digitale Marketingziele gemeinsam denken, schauen Sie sich unsere Webdesign Leistung an oder nehmen Sie Kontakt auf. Ihre Domain und DNS Einstellungen prüfen Sie außerdem mit unserer DNS Abfrage.

Quellen: Die technischen Angaben oben stützen sich auf die folgenden offiziellen Dokumente. Befehle und Standardwerte können in Ihrer Version abweichen, daher gilt immer die Dokumentation Ihrer eigenen Distribution zuerst.

• Debian: Mirroring Debian (ftpsync, debmirror, Push Mirroring)
• Debian Wiki: SecureApt (Signaturkette)
• Debian Wiki: SourcesList (Format deb822)
• Ubuntu Server Dokumentation: Paketverwaltung (ubuntu.sources)
• DNF Konfigurationsreferenz (baseurl, mirrorlist, metalink, gpgcheck)
• DNF Plugin reposync