Dieses Dokument umfaßt nur die Kompilierung und Installation des Apache auf Unix und Unix-ähnlichen Systemen. Für die Kompilierung und Installation unter Windows lesen Sie bitte Den Apache unter Microsoft Windows betreiben. Für andere Plattformen lesen Sie bitte die Dokumentation Plattformen.
Die Konfigurations- und Installationsumgebung des Apache 2.0 hat sich
seit dem Apache 1.3 komplett verändert. Der Apache 1.3 benutzt einen
speziellen Satz von Skripten, um eine einfache Installation zu
ermöglichen. Der Apache 2.0 dagegen verwendet nun
libtool
und autoconf
, um eine Umgebung zu
schaffen, die der vieler anderer Open Source Projekte ähnlich
sieht.
Wenn Sie von einer Unterversion auf die nächste aktualisieren (z.B. von 2.0.50 auf 2.0.51), springen Sie bitte zum Abschnitt Upgrade.
Download | $ lynx http://httpd.apache.org/download.cgi
|
Auspacken | $ gzip -d httpd-2_1_NN.tar.gz |
Konfigurieren | $ ./configure --prefix=PREFIX
|
Kompilieren | $ make |
Installieren | $ make install |
Anpassen | $ vi PREFIX/conf/httpd.conf |
Testen | $ PREFIX/bin/apachectl start
|
NN muss durch die Nummer der Unterversion ersetzt werden,
und PREFIX durch den Verzeichnispfad,
in dem der Server installiert werden soll. Wenn PREFIX nicht
angegeben ist, wird die Voreinstellung /usr/local/apache2
verwendet.
Beginnend mit den Anforderungen für die Kompilierung und Installation des Apache HTTPD ist weiter unten jeder Abschnitt des Kompilierungs- und Installationsvorganges genauer beschrieben.
Folgende Anforderungen gelten für die Erstellung des Apache:
PATH
wesentliche Generierungswerkzeuge wie
make
enthalten.ntpdate
oder xntpd
verwendet,
die auf dem Network Time Protocol (NTP) basieren. Nähere
Informationen über NTP Software und öffentliche Zeitserver
finden Sie in der Usenet Newsgroup comp.protocols.time.ntp
und auf der NTP
Homepage.configure
'-Skript gefunden werden kann, macht das
jedoch nichts. Selbstverständlich können Sie den Apache 2.0
auch so generieren und installieren. Lediglich diese Pflegeskripte
können dann nicht verwendet werden. Wenn Sie mehrere Perl
Interpreter installiert haben (vielleicht Perl 4 durch Ihren
Händler und Perl 5 durch Sie selbst), dann ist die Verwendung der
--with-perl
Option (siehe unten) empfehlenswert, um
sicherzustellen, dass der richtige Interpreter von
./configure
ausgewählt wird.Der Apache kann von der Apache HTTP Server Downloadseite heruntergeladen werden, auf der verschiedene Spiegelserver angegeben sind. Sie finden hier die jeweils aktuelle stabile Version.
Nach dem Download, insbesondere, wenn ein Mirror benutzt wurde, ist es
wichtig, zu prüfen, dass Sie eine vollständige, nicht
modifizierte Version des Apache HTTP Servers erhalten haben. Dies kann
durch Prüfen des heruntergeladenen Tarballs gegen die PGP-Signatur
erreicht werden. Dies ist wiederum ein Zweischrittverfahren. Zuerst
müssen Sie die
KEYS
-Datei ebenfalls von der Apache
Distributionsseite beziehen. (Um sicherzustellen, dass die
KEYS
-Datei selbst nicht verändert wurde, ist
es sinnvoll, eine Datei aus einer früheren Distribution des
Apache zu verwenden, oder den Schlüssel von einem öffentlichen
Schlüsselserver zu importieren.) Die Schlüssel werden mit einem
der folgenden Befehle (abhängig von Ihrer PGP Version) zu Ihrem
persönlichen Schlüsselring hinzugefügt:
oder
Der nächste Schritt ist das Testen des Tarballs gegen
die PGP-Signatur, die immer von der Apache Originalseite
bezogen werden sollte. Den Link zur Signaturdatei finden Sie hinter
dem jeweiligen Download-Link oder im entsprechenden Verzeichnis auf der
Apache-Distributionsseite
Sie hat den gleichen Dateinamen wie der Tarball, aber zusätzlich die
Endung .asc
. Nun können Sie die Distribution mit
einem der folgenden Befehle (wiederum abhängig von Ihrer PGP
Version) prüfen:
oder
Sie sollten eine Meldung wie
erhalten.
Abhängig von den Vertrauensbeziehungen in Ihrem
Schlüsselring können Sie auch eine Meldung erhalten, die
besagt, dass die Beziehungen zwischen dem Schlüssel und dem
Unterzeichner des Schlüssels nicht verifiziert werden können.
Solange Sie der Authentizität der KEYS
-Datei
vertrauen, ist dies kein Problem.
Das Auspacken des Quellcodes aus dem Apache HTTPD Tarball besteht aus einem simplen Dekomprimieren und danach "Ent-tarren":
Dies erstellt unterhalb des aktuellen Verzeichnisses ein neues
Verzeichnis, das den Quellcode für die Distribution enthält.
Sie sollten mit cd
in dieses Verzeichnis wechseln,
bevor Sie mit der Kompilierung des Servers weitermachen.
Der nächste Schritt ist die Konfiguration des
Apache-Codebaumes für Ihre spezielle Plattform und Ihre
persönlichen Bedürfnisse. Dies wird mit dem Skript
configure
durchgeführt, das im Wurzelverzeichnis
der Distribution enthalten ist. (Entwickler, welche die CVS Version
des Apache-Codebaumes herunterladen, müssen autoconf
und libtool
installiert haben und müssen
buildconf
ausführen, bevor sie mit den
nächsten Schritten fortfahren können. Dies wird bei
offiziellen Releases nicht notwendig sein.)
Um den Codebaum mit den Standardeinstellungen zu konfigurieren,
geben Sie einfach ./configure
ein. Zur Änderung
dieser Voreinstellungen akzeptiert configure
eine
Reihe von Variablen und Kommandozeilenoptionen. Umgebungsvariablen
werden üblicherweise vor den ./configure
-Befehl gesetzt,
während andere Optionen danach gesetzt werden. Die wichtigste Option
hierbei ist der vorangestellte Ablageort, unter dem der Apache später
installiert wird, denn der Apache muss auf diesen Ablageort eingestellt
werden, um korrekt zu arbeiten. Es gibt jedoch noch eine Reihe weiterer
Optionen für Ihre persönlichen Wünsche.
Um einen kurzen Eindruck zu gewinnen, welche Möglichkeiten Sie
haben, folgt hier ein typisches Beispiel, das den Apache mit einem
speziellen Compiler und Compilerflags für das
Installationsverzeichnis /sk/pkg/apache
kompiliert, sowie
die beiden zusätzlichen Module
Wenn configure
startet, benötigt es mehrere Minuten,
um die Verfügbarkeit von Features auf Ihrem System zu prüfen
und ein Makefile zu generieren, das später zur Kompilierung des
Servers verwendet wird.
Die einfachste Art und Weise, alle Konfigurationsflags für den
Apache herauszufinden, ist, ./configure --help
aufzurufen.
Hier folgt eine kurze Beschreibung der meisten Argumente und
Umgebungsvariablen.
Der autoconf
-Generierungsvorgang verwendet verschiedene
Umgebungsvariablen für die Konfiguration der Generierungsumgebung.
Im allgemeinen verändern diese Variablen die Methode, die benutzt
wird, um den Apache zu erstellen, nicht aber die letztendlichen
Features des Servers. Diese Variablen können vor dem Aufruf von
configure
im Environment gesetzt werden, doch es ist
üblicherweise einfacher, sie in der
configure
-Befehlszeile, wie im obigen Beispiel gezeigt,
anzugeben.
CC=...
CPPFLAGS=...
CFLAGS=...
LDFLAGS=...
LIBS=...
-L
" und "-l
" Optionen), die
an den Linker durchgereicht werden.INCLUDES=...
-IVerzeichnis
").TARGET=...
[Default: httpd
]NOTEST_CPPFLAGS=...
NOTEST_CFLAGS=...
NOTEST_LDFLAGS=...
NOTEST_LIBS=...
NOTEST
. Diese Variablen werden jedoch
nur auf den Generierungsprozess angewendet, nachdem autoconf seine
Featuretests durchgeführt hat. Dies erlaubt die Einbeziehung
von Flags, die während des Featuretests Probleme bereiten
würden, aber für die endgültige Kompilierung verwendet
werden müssen.SHLIB_PATH=...
--help
--quiet
checking...
"
Nachrichten.--verbose
Gegenwärtig existieren zwei Möglichkeiten, die Pfade zu konfigurieren, in denen der Apache seine Dateien installiert. Bei der ersten können Sie ein Verzeichnis angeben und den Apache veranlassen, sich selbst unterhalb dieses Verzeichnisses in seinen voreingestellten Ablageorten zu installieren.
--prefix=PREFIX
[Default:
/usr/local/apache2
]Es ist möglich, anzugeben, dass Architektur-abhängige Dateien in einem anderen Verzeichnis abgelegt werden sollen.
--exec-prefix=EPREFIX
[Default:
PREFIX
]Die zweite und flexiblere Weise, den Installationspfad für den
Apache einzustellen, ist die Verwendung der Datei
config.layout
. Wenn Sie diese Methode benutzen, können
Sie den Ablageort für jeden Dateityp innerhalb der
Apache-Installation separat angeben. Die Datei
config.layout
enthält verschiedene
Konfigurationsbeispiele. Sie können auch anhand der Beispiele Ihre
eigene individuelle Konfiguration erstellen. Die verschiedenen
Layouts in dieser Datei sind gruppiert in <Layout
FOO>...</Layout>
-Abschnitte und
werden mit Namen wie FOO
bezeichnet.
--enable-layout=LAYOUT
config.layout
, um die Installationspfade genau
anzugeben.Der Apache ist ein modularer Server. Nur die grundlegendste
Funktionalität ist im Kernserver enthalten. Erweiternde Features
stehen in verschiedenen Modulen bereit. Während des
Konfigurationsprozesses müssen Sie auswählen, welche Module
für die Verwendung mit Ihrem Server kompiliert werden sollen. Eine
Liste von Modulen ist in dieser
Dokumentation enthalten. Module mit dem Status "Base"
sind standardmäßig enthalten und müssen ausdrücklich
deaktiviert werden (z.B.
Es gibt zwei Möglichkeiten, Module zu kompilieren und mit dem
Apache zu benutzen. Module können statisch kompiliert
werden, was bedeutet, dass sie permanent in dem Apache Binary
eingebunden sind. Wenn Ihr Betriebssystem Dynamic Shared Objects
(DSOs; Anm. d. Übersetzers: dynamisch eingebundene Bibliotheken)
unterstützt und autoconf
diese Unterstützung
erkennen kann, dann können Module alternativ dynamisch
kompiliert werden. DSO-Module werden von der Apache Binary getrennt
gespeichert und können vom Server unter Verwendung der Direktiven
zur Laufzeitkonfiguration, die von --enable-so
angeben.
--enable-MODULE[=shared]
=shared
hinzu.--disable-MODULE
--enable-modules=MODUL-LISTE
--enable-mods-shared=MODUL-LISTE
Die MODUL-LISTE in den Optionen
--enable-modules
und --enable-mods-shared
ist üblicherweise eine durch Leerzeichen getrennte Liste von
Modul-Bezeichnern. Zum Beispiel können zum Aktivieren von
oder äquivalent
Zusätzlich können die speziellen Schlüsselwörter
all
oder most
benutzt werden, um alle oder
die meisten der Module in einem Schritt hinzuzufügen. Sie
können Module, die Sie nicht benutzen möchten, mit der Option
--disable-MODUL
entfernen. Um beispielsweise alle
Module mit Ausnahme von
verwenden.
Zusätzlich zum Standard-Set von Modulen fügt der Apache 2.0
auch eine Auswahl von Multi-Processing Modulen
(MPMs) ein. Ein, und nur ein einziges, MPM muss in den
Kompilierungsprozess eingebunden werden. Das voreingestellte MPM jeder
Plattform ist in der MPM Dokumentation
aufgeführt, kann jedoch mit der configure
-Kommandozeile
überschrieben werden.
--with-mpm=NAME
Um ein MPM mit dem Namen mpm_name zu aktivieren, verwenden Sie
Verschiedene Apache-Features, darunter configure
-Optionen dazu verwenden:
--with-gdbm[=Pfad]
--with-ndbm[=Pfad]
--with-berkeley-db[=Pfad]
/lib
und Pfad/include
nach relevanten Dateien zu suchen. Letztlich kann Pfad
auch die speziellen Include- und Bibliothek-Pfade durch Doppelpunkt
getrennt auflisten.Der Apache enthält ein Hilfsprogramm namens suexec, das zur Isolation benutzereigener CGI-Programme verwendet werden kann. Wenn suexec jedoch unsachgemäß konfiguriert wurde, kann es schwere Sicherheitsprobleme verursachen. Deshalb sollten Sie die suexec Dokumentation sorgfältig lesen und beachten, bevor Sie dieses Feature implementieren.
Nun können Sie die verschiedenen Teile, die das Apache-Paket bilden, einfach durch Ausführen des folgenden Befehls erstellen:
Seien Sie hierbei bitte geduldig, denn eine Basiskonfiguration benötigt ungefähr 3 Minuten auf einem Pentium III/Linux 2.2. System. Dies kann aber abhängig von Ihrer Hardware und der Anzahl der Module, die Sie aktiviert haben, sehr stark variieren.
Nun endlich installieren Sie das Package unter dem konfigurierten
Installations-PREFIX (siehe oben: Option --prefix
durch Aufrufen von:
Wenn Sie upgraden, wird die Installation Ihre Konfigurationsdateien oder Dokumente nicht überschrieben.
Als nächstes können Sie Ihren Apache HTTP Server anpassen,
indem Sie die Konfigurationsdateien
unterhalb von PREFIX/conf/
editieren.
Werfen Sie auch einen Blick in das Apache-Handbuch unter docs/manual/. Die aktuellste Version dieses Handbuchs sowie eine komplette Referenz der verfügbaren Konfigurationsanweisungen finden Sie unter http://httpd.apache.org/docs-2.1/.
Sie können nun Ihren Apache HTTP Server starten, indem Sie einfach
ausführen.
Danach sollten Sie Ihr erstes Dokument unter dem URL
http://localhost/
anfordern können. Die Webseite,
die Sie sehen, ist im PREFIX/htdocs/
ist. Den Server stoppen Sie wieder durch
Ausführen von:
Der erste Schritt beim Aktualisieren besteht darin, die
Versionsankündigung sowie die CHANGES
-Datei in der
Quelltextdistribution zu lesen, um Änderungen zu finden, die Ihr
System möglicherweise betreffen. Wenn Sie einen größeren
Versionssprung durchführen (z.B. vom 1.3 auf 2.0 oder von 2.0 auf
2.2), wird es wahrscheinlich auch größere Unterschiede in der
Kompilier- und Laufzeitkonfiguration geben, die manuelle Nacharbeiten
erfordern. Außerdem müssen alle Module aktualisiert
werden, um den Änderungen der Modul-API gerecht zu werden.
Die Aktualisierung einer Unterversion auf eine andere (z.B. von 2.0.55
auf 2.0.57) ist einfacher. make install
überschreibt
keine der bereits existierenden Dokumente, Log- und Konfigurationsdateien.
Ausserdem bemühen sich die Entwickler, inkompatible Änderungen
der configure
-Optionen, der Laufzeitkonfiguration sowie der
Modul-API zu vermeiden. In den meisten Fällen sollten Sie in der
Lage sein, den gleichen configure
-Befehl, die gleiche
Konfiguration und die gleichen Module wieder zu verwenden. (Das gilt erst
seit Version 2.0.41 -- frühere Versionen enthielten noch inkompatible
Änderungen).
Wenn Sie den Quellcode von Ihrer letzten Installation aufgehoben haben,
ist ein Upgrade sogar noch einfacher. Die Datei config.nice
im
Wurzelverzeichnis des alten Quelltextbaums enthält den genauen
configure
-Befehl, der verwendet wurde, um den Quellcode
zu konfigurieren. Um jetzt von einer Version auf die nächste zu
aktualisieren, kopieren Sie einfach die config.nice
in das
Verzeichnis der neuen Version, passen sie bei Bedarf an, und
führen Sie sie aus:
--prefix
und einen anderen Port wählen (durch Anpassen der