Vergewissern Sie sich, dass folgende Voraussetzungen erfüllt sind, bevor Sie den Apache-Webserver einrichten:

Apache ist in der Standardinstallation von openSUSE nicht enthalten. Zum Installieren von Apache mit einer vordefinierten Standardkonfiguration gehen Sie wie folgt vor:

Hierzu zählt sowohl das Multiprocessing-Modul (MPM) apache2-prefork als auch das Modul PHP5. Weitere Informationen zu Modulen erhalten Sie unter Abschnitt 28.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.

Sie können Apache so konfigurieren, dass das Programm beim Booten des Computers automatisch gestartet wird, oder Sie können es manuell starten.

Weitere Informationen zu den Runlevels in openSUSE und eine Beschreibung des YaST-Runlevel-Editors finden Sie in Abschnitt 16.2.3, „Konfigurieren von Systemdiensten (Runlevel) mit YaST“.

Über die Shell starten Sie Apache manuell mit dem Kommando rcapache2 start.

Nachdem der Webserver nun läuft, können Sie eigene Dokumente hinzufügen, die Konfiguration an Ihre Anforderungen anpassen und weitere Module mit den benötigten Funktionen installieren.

Dieser Abschnitt enthält eine Übersicht über die Apache-Konfigurationsdateien. Wenn Sie die Konfiguration mit YaST vornehmen, müssen Sie diese Dateien nicht bearbeiten. Die Informationen können jedoch nützlich sein, wenn Sie später auf die manuelle Konfiguration umstellen möchten.

Die Konfigurationsdateien von Apache befinden sich in zwei verschiedenen Verzeichnissen:

/etc/apache2/
     |
     |- charset.conv 
     |- conf.d/
     |   |
     |   |- *.conf
     |
     |- default-server.conf
     |- errors.conf
     |- httpd.conf
     |- listen.conf
     |- magic
     |- mime.types
     |- mod_*.conf
     |- server-tuning.conf
     |- ssl.*
     |- ssl-global.conf
     |- sysconfig.d
     |   |
     |   |- global.conf
     |   |- include.conf
     |   |- loadmodule.conf . .
     |
     |- uid.conf
     |- vhosts.d
     |   |- *.conf

Wenn Sie den Apache-Webserver manuell konfigurieren möchten, müssen Sie die Klartext-Konfigurationsdateien als root-Benutzer bearbeiten.

Virtuelle Hostkonfiguration

Virtueller Host bezieht sich auf die Fähigkeit von Apache, mehrere URIs (Universal Resource Identifiers) vom gleichen physischen Computer aus bedienen zu können. Dies bedeutet, dass mehrere Domänen wie www.example.com und www.example.net von einem einzigen Webserver auf einem physischen Rechner ausgeführt werden können.

Virtuelle Hosts werden häufig eingesetzt, um Verwaltungsaufwand (nur ein Webserver muss verwaltet werden) und Hardware-Kosten (für die einzelnen Domänen ist kein dedizierter Server erforderlich) zu sparen. Virtuelle Hosts können auf Namen, IP-Adressen oder Ports basieren.

Verwenden Sie zum Auflisten aller vorhandenen virtuellen Hosts das Kommando httpd2 -S. Dadurch wird eine Liste mit dem Standardserver und allen virtuellen Hosts zusammen mit deren IP-Adressen und überwachenden Ports ausgegeben. Zusätzlich enthält die Liste einen Eintrag für jeden virtuellen Host mit dessen Speicherort in den Konfigurationsdateien.

Virtuelle Hosts können mit YaST (siehe Abschnitt 28.2.3.1.4, „Virtuelle Hosts“) oder manuell durch Bearbeitung einer Konfigurationsdatei konfiguriert werden. In openSUSE ist Apache unter /etc/apache2/vhosts.d/ standardmäßig für eine Konfigurationsdatei pro virtuellem Host vorbereitet. Alle Dateien in diesem Verzeichnis mit der Erweiterung .conf sind automatisch Bestandteil der Konfiguration. Außerdem enthält dieses Verzeichnis eine grundlegende Vorlage für virtuelle Hosts (vhost.template bzw. vhost-ssl.template für einen virtuellen Host mit SSL-Unterstützung).

Erstellen Sie immer eine virtuelle Hostkonfiguration.

Es empfiehlt sich, immer eine virtuelle Hostkonfiguration zu erstellen, selbst dann, wenn der Webserver nur eine Domäne enthält. Dadurch fassen Sie nicht nur die gesamte domänenspezifische Konfiguration in einer einzigen Datei zusammen, sondern Sie können auch jederzeit auf eine funktionierende Basiskonfiguration zurückgreifen, indem Sie einfach die Konfigurationsdatei des virtuellen Hosts verschieben, löschen oder umbenennen. Aus dem gleichen Grund sollten Sie auch für jeden virtuellen Host eine eigene Konfigurationsdatei erstellen. Bei der Verwendung von namenbasierten virtuellen Hosts empfiehlt es sich, eine Standardkonfiguration einzurichten, die verwendet wird, wenn ein Domänenname nicht mit einer virtuellen Hostkonfiguration übereinstimmt. Der virtuelle Standardhost ist der Host, dessen Konfiguration zuerst geladen wird. Da die Reihenfolge der Konfigurationsdateien durch den Dateinamen bestimmt wird, starten Sie den Dateinamen der Konfiguration des virtuellen Standardhosts mit einem Unterstrich _, um sicherzustellen, dass sie zuerst geladen wird (z. B. _default_vhost.conf).

Der <VirtualHost></VirtualHost>-Block enthält die Informationen zu einer bestimmten Domäne. Wenn Apache eine Client-Anforderung für einen definierten virtuellen Host empfängt, verwendet es die in diesem Block angegebenen Direktiven. Nahezu alle Direktiven können auch im Kontext eines virtuellen Hosts verwendet werden. Weitere Informationen zu den Konfigurationsdirektiven von Apache finden Sie unter http://httpd.apache.org/docs/2.2/mod/quickreference.html.

Namensbasierte virtuelle Hosts

Namensbasierte virtuelle Hosts können an jeder IP-Adresse mehrere Websites bedienen. Apache verwendet das Hostfeld in dem vom Client übersandten HTTP-Header, um die Anforderung mit einem übereinstimmenden ServerName-Eintrag der virtuellen Hostdeklarationen zu verbinden. Wird kein übereinstimmender ServerName gefunden, dann wird der erste angegebene virtuelle Host als Standard verwendet.

