Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage Online-Version Copyright © 2000 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser zur Installation & Konfiguration oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Neue Software einspielen

Linux ist ein Ziel, das sich sehr schnell bewegt. Aufgrund der kooperativen Entstehungsweise dieses Projekts erscheint ständig neue Software, und Programme werden immer wieder durch neuere Versionen ersetzt. Dies gilt insbesondere für den Linux-Kernel, an dem viele Gruppen von Programmierern mitarbeiten. Es ist durchaus nicht ungewöhnlich, daß in der Entwicklungsphase jede Nacht ein neuer Kernel-Patch erscheint. Obwohl andere Teile des Systems nicht ganz so dynamisch sind, gilt das eben Gesagte im Prinzip auch hier.

Wie kann man sicher sein, daß man immer die aktuelle Version der Systemsoftware benutzt? Die einfache Antwort lautet: gar nicht. Sicherlich gibt es Leute dort draußen, für die es wichtig ist, daß sie zum Beispiel einmal täglich die neueste Version eines Kernel-Patches einspielen, aber für die meisten von uns besteht kein Grund, das System so oft auf den aktuellen Stand zu bringen. In diesem Abschnitt wollen wir die Frage behandeln, warum und wann man »updaten« sollte, und wir werden Ihnen zeigen, wie Sie wichtige Teile des Systems auf dem aktuellen Stand halten.

Wann sollte man ein Update vornehmen? Allgemein gesagt, sollten Sie nur dann »updaten«, wenn Sie erwiesenermaßen einen Bedarf dafür festgestellt haben. Wenn Sie zum Beispiel von der neuen Version eines Programms hören, in der gravierende Fehler beseitigt sind (das heißt Fehler, die Auswirkungen auf Ihre Arbeit mit diesem Programm haben), könnte das ein Grund sein, die neue Version zu besorgen. Wenn die aktuelle Version eines Programms Bestandteile enthält, die für Sie von Nutzen sein könnten, oder wenn sie wesentlich schneller läuft als Ihre jetzige Version, ist es ebenso angebracht, auf die neue Version umzusteigen. Wenn Ihr Rechner auf irgendeine Art mit dem Internet verbunden ist, sind auch kürzlich behobene Sicherheitslöcher ein guter Grund für ein Update. Dagegen ist es wahrscheinlich keine allzu gute Idee, ein Update vorzunehmen, nur um die neueste Version eines bestimmten Programms zu haben.

Ein Update kann eine schmerzvolle Angelegenheit werden. Das gilt zum Beispiel dann, wenn Sie neben dem Update des Programms auch die neueste Version des Compilers, der Libraries und noch andere Software benötigen. In dem Fall müssen Sie weitere Teile des Systems erneuern, bevor Sie die neue Programmversion installieren können, was eventuell erhebliche Zeit in Anspruch nimmt. Andererseits kann man dies auch als ein Argument dafür betrachten, daß die Software auf dem neuesten Stand gehalten werden sollte - wenn Compiler und Libraries aktuell sind, wird es kein Problem sein, das betreffende Programm auf den aktuellen Stand zu bringen.

Ohne einen Zugang zum Usenet oder Internet bleiben Sie am besten auf dem aktuellen Stand der Dinge, indem Sie ein CD-ROM-Abonnement bestellen. Auf diese Weise bekommen Sie etwa alle zwei Monate eine aktuelle Kopie der verschiedenen Linux-FTP-Server auf CD-ROM. Diesen Service bieten einige Linux-Händler an. Ein solches Abonnement ist selbst dann eine gute Idee, wenn Sie über einen Zugang zum Internet verfügen.

Damit sind wir bei einem anderen Thema - welches ist die beste Update-Methode? Manche Leute sind der Meinung, daß es einfacher ist, das System komplett neu zu installieren, wenn eine neue Version ihrer Lieblingsdistribution erscheint (zum Beispiel Slackware). Dann muß man sich keine Gedanken darüber machen, ob die verschiedenen Versionen der Software miteinander funktionieren. Dies mag für Leute ohne Zugang zum Internet richtig sein - wenn Sie nur alle zwei Monate eine neue CD-ROM beziehen, kann ein großer Teil der Software bereits wieder veraltet sein.

