Wie man RPM-Pakete baut

Ich habe RPM-basierte Paketmanager verwendet, um Software auf Red Hat und Fedora Linux zu installieren, seit ich vor mehr als 20 Jahren angefangen habe, Linux zu verwenden. Ich habe die rpm verwendet selbst programmieren, lecker und DNF , das ein enger Nachkomme von yum ist, um Pakete auf meinen Linux-Hosts zu installieren und zu aktualisieren. Die Tools yum und DNF sind Wrapper um das Dienstprogramm rpm, die zusätzliche Funktionen bieten, wie z. B. die Möglichkeit, Paketabhängigkeiten zu finden und zu installieren.

Weitere Linux-Ressourcen

• Spickzettel für Linux-Befehle
• Spickzettel für fortgeschrittene Linux-Befehle
• Kostenloser Online-Kurs:RHEL Technical Overview
• Spickzettel für Linux-Netzwerke
• SELinux-Spickzettel
• Spickzettel für allgemeine Linux-Befehle
• Was sind Linux-Container?
• Unsere neuesten Linux-Artikel

Im Laufe der Jahre habe ich eine Reihe von Bash-Skripten erstellt, von denen einige separate Konfigurationsdateien haben, die ich gerne auf den meisten meiner neuen Computer und virtuellen Maschinen installiere. Es erreichte den Punkt, dass es sehr viel Zeit in Anspruch nahm, all diese Pakete zu installieren, also beschloss ich, diesen Prozess zu automatisieren, indem ich ein RPM-Paket erstellte, das ich auf die Zielhosts kopieren und alle diese Dateien an ihren richtigen Speicherorten installieren konnte. Obwohl die Drehzahl Tool wurde früher verwendet, um RPM-Pakete zu bauen, diese Funktion wurde entfernt und ein neues Tool, rpmbuild, wurde erstellt, um neue RPMs zu erstellen.

Als ich mit diesem Projekt begann, fand ich sehr wenig Informationen über das Erstellen von RPM-Paketen, aber ich fand ein Buch, Maximum RPM , das hat mir geholfen, es herauszufinden. Dieses Buch ist jetzt etwas veraltet, ebenso wie die überwiegende Mehrheit der Informationen, die ich gefunden habe. Es ist auch vergriffen und gebrauchte Exemplare kosten Hunderte von Dollar. Die Online-Version von Maximum RPM ist kostenlos verfügbar und wird auf dem neuesten Stand gehalten. Die RPM-Website enthält auch Links zu anderen Websites, die eine Menge Dokumentation über RPM enthalten. Welche anderen Informationen es gibt, ist eher kurz und setzt offensichtlich voraus, dass Sie bereits über ein gutes Maß an Wissen über den Prozess verfügen.

Darüber hinaus geht jedes der Dokumente, die ich gefunden habe, davon aus, dass der Code wie in einer Entwicklungsumgebung aus Quellen kompiliert werden muss. Ich bin kein Entwickler. Ich bin ein Systemadministrator, und wir Systemadministratoren haben unterschiedliche Anforderungen, weil wir keinen Code für administrative Aufgaben kompilieren – oder nicht sollten –; Wir sollten Shell-Skripte verwenden. Wir haben also keinen Quellcode in dem Sinne, dass er in ausführbare Binärdateien kompiliert werden muss. Was wir haben, ist eine Quelle, die auch die ausführbare Datei ist.

Größtenteils sollte dieses Projekt als Student ohne Rootberechtigung durchgeführt werden. Rpms sollten niemals von root gebaut werden, sondern nur von nicht-privilegierten Benutzern. Ich werde angeben, welche Teile als root ausgeführt werden sollten und welche von einem nicht-root, unprivilegierten Benutzer.

Vorbereitung

Öffnen Sie zuerst eine Terminalsitzung und su Wurzeln. Achten Sie darauf, den - zu verwenden Option, um sicherzustellen, dass die vollständige Root-Umgebung aktiviert ist. Ich glaube nicht, dass Systemadministratoren sudo verwenden sollten für alle administrativen Aufgaben. Warum, erfahren Sie in meinem persönlichen Blogbeitrag:Real SysAdmins don’t sudo .

[student@testvm1 ~]$ su -

Password: 

[root@testvm1 ~]#

