Schlagwort-Archive: Spiegelserver

RHEL Spiegelserver für arme Admins

2 Antworten

Es muss nicht immer gleich der Red Hat Sattelite Server sein, um einen lokalen Spiegelserver für die Installation von RPM-Paketen bereitzustellen.

Auf GitHub habe ich im Repository „Poor man’s RHEL mirror“ eine kleine Sammlung von Bash-Skripten zusammengestellt, mit denen sich ein Spiegelserver für RHEL-Repositories aufbauen lässt. Mit diesem können RHEL-Repositories, für welche man eine gültige Subskription besitzt, auf einen Host im lokalen Netzwerk synchronisiert und deren Pakete anderen RHEL-Servern im LAN zur Verfügung gestellt werden.

Neben der reinen Spiegelung können mit den auf GitHub bereitgestellten Skripten weitere lokale Stage-Repositories eingerichtet werden, mit denen sich die Verfügbarkeit von Paketen für einzelne Stages steuern lässt. Zusätzlich bietet das Projekt Skripte, um eigene YUM-Repositories zu erstellen, um zum Beispiel eigene Pakete darüber bereitstellen zu können. Des Weiteren wurde die Möglichkeit berücksichtigt, die Red Hat Errata Informationen in die lokalen RHEL-Repositories zu integrieren, um die --advisory Option für YUM auch auf Systemen nutzen zu können, die über keine eigene Verbindung zum Internet verfügen.

Warum ist dieses Projekt nützlich?

  • Es schont die eigene Internetverbindung, da Pakete nur einmal aus dem Internet heruntergeladen und anschließend im LAN zur Verfügung gestellt werden.
  • Es unterstützt bei der Erstellung eines YUM-Repositories zur Bereitstellung von RPM-Paketen.
  • Es unterstützt das Staging-Konzept, in dem es die Möglichkeit bietet, stage-spezifische Repositories bereitzustellen.
  • Es implementiert die Red Hat Errata Informationen in die gespiegelten RHEL-Repos, so dass diese von angebundenen Servern genutzt werden können, die über keine eigene Internetverbindung verfügen.
  • Es entstehen keine Zusatzkosten, da alle notwendigen Werkzeuge in den Repos einer RHEL-Standard-Subskription enthalten sind.

Wer kann dieses Projekt nutzen?

Das Projekt selbst steht unter der MIT-Lizenz und kann unter deren Bedingungen frei genutzt, modifiziert und weiter verteilt werden.

Für den Betrieb des Spiegelservers ist der Besitz einer gültigen RHEL-Subskription Voraussetzung. Denn es können nur jene Repos gespiegelt werden, für die eine gültige Subskription vorhanden ist. Auch alle an den Spiegelserver angeschlossenen Systeme müssen über eine entsprechende und gültige Subskription verfügen.

Bei Fragen zu Subskriptionen helfen die folgenden Seiten weiter:

Um mit diesem Projekt einen Spiegelserver aufsetzen und betreiben zu können, sind gewisse Kenntnisse erforderlich. Zu diesen zählen die Installation eine RHEL-Systems inkl. Registrierung, das Hinzufügen von Subskriptionen und die Installation von Paketen. Informationen hierzu bietet die Product Documentation for Red Hat Enterprise Linux 7.

Wie ist das GitHub-Repository zu diesem Projekt aufgebaut?

Das GitHub-Repository beinhaltet ein README, welches einen Überblick über das Projekt und eine Kurzbeschreibung der einzelnen Skripte in englischer Sprache beinhaltet. Im Master-Branch befindet sich die letzte stabile Version des Projekts. Weiterentwicklungen und Fehlerkorrekturen werden im Dev-Branch gepflegt und nach einer Testphase in den Master-Branch übernommen.

Sorgen, Nöte und Anträge sowie gefundene Fehler dürfen gern über die Issue-Funktion oder in den Kommentaren zu diesem Beitrag gemeldet werden.

An dieser Stelle folgt eine Beschreibung in deutscher Sprache, wie ein Spiegelserver mit diesem Projekt aufgebaut werden kann. Dabei handelt es sich um keine Schritt-für-Schritt-Anleitung und es werden grundlegende Kenntnisse über den Betrieb eines RHEL-Servers und die Installation sowie Konfiguration von Paketen vorausgesetzt.

Einrichtung eines Spiegelservers für arme Sysadmins

