RPM Repository Management mit pulp

In Service Transitions gibt es häufig die Anforderung, dass Server keinen direkten Zugriff auf Software-Quellen aus dem Internet bekommen dürfen.

Für den Betrieb stellt dies gelegentlich eine Herausforderung dar,  wenn es beispielsweise in einem spezifischen Setup keine Möglichkeit gibt, um rpm-Paketquellen zentral von einem Repository-Service zu beziehen. Oft spielen auch Aufwand und Lizenzgebühren eine große Rolle, denn es ist zwar eine Auswahl an Tools vorhanden, jedoch sind diese teilweise für den Service unverhältnismäßig komplex oder schlichtweg zu kostenintensiv.

Wenn es darum geht, eine zentrale Schnittstelle für die Bereitstellung von Software zu schaffen, so ist pulp (pulpproject.org) eine mögliche Lösung. Es werden dabei folgende Formate unterstützt:

• RPM (auch DRPM und SRPM, Errata)
• Python-PyPI
• Puppet-modules
• Docker-modules
• OSTree

Dieser Artikel soll sich vor allem an diejenigen richten, die eine Lösung suchen um RPM-Repositories zu verwalten. Nachfolgend sollen einige Schlagworte genannt werden um einen kleinen Überblick zu geben, was pulp in diesem Rahmen leistet und was (noch) nicht. Bezüglich der Verwaltung der Formate unabhängig von RPM, wird keine Aussage getroffen.

Features

• Single Point of Access – Clients benötigen im Betrieb keinerlei Verbindung zu externen RPM-Repositories, diesen übernimmt pulp
• SSL-verschlüsselte Kommunikation mittels Vertrauensstellung (nur mit pulp-Agent)
• Zeitgesteuerte Synchronisierung von Repositories mit der jeweiligen externen Quelle
• Einfaches Erstellen eigener Repositories
• Verwaltung der Agents erfolgt dezentral (dazu gleich mehr)

Aufbau

Der pulp-Server läuft standardmäßig als WSGI im Apache httpd und nutzt als Datenbank eine MongoDB.

Zudem werden mit Qpid Message-Queues verwaltet, über welche die Kommunikation mit dem Agent statt findet.

Die Installation und Konfiguration wird in der Projekt-eigenen Dokumentation sehr gut beschrieben, weshalb hier nicht weiter darauf eingegangen werden soll.

Empfehlenswert ist es jedoch, die unter /var/lib/ gelagerten Verzeichnisse (mongodb, pulp) auf ein separates Volume mit entsprechend ausreichendem Platz zu verschieben. Dabei ist der erforderliche Speicherplatz natürlich sehr von den zu spiegelnden und abzulegenden Paketen abhängig. Die Datenbank benötigt in unserem Setup im Hause (bei ca. 30 Repos mit insgesamt ca. 75.000 Paketen) etwas über 2GB.

Desweiteren wird eine funktionierende Zertifikatsstruktur benötigt, bei der eine lokale oder offizielle CA vorhanden ist oder während der Konfiguration erstellt wird. Die Agents erhalten jeweils das CA-Zertifikat, mit welchem sie den Server verifizieren.

Die Verwaltung aller Repositories erfolgt mit dem Tool pulp-admin, während mit dem pulp-consumer auf dem Agent die Registrierung am Server und das Anbinden an die jeweiligen Repos statt findet. Die Anbindung wird damit nicht vom Server gesteuert, sondern “dezentral” von dem jeweiligen Agent. Man kann sich jedoch auf dem Server eine Liste der angebundenen Server ausgeben lassen: pulp-admin consumer list --detail

Vorteile

• Die yum/dnf-Konfiguration wird automatisch gepflegt, wenn das Repo über den Agent angebunden wird
  • Dies kann umgangen werden, wenn für ein Repo --serve-http=true gesetzt ist, dann ist die Nutzung ohne Agent möglich (dies hängt mit der Art der Verifizierung/Authentifizierung über SSL zusammen)
• Es wird ein lokales Abbild eines Repo erstellt, womit die Daten im eigenen Rechenzentrum liegen -> schnellerer Zugriff
• Die Synchronisierungsjobs können ausgesetzt werden (wichtig für die Planung von Wartungen, in welcher sich die Update-Quelle nicht verändern darf) -> entspricht in etwa einem “Repo-Freeze”
• Man erhält ein zentrales Abbild darüber, welche Server welche Repositories überhaupt eingebunden haben (leider nicht, ob daraus auch Pakete bezogen wurden)
• Das System ist sehr robust, einfach zu bedienen und es werden nur Änderungen gespiegelt, sodass der Traffic im laufenden Betrieb eher gering ausfällt
• Umfangreiche REST-API

Nachteile

• Es können keine Revisionen von Repositories abgebildet werden bzw. erfordert dies persönlichen Einfallsgeist
• Ein zentralerer Ansatz wäre ggf. wünschenswert, bei welchem vom Server aus gesteuert werden kann, welche Repos ein Agent/Consumer erhält
• Die CLI-Tools sind gut zu bedienen, jedoch ist die Ausgabe nicht anpassbar und damit schwer weiter zu verarbeiten; ein Ausweichen auf die API ist damit empfohlen
  • Statistische Auswertungen sind damit nur mit erhöhtem Aufwand durchführbar

Hinweise und nützliche Kommandos

Repository mit externer Quelle erstellen

Falls das Repo bereits bei der Installation des Agents genutzt werden soll, bietet sich das Vergeben folgender Option an:

Syncen der Pakete aus der Quelle auf die Disk

Vorher sollte der verfügbare Speicher geprüft werden.

Regelmäßige Synchronisation eines Repos

Mit -s wird der jeweilige Zeitintervall der Synchronisierung festgelegt. Das Schema basiert (teilweise) auf ISO 8601.

Obiges Beispiel führt die Synchronisierung jeweils täglich, um 4 Uhr morgens (lokale Zeitzone) aus. Beginnend ab dem 01.01.2017.

Nutzung eines Repositories auf dem Client

Auf dem Client/Consumer ist einfach folgendes auszuführen (installierter Agent vorausgesetzt):

Dann dauert es nur einen kurzen Moment, bis der Consumer über das Queueing-System die Repository-Informationen bezogen hat, und es wird  unter /etc/yum.repos.d ein repo-File angelegt.

Besonders Ungeduldige können mit einem service goferd restart nachhelfen.