Obwohl wir uns über alle neuen Spiegel freuen, sollte jeder zukünftige Spiegel-Betreuer sicherstellen, dass er folgende Fragen beantworten kann, bevor er seinen eigenen Spiegel aufsetzt:
Die Haupt-Spiegelseite listet alle zum Spiegeln verfügbaren Archive auf.
Bitte lesen Sie die Spiegel-Größen-Seite für genauere Informationen über die Spiegel-Größen.
Das debian-security/-Archiv enthält Sicherheitsaktualisierungen, die durch das Debian-Security-Team veröffentlicht werden. Es klingt für jeden interessant, da aber Sicherheitsaktualisieren unregelmäßig auftreten, müssen Sie Ihren Spiegel sehr oft aktualisieren, um immer auf dem neuesten Stand zu sein (oder Push-Spiegeln benutzen), deshalb empfehlen wir nicht, es zu spiegeln. Debian gibt sich alle Mühe, stattdessen die hohe Verfügbarkeit von security.debian.org sicherzustellen.
Beachten Sie: Seit der Veröffentlichung von 3.1 (Sarge) im Juni 2005 ist das debian-non-US-Archiv missbilligt worden.
Viele Leute denken, dass ftp.debian.org die kanonische
Adresse von Debian-Paketen sei und dass es für sie am besten sei, von dort zu
spiegeln. Das ist nicht wahr.
ftp.debian.org ist
lediglich einer von mehreren Servern, die von einem internen Debian-Server
aktualisiert werden. Diese Adresse befindet sich derzeit in den Vereinigten
Staaten auf einem einzelnen Server und existiert hauptsächlich noch für die
Abwärtskompatibilität.
Die offiziellen Spiegel sind als guter Ort gedacht,
um davon zu spiegeln.
Jeder der Server in der vollständigen Liste aller
Spiegel, der das Type: Push-Primary
- oder Type:
Push-Secondary
-Tag besitzt, sollte fürs
Spiegeln gut geeignet sein. Bitte verwenden Sie einen, der netztopologisch
und geographisch nahe bei Ihnen liegt.
Es gibt keinen wirklichen Unterschied zwischen den verschiedenen Push-Primary Spiegeln, soweit es das Spiegeln betrifft. Auf der anderen Seite, wenn viele Leute ftp.debian.org verwenden (und unglücklicherweise tun Sie das), verschwendet das unnötigerweise die gespendete Bandbreite.
Spiegel-Administratoren in den Vereinigten Staaten sollten von
ftp.us.debian.org (der offiziellen Spiegeladresse aus den USA, einem
Push-Primary-Spiegel) spiegeln. Da diese Adresse aber auch ein Verteilalias
(round robin alias
) ist, ist es für gewöhnlich am
sinnvollsten, herauszufinden, welche der Komponente am besten ist und direkt
von dieser zu spiegeln.
Das Positive daran ist, dass das Risiko von Fehlschlägen beim
zweistufigen Rsync vermieden wird (verschiedene Stufen könnten auf
verschiedenen Maschinen ablaufen – dies kann bei bestimmten
Zeitfenster zu verschieden Daten führen (eine sog. Race
Condition
)). Das Negative daran ist, dass es auf eine einzige
Maschine konzentriert deren Leistungsfähigkeit variiert,
aber dies ist momentan unserem Spiegelnetz im Allgemeinen inhärent.
Die bevorzugte Methode zum Spiegeln ist das so genannte anonftpsync-Skript.
Das von uns empfohlene Spiegelprotokoll ist rsync.
Bitte spiegeln Sie Debian nicht mittels wget oder anderen FTP-basierten Werkzeugen. Sie scheinen gut zu funktionieren, aber sie haben eine Reihe von Problemen (sie können keine harten Links erkennen, das erstellen von Teilspiegeln ist schwieriger usw.).
Wir empfehlen die Verwendung dieses Skripts, um das Archiv zu spiegeln. Folgen Sie einfach den Anweisungen im Skript, um den Spiegel zu erstellen.
Hier einige Ratschläge für jene, die andere Methoden bevorzugen:
project/trace/ Verzeichnis des Debian-Spiegels hinzu,
der nach ihrem Server benannt ist. Das heißt, dass Sie
date -u > .../debian/project/trace/ihr.server
aufrufen sollen, nachdem Ihr tägliches rsync beendet ist.Aufgrund des bereits großen Umfangs des Debian-Archivs bevorzugen einige Leute, nur die Teile zu spiegeln, die sie auch benötigen. Wenn Sie etwas ausschließen wollen, sollten Sie Architekturen ausschließen.
Mit anonftpsync kann dies durch das Editieren der ARCH_EXCLUDE Variable geschehen.
Wir empfehlen Ihnen dringend, die project/-, doc/- und weitere Unterverzeichnisse nicht auszuschließen. Üblicherweise sind diese nicht sehr groß und trotzdem für die Benutzer nützlich. Insbesondere project/trace hilft sehr, falls es Spiegel-Probleme gibt.
Es können auch andere speziell geschriebene Skripte verwandt werden, aber
normalerweise sind diese nicht notwendig und werden auch für offizielle
Spiegel nicht empfohlen. Zum Beispiel würden diese Rsync-Optionen
alle Architekturen ausschließen:
--exclude binary-alpha/ --exclude *_alpha.deb --exclude *_alpha.udeb --exclude installer-alpha/ --exclude Contents-alpha*
--exclude binary-amd64/ --exclude *_amd64.deb --exclude *_amd64.udeb --exclude installer-amd64/ --exclude Contents-amd64*
--exclude binary-arm/ --exclude *_arm.deb --exclude *_arm.udeb --exclude installer-arm/ --exclude Contents-arm*
--exclude binary-armel/ --exclude *_armel.deb --exclude *_armel.udeb --exclude installer-armel/ --exclude Contents-armel*
--exclude binary-hppa/ --exclude *_hppa.deb --exclude *_hppa.udeb --exclude installer-hppa/ --exclude Contents-hppa*
--exclude binary-hurd-i386/ --exclude *_hurd-i386.deb --exclude *_hurd-i386.udeb --exclude installer-hurd-i386/ --exclude Contents-hurd-i386*
--exclude binary-i386/ --exclude *_i386.deb --exclude *_i386.udeb --exclude installer-i386/ --exclude Contents-i386*
--exclude binary-ia64/ --exclude *_ia64.deb --exclude *_ia64.udeb --exclude installer-ia64/ --exclude Contents-ia64*
--exclude binary-m68k/ --exclude *_m68k.deb --exclude *_m68k.udeb --exclude installer-m68k/ --exclude Contents-m68k*
--exclude binary-mips/ --exclude *_mips.deb --exclude *_mips.udeb --exclude installer-mips/ --exclude Contents-mips*
--exclude binary-mipsel/ --exclude *_mipsel.deb --exclude *_mipsel.udeb --exclude installer-mipsel/ --exclude Contents-mipsel*
--exclude binary-powerpc/ --exclude *_powerpc.deb --exclude *_powerpc.udeb --exclude installer-powerpc/ --exclude Contents-powerpc*
--exclude binary-s390/ --exclude *_s390.deb --exclude *_s390.udeb --exclude installer-s390/ --exclude Contents-s390*
--exclude binary-sparc/ --exclude *_sparc.deb --exclude *_sparc.udeb --exclude installer-sparc/ --exclude Contents-sparc*
Das Hauptarchiv wird zweimal täglich aktualisiert. Die Spiegel starten typischerweise um 9:00 und 21:00 Uhr (beides UTC) mit der Aktualisierung, aber das sind keine festen Zeiten und Sie sollten Ihren Spiegel nicht fest darauf einstellen.
Wir empfehlen, einmal täglich zu spiegeln. Häufigere Spiegeln als zweimal täglich ist sinnlos und führt höchstwahrscheinlich dazu, dass Ihr Spiegel gesperrt wird – machen Sie dies also nicht.
Ihr Spiegel sollte sein Update einige Stunden nach dem Hauptarchiv-Spiegelpuls durchführen. Sie sollten prüfen, ob die Site, von der Sie spiegeln, eine Zeitstempel-Datei in ihrem project/trace/ Unterverzeichnis hinterlässt. Die Zeitstempel-Datei wird genauso wie die Site benannt, und sie wird die Zeit der Beendigung der letzten Spiegel-Aktualisierung enthalten. Fügen Sie ein paar Stunden zu dieser Zeit hinzu (um sicher zu sein) und spiegeln Sie dann.
Die einfachste Art, um automatisch zu spiegeln, ist, den Prozess täglich von cron aufrufen zu lassen. Weitere Informationen mit man crontab.
Beachten Sie, falls ihre Site mit einem Push-Mechanismus angestoßen wird, müssen Sie sich um all dies nicht kümmern.
Push
-Spiegeln ist eine Art des Spiegelns, die wir entwickelt haben,
um die Zeit zu minimieren, die es benötigt, bis Änderungen im Archiv die
Spiegel erreichen. Der Server-Spiegel benutzt einen SSH-Auslöser, um dem
nachgeschalteten Spiegel mitzuteilen, dass er sein Archiv aktualisieren soll.
Das Pushing
(dt. Schieben
) ist normalerweise auf einen
sicheren Auslöser begrenzt, der keine variablen Daten akzeptiert und der
Rest des Spiegelprozesses ist ein einfaches Pull
(dt. Ziehen
),
wie dies auch mit einem Cron-Auftrag geschieht.
Push-Spiegeln wird benötigt, um mehrere Server synchron zu halten (wie die
Server in DNS round-robin-Aliasen wie ftp.us.debian.org), und wir
verwenden es gewöhnlich für unsere erst- und zweitrangigen Spiegel. Für
normale
Spiegel benötigt diese Methode viel Aufwand, um sie
aufzusetzen, was sich im Vergleich zu einem gut angepasstem cron-Auftrag
nicht lohnt.
Für eine detaillierte Beschreibung, wie dieses funktioniert, warum es sicher ist und wie ein Push-Spiegel aufgesetzt wird finden Sie in der kompletten Beschreibung.
Wenn Sie planen, den Debian-Spiegel durch HTTP zur Verfügung zu
stellen, fügen Sie bitte die folgenden Einstellungen zur
Apache-Konfiguration (natürlich unter der Annahme, dass Sie Apache benutzen)
im <Directory /pfad/zu/ihrem/debian/spiegel>
Block hinzu, wobei /pfad/zu/ihrem/debian/spiegel der tatsächliche
Namen des Verzeichnisses sein sollte, indem sich ihr Spiegel befindet:
Options +Indexes +SymlinksIfOwnerMatch IndexOptions NameWidth=* +SuppressDescription
Dies erlaubt Verzeichnis-Indizes und stellt sicher, dass Symlink-Verfolgung funktioniert. Die Datei-Namen in den Verzeichnis-Indizes werden nicht abgeschnitten, und die (größtenteils nichtvorhandenen) Beschreibungen werden nicht angezeigt.
In Apache 1.3.x kann die folgende Option hinzugefügt werden:
DirectoryIndex .
Fügen Sie diese Option nicht bei Verwendung von Apache 2.x hinzu.
Sobald ein Spiegelserver installiert ist, sollte er bei Debian registriert werden, damit er in die Liste der Spiegel aufgenommen werden kann. Anmeldungen können über unser ein einfaches Web-Formular erfolgen.
Probleme und Anfragen können Sie an mirrors@debian.org schicken.