Erstellen Sie einen Studentenbenutzer, der für dieses Projekt verwendet werden kann, und legen Sie ein Passwort für diesen Benutzer fest.

[root@testvm1 ~]# useradd -c "Student User" student 

[root@testvm1 ~]# passwd student

Changing password for user student.

New password: <Enter the password>

Retype new password: <Enter the password>

passwd: all authentication tokens updated successfully.

[root@testvm1 ~]#

Das Erstellen von RPM-Paketen erfordert den rpm-build Paket, das wahrscheinlich noch nicht installiert ist. Jetzt als root installieren. Beachten Sie, dass dieser Befehl auch mehrere Abhängigkeiten installiert. Die Anzahl kann je nach bereits auf Ihrem Host installierten Paketen variieren; es installierte insgesamt 17 Pakete auf meiner Test-VM, was ziemlich wenig ist.

dnf install -y rpm-build

Der Rest dieses Projekts sollte als Benutzer student ausgeführt werden, sofern nicht ausdrücklich anders angegeben. Öffnen Sie eine weitere Terminalsitzung und verwenden Sie su um zu diesem Benutzer zu wechseln, um die restlichen Schritte auszuführen. Laden Sie einen von mir vorbereiteten Tarball einer Entwicklungsverzeichnisstruktur, utils.tar, von GitHub mit dem folgenden Befehl herunter:

wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar

Dieser Tarball enthält alle Dateien und Bash-Skripte, die von der letzten RPM installiert werden. Es gibt auch eine vollständige Spezifikationsdatei, die Sie zum Erstellen der RPM verwenden können. Wir werden detailliert auf jeden Abschnitt der Spezifikationsdatei eingehen.

Entpacken Sie als Benutzer Student den Tarball, indem Sie Ihr Home-Verzeichnis als Ihr aktuelles Arbeitsverzeichnis (pwd) verwenden.

[student@testvm1 ~]$ cd ; tar -xvf utils.tar 

Verwenden Sie den tree Befehl, um zu überprüfen, ob die Verzeichnisstruktur von ~/development und die enthaltenen Dateien wie die folgende Ausgabe aussehen:

[student@testvm1 ~]$ tree development/

development/

├── license

│   ├── Copyright.and.GPL.Notice.txt

│   └── GPL_LICENSE.txt

├── scripts

│   ├── create_motd

│   ├── die

│   ├── mymotd

│   └── sysdata

└── spec

    └── utils.spec



3 directories, 7 files

[student@testvm1 ~]$

Der mymotd Das Skript erstellt einen „Message Of The Day“-Datenstrom, der an stdout gesendet wird. Die create_motd Skript führt mymotd aus Skripte und leitet die Ausgabe in die Datei /etc/motd um. Diese Datei wird verwendet, um Benutzern, die sich remote mit SSH anmelden, eine tägliche Nachricht anzuzeigen.

Die die script ist mein eigenes Skript, das kill umschließt Befehl in einem Codeabschnitt, der laufende Programme finden kann, die mit einer bestimmten Zeichenfolge übereinstimmen, und sie beenden kann. Es verwendet kill -9 um sicherzustellen, dass sie die Kill-Nachricht nicht ignorieren können.

Die sysdata script kann Zehntausende von Datenzeilen über Ihre Computerhardware, die installierte Version von Linux, alle installierten Pakete und die Metadaten Ihrer Festplatten ausspucken. Ich verwende es, um den Zustand eines Hosts zu einem bestimmten Zeitpunkt zu dokumentieren. Ich kann es später als Referenz verwenden. Früher habe ich dies getan, um eine Aufzeichnung der Hosts zu führen, die ich für Kunden installiert habe.

Möglicherweise müssen Sie den Besitz dieser Dateien und Verzeichnisse auf student.student ändern. Tun Sie dies ggf. mit folgendem Befehl:

chown -R student.student development

Die meisten Dateien und Verzeichnisse in diesem Baum werden auf Fedora-Systemen durch die RPM installiert, die Sie während dieses Projekts erstellen.

Erstellen der Build-Verzeichnisstruktur

Der rpmbuild Befehl erfordert eine sehr spezifische Verzeichnisstruktur. Sie müssen diese Verzeichnisstruktur selbst erstellen, da kein automatisierter Weg bereitgestellt wird. Erstellen Sie die folgende Verzeichnisstruktur in Ihrem Home-Verzeichnis:

~ ─ rpmbuild

    ├── RPMS

    │   └── noarch

    ├── SOURCES

    ├── SPECS

    └── SRPMS

Wir werden das Verzeichnis rpmbuild/RPMS/X86_64 nicht erstellen, da dies architekturspezifisch für kompilierte 64-Bit-Binärdateien wäre. Wir haben Shell-Skripte, die nicht architekturspezifisch sind. In Wirklichkeit werden wir auch nicht das SRPMS-Verzeichnis verwenden, das Quelldateien für den Compiler enthalten würde.

Untersuchen der Spezifikationsdatei

Jede Spezifikationsdatei hat eine Reihe von Abschnitten, von denen einige ignoriert oder weggelassen werden können, abhängig von den spezifischen Umständen des RPM-Builds. Diese spezielle Spezifikationsdatei ist kein Beispiel für eine minimale Datei, die zum Arbeiten erforderlich ist, aber sie ist ein gutes Beispiel für eine mäßig komplexe Spezifikationsdatei, die Dateien verpackt, die nicht kompiliert werden müssen. Wenn eine Kompilierung erforderlich wäre, würde sie im %build durchgeführt werden Abschnitt, der in dieser Spezifikationsdatei weggelassen wird, da er nicht erforderlich ist.

Präambel

Dies ist der einzige Abschnitt der Spezifikationsdatei, der kein Label hat. Es besteht aus vielen der Informationen, die Sie beim Befehl rpm -qi [Package Name] sehen es läuft. Jedes Datum ist eine einzelne Zeile, die aus einem Tag besteht, das es identifiziert, und Textdaten für den Wert des Tags.

###############################################################################

# Spec file for utils

################################################################################

# Configured to be built by user student or other non-root user

################################################################################

#

Summary: Utility scripts for testing RPM creation

Name: utils

Version: 1.0.0

Release: 1

License: GPL

URL: http://www.both.org

Group: System

Packager: David Both

Requires: bash

Requires: screen

Requires: mc

Requires: dmidecode

BuildRoot: ~/rpmbuild/



# Build with the following syntax:

# rpmbuild --target noarch -bb utils.spec

Kommentarzeilen werden vom rpmbuild ignoriert Programm. Ich möchte diesem Abschnitt immer einen Kommentar hinzufügen, der die genaue Syntax des rpmbuild enthält Befehl, der zum Erstellen des Pakets erforderlich ist. Das Summary-Tag ist eine kurze Beschreibung des Pakets. Die Tags Name, Version und Release werden verwendet, um den Namen der RPM-Datei zu erstellen, wie in utils-1.00-1.rpm. Durch Erhöhen der Release- und Versionsnummern können Sie RPMs erstellen, mit denen ältere aktualisiert werden können.

Das Lizenz-Tag definiert die Lizenz, unter der das Paket veröffentlicht wird. Ich verwende immer eine Variante der GPL. Die Angabe der Lizenz ist wichtig, um zu verdeutlichen, dass es sich bei der im Paket enthaltenen Software um Open Source handelt. Aus diesem Grund habe ich auch die Lizenz- und GPL-Erklärung in die zu installierenden Dateien eingefügt.

Die URL ist normalerweise die Webseite des Projekts oder Projektinhabers. In diesem Fall ist es meine persönliche Webseite.

Das Group-Tag ist interessant und wird normalerweise für GUI-Anwendungen verwendet. Der Wert des Group-Tags bestimmt, welche Symbolgruppe im Anwendungsmenü das Symbol für die ausführbare Datei in diesem Paket enthält. In Verbindung mit dem Symbol-Tag (das wir hier nicht verwenden) verwendet, ermöglicht das Gruppen-Tag das Hinzufügen des Symbols und der erforderlichen Informationen zum Starten eines Programms in die Anwendungsmenüstruktur.

Das Packager-Tag wird verwendet, um die Person oder Organisation anzugeben, die für die Wartung und Erstellung des Pakets verantwortlich ist.