Die Direktive NameVirtualHost teilt Apache mit, welche IP-Adresse (und optional welcher Port) auf Client-Anforderungen mit dem Domänennamen im HTTP-Header überwacht werden soll. Diese Option wird in der Konfigurationsdatei /etc/apache2/listen.conf konfiguriert.

Als erstes Argument kann der vollständig qualifizierte Domänenname eingegeben werden – empfohlen wird aber die IP-Adresse. Das zweite, optionale Argument ist der Port. Dieser ist standardmäßig Port 80 und wird mit der Listen-Direktive konfiguriert.

Sowohl für die IP-Adresse als auch für die Portnummer kann ein Platzhalterzeichen (*) eingegeben werden. In diesem Fall werden die Anforderungen an allen Schnittstellen empfangen. IPv6-Adressen müssen in eckigen Klammern eingeschlossen sein.

Beispiel 28.1. Beispiele für namensbasierte VirtualHost-Einträge

# NameVirtualHost IP-address[:Port]
NameVirtualHost 192.168.3.100:80
NameVirtualHost 192.168.3.100
NameVirtualHost *:80
NameVirtualHost *
NameVirtualHost [2002:c0a8:364::]:80

In einer namensbasierten virtuellen Hostkonfiguration übernimmt das VirtualHost-Anfangstag die zuvor unter NameVirtualHost deklarierte IP-Adresse (bzw. den vollständig qualifizierten Domänennamen) als Argument. Eine mit der NameVirtualHost-Direktive deklarierte Portnummer ist optional.

Anstelle der IP-Adresse wird auch ein Platzhalterzeichen (*) akzeptiert. Diese Syntax ist allerdings nur in Verbindung mit einem Platzhalter in NameVirtualHost * zulässig. IPv6-Adressen müssen in eckige Klammern eingeschlossen werden.

Beispiel 28.2. Namensbasierte VirtualHost-Direktiven

<VirtualHost 192.168.3.100:80>
  ...
</VirtualHost>

<VirtualHost 192.168.3.100>
  ...
</VirtualHost>

<VirtualHost *:80>
  ...
</VirtualHost>

<VirtualHost *>
  ...
</VirtualHost>

<VirtualHost [2002:c0a8:364::]>
  ...
</VirtualHost>

IP-basierte virtuelle Hosts

Bei dieser alternativen virtuellen Hostkonfiguration werden auf einem Computer mehrere IPs eingerichtet. Auf einer Apache-Instanz befinden sich mehrere Domänen, denen jeweils eine eigene IP zugewiesen ist.

Auf dem physischen Server muss für jeden IP-basierten virtuellen Host eine eigene IP-Adresse eingerichtet sein. Falls der Computer nicht über die entsprechende Anzahl an Netzwerkkarten verfügt, können auch virtuelle Netzwerkschnittstellen verwendet werden (IP-Aliasing).

Das folgende Beispiel zeigt Apache auf einem Computer mit der IP 192.168.3.100, auf dem sich zwei Domänen mit den zusätzlichen IPs 192.168.3.101 und 192.168.3.102 befinden. Für jeden virtuellen Server wird ein eigener VirtualHost-Block benötigt.

Beispiel 28.3. IP-basierte VirtualHost-Direktiven

<VirtualHost 192.168.3.101>
  ...
</VirtualHost>

<VirtualHost 192.168.3.102>
  ...
</VirtualHost>

In diesem Beispiel sind die VirtualHost-Direktiven nur für Schnittstellen angegeben, die nicht 192.168.3.100 sind. Wenn für 192.168.3.100 auch eine Listen-Direktive konfiguriert ist, muss ein eigener IP-basierter Host eingerichtet werden, um die HTTP-Anforderungen an diese Schnittstelle zu erfüllen. Andernfalls werden die Direktiven aus der Standardserverkonfiguration (/etc/apache2/default-server.conf) angewendet.

Basiskonfiguration eines virtuellen Hosts

Die Konfiguration eines virtuellen Hosts sollte mindestens die folgenden Direktiven enthalten. Weitere Optionen finden Sie in /etc/apache2/vhosts.d/vhost.template.

ServerName

Der vollständig qualifizierte Domänenname, unter dem der Host angesprochen wird.

DocumentRoot

Der absolute Pfad des Verzeichnisses, aus dem Apache die Dateien für diesen Host bedient. Aus Sicherheitsgründen ist standardmäßig auf das gesamte Dateisystem kein Zugriff möglich. Sie müssen dieses Verzeichnis daher explizit innerhalb eines Directory-Containers entsperren.

ServerAdmin

Hier geben Sie die E-Mail-Adresse des Serveradministrators ein. Diese Adresse ist beispielsweise auf den von Apache erstellten Fehlerseiten angegeben.

ErrorLog

Das Fehlerprotokoll dieses virtuellen Hosts. Ein eigenes Fehlerprotokoll für jeden virtuellen Host ist zwar nicht zwingend erforderlich, jedoch durchaus üblich, da dies die Fehlersuche erleichtert. /var/log/apache2/ ist das Standardverzeichnis für die Protokolldateien von Apache.

CustomLog

Das Zugriffsprotokoll dieses virtuellen Hosts. Ein eigenes Zugriffsprotokoll für jeden virtuellen Host ist zwar nicht zwingend erforderlich, jedoch durchaus üblich, da dies die separate Analyse der Zugriffsdaten für jeden einzelnen Host ermöglicht. /var/log/apache2/ ist das Standardverzeichnis für die Protokolldateien von Apache.

Wie bereits erwähnt, ist standardmäßig auf das gesamte Dateisystem kein Zugriff möglich. Die Verzeichnisse, in die Sie die Dateien gestellt haben, mit denen Apache arbeiten soll – zum Beispiel das Verzeichnis DocumentRoot –, müssen daher explizit entsperrt werden:

<Directory "/srv/www/www.example.com/htdocs">
  Order allow,deny
  Allow from all
</Directory>

Die vollständige Basiskonfiguration eines virtuellen Hosts sieht wie folgt aus:

Beispiel 28.4. Basiskonfiguration eines virtuellen Hosts

<VirtualHost 192.168.3.100>
  ServerName www.example.com
  DocumentRoot /srv/www/www.example.com/htdocs
  ServerAdmin webmaster@example.com
  ErrorLog /var/log/apache2/www.example.com_log
  CustomLog /var/log/apache2/www.example.com-access_log common
  <Directory "/srv/www/www.example.com/htdocs">
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