Wir sind allerdings der Meinung, daß eine komplette Neuinstallation keine sinnvolle Art des Updates ist. Die meisten der aktuellen Linux-Distributionen sind nicht für diese Methode der Systemaktualisierung gedacht, und die Neuinstallation kann eine sehr komplizierte oder zeitaufwendige Angelegenheit sein. Außerdem verlieren Sie bei dieser Art des Updates in der Regel alle Änderungen und Anpassungen, die Sie am System bereits vorgenommen haben. Bedenken Sie auch, daß Sie die Home-Verzeichnisse der Benutzer sowie andere wichtige Dateien sichern müssen, die sonst während der Neuinstallation verlorengehen würden. Viele Neulinge entscheiden sich für diese Methode des Updates, weil es die einfachste ist. Tatsächlich ändert sich aber von einer Version zur nächsten nicht viel, so daß eine komplette Neuinstallation nicht notwendig ist und vermieden werden kann, wenn man sich ein gewisses Know-how zum Thema Update aneignet.

Wir wollen Ihnen in diesem Abschnitt zeigen, wie Sie verschiedene Teile Ihres Systems einzeln aktualisieren können. Wir werden besprechen, wie die Systembibliotheken und Compiler auf den neuesten Stand gebracht werden, und wir wollen auf eine angemessene Methode für die Installation neuer Software eingehen. Im folgenden Abschnitt werden wir besprechen, wie Sie einen neuen Kernel erzeugen können.

Die Bibliotheken aktualisieren

Die meisten der Programme auf einem Linux-System sind so kompiliert, daß sie Shared Libraries benutzen. Diese Bibliotheken enthalten nützliche Funktionen, die in vielen Programmen benötigt werden. Statt in jedem Programm, das solche Funktionen aufruft, eine Kopie davon zu speichern, stehen diese Funktionen in Systembibliotheken, auf die alle Programme zur Laufzeit zugreifen können. Das bedeutet, daß bei der Abarbeitung eines Programms zunächst der Programmcode selbst gelesen wird und dann die entsprechenden Routinen aus den Shared Libraries. Dadurch läßt sich eine Menge Speicherplatz sparen, weil nur eine Kopie der Library-Routinen auf der Festplatte gespeichert werden muß.

Manchmal ist es notwendig, Programme mit ihrer eigenen Kopie der Library-Routinen zu kompilieren, statt die Routinen aus den Shared Libraries zu benutzen (zum Beispiel beim Debuggen eines Programms). Man sagt dann, daß solche Programme statisch gelinkt sind, während Programme, die die Shared Libraries benutzen, dynamisch gelinkt sind.

Dynamisch gebundene Programme sind also darauf angewiesen, daß die Shared Libraries sich auf der Festplatte befinden. Shared Libraries sind so geschrieben, daß die Programme, die diese Bibliotheken benutzen, in der Regel nicht auf eine bestimmte Library-Version angewiesen sind. Das bedeutet, daß Sie Ihre Libraries aktualisieren können, und die Programme, die auf diese Libraries zugreifen, werden dann automatisch die neuen Routinen benutzen. (Es gibt eine Ausnahme: Wenn eine Bibliothek grundlegend verändert wird, arbeiten die alten Programme nicht mit der neuen Version zusammen. Sie erkennen das daran, daß sich die Versionsnummer vor dem Punkt geändert hat - mehr dazu erfahren Sie weiter unten. In einem solchen Fall müssen Sie die alten und die neuen Bibliotheken auf der Festplatte behalten. Alte Programme werden auf die alten Routinen zugreifen, neue Programme benutzen die neuen Routinen.)

