Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 11 SP4

31 Der HTTP-Server Apache

Mit einem Marktanteil von mehr als 50 % ist der Apache HTTP-Server (Apache) laut einer http://www.netcraft.com/-Umfrage im der weltweit am häufigsten eingesetzte Webserver. Der von Apache Software Foundation (http://www.apache.org/) entwickelte Apache-Server läuft auf fast allen Betriebssystemen. SUSE® Linux Enterprise Server umfasst Apache, Version 2.2. In diesem Kapitel erfahren Sie, wie Apache installiert, konfiguriert und eingerichtet wird. Sie lernen SSL, CGI und weitere Module kennen und erfahren, wie Sie bei Problemen mit dem Webserver vorgehen.

31.1 Kurzanleitung

In diesem Abschnitt erfahren Sie, wie Sie Apache in kürzester Zeit installieren und einrichten. Zur Installation und Konfiguration von Apache müssen Sie als root-Benutzer angemeldet sein.

31.1.1 Anforderungen

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

  1. Das Netzwerk des Computers ist ordnungsgemäß konfiguriert. Weitere Informationen zu diesem Thema finden Sie unter Kapitel 22, Grundlegendes zu Netzwerken.

  2. Durch Synchronisierung mit einem Zeitserver ist sichergestellt, dass die Systemzeit des Computers genau ist. Die exakte Uhrzeit ist für Teile des HTTP-Protokolls nötig. Weitere Informationen zu diesem Thema finden Sie unter Kapitel 24, Zeitsynchronisierung mit NTP.

  3. Die neuesten Sicherheitsaktualisierungen sind installiert. Falls Sie sich nicht sicher sind, führen Sie YaST-Online-Update aus.

  4. In der Firewall ist der Standardport des Webservers ( 80) geöffnet. Lassen Sie dazu in SUSEFirewall2 den Service HTTP-Server in der externen Zone zu. Dies können Sie mithilfe von YaST erledigen. Weitere Informationen finden Sie in Section 15.4.1, “Configuring the Firewall with YaST”.

31.1.2 Installation

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

Prozedur 31.1: Installation von Apache mit der Standardkonfiguration
  1. Starten Sie YaST, und wählen Sie Software › Software installieren oder löschen.

  2. Wählen Sie Filter › Schemata und dann Web and LAM Server in Serverfunktionen aus.

  3. Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.

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

31.1.3 Start

Sie können Apache automatisch beim Booten oder manuell starten.

Prozedur 31.2: Automatisches Starten von Apache
  1. Um sicherzustellen, dass Apache beim Booten des Computers in den Runlevels 3 und 5 automatisch gestartet wird, führen Sie das folgende Kommando aus:

    chkconfig -a apache2
  2. Sie können auch YaST starten und System › Systemdienste (Runlevel) auswählen.

  3. Suchen Sie dann nach apache2 und aktivieren Sie den Service.

    Der Webserver wird sofort gestartet.

  4. Speichern Sie die Änderungen mit Beenden.

    Das System ist so konfiguriert, dass Apache beim Booten des Computers automatisch in den Runlevels 3 und 5 gestartet wird.

Weitere Informationen zu den Runlevels in SUSE Linux Enterprise Server und eine Beschreibung des YaST-Runlevel-Editors finden Sie in Abschnitt 10.2.3, „Konfigurieren von Systemdiensten (Runlevel) mit YaST“.

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

Prozedur 31.3: Überprüfen, ob Apache ausgeführt wird

Werden beim Starten von Apache keine Fehlermeldungen angezeigt, bedeutet dies im Normalfall, dass der Webserver ausgeführt wird. So überprüfen Sie, ob Apache ausgeführt wird:

  1. Starten Sie einen Webbrowser und öffnen Sie http://localhost/.

    Wenn Apache ausgeführt wird, wird eine Testseite mit der Meldung It works! angezeigt.

  2. Wenn diese Seite nicht angezeigt wird, lesen Sie den Abschnitt Abschnitt 31.9, „Fehlersuche“.

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.

31.2 Konfigurieren von Apache

SUSE Linux Enterprise Server bietet zwei Konfigurationsoptionen:

Bei der manuellen Konfiguration können Sie mehr Details einstellen, allerdings müssen Sie ohne den Komfort der Bedienoberfläche von YaST zurechtkommen.

Wichtig
Wichtig: Neuladen oder -starten von Apache nach Konfigurationsänderungen

Damit Konfigurationsänderungen wirksam werden, ist in den meisten Fällen ein erneutes Laden (in einigen Fällen auch ein Neustart) von Apache erforderlich. Laden Sie Apache mit rcapache2  reload neu oder verwenden Sie eine der in Abschnitt 31.3, „Starten und Beenden von Apache“ beschriebenen Neustartoptionen.

Wenn Sie Apache mit YaST konfigurieren, kann dieser Schritt automatisch ausgeführt werden. Stellen Sie dazu HTTP-Service auf Aktiviert ein, wie in Abschnitt 31.2.3.2, „HTTP-Server-Konfiguration“ beschrieben.

31.2.1 Apache-Konfigurationsdateien

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:

31.2.1.1 /etc/sysconfig/apache2

/etc/sysconfig/apache2 steuert einige globale Einstellungen von Apache, beispielsweise die zu ladenden Module, die einzuschließenden Konfigurationsdateien, die beim Serverstart zu verwendenden Flags sowie Flags, die der Kommandozeile hinzugefügt werden sollen. Die Konfigurationsoptionen dieser Datei sind hinreichend dokumentiert und werden daher an dieser Stelle nicht näher erläutert. Für die Konfigurationsanforderungen eines typischen Webservers dürften die Einstellungen der Datei /etc/sysconfig/apache2 ausreichen.

31.2.1.2 /etc/apache2/

/etc/apache2/ enthält alle Konfigurationsdateien für Apache. In diesem Abschnitt wird der Zweck jeder einzelnen Datei erklärt. Jede Datei enthält mehrere Konfigurationsoptionen (auch als Direktiven bezeichnet). Die Konfigurationsoptionen dieser Dateien sind hinreichend dokumentiert und werden daher an dieser Stelle nicht näher erläutert.

Die Apache-Konfigurationsdateien gliedern sich wie folgt:

/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
Apache-Konfigurationsdateien in /etc/apache2/
charset.conv

In dieser Datei ist festgelegt, welche Zeichensätze für die verschiedenen Sprachen verwendet werden. Bearbeiten Sie diese Datei nicht.

