© Yvonne Bogdanski, 123RF.com

Die Open-Source-Welt ist für ihre Vielfalt bekannt. Da überrascht es kaum, dass sich kluge Köpfe auch für das Installieren und Aktualisieren von Software originelle Alternativen ausgedacht haben – von der Versionskontrolle für das ganze Betriebssystem bis zur Instant-Anwendung auf dem USB-Stick.

Die meisten Linux-Distributionen verwenden RPM oder Dpkg, um Software zu installieren und zu warten. Die Alternative Gentoo hat mit ihrem Quelltext-basierten System einen eigenen Weg beschritten (siehe den Beitrag in diesem Schwerpunkt). Daneben existieren aber noch weitere reizvolle Ansätze. Dieser Artikel stellt drei von ihnen vor.

Alles versioniert

Software-Entwickler pflegen ihren Quellcode in einem Versionskontrollsystem. Warum sollten Packager und Sysadmins nicht auch die Vorteile solcher Systeme nutzen, um installierte Programme und Systeme zu verwalten? Diese Überlegung steht hinter der Software Conary [1]. Erik Troan, zuvor bei Red Hat an RPM beteiligt, veröffentlichte sie erstmals 2004, inspiriert von der verteilten Versionskontrolle Mercurial. Conary steht unter der Open-Source-Lizenz CPL und dient als Basistechnologie für die Produkte der von Troan gegründeten Firma Rpath.

Das in Python umgesetzte Conary stellt das gesamte Betriebssystem unter Versionskontrolle. Auf diese Weise lassen sich nicht nur einzelne Pakete, sondern auch Gruppen, ja ganze Systemimages versionieren. So können große Anwender beispielsweise maßgeschneiderte Systeme für einen Mail- oder Webserver auf einer bestimmte Hardware auschecken.

Die unterschiedlichen Varianten eines Pakets für bestimmte Prozessorarchitekturen oder mit besonderen Compile-Optionen verwaltet Conary als so genannte Flavors (Geschmacksrichtungen). Das erspart es den Distributionsbauern, mehrere Zweige parallel zu pflegen.

Diese Technologie steckt im Systembaukasten Rbuilder, der in einer öffentlichen Instanz [2] für Open-Source-Projekte kostenlos bereitsteht. Dort entsteht auch das Conary-basierte Foresight Linux [3]. Ein kommerzieller Kunde ist EMC, der damit komplette Systeme für RSA-Datensicherheits-Appliances baut.

Auch für den Maintainer, der ausgewählte Software für eine Linux-Distribution paketiert, hat das System einiges zu bieten. Die als Recipe (Rezept) bezeichneten Dateien, die das Bauen aus den Quelltexten steuern, sind in einer Domain Specific Language (DSL) auf Python-Basis formuliert. Für viele Arten von Builds existieren fertige Superklassen, beispielsweise »AutoPackageRecipe« in Listing 1, das C-Software mit den Autotools baut. Daneben gibt es eine ganze Bibliothek solcher Klassen, unter anderem für C++-Programme, Java, Gnome-Anwendungen und CPAN-Module.

01 class Goom(AutoPackageRecipe):
02
03 name = 'goom'
04 version = '2k4_0'
05
06 buildRequires = []
07
08 def unpack(r):
09 r.macros.upstreamVersion = r.macros.version.replace('_','-')
10 r.addArchive('mirror://sourceforge/%(name)s/%(name)s-%(upstreamVersion)s-src.tar.gz')

Deep Inspection

Es fällt auf, dass das Rezept in Listing 1 keine expliziten Abhängigkeiten nennt. Deren Auflösung automatisiert Conary weitgehend. Deep Inspection nennt sich der Vorgang, bei dem Conary den Quellcode inspiziert und die benötigten Bibliotheken ermittelt. Das funktioniert unter anderem für Java, PHP und Ruby. Rpath-CTO Brett Adam bezeichnet dieses Feature als Alleinstellungsmerkmal. Es erfasse rund 90 Prozent der Abhängigkeiten, schätzt er. Der Anwender ergänzt etwaige unerkannte Abhängigkeiten in der Recipe-Datei und kann auf Wunsch die automatisch ermittelten Einstellungen manuell überschreiben.

Für alles, was sich nicht in der DSL regeln lässt, kann er zu Python greifen. In Listing 1 geschieht das in den Zeilen 9 und 10, um in dem Namen des Quelltext-Tarball einen Bindestrich zu ersetzen, der bei Conary nicht erlaubt ist.

Sparsam