Wenn Sie ein Programm mit Shared Libraries kompilieren, wird dem ausführbaren Programm Code hinzugefügt, der beim Start des Programms den dynamischen Linker ld.so aufruft. ld.so sucht die benötigten Shared Libraries und lädt die Routinen in den Arbeitsspeicher. Dynamisch gebundene Programme enthalten auch sogenannte »Stub«-Routinen, die im ausführbaren Programm als Platzhalter für die eigentlichen Routinen aus den Shared Libraries dienen. ld.so ersetzt bei der Ausführung des Programms diese Stubs (etwa: Stummel) durch den Library-Code.

Mit dem Befehl ldd können Sie die Shared Libraries anzeigen lassen, die ein bestimmtes Programm benötigt. Ein Beispiel:

rutabaga% ldd /usr/bin/X11/xterm 
        libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6.0 
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6.0 
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6.0 
        libc.so.5 => /lib/libc.so.5.0.9



   

Wie Sie sehen, greift das Programm xterm auf die vier Shared Libraries libXaw, libXt, libX11 und libc zu. (Die ersten drei gehören zum X Window System, die letzte ist die Standardbibliothek für C.) Es werden auch die Versionsnummern der Bibliotheken angezeigt, für die dieses Programm kompiliert wurde (also die Version der benutzten Stub-Routinen), sowie die Namen der Dateien, die die Shared Libraries enthalten. Das sind diejenigen Dateien, die ld.so beim Programmstart finden wird.

Die Datei /etc/ld.so.conf enthält eine Liste der Verzeichnisse, die ld.so nach Shared Libraries durchsuchen wird. Hier ein Beispiel für eine solche Datei:

/usr/lib
/usr/local/lib
/usr/X11R6/lib



   

ld.so sucht immer in /lib und /usr/lib - egal, was in ld.so.conf steht. In der Regel gibt es keinen Grund, diese Datei zu verändern, und mit der Umgebungsvariable LD_LIBRARY_PATH können Sie diesem Suchpfad weitere Verzeichnisse hinzufügen (wenn Sie zum Beispiel Ihre eigenen Shared Libraries benutzen, die nicht systemweit in Gebrauch sein sollten). Wenn Sie doch weitere Einträge in /etc/ld.so.conf machen oder zusätzliche Bibliotheken installieren oder aktualisieren, sollten Sie auf jeden Fall den Befehl ldconfig eingeben, der den Shared-Library-Cache aus dem Inhalt von ld.so neu erstellt. Dieser Cache wird von ld.so benutzt, um zur Laufzeit die Bibliotheken schnell finden zu können, ohne tatsächlich die Verzeichnisse zu durchsuchen. In den Manpages zu ld.so und ldconfig finden Sie weitere Details hierzu.

Nachdem Sie jetzt erfahren haben, wie Shared Libraries funktionieren, wollen wir sie nun auf den neuesten Stand bringen. Die beiden Bibliotheken, die am häufigsten aktualisiert werden, sind libc (die Standard-C-Bibliothek) und libm (die Mathematik-Bibliothek). Zu jeder Shared Library gehören zwei Dateien:

bibliothek.a

Dies ist die statische Version der Bibliothek. Wenn ein Programm statisch gebunden wird, werden Routinen aus dieser Datei direkt in das ausführbare Programm kopiert, so daß das Programm seine eigene Kopie der Library-Routinen enthält.

bibliothek.so.version

Dies ist das Abbild (Image) der Shared Library. Wenn ein Programm dynamisch gebunden wird, wird für jede Routine der Bibliothek, auf die das Programm zugreift, ein Stub aus dieser Datei in das ausführbare Programm kopiert, damit ld.so die Shared Library zur Laufzeit lokalisieren kann. Bei der Ausführung des Programms kopiert ld.so die Bibliotheks-Routinen aus dieser Datei in den Arbeitsspeicher, wo sie vom Programm benutzt werden können. Für dynamisch gebundene Programme wird die Datei bibliothek.a der Bibliothek nicht benutzt.