Um das Projekt nutzen zu können, benötigt man eine RHEL-Installation mit gültiger Subskription, auf welcher mindestens die folgenden Pakete installiert sein müssen:

  • reposync und createrepo, um RHEL-Repos synchronisieren und eigene Repos erstellen zu können
  • git zum Klonen des hier beschriebenen Projekts
  • Die Gruppe Basic Web Server oder einen anderen Webserver eurer Wahl, um die gespiegelten Repos über HTTP im LAN bereitstellen zu können

Zu Beginn sind die Dateien aus dem oben genannten GitHub-Repository in einem Verzeichnis auf dem lokalen Host bereitzustellen. Anschließend ist das Projekt zu konfigurieren. Die dazu notwendigen Schritte werden in den folgenden Abschnitten erläutert.

CONFIG.SAMPLE

Hierbei handelt es sich um die Hauptkonfigurationsdatei. Diese ist in CONFIG umzubenennen bzw. zu kopieren und zu editieren. In dieser Datei werden die Variablen gesetzt, die von den verschiedenen Shell-Skripten verwendet werden. Darunter sind z.B. Angaben, welche Repos gespiegelt werden und wo die Dateien gespeichert werden sollen.

Die Datei ist mit Kommentaren versehen und sollte weitgehend selbsterklärend sein (was für alle weiteren Dateien gilt).

create_yum_repo.sh

Dieses Skript kann genutzt werden, um ein eigenes YUM-Repository zu erstellen, über welches RPM-Pakete bereitgestellt werden können. Der Name des zu erstellenden Repos kann dem Skript als Parameter übergeben werden.

do_reposync.sh

Dies ist das Herzstück des Projekts. Es kümmert sich um die Spiegelung der RHEL-Repos. Die notwendigen Parameter werden in der Datei CONFIG konfiguriert.

Das Skript lädt nur die aktuellen Pakete aus den Repos herunter, löscht aus den Upstream-Repos entfernte Pakete jedoch nicht automatisch auf dem lokalen Host. Dies ist meinen persönlichen Anforderungen geschuldet. Es ist nicht ausgeschlossen, dass ich diese Parameter in Zukunft ebenfalls konfigurierbar gestalte.

Einen Überblick über den Speicherbedarf ausgewählter RHEL-Repos findet ihr hier: How much disk space do I need for reposync?

Um die heruntergeladenen Pakete im LAN zur Verfügung zu stellen, muss das BASEDIR (siehe CONFIG) über einen Webserver zugreifbar gemacht werden.

refresh_repo.sh

Werden einem Repo neue RPM-Dateien hinzugefügt, muss die Metadaten-Datenbank aktualisiert werden, damit Klienten die neuen Pakete auch finden können. Um diese Aktualisierung kümmert sich eben dieses Skript.

rsync_repo.sh

Mit diesem Skript lassen sich Repos auf dem lokalen System synchronisieren. Dabei werden die Dateien jedoch nicht 1:1 kopiert, sondern Hardlinks erstellt. Dies spart bei der Verwendung mehrerer Repos für unterschiedliche Stages Speicherplatz.

Neben dem kompletten Sync eines Repos ist es auch möglich, dem Skript eine Datei zu übergeben, welche die Namen der Pakete enthält, welche in ein weiteres Repo „transportiert“ werden sollen.

Wrapper-Scripts

In meiner Umgebung arbeiten wir mit bis zu vier verschiedenen Stages (E, I, Q und P). Für jede dieser Stages wird ein eigenes Stage-Repo des Upstream rhel-7-server-rpms erzeugt. Um diese Stage-Repos zu aktualisieren, werden die folgenden Skripte verwendet:

  • update_rhel-e-stage.sh
  • update_rhel-i-stage.sh
  • update_rhel-q-stage.sh
  • update_rhel-p-stage.sh

Jede Stage wird mit den Paketen aus der vorhergehenden aktualisiert. So ruft z.B. update_rhel-e-stage.sh das Skript rsync_repo.sh, um die Pakete aus dem lokalen Spiegel des Upstreams rhel-7-server-rpms zu importieren. update_rhel-i-stage.sh verwendet dementsprechend die rhel-e-stage als Quelle usw.

Diese Konfiguration ist für meinen Anwendungsfall optimiert. Die Verwendung der Skripte ist optional. Der Spiegelserver funktioniert auch ohne diese Wrapper-Scripts.

update_mirror_packages_and_erratas.sh

