Systemweite Vereinheitlichung benutzerdefinierter Skripte mit RPM unter Red Hat/CentOS

Ziel

Unser Ziel ist es, RPM-Pakete mit benutzerdefinierten Inhalten zu erstellen und Skripte über eine beliebige Anzahl von Systemen hinweg zu vereinheitlichen, einschließlich Versionierung, Bereitstellung und Aufhebung der Bereitstellung.

Betriebssystem- und Softwareversionen

• Betriebssystem: Red Hat Enterprise Linux 7.5
• Software: rpm-build 4.11.3+

Anforderungen

Privilegierter Zugriff auf das System für die Installation, normaler Zugriff für den Build.

Schwierigkeit

MITTEL

Konventionen

• # – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder durch Verwendung von sudo Befehl
• $ – gegebene Linux-Befehle, die als normaler nicht-privilegierter Benutzer ausgeführt werden sollen

Einführung

Eines der Kernmerkmale eines jeden Linux-Systems ist, dass es für die Automatisierung entwickelt wurde. Wenn eine Aufgabe möglicherweise mehr als einmal ausgeführt werden muss – selbst wenn sich ein Teil davon bei der nächsten Ausführung ändert – stehen einem Systemadministrator unzählige Tools zur Verfügung, um dies zu automatisieren, von einer einfachen shell Skripte, die bei Bedarf von Hand ausgeführt werden (wodurch Tippfehler eliminiert oder nur einige Tastatureingaben eingespart werden), bis hin zu komplexen Skriptsystemen, in denen Aufgaben von cron ausgeführt werden zu einem bestimmten Zeitpunkt miteinander interagieren, mit dem Ergebnis eines anderen Skripts arbeiten, möglicherweise von einem zentralen Verwaltungssystem gesteuert usw.

Während diese Freiheit und das reichhaltige Toolset tatsächlich zur Produktivität beitragen, gibt es einen Haken:Als Systemadministrator schreiben Sie ein nützliches Skript auf einem System, das sich auf einem anderen als nützlich erweist, also kopieren Sie das Skript hinüber. Auf einem dritten System ist das Skript auch nützlich, aber mit geringfügigen Änderungen – vielleicht eine neue Funktion, die nur in diesem System nützlich ist und mit einem neuen Parameter erreichbar ist. In Anbetracht der Verallgemeinerung erweitern Sie das Skript, um die neue Funktion bereitzustellen, und führen auch die Aufgabe aus, für die es geschrieben wurde. Jetzt haben Sie zwei Versionen des Skripts, die erste befindet sich auf den ersten beiden Systemen, die zweite auf dem dritten System.

Sie haben 1024 Computer, die im Rechenzentrum ausgeführt werden, und 256 von ihnen benötigen einige der von diesem Skript bereitgestellten Funktionen. Mit der Zeit werden Sie überall 64 Versionen des Skripts haben, wobei jede Version ihre Aufgabe erfüllt. Bei der nächsten Systembereitstellung benötigen Sie eine Funktion, von der Sie sich erinnern, dass Sie sie in irgendeiner Version programmiert haben, aber welche? Und auf welchen Systemen sind sie?

Auf RPM-basierten Systemen wie Red Hat Flavors kann ein Systemadministrator den Paketmanager nutzen, um Ordnung in den benutzerdefinierten Inhalten zu schaffen, einschließlich einfacher Shell-Skripte, die möglicherweise nur die Tools bereitstellen, die der Administrator der Einfachheit halber geschrieben hat.

In diesem Tutorial erstellen wir ein benutzerdefiniertes RPM für Red Hat Enterprise Linux 7.5, das zwei bash enthält Skripte, parselogs.sh und pullnews.sh um eine Möglichkeit bereitzustellen, dass alle Systeme die neueste Version dieser Skripte in /usr/local/sbin haben Verzeichnis und damit auf dem Pfad jedes Benutzers, der sich am System anmeldet.

Distributionen, Haupt- und Nebenversionen

Im Allgemeinen sollten die Neben- und Hauptversion der Build-Maschine mit den Systemen übereinstimmen, auf denen das Paket bereitgestellt werden soll, sowie mit der Distribution, um die Kompatibilität sicherzustellen. Wenn es verschiedene Versionen einer bestimmten Distribution oder sogar verschiedene Distributionen mit vielen Versionen in Ihrer Umgebung gibt (oh, Freude!), sollten Sie für jede Build-Maschinen einrichten. Um die Arbeit zu verkürzen, können Sie einfach eine Build-Umgebung für jede Distribution und jede Hauptversion einrichten und sie auf der niedrigsten Nebenversion haben, die in Ihrer Umgebung für die jeweilige Hauptversion vorhanden ist. Natürlich müssen sie keine physischen Maschinen sein und müssen nur zur Erstellungszeit ausgeführt werden, sodass Sie virtuelle Maschinen oder Container verwenden können.

