Wir stellen die Infrastruktur für die Verteilung von Paketen und Updates von RH-basierten Distributionen im Unternehmensnetzwerk bereit

Jeder hat die Importsubstitution schon ziemlich satt, aber es ist noch weit von den geschätzten Indikatoren für heimische Betriebssysteme auf Desktops entfernt. Es ist an der Zeit, das Verteilungsschema für Updates / Add-Ons und andere Software zu besprechen.

Und nein, ich werde Sie nicht wie einen Onkel beim KDPV ansehen, und ein paar Minuten reichen hier eindeutig nicht aus. Wir werden uns langsam von der lokalen Maschine zur Erfassung des Universums des Unternehmensnetzwerks bewegen.


Wie üblich sind wir mit inländischen RedHat-basierten Distributionen beschäftigt – RedOS, Rosa. Debian-basierte Builds sind nicht meine Richtung, aber ich bin sicher, dass auch dort alles in Ordnung ist.

Für diejenigen, die sich bisher noch nicht mit Linux beschäftigt haben, erkläre ich es kurz: rpm (RedHat Package Manager) ist ein Programm zur Verwaltung von Installationspaketen in von RedHat Linux abgeleiteten Distributionen. Installationspakete haben die Erweiterung .rpm.

Mit dem Programm können Sie ein Paket installieren, entfernen, Inhalte/Metadaten anzeigen, installierte Pakete anzeigen usw. Das Paket selbst enthält neben ausführbaren Dateien, Bibliotheken, Konfigurationen, Dokumentation und anderen Daten eine ausreichende Anzahl von Skripten, die die Paketkonfiguration für ein bestimmtes System selbstständig anpassen und umgekehrt. Sie räumen auch nach sich selbst auf, wenn Software entfernt wird. Darüber hinaus gibt das RPM-Format an, welche Pakete (Abhängigkeiten) im System vorhanden sein müssen (erfordert) und welche Abhängigkeiten dieses Paket bereitstellt (bereitstellt). Um den Aufwand für die Suche nach Paketen zu beseitigen, die die Abhängigkeiten des zu installierenden Programms (sowie Abhängigkeiten-Abhängigkeiten) erfüllen, wurde ein wunderbares Tool yum (yellowdog updater, modifiziert) erstellt, das dies für uns erledigt und alles Fehlende installiert zusammen mit dem gewünschten Paket. Eigentlich ist dnf bereits eine Weiterentwicklung von yum (oder besser gesagt ein Fork), wobei die Kompatibilität zu yum auf Kommandoebene gewahrt bleibt.

▍ So aktualisieren Sie einen lokalen Computer

Theoretisch wird es bereits aktualisiert, weil. In der grafischen Shell werden Sie durch das dnfdragora- oder yumex-Symbol gestört. Persönlich denke ich, dass diese „Kameraden“ es nicht wert sind, auf Unternehmensdesktops zu leben – die Logik ihrer Arbeit ist nicht offensichtlich, die Benutzeroberflächen sind schrecklich, sie selbst frieren aus irgendeinem Grund und ohne Grund ein, erfordern übermäßige Rechte, verschlingen Ressourcen, und es gibt keine Möglichkeit, Benutzern ein OK für ein so wichtiges Ereignis zu geben. Unverantwortlich sie (Benutzer).

Wenn Ihre Distribution bereits mit der Umstellung auf dnf begonnen hat, müssen Sie das Paket dnf-automatic installieren und den erforderlichen Timer zu systemd hinzufügen:

# systemctl enable –now dnf-automatic-install.timer

In diesem Fall müssen Sie einen der möglichen Timer auswählen:

Was sie tun, versuchen Sie selbst zu erraten, oder Sie können in man dnf-automatic gucken

Für yum müssen Sie das Paket yum-cron installieren und so organisieren, dass es beim Booten ausgeführt wird

# systemctl aktiviert yum-cron.service # systemctl startet yum-cron.service

Alle Einstellungen in Dateien

/etc/yum/yum-cron.conf

und

/etc/yum.conf

.

Updates kommen jetzt regelmäßig und still.

Wenn Sie alles kontrollieren wollen

Wenn die automatische Aktualisierung nicht zu Ihnen passt, müssen Sie einen automatischen Download von Aktualisierungen einrichten, aber ihre Anwendung über das Konfigurationsverwaltungssystem (SCM) implementieren – ansible, chef, puppet usw. Dementsprechend gibt es bereits die Lösung des Problems mit Gruppen von “Testern” und dem Rest des Volumens von Benutzern.

▍ Aktualisieren der lokalen Maschine vom Server

Es scheint, dass alles, was Sie brauchen, oben geschrieben ist und Sie sich zerstreuen können. Aber warte 🙂

