© photocase.com
Softwarepakete einfach nur zu installieren und zu entfernen – das ist keine große Kunst. Aus den gängigen Paketsystemen ist jedoch viel mehr herauszuholen. Der Artikel gibt dazu praktische Tipps und stellt nützliche Tools vor.
Mit dem Paketmanagement der eigenen Distribution setzt man sich normalerweise nur selten auseinander. Dabei besitzen die Programme oft versteckte Funktionen, die Paketverwaltung vereinfachen. Kleine Zusatztools verschaffen zum Beispiel Zugang zu Software-Archiven oder stellen Abhängigkeiten grafisch dar. Dieser Artikel gibt Tipps zur Nutzung der mitgelieferten Programme und stellt die nützlichsten Tools vor.
Hängendes RPM flott machen
Weil RPM seine Informationen in eine systemweite Datenbank schreibt, muss es sich darum kümmern, dass nicht zwei Benutzer gleichzeitig sie verändern. Das macht es mit normalen Datei-Locks. Stürzt RPM einmal ab, löscht es die Sperrdateien nicht. Die Folge: Der Befehl »rpm« bleibt einfach hängen, gibt aber auch keine Fehlermeldung aus. Wer sich durch einen Blick in die Prozesstabelle mit »ps« davon überzeugt hat, dass rpm nicht mehr läuft, kann die Locks einfach löschen: »rm -f /var/lib/rpm/__db.*«.
Yum beschleunigen
Mit Yum unter Fedora Pakete zu installieren, kann manchmal ganz schön nerven: Bei jedem Aufruf dauert es schon mal eine zeitlang, bis das RPM-Frontend seine Cache-Dateien aktualisiert hat. Um den Vorgang wenigstens ein bisschen zu beschleunigen, bietet sich der Schalter »-C« an, der die Cache-Aktualisierung deaktiviert. Damit ist zwar nicht gewährleistet, dass Yum immer auf dem neuesten Stand ist, aber es arbeitet wenigstens schneller. Zum Beispiel brauchte die Installation des Checkinstall-RPMs so nur knapp fünf statt fünfzehn Sekunden. Tipp: einmal täglich im Hintergrund Yum den Cache aktualisieren lassen.
Auch für RPM: Apt statt Yum
Apt ist zwar normalerweise als Frontend für Debian-Deb-Pakete bekannt, es lässt sich aber auch mit RPM benutzen. Damit wird die Installation von RPM-Paketen schneller und einfacher. Außerdem stehen einige Repositories zur Verfügung, die es für Yum nicht gibt, zum Beispiel das Archiv mit Musiksoftware Planet CCRMA [http://ccrma.stanford.edu/planetccrma/software]. Um es zu nutzen sind die Pakete apt und apt-libs nötig. Suse-Benutzer finden die Pakete unter [http://linux01.gwdg.de/apt4rpm], Fedora-User können von der Planet-CCRMA-Site das passende Kommando direkt per Cut-And-Paste übernehmen. Die Konfigurationsdateien befinden sich in »/etc/apt«, Repositories stellt man wie bei Debian in »/etc/apt/sources.list« ein. Unter KDE stellt KPackage nach Aktivierung der Einstellung »APT: Debian« den Inhalt von Apt-Repositories übersichtlich dar. Ein Doppelklick auf eines der Pakete installiert es per »apt-get« (Abbildung 1).
Abbildung 1: Unter Suse beherrscht Kpackage auch Apt-Repositories.
RPMs konvertieren
Um einen Blick in den Inhalt eines RPMs zu werfen oder es auf Nicht-RPM-Plattformen zu entpacken, braucht man ein Zusatzprogramm, denn »rpm« selbst kann das nicht. Teil der RPM-Distribution ist »rpm2pio«, das ein Cpio-Archiv in die Standardausgabe schreibt. Entweder man benutzt also den Umleitungsoperator »>« , um in eine Datei zu schreiben, oder schickt das Ergebnis per Pipe an »cpio«, das ohnehin von der Standardeingabe liest. Weil Cpio nicht gerade das am häufigsten benutzte Archiv-Tool ist, als kurze Erinnerung: »cpio -id« entpackt das Archiv und legt nicht vorhandene Verzeichnisse an.
Platz sparen mit RPM
Viel Plattenplatz verbrauchen häufig die mit jedem Paket automatisch installierten Dokumentationsdateien. Um RPMs ohne sie zu installieren, benutzt man den Schalter »–excludedocs«. Einen Überblick über die in einem noch nicht installierten Paket enthaltene Dokumentation verschafft »rpm -qpd Paketdatei«.
Pakete automatisch bauen
Viel freie Software gibt es nicht als Binärpaket im RPM- oder Debian-Format. Stattdessen greift der Benutzer zum Compiler und übersetzt das Programm selbst. Das abschließende make install verteilt die Daten auf der Platte, wo sie meist nicht ohne weiteres wiederzufinden ist. Checkinstall erzeugt auf Wunsch bei diesem ein distributionsspezifisches Paket, das sich später leicht entfernen lässt. Dafür ruft der Benutzer statt »make install« einfach »checkinstall« auf und beantwortet die folgenden Fragen.
Checkinstall loggt die Schreib-Events während der Installation mit. Es erzeugt Deb-Pakete für Debian und RPM-Pakete für Suse, Mandrake und andere. Auf Wunsch legt man in das Installationsverzeichnis zusätzliche Skripte, die man jeweils vor und nach der Installation beziehungsweise Deinstallation über den Paketmanager der Distribution aufruft. Weitere Optionen zeigt über das Kommando »checkinstall -h«. Checkinstall funktioniert zwar häufig, aber nicht immer. Probleme hat es zum Beispiel mit statisch gelinkten Bibliotheken.
RPM programmieren
Wer mit selbst geschriebenen Programmen RPM-Pakete installieren oder bearbeiten möchte, braucht das Rad nicht neu zu erfinden. Die Librpm enthält alle dafür nötigen Funktionen. Bei Suse enthält das Paket »rpm« die Shared-Library, die Header finden sich in »rpm-devel«. Skriptsprachen-Benutzer können auf Module für Python und Perl zurückgreifen. Viele Beispiele im Netz sind allerdings veraltet, weil sich das API immer wieder geändert hat. Einige brauchbare Informationen liefert: [http://people.redhat.com/pnasrat/rpm-python/rpm-python-slides/frames.html]
Pakete zu Dateien finden
Häufig findet man in den Untiefen des Dateisystems die eine oder andere unbekannte Datei. Um zu erfahren, zu welchem Paket sie gehört, bieten die Paketsysteme je eigene Wege. Für Debian-Pakete übernimmt das »dpkg -S /Pfad/zu/Dateiname«. Die lange Variante der Option lautet »–search«. Auf RPM-Systemen wie Fedora, Red Hat oder Suse übernimmt das »rpm -qf /Pfad/zu/Dateiname«.
Abhängigkeiten grafisch
Die meisten Pakete moderner Distributionen setzten viele andere Programme und Bibliotheken voraus. Zum Beispiel benutzt der Mail- und Groupware-Client Evolution auf dem aktuellen Ubuntu knapp 100 verschiedene Libraries.
Zur besseren Übersicht über so komplexe Verhältnisse verhilft eine grafische Aufbereitung. Debian-basierte Distributionen bringen die Mittel dafür schon mit: Der Befehl »apt-cache« versteht die Option »dotty«, die Abhängigkeiten im Dot-Format des Visualisierungspakets Graphviz ausgibt: »apt-cache dotty Paket > Paket.dot«.
Der Befehl »dotty Paket.dot« zeigt das Ergebnis an oder gibt es mit dem Schalter »dot -Tps Paket.dot > Paket.ps« als Postscript-Datei aus. Weil Apt-Cache alle Abhängigkeiten bis zum Ende weiterverfolgt, wird die Darstellung allerdings leicht unübersichtlich. Abhilfe schafft der Eintrag »APT::Cache::GivenOnly “true”;« in der Datei »/etc/apt/apt.conf«. Abbildung 2 zeigt das Ergebnis für den Webserver Apache.
Abbildung 2: Unter Debian kann der Befehl »apt-cache« Paketabhängigkeiten visualisieren. Hier ausschnittsweise die Abhängigkeiten des Apache-Webservers.
Echtheit verifizieren
Wer feststellen will, ob die installierten Binaries auf seinem Server noch im gleichen Zustand sind wie bei der ursprünglichen Installation, kann auf die Option »-V« des RPM-Kommandos zurückgreifen. Beim Verdacht eines Einbruchs ist das ein erster, einfacher Schritt, ohne gleich das ganze Arsenal an Root-Kit-Aufspürern aufzufahren. Gibt beispielsweise »rpm -V procps« nichts aus, sind die zugehörigen Dateien wie »ps« mit großer Wahrscheinlichkeit unangetastet (vorausgesetzt kein Einbrecher hat »rpm« selbst manipuliert). Gibt RPM zum Beispiel »S.5….T /bin/ps« aus, stehen die Buchstaben und Zahlen für einzelne Anderungen wie Dateigröße (S), MD5-Checksumme (5) und Modifikationszeit (M).
Unnütze Pakete entfernen mit Aptitude
Dass APT Abhängigkeiten automatisch auflöst und bei der Installation eines Pakets die gesamte benötigte Software mit installiert, nimmt Administratoren von Debian-System und -Derivaten viel Arbeit ab. Doch die so im System gestrandeten Pakete aufzuspüren, wenn sie nicht mehr gebraucht werden, ist ohne Hilfsmittel mühsam.
Die Debian-Paketexperten empfehlen deshalb, zur Installation an Stelle von »apt-get install« den Gebrauch von »aptitude install«. Es speichert in seiner Datenbank, ob ein Paket auf Benutzeranfrage hin eingespielt wurde oder auf Grund der Notwendigkeit eines explizit angeforderten Pakets. In Folge eines »Dependencies«-Eintrags installierte Pakete kennzeichnet das Aptitude-Interface mit »A« für “automatically installed” (Abbildung 3). Das Suchmuster »~M« findet solche Pakete. Mit [Shift]+[M] verleiht der Benutzer einen Eintrag manuell den Status “automatisch installiert”, mit [M] hebt er ihn auf.
Abbildung 3: Aptitude markiert automatisch mitinstallierte Pakete mit einem »A«. So lassen sie sich leicht aufspüren und entfernen, wenn der Bedarf nicht mehr besteht.
Debian-Hausdiät
Mit anderen Apt-Frontends als Aptitude stehen solche Markierungen nicht zur Verfügung. Dann helfen auf diese Aufgabe spezialisierte Werkzeuge dabei, überflüssige Pakete ausfindig zu machen. Das Programm Deborphan sucht in den Sektionen »libs« und »oldlibs« nach installierten Paketen, von denen kein anderes abhängt, und liefert die Namen in der Standardausgabe. So lässt es sich leicht in Bash-Aufrufe oder -Skripte integrieren. Beispielsweise entfernt das Kommando »apt-get remove $(deborphan)« direkt die von Deborphan aufgespürten Pakete.
Die Suche mit Deborphan lässt sich auf andere Sektionen ausdehnen: »deborphan –guess-dev« fahndet beispielsweise nach nicht mehr benötigten Entwickler-Paketen, »deborphan –guess-dummy« nach Dummy-Paketen. Der Parameter »–guess-all« durchforstet alle Sektionen. Einen Überblick über die Funktionen liefert »deborphan –help«. Nach einem Deborphan-Durchlauf deckt ein weiterer Programmaufruf häufig weitere überflüssige Pakete auf.
Etwas mehr Benutzerinteraktion erfordert Debfoster. Es legt eine Datenbank an, in der es Pakete speichert, die der Admin behalten möchte. Dazu fragt es ihn beim ersten Aufruf nach dem Status jener Pakete, von denen keine anderen abhängen. Dabei zeigt es jeweils eine Liste der Pakete, die wiederum als Folgeabhängigkeiten existieren und mit dem erste Paket installiert bleiben. So erstellt Debfoster einen Abhängigkeitsbaum. Entfernt der Benutzer ein Paket, fragt es beim nächsten Aufruf, wie es mit den in diesem Zweig weiterhin vorhandenen Packages verfahren soll.
Damit hat es gegenüber Deborphan den Vorteil, dass es alle Pakete findet und es dem Anwender ermöglicht, etwa Meta-Pakete dauerhaft als erwünscht zu definieren. Der Nachteil liegt im recht großen Zeitaufwand beim Erstellen der initialen Datenbank. Debfoster integriert jedoch mittels Parametern wie »–guess-dev« auch die Ratefunktionen von Deborphan, um diesen Vorgang teilweise zu automatisieren.