Dieses Skript aktualisiert die Pakete in den Repos des lokalen Spiegelservers inkl. der Red Hat Errata Informationen. Letztere ermöglichen es, die Erratas (RHSA, RHBA und RHEA) auch Systemen verfügbar zu machen, welche über keine Verbindung zum Internet verfügen.

Das Skript ist in der Standardeinstellung auf meinen Anwendungsfall optimiert und aktualisiert am Ende alle vorhandenen RHEL-Stage-Repos. Wer diese Funktion nicht benötigt, kann sie durch Auskommentieren der Zeilen 45 und 46 im Skript deaktivieren.

Anschließend kann ein Cronjob erstellt werden, welcher das Skript ausführt, um den Spiegelserver regelmäßig gemäß der eigenen Anforderungen zu aktualisieren.

Die gespiegelten Repos verfügbar machen

Hat man die Repos seiner Wahl gespiegelt, ergibt sich je nach Konfiguration eine Verzeichnisstruktur ähnlich der folgenden.

$ tree -L 2
.
├──  rhel-7-test-mirror
│   ├── rhel-7-server-extras-rpms
│   ├── rhel-7-server-optional-rpms
│   ├── rhel-7-server-rpms
│   ├── rhel-7-server-supplementary-rpms
│   ├── rhel-e-stage
│   ├── rhel-e-stage.repo
│   ├── rhel-i-stage
│   ├── rhel-p-stage
│   ├── rhel-q-stage
│   └── rhel-server-rhscl-7-rpms

Das Verzeichnis rhel-7-test-mirror aus obigen Beispiel enthält die gespiegelten Repos als Unterverzeichnisse. Dieses Verzeichnis sollte über einen Webserver zugreifbar gemacht werden, um die Pakete den Clients im lokalen Netzwerk verfügbar zu machen.

Im obigen Listing ist eine Datei namens rhel-e-stage.repo zu sehen. Dabei handelt es sich um eine Repo-Datei, welche heruntergeladen und im Verzeichnis /etc/yum.repos.d/ platziert werden kann, um wie in diesem Beispiel das Repo rhel-e-stage zu aktivieren.

Aufbau einer Repo-Datei

Das folgende Listing zeigt die kommentierte Repo-Datei aus dem vorstehenden Abschnitt. Sie kann als Muster für weitere eigene Repo-Dateien dienen.

[rhel-e-stage] # Repo ID
baseurl = http://example.com/rhel-7-test-mirror/rhel-e-stage/
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
name = Repo for rhel-7-server-rpms (Test)

Fragen, Sorgen, Nöte und Anträge

Das Projekt und die enthaltene Software werden so wie sie sind unter der angegebenen Lizenz zur Verfügung gestellt.

Fragen, Sorgen, Nöte und Anträge können sowohl hier in den Kommentaren zum Artikel, als auch auf Github hinterlassen werden.

Ich hoffe, dass dieses Projekt euch (weiterhin) nützlich ist und freue mich über Rückmeldungen, wie es euch gefällt.

Lokaler Spiegelserver für CentOS, Fedora und RHEL

4 Antworten

Durch die Nutzung eines lokalen Spiegelservers lassen sich Softwarepakete im lokalen Netzwerk bereitstellen. Dies schont die Internetverbindung und spart damit Bandbreite und evtl. Kosten.

Dieser Artikel beschreibt und dokumentiert die Einrichtung eines lokalen Spiegelservers für CentOS, Fedora und RHEL. Er bietet jedoch keine Schritt-für-Schritt-Anleitung. Für detaillierte Informationen wird auf die Quellen am Ende des Artikels sowie auf die manpages der einzelnen Kommandos verwiesen.

Konfiguration des Spiegelservers

Für den Betrieb eines lokalen Spiegelservers müssen ein Webserver sowie die CLI-Programme reposync und createrepo auf dem Host installiert werden, welcher als Spiegelserver dienen soll.

Hinweis für RHEL: Bei Verwendung von RHEL könnten nur jene Paketquellen gespiegelt werden, für welche der Spiegelserver eine gültige Subskription besitzt. Sollen auch solche Paketquellen gespiegelt werden, für die der Host keine Subskription besitzt, ist der Einsatz des kostenpflichtigen Satellite Servers erforderlich.

Diese Pakete befinden sich in der Regel in den Paketquellen, welche standardmäßig zur jeweiligen Distribution gehören. Für CentOS/RHEL können die Pakete zum Beispiel mit den folgenden Befehlen installiert werden:

$ sudo yum groupinstall "Einfacher Webserver"
$ sudo yum install yum-utils createrepo

Verwendet man bereits eine Fedora-Version mit dem YUM-Nachfolger DNF, so können die Pakete wie folgt installiert werden:

$ sudo dnf groupinstall "Web Server"
$ sudo dnf install yum-utils createrepo

Für eine Minimalkonfiguration des Webservers ist es erforderlich, den FQDN des Hosts als ServerName in der Datei /etc/httpd/conf/httpd.conf zu setzen.

Verwendet man die Hostfirewall, so ist der Zugriff auf den Webserver in dieser noch freizugeben.

$ sudo firewall-cmd --add-service http

Im nächsten Schritt wird unterhalb des Webserver-Wurzelverzeichnisses ein Verzeichnis erstellt, in dem zukünftig die gespiegelten Repositories abgelegt werden.

sudo mkdir /var/www/html/repomirror

Nun können mit reposync Pakete aus Online-Quellen auf den Spiegelserver heruntergeladen werden:

$ sudo reposync --gpgcheck -l --repoid= --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Die benötigte Repo-ID kann der ersten Spalte der Ausgabe von sudo yum repolist entnommen werden. Mit dem Parameter -n wird nur die aktuellste verfügbare Paketversion heruntergeladen.

Möchte man bspw. das base-Repository von CentOS spiegeln, so geschieht dies mit dem Kommando:

$ sudo reposync --gpgcheck -l --repoid=base --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Dadurch wird im Verzeichnis /var/www/html/repomirror das Unterverzeichnis base erstellt.

Damit die lokale Paketquelle nun von anderen Servern im lokalen Netzwerk genutzt werden kann, müssen noch die Metadaten mit Hilfe des folgenden Befehls erstellt werden. Beispiel für das base-Repository aus CentOS:

# cd /var/www/html/repomirror/base
# createrepo -v /var/www/html/repomirror/base/ -g comps.xml

Um den Abgleich der Paketquellen und die Erstellung der Metadaten zu automatisieren, kann folgendes Skript über den Cron-Dienst ausgeführt werden. Hier sind lediglich noch die REPO-ID und der Download-Pfad für die entsprechenden Variablen zu definieren.
#!/bin/bash
#
# Beschreibung: Skript zur Synchronisierung des RHEL-Repositories
# auf dem Spiegelserver
# Autor: Joerg Kastning <joerg(Punkt)kastning(aet)uni-bielefeld.de>

LOG="/var/log/do_reposync.log"
REPOID=" "
DOWNLOADPATH=" "

echo \# `date +%Y-%m-%d` - START REPOSYNC \# > $LOG

reposync --gpgcheck -l --repoid=$REPOID --download_path=/var/www/html/$DOWNLOADPATH --downloadcomps --download-metadata -n >> $LOG

echo \# `date +%Y-%m-%d` - END REPOSYNC \# >> $LOG
echo \# `date +%Y-%m-%d` - START CREATEREPO \# >> $LOG

cd /var/www/html/$DOWNLOADPATH/$REPOID
createrepo -v /var/www/html/$DOWNLOADPATH/$REPOID -g comps.xml >> $LOG

echo \# `date +%Y-%m-%d` - END CREATEREPO \# >> $LOG

exit 0

Erzeugung einer *.repo-Datei

Um die Paketquellen auf dem Spiegelserver zu verwenden, müssen diese auf dem Client bekannt gemacht werden. Dies geschieht zum Beispiel, indem auf dem Client eine *.repo-Datei im Verzeichnis /etc/yum.repos.d/ angelegt wird. Der Aufbau dieser Datei wird am Beispiel des CentOS-Repositories base demonstriert:

[base]
name= CentOS-$releasever - Base (local)
baseurl=http://FQDN/repomirror/base/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Legt man diese Datei auf dem lokalen Spiegelserver in einem Verzeichnis ab, welches über den Webserver erreichbar ist, kann sie von einem Client mit dem folgenden Kommando importiert werden:

# yum-config-manager --add-repo http://FQDN/repomirror/DATEINAME.repo

Besonderheit bei Verwendung von SELinux

Bei Verwendung von SELinux, müssen die Dateien noch mit dem Attribut httpd_sys_content_t ausgestattet werden. Für Dateien in /var/www/html geschieht dies mit:

restorecon -R -v /var/www/html/*

Quellen und weiterführende Links