Repo Cache
Aus Fedorawiki.de
| Dieser Artikel ist veraltet und Bedarf einer Aktualisierung. |
Damit beim Einsatz von mehreren Linux-Rechnern in einem kleinem Netzwerk nicht jeder die Updates aus dem Internet herunterladen muss (und somit viel unnötiger Traffic verursacht wird) oder bei einer Neuinstallation nicht mehrere hundert Megabyte Daten aus dem Internet heruntergeladen werden müssen, kann ein sogenannter Repository Cache eingerichtet werden.
Die Funktion dieses repo-cache Servers ist recht simpel: Der Server gleicht in einem bestimmten Intervall (z.b. wöchentlich oder täglich) die Daten eines (in der Nähe befindlichen) Spiegelservers von Fedora ab. Diese werden anschliessend per NFS im LAN freigegeben (oder lokal genutzt) und auf den Clients eine weitere Repo-Definition in die Yum-Konfiguration eingefügt.
Inhaltsverzeichnis |
Die Standard Repositories in Fedora
In Fedora Core sind standardmässig drei Repositories aktiviert. Diese sind die produktiven Varianten von 'Fedora Core' (mit dem Inhalt der Installationsmedien), 'Fedora Updates' (freigegebene Updates) und 'Fedora Extras' (Zusatzsoftware). Wie bereits dem Namen zu entnehmen ist, werden die Updates über das 'Fedora Updates' Repository verteilt. Diese Definitionen sind in Dateien im Verzeichnis /etc/yum.repos.d/ abgelegt:
[liro@fc5 yum.repos.d]$ ll -rw-r--r-- 1 root root 840 Mar 15 00:20 fedora-core.repo -rw-r--r-- 1 root root 763 Mar 15 00:20 fedora-extras.repo -rw-r--r-- 1 root root 790 Mar 15 00:20 fedora-updates.repo
nebst den oben erwähnten Repositories gibt es noch weitere Test- und Entwicklungs-Repos (z.t. auch in den obigen Dateien integriert), welche jedoch mit enabled=0 standardmässig deaktiviert sind.
Wir wollen in unserem Beispiel das fedora-updates Repository cachen.
| <b>Anmerkung:</b> Selbstverständlich kann auch jedes andere Repository nach dem gleichen Prinzip zwischengespeichert werden, wir beschränken uns jedoch hier auf die Updates. |
Einen Mirror wählen
Um an die Liste der Mirrors (Spiegelserver) zu gelangen, reicht ein Blick in die Repository-Datei:
[updates] name=Fedora Core $releasever - $basearch - Updates #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Hier zu sehen die beiden Einträge, welche die Liste der Mirrors definieren (baseurl ist auskommentiert, damit die Mirror-Liste angewandt wird). Dieser Link kann nun in einen Browser kopiert werden und $releasever durch die benutzte Fedoraversion (bei Fedora Core 5 -> 5) ersetzt werden.
Etwas übersichtlicher gestaltet sich die Suche nach einem Mirror mittels diesem Link (einen updates-released Mirror wählen), da die Mirrors hier mit Ländercode angegeben werden.
Den gewählten Mirror synchronisieren
Nutzung eines rsync Mirrors
Um den gewählten Mirror zu synchronisieren gibt es eine sehr einfache und praktische Variante mit 'rsync'. Leider unterstützen nur wenige Mirrors rsync (dies muss vom Administrator eingerichtet bzw. freigegeben werden). rsync muss im Speicher-Verzeichnis für die Daten ausgeführt werden.
rsync -avrt rsync://rsync.uni-bayreuth.de/fedora-linux-core/updates/6/i386 \
--exclude=debug/ --exclude=repodata/ --exclude=*debuginfo* --exclude=*i18* \
--exclude=*langpack*/mirror/fedora/linux/core/updates/6/i386/
Ein erweiterter Artikel zum Synchronisieren mit einem rsync-Skript gibt auf dieser Seite
Falls die Nutzung von rsync aus irgendwelchen Gründen nicht möglich ist oder lieber mit FTP geabreitet werden will, sollte das nächsten
Nutzung von FTP-Mirrors
Um eine Synchronisation eines FTP-Mirrors einzurichten, verwenden wir das Programm lftp. Sollte es nicht installiert sein, kann es mittels
nachinstalliert werden.
'lftp' beherrscht einen sogenannten Befehlsmodus, d.h. mit einem einzigen Befehl können mehrere FTP-Kommandos ausgeführt werden. Dies ist notwendig, da wir uns auf den FTP-Server einloggen (1. Schritt), ins Zielverzeichnis wechseln (2. Schritt) und zuletzt die Daten synchronisieren (3. Schritt).
Mit folgendem Befehl wird der fedora core 6 update mirror von Switch mit folgenden Vorgaben abgeglichen:
- der Transfer soll mit einer Transferlimite von 80kbit/s vollzogen werden (set net:limit-rate 81920)
- zuerst sollen die lokalen, veralteten Daten gelöscht werden (--delete-first)
- das Unterverzeichnis 'debug' soll ingnoriert werden (-X debug/*)
- Zielverzeichnis für die Daten ist /repo_cache/updates_fc6
- der gesamte Transfer wird in die Logdatei fc6_repo_update.log in demselben Verzeichnis geloggt (--log=/repo_cache/fc5_repo_update.log)
lftp -c 'set net:limit-rate 81920;open mirror.switch.ch;anon;mirror \ --log=/repo_cache/fc5_repo_update.log \ --delete-first -X debug/* \ /mirror/fedora/linux/core/updates/6/i386/ /repo_cache/updates_fc6'
Die Schreibweise mit den "\" ermöglicht es, überlange Befehle komfortabel mit einer Art Zeilenbrüchen einzugeben und sie trotzdem als eine Zeile interpretieren zu lassen.
Beim ersten Aufruf, der ersten Synchronisation kann dieser Vorgang lange andauern (da z.T. mehrere Gigabyte an Updates vorliegen). Für jede weitere Synchronisation wird sich das Transfervolumen in Grenzen halten, da nur neue Inhalte geladen werden.
|
| <b>Anmerkung:</b> Selbstverständlich kann dieser Vorgang auch in ein Shell-Skript verfasst werden, wo zusätzlich die Logdateien rotieren und z.B. Start- und Endzeit vermerkt werden |
Lokales yum-Repository anlegen
Um ein eigenes lokales Repository zu erstellen, wird das Programm createrepo benötigt.
In diesem Beispiel soll der Ordner /repo_cache/updates_fc6 dafür benutzt werden. Anschließend werden mit createrepo die benötigten (Meta-)Dateien erstellt.
createrepo /repo_cache/updates_fc6
In dem Verzeichnis selbst wird dabei ein Unterordner repodata erstellt, der die benötigten Dateien enthält.
Datenfreigabe (via NFS)
Da wir nun lokal die Daten des gewählten Repositories haben, müssen diese nun noch freigegeben werden. Dies geschieht mittels eines Eintrages in (Freigabe via NFS):
/repo_cache *(ro,sync)
Hier wird das Repository allen Stationen freigegeben (read-only). Nach einem Neustart von NFS wird dieses Verzeichnis zur Verfügung gestellt.
Datenanbindung
Entweder kann der NFS-Export direkt in die fstab (/etc/fstab) eingetragen werden oder über den 'automounter' (Dienst autofs) angesprochen werden (empfohlene Variante). Nach dem Testen des Zugriffs auf den NFS-Export mit
mount -t nfs [server]:/repo_cache /[zielverzeichnis]
kann eine der oben erwähnten Varianten für die permanente Anbindung verwendet werden.
Datenfreigabe (via http)
Das Verzeichnis /repo_cache muss zu Verzeichnis des Webserver /var/www/ hinzugefügt werden. Es liesse sich auch durch Anpassen der Konfiguration einrichten, aber dies ist der einfachere Weg.
Link zum Inhalt erstellen
Kontrolle, ob der Link erstellt wurde.
ls -l /var/www/html/repo_cache
Starten des Web-Server
|
| <b>Anmerkung:</b> Dieser Abschnitt wurde nicht an die neueren Versionen von Fedora angepasst. Berechtigungen setzen, SELinux und anderes muss wahrscheinlich angepasst werden. |
Yum-Konfiguration erweitern
Damit yum nun unser oben erstelltes Repository verwendet, müssen wir eine weitere Repo-Definition in /etc/yum.repos.d/ erstellen. Dazu kopieren wir die vorhandene Datei fedora-updates.repo nach 'fedora-updates-cache.repo'.
Für die Anbindung an einen NFS-Server
[cache-updates] name=Fedora Core $releasever - $basearch - Updates baseurl=file:///[nfs-mount-verzeichnis]/updates_fc$releasever enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Für die Anbindung an einen Web-Server
[cache-updates] name=Fedora Core $releasever - $basearch - Updates baseurl=http://[IP-Adresse des Servers]/updates_fc$releasever enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
Im der neuerstellten Definition sind zwei Optionen anzupassen:
- den Repo-Namen ([cache-updates])
- und die baseurl (mit file:// kann ein lokales Verzeichnis angegeben werden und mit http:// einen Pfad zu eimem Web-Server)
|
| <b>Anmerkung:</b> Es ist wichtig, dass sich die neue Repodefinition VOR dem Original sortiert. Ein 'll /etc/yum.repos.d' sollte die cache-repo-Definition vor dem Original auflisten |
Das Resultat
Sollte nun das Original-Repository weiterhin aktiviert bleiben (ist empfohlen) werden alle Updates seit der letzten Synchronisation von dort bezogen. Der Rest jedoch aus dem Cache (kein Herunterladen erforderlich):
[root@fc5 ~]# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories cache-updates [1/4] cache-updates 100% |=========================| 951 B 00:00 core [2/4] core 100% |=========================| 1.1 kB 00:00 updates [3/4] updates 100% |=========================| 951 B 00:00 extras [4/4] extras 100% |=========================| 1.1 kB 00:00 ... ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kernel i686 2.6.16-1.2096_FC5 cache-updates 13 M Updating: beagle i386 0.2.5-1.fc5.1 cache-updates 1.3 M gnome-pilot i386 2.0.13-7.fc5.6 cache-updates 538 k gnome-user-share i386 0.9-4 cache-updates 37 k libbeagle i386 0.2.5-1.fc5.1 cache-updates 35 k procps i386 3.2.6-3.3 cache-updates 206 k tzdata noarch 2006d-1.fc5 cache-updates 488 k Removing: kernel i686 2.6.15-1.2054_FC5 installed 34 M Transaction Summary ============================================================================= Install 3 Package(s) Update 7 Package(s) Remove 1 Package(s) Total download size: 16 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction ...
Das Herunterladen der Updates entfällt, da die Daten lokal vom NFS- oder von Web-Server bezogen werden.
