Paket-Management

Die meisten Administratoren verwenden zur Installation von Softwarepaketen die Werkzeuge ihrer Distribution. Daher prüft das LPI die entsprechenden Kenntnisse (siehe Kasten "LPI-Aufgabengruppen"). Den Abschnitten Festplattenpartitionierung und Installation eines Bootmanagers, die auch zur Aufgabengruppe 1.102 gehören, widmet sich ein späterer Artikel über Dateisysteme.

Paketverwaltung

Das LPI erwartet für eine erfolgreiche Prüfung von den Teilnehmern, dass sie sowohl mit der Paketverwaltung RPM (Red Hat, Fedora, Suse) als auch mit DPKG und »apt-get« (Debian, Ubuntu, Kubuntu) umgehen und sie einsetzen können.

Mit der jeweiligen Paketverwaltung seiner Distribution kann der Admin die installierten Pakete und deren Installationsdatum feststellen und die installierten Dateien aufrufen. Speziell beim Upgrade eines Pakets kennt die Paketverwaltung die Konfigurationsdateien der installierten Programme und schützt sie vor dem Überschreiben.

RPM

Für die RPM-Paketverwaltung dreht sich in der Prüfung alles um den Befehl »rpm«. Er installiert (»-i«) und deinstalliert (»-e«) Pakete. Dabei überprüft das RPM-System, ob die Installation oder Deinstallation ohne Probleme erfolgt. Eine erste Trockenübung vor der Installation erlaubt die Option »--test« am Ende der Befehlszeile. Treten mit ihr Fehler auf, bricht der Vorgang ab.

Bei einer Wiederholung der Installation mit den Optionen »--force« oder »--nodeps« ignoriert RPM die Fehler beziehungsweise fehlenden Abhängigkeiten. Speziell für das Update mit »rpm -U« gibt es zusätzlich die Option »--oldpackage«, die eine Installation älterer Pakete über neuere erlaubt.

Für alle Optionen existieren auch Langversionen: »--install« (»-i«), »--erase« (»-e«) und »--upgrade« (»-U«). Besonders interessant sind auch die Optionen »--verify« (»-V«), »--checksig« (»-K«) und »--query« (»-q«), die der Aspirant bei der LPI-Prüfung kennen soll. Die Option »-V« prüft die Integrität eines installierten Pakets. Fehlende oder modifizierte Dateien zeigt der Befehl ebenfalls an. Die Angabe von »-K« prüft vor der Installation die Integrität des Pakets. Sie zeigt Fehler in der Prüfsumme oder in der Signatur an, die sicherstellen, dass die RPM-Pakete aus einer vertrauenswürdigen Quelle stammen und konsistent sind.

Die Option »-q« zeigt alle gespeicherten Informationen über die installierten Pakete an. Das sind die Listen der installierten Dateien (»-ql«), Konfigurationsdateien (»-qc«), Dokumentationsdateien (»-qd«) sowie allgemeine Informationen über das Paket (»-qi«). Mit »-qa« (siehe Abbildung 1) erhält der Benutzer eine Aufstellung aller installierten Pakete. Wer zum Beispiel erfahren will, welche Gnome-Pakete installiert sind, nutzt folgenden Befehl:

rpm -qa | grep gnome

Zu welchem Paket eine bestimmte Datei gehört, zeigt die Eingabe von:

rpm -qf /etc/motd/setup-2.5.44-1

Um eine Query-Optionen auf ein noch nicht installiertes Paket anzuwenden, ist zusätzlich »p« anzugeben. Ein anderer Befehl - »rpm --rebuilddb« - repariert eine defekte RPM-Datenbank und baut sie neu auf.

Debian-Paketmanagement

Debians Pendants zu RPM heißen DPKG (Debian Package) und »apt-get« (Advanced Packaging Tool). Zusätzlich zur reinen Installation (»dpkg -i«) beziehungsweise Deinstallation (»dpkg -r«) erhält der Admin mit dem Aufruf »dpkg -l« eine Liste aller installierten Pakete.

Erfreulicherweise kann der Anwender hier direkt ein Suchmuster mit angeben. Um etwa alle Gnome-Pakete zu sehen, genügt »dpkg -l `gnome*`«. Der Befehl »dpkg -L Paketname« zeigt alle Dateien eines Pakets an, »dpkg -S Suchmuster« sucht in den Dateinamen aller installierten Pakete nach dem Muster.