Bei der Aktualisierung von installierter Software verhält sich Conary ebenfalls wie ein Versionskontrollsystem: Es überträgt lediglich ein Changeset, überspielt also nicht sämtliche Binärdateien, wenn sich nur eine Konfigurationsdatei ändert – laut Brett Adam ein großer Vorteil gegenüber RPM. Dabei lässt er allerdings außer Acht, dass Suse und Red Hat ein ähnliches Feature bieten (siehe Kasten “Delta-RPM”). Immerhin berichtet der Rpath-CTO von einem großen Kunden, der zu Conary gewechselt habe, um seine Anwendungen zur Kreditkartenabrechnung schneller und effizienter auf seinen zahlreichen und weltweit verteilen Servern zu aktualisieren.

Besagter Kunde nutze zudem ein Feature, das Conary seit rund eineinhalb Jahren bietet. Das System kann RPM-Pakete von Suse Linux Enterprise, RHEL und Centos einkapseln (Abbildung 1). So erhielt das Unternehmen eine Conary-Systemverwaltung aus einem Guss und kann dennoch weiterhin bei seiner bevorzugten Enterprise-Distribution bleiben. Die Subskriptionsverträge bleiben davon unberührt, da Conary die Original-Binärpakete des Herstellers unverändert lässt und lediglich einpackt.

Abbildung 1: Da Rpaths Paketmanager Conary fremde Binärpakete einkapseln kann, eignet er sich auch zur Verwaltung eigentlich RPM-basierter Enterprise-Distributionen wie Suse und Red Hat.

Wer Conary kennenlernen möchte, kann als Alternative zu Rpaths kommerziellen Angeboten zum freien Foresight Linux greifen, das alle erforderlichen Tools enthält. Unter [4] hat Rpath eine Community-Website eingerichtet, die zum Austausch von Recipes dient, derzeit aber nicht besonders üppig befüllt ist. Ein Artikel im “LinuxUser” [5] beschreibt die Conary-Kommandos sowie das Bauen eigener Pakete und Appliances.

Endanwender-Installation

Während Conary ganze Betriebssysteme versioniert, bedient der Zero Install Injector, kurz 0install [6], das andere Extrem: Die Software ermöglicht es Normalanwendern ohne Superuser-Rechte, einzelne Programme nach Wunsch zu installieren. Dabei ist sie distributionsneutral – ein Paket lässt sich auf allerlei Linuxen installieren, sofern dort die Zero-Install-Tools vorhanden sind.

Zero Install ist einer von mehreren Versuchen, die Software-Installation unter Linux ähnlich anwenderfreundlich zu gestalten wie unter Windows oder Mac OS X, und verwendet dabei ein übersichtliches GUI (Abbildung 2). Im Gegensatz zu eingeschlafenen Projekten wie Autopackage und Klik erfreut es sich aktiver Pflege und Entwicklung. Das Projekt möchte noch 2011 die Version 1.0 publizieren, derzeit ist 0.54 aktuell.

Abbildung 2: Zero Install legt die Software-Installation in die Hand des einfachen Anwenders.

Software-Entwickler profitieren von Zero Install, da sie ihre Programme dezentral auf der eigenen Website in einem installierbaren Format publizieren können, ohne auf die Arbeitsabläufe und Repositories der Linux-Distributionen angewiesen zu sein. Thomas Leonard, der Erfinder des Zero Install Injector, legt solche Gedanken in einem online verfügbaren Artikel dar [7]. Der Brite entwickelt das Installationssystem seit 2003 und verwendet es unter anderem für seine Desktopumgebung Rox und deren Anwendungen.

Zum Installieren eines Softwarepakets benötigt der Anwender einen Zero Install Feed. Dabei handelt es sich um eine im Web veröffentlichte XML-Datei mit Meta-Informationen zum Paket. Sie enthält unter anderem die Adresse des Installationsarchivs und den Hashwert, der das Paket identifiziert (Abbildung 3). Eine ständig aktualisierte Sammlung zahlreicher Feeds bietet [8].

Abbildung 3: Was hier als XML-Quelltext sichtbar gemacht ist, erlebt der Anwender als schlichten Weblink zum Anklicken: Die so genannten Feeds enthalten die Metadaten, die Zero Install zum Herunterladen und Einspielen von Software benötigt.

Zieht der Benutzer die Feed-Adresse aus dem Webbrowser in das Zero-Install-Fenster, starten Download und Installation. Dabei landen alle Dateien eines Pakets unterhalb von »~/.cache/0install.net/implementations/Hashwert/« im Homeverzeichnis des Anwenders. Dort findet sich für jedes installierte Programm ein Baum von Systemverzeichnissen wie auf einem ganz gewöhnlichen Unix-System (Abbildung 4).