In diesem Tutorial ist unsere Arbeit viel einfacher, wir stellen nur zwei Skripte bereit, die überhaupt keine Abhängigkeiten haben (außer bash ), also bauen wir noarch Pakete, die für „nicht architekturabhängig“ stehen, geben wir auch nicht an, für welche Distribution das Paket gebaut wurde. Auf diese Weise können wir sie auf jeder Distribution installieren und aktualisieren, die rpm verwendet , und für jede Version – wir müssen nur sicherstellen, dass die rpm-build Paket ist die älteste Version in der Umgebung.

Gebäudeumgebung einrichten

Um benutzerdefinierte RPM-Pakete zu erstellen, müssen wir rpm-build installieren Paket:

# yum install rpm-build

Ab sofort verwenden wir keine root Benutzer, und das aus gutem Grund. Das Erstellen von Paketen erfordert kein root Privileg, und Sie möchten Ihre Baumaschine nicht kaputt machen.

Erstellen der ersten Version des Pakets

Lassen Sie uns die Verzeichnisstruktur erstellen, die zum Erstellen benötigt wird:

$ mkdir -p rpmbuild/SPECS

Unser Paket heißt admin-scripts, Version 1.0. Wir erstellen ein specfile die die Metadaten, Inhalte und Aufgaben angibt, die vom Paket ausgeführt werden. Dies ist eine einfache Textdatei, die wir mit unserem bevorzugten Texteditor wie vi erstellen können . Das zuvor installierte rpmbuild Paket wird Ihre leere Spezifikationsdatei mit Vorlagendaten füllen, wenn Sie vi verwenden um ein leeres zu erstellen, aber betrachten Sie für dieses Tutorial die Spezifikation unten namens admin-scripts-1.0.spec :

Name:           admin-scripts
Version:        1
Release:        0
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Platzieren Sie die Spezifikationsdatei im rpmbuild/SPEC Verzeichnis, das wir zuvor erstellt haben.

Wir brauchen die Quellen, auf die in der specfile verwiesen wird – in diesem Fall die beiden Shell-Skripte. Lassen Sie uns das Verzeichnis für die Quellen erstellen (als Paketname bezeichnet, an den die Hauptversion angehängt wird):

$ mkdir -p rpmbuild/SOURCES/admin-scripts-1/scripts

Und kopieren/verschieben Sie die Skripte hinein:

$ ls rpmbuild/SOURCES/admin-scripts-1/scripts/
parselogs.sh  pullnews.sh

Da es in diesem Tutorial nicht um Shell-Scripting geht, ist der Inhalt dieser Scripts irrelevant. Da werden wir eine neue Version des Pakets erstellen und die pullnews.sh ist das Skript, mit dem wir demonstrieren werden, seine Quelle in der ersten Version ist wie folgt:

#!/bin/bash
echo "news pulled"
exit 0

Vergessen Sie nicht, den Dateien in der Quelle die entsprechenden Rechte hinzuzufügen – in unserem Fall das Ausführungsrecht:

chmod +x rpmbuild/SOURCES/admin-scripts-1/scripts/*.sh




Jetzt erstellen wir eine tar.gz Archiv aus der Quelle in dasselbe Verzeichnis:

cd rpmbuild/SOURCES/ && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Wir sind bereit, das Paket zu bauen:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.0.spec

Wir erhalten eine Ausgabe über den Build, und wenn etwas schief geht, werden Fehler angezeigt (z. B. fehlende Datei oder fehlender Pfad). Wenn alles gut geht, erscheint unser neues Paket im RPMS-Verzeichnis, das standardmäßig unter rpmbuild generiert wird Verzeichnis (nach Architektur in Unterverzeichnisse sortiert):

$ ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm

Wir haben ein einfaches, aber voll funktionsfähiges RPM-Paket erstellt. Wir können es nach allen Metadaten abfragen, die wir zuvor bereitgestellt haben:

$ rpm -qpi rpmbuild/RPMS/noarch/admin-scripts-1-0.noarch.rpm 
Name        : admin-scripts
Version     : 1
Release     : 0
Architecture: noarch
Install Date: (not installed)
Group       : Application/Other
Size        : 78
License     : GPL
Signature   : (none)
Source RPM  : admin-scripts-1-0.src.rpm
Build Date  : 2018. aug.  1., Wed, 13.27.34 CEST
Build Host  : build01.foobar.com
Relocations : (not relocatable)
Packager    : John Doe 
URL         : www.foobar.com/admin-scripts
Summary     : FooBar Inc. IT dept. admin scripts
Description :
Package installing latest version the admin scripts used by the IT dept.




Und natürlich können wir es installieren (mit root Privilegien):

Installieren von benutzerdefinierten Skripten mit RPM

Da wir die Skripte in einem Verzeichnis installiert haben, das sich im $PATH jedes Benutzers befindet , können Sie sie als jeder Benutzer im System von jedem Verzeichnis aus ausführen:

$ pullnews.sh 
news pulled




Das Paket kann so verteilt werden, wie es ist, und kann in Repositories gepusht werden, die für eine beliebige Anzahl von Systemen verfügbar sind. Dies würde den Rahmen dieses Tutorials sprengen – das Erstellen einer anderen Version des Pakets jedoch sicherlich nicht.

Erstellen einer weiteren Version des Pakets

Unser Paket und die äußerst nützlichen Skripte darin werden in kürzester Zeit populär, wenn man bedenkt, dass sie überall mit einem einfachen yum install admin-scripts erreichbar sind innerhalb der Umwelt. Es wird bald viele Anfragen für einige Verbesserungen geben – in diesem Beispiel kommen viele Stimmen von zufriedenen Benutzern, die pullnews.sh Sollte bei der Ausführung eine weitere Zeile gedruckt werden, würde diese Funktion das gesamte Unternehmen retten. Wir müssen eine andere Version des Pakets erstellen, da wir kein weiteres Skript installieren möchten, sondern eine neue Version davon mit demselben Namen und Pfad, da sich die Systemadministratoren in unserer Organisation bereits stark darauf verlassen.

Zuerst ändern wir die Quelle der pullnews.sh in den QUELLEN zu etwas noch Komplexerem:

#!/bin/bash
echo "news pulled"
echo "another line printed"
exit 0

Wir müssen die tar.gz mit dem neuen Quellinhalt neu erstellen – wir können den gleichen Dateinamen wie beim ersten Mal verwenden, da wir die Version nicht ändern, sondern nur veröffentlichen (und so die Source0 Referenz bleibt gültig). Beachten Sie, dass wir zuerst das vorherige Archiv löschen:

cd rpmbuild/SOURCES/ && rm -f admin-scripts-1.tar.gz && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Jetzt erstellen wir ein weiteres Specfile mit einer höheren Release-Nummer:

cp rpmbuild/SPECS/admin-scripts-1.0.spec rpmbuild/SPECS/admin-scripts-1.1.spec

Wir ändern nicht viel am Paket selbst, also verwalten wir einfach die neue Version wie unten gezeigt:

Name:           admin-scripts
Version:        1
Release:        1
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Wenn Sie fertig sind, können wir eine weitere Version unseres Pakets erstellen, die das aktualisierte Skript enthält. Beachten Sie, dass wir auf die Spezifikationsdatei mit der höheren Version als Quelle des Builds verweisen:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.1.spec

Wenn der Build erfolgreich ist, haben wir jetzt zwei Versionen des Pakets in unserem RPMS-Verzeichnis:

ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm  admin-scripts-1-1.noarch.rpm

Und jetzt können wir das „erweiterte“ Skript installieren oder aktualisieren, wenn es bereits installiert ist.

Upgrade benutzerdefinierter Skripte mit rpm

Und unsere Systemadministratoren können sehen, dass die Feature-Anfrage in dieser Version gelandet ist:

rpm -q --changelog admin-scripts
* Wed aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line

* Wed aug 01 2018 John Doe 
- release 1.0 - initial release

Schlussfolgerung

Wir haben unsere benutzerdefinierten Inhalte in versionierte RPM-Pakete verpackt. Das bedeutet, dass keine älteren Versionen über Systeme verstreut bleiben, alles ist an seinem Platz, auf der Version, die wir installiert oder auf die wir aktualisiert haben. RPM bietet die Möglichkeit, altes Zeug zu ersetzen, das nur in früheren Versionen benötigt wurde, kann benutzerdefinierte Abhängigkeiten hinzufügen oder einige Tools oder Dienste bereitstellen, auf die sich unsere anderen Pakete verlassen. Mit Mühe können wir fast jeden unserer benutzerdefinierten Inhalte in RPM-Pakete packen und ihn nicht nur einfach, sondern konsistent in unserer Umgebung verteilen.