Die meisten der Abbilder der Shared Libraries, auf die das gesamte System zugreift, nämlich bibliothek.so.version, stehen in /lib. Die Images der Shared Libraries können in einem beliebigen Verzeichnis stehen, das ld.so zur Laufzeit durchsucht - dazu gehören /lib, /usr/lib und die Dateien, die in ld.so.conf aufgeführt sind. In der Manpage zu ld.so finden Sie Details hierzu.

Wenn Sie einen Blick in /lib werfen, werden Sie etwa folgendes sehen:

lrwxrwxrwx  1 root    root      14 Oct 23 13:25 libc.so.5 -> libc.so.5.2.18
-rwxr-xr-x  1 root    root  623620 Oct 23 13:24 libc.so.5.2.18
lrwxrwxrwx  1 root    root      15 Oct 17 22:17 libvga.so.1 -> libvga.so.1.2.10 
-rwxr-xr-x  1 root    root  128004 Oct 17 22:17 libvga.so.1.2.10 



   

In diesem Fall werden die »Shared Library«-Images für zwei Bibliotheken angezeigt - libc und libvga. Beachten Sie, daß für jede Bibliothek ein symbolischer Link namens bibliothek.so.major angelegt wurde, wobei major die große Versionsnummer der Bibliothek ist. Die kleine Nummer (Minor Number) wird ausgelassen, weil ld.so nur anhand der großen Nummer nach Bibliotheken sucht. Wenn ld.so ein Programm vorfindet, das mit den Stubs der Version 5.2.18 von libc kompiliert wurde, durchsucht es seinen Suchpfad nach der Datei libc.so.5. In diesem Fall ist /lib/libc.so.5 ein symbolischer Link auf /lib/libc.so.5.2.18 - die Library-Version, die wir tatsächlich installiert haben.

Wenn Sie eine Bibliothek aktualisieren, müssen Sie die Dateien auf .a und .so.version dieser Bibliothek ersetzen. Bei den ersten ist das kein Problem: Kopieren Sie einfach die neuen Versionen darüber. Beim Image der Shared Library, .so.version, müssen Sie allerdings etwas vorsichtiger sein. Das liegt daran, daß die meisten der Programme auf dem System diesen Code benutzen, so daß man sie nicht einfach löschen oder umbenennen darf. Anders gesagt: Der symbolische Link bibliothek.so.major muß immer auf ein gültiges Library-Image verweisen. Zu diesem Zweck kopieren Sie zunächst die neue Image-Datei nach /lib und ändern dann in einem Schritt mit ln -sf den symbolischen Link so, daß er auf die neue Datei verweist. Wir werden das weiter unten vorführen.

Nehmen wir an, daß Sie von der Version 5.2.18 der libc auf die Version 5.4.47 »updaten« möchten. Sie sollten die Dateien libc.a und libc.so.5.4.47 auf Ihrem System haben. Überschreiben Sie zuerst die alte statische Bibliothek, indem Sie die neue .a-Datei an die entsprechende Stelle kopieren:

rutabaga# cp libc.a /usr/lib 



   

Kopieren Sie dann die neue Image-Datei nach /lib (oder dahin, wo das neue Library-Image stehen soll):

rutabaga# cp libc.so.5.4.47 /lib



   

Mit dem Befehl ls -l /lib/libc* sollten Sie jetzt etwa folgendes angezeigt bekommen:

lrwxrwxrwx  1 root    root         14 Oct 23 13:25 libc.so.5 -> libc.so.5.2.18
-rwxr-xr-x  1 root    root     623620 Oct 23 13:24 libc.so.5.2.18
-rwxr-xr-x  1 root    root     720310 Nov 16 11:02 libc.so.5.4.47



   

Damit der symbolische Link auf die neue Bibliothek verweist, geben Sie ein:

rutabaga# ln -sf /lib/libc.so.5.4.47 /lib/libc.so.5



   

Damit erhalten Sie:

lrwxrwxrwx  1 root  root      14 Oct 23 13:25 libc.so.5 -> /lib/libc.so.5.4.47
-rwxr-xr-x  1 root  root  623620 Oct 23 13:24 libc.so.5.2.18
-rwxr-xr-x  1 root  root  720310 Nov 16 11:02 libc.so.5.4.47



   

Es ist sicherlich keine schlechte Idee, ldconfig jedesmal aufzurufen, nachdem Sie Libraries aktualisiert oder hinzugefügt haben, damit der Library-Cache, den ld.so benutzt, neu geschrieben wird. Es kann passieren, daß ld.so eine neue Library erst erkennt, nachdem Sie ldconfig aufgerufen haben.

Die Linux-Gemeinde macht gerade den Schritt von der alten Version 5 der libc zur sogenannten glibc2, auch libc6 genannt. Im Prinzip unterscheidet sich das nicht von irgendeinem anderen inkompatiblen Bibliotheks-Update, aber in der Praxis bringt das alle möglichen Schwierigkeiten mit sich, weil das inkompatible Austauschen der C-Bibliothek jedes, aber auch jedes Programm im System betrifft. Die neue glibc2 hat zwar mehrere Vorteile - unter anderem ist sie Thread-sicher, was es sehr viel einfacher macht, Programme zu schreiben, die mehrere Dinge zur gleichen Zeit machen -, aber viele Leute halten sie noch für instabil. Außerdem können Sie Programme, die für die eine Version kompiliert worden sind, nicht mit der anderen Bibliotheksversion ausführen. Wenn Sie ein Programm benutzen wollen, zu dem Sie keinen Quellcode haben, müssen Sie die C-Bibliothek installieren, die dieses Programm benötigt. Glücklicherweise ist es möglich, beide Versionen auf einem Rechner zu installieren, wenn das auch mit einigen Schwierigkeiten verbunden ist. Diejenigen Distributionen, die bereits auf glibc2 umgestellt haben, stellen normalerweise ein installierbares Paket namens »libc5-Kompatibilität« (oder so ähnlich) bereit. Installieren Sie dieses, wenn Sie Programme ausführen wollen, die mit der alten C-Bibliothek kompiliert worden sind.

Eine Frage bleibt noch zu beantworten: Wo bekommen Sie neue Versionen der Bibliotheken? Einige der grundlegenden System-Libraries (libc, libm usw.) können Sie aus dem Verzeichnis /pub/Linux/GCC auf ftp://metalab.unc.edu auf Ihren Rechner herunterladen. Dieses Verzeichnis enthält die Linux-Version des Compilers gcc, Libraries, Include-Dateien sowie andere Utilities. Zu jeder Datei sollte eine README- oder Release-Datei gehören, die eine Installationsanweisung enthält. Andere Bibliotheken werden an anderen Orten gepflegt und archiviert. Auf jeden Fall sollte jede Library, die Sie installieren, aus den .a- und .so.version-Dateien bestehen. Außerdem gehört ein Satz Include-Dateien für den Compiler dazu.

Den Compiler aktualisieren

Bei einem weiteren Bestandteil Ihres Systems ist es sehr wichtig, daß Sie auf dem aktuellen Stand bleiben: dem C-Compiler mit den zugehörigen Utilities. Dazu gehören gcc (der GNU-Compiler selbst für C und C++), der Linker, der Assembler, der C-Präprozessor sowie verschiedene Include-Dateien und Libraries für den Compiler. Diese sind alle in der gcc-Distribution für Linux enthalten. Normalerweise wird eine neue Version des gcc zusammen mit den neuen Versionen von libc und den Include-Dateien veröffentlicht, die alle aufeinander angewiesen sind.

