In diesem Artikel geht darum, Katello als Package-Mirror für Icinga einzurichten. Konkret um Icinga for Windows, Debian / Ubuntu, Red Hat Enterprise Linux und andere Derivate.
Im Consulting treffen immer wieder verschiedene Produkte aus unserem Portfolio aufeinander und da wir natürlich auch an Open Source Projekten mitarbeiten und diese verbessern wollen, ist ein solches Aufeinandertreffen immer wieder der richtige Aufhänger. So war es auch kürzlich, als ich nach einem Kundentermin mit Christian Stein, dem Hauptansprechpartner für Icinga for Windows, gesprochen habe. Nach einem kurzen Gespräch über mein Anliegen verwies er mich an Alexander Klimov, der für diesen Teil der Icinga-Infrastruktur verantwortlich ist.
Dank der beiden gibt es nun ein neues Feature, das es erlaubt, Icinga for Windows einfacher mit der eigenen Umgebung zu synchronisieren, wenn man Katello (ein Plugin für Foreman) verwendet. Dieses Feature nennt sich PULP_MANIFEST und ermöglicht die Synchronisation als einfaches File-Repository. Dies gilt nicht nur für Benutzer des Open-Source-Projekts Katello, sondern auch für Benutzer der Downstream-Produkte Red Hat Satellite und Orcharhino sowie für Benutzer, die direkt die Backend-Komponente Pulp verwenden.
Dies möchte ich zum Anlass nehmen, nicht nur dieses neue Feature zu beleuchten, sondern auch ein kleines Tutorial zu schreiben, wie man die verschiedenen Repositories von Icinga mit Katello spiegeln kann und dabei dem geneigten Leser vielleicht noch die eine oder andere Hilfestellung zu geben. Natürlich kann das Ganze auf jedes Repository angewendet werden und neben den Typen, die ich gleich zeigen werde, gibt es noch weitere, die Katello unterstützt.
Package-Mirror für Icinga for Windows
Der Philosophie folgend, jedes Projekt bzw. jeden Hersteller als separates Produkt anzulegen, würde ich in Katello immer mit einem Produkt „Icinga“ beginnen, unter dem dann die Repositories angelegt werden. Hier möchte ich nun einfach mit Icinga for Windows beginnen. Im Wizard muss nur der Name festgelegt werden, aus dem sich das Label automatisch füllt, ich bleibe hier gerne bei „IcingaForWindows“, so bleibt beides gleich und ich kann einfach zwischen Benutzeroberfläche und Automatisierung wechseln. Als Type muss dann „file“ gewählt werden und als Upstream URL „https://packages.icinga.com/IcingaForWindows/“, da hier die Datei PULP_MANIFEST liegt.
Diese Datei enthält eine Liste aller Dateien mit Prüfsumme und Größe und dient Pulp als Metadaten für diesen Repository-Typ. Bei Icinga wird die Datei einfach durch ein eigenes Skript im bestehenden Workflow erzeugt, noch einfacher geht es ggf. mit pulp-manifest.
Zusätzlich kann eine Mirroring Policy ausgewählt werden. Hier mag „Additive“ interessant klingen, aber durch den Aufbau der IcingaForWindows-Repositories mit eigenen Metadaten würden ältere Versionen ohnehin nicht ohne weiteres verfügbar bleiben und im Repository wird auch schon eine Major-Version mehr als noch unterstützt vorgehalten. Daher macht in diesem Fall nur „Mirror Content“ Sinn. Ebenso macht nur der Haken bei Unprotected Sinn, da hier nicht mit Client-Zertifikaten gearbeitet werden kann.
Bei Bedarf kann im Vorfeld auch ein Proxy konfiguriert und nun für dieses Repository ausgewählt werden. Ist alles passend eingestellt, muss nur noch gespeichert und anschließend der Sync gestartet werden. Danach sollte das Repository so aussehen und für die Clients unter der URL bei Published At verfügbar sein:
Package-Mirror für Debian / Ubuntu
Der Workflow für Debian und Ubuntu wäre der gleiche, aber da Icinga hier zwei getrennte Repositories anbietet, muss das Beispiel für Debian auch für Ubuntu wiederholt werden. Bei anderen Projekten kann dies auch unterschiedlichen gelöst sein.
Auch hier legt man einfach ein Repository unter dem Produkt an, als Name schlage ich einfach mal „Debian“ vor, da man eigentlich immer auch das Produkt sieht. Für manche ist es aber zu unübersichtlich, wenn mehrere Repositories „Debian“ heißen, dann empfehle ich das Produkt als Präfix zu verwenden. Die Upstream URL wäre dann „https://packages.icinga.com/debian/“.
Die Releases/Distributions sind z.B. „icinga-bookworm icinga-bullseye“. Dies kann ich erst seit kurzem so empfehlen, da Katello bzw. Pulp früher nur eine flache Repository-Struktur hatte und somit hier mehrere Werte vermischt worden wären. Mittlerweile werden strukturierte Repositories unterstützt, was die Konfiguration vereinfacht. Aber auch hier gilt, wer lieber ein Repository pro Release haben möchte, hängt einfach den Releasenamen als Suffix an den Namen an und verwendet hier immer nur einen Wert.
Die Component gibt uns Upstream vor und ist hier „main“. Die Architectures erlauben eine Begrenzung auf beispielsweise „amd64“, was meinen Bedarf deckt. Auch hier könnte man separate Repositories bauen, aber das habe ich in der Praxis noch bei keinem Kunden als Wunsch gehabt.
Bei Icinga empfehle ich als Download Policy „On Demand“ und als Mirroring Policy „Content Only“, da Upstream sowieso alle Pakete im Repository belässt und man somit Platz sparen kann. Bei anderen Projekten ist dies nicht der Fall und man sollte sicherstellen, dass aller Content auch heruntergeladen wurde und gegebenenfalls auch nicht gelöscht wird, indem „Immediate“ und „Additive“ gewählt wird.
Auch hier kann natürlich ein Proxy hinterlegt werden und je nachdem, wie die Clients angebunden werden sollen, kann der Haken bei Unprotected entfernt werden. Damit ist auch das Repository fertig konfiguriert und kann gespeichert und synchronisiert werden.
In diesem Screenshot sieht man, dass ich einen GPG-Key hinterlegt habe. Dies funktioniert über den Menüpunkt Content Credentials und ist hier zu empfehlen um die Integrität sicherzustellen.
Package-Mirror für Red Hat Enterprise Linux und Derivate / SUSE
Manche sagen das Beste kommt zum Schluss, hier sage ich das Komplizierteste zum Schluss. Nicht weil es übermäßig kompliziert ist, aber im Gegensatz zu Debian / Ubuntu brauchen wir hier zwingend einzelne Repositories und im Falle von Icinga kommen noch Credentials dazu, um überhaupt Zugriff auf Upstream zu bekommen.
Hier legen wir also wieder ein Repository an, aber der Name setzt sich am besten direkt aus mehreren Komponenten zusammen, nämlich dem Namen des Betriebssystems, der Version und der Architektur in meinem Fall „EL9-x86_64“. Wer das bevorzugt, kann das natürlich wieder mit einem Präfix versehen und im Fall von Icinga kann die Architektur weggelassen werden. Zum einen nutzt Icinga den SUSE-Standard, bei dem alle Architekturen in einem Repository liegen, zum anderen stellt das Projekt nur architekturunabhängige und 64-Bit-Pakete zur Verfügung.
Wenn das Zielbetriebssystem Red Hat Enterprise Linux ist, kann mit den Publishing Settings, also der Zuordnung von Version und Architektur, noch die Client-Anbindung mit dem Subscription Manager vereinfacht werden. Auf anderen Betriebssystemen funktioniert dies nicht, was technische Gründe hat, aber hoffentlich irgendwann anders gelöst wird.
Dann wird die Upstream URL „https://packages.icinga.com/subscription/rhel/9/release/“ benötigt, unter der die Metadaten zu finden sind. Da ich selten die Notwendigkeit sehe, wähle ich meistens die Option Ignore SRPMs. Und da dieses Repository mittels User und Passwort zugriffsbeschränkt ist, hinterlege ich dies einfach als Upstream Username und Upstream Password. Ein Token würde hier auch unterstützt werden, wenn Upstream das verwendet.
Jetzt noch als Download Policy „On Demand“ und als Mirroring Policy „Content Only“ sowie bei Bedarf Proxy und Protection auswählen, speichern und den Sync starten.
Was man diesmal nicht sieht, ist, dass ich auch hier den GPG-Schlüssel hinterlegt habe. Auch nicht zu sehen, aber hoffentlich kann sich jeder bei Bedarf vorstellen, wie das für jede weitere Distribution und jede Version davon zu wiederholen ist. Zum Beispiel würde ich dann noch „EL8-x86_64“ oder „SLES15.6-x86_64“ anlegen.
Nächste Schritte
Es gibt natürlich noch ein paar weitere Schritte, aber ich bin mir noch nicht sicher, in welcher Reihenfolge ich sie angehen würde, weil das von Umgebung zu Umgebung unterschiedlich ist.
Auf jeden Fall müssen die gespiegelten Repositories auch von den Systemen genutzt werden, d.h. ich muss sie hier irgendwie anbinden. Das geht direkt über die Konfiguration des Paketmanagers dnf/yum, zypper oder apt, wenn man auf die Features des Subscription-Managers verzichten kann und im Idealfall mit z.B. Ansible eine solche Konfiguration einfach auf alle Systeme ausgerollt hat. Mit dem Subscription-Manager hat man die Kontrolle von zentraler Stelle aus und kann die Repositories bei Bedarf einfach über die GUI von Katello zuweisen. Für Windows ist beides keine Option, aber dank der Möglichkeiten von Icinga for Windows auch nicht notwendig, da es quasi selbst die Rolle des Paketmanagers übernimmt.
Ein weiterer Schritt wäre, über ein Staging nachzudenken. Durch die Definition eines Lifecycle Environment Paths, der beispielsweise aus Development, Testing und Production besteht. Ähnlich wie bei der Erstellung, Versionierung und dem Deployment von Content Views in diesen Stages kann sichergestellt werden, dass Updates erst nach erfolgreichem Test in der vorherigen, weniger kritischen Stage zur Verfügung gestellt werden. Im Falle von Icinga kann zusätzlich sichergestellt werden, dass der unterstützte Update-Pfad von „Master first, then Satellites, then Agents“ sicher eingehalten wird.
Ein weiterer denkbarer Schritt wäre die Automatisierung der Konfiguration in Katello. Das mache ich sehr gerne, um Reproduzierbarkeit zu haben, aber vor allem um mir und dem Kunden Klickarbeit zu ersparen. Dazu eignet sich wiederum Ansible mit der Collection theforeman.foreman.
Und natürlich ist Icinga nur ein gutes Beispiel, viele andere Projekte haben eigene Repositories, bei denen es auch Sinn macht, diese in die eigene Umgebung zu spiegeln. Ich denke da natürlich in erster Linie an Tools aus unserem Portfolio wie Grafana oder Elasticsearch, aber auch du findest sicher Beispiele in deiner IT-Umgebung.
Je nachdem lässt sich das Ganze natürlich auch auf andere Inhalte ausweiten. Zum Beispiel für Ansible, um den Zugriff auf Collections und Roles zu realisieren und bei Bedarf auch zu filtern, so dass nur geprüfter Content verwendet wird. Oder durch die Möglichkeit als Container Registry gezielt Container zur Verfügung zu stellen und sich Restriktionen wie das Rate-Limit von Docker-Hub zu ersparen.
Fazit
Ich hoffe, der Vorteil eines lokalen Paket-Mirrors ist offensichtlich, der Blogpost hat gezeigt, wie einfach ein lokaler Mirror mit Katello ist und warum ich froh bin, dass Icinga for Windows das unterstützt. Wahrscheinlich werde ich in Zukunft auch andere Projekte um Unterstützung von Katello bitten, wenn sie ein eigenes Repository wie Icinga for Windows zur Verfügung stellen. Tatsächlich habe ich bereits beim Foreman Projekt selbst angefragt, ob dies für das Discovery-Image eingerichtet werden kann. Wenn andere das auch machen, werden alle davon profitieren.
Dir als Leser habe ich hoffentlich etwas an die Hand gegeben, das dir nicht nur bei der Einrichtung von Icinga-Repositories in Katello hilft, sondern auch darüber hinaus. Wenn du dich bisher noch nicht mit dem Thema beschäftigt hast, aber jetzt Interesse hast, dann schau dir doch als Einstieg unsere Seite zu Foreman an und entdecke, was der Vorarbeiter noch alles für dich tun kann. Noch mehr Informationen bekommst du in unserer Schulung zu Foreman, die wir übrigens zusammen mit dem Foreman-Projekt als offizielle Schulung zum Tool entwickelt und veröffentlicht haben. Und wie immer bieten wir natürlich auch Beratung, Support und Outsourcing zu diesem Thema an.
Das Headerbild kombiniert den Deliveryman von oksmith von Openclipart mit den Logos der Projekte.