Um Ihren Webserver mit YaST zu konfigurieren, starten Sie YaST und wählen Sie Netzwerkdienste +HTTP-Server. Wenn Sie dieses Modul zum ersten Mal starten, wird der HTTP-Server-Assistent geöffnet und sie werden aufgefordert, einige grundlegende Entscheidungen zur Verwaltung des Servers zu treffen. Nach Fertigstellung des Assistenten wird das Dialogfeld HTTP-Server-Konfiguration geöffnet, sobald Sie das HTTP-Server-Modul aufrufen. Weitere Informationen finden Sie unter Abschnitt 28.2.3.2, „HTTP-Server-Konfiguration“.

HTTP-Server-Assistent

Der HTTP-Server-Assistent besteht aus fünf Schritten. Im letzten Schritt des Assistenten haben Sie die Möglichkeit, den Expertenkonfigurationsmodus aufzurufen, in dem Sie weitere spezielle Einstellungen vornehmen können.

Netzwerkgeräteauswahl

Geben Sie hier die Netzwerkschnittstellen und -ports an, die von Apache auf eingehende Anfragen überwacht werden. Sie können eine beliebige Kombination aus bestehenden Netzwerkschnittstellen und zugehörigen IP-Adressen auswählen. Sie können Ports aus allen drei Bereichen (Well-Known-Ports, registrierte Ports und dynamische oder private Ports) verwenden, sofern diese nicht für andere Dienste reserviert sind. Die Standardeinstellung ist die Überwachung aller Netzwerkschnittstellen (IP-Adressen) an Port 80.

Aktivieren Sie Firewall-Port öffnen, um die vom Webserver überwachten Ports in der Firewall zu öffnen. Dies ist erforderlich, um den Webserver im Netzwerk (LAN, WAN oder Internet) verfügbar zu machen. Das Schließen des Ports ist nur in Testsituationen sinnvoll, in denen kein externer Zugriff auf den Webserver erforderlich ist. Wenn Sie über mehrere Netzwerkschnittstellen verfügen, klicken Sie auf Firewall-Details..., um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.

Klicken Sie auf Weiter, um mit der Konfiguration fortzufahren.

Module

Mit der Konfigurationsoption Module aktivieren bzw. deaktivieren Sie die vom Webserver unterstützten Skriptsprachen. Informationen zur Aktivierung bzw. Deaktivierung anderer Module erhalten Sie unter Abschnitt 28.2.3.2.2, „Servermodule“. Klicken Sie auf Weiter, um das nächste Dialogfeld zu öffnen.

Standardhost

Diese Option betrifft den Standard-Webserver. Wie in Abschnitt 28.2.2.1, „Virtuelle Hostkonfiguration“ beschrieben, kann Apache von einem einzigen Computer mehrere virtuelle Hosts bedienen. Der erste in der Konfigurationsdatei deklarierte virtuelle Host wird im Allgemeinen als Standardhost bezeichnet. Alle nachfolgenden virtuellen Hosts übernehmen die Konfiguration des Standardhosts.

Wenn Sie die Hosteinstellungen (auch als Direktiven bezeichnet) bearbeiten möchten, wählen Sie den entsprechenden Eintrag in der Tabelle aus und klicken Sie auf Bearbeiten. Zum Hinzufügen neuer Direktiven klicken Sie auf Hinzufügen. Zum Löschen einer Direktive wählen Sie die Direktive aus und klicken Sie auf Löschen.

Abbildung 28.1. HTTP-Server-Assistent: Standardhost

Für den Server gelten folgende Standardeinstellungen:

Document-Root

Der absolute Pfad des Verzeichnisses, aus dem Apache die Dateien für diesen Host bedient. Dies ist standardmäßig /srv/www/htdocs.

Alias

Mithilfe von Alias-Direktiven können URL-Adressen physischen Speicherorten im Dateisystem zugeordnet werden. Dies bedeutet, dass über eine URL sogar auf Pfade im Dateisystem außerhalb des Document Root zugegriffen werden kann, sofern die URL via Aliasing auf diesen Pfad verweist.

Der vorgegebene openSUSE Alias für die in der Verzeichnisindex-Ansicht angezeigten Apache-Symbole, /icons, verweist auf /usr/share/apache2/icons.

ScriptAlias

Ähnlich wie die Alias-Direktive ordnet die ScriptAlias-Direktive eine URL einem Speicherort im Dateisystem zu. Der Unterschied besteht darin, dass ScriptAlias als Zielverzeichnis einen CGI-Speicherort für die Ausführung von CGI-Skripten festlegt.

Verzeichnis

Unter den Verzeichnis-Einstellungen können Sie eine Gruppe von Konfigurationsoptionen zusammenfassen, die nur für das angegebene Verzeichnis gelten.

Hier werden auch die Zugriffs- und Anzeigeoptionen für die Verzeichnisse /srv/www/htdocs, /usr/share/apache2/icons und /srv/www/cgi-bin konfiguriert. Eine Änderung dieser Standardeinstellungen sollte nicht erforderlich sein.

Einbeziehen

Hier können weitere Konfigurationsdateien hinzugefügt werden. Zwei Include-Direktiven sind bereits vorkonfiguriert: /etc/apache2/conf.d/ ist das Verzeichnis für die Konfigurationsdateien externer Module. Durch diese Direktive werden alle Dateien in diesem Verzeichnis mit der Erweiterung .conf eingeschlossen. Durch die zweite Direktive, /etc/apache2/conf.d/apache2-manual.conf, wird die Konfigurationsdatei apache2-manual eingeschlossen.

Servername

Hier wird die Standard-URL festgelegt, über die Clients den Webserver kontaktieren. Verwenden Sie einen qualifizierten Domänennamen (FQDN), um den Webserver unter http://FQDN/ zu erreichen. Alternativ können Sie auch die IP-Adresse verwenden. Sie können hier keinen willkürlichen Namen eingeben. Der Server muss unter diesem Namen "bekannt" sein.

E-Mail des Serveradministrators

Hier geben Sie die E-Mail-Adresse des Serveradministrators ein. Diese Adresse ist beispielsweise auf den von Apache erstellten Fehlerseiten angegeben.

Klicken Sie am Ende der Seite Standardhost auf Weiter, um mit der Konfiguration fortzufahren.

Virtuelle Hosts