Die Requires-Anweisungen definieren die Abhängigkeiten für diese RPM. Jeder ist ein Paketname. Wenn eines der angegebenen Pakete nicht vorhanden ist, versucht das DNF-Installationsdienstprogramm, es in einem der in /etc/yum.repos.d definierten Repositories zu finden und es zu installieren, falls es vorhanden ist. Wenn DNF eines oder mehrere der erforderlichen Pakete nicht finden kann, gibt es einen Fehler aus, der angibt, welche Pakete fehlen, und wird beendet.

Die BuildRoot-Zeile gibt das oberste Verzeichnis an, in dem die Datei rpmbuild Das Tool findet die Spezifikationsdatei und erstellt darin temporäre Verzeichnisse, während es das Paket erstellt. Das fertige Paket wird im zuvor angegebenen noarch-Unterverzeichnis gespeichert. Der Kommentar, der die zum Erstellen dieses Pakets verwendete Befehlssyntax zeigt, enthält die Option –target noarch , die die Zielarchitektur definiert. Da es sich um Bash-Skripte handelt, sind sie keiner bestimmten CPU-Architektur zugeordnet. Wenn diese Option weggelassen würde, würde der Build auf die Architektur der CPU ausgerichtet, auf der der Build ausgeführt wird.

Der rpmbuild Das Programm kann auf viele verschiedene Architekturen abzielen, und die Verwendung von --target Die Option ermöglicht es uns, architekturspezifische Pakete auf einem Host mit einer anderen Architektur als der zu erstellen, auf der der Build ausgeführt wird. So könnte ich ein Paket erstellen, das für die Verwendung auf einer i686-Architektur auf einem x86_64-Host und umgekehrt gedacht ist.

Ändern Sie den Packager-Namen in Ihren und die URL zu Ihrer eigenen Website, falls Sie eine haben.

%Beschreibung

Die %description Abschnitt der Spezifikationsdatei enthält eine Beschreibung des RPM-Pakets. Sie kann sehr kurz sein oder viele Informationszeilen enthalten. Unsere %description Abschnitt ist eher knapp.

%description

A collection of utility scripts for testing RPM creation.

%prep

Der %prep Abschnitt ist das erste Skript, das während des Erstellungsprozesses ausgeführt wird. Dieses Skript wird während der Installation des Pakets nicht ausgeführt.

Dieses Skript ist nur ein Bash-Shell-Skript. Es bereitet das Build-Verzeichnis vor, erstellt nach Bedarf Verzeichnisse, die für den Build verwendet werden, und kopiert die entsprechenden Dateien in die entsprechenden Verzeichnisse. Dies würde die Quellen enthalten, die für eine vollständige Kompilierung als Teil des Builds erforderlich sind.

Das Verzeichnis $RPM_BUILD_ROOT repräsentiert das Root-Verzeichnis eines installierten Systems. Die im $RPM_BUILD_ROOT-Verzeichnis erstellten Verzeichnisse sind vollständig qualifizierte Pfade wie /user/local/share/utils, /usr/local/bin usw. in einem Live-Dateisystem.

Im Fall unseres Pakets haben wir keine vorkompilierten Quellen, da alle unsere Programme Bash-Skripte sind. Also kopieren wir diese Skripte und andere Dateien einfach in die Verzeichnisse, wo sie im installierten System hingehören.

%prep

################################################################################

# Create the build tree and copy the files from the development directories    #

# into the build tree.                                                         #

################################################################################

echo "BUILDROOT = $RPM_BUILD_ROOT"

mkdir -p $RPM_BUILD_ROOT/usr/local/bin/

mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils



cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin

cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils

cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils



exit

Beachten Sie, dass die Exit-Anweisung am Ende dieses Abschnitts erforderlich ist.

%Dateien

Dieser Abschnitt der Spezifikationsdatei definiert die zu installierenden Dateien und ihre Speicherorte im Verzeichnisbaum. Es gibt auch die Dateiattribute und den Eigentümer und Gruppeneigentümer für jede zu installierende Datei an. Die Dateiberechtigungen und Eigentumsrechte sind optional, aber ich empfehle, dass sie explizit festgelegt werden, um jede Möglichkeit auszuschließen, dass diese Attribute bei der Installation falsch oder mehrdeutig sind. Verzeichnisse werden bei Bedarf während der Installation angelegt, falls sie noch nicht vorhanden sind.

%files