Sie finden die aktuelle Version von gcc für Linux auf verschiedenen FTP-Servern - unter anderem auch in /pub/Linux/GCC auf ftp://metalab.unc.edu . Aus den dazugehörigen Textdateien (Release Notes) erfahren Sie, wie Sie vorgehen müssen. In der Regel wird eine neue Version des Compilers eingespielt, indem man als root einige tar-Dateien entpackt und eventuell ein paar andere Dateien löscht. Falls Sie keinen Zugang zum Internet haben, können Sie sich den neuesten Compiler als Kopie in Form einer CD-ROM besorgen, wie wir das weiter oben beschrieben haben.

Mit dem Befehl

gcc -v



   

können Sie feststellen, welche Version von gcc Sie installiert haben. Die Anzeige sollte etwa so aussehen:

Reading specs from /usr/lib/gcc-lib/i486-linux/2.8.1/specs 
gcc version 2.8.1 



   

Beachten Sie, daß gcc selbst nur ein Steuerprogramm für den Compiler und die anderen Programmierwerkzeuge unter

/usr/lib/gcc-lib/machine/version



   

Wenn Sie Software in C++ schreiben, dann kann es sich lohnen, egcs zu installieren, eine neue Version des gcc, die sehr viel robuster ist als der gcc selbst und viele der neuen Sprachelemente von C++ unterstützt. Unglücklicherweise verwenden egcs, ältere Versionen des gcc (bis Version 2.7.2) und neuere Versionen des gcc (ab Version 2.8.0) alle verschiedene, inkompatible Objektformate, so daß Sie alle Ihre C++-Bibliotheken und -Programme neu kompilieren müssen, wenn Sie von einem Compiler auf einen anderen umsteigen. Die Free Software Foundation hat vor kurzem angekündigt, daß egcs ihr Default-Compiler wird (und damit den gcc ersetzt), so daß diese Probleme bald der Vergangenheit angehören werden.

Andere Software aktualisieren

Natürlich werden Sie gelegentlich auch andere Teile Ihres Systems auf den neuesten Stand bringen müssen. Wir haben bereits erwähnt, daß die einfachste und beste Vorgehensweise die ist, daß Sie nur dann »updaten«, wenn es wirklich notwendig ist. Warum sollten Sie beispielsweise immer die neueste Version von Emacs auf Ihrem System haben, wenn Sie das Programm gar nicht benutzen? Eigentlich besteht auch kein Grund, bei regelmäßig benutzten Anwendungen immer auf dem aktuellen Stand zu bleiben - wenn Sie mit Ihrer Version zufrieden sind, besteht kaum Veranlassung zum Update.

Wenn Sie andere Anwendungsprogramme aktualisieren möchten, müssen Sie die neueste Version der Software besorgen. In der Regel sind das mit gzip oder compress gepackte Dateien. Solche Programmpakete werden in verschiedenen Formaten verteilt; dazu gehören binäre Distributionen, bei denen der Binärcode und dazugehörige Dateien so archiviert sind, daß sie auf Ihrem System sofort entpackt werden können. Ein anderes Format enthält Quellcode (oder Teile des Quellcodes), so daß Sie einige Befehle ausführen müssen, um die Programme zu kompilieren und auf Ihrem System zu installieren.

Die Shared Libraries machen es sehr einfach, Software in Form von Binärdateien zu verteilen. Solange Sie eine Version der Libraries haben, die zu den Stubs in der Software kompatibel ist, werden Sie keine Probleme haben. Allerdings ist es oft einfacher (und vorteilhafter), ein Programm in Form von Quellcode zu verteilen. Das bietet Ihnen einerseits die Möglichkeit, den Code anzuschauen und weiterzuentwickeln; andererseits haben Sie dann die Gelegenheit, das Programm speziell für Ihr System und mit eigenen Libraries zu kompilieren. Viele Programme erlauben bei der Kompilierung die Angabe gewisser Optionen, etwa das selektive Einbinden bestimmter Programmteile in das fertige Programm. Diese Art der Anpassung ist nicht möglich, wenn Sie fertig kompilierten Binärcode erhalten.