Abbildung 4: Innerhalb eines Zero-Install-Pakets befindet sich ein Unix-Verzeichnisbaum. Bereits heruntergeladene Bibliotheken kommen bei der Installation weiterer Software erneut zur Verwendung.

Zero Install löst Abhängigkeiten automatisch auf und lädt die benötigten Dateien herunter. Befindet sich eine Bibliothek bereits im Installationsverzeichnis des Benutzers, wird sie nicht neu geladen. Daneben können optional auch verschiedene Benutzer auf einem Rechner vorhandene Bibliotheken teilen, wofür das Installationssystem diese in »/var/cache/0install.net/« bereithält.

Interessanterweise kennt Zero Install im Grunde nur das Ausführen von Programmen. Das Kommando »0launch« und seine GUI-Entsprechung führen eine Anwendung aus, wenn sie bereits installiert ist. Andernfalls lädt es die Software zur Installation herunter. Ist ein Programm bereits länger als einen Monat nicht gelaufen, sucht Zero Install automatisch nach Updates. Aktualisierungen lassen sich auch von Hand im GUI des Installationssystems veranlassen.

Dazu gesellen sich Features, die einer Softwareverwaltung gut zu Gesicht stehen: GPG-signierte Feeds stellen Herkunft und Unversehrtheit sicher. Daneben kann der Anwender Policies vorgeben, die beispielsweise nur die Installation stabiler Programmversionen erlauben. Versionen mit Sicherheitsproblemen werden in den Web-Feeds als »insecure« gebrandmarkt.

Ohne Root

Bei Zero Install kommt nicht nur der Benutzer ohne Rootrechte aus, das System verwendet auch keine Pre- oder Post-Install-Skripte, die mit den Berechtigungen des Superusers laufen. Kombiniert mit entsprechenden Policies könnte es für den Sysadmin ein Möglichkeit bieten, Anwender administrierter Rechner zusätzlich gewünschte Software installieren zu lassen – unter Umständen aus einer im lokalen Netzwerk vorgehaltenen, vertrauenswürdigen Quelle.

Software-Entwickler und Packager finden auf der 0install-Website umfangreiche Anleitungen und einige Tools, um eigene Pakete zu bauen und Feeds zu publizieren. Es gibt auch Utilities, die Zero-Install-Feeds aus Dpkg- oder RPM-Repositories generieren.

Einstecken statt installieren

Noch weiter treiben es die Portable Linux Apps [9]: Was seit Jahren unter Windows funktioniert, gibt es seit April 2010 auch unter Linux: Binärdateien auf USB-Speicher kopieren, einstecken und ausführen. Die Sammlung tragbarer Programme für den Speicherstick ist beträchtlich und reicht von Libre Office über den Videoplayer VLC bis zum Security-Tool Wireshark (Abbildung 5).

Abbildung 5: Portable Linux Apps bringt eine große Software-Auswahl auf den USB-Stick. Der Einsatz ist allerdings auf 32-Bit-Systeme beschränkt und kann an Mount-Optionen scheitern.

Ein beliebter Tipp empfiehlt, die Lieblingsanwendung in Linux- und Windows-Version auf einen USB-Stick zu spielen. So kann man unter den verschiedenen Betriebssystemen als Gast in vertrauter Umgebung arbeiten. Möchten die Programme allerdings Einstellungen oder andere Daten speichern, ist es nicht besonders schön, wenn sie auf dem fremden Rechner landen, insbesondere bei Passwörtern. Zumindest unter Linux lässt sich das mit einer auf den Stick zeigenden »HOME« -Variablen beheben, wie der “LinuxUser” [10] empfiehlt.

Hindernisse

Das alles funktioniert derzeit allerdings nur auf 32-Bit-Systemen, womit viele neuere Computer ausscheiden. Daneben funken neuere Udisks-Versionen auch noch dazwischen: Beim automatischen Mounten des eingesteckten Speichers hängen sie FAT-formatierte Sticks mit der Option »showexec« ein. Diese erlaubt nur das Ausführen von Dateien mit der Endung ».exe« ».com« oder ».bat« . Allerdings lässt sie sich auch austricksen: Ist das Executable passend umbenannt und der Stick erneut eingesteckt, funktioniert die Portable-App. Dem absurden Vorschlag aus einem Ubuntu-Forum, das Udisks-Binary mit Sed zu traktieren, sollten man auf keinen Fall folgen.