Einfacher ist die Installation neuer Pakete jedoch mit »apt-get«. Dieses Werkzeug berücksichtigt Abhängigkeiten automatisch und installiert die entsprechenden Pakete mit. Ein »apt-get update« versorgt den lokalen Rechner mit der neuesten Paketliste, der Befehl »apt-get upgrade« installiert neue Versionen der installierten Pakete.

Eine Alternative ist die Paketinstallation mit »dselect«. Dieses Tool startet ein menübasiertes Auswahlfenster zum An- und Abwählen von Paketen. Die Installation erfolgt anschließend über »apt-get«. Wenn der Debian-Admin ein Paket nur im RPM-Format findet, wandelt er es mit »alien« in ein ».deb«-Paket um; das funktioniert auch umgekehrt.

Für die LPI-Prüfung sollte der Aspirant die Werkzeuge beider Paketverwaltungen kennen und eingesetzt haben. Sowohl RPM als auch die Debian-Paketverwaltung verfügen über eigene Konfigurationsdateien:

• »/etc/rpmrc« oder »/etc/rpm/*«
• »/etc/dpkg/dpkg.cfg«
• »/etc/apt/*«

Über diese Dateien sollte jeder LPI-Kandidat ebenfalls Bescheid wissen.

Komprimierungsformate

Manchmal ist von der gewünschten Software für die eigene Distribution kein Binärpaket verfügbar. Steht auch kein Sourcepaket (»*.src.rpm« oder *».src.deb«) bereit, ist die Software aus dem Quelltext zu installieren. Dies ist auch dann erforderlich, wenn das Programm noch benutzerspezifische Optionen erhalten soll. Der Quelltext der Software steht üblicherweise als Archiv bereit, das es zunächst auszupacken gilt. Folgende Formate sind gebräuchlich:

• Tar (».tar«)
• Gzip (».gz«)
• Bzip 2 (».bz2«)

Häufig sind auch Kombinationen aus ».tar.gz« und ».tgz« sowie »tar.bz2« und ».tbz2« anzutreffen.

Tar, das Tape-Archive-Backup-Format, sammelt mehrere Dateien und Verzeichnisse in einer Datei. Das Format speichert wie ein Backup sowohl Eigentümer als auch Rechte und Zeitstempel. Gzip und Bzip2 sind Kompressionsprogramme, die eine Datei oder einen Datenstrom (über eine Pipe) komprimieren.

Um ein Tar-Archiv zu erzeugen, benutzt der Admin den Befehl »tar -cf Archiv.tar zu komprimierende Dateien«. Der Befehl »tar -xf Archiv.tar« entpackt das Archiv wieder. Da Tar selbst normalerweise keine Kompression durchführt, übernehmen das die Programme Gzip oder Bzip 2. Mit den Optionen »-z« (Gzip) und »-j« (Bzip 2) fordert der Admin direkt beim Erzeugen des Tar-Archivs dessen Kompression. Zum Entpacken eines »tar.gz«-Archivs sind also alternativ diese beiden Kommandos möglich:

tar -xzf Archiv.tar.gz
gunzip Archiv.tar.gz; tar xf Archiv.tar

Achtung: Die Optionen von »tar« lassen sich sowohl mit als auch ohne Minuszeichen aufrufen.

Quelltexte kompilieren

Meist erfolgen das Auspacken des Archivs und die anschließende Übersetzung in den Verzeichnissen »/usr/src« oder »/usr/local/src«. Ist das Paket entpackt, gilt es, die Quellen zu übersetzen. Um die Quelltexte, die meist in der Programmiersprache C geschrieben sind, zu übersetzen, benötigt der Admin den GNU-C-Compiler »gcc«, einen Linker und die Maketools. Damit er nicht jede Quelltextdatei einzeln übersetzen muss, enthalten die Pakete meist ein Makefile. Ist dieses nicht vorhanden, muss er es erst erzeugen.

Die Archive der meisten Softwareprojekte enthalten hierzu ein Skript namens Configure. Es überprüft das Vorhandensein der notwendigen Bibliotheken und Dateien. Fehlen für den Kompiliervorgang oder den späteren Betrieb notwendige Dateien, stoppt das Skript, andernfalls erzeugt es das Makefile, das dann das Kommando »make« abarbeitet.

Handelt es sich um ein von den Standards abweichendes Betriebssystem, erlaubt der Configure-Aufruf die Angabe abweichender Pfade, die er beim Erzeugen des Makefile berücksichtigt. Welche Optionen die Software unterstützt, ist meist in einer Datei »README« oder »INSTALL« dokumentiert.

In den meisten Fällen übersetzt der Admin eine Software aus ihrem Quelltext mit dem folgenden Dreisatz:

./configure
make
make install

Erfahrene Administratoren geben häufig alle drei Befehle in einer Zeile an:

./configure && make && make install

Die »&&«-Zeichen zwischen den Befehlen bestimmen, den jeweils nächsten Befehl nur dann auszuführen, wenn der davor fehlerfrei abgearbeitet ist.

Aus Sicherheitsgründen sollten Konfiguration und Übersetzen nicht mit Root-Rechten erfolgen, während der Befehl »make install« meist mit Root-Privilegien auszuführen ist. Schlägt das Übersetzen fehl, ist zu prüfen, ob Bibliotheken fehlen, mit »make clean« sind bereits übersetzte Programmteile zu löschen.

Bibliotheken

Das Übersetzen von Programmen bindet praktisch immer Bibliotheken ein. Dieser Vorgang heißt Linken, er erfolgt entweder statisch oder dynamisch. Das statische Binden lagert die Bibliotheken komplett in der ausführbaren Datei ein. Zum späteren Ausführen des Programms müssen die Bibliotheken dann nicht auf dem System vorhanden sein. Das dynamische Einbinden der Bibliotheken als Shared Objects (».so«) bettet nur die Referenzen auf die Bibliotheken in der ausführbaren Datei ein. Beim späteren Start des Programms müssen diese auf dem System vorhanden sein, um geladen zu werden.

Das statische Linken von Bibliotheken macht die ausführbaren Dateien (sehr) groß, Laden und Start dauern entsprechend länger. Sicherheitsrelevante Software wird trotzdem häufig statisch kompiliert, um zu verhindern, dass ein Angreifer in gelinkte Bibliotheken Sicherheitslücken einbauen kann.

Dynamisch gelinkte Software ist wesentlich kleiner und benötigt meist auch weniger Arbeitsspeicher, da die verwendeten Bibliotheken nur ein Mal geladen, aber von mehreren Prozessen gemeinsam genutzt werden. Daher bezeichnet man diese Bibliotheken als Shared Objects. Sind sie bereits geladen, spart das beim Start des Programms auch die entsprechende Zeit, die ein zusätzliches Laden benötigen würde.

Der Nachteil: Wurde das Programm für eine bestimmte Version der Bibliothek übersetzt, funktioniert es nach deren Update möglicherweise nicht mehr. Die Paketverwaltungen berücksichtigen dies aber meist und aktualisieren die betroffenen Programme.

Hat der Admin aber das Programm aus Archivquellen ohne den Paketmanager installiert, muss er sich selbst darum kümmern. Der Befehl »ldd« (siehe Abbildung 3) zeigt alle vom Programm benötigten Bibliotheken. Aber auch wenn sie alle installiert sind, heißt dies nicht, dass Linux sie auch findet. Zunächst definiert die Datei »/etc/ld.so.conf«, wo das System überhaupt nach Bibliotheken sucht. Bei der Installation von Libraries in ungewöhnlichen Pfaden ist die Konfigurationsdatei anzupassen (siehe Listing 1). Moderne Distributionen nutzen hier auch Dateien aus dem Verzeichnis »/etc/ld.so.conf.d/«.

01 include ld.so.conf.d/*.conf
02 /usr/lib
03 /lib
04 /usr/X11R6/lib
05 /usr/local/lib

Wurde eine Bibliothek über die Paketverwaltung der Distribution installiert, kümmert sich diese auch um das Anpassen der Datei und um die Neuanlage des Cache. Um nicht bei jedem Programmstart alle Verzeichnisse durchsuchen zu müssen, verwendet Linux nämlich einen Cache, der alle in den definierten Verzeichnissen gespeicherten Bibliotheken aufführt. Der Befehl »ldconfig« legt diesen Cache neu an. Der Admin sollte ihn jedes Mal aufrufen, wenn er eine Bibliothek manuell installiert, damit Linux sie auch bestimmt findet.

Prüfungsvorbereitung

Zur Vorbereitung auf die LPI-Prüfung sollten Anwärter selbst einige Softwarepakete installieren, beginnend mit dem Quelltext. Auch die Paketverwaltung mit RPM und den Debian-Werkzeugen »apt-get« und »dpkg« lässt sich vorher trainieren. Um die gängigen Fragen (siehe Kasten "Fragen zur Paketverwaltung") zu beantworten, ist es sinnvoll, beide Systeme zu testen. (tle)