Auch die Systemsicherheit kommt ins Spiel, wenn binäre Dateien ohne Quellcode installiert werden. Obwohl man auf Unix-Systemen kaum von Computerviren gehört hat, Fußnoten 1 ist es nicht so schwierig, ein »Trojanisches Pferd« zu entwickeln - ein Programm, das anscheinend eine nützliche Funktion ausführt, in Wirklichkeit aber Schaden im System verursacht. So könnte jemand zum Beispiel ein Programm schreiben, das als »Zugabe« alle Dateien im Home-Verzeichnis desjenigen löscht, der das Programm aufruft. Weil ein solches Programm mit den Berechtigungen des Benutzers ausgeführt wird, hat es auch die Möglichkeit, auf diese Art Schaden anzurichten. (Selbstverständlich verhindern die Sicherheitsmechanismen von Unix, daß auch an den Dateien weiterer Benutzer oder an wichtigen Systemdateien, die root gehören, Schaden entstehen kann.)

Obwohl das Installieren von Quellcode so etwas nicht unbedingt verhindern kann (lesen Sie die Quelldateien aller Programme, die Sie für Ihr System kompilieren?), haben Sie auf jeden Fall die Möglichkeit nachzuschauen, was das Programm tatsächlich tut. Ein Programmierer müßte sich einige Mühe geben, um ein solches Trojanisches Pferd zu verstecken - wenn Sie aber völlig unbedarft binären Code installieren, setzen Sie sich selbst der Gefahr aus.

Auf jeden Fall ist der Umgang mit Quellcode und binären Dateien recht einfach. Wenn das Programmpaket als tar-Datei verteilt wird, finden Sie zunächst mit tar t heraus, wie die Dateien archiviert wurden. Falls es sich um Binärdateien handelt, können Sie die Dateien wahrscheinlich von / oder /usr aus sofort entpacken. Zuvor sollten Sie alle alten Versionen des Programms sowie die dazugehörigen Dateien löschen (alle die, die nicht von der neuen tar-Datei überschrieben werden). Wenn die alte ausführbare Datei in Ihrem Suchpfad vor der neuen Version steht, werden Sie weiterhin mit dem alten Programm arbeiten, solange Sie dieses nicht entfernt haben.

Viele Distributionen verwenden ein besonderes Paketierungssystem, mit dem das Installieren und Deinstallieren von Software viel einfacher wird. Es gibt mehrere Paketierungssysteme, aber die meisten Distributionen, darunter Red Hat, SuSE und Caldera, verwenden das RPM-System, das wir im nächsten Abschnitt behandeln werden. Die Debian-Distribution verwendet ein eigenes System namens .deb, das hier nicht behandelt wird.

Der Umgang mit Quellcode ist nicht ganz so einfach. Als erstes müssen Sie die Quelldateien in einem eigenen Verzeichnis entpacken. Auf den meisten Systemen ist das /usr/src. Normalerweise brauchen Sie keine root-Berechtigung, um ein Softwarepaket zu kompilieren (aber Sie werden in der Regel als root das fertig kompilierte Programm installieren!). Deshalb ist es vielleicht eine gute Idee, mit dem Befehl

chmod 1777 /usr/src 



   

das Verzeichnis /usr/src für alle Benutzer schreibbar zu machen. Danach steht es jedem Benutzer frei, Unterverzeichnisse zu /usr/src anzulegen, um dort Dateien zu installieren. Die 1 an der ersten Stelle der Modusbits ist das »Sticky«-Bit; dieses verhindert, daß Benutzer sich gegenseitig die Unterverzeichnisse löschen.

Sie können dann ein Unterverzeichnis in /usr/src anlegen und die tar-Datei dort entpacken, oder Sie entpacken direkt von /usr/src aus, wenn das Archiv bereits ein Unterverzeichnis enthält.

