\documentclass[a4paper,11pt]{article} \usepackage{ngerman} \usepackage[latin1]{inputenc} \setlength\parskip{\medskipamount} \setlength\parindent{0pt} \begin{document} % Software_Installation % Copyright Oliver Boehm, Mirko Zeibig % Lizenz: GFDL % % $Name: $ % $Revision: 1.2.2.8 $ % $Source: /cvsroot/selflinux/tutorial/adminbasics/installation/software_basic/software_installation/software_installation,v $ % SelfLinux-0.7.2 % % Diese Datei ist Teil von SelfLinux http://www.selflinux.de % %%% $Id: software_installation,v 1.2.2.8 2003/03/01 07:42:52 fboerner Exp $ \title{Software-Installation} \author{Oliver Boehm} %\url{mailto:boehm@2xp.de} \author{Mirko Zeibig} %\url{mailto:mirko-lists@zeibig.net} \maketitle %\ref{../index.tex} %\ref{adminbasics1.tex} Elementare Systemverwaltung \ref{Software_Installation} \par{Layout} Matthias Hagedorn %\url{mailto:herbert-kw@t-online.de} \par{Lizenz} GFDL \tableofcontents{} \section{Installieren und Deinstallieren von Software} \label{d29e60} \par Leider gibt es noch kein einheitliches Installations-Verfahren unter Linux, aber mit dem {\bf RPM} (Redhat Package Manager}-Format von RedHat hat sich mittlerweile ein Format durchgesetzt, das auch von anderen Distributoren verwendet wird. Daneben gibt es noch andere Formate und Verfahren, von denen die Gebräuchlichsten hier vorgestellt werden. \par Eines kennzeichnet aber sämtliche Installationsverfahren: kein Reboot nach erfolgter Installation. Sämtliche Tools können sofort gestartet werden, evtl. ist das Starten eines Dienstes (Unix-Jargon: Daemon) nötig, was von der Kommandozeile aus erfolgt. \section{Linux-Distributoren} \label{d29e80} \par Die meisten Linux-Distributionen sind recht umfangreich und enthalten bereits die nötigen Tools und Programme, die bei der Grund-Installation ausgewählt wurden. Will man später das eine oder andere Programm nachträglich installieren, kann dies mit den Distributions-eigenen Werkzeugen erfolgen. Auch die Deinstallation ist über diesen Weg möglich. Voraussetzung dafür ist, dass das gewünschte Programm im Distributions-Umfang mit dabei ist. \par Leider liegen manche Programme nicht in der neuesten Version vor, andere Programme fehlen, weil beispielsweise die Lizenz des Herstellers nicht mit der Distribution vereinbar ist. Dann muss man sich selbst darum kümmern, an die aktuelle Version des gewünschten Paketes zu kommen, um diese auf dem Rechner installieren zu können. \section{RPM} \label{d29e97} \par Das {\bf RPM}-Format, das von RedHat für ihre Distribution entwickelt wurde, enthält zusammen mit einigen Verwaltungsdaten das compilierte Programm-Paket. Erkennbar sind {\bf RPM}-Dateien an der Endung {\bf .rpm}, wobei zusätzlich die Architektur (z. B. {\bf i386} oder {\bf alpha}) im Namen der Datei enthalten ist. So kennzeichnet \par {\bf kaffe-1.0.6-2.i386.rpm} \par das Kaffe-Paket für die Intel386-Architektur. Pakete, die nicht an eine bestimmte Architektur gebunden sind (z. B. manche Java-Pakete) erhalten die Endung {\bf .noarch.rpm}. Handelt es sich um ein Paket in Source-Form, so wird dies durch {\bf .src.rpm} gekennzeichnet. \par Folgende Eigenschaften kennzeichnen das {\bf RPM}-Format: \begin{list}{*}{} \item Prüfung, ob die Voraussetzung für ein Paket vorhanden ist \item lokale Installation \item Installation per FTP möglich \item Deinstallation \end{list} \par Wer über {\bf FTP} installieren will, kann als Paket-Name eine {\bf URL} angeben, z. B. \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rpm -ih ftp://ftp.redhat.com/pub/redhat/i386/RedHat/RPMS/kaffe-1.0.6-2.i386.rpm \end{scriptsize} \end{tt} \linebreak \par Das Schöne an der Installation per {\bf FTP} ist, dass die Abhängigkeiten vor der eigentlichen Installation überprüft werden, d. h. das restliche Paket wird erst heruntergeladen, wenn die Abhängigkeiten erfüllt sind. Dazu teilt sich der eigentliche Installations-Vorgang in drei Phasen auf: \newcounter{d6e182} \begin{list}{\arabic{d6e182}} {\usecounter{d6e182}} \item das Pre-Install-Skript wird ausgeführt (falls vorhanden) \item das eigentliche Archiv wird ausgepackt und in das Dateisystem kopiert \item das Post-Install-Skript wird ausgeführt (falls vorhanden) \end{list} \par Ein ähnliches Schema wird bei der Deinstallation angewandt, auch hier gibt es häufig ein {\bf Pre-Uninstall}- und {\bf Post-Uninstall-Skript}. \par Andere Distributoren, wie z. B. SuSE oder Mandrake, sind mittlerweile auch auf den {\bf RPM}-Zug aufgesprungen, so dass dieses Format recht häufig im Internet anzutreffen ist. Allerdings kann man nicht einfach ein SuSE {\bf rpm} unter Mandrake installieren oder umgekehrt, da die Pakete von den verschiedenen Distributoren teilweise unterschiedlich zusammengebaut werden. \par Mit {\bf rpm} kann man Pakete einzeln, aber auch mehrere auf einmal installieren, erneuern oder entfernen. Sind Pakete dabei, die voneinander abhängig sind, sortiert sie {\bf rpm} in der richtigen Reihenfolge für die Installation. Dies bedeutet eine erhebliche Erleichterung für den Administrator, da er sich keine Gedanken darüber zu machen braucht, welche Pakete er zuerst installieren muss -- er gibt einfach alle in Frage kommenden Pakete an. %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Kommando \end{minipage} & \begin{minipage}{60mm} Kurzbeschreibung \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf rpm -ih x.rpm} \end{minipage} & \begin{minipage}{60mm} {\bf Installation}; \linebreak die Option {\bf -h} (oder auch {\bf -vh}) gibt zusätzlich noch einen Fortschrittsbalken aus \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf rpm -U x.rpm} \end{minipage} & \begin{minipage}{60mm} {\bf Update}; \linebreak werden Konfigurationsdaten verändert, werden sie vorher unter der Endung {\bf .rpmsave} gesichert. \linebreak Alternativ wird die neue Version einer Konfigurationsdatei mit der Endung {\bf .rpmnew} angelegt. \linebreak Während des Updates macht der RedHat Package Manager auf diese Aktionen aufmerksam. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf rpm -qa} \end{minipage} & \begin{minipage}{60mm} {\bf Query} -- Abfrage aller Pakete; \linebreak ohne die Option {\bf -a} kann man gezielt nach einem Paket nachfragen (z.B. {\bf rpm -q fileutils}) \linebreak Hilfreich ist auch die Option {\bf -f}, mit der man abfragen kann, zu welchem Paket eine Datei (z. B. {\bf /bin/ls}) gehört. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf rpm -e x.rpm} \end{minipage} & \begin{minipage}{60mm} {\bf Erase} -- zum Deinstallieren eines Paketes \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf rmp -V x} \end{minipage} & \begin{minipage}{60mm} {\bf Verify} -- ist das Paket noch ordnungsgemäß installiert oder hat da etwa jemand dran manipuliert? \end{minipage} \\ \hline \end{tabular} \par Die Manual-Page von {\bf rpm} ist recht umfangreich, entsprechend dem Umfang dieses Kommandos. In der Tabelle sind deswegen nur die wichtigsten Befehle aufgelistet, um einen schnellen Einstieg zu ermöglichen. Tiefergehende Information sind über {\bf man rpm} abrufbar. Eine sehr ausführliche Beschreibung der Möglichkeiten von {\bf rpm} findet sich unter http://www.rpm.org/max-rpm/. \subsection{Kompilieren von Source-RPMs} \label{d29e375} \par Hat man ein Paket nur in Source-Form vorliegen ({\bf xxx.src.rpm}), ist die Option {\bf --rebuild} ganz hilfreich. Sie sorgt dafür, dass das Paket nach dem Auspacken auch gleich kompiliert wird. Während hierfür bei {\bf RPM}-Versionen bis 4.0.X auch der Befehl {\bf rpm} zuständig ist, gibt es seit der Version 4.1 den Befehl {\bf rpmbuild}. \par Das Kompilieren eines {\bf Source-RPMs} auf dem eigenen Rechner hat auch den Vorteil, dass die Programme auf jeden Fall zu den installierten Bibliotheken passen. \par Generell ist es empfehlenswert, diesen Kompilationsvorgang nicht als Benutzer {\bf root} durchzuführen. Um als normaler Benutzer einen {\bf rebuild} durchzuführen, muß als erstes eine Datei {\bf .rpmmacros} im Homeverzeichnis angelegt werden: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ cat \~{}/.rpmmacros \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} %\_topdir /tmp/mirko-redhat\end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} \linebreak user@linux \~{}/ \$ \end{scriptsize} \end{tt} \linebreak \par Nun müssen noch einige Verzeichnisse angelegt werden: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/SPECS \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/BUILD \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/SOURCES \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/RPMS \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/RPMS/i386 \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/RPMS/i686 \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/RPMS/noarch \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir /tmp/mirko-redhat/SRPMS \end{scriptsize} \end{tt} \linebreak \par oder in einem Einzeiler: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ mkdir -p /tmp/mirko-redhat/{RPMS/i386,RPMS/noarch,BUILD,SOURCES,SPECS,SRPMS} \end{scriptsize} \end{tt} \linebreak \par Jetzt kann man ein vorhandenes {\bf Source-RPM} einfach wie folgt kompilieren: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rpm --rebuild mod\_auth\_pam-1.0a-1.src.rpm \end{scriptsize} \end{tt} \linebreak \par oder aber bei {\bf RPM}-Versionen ab 4.1: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rpmbuild --rebuild mod\_auth\_pam-1.0a-1.src.rpm \end{scriptsize} \end{tt} \linebreak \par Nach Ausführen des Befehls wird der Kompilationsvorgang durchgeführt: \begin{list}{*}{} \item Die unter SOURCES abgelegten Quellen werden unterhalb von BUILD ausgepackt. \item Eventuell vorhandene Patches (Quelltext-Änderungen, die der Fehlerkorrektur oder dem Anpassen an das System dienen) verändern den Quelltext. \item Dann wird meistens automatisch der unter Die klassische Installation beschriebene Ablauf aus {\bf ./configure}, {\bf make}, {\bf make install} ausgeführt. Allerdings werden die Dateien hierbei temporär unter {\bf /var/tmp/PAKET-root} installiert, da man als normaler Benutzer ja keine Zugriffsrechte auf die Standardverzeichnisse {\bf /usr}, {\bf /etc} usw. hat. \item Nun werden noch automatisch eventuell auftretende Abhängigkeiten aufgelöst. \item Die dem Programm zugehörigen Dateien werden komprimiert und in einem {\bf RPM} zusammengefasst. \end{list} \par Am Ende findet sich dann unter {\bf RPMS/i386} das fertige {\bf RPM}-Paket, welches man dann als {\bf root} installieren kann. \subsection{Anfragen der RPM-Datenbank} \label{d29e554} \par Neben den eigentlichen Programm- oder Source-Dateien, die gepackt vorliegen, enthalten {\bf RPM}-Dateien zusätzliche Informationen, welche bei der Installation in einer Datenbank gespeichert werden. So umfasst ein {\bf RPM} zusätzlich eine kurze Beschreibung des Programmes, den Installationszeitpunkt, die Zeit zu dem es kompiliert wurde, eine Auflistung aller dem Programm zugehörigen Dateien nebst Informationen über die Größe dieser Dateien und einen {\bf MD5-Hash}, durch den sich nachträglich überprüfen lässt, ob die Dateien geändert wurden. \par Auch sind in einem {\bf RPM} die Abhängigkeiten von anderen Bibliotheken abgespeichert, so dass das Aufspielen einer neuen, inkompatiblen Bibliotheksversion durch den RedHat Package Manager verhindert wird. Außerdem lassen sich in einer {\bf RPM}-Datei Skripte unterbringen, die vor bzw. nach der Installation bzw. Deinstallation eines Programmes automatisch ausgeführt werden. Diese können dann z.B. einen Dienst automatisch als zu startendes Programm eintragen oder einen neuen Benutzer hinzufügen (bei Datenbanken, Web- und Mailservern gebräuchlich) bzw. diese Aktionen bei der Deinstallation rückgängig machen. \par Die in der Datenbank während der Installation eingetragenen Informationen lassen sich jederzeit abfragen (s. Tabelle) %table \begin{tabular}{|l|l|l|} \hline \begin{minipage}{60mm} Option/Argument \end{minipage} & \begin{minipage}{60mm} Bedeutung \end{minipage} & \begin{minipage}{60mm} Beispiel \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -q} query = Abfrage, \end{minipage} & \begin{minipage}{60mm} ob ein Paket installiert ist \end{minipage} & \begin{minipage}{60mm} {\bf rpm -q fileutils} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -qa} \end{minipage} & \begin{minipage}{60mm} Anzeige aller installierten Pakete \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -qf} Dateiname \end{minipage} & \begin{minipage}{60mm} zu welchem Paket gehört die Datei? \end{minipage} & \begin{minipage}{60mm} {\bf rpm -qf /bin/ls =\verb+>+ fileutils-4.1-4} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -ql} Paketname \end{minipage} & \begin{minipage}{60mm} listet alle zum Paket gehörenden Dateien \end{minipage} & \begin{minipage}{60mm} {\bf rpm -ql fileutils oder rpm -qlf /bin/ls} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -qi} Paketname \end{minipage} & \begin{minipage}{60mm} Infos zur Version, Inhaltsangabe, Installationsdatum, etc. \end{minipage} & \begin{minipage}{60mm} {\bf rpm -qi fileutils} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -qd} Paketname \end{minipage} & \begin{minipage}{60mm} zeigt nur die zum Paket gehörenden Dokumentationsdateien an \end{minipage} & \begin{minipage}{60mm} {\bf rpm -qd xinetd} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -qc} Paketname \end{minipage} & \begin{minipage}{60mm} zum Paket gehörende Konfigurationsdateien \end{minipage} & \begin{minipage}{60mm} {\bf rpm -qc xinetd} \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -q --changelog} Paketname \end{minipage} & \begin{minipage}{60mm} Anzeigen des RPM-ChangeLog, dieses muss nicht gleichbedeutend mit dem der Software sein, da die Distributoren die Sourcen oft noch patchen. \end{minipage} & \begin{minipage}{60mm} {\bf rpm -q --changelog openssl} \end{minipage} \\ \hline \end{tabular} \par Viele dieser Abfrageoptionen lassen sich auch auf noch nicht installierte RPM-Pakete anwenden, hierzu dient die Option -p: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rpm -qip /mnt/cdrom/RedHat/RPMS/pinfo-0.5-1.i386.rpm \end{scriptsize} \end{tt} \linebreak \subsection{Graphische RPM-Frontends} \label{d29e754} gnorpm, kpackage und xrpm \par Wer mit der Kommandozeile des {\bf rpm}-Kommandos auf Kriegsfuß steht oder Probleme hat, sich die wichtigsten Optionen zu behalten, hat die Auswahl zwischen mehreren graphischen Frontends, die aber nicht alle Optionen von rpm abdecken. \par {\bf kpackage} ist bei KDE dabei und unterstützt Drag \& Drop, d. h. man kann ein heruntergeladenes Paket aus dem Datei-Manager heraus in {\bf kpackage} hineinschieben und fallen lassen. Es versteht auch das Debian-Paketformat, das an der Endung {\bf .deb} erkennbar ist. \par {\bf GnoRPM} ist für Freunde des Gnome-Desktops. \par {\bf xrpm} ist ein in Python geschriebenes Frontend, das einfach zu bedienen ist und alle wichtigen Funktionen enthält. \par {\bf mc} -- der Midnight Commander ist zwar kein graphisches {\bf RPM}-Frontend, kann aber {\bf RPM}-Archive lesen und anzeigen \section{Debian Paket Format} \label{d29e829} \par Das Debian Paketformat ist detaillierter als {\bf RPM}. Debian definiert nicht nurdas Format, sondern auch die Datei-Struktur und vieles mehr. Deswegen istdas System problemloser aktualisierbar. \par Während die meisten Distributionen inzwischen auf das {\bf RPM}-Format umgestiegen sind, ist Debian seinem Paket-Format treu geblieben. Erkennbar sind diese Pakete an der Endung {\bf .deb}. Zum Auspacken dient der Debian Packager ({\bf dpkg}) oder das Kommando {\bf apt-get}. {\bf dselect} bietet ein Standard-Menü zur Paket-Installation, {\bf taskselect} ein Menue mit verschiedenen vordefinierten Paketauswahlen. z.B. {\bf x-window-system} oder {\bf mail-server}. \par Es gibt neben der Menü-gesteuerten Alternative ({\bf dselect}, {\bf ampitude}) auch graphische Frontends ({\bf gnome-apt}, {\bf kpackage}). %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Kommando \end{minipage} & \begin{minipage}{60mm} Beschreibung \end{minipage} \\ \hline \begin{minipage}{60mm} apt-get install \verb+<+paketname\verb+>+ \end{minipage} & \begin{minipage}{60mm} Paket installieren \end{minipage} \\ \hline \begin{minipage}{60mm} apt-get install \verb+<+kernel-name\verb+>+ \end{minipage} & \begin{minipage}{60mm} anderen Kernel installieren \end{minipage} \\ \hline \begin{minipage}{60mm} apt-get --purge remove \verb+<+paketname\verb+>+ \end{minipage} & \begin{minipage}{60mm} Paket löschen \end{minipage} \\ \hline \begin{minipage}{60mm} apt-get remove \verb+<+paketname\verb+>+ \end{minipage} & \begin{minipage}{60mm} Paket löschen, aber \linebreak Konfigurations-Dateien behalten \end{minipage} \\ \hline \begin{minipage}{60mm} apt-get update / upgrade \end{minipage} & \begin{minipage}{60mm} System auf den neuesten Stand bringen \end{minipage} \\ \hline \end{tabular} \par Da die Unterstützung von Debian-Paketen manchmal hinter der von {\bf RPM}-Paketen hinterherhinkt, gibt es einen Konverter ({\bf alien}), mit dem sich diese Pakete ins Debian-Format umwandeln lassen (und umgekehrt). Kritisch für eine Konvertierung sind systemnahen Paketen, da hier hierbei evtl. wichtige Informationen verloren gehen können. \par Weitere Angaben zu Debian können dem Online-Manuel (man ...) oder dem Debian GNU/Linux Anwenderhandbuch (http://www.openoffice.de/linux/buch/) entnommen werden. \section{Die klassische Installation} \label{d29e987} \par Bevor Linux auf der Bildfläche erschien, wurden Programm-Pakete in Source-Form zur Verfügung gestellt, die in komprimierte {\bf Tar}-Archive (auch als {\bf Tar-Ball} bezeichnet) verpackt wurden. Während früher hauptsächlich das Unix-eigene {\bf compress} zum Komprimieren verwendet wurde, ist es inzwischen weitgehend von {\bf gzip} verdrängt worden, das einen besseren Komprimierungs-Faktor erzielt. Vereinzelt wird auch {\bf bzip2} eingesetzt (z. B. von http://www.blackdown.org), da es noch einen Tick besser ist (vgl. Abbildung ''tar-archive.png''} -- hier wurde zum Vergleich die {\bf Tar}-Datei von tkcvs 6.4 herangezogen) Typische Komprimierung von compress, gzip und bzip2 \par %table \begin{tabular}{|l|l|l|} \hline \begin{minipage}{60mm} Endung \end{minipage} & \begin{minipage}{60mm} komprimiert mit \end{minipage} & \begin{minipage}{60mm} auspacken mit \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf .tar} \end{minipage} & \begin{minipage}{60mm} (ohne) \end{minipage} & \begin{minipage}{60mm} {\bf tar xvf} ... \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf .tar.Z} \end{minipage} & \begin{minipage}{60mm} {\bf compress} \end{minipage} & \begin{minipage}{60mm} {\bf tar Zxvf} ... \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf .tar.gz} \end{minipage} & \begin{minipage}{60mm} {\bf gzip} \end{minipage} & \begin{minipage}{60mm} {\bf tar zxvf} ... \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf .tgz} \end{minipage} & \begin{minipage}{60mm} {\bf gzip} \end{minipage} & \begin{minipage}{60mm} {\bf tar zxvf} ... \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf .tar.bz2 } \end{minipage} & \begin{minipage}{60mm} {\bf bzip2} \end{minipage} & \begin{minipage}{60mm} {\bf tar Ixvf} ... \end{minipage} \\ \hline \end{tabular} \par Das {\bf GNU-tar-Kommando}, das üblicherweise bei allen Linux-Distributionen verwendet wird, kann mit komprimierten {\bf Tar}-Archiven umgehen (s. Tabelle). Andere Unix-Systeme (z. B. SunOS) verwenden eine andere {\bf Tar}-Implementierung. Hier muss man zuerst das Archiv dekomprimieren (mit {\bf uncompress}, {\bf gunzip} oder {\bf bunzip2}), ehe man die {\bf Tar}-Datei auspacken kann. \par Vereinzelt findet man auch im Linux-Bereich {\bf Zip}-Archive vor, erkennbar an der Endung {\bf .zip}. Diese werden mit {\bf unzip} ausgepackt. \par Nachdem das {\bf Tar}-Archiv erfolgreich ausgepackt ist, sollte man nach einer Datei {\bf README} oder {\bf INSTALL} Ausschau halten. Dort steht beschrieben, wie das Paket übersetzt und installiert wird. Unabhängig von der Plattform und Distribution sind es meist folgende Schritte, die ausgeführt werden: \newcounter{d6e1196} \begin{list}{\arabic{d6e1196}} {\usecounter{d6e1196}} \item {\bf ./configure} oder {\bf make config} \linebreak Im ersten Schritt wird untersucht, um was für ein System (Linux, Unix, ...) es sich handelt, welche Bibliotheken vorhanden sind und ob die zur Kompilierung benötigten Tools wie C-Compiler ({\bf gcc}) oder Linker ({\bf ld}) installiert sind, um daraus ein {\bf Makefile} zu generieren. \item {\bf make} \linebreak Mit Hilfe des {\bf Makefiles}, das im ersten Schritt erzeugt wurde, wird das Paket übersetzt. \item {\bf make test} (optional) \linebreak Mit diesem Schritt wird überprüft, ob die Kompilation erfolgreich war. \item {\bf make install} \linebreak Damit wird das Paket installiert. \end{list} \par Hilfreich bei der Übersetzung ist die Option {\bf -n} des {\bf make}-Kommandos. Damit kann man make erst einmal trocken ausführen, um zu sehen, welche Kommandos alle ausgeführt werden und in welches Verzeichnis welche Dateien kopiert werden, um nötigenfalls das Makefile noch anpassen zu können. \par Auch wenn dieses Verfahren meist problemlos funktioniert, hat die Sache einen Haken: an die Deinstallation hat der Autor meistens nicht gedacht, d. h. ein {\bf make uninstall} wird in den wenigsten Fällen klappen. Und so bleiben die installierten Dateien bis in alle Ewigkeit im System, es sei denn, man hat sich bei der Installation gemerkt, welche Dateien wohin kopiert wurden und löscht sie manuell. \par Weitere Nachteile der manuellen Installation: \begin{list}{*}{} \item Auf dem Zielsystem müssen alle Werkzeuge (Compiler, Linker, Make etc.), Bibliotheken und Headerdateien zum Kompilieren des Programmes vorhanden sein. \item Bei der Installation einer neueren Version eines Programmes ({\bf Update}) werden evtl. die bereits vorhandenen, an das System angepassten Konfigurationsdateien der alten Version überschrieben. \end{list} \section{Perl-Archive} \label{d29e1279} \par Für {\bf Perl}-Module gibt es als zentrale Anlaufstelle den {\bf CPAN-Server} (Comprehensive Perl Archive Network, http://cpan.org), über den fast alle {\bf Perl}-Module bezogen und direkt installiert werden können. \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ perl -MCPAN -e 'install Data::JavaScript' \end{scriptsize} \end{tt} \linebreak \par Mit diesem Aufruf wird das {\bf Data::JavaScript}-Modul installiert. Beim ersten Mal muss man evtl. noch die automatische Installation konfigurieren. Dazu wird man interaktiv durch verschiedene Fragen durchgelotst (z. B. wo das {\bf $\backslash$cmd{gzip}}- und {\bf $\backslash$cmd{tar}}-Kommando liegt, {\bf $\backslash$dots}). \par Danach geht es mit der eigentlichen Installation los, bei der das angegebene Modul von einem {\bf CPAN}-Server heruntergeladen, ausgepackt, getestet und installiert wird. War alles erfolgreich, sollte am Ende ein \begin{tt} \begin{scriptsize} \verb+ +/usr/bin/make install\verb+ +-- OK\end{scriptsize} \end{tt} \linebreak \par zu sehen sein. Falls nicht, kann es evtl. daran liegen, dass das angegebene Modul noch von weiteren Modulen abhängt, die nicht auf dem System vorhanden sind. In diesem Fall sollte man zuerst diese Module noch installieren. \section{Selbstauspackende Archive} \label{d29e1335} \par In seltenen Fällen kommen auch Shell-Skripte zum Einsatz, die sich nach dem Aufruf selbst auspacken. Eventuell muss man vorher noch einige Fragen zur Installation beantworten. Meistens heißt das Skript {\bf install.sh} und wird mit \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ ./install.sh \end{scriptsize} \end{tt} \linebreak \par oder \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ sh install.sh \end{scriptsize} \end{tt} \linebreak \par aufgerufen. Lässt sich das Skript nicht ausführen, empfiehlt es sich, die erste Zeile zu überprüfen. Sie sollte ein \begin{tabular}{|l|} \hline \begin{tt} Ausgabe nach der Eingabe von install.sh \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #!/bin/sh \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par enthalten, was leider nicht immer der Fall ist. \section{Software-Archive} \label{d29e1379} \par Linux ist Allgemeingut, dessen Bestandteile im Internet verstreut sind. Da es niemanden gehört, gibt es auch keine zentralen Stellen, die die ganzen Sourcen verwalten. Es gibt allerdings einige Anlaufstellen, von denen wir hier eine ganz kleine Auswahl präsentieren möchten (ohne Wertung): \begin{list}{*}{} \item Sunsite \linebreak Unter http://sunsite.unc.edu/pub finden sich neben GNU-Projekten auch andere OpenSource-Projekte und über 55 GB an Linux-Software und -Dokumentationen. \item Rpmfind \linebreak http://rpmfind.net/linux/RPM ist ein riesiger Katalog von RPM-Archiven. Was man hier nicht findet, ist vermutlich auch nicht als RPM-Paket erhältlich. \end{list} \par Daneben gibt es natürlich noch die einzelnen Distributionen, die auch als Ausgangspunkt dienen können. \ref{inhalt.tex} \end{document}