Da unser Unternehmensnetzwerk durch zehn Firewalls von der Außenwelt isoliert ist, funktionieren alle oben genannten Funktionen einfach nicht, wenn Sie einfach ein Betriebssystem von einer Festplatte / einem Flash-Laufwerk herunterladen. Auch die Pakete dnf-automatic oder yum-cron lassen sich nicht ohne zusätzliche Gesten installieren. Zunächst müssen wir unserer Maschine verbieten, das Internet nach Updates zu durchsuchen, und sie dann daran gewöhnen, interne Ressourcen zu verwenden.

Sowohl dnf als auch yum verwenden denselben Ort, um die Konfiguration der Repositories zu speichern – das Verzeichnis /etc/yum.repos.d. Wir gehen dorthin und bearbeiten alle Dateien der Reihe nach mit unserem bevorzugten Texteditor: nano, mcedit, vi, ed, sed. Unsere Aufgabe ist es, in jedem Abschnitt die Zeile enabled=1 durch enabled=0 zu ersetzen. Daher haben wir die im Internet befindlichen Standard-Repositorys deaktiviert.

Der nächste Schritt besteht darin, interne Repositories zu verbinden. Kopieren Sie hier eine vorgefertigte Konfigurationsdatei, die Sie vom Systemadministrator erhalten haben. Ich habe völlig vergessen, dass wir der Systemadministrator sind, was bedeutet, dass die Datei unabhängig von diesem Verzeichnis als Grundlage erstellt werden muss. Darin unterbrechen wir die baseurl auf die Adresse unseres Servers und setzen für die notwendigen Abschnitte enabled=1. Außerdem werden wir in der Anfangsphase gpgcheck deaktivieren – wenn wir Erfahrung / Wissen sammeln, werden wir entscheiden, was wir weiter damit machen.

So reduzieren Sie die Interaktivität

Mit der Konfiguration der Repositories kann man einfacher arbeiten, so dass man beispielsweise alle Manipulationen in Installationsskripte oder in Playbooks schieben kann (nur am Beispiel von dnf demonstriert).

Aktive Repositories im System anzeigen:

Alle im System konfigurierten Repositorys anzeigen:

Deaktivieren Sie alle Repositories (hier müssen Sie sich vor der Shell verstecken):

Aktivieren Sie selektiv einige Repositories:

Wenn das Verzeichnis /etc/yum.repos.d bereits Konfigurationen für seine Repositories enthält, werden sie auch hier angezeigt. Übrigens kann die Konfigurationsdatei über den dnf config-manager zum Client hinzugefügt werden – lesen Sie das Mana :).

▍ Installieren Sie den Server und erhalten Sie ein Update aus dem Internet

Es scheint, dass der Client eingerichtet wurde, aber es ist noch zu früh, um sich zu entspannen – erinnern Sie sich an die Basis-URL aus dem vorherigen Absatz? Er zeigt jetzt ins Nirgendwo. Also wechseln wir zur Serverkonsole (oder einfach zu einer dedizierten Maschine) und beginnen, unseren eigenen Update-Server aufzubauen. Falscher Begriff “Updates”, weil. Es ist im Wesentlichen ein Verteilungsserver, auf dem die gesamte Software gespeichert ist, und Updates sind nur neue Versionen von Paketen.

Das Distributions-Image (aus dem das Installationsmedium erstellt wurde) enthält normalerweise einen autarken und ziemlich großen Satz von Paketen, aber es gibt viel mehr davon auf dem Server des Herstellers. Und wenn wir zum Beispiel das Image von Centos Netinstall nehmen, dann gibt es praktisch überhaupt keine Pakete – alles wird aus dem Netzwerk gezogen.

Auf unserem Server fassen wir die Konfiguration der yum-Repositories nicht an – schließlich müssen wir wirklich Daten aus dem Internet ziehen.

Auch für unseren Server ist es notwendig, den Zugang zu den Servern des Herstellers über das https-Protokoll zu öffnen. Wir nehmen die notwendigen Adressen aus der Baseurl, die in den ursprünglichen Configs eingetragen sind.

Fast alles ist bereit, aber wenn Sie yum oder dnf mit dem Update-Parameter ausführen, wird unsere Maschine nicht zu einem Verteilungsserver, wir aktualisieren nur die installierten Pakete.

Um ein Repository zu “spiegeln”, gibt es ein Reposync-Dienstprogramm aus dem Paket yum-utils (oder dnf-utils). Wir starten es und beobachten den Vorgang des Herunterladens von Repositories in das aktuelle Verzeichnis. Als Nächstes richten wir den regelmäßigen Start dieses Befehls per cron oder über den systemd-Timer ein und erhöhen den lokalen HTTP-Server mit den erforderlichen Einstellungen, damit Clients die Repository-Metadaten und die darin enthaltenen Pakete herunterladen können.

Es gibt eine zweite Möglichkeit.