conf.d/*.conf

Dies sind Konfigurationsdateien anderer Module. Bei Bedarf können die Konfigurationsdateien in Ihre virtuellen Hostkonfigurationen eingeschlossen werden. Beispiele finden Sie in vhosts.d/vhost.template. Sie können damit unterschiedliche Modulsätze für verschiedene virtuelle Hosts bereitstellen.

default-server.conf

Diese Datei enthält eine globale Konfiguration für virtuelle Hosts mit vernünftigen Standardeinstellungen. Statt die Werte in dieser Datei zu ändern, sollten Sie sie in der virtuellen Hostkonfiguration überschreiben.

errors.conf

Diese Datei legt fest, wie Apache auf Fehler reagiert. Wenn Sie die Meldungen für alle virtuellen Hosts ändern möchten, können Sie diese Datei bearbeiten. Anderenfalls sollten Sie die entsprechenden Direktiven in den virtuellen Hostkonfigurationen überschreiben.

httpd.conf

Dies ist die Hauptkonfigurationsdatei des Apache-Servers. Diese Datei sollten Sie nicht bearbeiten. Sie enthält in erster Linie Include-Anweisungen und globale Einstellungen. Globale Einstellungen können Sie in den entsprechenden in diesem Abschnitt aufgelisteten Konfigurationsdateien ändern. Host-spezifische Einstellungen wie DocumentRoot (absoluter Pfad) ändern Sie in der virtuellen Hostkonfiguration.

listen.conf

Diese Datei bindet Apache an bestimmte IP-Adressen und Ports. Außerdem konfiguriert diese Datei das namensbasierte virtuelle Hosting. Weitere Informationen finden Sie unter Abschnitt 31.2.2.1.1, „Namensbasierte virtuelle Hosts“.

magic

Diese Datei enthält Daten für das Modul mime_magic, mit dessen Hilfe Apache den MIME-Typ unbekannter Dateien ermittelt. Ändern Sie diese Datei nicht.

mime.types

Diese Datei enthält die dem System bekannten MIME-Typen (genau genommen ist diese Datei eine Verknüpfung mit /etc/mime.types). Bearbeiten Sie diese Datei nicht. MIME-Typen, die hier nicht aufgelistet sind, sollten Sie der Datei mod_mime-defaults.conf hinzufügen.

mod_*.conf

Dies sind die Konfigurationsdateien der in der Standardinstallation enthaltenen Module. Weitere Informationen hierzu erhalten Sie unter Abschnitt 31.4, „Installieren, Aktivieren und Konfigurieren von Modulen“. Die Konfigurationsdateien optionaler Module befinden sich im Verzeichnis conf.d.

server-tuning.conf

Diese Datei enthält Konfigurationsdirektiven für verschiedene MPMs (siehe Abschnitt 31.4.4, „Multiprocessing-Module“) und allgemeine Konfigurationsoptionen, die sich auf die Leistung von Apache auswirken. Sie können diese Datei bearbeiten, sollten den Webserver anschließend aber gründlich testen.

ssl-global.conf und ssl.*

Diese Dateien enthalten die globale SSL-Konfiguration und die SSL-Zertifikatdaten. Weitere Informationen hierzu erhalten Sie unter Abschnitt 31.6, „Einrichten eines sicheren Webservers mit SSL“.

sysconfig.d/*.conf

Diese Konfigurationsdateien werden automatisch aus /etc/sysconfig/apache2 generiert. Ändern Sie diese Dateien nicht. Bearbeiten Sie stattdessen die Dateien unter /etc/sysconfig/apache2. Speichern Sie in diesem Verzeichnis keine anderen Konfigurationsdateien.

uid.conf

Diese Datei gibt die Benutzer- und Gruppen-ID an, unter der Apache läuft. Ändern Sie diese Datei nicht.

vhosts.d/*.conf

In diesem Verzeichnis wird die virtuelle Host-Konfiguration gespeichert. Das Verzeichnis enthält Vorlagendateien für virtuelle Hosts mit und ohne SSL. Alle Dateien in diesem Verzeichnis mit der Erweiterung .conf sind automatisch Bestandteil der Apache-Konfiguration. Weitere Informationen finden Sie unter Abschnitt 31.2.2.1, „Virtuelle Hostkonfiguration“.

31.2.2 Manuelle Konfiguration von Apache

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

31.2.2.1 Virtuelle Hostkonfiguration

Virtueller Host bezieht sich auf die Fähigkeit von Apache, mehrere URI (Universal Resource Identifiers) vom gleichen physischen Computer aus bedienen zu können. In anderen Worten: Mehrere Domänen wie www.beispiel.com und www.beispiel.net können von einem einzigen Webserver auf einem physischen Computer ausgeführt werden.

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 31.2.3.1.4, „Virtuelle Hosts“) oder manuell durch Bearbeitung einer Konfigurationsdatei konfiguriert werden. In SUSE Linux Enterprise Server ist Apache unter /etc/apache2/vhosts.d/ standardmäßig für eine Konfigurationsdatei pro virtuellen 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).

Tipp
Tipp: 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.

31.2.2.1.1 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 31.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 31.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>
31.2.2.1.2 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 31.3: IP-basierte VirtualHost-Direktiven
<VirtualHost 192.168.3.101>
  ...
</VirtualHost>

<VirtualHost 192.168.3.102>
  ...
</VirtualHost>

In diesem Beispiel sind nur für die beiden zusätzlichen IP-Adressen (also nicht für 192.168.3.100 ) VirtualHost -Direktiven angegeben. Sollte für 192.168.3.100 auch eine Listen-Direktive konfiguriert sein, müsste ein eigener IP-basierter Host für die HTTP-Anforderungen an diese Schnittstelle eingerichtet werden. Anderenfalls fänden die Direktiven aus der Standardserverkonfiguration (/etc/apache2/default-server.conf) Anwendung.

31.2.2.1.3 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 31.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>

31.2.3 Konfigurieren von Apache mit YaST

Zur Konfiguration des Webservers mit YaST starten Sie YaST, und wählen Sie Netwerkdienste › 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 31.2.3.2, „HTTP-Server-Konfiguration“.

31.2.3.1 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.

31.2.3.1.1 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.

31.2.3.1.2 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 31.2.3.2.2, „Servermodule“. Klicken Sie auf Weiter, um das nächste Dialogfeld zu öffnen.

31.2.3.1.3 Standardhost

Diese Option betrifft den Standard-Webserver. Wie in Abschnitt 31.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.

HTTP-Server-Assistent: Standardhost
Abbildung 31.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 SUSE Linux Enterprise Server-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. Geben Sie hier keinen willkürlichen Namen ein – 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.

31.2.3.1.4 Virtuelle Hosts

In diesem Schritt zeigt der Assistent eine Liste der bereits konfigurierten virtuellen Hosts an (siehe Abschnitt 31.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 legen Sie fest, ob CGI-Skripten zugelassen sind und welches Verzeichnis für diese Skripten 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 31.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 Public HTML aktivieren stellen Sie den Inhalt der öffentlichen Benutzerverzeichnisse (~user/public_html/) auf dem Server unter http://www.example.com/~user bereit.

Wichtig
Wichtig: 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.

31.2.3.1.5 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 31.2.3.2, „HTTP-Server-Konfiguration“ beschriebene Dialogfeld öffnen.

HTTP-Server-Assistent: Zusammenfassung
Abbildung 31.2: HTTP-Server-Assistent: Zusammenfassung

31.2.3.2 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. Dies geschieht erst, wenn Sie das Dialogfeld mit Beenden schließen. Klicken Sie hingegen auf Abbrechen, so verlassen Sie das Konfigurationsmodul und Ihre Konfigurationsänderungen werden verworfen.

31.2.3.2.1 Ü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 31.3, „Starten und Beenden von Apache“. Diese Kommandos sind sofort wirksam und ihre Protokollmeldungen werden auch sofort angezeigt.

Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen
Abbildung 31.3: Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen
31.2.3.2.2 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 31.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.

Konfiguration des HTTP-Servers: Server-Module
Abbildung 31.4: Konfiguration des HTTP-Servers: Server-Module
31.2.3.2.3 Haupthost oder Hosts

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

31.3 Starten und Beenden von Apache

Bei Konfiguration mit YaST, wie in Abschnitt 31.2.3, „Konfigurieren von Apache mit YaST“ beschrieben, wird Apache beim Booten des Computers in den Runlevels 3 und 5 gestartet und in den Runlevels 0, 1, 2 und 6 beendet. Diese Funktionsweise können Sie mit dem Runlevel-Editor von YaST oder dem Kommandozeilenwerkzeug chkconfig ändern.

Verwenden Sie zum Starten, Stoppen und Bearbeiten von Apache auf einem laufenden System das init-Skript /usr/sbin/rcapache2. Allgemeine Informationen über Init-Skripte finden Sie unter Abschnitt 10.2.2, „Init-Skripten“. Der Befehl rcapache2 akzeptiert folgende Parameter:

status

Überprüft, ob Apache gestartet wurde.

start

Startet Apache, sofern es noch nicht läuft.

startssl

Startet Apache mit SSL-Unterstützung, sofern es noch nicht läuft. Weitere Informationen zu der SSL-Unterstützung finden Sie unter Abschnitt 31.6, „Einrichten eines sicheren Webservers mit SSL“.

stop

Stoppt Apache durch Beenden des übergeordneten Prozesses.

restart

Beendet Apache und startet es danach neu. Falls der Webserver noch nicht gelaufen ist, wird er nun gestartet.

try-restart

Stoppt Apache und startet es erneut, vorausgesetzt, es wird bereits ausgeführt.

reload oder graceful

Beendet den Webserver erst, nachdem alle durch Forking erstellten Apache-Prozesse aufgefordert wurden, ihre Anforderungen vor dem Herunterfahren zu Ende zu führen. Anstelle der beendeten Prozesse werden neue Prozesse gestartet. Dies führt zu einem vollständigen Neustart von Apache.

Tipp
Tipp: Neustart von Apache in Produktionsumgebungen

Mit dem Kommando rcapache2  reload aktivieren Sie Änderungen in der Apache-Konfiguration ohne Verbindungsunterbrechungen.

restart-graceful

Startet einen zweiten Webserver, der sofort alle eingehenden Anforderungen verarbeitet. Die vorherige Instanz des Webservers wickelt weiterhin alle bestehenden Anforderungen für eine Zeitdauer ab, die mit GracefulShutdownTimeout definiert wurde.

rcapache2 restart-graceful ist beim Upgrade auf eine neue Version oder nach dem Ändern von Konfigurationsoptionen nützlich, die einen Neustart erfordern. Die Verwendung dieser Option sorgt für eine minimale Serverabschaltdauer.

GracefulShutdownTimeout muss festgelegt werden, andernfalls veranlasst restart-graceful einen regulären Neustart. Bei der Einstellung auf null wartet der Server auf unbestimmte Zeit, bis alle verbleibenden Anforderungen vollständig verarbeitet sind.

Ein ordnungsgemäßer Start kann fehlschlagen, wenn die originale Apache-Instanz nicht alle nötigen Ressourcen löschen kann. In diesem Fall veranlasst das Kommando einen ordnungsgemäßen Stopp.

stop-graceful

Hält den Webserver nach einer Zeitdauer an, die mit GracefulShutdownTimeout konfiguriert wurde, um sicherzustellen, dass die bestehenden Anforderungen abgeschlossen werden können.

GracefulShutdownTimeout muss festgelegt sein, andernfalls verursacht stop-graceful einen ordnungsgemäßen Neustart. Bei der Einstellung auf null wartet der Server auf unbestimmte Zeit, bis alle verbleibenden Anforderungen vollständig verarbeitet sind.

configtest oder extreme-configtest

Überprüft die Syntax der Konfigurationsdateien, ohne den laufenden Webserver zu beeinträchtigen. Da dieser Test beim Starten, Neuladen oder Neustarten des Servers automatisch durchgeführt wird, ist eine explizite Ausführung des Tests in der Regel nicht notwendig (bei einem Konfigurationsfehler wird der Webserver ohnehin nicht gestartet, neu geladen oder neu gestartet). Mithilfe der Option extreme-configtest wird der Webserver unter dem Benutzernamen nobody gestartet und die Konfiguration wird geladen, sodass mehr Fehler gefunden werden können. Beachten Sie, dass die SSL-Einrichtung nicht getestet werden kann, obwohl die Konfiguration geladen wurde, da SSL-Zertifikate nicht von nobody gelesen werden können.

probe

Überprüft, ob ein Neuladen des Webservers erforderlich ist (d. h., ob sich die Konfiguration geändert hat), und schlägt die erforderlichen Argumente für den Befehl rcapache2 vor.

server-status und full-server-status

Erstellt einen Dump des kurzen oder vollständigen Statusfensters. lynx oder w3m muss installiert und das mod_status-Modul muss aktiviert sein. Außerdem muss /etc/sysconfig/apache2 unter APACHE_SERVER_FLAGS das Flag status enthalten.

Tipp
Tipp: Weitere Flags

Weitere Flags, die Sie mit dem Befehl rcapache2 angeben, werden direkt an den Webserver weitergeleitet.

31.4 Installieren, Aktivieren und Konfigurieren von Modulen

Die Apache-Software ist modular aufgebaut. Alle Funktionen außer einigen Kernaufgaben werden von Modulen durchgeführt Dies geht sogar so weit, dass selbst HTTP durch ein Modul verarbeitet wird (http_core).

Apache-Module können bei der Entwicklung in die Apache-Binaries kompiliert oder während der Laufzeit dynamisch geladen werden. Informationen zum dynamischen Laden von Modulen erhalten Sie unter Abschnitt 31.4.2, „Aktivieren und Deaktivieren von Modulen“.

Apache-Module lassen sich in vier Kategorien einteilen:

Basismodule

Basismodule sind standardmäßig in Apache enthalten. In Apache in SUSE Linux Enterprise Server sind nur mod_so (zum Laden anderer Module) und http_core kompiliert. Alle anderen Module sind als gemeinsam genutzte Objekte verfügbar: Sie sind nicht in der Server-Binärdatei enthalten, sondern können zur Laufzeit eingebunden werden.

Erweiterungsmodule

Im Allgemeinen sind Erweiterungsmodule im Apache-Softwarepaket enthalten, jedoch nicht statisch im Server kompiliert. In SUSE Linux Enterprise Server stehen diese Module als gemeinsame Objekte zur Verfügung, die während der Laufzeit in Apache geladen werden können.

Externe Module

Externe Module sind nicht in der offiziellen Apache-Distribution enthalten. SUSE Linux Enterprise Server umfasst jedoch mehrere Module.

Multiprocessing-Module (MPMs)

Multiprocessing-Module (MPMs) sind dafür verantwortlich, Anforderungen an den Webserver anzunehmen und zu verarbeiten, und stellen damit das Kernstück der Webserver-Software dar.

31.4.1 Installieren von Modulen

Wenn Sie die in Abschnitt 31.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.

In YaST können Sie weitere externe Module installieren. Starten Sie dazu YaST und wählen Sie Software › Software-Management. 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.

31.4.2 Aktivieren und Deaktivieren von Modulen

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 31.2.3.1, „HTTP-Server-Assistent“ beschriebenen Modulkonfiguration aktiviert oder deaktiviert werden. Alle anderen Module werden, wie im Abschnitt Abschnitt 31.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.

Wichtig
Wichtig: 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.

31.4.3 Basis- und Erweiterungsmodule

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/.

mod_actions

Bietet Methoden zur Ausführung eines Skripts, wenn ein bestimmter MIME-Typ (z. B. application/pdf), eine Datei mit einer bestimmten Erweiterung (z. B. .rpm) oder eine bestimmte Anforderungsmethode (z. B. GET) verlangt wird. Dieses Modul ist standardmäßig aktiviert.

mod_alias

Dieses Modul stellt die Direktiven Alias und Redirect bereit. Damit können Sie eine URI einem bestimmten Verzeichnis zuordnen (Alias) bzw. eine angeforderte URL umleiten. Dieses Modul ist standardmäßig aktiviert.

mod_auth*

Die Authentifizierungsmodule bieten verschiedene Methoden zur Authentifizierung: Basisauthentifizierung mit mod_auth_basic oder Digest-Authentifizierung mit mod_auth_digest. Die Digest-Authentifizierung in Apache 2.2 befindet sich noch im Versuchsstadium.

mod_auth_basic und mod_auth_digest funktionieren nur gemeinsam mit dem Authentifizierungsanbietermodul mod_authn_* (z. B. mod_authn_file für die Authentifizierung auf Basis einer Textdatei) und mit dem Autorisierungsmodul mod_authz_* (z. B. mod_authz_user für die Benutzerautorisierung).

Weitere Informationen zu diesem Thema erhalten Sie im Artikel Gewusst wie: Authentifizierung unter http://httpd.apache.org/docs/2.2/howto/auth.html.

mod_autoindex

Wenn keine Indexdatei vorhanden ist (z. B. index.html), generiert mod_autoindex Verzeichnislisten. Das Aussehen dieser Indizes kann konfiguriert werden. Dieses Modul ist standardmäßig aktiviert. Allerdings sind Verzeichnislisten durch die Options-Direktive standardmäßig deaktiviert – Sie müssen diese Einstellung daher in Ihrer virtuellen Hostkonfiguration ändern. Die Standardkonfigurationsdatei dieses Moduls befindet sich unter /etc/apache2/ und heißt mod_autoindex-defaults.conf.

mod_cgi

mod_cgi wird zur Ausführung von CGI-Skripten benötigt. Dieses Modul ist standardmäßig aktiviert.

mod_deflate

Mit diesem Modul kann Apache so konfiguriert werden, dass bestimmte Dateitypen automatisch vor der Bereitstellung komprimiert werden.

mod_dir

mod_dir stellt die DirectoryIndex-Direktive bereit, mit der Sie festlegen können, welche Dateien bei Anforderung eines Verzeichnisses automatisch zurückgegeben werden (standardmäßig index.html). Außerdem leitet dieses Modul automatisch zur korrekten URI um, wenn in einer Verzeichnisanforderung der nachgestellte Schrägstrich fehlt. Dieses Modul ist standardmäßig aktiviert.

mod_env

Steuert die Umgebungsvariablen, die an CGI-Skripten oder SSI-Seiten übergeben werden. Sie können Umgebungsvariablen festlegen oder aufheben oder von der Shell übergeben, die den httpd-Prozess aufgerufen hat. Dieses Modul ist standardmäßig aktiviert.

mod_expires

Mit mod_expires legen Sie fest, wie häufig Ihre Dokumente über Proxy- und Browser-Caches durch Zustellung eines Expires-Header aktualisiert werden. Dieses Modul ist standardmäßig aktiviert.

mod_include

mod_include ermöglicht die Verwendung von serverseitigen Includes (SSI), die die grundlegende Funktionalität für die dynamische Generierung von HTML-Seiten bereitstellen. Dieses Modul ist standardmäßig aktiviert.

mod_info

Dieses Modul stellt unter http://localhost/server-info/ eine umfassende Übersicht über die Serverkonfiguration bereit. Aus Sicherheitsgründen sollte der Zugriff auf diese URL generell eingeschränkt sein. Standardmäßig erhält nur localhost Zugriff auf diese URL. mod_info wird in der Datei /etc/apache2/mod_info.conf konfiguriert.

mod_log_config

Mit diesem Modul konfigurieren Sie den Aufbau der Apache-Protokolldateien. Dieses Modul ist standardmäßig aktiviert.

mod_mime

Das MIME-Modul sorgt dafür, dass eine Datei auf Basis seiner Dateinamenerweiterung mit dem korrekten MIME-Header bereitgestellt wird (z. B. text/html für HTML-Dokumente). Dieses Modul ist standardmäßig aktiviert.

mod_negotiation

Dieses Modul ist für die Inhaltsverhandlung erforderlich. Weitere Informationen erhalten Sie unter http://httpd.apache.org/docs/2.2/content-negotiation.html. Dieses Modul ist standardmäßig aktiviert.

mod_nss

Ermöglicht verschlüsselte Verbindungen zwischen Webserver und Clients über die Protokolle TLS 1.1 und TLS 1.2 anhand der Mozilla Network Security Services-Bibliothek. Weitere Informationen finden Sie im Abschnitt 31.7, „Einrichten eines sicheren Webservers mit NSS“.

mod_rewrite

Dieses Modul stellt die gleiche Funktionalität wie mod_alias bereit, bietet aber mehr Funktionen und ist somit flexibler. Mit mod_rewrite können Sie URLs auf Basis verschiedener Regeln umleiten, Header anfordern und einiges mehr.

mod_setenvif

Legt Umgebungsvariablen auf der Basis von Details aus der Client-Anforderung fest, z. B. die Browserzeichenfolge, die der Client sendet, oder die IP-Adresse des Clients. Dieses Modul ist standardmäßig aktiviert.

mod_speling

mod_speling versucht, typografische Fehler in URLs, beispielsweise die Groß-/Kleinschreibung, automatisch zu korrigieren.

mod_ssl

Dieses Modul ermöglicht verschlüsselte Verbindungen zwischen dem Webserver und den Clients. Weitere Informationen finden Sie in Abschnitt 31.6, „Einrichten eines sicheren Webservers mit SSL“. Dieses Modul ist standardmäßig aktiviert.

mod_status

Dieses Modul stellt unter http://localhost/server-status/ Informationen über die Aktivität und Leistung des Servers bereit. Aus Sicherheitsgründen sollte der Zugriff auf diese URL generell eingeschränkt sein. Standardmäßig erhält nur localhost Zugriff auf diese URL. mod_status wird in der Datei /etc/apache2/mod_status.conf konfiguriert.

mod_suexec

mod_suexec ermöglicht die Ausführung von CGI-Skripten unter einem anderen Benutzer oder einer anderen Gruppe. Dieses Modul ist standardmäßig aktiviert.

mod_userdir

Dieses Modul ermöglicht benutzerspezifische Verzeichnisse unter ~user/. In der Konfiguration muss die UserDir-Direktive angegeben sein. Dieses Modul ist standardmäßig aktiviert.

31.4.4 Multiprocessing-Module

SUSE Linux Enterprise Server bietet zwei Multiprocessing-Module (MPMs) für Apache:

31.4.4.1 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.

Wichtig
Wichtig: MPMs in diesem Dokument

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

31.4.4.2 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.

Warnung
Warnung: 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.

31.4.5 Externe Module

Nachfolgend finden Sie eine Liste aller externen Module, die mit SUSE Linux Enterprise Server ausgeliefert werden.

mod-apparmor

Unterstützt Apache bei der AppArmor-Einschränkung auf einzelne cgi-Skripte, die von Modulen wie mod_php5 und mod_perl benutzt werden.

Paketname: apache2-mod_apparmor
Weitere Informationen: Part IV, “Confining Privileges with AppArmor”
mod_mono

mod_auth_kerb bietet die Kerberos-Authentifizierung beim Apache-Webserver.

Paketname: apache2-mod_auth_kerb
Weitere Informationen: http://modauthkerb.sourceforge.net/configure.html
mod_mono

Mithilfe von mod_mono können Sie ASP.NET-Seiten auf Ihrem Server ausführen.

Paketname: apache2-mod_mono
Konfigurationsdatei: /etc/apache2/conf.d/mod_mono.conf
mod_perl

mod_perl ermöglicht die Ausführung von Perl-Skripten in einem eingebetteten Interpreter. Durch den dauerhaften, im Server eingebetteten Interpreter lassen sich Verzögerungen durch den Start eines externen Interpreters und den Start von Perl vermeiden.

Paketname: apache2-mod_perl
Konfigurationsdatei: /etc/apache2/conf.d/mod_perl.conf
Weitere Informationen: /usr/share/doc/packages/apache2-mod_perl
mod_php5

PHP ist eine serverseitige, plattformübergreifende, in HTML eingebettete Skriptsprache.

Paketname: apache2-mod_php5
Konfigurationsdatei: /etc/apache2/conf.d/php5.conf
Weitere Informationen: /usr/share/doc/packages/apache2-mod_php5
mod_python

mod_python bettet Python in den Apache-Webserver ein. Dies bringt Ihnen einen erheblichen Leistungsgewinn und zusätzliche Flexibilität bei der Entwicklung webbasierter Anwendungen.

Paketname: apache2-mod_python
Weitere Informationen: /usr/share/doc/packages/apache2-mod_python
mod_security

mod_security bietet eine Firewall zum Schutz von Webanwendungen vor verschiedenen Angriffen. Auch die Überwachung des HTTP-Datenverkehrs und die Echtzeitanalyse werden damit ermöglicht.

Paketname: apache2-mod_security2
Konfigurationsdatei: /etc/apache2/conf.d/mod_security2.conf
Weitere Informationen: /usr/share/doc/packages/apache2-mod_security2
Dokumentation: http://modsecurity.org/documentation/

31.4.6 Kompilieren von Modulen

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:

  • /usr/sbin/apxs2: Für die Entwicklung von Erweiterungsmodulen, die mit allen MPMs verwendbar sind. Die Module werden im Verzeichnis /usr/lib/apache2 installiert.

  • /usr/sbin/apxs2-prefork: Für die Entwicklung von Prefork-MPM-Modulen. Die Module werden im Verzeichnis /usr/lib/apache2-prefork installiert.

  • /usr/sbin/apxs2-worker: Für die Entwicklung von Worker-MPM-Modulen. Die Module werden im Verzeichnis /usr/lib/apache2-worker installiert.

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.

31.5 Aktivieren von CGI-Skripten

Die Common Gateway Interface (CGI) von Apache ermöglicht die dynamische Erstellung von Inhalten mit Programmen bzw. so genannten CGI-Skripten. CGI-Skripten können in jeder beliebigen Programmiersprache geschrieben sein. In der Regel werden aber die Skriptsprachen Perl oder PHP verwendet.

Damit Apache in der Lage ist, die von CGI-Skripts erstellten Inhalte bereitzustellen, muss das Modul mod_cgi aktiviert sein. Außerdem ist mod_alias erforderlich. Beide Module sind standardmäßig aktiviert. Informationen zur Aktivierung von Modulen finden Sie unter Abschnitt 31.4.2, „Aktivieren und Deaktivieren von Modulen“.

Warnung
Warnung: CGI-Sicherheit

Die Zulassung der CGI-Skriptausführung auf dem Server ist ein Sicherheitsrisiko. Weitere Informationen finden Sie in Abschnitt 31.8, „Vermeiden von Sicherheitsproblemen“.

31.5.1 Konfiguration in Apache

In SUSE Linux Enterprise Server ist die Ausführung von CGI-Skripts 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 31.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.

Beispiel 31.5: CGI-Konfiguration für virtuelle Hosts
ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"1

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI2
 AddHandler cgi-script .cgi .pl3
 Order allow,deny4
 Allow from all
</Directory>

1

Fordert Apache auf, alle Dateien in diesem Verzeichnis als CGI-Skripten zu behandeln

2

Aktiviert die Ausführung von CGI-Skripten

3

Fordert den Server auf, Dateien mit den Erweiterungen .pl und .cgi als CGI-Skripten zu behandeln. passen Sie diese Anweisung entsprechend Ihren Anforderungen an

4

Die Order- und Allow-Anweisungen legen den Standardzugriffsstatus sowie die Reihenfolge fest, in der Allow- und Deny-Anweisungen ausgewertet werden. In diesem Fall werden allow-Anweisungen vor deny-Anweisungen ausgewertet und der universelle Zugriff ist möglich.

31.5.2 Ausführen eines Beispielskripten

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 – dies ist in den meisten Fällen HTML, 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 31.8, „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://example.com/cgi-bin/test.cgi auf. Nun sollte der CGI/1.0-Testskriptbericht angezeigt werden.

31.5.3 CGI-Fehlerbehebung

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

CGI-Fehlerbehebung
  • Haben Sie den Server nach der Konfigurationsänderung neu geladen? Überprüfen Sie dies mit rcapache2 probe.

  • Falls Sie ein benutzerdefiniertes CGI-Verzeichnis eingerichtet haben, ist dieses richtig konfiguriert? Falls Sie sich nicht sicher sind, führen Sie das Skript im CGI-Standardverzeichnis /srv/www/cgi-bin/ aus. Rufen Sie das Skript dazu mit http://localhost/cgi-bin/test.cgi auf.

  • Wurden die richtigen Berechtigungen zugewiesen? Wechseln Sie in das CGI-Verzeichnis und führen Sie ls -l test.cgi aus. Die Befehlsausgabe sollte mit folgender Zeile beginnen:

    -rwxr-xr-x  1 root root
  • Überprüfen Sie das Skript auf Programmierfehler. Wenn Sie die Datei test.cgi nicht bearbeitet haben, dürfte sie keine Programmierfehler enthalten. Falls Sie aber eigene Programme verwenden, sollten Sie diese immer auf Programmierfehler untersuchen.

31.6 Einrichten eines sicheren Webservers mit SSL

Wenn sensible Daten wie Kreditkarteninformationen zwischen Webserver und Client übertragen werden, ist eine sichere, verschlüsselte Verbindung mit Authentifizierung wünschenswert. mod_ssl bietet mittels der Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS) eine sichere Verschlüsselung für die HTTP-Kommunikation zwischen einem Client und dem Webserver. Wenn Sie SSL/TSL verwenden, wird zwischen dem Webserver und dem Client eine private Verbindung eingerichtet. Die Datenintegrität bleibt dadurch gewährleistet und Client und Server können sich gegenseitig authentifizieren.

Zu diesem Zweck sendet der Server vor der Beantwortung von Anforderungen an eine URL ein SSL-Zertifikat mit Informationen, die die Identität des Servers nachweisen. Dies garantiert, dass der Server eindeutig der richtige Endpunkt der Kommunikation ist. Außerdem wird durch das Zertifikat eine verschlüsselte Verbindung zwischen dem Client und dem Server hergestellt, die sicherstellt, dass Informationen ohne das Risiko der Freigabe sensitiver Klartextinhalte übertragen werden.

mod_ssl implementiert die SSL/TSL-Protokolle nicht selbst, sondern fungiert als Schnittstelle zwischen Apache und einer SSL-Bibliothek. In SUSE Linux Enterprise Server wird die OpenSSL-Bibliothek verwendet. OpenSSL wird bei der Installation von Apache automatisch installiert.

Anmerkung
Anmerkung: TLS-Versionen über TLS 1.0

Die openssl-Bibliothek unterstützt TLS-Versionen bis einschließlich TLS 1.0. Es gibt keine Unterstützung für höhere TLS-Versionen wie 1.1 oder 1.2. mod_nss im Paket apache2-mod_nss bietet TLS 1.1 und 1.2 über die Mozilla Network Security Services-Bibliothek. Weitere Informationen finden Sie im Abschnitt 31.7, „Einrichten eines sicheren Webservers mit NSS“.

Die Verwendung von mod_ssl in Apache erkennen Sie in URLs am Präfix https:// (statt http://).

Tipp
Tipp: Beispielzertifikat

Ein Beispielzertifikat für eine hypothetische Firma Snake Oil ist zur Installation des Pakets apache2-example-certificates verfügbar.

31.6.1 Erstellen eines SSL-Zertifikats

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.

Tipp
Tipp: 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.

31.6.1.1 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.

Wichtig
Wichtig: Nur zu Testzwecken

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

31.6.1.2 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 31.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. Unter Common Name (allgemeiner Name) müssen Sie den Namen der Zertifizierungsstelle eingeben. Geben Sie hier einen aussagekräftigen Namen ein, beispielsweise Zertifizierungsstelle von My company.

    Wichtig
    Wichtig: 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).

    Wichtig
    Wichtig: 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.beispiel.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 von SERVER 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.

    Wichtig
    Wichtig: 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.

Wichtig
Wichtig: 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.

31.6.1.3 Anfordern eines offiziell signierten Zertifikats

Es gibt verschiedene offizielle Zertifizierungsstellen, die Ihre Zertifikate signieren. Zertifizierungsstellen sind vertrauenswürdige unabhängige Parteien. Einem Zertifikat, das durch eine solche Zertifizierungsstelle signiert wurde, kann daher voll und ganz vertraut werden. Sichere Webserver, deren Inhalte für die Öffentlichkeit bereitstehen, verfügen in der Regel über ein offiziell signiertes Zertifikat.

Die bekanntesten offiziellen Zertifizierungsstellen sind Thawte (http://www.thawte.com/) und Verisign (http://www.verisign.com). Diese und andere Zertifizierungsstellen sind bereits in Browsern kompiliert. Zertifikate, die von diesen Zertifizierungsstellen signiert wurden, werden daher von Browsern automatisch akzeptiert.

Wenn Sie ein offiziell signiertes Zertifikat anfordern, senden Sie kein Zertifikat an die Zertifizierungsstelle, sondern eine CSR (Certificate Signing Request, Zertifikatsignierungsanforderung). Zur Erstellung einer CSR rufen Sie das Skript /usr/share/ssl/misc/CA.sh -newreq auf.

Das Skript fragt zunächst nach dem Passwort für die Verschlüsselung der CSR. Danach müssen Sie einen Distinguished Name (DN) eingeben. 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, überprüft und 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. Unter Common Name (allgemeiner Name) müssen Sie den Namen der Zertifizierungsstelle eingeben. Geben Sie hier einen aussagekräftigen Namen ein, beispielsweise Zertifizierungsstelle von My company. Zum Schluss müssen Sie noch ein Challenge Passwort (zur Vernichtung des Zertifikats, falls der Schlüssel kompromittiert wird) und einen alternativen Unternehmensnamen eingeben.

Die CSR wird in dem Verzeichnis erstellt, aus dem Sie das Skript aufgerufen haben. Der Name der CSR-Datei lautet newreq.pem.

31.6.2 Konfigurieren von Apache mit SSL

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.

Wichtig
Wichtig: 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 15.4.1, “Configuring the Firewall with YaST”).

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 31.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:

  • DocumentRoot

  • ServerName

  • ServerAdmin

  • ErrorLog

  • TransferLog

31.6.2.1 Namensbasierte virtuelle Hosts und SSL

Auf einem Server mit nur einer IP-Adresse können standardmäßig nicht mehrere SSL-aktivierte virtuelle Hosts laufen. Für ein namensbasiertes virtuelles Hosting muss Apache wissen, welcher Servername angefordert wurde. Das Problem ist dabei, dass SSL-Verbindungen erst gelesen werden können, nachdem die Verbindung (unter Verwendung des standardmäßigen virtuellen Hosts) bereits hergestellt wurde. Demzufolge erhalten Benutzer eine Warnmeldung, die besagt, dass das Zertifikat nicht mit dem Servernamen übereinstimmt.

SUSE Linux Enterprise Server bietet eine Erweiterung des SSL-Protokolls namens Server Name Indication (SNI), die dieses Problem behebt, indem der Name der virtuellen Domäne als Teil der SSL-Verhandlung gesendet wird. Dies ermöglicht dem Server ein frühes Umschalten zur korrekten virtuellen Domäne, wodurch der Browser das richtige Zertifikat erhält.

SNI ist in SUSE Linux Enterprise Server standardmäßig aktiviert. Für die Aktivierung von namensbasierten virtuellen Hosts für SSL müssen Sie den Server wie in Abschnitt 31.2.2.1.1, „Namensbasierte virtuelle Hosts“ beschrieben konfigurieren. (Beachten Sie, dass für SSL Port 443 anstelle von Port 80 benötigt wird.)

Wichtig
Wichtig: SNI - Browserunterstützung

SNI muss auf der Client-Seite unterstützt werden. Auch wenn die meisten Browser SNI unterstützen, fehlt die SNI-Unterstützung bei einigen Browsern für Mobilgeräte sowie im Internet Explorer und in Safari unter Windows* XP. Weitere Informationen finden Sie in http://en.wikipedia.org/wiki/Server_Name_Indication.

Konfigurieren Sie die Behandlung von Browsern ohne SNI-Fähigkeit mit der Direktive SSLStrictSNIVHostCheck. Wenn SNI in der Serverkonfiguration auf on gesetzt ist, werden Browser ohne SNI-Fähigkeit für alle virtuellen Hosts abgelehnt. Wenn für SNI on in einer VirtualHost-Direktive festgelegt ist, wird der Zugriff auf den konkreten virtuellen Host abgelehnt.

Wenn in der Serverkonfiguration off festgelegt ist, verhält sich der Server wie ohne SNI-Unterstützung. SSL-Anforderungen werden durch den ersten (für Port 443) definierten virtuellen Host bearbeitet.

31.7 Einrichten eines sicheren Webservers mit NSS

Das Modul mod_nss sorgt für die starke Verschlüsselung mit den TLS-Protokollen 1.1 und 1.2 (Transport Layer Security), die bei Verwendung von Apache mit mod_ssl nicht zur Verfügung stehen.

Die SSL-/TLS-Unterstützung im Paket apache2 wird in der Regel durch mod_ssl gewährleistet; dieses Modul bietet SSL/TLS über die openssl Cryptographic Library. Die in SUSE Linux Enterprise Server 11 SP4 verwendete Version der openssl-Bibliothek unterstützt ausschließlich TLS bis Version 1.0. Die Unterstützung für TLS 1.1 und 1.2 kann nur durch Versionen erfolgen, die nicht mit der Mehrzahl der Pakete in SLE 11 SP4 kompatibel sind. Alternativ nutzen Sie die Mozilla Network Security Services-Bibliothek im Paket mozilla-nss.

Anmerkung
Anmerkung: Unterstützung für SSLv2

mod_nss bietet keine Unterstützung für SSLv2. Wenn Sie das SSLv2-Protokoll benötigen, müssen Sie mod_ssl verwenden.

mod_ssl und mod_nss können gleichzeitig initialisiert werden; die Protokoll-Handler (SSLEngine on für mod_ssl bzw. NSSEngine on für mod_nss) können jedoch nicht gleichzeitig aktiviert sein, weder global noch im Kontext eines VirtualHost-Konfigurationsdirektivenblocks.

Wenn nur bei einem VirtualHost-Abschnitt die Direktive NSSEngine aktiviert ist (on), hat diese Direktive für einen Port, der durch Apache überwacht wird, Vorrang vor allen anderen VirtualHost-Deklarationen (in deren Kontext SSLEngine aktiviert/on sein kann). Die gleichzeitige Nutzung beider Module für unterschiedliche VirtualHosts unter derselben IP-Adresse und an demselben Port ist nicht möglich. Wenn Sie die Unterstützung für verschlüsselte Verbindungen sowohl mit mod_nss als auch mit mod_ssl benötigen, sollten Sie mehrere IP-Adressen verwenden und die Kryptographiemodule des Servers an die jeweiligen IP-Adressen binden. Falls Sie nicht beide Kryptographiemodule gleichzeitig benötigen, wird empfohlen, nur ein Modul zu nutzen und das andere Modul zu deaktivieren.

mmod_nss verwendet ein Datenbankformat für die Server- und CA-Zertifikate und den privaten Schlüssel. Aus diesem Grund müssen vorhandene mod_ssl-basierte Zertifikate für den Gebrauch mit mmod_nss konvertiert werden. Das Paket apache2-mod_nss enthält das Perl-Skript /usr/sbin/mod_nss_migrate.pl für diese Aufgabe. Das Skript erstellt eine neue Datenbank.

Mit dem folgenden Befehl rufen Sie eine Liste der Zertifikate ab, die sich in der NSS-Datenbank befinden:

certutil -d /etc/apache2/mod_nss.d -L

Weitere Informationen zum NSS-Datenbankverwaltungsprogramm certutil erhalten Sie mit dem Befehl certutil --help.

Die Datei /etc/apache2/conf.d/mod_nss.conf ist die standardmäßige Konfigurationsdatei für das Paket mod_nss. Weitere Informationen finden Sie in den Kommentaren in dieser Datei.

31.8 Vermeiden von Sicherheitsproblemen

Ein dem öffentlichen Internet ausgesetzter Webserver erfordert ständige Wartungs- und Verwaltungsarbeiten. Sicherheitsprobleme, verursacht durch die Software wie auch durch versehentliche Fehlkonfigurationen, sind kaum zu vermeiden. Im Folgenden einige Tipps zur Verbesserung der Sicherheit.

31.8.1 Stets aktuelle Software

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:

31.8.2 DocumentRoot-Berechtigungen

In SUSE Linux Enterprise Server sind das DocumentRoot -Verzeichnis /srv/www/htdocs 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 sind, kann 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.

31.8.3 Zugriff auf das Dateisystem

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 31.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.

31.8.4 CGI-Skripten

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. Skripts, die vom Server ausgeführt werden, sollten nur aus Quellen stammen, denen der Serveradministrator vertraut. Keine gute Idee ist es, den Benutzern die Ausführung ihrer eigenen Skripts 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 SUSE Linux Enterprise Server ist es generell nicht gestattet, CGI-Skripts 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.

31.8.5 Benutzerverzeichnisse

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 SUSE Linux Enterprise Server sind .htaccess-Dateien standardmäßig aktiviert. Den Benutzern ist es allerdings nicht erlaubt, Option-Direktiven mit mod_userdir zu überschreiben (siehe hierzu die Konfigurationsdatei /etc/apache2/mod_userdir.conf).

31.9 Fehlersuche

Wenn sich Apache nicht starten lässt, eine Webseite nicht angezeigt werden kann oder Benutzer keine Verbindung zum Webserver herstellen können, müssen Sie die Ursache des Problems herausfinden. Im Folgenden werden einige nützliche Ressourcen vorgestellt, die Ihnen bei der Fehlersuche behilflich sein können:

Ausgabe von rcapache2

Statt den Webserver mit der Binärdatei /usr/sbin/httpd2 zu starten und zu stoppen, verwenden Sie das Skript rcapache2 (siehe Abschnitt 31.3, „Starten und Beenden von Apache“). Es bietet umfassende Informationen über Fehler und stellt außerdem Tipps und Hinweise zur Behebung von Konfigurationsfehlern zur Verfügung.

Protokolldateien und Ausführlichkeitsgrad

Bei schwerwiegenden und nicht schwerwiegenden Fehlern finden Sie mögliche Ursachen in den Apache-Protokolldateien, insbesondere in der standardmäßig im Verzeichnis /var/log/apache2/error_log gespeicherten Fehlerprotokolldatei. Mit der Direktive LogLevel können Sie im Übrigen die Ausführlichkeit der protokollierten Meldungen einstellen. Dies ist z. B. nützlich, wenn Sie mehr Details benötigen.

Tipp
Tipp: Ein einfacher Test

Sie können die Apache-Protokollmeldungen mit dem Befehl tail -F /var/log/apache2/ my_error_log überwachen. Führen Sie anschließend den Befehl rcapache2 restart aus. Versuchen Sie anschließend eine Verbindung mit einem Browser herzustellen und überprüfen Sie dort die Ausgabe.

Firewall und Ports

Es wird häufig versäumt, die Ports für Apache in der Firewall-Konfiguration des Servers zu öffnen. YaST bietet bei der Konfiguration von Apache eine eigene Option, die sich dieses speziellen Themas annimmt (siehe Abschnitt 31.2.3, „Konfigurieren von Apache mit YaST“). Bei der manuellen Konfiguration von Apache können Sie die Ports für HTTP und HTTPS in der Firewall über das Firewall-Modul von YaST öffnen.

Falls sich Ihr Problem nicht mithilfe der vorgenannten Ressourcen beheben lässt, finden Sie weitere Informationen in der Apache-Fehlerdatenbank, die online unter http://httpd.apache.org/bug_report.html zur Verfügung steht. Sie können sich auch an die Apache-Benutzer-Community wenden, die Sie über eine Mailingliste unter http://httpd.apache.org/userslist.html erreichen. Des Weiteren empfehlen wir die Newsgroup comp.infosystems.www.servers.unix.

31.10 Weiterführende Informationen

Das Paket apache2-doc, das an verschiedenen Orten bereitgestellt wird, enthält das vollständige Apache-Handbuch für die lokale Installation und Referenz. Das Handbuch ist nicht in der Standardinstallation enthalten. Am schnellsten installieren Sie es mit dem Befehl zypper in apache2-doc. Nach der Installation steht das Apache-Handbuch unter http://localhost/manual/ zur Verfügung. Unter http://httpd.apache.org/docs-2.2/ können Sie auch im Web darauf zugreifen. SUSE-spezifische Konfigurationstipps finden Sie im Verzeichnis /usr/share/doc/packages/apache2/README.*.

31.10.1 Apache 2.2

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.

31.10.2 Apache Module

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

31.10.3 Entwicklung

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

Informationen für Apache-Entwickler

http://httpd.apache.org/dev/

Dokumentation für Apache-Entwickler

http://httpd.apache.org/docs/2.2/developer/

Entwickeln von Apache-Modulen mit Perl und C

http://www.modperl.com/

31.10.4 Verschiedene Informationsquellen

Wenn Sie in SUSE Linux Enterprise Server Probleme mit Apache haben, werfen Sie einen Blick in die technische Informationssuche unter http://www.novell.com/support. 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.

Diese Seite drucken