In diesem Schritt zeigt der Assistent eine Liste der bereits konfigurierten virtuellen Hosts an (siehe Abschnitt 28.2.2.1, „Virtuelle Hostkonfiguration“). Wenn Sie vor dem Starten des YaST-HTTP-Assistenten keine manuellen Änderungen vorgenommen haben, ist kein virtueller Host vorhanden.

Zum Hinzufügen eines Hosts klicken Sie auf Hinzufügen, um ein Dialogfeld zu öffnen, in das Sie grundlegende Informationen über den Host eingeben, z. B. Servername, Übergeordnetes Verzeichnis der Server-Inhalte (DocumentRoot) und Administrator-E-Mail. Unter Server-Auflösung legen Sie fest, wie der Host identifiziert wird (nach seinem Namen oder nach seiner IP-Adresse). Geben Sie den Namen oder die IP-Adresse unter Change Virtual Host ID (Virtuelle Host-ID ändern) an.

Klicken Sie auf Weiter, um mit dem zweiten Teil der virtuellen Hostkonfiguration fortzufahren.

Im zweiten Teil der virtuellen Hostkonfiguration können Sie festlegen, ob CGI-Skripts zugelassen sind und welches Verzeichnis für diese Skripts verwendet wird. Dort können Sie auch SSL aktivieren. Wenn Sie SSL aktivieren, müssen Sie auch den Zertifikatpfad angeben. Informationen über SSL und Zertifikate finden Sie in Abschnitt 28.6.2, „Konfigurieren von Apache mit SSL“. Mit der Option Verzeichnisindex geben Sie an, welche Datei angezeigt wird, wenn der Client ein Verzeichnis anfordert (standardmäßig ist dies die Datei index.html). Statt der Standardeinstellung können Sie aber auch ein oder mehrere andere Dateinamen (jeweils getrennt durch ein Leerzeichen) angeben. Mit Enable Public HTML (Öffentliches HTML aktivieren) stellen Sie den Inhalt der öffentlichen Benutzerverzeichnisse (~user/public_html/) auf dem Server unter http://www.example.com/~user bereit.

	Erstellen virtueller Hosts
Virtuelle Hosts können Sie nicht völlig willkürlich hinzufügen. Wenn Sie namensbasierte virtuelle Hosts hinzufügen möchten, müssen die Hostnamen im Netzwerk aufgelöst sein. Bei IP-basierten virtuellen Hosts darf jeder verfügbaren IP-Adresse nur ein Host zugewiesen sein.

Zusammenfassung

Dies ist der abschließende Schritt des Assistenten. Legen Sie hier fest, wie und wann der Apache-Server gestartet werden soll: beim Boot-Vorgang oder manuell. Außerdem erhalten Sie in diesem Schritt eine kurze Zusammenfassung Ihrer bisherigen Konfiguration. Wenn Sie mit den Einstellungen zufrieden sind, schließen Sie die Konfiguration mit Verlassen ab. Möchten Sie Einstellungen ändern, dann klicken Sie so oft auf Zurück, bis das entsprechende Dialogfeld angezeigt wird. Über Expertenkonfiguration für HTTP-Server können Sie hier auch das in Abschnitt 28.2.3.2, „HTTP-Server-Konfiguration“ beschriebene Dialogfeld öffnen.

Abbildung 28.2. HTTP-Server-Assistent: Zusammenfassung

HTTP-Server-Konfiguration

Im Dialogfeld HTTP-Server-Konfiguration können Sie weitaus mehr Einstellungen vornehmen als im Assistenten (dieser wird ohnehin nur bei der Anfangskonfiguration des Webservers ausgeführt). Das Dialogfeld enthält vier Registerkarten, die nachfolgend beschrieben werden. Keine der in diesem Dialogfeld vorgenommenen Konfigurationsänderungen wird sofort wirksam. Die Änderungen werden erst wirksam, wenn Sie das Dialogfeld mit Verlassen schließen. Klicken Sie hingegen auf Abbrechen, so verlassen Sie das Konfigurationsmodul und Ihre Konfigurationsänderungen werden verworfen.

Überwachte Ports und Adressen

Geben Sie unter HTTP-Dienst an, ob Apache laufen soll (Aktiviert) oder beendet werden soll (Deaktiviert). Mit den Schaltflächen Hinzufügen, Bearbeiten und Löschen geben Sie unter Ports überwachen die Adressen und Ports an, die vom Server überwacht werden sollen. Standardmäßig werden alle Schnittstellen an Port 80 überwacht. Die Option Firewall-Port öffnen sollte immer aktiviert sein, weil ansonsten der Webserver von außen nicht erreichbar ist. Das Schließen des Ports ist nur in Testsituationen sinnvoll, in denen kein externer Zugriff auf den Webserver erforderlich ist. Wenn Sie über mehrere Netzwerkschnittstellen verfügen, klicken Sie auf Firewall-Details..., um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.

Über die Schaltfläche Protokolldateien können Sie das Zugriffs- oder das Fehlerprotokoll überwachen. Diese Funktion ist besonders beim Testen der Konfiguration hilfreich. Die Protokolldatei wird in einem eigenen Fenster geöffnet, aus dem Sie den Webserver auch neu starten oder neu laden können. Weitere Informationen finden Sie in Abschnitt 28.3, „Starten und Beenden von Apache“. Diese Kommandos sind sofort wirksam und ihre Protokollmeldungen werden auch sofort angezeigt.

Abbildung 28.3. Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen

Servermodule

Über Status wechseln können Sie Apache2-Module aktivieren und deaktivieren. Über Modul hinzufügen können Sie weitere Module hinzufügen, die zwar bereits installiert, aber noch nicht in dieser Liste aufgeführt sind. Weitere Informationen über Module finden Sie in Abschnitt 28.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.

Abbildung 28.4. Konfiguration des HTTP-Servers: Server-Module

Haupthost oder Hosts

Diese Dialogfelder sind mit den bereits beschriebenen identisch. in Abschnitt 28.2.3.1.3, „Standardhost“ und Abschnitt 28.2.3.1.4, „Virtuelle Hosts“ beschriebenen Dialogfeldern.

Wenn Sie die in Abschnitt 28.1.2, „Installation“ beschriebene Standardinstallation vorgenommen haben, sind folgende Module bereits installiert: alle Basis- und Erweiterungsmodule, das Multiprocessing-Modul Prefork MPM sowie die externen Module mod_php5 und mod_python.