Sobald die Quelldateien entpackt sind, sollten Sie als nächstes die README-Dateien und Installationshinweise lesen, die zu den Quellen gehören. Fast alle Pakete werden mit solcher Dokumentation verteilt. Grundsätzlich gehen Sie zum Kompilieren der meisten Programme wie folgt vor:

2. Editieren Sie gegebenenfalls weitere Dateien, die zum Programm gehören. Einige Anwendungen erwarten, daß Sie eine Datei namens config.h anpassen; auch dies sollte in den Installationshinweisen erwähnt werden.

3. Rufen Sie gegebenenfalls ein Konfigurationsskript auf. Ein solches Skript stellt fest, wie Ihre Systemumgebung zusammengesetzt ist - dies wird bei komplexeren Anwendungen nötig sein. Sie werden selbst herausfinden, wann Sie diesen Schritt durchführen müssen.

Um etwas konkreter zu werden: Wenn die Quellen kein Makefile im Top-Level-Verzeichnis enthalten, statt dessen aber eine Datei namens Makefile.in und eine Datei namens configure, dann ist das Paket mit dem Autoconf-System zusammengestellt worden. In diesem (immer gängigeren) Fall führen Sie das Konfigurationsskript folgendermaßen aus:

./configure



   

Das ./ am Anfang sollte verwendet werden, damit das lokale configure-Skript ausgeführt wird und nicht etwa eines, das sich zufällig im Pfad befindet. Bei manchen Paketen können Sie Optionen an configure übergeben, die bestimmte Funktionen des Pakets ein- oder ausschalten. Wenn das configure-Skript einmal ausgeführt worden ist, können Sie mit dem nächsten Schritt weitermachen.

4. Rufen Sie make auf. In der Regel werden daraufhin die notwendigen Schritte zur Kompilierung ausgeführt, wie sie im Makefile definiert sind. Oft müssen Sie make noch ein »Ziel« (target) mitgeben, etwa make all oder make install. Dies sind zwei häufig verwendete Ziele. make all wird meistens nicht benötigt, kann aber eingesetzt werden, um alle Ziele einzuschließen, die im Makefile aufgeführt sind (zum Beispiel, um alle Programme in einem Paket zu kompilieren, wenn per Voreinstellung nur eines kompiliert wird). Mit make install werden nach der Kompilierung sowohl der ausführbare Code als auch alle dazugehörigen Dateien auf dem System installiert. Aus diesem Grunde wird make install normalerweise als root aufgerufen.

Die meisten Softwarepakete enthalten neben den Quelltexten und ausführbarem Code auch Manpages und andere Dateien. Das Installationsskript (falls vorhanden) wird diese Dateien an einer geeigneten Stelle abspeichern. Die Manpages haben Namen wie foobar.1 oder foobar.man. Diese Dateien sind (meistens) nroff-Quelltexte und werden von man in ein lesbares Format gebracht. Wenn der Quelltext einer Manpage eine Ziffer als Suffix aufweist, etwa .1, sollten Sie diese Datei in das Verzeichnis /usr/man/man1 kopieren, wobei die 1 mit der Ziffer im Suffix übereinstimmt. (Diese Ziffer entspricht der Nummer des »Abschnitts« (section), in den diese Manpage gehört; für die meisten Anwenderprogramme ist das die 1.) Bei Dateien mit dem Suffix .man wird es in der Regel ausreichen, wenn Sie die Datei nach /usr/man/man1 kopieren und dabei die Erweiterung .man in .1 umbenennen.

Ein »Virus« im klassischen Sinn ist ein Programm, das sich an einen »Wirt« anhängt und dann aktiv wird, wenn das Wirtsprogramm aufgerufen wird. Auf Unix-Systemen braucht man in der Regel Root-Berechtigungen, um wirklich Schaden anzurichten. Wenn ein Programmierer aber weiß, wie er sich diese Berechtigungen verschaffen kann, wird er sich kaum noch mit einem Virus abgeben.

Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center