von Georg Basse, Mai 2004
In den Frühzeiten der Linux-Geschichte wurde die Software auf Bändern oder Disketten ausgeliefert. Mit zunehmender Komplexität der Distributionen wurden deren Komponenten in Form von Paketen gebündelt, die sich einzeln und nach Vorauswahl durch den Benutzer installieren liessen. Verschiedene Ansätze für das Paketmanagement wurden im Laufe der Jahre ersonnen, fanden Verbreitung und gerieten wieder in Vergessenheit. Übriggeblieben sind einige, wenige Formate wie das Debian Paketformat , das Redhat Packet Management und auch die noch sehr urtümliche Slackware Paketverwaltung. Daneben hat Gentoo mit seinem Portage-System einige Ideen aus der *BSD Welt in das Reich des Pinguins übertragen.
Dieses Dokument beschreibt vergleichend die grundliegenden Eigenschaften der genannten Paketverwaltungen. Dies geschieht sowohl aus Anwender- und Adminstratorensicht als auch aus Sicht des Entwicklers, der Pakete selbst schnüren möchte. Aufgrund der hohen Komplexität des Themas können natürlich nicht alle Aspekte der jeweiligen Mechanismen und Tools behandelt werden. Weiterführende Literatur zu den einzelnen Werkzeugen ist am Ende des Artikels genannt.
Anforderungen heute
Eine Paketverwaltung muss eine Reihe von Anforderungen erfüllen. Aus Sicht des Adminstrators ist hier in erster Linie der Umgang mit Abhängigkeiten zwischen Paketen zu nennen. Jedes Paket muss vollständig über seine Erfordernisse an die Laufzeitumgebung Auskunft geben und ebenso vollständig die von ihm bereitgestellten Komponenten nennen. Mit diesen Informationen versorgt können dann entsprechende Softwaretools automatisch alle für die Installation eines Paketes notwendigen weiteren Pakete prüfen und wenn nötig installieren. Dies ist nicht trivial: Aus der Installation einer für ein Paket erforderlichen Bibliothek beispielsweise können sich weitere Abhängigkeiten ergeben. Auch sind Abhängigkeiten nicht immer eindeutig zu definieren; manche Komponenten werden nur unter bestimmten Voraussetzungen benötigt (sind also optional), an anderer Stelle sind nur bestimmte Funktionalitäten (wie z.B. ein SMTP Mail Transfer Programm) erforderlich, die sich auf ähnliche Weise von mehreren Programmen (z.B. sendmail, postfix, qmail) bereitstellen lassen.Eine Hauptaufgabe von Tools zur Paketverwaltung ist es, die unterschiedlichen Quellen Pakete zu verwalten. Neben Wechseldatenträgern wie CDROMs und DVDs der jeweiligen Distribution sind auch Internetressourcen und idealerweise fremde, nicht zur Distribution gehörige Datenträger als Lieferanten von Softwarepaketen heranzuziehen. Dabei will der Administrator möglichst einfach die gewünschte Software ungeachtet der unterschiedlichen Quellen finden können. Eine moderne Paketverwaltung muss auch einmal installierte Software wieder eindeutig den Ursprungspaketen zuordnen können. Für jede installierte Datei ist ein Eintrag in einer Datenbank erforderlich, die das Ursprungspaket benennt. Wie diese Datenbank realisiert ist, spielt hierbei eine untergeordnete Rolle. Neben der Erstinstallation eines Pakets ist das Update von Paketen und das Upgrade einer Distribution das Hauptarbeitsfeld des Paketmanagements. Wichtig hierbei ist ein reibungsloser Wechsel von einem Versionsstand zum nächsten unter Beibehaltung der Konfigurationen an der jeweilgen Software. Je weiter eine Software zu konfigurieren ist, desto schwieriger kann die Abbildung dieser Anforderung bei der Paketerstellung sein. Ein „bootless“ Upgrade einer gesamten Distribution ohne spürbaren Ausfall von bereitgestellten Diensten ist der Extremfall in diesem Bereich.
Neben Binärpaketen spielen Quellcodes in der Paketverwaltung ebenfalls eine wichtige Rolle, reden wir hier doch über die Verwaltung von Open Source Systemen. Das Paketmanagement muss eine klare Zuordnung von erstellten Binärdateien zum zugrunde liegenden Quellcode erlauben. Dabei müssen sich die während des Buildprozesses gemachten Konfigurationen des Quellcodes eindeutig nachvollziehen lassen. Nur dann ist es möglich, anhand des Quellcodes bei Bedarf ein neues, verändertes oder verbessertes Paket für die jeweilige Distribution zu erzeugen, das sich in den übrigen Eigenschaften genauso verhält wie das alte Paket.
In dieses Problemfeld fällt auch die Anforderung nach einem integrierten Patch-Management, obwohl hier Entwickler und Software-Maintainer eher betroffen sind als der Administrator und Anwender eines Systems. Linux Distrbutoren hauptsächlich damit beschäftigt, aus dem jedem zur Verfügung stehenden Pool an freier Software ein Produkt mit charakteristischen Eigenschaften und einem entsprechenden Branding zur erstellen. Diese Maintainance für einzelne freie Softwareprojekte fällt umso schwerer, je mehr individuelle und manuelle Arbeiten bei Versionswechsel des jeweilgen Projekts erforderlich sind. Die Integration distributions- und plattformabhängiger Patches und die Durchführung des Buildprozesses solte durch die Paketverwaltung soweit wie möglich automatisch ablaufen. Ein solches automatisches Verfahren garantiert auch eine hohe Nachvollzeihbarkeit und ist dann mehr oder weniger selbst dokumentierend. Ein weiterer Aspekt ist der Bedarf nach einer wirklich plattformübergreifenden Funktion der Paketverwaltung. Wird in anderen Betriebssystemwelten hierunter nur die Funktion einer Software mit verschiedenen Jahrgängen eines Betriebssystems auf derselben Hardware verstanden, so bietet Linux hier eine bei weitem grössere Abdeckung. Hier wollen neben 32-Bit x86 Architekturen auch die abgeleiteten 64-Bit Architekturen ebenso bedient werden wie PowerPC- und Sparc-Plattformen, IBMs zSeries und eine Fülle weiterer Plattformen mit geringer werdender Relevanz (wie HP PA Risc, Motorola 68K, Acorn Risc Prozessor). Ein Paketmanagement muss helfen, die plattformabhängigen Spezifitäten des Buildprozesses und des Patchen des Ausgangsquellcodes im Griff zu behalten.
Features im Vergleich
Um möglichst einfach einen Überblick zu Paketformaten, -managern und zur Verfügung stehenden Features zu erhalten, wurden diese in Tabelle 1 vergleichend gegenübergestellt. Diese Darstellung orientiert sich an der Alien-Homepage [5]. Um diese Gegenüberstellung verständlich zu machen, bedarf es einer Beschreibung der genannten Features:
- Sicherheit und Authentizität:Die Installation von Softwarepaketen stellt nicht zu unterschätzende Sicherheitsanforderungen. Durch die Verwendung einer digitalen Signatur vorzugsweise auf Basis des freien GPG ist die Herkunft des Pakets aus einer bestimmten Quelle sicherzustellen. Hierzu muss der Maintainer eines Pakets ein Schlüsselpaar erstellen und seinen öffentlichen Schlüssel bereitstellen. Bei der Paketerstellung signiert der Maintainer das Paket mit seinem privaten und nur ihm zugänglichen Schlüssel. Nach dem Download eines Pakets kann der Benutzer dann mittels des öffentlichen Schlüssels die korrekte Signatur des Pakets nachweisen. Besonders bedeutsam ist dies für Mirror-Server, die Pakete einer Originalquelle (z.B. dem Stammserver einer Distribution) spiegeln. Durch die Signatur lässt sich prüfen, ob es sich auf dem Mirror wirklich um Originale des Stammservers handelt oder um möglicherweise in böswilliger Absicht manipulierte Pakete von Dritten. In der RPM-Welt ist die Verwendung von Signaturen einigen Jahren üblich, auch für Debian Pakete bürgert sich dieses Vorgehen ein. Slackware Pakete kennen diesen Mechanismus leider nicht. Prüfsummen stellen zusätzlich die Integrität von Paketen sicher. Fedora Core nutzt diese Summen, um bei CDROM Images vor einer Installation auf Wunsch einen Integritätstest der gesamten Distribution durchzuführen, wodurch sich download-bedingte Fehler ausschliessen lassen.
- Paket-Metadaten:Innerhalb der Paket-Metadaten, also der Gesamtheit aller Verwaltungsdaten und -informationen sollten neben dem Namen und der Versionsinformation der Software auch eine Beschreibung des Paketinhalts enthalten sein. Ein Paket kann dabei neben seinem eigentlichen Paketnamen (z.B. apache) auch den Namen eines virtuellen Pakets (z.B. Webserver) tragen. Einen grossen Stellenwert nehmen wie oben angeführt die Benennung von Beziehungen unterschiedlicher echter oder virtueller Pakete untereinander ein. Abhängigkeiten auf Paket- oder Dateiebene sind hierbei ebenso zu nennen wie Konflikte, also Ausschlusskriterien für ein neues Paket aufgrund des Vorhandenseins eines anderen. Als Anforderungen (recommendations) werden in Abgrenzung dazu Paketbeziehungen verstanden, die eine Installation eines Pakets zwar nicht unmöglich machen, in den meisten Fällen aber einen Betrieb der jeweiligen Software erschweren oder verhindern. Alle diese Beziehungen können ausserdem versionsabhängig sein. Eine logische Verknüpfung von Abhängigkeiten im Sinne von „Paket A benötigt Paket B und (Paket C oder D)“ bietet in beliebiger Schachtelungstiefe derzeit nur Debian. RPM erfordert hier aufwendige Konstrukte, da hier nur reine Und-verknüpfte Listen möglich sind. Auch ist hier ebenso wie bei Slackware keine Priorisierung bekannt, für das System essentielle Pakete (z.B. binutils) können nicht von entbehrlichen Paketen (z.B. emacs) getrennt differenziert werden. Fedora Core nimmt eine solche Trennung ausserhalb von RPM im Software-Installationstool vor, Suse tut in YaST ähnliches.
- Besondere DateienRPM bietet besondere Mechanismen für die Installation und das Löschen von Dokumentationen und Konfigurationsdateien an. Dies spiegelt sich im Verzeichnisbaum unterhalb von /usr/share/doc wieder, wo RPM einheitlich formatierte Verzeichnisnamen für die Paketdokumentationen generiert. Auch die bei Installation und Deinstallation auftretenden Dateien /etc/xyz.rpmsave und rpmnew erzeugt RPM für deklarierte Konfigurationsdateien automatisch. Von besonderer Bedeutung für die Zuordnung von Dateien zu Paketen in einem installierten System können „ghost“ Dateien wie z.B. Logfiles sein. Diese sind nicht im Paket enthalten, werden aber von der enthaltenen Software erzeugt und sind daher dem Paket zuzuordnen.
- Paketmanager-ProgrammeBei der Installation und Deinstallation können unter Umständen aufwendige Massnahmen erforderlich sein, die weit über das einfache Kopieren und Löschen von Dateien hinausgehen. Diese Massnahmen sind hochgradig spezifisch für das jeweilige Programm und daher nicht vollautomatisch vom Paketmanagement durchzuführen. Stattdessen muss der Paket Maintainer durch vor oder nach einem Installations- oder Deinstallationsprozess ablaufende Scripts die erforderlichen Dinge erledigen lassen. Die Qualität dieser Scripts macht einen wesentlichen Anteil des Komforts im Umgang mit Softwarepaketen aus und an dieser Stelle zeigen sich die meisten Qualitätsunterschiede zwischen verschiedenen Distributionen, auch wenn sie wie bei RPM ein und dasselbe Paketformat verwenden.Neben Pre- und Postinstallations- und Deinstallationsprogrammen sind Triggerscripts [6] ein interessantes und nur bei RPM vorkommenden Feature. Durch einen Trigger ist ein installiertes Paket imstande, auf Veränderungen im Paketpool zu reagieren und z.B. bei Austausch eines Mail Transfer Agents die erforderlichen Änderungen an der eigenen Konfiguration automatisch vorzunehmen. Dieses Feature wird leider trotz seines hohen Nutzens nicht oft verwendet.
RPM
Das RPM Paket stellt neben einer Reihe weiterer Tools mit dem Programm /bin/rpm das wichtigste Programm für das Paketmanagement bereit. Es dient zum Installieren, Löschen und Aktualisieren von Paketen und verfügt über viele Funktionen zum Anzeigen von Paketeigenschaften. Die Manual-Seite zu „rpm“ (man rpm) ist ausgesprochen ausführlich und sollte die Benutzung hinreichend erklären. Daher sollen hier nur anhand einiger, auf die Vergleichstabelle bezogene Tips im Umgang mit „rpm“ beschrieben werden.Zur Arbeit mit digitalen Signaturen stellt „rpm“ einige Kommandos bereit. Neue öffentliche Schlüssel lassen sich mit rpm –import key.txt aus einer ASCII Datei (hier key.txt) einspielen. Bei Installation oder Update eines Pakets prüft „rpm“ dann die Paketsignatur mit diesem öffentlichen Schlüssel und warnt gegebenenfalls. rpm -K paket.rpm prüft ein Paket (hier paket.rpm) hinsichtlich seiner Signatur und gibt den Schlüsseltyp aus. Eine Übersicht über die installierten Schlüssel liefert der Aufruf rpm -qi gpg-pubkey.
Eine weitere wichtige Eigenschaft der RPM Pakete ist das Vorhandensein einer Prüfsumme, über die sich die Integrität des Pakets nachweisen läßt. Dies funktioniert auch mit Dateien aus installierten Paketen. Der Befehl rpm -Va listet alle Dateien, die sich seit der Installation der vorhandenen Pakete verändert haben. Einerseits kann diese Funktion zum Erstellen eines in Bezug auf die Installations-CDs einer Distribution inkementellen Backups herangezogen werden. Andererseits bietet sich so eine Kontrollmöglichkeit, ob Binärdateien einer Änderung unterzogen wurden. Solche Änderungen sind zunächst einmal verdächtig und können Hinweise auf unerwünschte Benutzeraktivitäten oder sogar auf ungebetete Gäste auf dem System liefern, da u.U. Originaldateien durch kompromittierte Kopien ausgetauscht wurden.
Mit der Option -q werden bei „rpm“ alle Abfragen von Paketdaten und RPM Datenbankinformationen eingeleitet. Viele Paket-Metadaten lassen sich mit dem Aufruf rpm -qip paket.rpm für nicht installierte Pakete bzw. mit rpm -qi paketname für installierte anzeigen. Eine Liste der installierten Pakete liefert rpm -qa, wobei der Aufruf in der Form rpm -qa -last | less diese Liste nach Installationszeitpunkt sortiert auflistet. Eine Liste der Abhängigkeiten eines Pakets zeigt das Kommando rpm -qpR paket.rpm bzw. rpm -qR paketname (s.o) an. Weitere oft benötigte Optionen sind rpm -qpl paket.rpm für die Anzeige der Dateien innerhalb eines Pakets und rpm -qf dateiname, um die Zugehörigkeit einer Datei zu einem Paket zu ermitteln.
Bei Updates eines Pakets kann es sinnvoll sein, den ursprünglichen Versionsstand inklusive der durchgeführten Konfigurationen zu sichern, um bei Problemen eine „fall back“ Möglichkeit zu haben. Dafür stellt „rpm“ die Option –repackage zur Verfügung. Mit rpm -U –repackage paket.rpm wird ein Update des Pakets durchgeführt, die alte Version landet als RPM-Paket unter /var/spool/repackage/altpaket.rpm. Für ein „fall back“ genügt dann ein rpm -U –oldpackage altpaket.rpm. Dies kann auch als elegante Möglichkeit dienen, um Pakete mit komplexen Konfigurationen sicher von einer Maschine auf eine andere zu transportieren.
APT
EntwicklungMit Debian 0.93 erschien das bis heute eingesetzte .deb Paketformat und der Paketmanager „dpkg“ auf der Bildfläche. Seine weitreichenden Fähigkeiten besonders im Bereich der Behandlung von Abhängigkeiten zwischen einzelnen Paketen wurden aus dem Anspruch des Debian-Projekts heraus geschaffen, ein integriertes und stabiles Gesamtsystem zu schaffen. Für dpkg existieren mit dselect und apt-get verschiedene Frontends.
Das ursprünglich für Debian entwickelt stellt das „advanced packaging tool“ APT ein universelles Frontend für die Paketmanager dpkg und RPM dar. Die RPM Portierung stammt vom Linux-Distributor Connectiva, steht aber für alle RPM basierten Distributionen bereit [1]. Das APT Paket besteht aus einer Sammlung von Tools, von denen apt-get das am meisten verwendete Programm sein dürfte. Es erledigt die Installation neuer Pakete, das Update vorhandener Pakete und bei Bedarf auch das Upgrade einer Linux-Installation in seiner Gesamtheit.
Damit dies funktioniert, benötigt apt-get die Metadaten aller bereitstehender Pakete in einer lokalen Caching-Datenbank, der Paket-Cache unter /var/cache/apt/pkgcache.bin. Diese lokale Datenbank wird anhand der zur Verfügung stehenden Paketquellen gefüllt. Hierbei kann es sich um Wechseldatenträger oder Netzwerkressourcen handeln. Benannt werden diese Quellen in der Datei /etc/apt/sources.list, die sich manuell oder (im Falle von CDROMs und DVDs) mit dem Befehl apt-cdrom pflegen lässt. Der Befehl apt-get update aktualisiert und ergänzt die Cache anhand dieser Quellinformationen. Jede Datenquelle muss die Metadaten der durch sie bereitgestellten Pakete in einem Verzeichnis apt/ bereitstellen. Bei Online-Repositories egal ob für Debian oder RPM Distributionen [3] ist dies Aufgabe des jeweiligen Betreibers, bei CDROMs muss dies bei der Erstellung des Master-Images vorgenommen werden. Das Debian-Projekt übernimmt dies bei seiner Distribution, bei RPM-basierten Distributionen wie Fedora Core oder Suse Linux ist dies nicht der Fall. Sollen auch die Installations-CDs einer solchen Distribution durch APT verwaltet werden, steht ein Remastering an. Für RedHat Linux und Fedora Core 1 ist unter [2] eine passende Anleitung zu finden.
Der Mühen Lohn liegt in einer sehr bequemen Art der Paketverwaltung, wie das Beispiel in Listing #1 zeigt. Das zusätzlich erforderliche Paket Neon wurde automatisch identifiziert, in einem der konfigurierten Repositories lokalisiert und nach dem Herunterladen installiert. Soll das Paket entfernt werden, genügt ein apt-get remove cadaver. Allerdings verbleibt das als Abhängigkeit installierte Paket Neon in diesem Fall im System- APT kann schliesslich nicht „wissen“, ob der Administrator diese Software nicht doch noch benötigt und tut hier lieber nichts als zuviel des Guten.
Wie aus dem Beispiel zu erkennen ist, prüft APT vorhandene GPG-Signaturen von RPM Paketen und versucht so, die Authentizität der Software sicherzustellen. Dieses Feature wird durch den Schalter GPG-Check „true“; im Block RPM {}; der Datei /etc/apt/apt.conf kontrolliert und sollte immer aktiv sein. Ein Einschleusen von maligner Software in ein Linux-System kann bei heutiger Sicherheitslage am leichtesten über kompromittierte Server und Repositories geschehen. Das Signieren von Paketen, wie es RPM seit längerem und Debian dpkg seit dem Release 3 (Woody) kennt, bietet hier einen recht zuverlässigen Schutz vor Manipulationen. Anhand der Signatur eines Pakets und dem öffentlichen Schlüssel der Quelle (Repository), von der das Paket zu stammen vorgibt, kann die Herkunft desselben geprüft werden. Dies setzt natürlich voraus, daß die öffentliche Schlüssel der konfigurierten Repositories auch dem lokalen APT bekannt sind. Bei einem RPM System muss dazu der öffentliche Schlüssel vom jeweiligen Server heruntergeladen und mit rpm –import schlüsseldateiname im RPM System bekanntgemacht werden. Ohne diese Vorbereitung lädt apt-get zwar die angeforderten Pakete herunter, verweigert aber die Installation.
Wem auch dieser Umgang mit APT noch zu unbequem ist und lieber mit einem grafischen Frontend arbeiten möchte, findet in Synaptic [4] das richtige Werkzeug. Ein einmaliges apt-get install synaptic lädt und installiert das Programm, das sich bei KDE 3.2 und Fedora Core 2 unter „Systemeinstellungen, Weitere Systemeinstellungen, Synaptic Paketverwaltung“ wiederfindet. Unter einer übersichtlichen Oberfläche finden sich dort die Namen und Beschreibungen der zur Verfügung stehenden Pakete (Abbildung #1). Synaptic steht für Debian und RPM Distributionen (RedHat Linux, Fedora Core, Suse) bereit. Ein zumindest von der Oberfläche her homogenes Paketmanagement ist bei diesem „Mainstream“ Distributionen also möglich.
yum
Neben APT ist Yum das derzeit am meisten diskutierte Frontend zu RPM. Es basiert auf dem Programm YUP („Yellowdog Updater“) der Linux RPM-Distribution Yellowdog für PowerPC. Die Entwicklung von Yum („yellowdog updater modified“) begann an der Duke University in Durham (USA) durch Seth Vidal, einem der dortigen Systemadminstratoren. Ursprünglich als Motivation zum Erlernen der Scriptsprache Phyton gedacht, entwickelte sich Yum zu einem mittlerweile recht verbreiteten Tool für die Paketverwaltung bei RPM-basierten Distributionen. Vor allem Fedora Core setzt neuerdings auf diese Entwicklung und will das Redhat-eigene „up2date“ früher oder später durch Yum ablösen.Ähnlich wie APT stützt sich Yum auf Online-Repositories als Quelle von RPM-Paketen. Als Informationsbasis nutzt es die Header der RPM Pakete, die auf dem Repository im Verzeichnis headers/ als Dateien mit dem Namen paket.hdr liegen müssen. Die Datei header.info im gleichen Verzeichnis enthält zusätzlich eine Liste aller Pakete und Pfade zu diesen im Repository. Der Erstellung eines Yum-Repositories dient das Programm „yum-arch“. Im Gegensatz zu APT, das als Paket-unabhängiges Tool ein eigenes Format für die Speicherung dieser Paketinformationen benutzt beschränkt sich Yum auf den Umgang mit RPM Paketen und kommt so mit einer deutlich kompakteren Datenbasis aus.
Für den Zugriff auf die Repositories und die Installation von Paketen ist das Programm „yum“ vorgesehen. Es nutzt dafür die Protokolle HTTP oder FTP und stützt sich auf die zentrale Konfigurationsdatei /etc/yum.conf. Diese definiert neben zahlreichen Rahmenparametern auch die verfügbaren Yum-Server. Ein Blick auf die Homepage des Projekts [9] ist schon wegen der Liste der verfügbaren Repository-Server lohnend. Auch auf den Seiten von Freshrpms [10] finden sich lohnende Hinweise.
Beim ersten Aufruf von „yum“ lädt es die RPM Header von den Servern und speichert diese lokal in /var/cache/yum. Dieser Vorgang kann ohne weitere Folgen für das System mit dem Kommando yum list updates erzwungen werden; allerdings sind wegen der Rechtevergabe für das Caching-Verzeichnis hier Rootrechte erforderlich. Als Ausgabe des Kommandos erscheint eine Liste von aktualisierbaren Paketen im System. Ähnlich dem bereits beschriebenen „apt-get“ genügt dann der Aufruf von yum install paket.rpm für den Download, die Auflösung von Abhängigkeiten und die Installation eines neuen Pakets. Die Manpage zu „yum“ und die Homepage des Projekts [9] erläutert die zur Verfügung stehenden Optionen in kompakter Form, weshalb auf eine Wiederholung hier verzichtet wird.
Neben serverlokalisierten Repositories kann „yum“ durchaus auch lokale Verzeichnisse als Paketquellen benutzen. Hierzu genügt es, im Basisverzeichnis der Sammlung von RPM Paketen mit dem Kommando yum-arch . (bzw. yum-arch pfadname) den Extraktionsvorgang für die RPM Header zu starten. Die Header finden sich dann wie erwähnt im Verzeichnis headers/ wieder. In /etc/yum.conf kann dann dieses Verzeichnis wie in Listing 1 gezeigt eingebunden werden. Ebenso einfach ist es auch, dieses Repository netzwerkweit bereitzustellen. Das Verzeichnis muss lediglich z.B. durch einen passenden Eintrag in der Apache-Konfiguration als Dokumentenquelle für den Webserver bekanntgemacht werden. Das funktioniert auf einem Server im lokalen Netz genauso wie auf angemietetem Webspace- für eigene Entwicklungen ein eleganter Weg der Publikation.
Mandrake URPM
URPM ist ähnlich wie der Yellow Dog Updater ein distributionsspezifisches Tool, das bisher nur unter Linux Mandrake zum Einsatz kommt. Es setzt ausschliesslich auf RPM auf und dient im wesentlichen zum automatischen Auflösen von Abhängigkeiten zwischen Paketen. Dazu verwendet URPM eine lokale Liste mit Headerinformationen der RPM Pakete, die von der jeweiligen Paketlokation (Datenträger, Serversysteme, lokale Verzeichnisse), im URPM-Jargon Sources genannt bereitgestellt werden muss. In der Regel liegt diese Liste als komprimierte Datei Mandrake/RPMS/synthesis.hdlist.cz auf einer CDROM oder einem FTP Server. Für die zum Zeitpunkt der Drucklegung aktuelle Mandrake-Version 10.0 ist diese Datei nur 263 kBytes gross.Das URPM Paket besteht aus einer Reihe von Kommandozeilen-Programmen, die jeweils einem bestimmten Zweck bei der Paketverwaltung dienen. Zur Installation neuer Pakete dient das Programm „urpmi“. Der Aufruf urpmi paket.rpm ermittelt zunächst, ob das gewünschte Paket in den angemeldeten Sources verfügbar ist. Ist dies der Fall, werden die Abhängigkeiten des Pakets aufgelöst, die benötigten Pakete beschafft und installiert. Verwendet man hier nicht die Option –auto beim Aufruf von „urpmi“, fragt das Tool beim Administrator nach, ob wirklich die ermittelten Pakte installiert werden sollen. Je nach Paketquelle fordert das Tool benötigte CDROMs an oder listet mögliche Alternativen (z.B. mehrere Server) für Installationsquellen auf.
Auf ähnliche Weise kann auch das Update aller installierten Pakete geschehen; urpmi –auto-select –auto –update sucht alle aktualisieren Versionen der installierten Pakete von den Sources zusammen und installiert diese ohne Nachfrage. Diese Funktion ermöglicht auch das Upgrade der gesamten Distribution. Allerdings sind hier vorher die Sources auf die Quellen der neuen Distribution einzustellen. Unter [8] findet sich eine kurze Anleitung, wie der Distributionsupgrade am besten zu bewerkstelligen ist.
Der Befehl „urpmi.addmedia“ aus dem URPM Paket fügt Paketlokationen zur lokalen „sources“ Liste hinzu und liest die Headerliste aus dieser Quelle ein. Der Befehl urpmi.addmedia gwdg ftp://ftp.gwdg.de/pub/linux/mandrake/10.0/i586/Mandrake/RPMS with . fügt der Quellliste den FTP Server der GWDG hinzu und benennt das RPM Verzeichnis auf diesem Server als Quelle für die Datei synthesis.hdlist.cz. CDROMs oder lokale Verzeichnisse mit RPM Paketen sind in ähnlicher Weise in die Paketverwaltung zu integrieren. Auserdem ist es sinnvoll, mit dem Befehl urpmi.update gwdg die Paketliste des og. Servers regelmässig zu aktualisieren, um bei Änderungen auf den neusten Stand zu kommen. Für CDROMs und DVDs ist dies natürlich nicht erforderlich.
Alle Daten aus hinzugefügten Sources sind unterhalb des Verzeichnisse /var/lib/urpmi abgelegt. In den mit „list“ beginnenden Dateien sind die Lokationen der Sources gespeichert, „synthesis“ Dateien enthalten die Headerinformationen usw. Ein manueller Eingriff ist hier nicht erforderlich, da URPM für alle Manipulationen entsprechende Befehle bereitstellt. Einzig im Fehlerfall kann es nötig werden, in diesem Verzeichnis zu arbeiten. Es lohnt sich eher, regelmässig den Inhalt des Verzeichnisses /var/cache/urpmi zu prüfen. Hier landen nämlich alle von Servern heruntergeladene Pakete. Gerade bei grossen Dateien kann sich die Sicherung dieser auf eine CDR lohnen, um ggf. nicht erneut einen bandbreitenhungrigen Download zu starten.
Novell Suse YaST
YaST („Yet another setup tool“) ist seit 1994 das Administrationstool von Suse Linux, das damals noch statt einer Versionsnummer das Erscheinungsdatum auf dem CD-Cover trug und von der S.u.S.E GmbH in Fürth bereitgestellt wurde. Im Gegensatz zu den bisher vorgestellten Tools ist das aktuelle YaST2 heute mehr eine Middleware zur Linux Systemadminstration als ein Paketmanagementtool. Es gräbt sich mittels verschachtelter Startscripts und Konfigurationsdateien tief in den Bootmechanismus und die Konfiguration von Daemons ein und erhebt den Anspruch, durch GUI-Elemente die Linuxadminstration besonders anfängerfreundlich zu gestalten. Ob dies dem Tool gelingt, ist immer wieder Gegenstand hitziger Diskussionen in der Linux-Szene. Hier sollen diese Streitereien nicht interessieren, vielmehr sei der Wert von YaST2 bei der Paketverwaltung hinterfragt.In jedem Fall bemerkenswert ist die Tatsache, daß ein automatisches Auflösen von Abhängigkeiten zwischen Paketen bei YaST2 und Suse Linux schon von je her und sogar vor Einführung von RPM als Paketformat zum guten Ton gehörte. Anfangs beschränkte sich diese Fähigkeit auf den Umgang mit Paketen der distributionseigenen Datenträger. Heute vermag YaST2 auch Internetressourcen, eigene CDROMs und Verzeichnisse zu integrieren.
Webmin
Webmin ist ein beliebtes, webbasiertes Tool zur Administration nicht nur für Linux, sondern für nahezu alle unixoiden Systeme, MacOS X eingeschlossen. Neben vielen anderen hilfreichen Modulen verfügt es auch über Funktionen für das Paketmanagement. Eigentlich ist dieses Modul eher spartanisch ausgestattet. Es bietet gerade einmal die Basisfunktionen für die Installation und das Upgrade von Paketen.Dennoch hat es seinen Reiz, denn es stellt hier für den Reigen der Paketformate der UNIX Welt eine einheitliche Oberfläche bereit. Free- und OpenBSD- Pakete, System-V Pakete, HP-UX Softwaredepots, Debian-, Redhat- und Slackwarepakete können mit einer konsistenten Oberfläche installiert werden. In einer Baumansicht sind alle installierten Pakete inklusive ihrer Paketbeschreibungen einsehbar. Die Installation neuer Pakete kann entweder von einer Datei auf der jeweiligen Maschine oder von einem FTP-oder HTTP Server ausgehen. Auch der Upload einer Datei per HTTP ist möglich. Spezielle Optionen einzelner Paketformate sind dabei in der Regel leider nicht zugänglich, hier verlangt die Universalität einige Abstriche. Je nach verwendetem Paketmanager stellt Webmin einige Zusatzfunktionen bereit, so ist z.B. der Zugriff auf APT Repositories und die Durchführung eines Systemupgrades mit apt-get möglich.
Links zum Thema