Auf unserer Maschine fixieren wir den Keepcache-Parameter in der Datei yum.conf und/oder dnf.conf. Dementsprechend wird alles, was wir auf unseren Computer legen, im Cache /var/cache/yum (/var/cache/dnf) abgelegt und diese Pakete können genommen und an alle Leidenden verteilt werden.

Sie können auch die Option –downloadonly verwenden, um die Phase der Paketinstallation zu überspringen und nur herunterzuladen.

Außerdem können Sie in diesem Fall eine zusätzliche Maschine außerhalb des Firmennetzwerks haben und von dort Pakete mit einem „Floppinet“ auf den internen Server ziehen.

Denken Sie selbst an die dritte und die folgenden Optionen – wget, curl, rsync usw. Das Spiegeln und Synchronisieren des Ordners vom http-Server ist kein Problem.

Wir haben die Pakete irgendwie heruntergeladen und an einem für Clients zugänglichen Ort abgelegt, aber das reicht nicht aus – wir müssen den Inhalt des Repositorys indizieren und die erforderlichen Metadaten vorbereiten.

Die Umwandlung eines Datei-Dumps mit Paketen in ein Repository erfolgt durch das Dienstprogramm createrepo aus dem Paket createrepo. Wir beginnen und geben in den Parametern den Namen des Verzeichnisses mit den Paketen an. Nach der Verarbeitung erscheint darin ein Repodata-Verzeichnis, das Metadaten enthält, die der Client in seinen Cache zieht, was es seinem Paketmanager ermöglicht, Abhängigkeiten sofort aufzulösen und die erforderlichen Pakete zu finden. Wenn einem bestehenden Repository etwas hinzugefügt wurde, können Sie den Indexierungsprozess mit der Option –update beschleunigen

▍ Repository aus Repository aktualisieren

Wir fahren fort. Das Schema mit einem Server im Firmennetzwerk ist nicht sehr gut. Auch unter Berücksichtigung der geringen Anforderungen an die Geschwindigkeit bzw. Geschwindigkeit von Updates wünsche ich mir eine gewisse Fehlertoleranz und weniger Belastung der Datenkanäle. Wie üblich wird dies gelöst, indem sekundäre und / oder kaskadierende Update-Server an entfernten Standorten installiert werden – näher an den Verbrauchern.

Beispiel-Update-Infrastruktur-Diagramm

Server-Setup – wie oben beschrieben, nur ziehen sie Pakete nicht direkt aus dem Internet, sondern von unserem zentralen Server. Und hier wird die Einrichtung von Clients spezifisch sein. Die Enterprise liebt und begrüßt die Vereinheitlichung, daher schlage ich vor, keine einzigartigen Repositories-Beschreibungsdateien für jede Site zu erstellen. Wie kann man dann dem Client mitteilen, dass er den Server kontaktieren soll, der diesen Standort bedient?

Welche der Optionen Sie implementieren möchten, entscheiden Sie ebenfalls selbst und basierend auf Ihren Fähigkeiten und Ihrer Netzwerktopologie.

▍ Eigene Repositories

Was tun mit den “verlassenen” Paketen, die nicht aus dem offiziellen Repository des Betriebssystemherstellers stammen, oder mit Paketen, die wir selbst erstellt haben?

Das ist richtig – Platz in Ihren eigenen Repositories. Auf dem Webserver nehmen wir die notwendigen Einstellungen / Verzeichnisse vor und legen dort die Pakete ab. Verwenden Sie als Nächstes das Dienstprogramm createrepo, um die erforderlichen Metadaten zu generieren. Für Kunden erstellen wir eine Datei mit einer Beschreibung des Repositorys. Alles sollte funktionieren.

Ich möchte noch eine Nuance erwähnen. All diese Manipulationen bei der Softwareinstallation, sofortige Bereitstellung von Informationen über verfügbare Pakete und ihre Abhängigkeiten, geringe Belastung der Kanäle – all dies wird durch Vorindizierung und Datencaching erreicht.

Wenn Sie also Ihr Paket nicht gerade dem Repository hinzugefügt sehen, müssen Sie dnf/yum mit der Option –refresh ausführen. Auf diese Weise zwingen Sie es, die neuesten Repository-Metadaten herunterzuladen und die erforderlichen Pakete zu erhalten.

▍ Finale

Wie Sie sehen können, nichts Kompliziertes. Nachdem wir unsere eigene Distributionsserver-Infrastruktur für RPM-basierte Distributionen bereitgestellt haben, können wir unsere Linux-Workstations bereits vollständig verwalten und unserem SCM (ansible, chef, puppet usw.) Aufgaben zum Aktualisieren, Installieren oder Entfernen von Software übertragen. Und das alles völlig unmerklich für den Benutzer.

Telegrammkanal und gemütlich plaudern für Kunden

Similar Posts

Leave a Reply

Your email address will not be published.