Sie können weitere externe Module installieren. Starten Sie dazu YaST und wählen Sie Software+Software installieren oder löschen. Wählen Sie danach Filter+Suche und suchen Sie nach apache. Die Ergebnisliste zeigt nun neben anderen Paketen alle verfügbaren externen Apache-Module an.

Sie können bestimmte Module entweder manuell oder mit YaST aktivieren oder deaktivieren. In YaST müssen die Skriptsprachmodule (PHP5, Perl und Python) mit der im Abschnitt Abschnitt 28.2.3.1, „HTTP-Server-Assistent“ beschriebenen Modulkonfiguration aktiviert oder deaktiviert werden. Alle anderen Module werden, wie im Abschnitt Abschnitt 28.2.3.2.2, „Servermodule“ beschrieben, aktiviert oder deaktiviert.

Manuell können Sie die Module mit den Befehlen a2enmod mod_foo oder a2dismod mod_foo aktivieren bzw. deaktivieren. a2enmod -l gibt eine Liste aller zurzeit aktiven Module aus.

Einschließen der Konfigurationsdateien externer Module

Wenn Sie externe Module manuell aktivieren, müssen Sie sicherstellen, dass auch ihre Konfigurationsdateien in allen virtuellen Hostkonfigurationen geladen werden. Die Konfigurationsdateien externer Module befinden sich im Verzeichnis /etc/apache2/conf.d/ und werden standardmäßig nicht geladen. Wenn Sie auf allen virtuellen Hosts die gleichen Module benötigen, können Sie die Konfigurationsdateien aus diesem Verzeichnis mit *.conf einschließen. Anderenfalls müssen Sie die Dateien einzeln einschließen. Beispiele hierzu finden Sie in der Datei /etc/apache2/vhosts.d/vhost.template.

Alle Basis- und Erweiterungsmodule werden ausführlich in der Apache-Dokumentation beschrieben. An dieser Stelle gehen wir daher nur kurz auf die wichtigsten Module ein. Informationen zu den einzelnen Modulen erhalten Sie auch unter http://httpd.apache.org/docs/2.2/mod/.

openSUSE bietet zwei Multiprocessing-Module (MPMs) für Apache:

Prefork-MPM

Das Prefork-MPM implementiert einen Prefork-Webserver, der keine Threads verwendet. Mit diesem Modul verhält sich der Webserver, was die Handhabung von Anforderungen betrifft, ähnlich wie Apache Version 1.x: Er isoliert jede einzelne Anforderung und verarbeitet sie in einem separaten untergeordneten Prozess (Forking). Eine Beeinträchtigung aller Anforderungen durch wenige problematische Anforderungen und somit eine Sperre des Webservers lassen sich dadurch vermeiden.

Die prozessbasierte Vorgehensweise des Prefork-MPM bietet zwar Stabilität, konsumiert aber mehr Systemressourcen wie das Worker-MPM. Für UNIX-basierte Betriebssysteme gilt das Prefork-MPM als Standard-MPM.

	MPMs in diesem Dokument
In diesem Dokument wird davon ausgegangen, dass Apache mit dem Prefork-MPM verwendet wird.

Worker-MPM

Das Worker-MPM implementiert einen Multithread-Webserver. Ein Thread ist die "Lightweight-Version" eines Prozesses. Der Vorteil von Threads gegenüber Prozessen ist deren geringerer Ressourcenkonsum. Anstatt lediglich untergeordnete Prozesse zu erstellen (Forking), verarbeitet das Worker-MPM Anforderungen durch Threads mit Serverprozessen. Die untergeordneten Prefork-Prozesse sind auf mehrere Threads verteilt (Multithreading). Diese Ansatzweise macht den Apache-Server durch den geringeren Ressourcenkonsum leistungsfähiger als mit dem Prefork-MPM.

Ein Hauptnachteil ist die Instabilität des Worker-MPM: Ein fehlerhafter Thread kann sich auf alle Threads eines Prozesses auswirken. Im schlimmsten Fall fällt der Server dadurch aus. Besonders bei gleichzeitiger Verwendung des Common Gateway Interface (CGI) auf einem überlasteten Apache-Server kann es zu internen Serverfehlern kommen, da Threads in diesem Fall unter Umständen nicht in der Lage sind, mit den Systemressourcen zu kommunizieren. Gegen die Verwendung des Worker-MPM in Apache spricht auch die Tatsache, dass nicht alle verfügbaren Apache-Module Thread-sicher sind und daher nicht in Verbindung mit dem Worker-MPM eingesetzt werden können.

	Verwendung von PHP-Modulen mit MPMs
Nicht alle verfügbaren PHP-Module sind Thread-sicher. Von einer Verwendung des Worker-MPM in Verbindung mit mod_php wird daher abgeraten.

Nachfolgend finden Sie eine Liste aller externen Module, die mit openSUSE ausgeliefert werden. Die Dokumentation zu den einzelnen Modulen finden Sie in den jeweils genannten Verzeichnissen.

Apache kann von erfahrenen Benutzern durch selbst entwickelte Module erweitert werden. Für die Entwicklung eigener Apache-Module und für die Kompilierung von Drittanbieter-Modulen sind neben dem Paket apache2-devel auch die entsprechenden Entwicklungstools erforderlich. apache2-devel enthält unter anderem die apxs2-Tools, die zur Kompilierung von Apache-Erweiterungsmodulen erforderlich sind.

apxs2 ermöglicht die Kompilierung und Installation von Modulen aus dem Quellcode (einschließlich der erforderlichen Änderungen an den Konfigurationsdateien). Dadurch ergeben sich Dynamic Shared Objects (DSOs), die während der Laufzeit in Apache geladen werden können.

Die Binaries von apxs2 befinden sich unter /usr/sbin:

Mit den folgenden Kommandos installieren und aktivieren Sie ein Modul aus dem Quellcode:

cd /path/to/module/source; apxs2 -cia
    mod_foo.c

wobei das Modul mit -c kompiliert, mit -i installiert und mit -a aktiviert wird. Alle weiteren Optionen von apxs2 werden auf der man-Seite apxs2(1) beschrieben.

In openSUSE ist die Ausführung von CGI-Skripten nur im Verzeichnis /srv/www/cgi-bin/ erlaubt. Dieses Verzeichnis ist bereits für die Ausführung von CGI-Skripten konfiguriert. Wenn Sie eine virtuelle Hostkonfiguration erstellt haben (siehe Abschnitt 28.2.2.1, „Virtuelle Hostkonfiguration“) und Ihre CGI-Skripten in einem Host-spezifischen Verzeichnis ablegen möchten, müssen Sie das betreffende Verzeichnis entsperren und für CGI-Skripten konfigurieren.

ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI
 AddHandler cgi-script .cgi .pl
 Order allow,deny
 Allow from all