%attr(0744, root, root) /usr/local/bin/*

%attr(0644, root, root) /usr/local/share/utils/*

%pre

Dieser Abschnitt ist in der Spezifikationsdatei unseres Laborprojekts leer. Dies wäre der Ort, um alle Skripte abzulegen, die während der Installation des RPM, aber vor der Installation der Dateien ausgeführt werden müssen.

%beitrag

Dieser Abschnitt der Spezifikationsdatei ist ein weiteres Bash-Skript. Dieser läuft nach der Installation von Dateien. Dieser Abschnitt kann so ziemlich alles sein, was Sie brauchen oder wollen, einschließlich das Erstellen von Dateien, das Ausführen von Systembefehlen und das Neustarten von Diensten, um sie nach Konfigurationsänderungen neu zu initialisieren. Der %post -Skript für unser RPM-Paket führt einige dieser Aufgaben aus.

%post

################################################################################

# Set up MOTD scripts                                                          #

################################################################################

cd /etc

# Save the old MOTD if it exists

if [ -e motd ]

then

   cp motd motd.orig

fi

# If not there already, Add link to create_motd to cron.daily

cd /etc/cron.daily

if [ ! -e create_motd ]

then

   ln -s /usr/local/bin/create_motd

fi

# create the MOTD for the first time

/usr/local/bin/mymotd > /etc/motd

Die in diesem Skript enthaltenen Kommentare sollten seinen Zweck deutlich machen.

%postun

Dieser Abschnitt enthält ein Skript, das ausgeführt wird, nachdem das RPM-Paket deinstalliert wurde. Die Verwendung von rpm oder DNF zum Entfernen eines Pakets entfernt alle Dateien, die in %files aufgeführt sind Abschnitt, aber es entfernt keine Dateien oder Links, die von %post erstellt wurden Abschnitt, also müssen wir das in diesem Abschnitt behandeln.

Dieses Skript besteht normalerweise aus Bereinigungsaufgaben, die durch einfaches Löschen der zuvor von RPM installierten Dateien nicht ausgeführt werden können. Im Fall unseres Pakets beinhaltet es das Entfernen des Links, der durch den %post erstellt wurde Skript und Wiederherstellen des gespeicherten Originals der motd-Datei.

%postun

# remove installed files and links

rm /etc/cron.daily/create_motd



# Restore the original MOTD if it was backed up

if [ -e /etc/motd.orig ]

then

   mv -f /etc/motd.orig /etc/motd

fi

%sauber

Dieses Bash-Skript führt nach dem RPM-Build-Prozess eine Bereinigung durch. Die beiden Zeilen in %clean Abschnitt unten die Build-Verzeichnisse entfernen, die von rpm-build erstellt wurden Befehl. In vielen Fällen kann auch eine zusätzliche Bereinigung erforderlich sein.

%clean

rm -rf $RPM_BUILD_ROOT/usr/local/bin

rm -rf $RPM_BUILD_ROOT/usr/local/share/utils

%Änderungsprotokoll

Dieser optionale Textabschnitt enthält eine Liste der Änderungen am RPM und den darin enthaltenen Dateien. Die neuesten Änderungen werden oben in diesem Abschnitt aufgezeichnet.

%changelog

* Wed Aug 29 2018 Your Name <[email protected]>

  - The original package includes several useful scripts. it is

    primarily intended to be used to illustrate the process of

    building an RPM.

Ersetzen Sie die Daten in der Kopfzeile durch Ihren eigenen Namen und Ihre E-Mail-Adresse.

Erstellen der Drehzahl

Die Spezifikationsdatei muss sich im SPECS-Verzeichnis des RPMBuild-Baums befinden. Ich finde es am einfachsten, einen Link zur eigentlichen Spezifikationsdatei in diesem Verzeichnis zu erstellen, sodass sie im Entwicklungsverzeichnis bearbeitet werden kann und nicht in das SPECS-Verzeichnis kopiert werden muss. Machen Sie das SPECS-Verzeichnis zu Ihrem pwd und erstellen Sie dann den Link.

cd ~/rpmbuild/SPECS/

ln -s ~/development/spec/utils.spec

Führen Sie den folgenden Befehl aus, um die RPM zu erstellen. Es sollte nur einen Moment dauern, die RPM zu erstellen, wenn keine Fehler auftreten.

rpmbuild --target noarch -bb utils.spec

Überprüfen Sie im Verzeichnis ~/rpmbuild/RPMS/noarch, ob das neue RPM dort existiert.

[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/

[student@testvm1 noarch]$ ll

total 24

-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm

[student@testvm1 noarch]$

Testen der Drehzahl

Installieren Sie als Root das RPM, um zu überprüfen, ob es korrekt installiert wird und ob die Dateien in den richtigen Verzeichnissen installiert sind. Der genaue Name des RPM hängt von den Werten ab, die Sie für die Tags im Präambelabschnitt verwendet haben, aber wenn Sie die im Beispiel verwendeten, lautet der RPM-Name wie im folgenden Beispielbefehl gezeigt:

[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/

[root@testvm1 noarch]# ll

total 24

-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm

[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm

Preparing...                          ################################# [100%]

Updating / installing...

   1:utils-1.0.0-1                    ################################# [100%]

Überprüfen Sie /usr/local/bin, um sicherzustellen, dass die neuen Dateien vorhanden sind. Sie sollten auch überprüfen, ob der Link create_motd in /etc/cron.daily erstellt wurde.

Verwenden Sie die rpm -q --changelog utils Befehl, um das Änderungsprotokoll anzuzeigen. Zeigen Sie die vom Paket installierten Dateien mit den rpm -ql utils an Befehl (das ist ein kleines L in ql .)

[root@testvm1 noarch]# rpm -q --changelog utils

* Wed Aug 29 2018 Your Name <[email protected]>

- The original package includes several useful scripts. it is

    primarily intended to be used to illustrate the process of

    building an RPM.



[root@testvm1 noarch]# rpm -ql utils

/usr/local/bin/create_motd

/usr/local/bin/die

/usr/local/bin/mymotd

/usr/local/bin/sysdata

/usr/local/share/utils/Copyright.and.GPL.Notice.txt

/usr/local/share/utils/GPL_LICENSE.txt

/usr/local/share/utils/utils.spec

[root@testvm1 noarch]#

Entfernen Sie das Paket.

rpm -e utils

Experimentieren

Jetzt ändern Sie die Spezifikationsdatei so, dass ein nicht vorhandenes Paket erforderlich ist. Dadurch wird eine Abhängigkeit simuliert, die nicht erfüllt werden kann. Fügen Sie die folgende Zeile direkt unter der vorhandenen Requires-Zeile hinzu:

Requires: badrequire

Erstellen Sie das Paket und versuchen Sie, es zu installieren. Welche Meldung wird angezeigt?

Wir haben die rpm verwendet Befehl zum Installieren und Löschen der utils Paket. Versuchen Sie, das Paket mit yum oder DNF zu installieren. Sie müssen sich im selben Verzeichnis wie das Paket befinden oder den vollständigen Pfad zum Paket angeben, damit dies funktioniert.

Schlussfolgerung

Es gibt viele Tags und ein paar Abschnitte, die wir in diesem Blick auf die Grundlagen der Erstellung eines RPM-Pakets nicht behandelt haben. Die unten aufgeführten Ressourcen können weitere Informationen bereitstellen. Das Erstellen von RPM-Paketen ist nicht schwierig; Sie brauchen nur die richtigen Informationen. Ich hoffe, das hilft Ihnen – ich habe Monate gebraucht, um die Dinge selbst herauszufinden.

Wir haben das Erstellen aus dem Quellcode nicht behandelt, aber wenn Sie ein Entwickler sind, sollte dies ein einfacher Schritt von diesem Punkt an sein.

Das Erstellen von RPM-Paketen ist eine weitere gute Möglichkeit, ein fauler Systemadministrator zu sein und Zeit und Mühe zu sparen. Es bietet eine einfache Methode zum Verteilen und Installieren der Skripte und anderer Dateien, die wir als Systemadministratoren auf vielen Hosts installieren müssen.

Ressourcen

• Edward C. Baily, Maximale Drehzahl , Sams Publishing, 2000, ISBN 0-672-31105-4

• Edward C. Baily, Maximale Drehzahl , aktualisierte Online-Version

• RPM-Dokumentation :Diese Webseite listet den größten Teil der verfügbaren Online-Dokumentation für rpm auf. Es enthält viele Links zu anderen Websites und Informationen über rpm.