</Directory>

Die CGI-Programmierung unterscheidet sich von der herkömmlichen Programmierung insoweit, als CGI-Programmen und -Skripten ein MIME-Typ-Header wie Content-type: text/html vorangestellt werden muss. Dieser Header wird an den Client gesendet, damit er weiß, welchen Inhaltstyp er empfängt. Darüber hinaus muss die Skriptausgabe vom Client, in der Regel einem Webbrowser, verstanden werden. In den meisten Fällen ist dies HTML, manchmal aber auch Klartext, Bilder oder Ähnliches.

Unter /usr/share/doc/packages/apache2/test-cgi stellt Apache ein einfaches Testskript bereit. Dieses Skript gibt den Inhalt einiger Umgebungsvariablen als Klartext aus. Wenn Sie dieses Skript ausprobieren möchten, kopieren Sie es in das Verzeichnis /srv/www/cgi-bin/ bzw. in das Skriptverzeichnis Ihres virtuellen Hosts (/srv/www/www.example.com/cgi-bin/) und benennen Sie es in test.cgi um.

Dateien, auf die der Webserver zugreifen kann, sollten im Besitz des root-Benutzers sein. Weitere Informationen hierzu finden Sie im Abschnitt Abschnitt 28.7, „Vermeiden von Sicherheitsproblemen“. Da der Webserver unter einem anderen Benutzer ausgeführt wird, müssen CGI-Skripten von jedermann ausgeführt und gelesen werden können. Wechseln Sie daher in das CGI-Verzeichnis und führen Sie den Befehl chmod 755 test.cgi aus, um die entsprechenden Berechtigungen einzurichten.

Rufen Sie danach http://localhost/cgi-bin/test.cgi oder http://www.example.com/cgi-bin/test.cgi auf. Nun sollte der "CGI/1.0-Testskriptbericht" angezeigt werden.

Wenn Sie nach der Ausführung des CGI-Testskripten statt des Testskriptberichts eine Fehlermeldung erhalten, überprüfen Sie Folgendes:

Wenn Sie SSL/TSL mit dem Webserver einsetzen möchten, müssen Sie ein SSL-Zertifikat erstellen. Dieses Zertifikat ist für die Autorisierung zwischen Webserver und Client erforderlich, damit beide Endpunkte jeweils die Identität des anderen Endpunkts überprüfen können. Zum Nachweis der Zertifikatintegrität muss das Zertifikat von einer Organisation signiert sein, der jeder der beteiligten Benutzer vertraut.

Sie können drei Zertifikatsarten erstellen: ein "Dummy"-Zertifikat, das nur zu Testzwecken verwendet wird, ein selbst signiertes Zertifikat für einen bestimmten Benutzerkreis, der Ihnen vertraut, und ein Zertifikat, das von einer unabhängigen, öffentlich bekannten Zertifizierungsstelle (CA) signiert wurde.

Die Zertifikaterstellung besteht im Grunde nur aus zwei Schritten: Zunächst wird ein privater Schlüssel für die Zertifizierungsstelle generiert und danach wird das Serverzertifikat mit diesem Schlüssel signiert.

	Weiterführende Informationen
Weitere Informationen über das Konzept von SSL/TSL und diesbezügliche Festlegungen finden Sie unter http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html.

Erstellen eines "Dummy"-Zertifikats

Die Erstellung eines Dummy-Zertifikats ist einfach. Rufen Sie lediglich das Skript /usr/bin/gensslcert auf. Es erstellt oder überschreibt die unten aufgelisteten Dateien. Verwenden Sie die optischen Switches von gensslcert, um die Feineinstellungen für das Zertifikat vorzunehmen. Rufen Sie /usr/bin/gensslcert -h auf, um weitere Informationen zu erhalten.

• /etc/apache2/ssl.crt/ca.crt

• /etc/apache2/ssl.crt/server.crt

• /etc/apache2/ssl.key/server.key

• /etc/apache2/ssl.csr/server.csr

• /root/.mkcert.cfg

Außerdem wird eine Kopie der Datei ca.crt im Verzeichnis /srv/www/htdocs/CA.crt zum Herunterladen bereitgestellt.

	Nur zu Testzwecken
Verwenden Sie Dummy-Zertifikate niemals in Produktionsumgebungen, sondern nur zum Testen.

Erstellen eines selbst signierten Zertifikats

Wenn Sie einen sicheren Webserver für Ihr Intranet oder einen bestimmten Benutzerkreis einrichten, reicht unter Umständen ein von Ihrer eigenen Zertifizierungsstelle signiertes Zertifikat aus.

Die Erstellung eines selbst signierten Zertifikats ist ein interaktiver Vorgang, der aus neun Schritten besteht. Wechseln Sie dazu zunächst in das Verzeichnis /usr/share/doc/packages/apache2 und führen Sie den folgenden Befehl aus: ./mkcert.sh make --no-print-directory /usr/bin/openssl /usr/sbin/ custom. Diesen Befehl sollten Sie keinesfalls außerhalb dieses Verzeichnisses ausführen. Das Programm gibt eine Reihe von Eingabeaufforderungen aus, von denen einige Benutzereingaben erfordern.

Prozedur 28.4. Erstellen eines selbst signierten Zertifikats mit mkcert.sh

1. Festlegen des für Zertifikate zu verwendenden Signaturalgorithmus

   Wählen Sie RSA aus (R, die Standardeinstellung), da einige ältere Browser Probleme mit DSA haben.

2. Generating RSA private key for CA (1024 bit) (Privaten RSA-Schlüssel für CA (1024 Bit) erstellen)

   Keine Eingabe erforderlich.

3. Generating X.509 certificate signing request for CA (X.509-Zertifikatsignierungsanforderung für CA erstellen)

   Hier erstellen Sie den DN (Distinguished Name) der Zertifizierungsstelle. Dazu müssen Sie einige Fragen, z. B. nach dem Land oder der Organisation, beantworten. Geben Sie an dieser Stelle nur gültige Daten ein. Schließlich wird alles, was Sie hier eingeben, später im Zertifikat angezeigt. Sie müssen nicht alle Fragen beantworten. Wenn eine Frage nicht auf Sie zutrifft oder Sie eine Antwort offen lassen möchten, geben Sie "." ein. Allgemeiner Name ist der Name der CA selbst. Wählen Sie einen aussagekräftigen Namen wie CA mein Unternehmen.

   	Eigenname der CA
   Der Eigenname der CA muss sich vom Eigennamen des Servers unterscheiden. Wählen Sie daher in diesem Schritt nicht den voll qualifizierten Hostnamen.

4. Generating X.509 certificate for CA signed by itself (Von CA selbst signiertes X.509-Zertifikat für CA erstellen)

   Wählen Sie Zertifikatversion 3 aus (die Standardeinstellung).

5. Generating RSA private key for SERVER (1024 bit) (Privaten RSA-Schlüssel für SERVER (1024 Bit) erstellen)

   Keine Eingabe erforderlich.

6. Generating X.509 certificate signing request for SERVER (X.509-Zertifikatsignierungsanforderung für SERVER erstellen)

   Hier erstellen Sie den DN für den Serverschlüssel. Es werden nahezu die gleichen Fragen gestellt wie für den DN der Zertifizierungsstelle. Ihre Antworten betreffen jedoch den Webserver und müssen nicht unbedingt identisch mit den für die Zertifizierungsstelle eingegebenen Daten sein (der Server kann sich z. B. an einem anderen Standort befinden).

   	Auswahl eines Common Name
   Als Common Name (allgemeiner Name) müssen Sie hier den vollständig qualifizierten Hostnamen des sicheren Servers eingeben (z. B. www.example.com). Anderenfalls gibt der Browser beim Zugriff auf den Webserver eine Warnung mit dem Hinweis aus, dass das Zertifikat nicht mit dem Server übereinstimmt.

7. Generating X.509 certificate signed by own CA (Von eigener CA signiertes X.509-Zertifikat erstellen)

   Wählen Sie Zertifikatversion 3 aus (die Standardeinstellung).

8. Encrypting RSA private key of CA with a pass phrase for security (Privaten RSA-Schlüssel der CA aus Sicherheitsgründen mit einem Passwort verschlüsseln)

   Aus Sicherheitsgründen empfiehlt es sich, den privaten Schlüssel der Zertifizierungsstelle mit einem Passwort zu verschlüsseln. Wählen Sie daher J aus und geben Sie ein Passwort ein.

9. Encrypting RSA private key of SERVER with a pass phrase for security (Privaten RSA-Schlüssel des SERVERS aus Sicherheitsgründen mit einem Passwort verschlüsseln)

   Wenn Sie den Serverschlüssel mit einem Passwort verschlüsseln, müssen Sie dieses Passwort bei jedem Start des Webservers eingeben. Dies macht den automatischen Start des Webservers beim Hochfahren des Computers oder einen Neustart des Webservers nahezu unmöglich. Aus diesem Grund sollten Sie diese Frage mit N beantworten. Denken Sie aber daran, dass Ihr Schlüssel in diesem Fall ungeschützt ist, und stellen Sie sicher, dass nur autorisierte Personen Zugriff auf den Schlüssel haben.

   	Verschlüsseln des Serverschlüssels
   Wenn Sie den Serverschlüssel mit einem Passwort verschlüsseln möchten, erhöhen Sie den Wert für APACHE_TIMEOUT in /etc/sysconfig/apache2. Anderenfalls bleibt Ihnen unter Umständen nicht genügend Zeit für die Eingabe des Passworts, bevor der Startversuch des Servers wegen Zeitüberschreitung abgebrochen wird.

Die Ergebnisseite des Skripts enthält eine Liste der generierten Zertifikate und Schlüssel. Die Dateien wurden allerdings nicht, wie im Skript angegeben, im lokalen Verzeichnis conf erstellt, sondern in den passenden Verzeichnissen unter /etc/apache2/.

Der letzte Schritt besteht darin, die Zertifikatdatei der Zertifizierungsstelle aus dem Verzeichnis /etc/apache2/ssl.crt/ca.crt in ein Verzeichnis zu kopieren, in dem die Benutzer auf die Datei zugreifen können. Aus diesem Verzeichnis können die Benutzer die Zertifizierungsstelle in ihren Webbrowsern der Liste der bekannten und vertrauenswürdigen Zertifizierungsstellen hinzufügen. Wäre die Zertifizierungsstelle nicht in dieser Liste enthalten, würde der Browser melden, dass das Zertifikat von einer unbekannten Zertifizierungsstelle ausgegeben wurde. Das neu erstellte Zertifikat ist ein Jahr lang gültig.

	Eigensignierte Zertifikate
Verwenden Sie selbst signierte Zertifikate nur auf einem Webserver, auf den Benutzer zugreifen, denen Sie bekannt sind und die Ihnen als Zertifizierungsstelle vertrauen. Für einen öffentlichen Online-Versand wäre ein solches Zertifikat z. B. nicht geeignet.

Port 443 ist auf dem Webserver der Standardport für SSL- und TLS-Anforderungen. Zwischen einem "normalen" Apache-Webserver, der Port 80 überwacht, und einem SSL/TLS-aktivierten Apache-Server, der Port 443 überwacht, kommt es zu keinen Konflikten. In der Tat kann die gleiche Apache-Instanz sowohl HTTP als auch HTTPS ausführen. In der Regel verteilen separate virtuelle Hosts die Anforderungen für Port 80 und Port 443 an separate virtuelle Server.

	Firewall-Konfiguration
Vergessen Sie nicht, die Firewall für den SSL-aktivierten Apache-Webserver an Port 443 zu öffnen. Sie können dazu YaST verwenden (siehe Section “Configuring the Firewall with YaST” (Chapter 14, Masquerading and Firewalls, ↑Security Guide)).

Der SSL-Modus wird standardmäßig in der globalen Serverkonfiguration aktiviert. Falls er auf Ihrem Host deaktiviert wurde, aktivieren Sie ihn mithilfe des folgenden Kommandos: a2enmod ssl. Um SSL schließlich aktivieren zu können, muss der Server mit dem Flag "SSL" gestartet werden. Rufen Sie dazu a2enflag SSL auf. Wenn Sie sich zuvor entschieden haben, Ihr Serverzertifikat durch ein Passwort zu verschlüsseln, sollten Sie auch den Wert von APACHE_TIMEOUT in /etc/sysconfig/apache2 heraufsetzen, damit Ihnen beim Start von Apache genügend Zeit für die Eingabe des Passworts bleibt. Starten Sie den Server anschließend neu, damit die Änderungen wirksam werden. Ein Neuladen des Servers reicht dazu nicht aus.

Das Verzeichnis der virtuellen Hostkonfiguration enthält die Vorlage /etc/apache2/vhosts.d/vhost-ssl.template. Diese enthält SSL-spezifische Direktiven, die bereits an anderer Stelle hinreichend dokumentiert sind. Informationen über die Basiskonfiguration eines virtuellen Hosts finden Sie unter Abschnitt 28.2.2.1, „Virtuelle Hostkonfiguration“.

Kopieren Sie zum Starten die Vorlage zu /etc/apache2/vhosts.d/mySSL-host.conf und bearbeiten Sie diese. Es sollte ausreichen, die Werte für die folgenden Anweisungen anzupassen:

Namensbasierte virtuelle Hosts und SSL

Auf einem Server mit nur einer IP-Adresse können nicht mehrere SSL-aktivierte virtuelle Hosts laufen. Benutzer, die versuchen, eine Verbindung mit einer solchen Konfiguration herzustellen, erhalten bei jedem Besuch der URL eine Warnung mit dem Hinweis, dass das Zertifikat nicht mit dem Namen des Servers übereinstimmt. Für die Kommunikation auf Grundlage eines gültigen SSL-Zertifikats ist eine separate IP-Adresse bzw. ein separater Port für jede SSL-aktivierte Domäne erforderlich.

Bei Bekanntwerden von Sicherheitsrisiken in der Apache-Software veröffentlicht SUSE sofort einen entsprechenden Sicherheitshinweis. Dieser enthält Anleitungen zur Behebung der Schwachstellen, die wiederum möglichst frühzeitig angewendet werden sollten. Die Sicherheitsankündigungen von SUSE stehen unter folgenden Adressen zur Verfügung:

In openSUSE sind das DocumentRoot-Verzeichnis /srv/www/htdocs (absoluter Pfad) und das CGI-Verzeichnis /srv/www/cgi-bin standardmäßig dem Benutzer bzw. der Gruppe root zugeordnet. Diese Berechtigungen sollten nicht geändert werden. Wenn diese Verzeichnisse für alle Benutzer modifizierbar wären, könnte jeder Benutzer Dateien darin ablegen. Diese Dateien würden dann von Apache mit wwwrun-Berechtigungen ausgeführt werden, was wiederum dem Benutzer unbeabsichtigt Zugriff auf die Ressourcen des Dateisystems gewähren würde. Das DocumentRoot-Verzeichnis und die CGI-Verzeichnisse Ihrer virtuellen Hosts sollten Sie als Unterverzeichnisse im Verzeichnis /srv/www anlegen. Stellen Sie auch bei diesen Verzeichnissen sicher, dass die Verzeichnisse und die darin enthaltenen Dateien dem Benutzer bzw. der Gruppe root zugeordnet sind.

Standardmäßig wird in /etc/apache2/httpd.conf der Zugriff auf das gesamte Dateisystem verweigert. Diese Direktiven sollten Sie nicht überschreiben. Aktivieren Sie stattdessen explizit den Zugriff auf die Verzeichnisse, die Apache lesen muss. Weitere Informationen finden Sie in Abschnitt 28.2.2.1.3, „Basiskonfiguration eines virtuellen Hosts“. Achten Sie dabei darauf, dass keine unbefugten Personen auf kritische Dateien wie Passwort- oder Systemkonfigurationsdateien zugreifen können.

Interaktive Skripten in Perl, PHP, SSI oder anderen Programmiersprachen können im Prinzip jeden beliebigen Befehl ausführen und stellen damit generell ein Sicherheitsrisiko dar. Skripten, die vom Server ausgeführt werden, sollten nur aus Quellen stammen, denen der Serveradministrator vertraut. Es wird davon abgeraten, den Benutzern die Ausführung eigener Skripten zu erlauben. Zusätzlich empfiehlt es sich, die Sicherheit aller Skripten zu überprüfen.

Es ist durchaus üblich, sich die Skriptverwaltung durch eine Einschränkung der Skriptausführung zu vereinfachen. Dabei wird die Ausführung von CGI-Skripten auf bestimmte Verzeichnisse eingeschränkt, statt sie global zuzulassen. Die Direktiven ScriptAlias und Option ExecCGI werden zur Konfiguration verwendet. In der Standardkonfiguration von openSUSE ist es generell nicht gestattet, CGI-Skripten von jedem beliebigen Ort aus auszuführen.

Alle CGI-Skripten werden unter dem gleichen Benutzer ausgeführt. Es kann daher zu Konflikten zwischen verschiedenen Skripten kommen. Abhilfe schafft hier das Modul suEXEC, das die Ausführung von CGI-Skripten unter einem anderen Benutzer oder einer anderen Gruppe ermöglicht.

Bei der Aktivierung von Benutzerverzeichnissen (mit mod_userdir oder mod_rewrite) sollten Sie unbedingt darauf achten, keine .htaccess-Dateien zuzulassen. Durch diese Dateien wäre es den Benutzern möglich, die Sicherheitseinstellungen zu überschreiben. Zumindest sollten Sie die Möglichkeiten des Benutzers durch die Direktive AllowOverRide einschränken. In openSUSE sind .htaccess-Dateien standardmäßig aktiviert. Den Benutzern ist es allerdings nicht erlaubt, mit mod_userdir Option-Anweisungen zu überschreiben (siehe Konfigurationsdatei /etc/apache2/mod_userdir.conf).

Eine Liste der neuen Funktionen in Apache 2.2 finden Sie unter http://httpd.apache.org/docs/2.2/new_features_2_2.html. Upgrade-Informationen von Version 2.0 auf Version 2.2 erhalten Sie unter http://httpd.apache.org/docs-2.2/upgrading.html.

Weitere Informationen zu externen Apache-Modulen, die kurz im Abschnitt Abschnitt 28.4.5, „Externe Module“ beschrieben werden, finden Sie an folgenden Orten:

Weitere Informationen zur Entwicklung von Apache-Modulen sowie zur Teilnahme am Apache-Webserver-Projekt finden Sie unter folgenden Adressen:

Wenn Sie in openSUSE Probleme mit Apache haben, werfen Sie einen Blick in openSUSE-Wiki unter http://old-en.opensuse.org/Apache. Die Entstehungsgeschichte von Apache finden Sie unter http://httpd.apache.org/ABOUT_APACHE.html. Auf dieser Seite erfahren Sie auch, weshalb dieser Server Apache genannt wird.