Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Server-Dokumentation / Administrationshandbuch / Services / Der HTTP-Server Apache
Gilt für SUSE Linux Enterprise Server 12 SP5

32 Der HTTP-Server Apache

Gemäß der Umfrage von http://www.netcraft.com/ ist der HTTP-Server Apache (oder kurz Apache) weltweit der meistgenutzte Webserver. Der von der Apache Software Foundation (http://www.apache.org/) entwickelte Apache-Server läuft auf fast allen Betriebssystemen. SUSE® Linux Enterprise Server umfasst Apache, Version 2.4. 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.

32.1 Kurzanleitung

In diesem Abschnitt finden Sie Informationen zum schnellen Einrichten und Starten von Apache. Zur Installation und Konfiguration von Apache müssen Sie root-Benutzer sein.

32.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 16, 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 25, 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 16.4.1, “Configuring the Firewall with YaST”.

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

Vorgehen 32.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 Ansicht › Schemata und schließlich Web- und LAMP-Server.

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

32.1.3 Start

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

Um sicherzustellen, dass Apache beim Booten des Computers in den Zielen multi-user.target und graphical.target automatisch gestartet wird, führen Sie das folgende Kommando aus:

root # systemctl enable apache2

Weitere Informationen zu den systemd-Zielen in SUSE Linux Enterprise Server sowie eine Beschreibung zu YaST Services Manager finden Sie unter Abschnitt 13.4, „Verwalten von Services mit YaST“.

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

Vorgehen 32.2: Ü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 32.9, „Fehlerbehebung“.

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.

32.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 manuell mit systemctl reload apache2 neu oder verwenden Sie eine der in Abschnitt 32.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 32.2.3.2, „HTTP-Server-Konfiguration“ beschrieben.

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

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

32.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 Direktiven genannt). 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 32.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 32.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 32.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 32.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 32.2.2.1, „Virtuelle Hostkonfiguration“.

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

32.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 apache2ctl -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 32.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.4/mod/quickreference.html.

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

Erstellen Sie zunächst je einen <VirtualHost>-Block für die einzelnen zu bedienenden namensbasierten Hosts. Jeder <VirtualHost>-Block muss mindestens eine ServerName-Direktive enthalten, mit der die zu bedienenden Hosts zugewiesen werden, sowie eine DocumentRoot-Direktive, aus der der Speicherort im Dateisystem hervorgeht, an dem sich der Inhalt für diesen Host befindet.

Beispiel 32.1: Einfache Beispiele für namensbasierte VirtualHost-Einträge
<VirtualHost *:80>
# This first-listed virtual host is also the default for *:80
ServerName www.example.com
ServerAlias example.com
DocumentRoot /srv/www/htdocs/domain
</VirtualHost>

<VirtualHost *:80>
ServerName other.example.com
DocumentRoot /srv/www/htdocs/otherdomain
</VirtualHost>

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

Anstelle der IP-Adresse wird auch ein Platzhalterzeichen (*) akzeptiert. IPv6-Adressen müssen in eckige Klammern eingeschlossen werden.

Beispiel 32.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>
32.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 32.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.

32.2.2.1.3 Basiskonfiguration eines virtuellen Hosts

Die Konfiguration eines virtuellen Hosts sollte mindestens die folgenden Direktiven enthalten, um den virtuellen Host einzurichten. 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">
  Require all granted
</Directory>
Anmerkung
Anmerkung: Require all granted

In vorherigen Versionen von Apache wurde die Anweisung Require all granted wie folgt ausgedrückt:

Order allow,deny
Allow from all

Diese alte Syntax wird vom mod_access_compat-Modul nach wie vor unterstützt.

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

Beispiel 32.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">
  Require all granted
  </Directory>
</VirtualHost>

32.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 32.2.3.2, „HTTP-Server-Konfiguration“.

32.2.3.1 HTTP-Server-Assistent

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

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

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

32.2.3.1.3 Standardhost

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

Mit Alias-Direktiven können URLs zu Speicherorten in physischen Dateisystemen 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 /icons für die in der Verzeichnisindex-Ansicht angezeigten Apache-Symbole 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.

32.2.3.1.4 Virtuelle Hosts

In diesem Schritt zeigt der Assistent eine Liste der bereits konfigurierten virtuellen Hosts an (siehe Abschnitt 32.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 32.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.

32.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. Zum Ändern bestimmter Einstellungen 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 32.2.3.2, „HTTP-Server-Konfiguration“ beschriebene Dialogfeld öffnen.

HTTP-Server-Assistent: Zusammenfassung
Abbildung 32.2: HTTP-Server-Assistent: Zusammenfassung

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

32.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 die Zugriffs- oder die Fehlerprotokolldatei ü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 32.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 32.3: Konfiguration des HTTP-Servers: Überwachen von Ports und Adressen
32.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 32.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.

Konfiguration des HTTP-Servers: Server-Module
Abbildung 32.4: Konfiguration des HTTP-Servers: Server-Module
32.2.3.2.3 Haupthost oder Hosts

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

32.3 Starten und Beenden von Apache

Bei Konfiguration mit YaST, wie in Abschnitt 32.2.3, „Konfigurieren von Apache mit YaST“ beschrieben, wird Apache beim Booten des Computers in multi-user.target und graphical.target gestartet. Diese Funktionsweise können Sie mit YaST Services Manager oder dem Kommandozeilenwerkzeug systemctl (systemctl enable oder systemctl disable) ändern.

Mit den Kommandos systemctl bzw. apachectl können Sie Apache auf einem laufenden System starten, stoppen und ändern.

Allgemeine Informationen zu systemctl-Kommandos finden Sie unter Abschnitt 13.2.1, „Verwalten von Diensten auf einem laufenden System“.

systemctl status apache2

Überprüft, ob Apache gestartet wurde.

systemctl start apache2

Startet Apache, sofern es noch nicht läuft.

systemctl stop apache2

Stoppt Apache durch Beenden des übergeordneten Prozesses.

systemctl restart apache2

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

systemctl try-restart apache2

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

systemctl reload apache2

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 diesem Kommando können Änderungen in der Apache-Konfiguration aktiviert werden, ohne dass die Verbindung unterbrochen wird.

systemctl stop apache2

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

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

apachectl status und apachectl fullstatus

Erstellt einen Dump des kurzen oder vollständigen Statusfensters. Das Modul mod_status muss aktiviert und ein Textbrowser (z. B. links oder w3m) muss installiert sein. Außerdem muss /etc/sysconfig/apache2 unter APACHE_SERVER_FLAGS das Flag status enthalten.

Tipp
Tipp: Weitere Flags

Wenn Sie weitere Flags für die Kommandos festlegen, werden diese an den Webserver übergeben.

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

32.4.1 Installieren von Modulen

Wenn Sie die in Abschnitt 32.1.2, „Installation“ beschriebene Standardinstallation vorgenommen haben, sind folgende Module bereits installiert: alle Basis- und Erweiterungsmodule, das Multiprocessing-Modul Prefork MPM sowie das externe Modul 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 Ansicht › Suche und suchen Sie nach apache. Die Ergebnisliste zeigt nun neben anderen Paketen alle verfügbaren externen Apache-Module an.

32.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 32.2.3.1, „HTTP-Server-Assistent“ beschriebenen Modulkonfiguration aktiviert oder deaktiviert werden. Alle anderen Module werden, wie im Abschnitt Abschnitt 32.2.3.2.2, „Servermodule“ beschrieben, aktiviert oder deaktiviert.

Mit den Kommandos a2enmod MODUL bzw. a2dismod MODUL können Sie die Module stattdessen manuell aktivieren oder deaktivieren. a2enmod -l gibt eine Liste aller derzeit 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 unter /etc/apache2/conf.d/ und werden standardmäßig in /etc/apache2/default-server.conf geladen. Für eine feinere Steuerung können Sie die Einbeziehung in /etc/apache2/default-server.conf auskommentieren und sie nur zu bestimmten virtuellen Hosts hinzufügen. Beispiele hierzu finden Sie in der Datei /etc/apache2/vhosts.d/vhost.template.

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

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

Dank mod_http2 unterstützt Apache das HTTP/2-Protokoll. Dies kann durch Angabe von Protocols h2 http/1.1 in einem VirtualHost aktiviert werden.

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.4/content-negotiation.html. Dieses Modul ist standardmäßig aktiviert.

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_spelling

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

32.4.4 Multiprocessing-Module

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

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

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

32.4.5 Externe Module

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

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

32.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. Das Installationsverzeichnis ist /usr/lib64/apache2.

  • /usr/sbin/apxs2-prefork: Für die Entwicklung von Prefork-MPM-Modulen. Das Installationsverzeichnis ist /usr/lib64/apache2-prefork.

  • /usr/sbin/apxs2-worker: Für die Entwicklung von Worker-MPM-Modulen. Das Installationsverzeichnis ist /usr/lib64/apache2-worker.

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

cd /path/to/module/source
apxs2 -cia MODULE.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.

32.5 Aktivieren von CGI-Skripten

Die Common Gateway Interface (CGI) von Apache ermöglicht die Erstellung dynamischer Inhalte mit Programmen bzw. sogenannten 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 32.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 32.8, „Vermeiden von Sicherheitsproblemen“.

32.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 32.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 32.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
 Require all granted4
</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 Require-(Anfordern-)Direktive bestimmt den standardmäßigen Zugriffsstatus. In diesem Fall wird der uneingeschränkte Zugriff auf das angegebenene Verzeichnis erteilt. Weitere Informationen zur Authentifizierung und Autorisierung finden Sie in http://httpd.apache.org/docs/2.4/howto/auth.html.

32.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 der Regel 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. Bearbeiten Sie die Datei so, dass sie #!/bin/sh als erste Zeile enthält.

Dateien, auf die der Webserver zugreifen kann, sollten im Besitz des root-Benutzers sein. Weitere Informationen hierzu finden Sie im Abschnitt Abschnitt 32.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.

32.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? Falls nicht, laden Sie ihn mit systemctl reload apache2 neu.

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

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

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

32.6.1 Erstellen eines SSL-Zertifikats

Wenn Sie SSL/TLS 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 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/TLS und diesbezügliche Festlegungen finden Sie unter http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html.

32.6.1.1 Erstellen eines Dummy-Zertifikats

Zum Erstellen eines Dummy-Zertifikats rufen Sie das Skript /usr/bin/gensslcert auf. Es erstellt oder überschreibt die unten aufgelisteten Dateien. Verwenden Sie die optionalen Schalter 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

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.

32.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 (CA) signiertes Zertifikat aus. Die Besucher einer solchen Website erhalten eine Warnung wie Diese Website ist nicht vertrauenswürdig, da die Webbrowser keine eigensignierten Zertifikate erkennen.

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.

Zunächst generieren Sie einen Antrag auf Ausstellung eines Zertifikats (CSR). Hierzu verwenden Sie openssl mit dem Zertifikatsformat PEM. In diesem Schritt werden Sie aufgefordert, einen Passwortsatz anzugeben und mehrere Fragen zu beantworten. Merken Sie sich diesen Passwortsatz; Sie werden ihn später benötigen.

sudo openssl req -new > new.cert.csr
Generating a 1024 bit RSA private key
..++++++
.........++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:1
Verifying - Enter PEM pass phrase:2
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:3
State or Province Name (full name) [Some-State]:4
Locality Name (eg, city) []:5
Organization Name (eg, company) [Internet Widgits Pty Ltd]:6
Organizational Unit Name (eg, section) []:7
Common Name (for example server FQDN, or YOUR name) []:8
Email Address []:9

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:10
An optional company name []:11

1

Geben Sie Ihren Passwortsatz ein,

2

... wiederholen Sie die Eingabe (und merken Sie sie sich).

3

Geben Sie Ihren zwei Buchstaben umfassenden Ländercode ein, z. B. GB oder CZ.

4

Geben Sie den Namen des Bundeslands oder Kantons ein, in dem Sie leben.

5

Geben Sie den Namen des Ortes ein, z. B. Prag.

6

Geben Sie den Namen der Organisation ein, für die Sie arbeiten.

7

Geben Sie Ihre Organisationseinheit ein oder lassen Sie dieses Feld leer, wenn Sie keine Organisationseinheit besitzen.

8

Geben Sie den Domänennamen des Servers bzw. Ihren Vor- und Nachnamen ein.

9

Geben Sie Ihre geschäftliche Email-Adresse ein.

10

Lassen Sie das Challenge-Passwort leer; ansonsten müssen Sie es bei jedem Neustart des Apache-Webservers eingeben.

11

Geben Sie optional den Namen des Unternehmens ein oder lassen Sie dieses Feld leer.

Nun können Sie das Zertifikat generieren. Verwenden Sie openssl erneut und nutzen Sie wieder das standardmäßige PEM-Format für das Zertifikat.

Vorgehen 32.3: Generieren des Zertifikats
  1. Exportieren Sie den privaten Teil des Schlüssels in new.cert.key. Sie werden aufgefordert, den Passwortsatz einzugeben, den Sie beim Erstellen des Zertifizierungsantrags (CSR) festgelegt haben.

    sudo openssl rsa -in privkey.pem -out new.cert.key
  2. Generieren Sie den öffentlichen Teil des Zertifikats gemäß den Daten, die Sie im Ausstellungsantrag angegeben haben. Mit der Option -days geben Sie den Zeitraum (in Tagen) an, nach dem das Zertifikat abläuft. Sie können ein Zertifikat widerrufen oder vor Ablauf ersetzen.

    sudo openssl x509 -in new.cert.csr -out new.cert.cert -req \
    -signkey new.cert.key -days 365
  3. Kopieren Sie die Zertifikatsdateien in die entsprechenden Verzeichnisse, so dass sie vom Apache-Server gelesen werden können. Achten Sie darauf, dass der private Schlüssel /etc/apache2/ssl.key/server.key nicht allgemein lesbar ist, das öffentliche PEM-Zertifikat /etc/apache2/ssl.crt/server.crt dagegen schon.

    sudo cp new.cert.cert /etc/apache2/ssl.crt/server.crt
    sudo cp new.cert.key /etc/apache2/ssl.key/server.key
Tipp
Tipp: Speicherort des öffentlichen Zertifikats

Der letzte Schritt besteht darin, die öffentliche Zertifikatdatei aus dem Verzeichnis /etc/apache2/ssl.crt/server.crt in ein Verzeichnis zu kopieren, in dem die Benutzer auf die Datei zugreifen können. Aus diesem Verzeichnis können die Benutzer sie 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.

32.6.1.3 Anfordern eines offiziell signierten Zertifikats

Es gibt mehrere 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. Eine Liste der am häufigsten genutzten Zertifizierungsstellen finden Sie unter https://en.wikipedia.org/wiki/Certificate_authority#Providers.

Wenn Sie ein offiziell signiertes Zertifikat anfordern, senden Sie kein Zertifikat an die Zertifizierungsstelle, sondern eine CSR (Certificate Signing Request, Zertifikatsignierungsanforderung). Geben Sie zum Erstellen einer CSR den folgenden Befehl ein:

openssl req -new -newkey rsa:2048 -nodes -keyout newkey.pem -out newreq.pem

Sie werden aufgefordert, einen Distinguished Name (DN) einzugeben. 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.

32.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 16.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 (Groß- und Kleinschreibung beachten!). 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 32.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

32.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 32.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. SNI wird allerdings von den meisten Browsern unterstützt, ausgenommen von bestimmten älteren Browsern. Weitere Informationen finden Sie unter https://en.wikipedia.org/wiki/Server_Name_Indication#Support.

Mit der Direktive SSLStrictSNIVHostCheck konfigurieren Sie die Handhabung von Browsern ohne SNI-Fähigkeit. 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.

32.7 Ausführen mehrerer Apache-Instanzen auf demselben Server

Ab SUSE® Linux Enterprise Server  12 SP1 können Sie mehrere Apache-Instanzen auf einem einzigen Server ausführen. So erhalten Sie mehrere Vorteile im Vergleich zum Ausführen mehrerer virtueller Hosts (siehe Abschnitt 32.2.2.1, „Virtuelle Hostkonfiguration“):

  • Wenn ein virtueller Host zeitweise deaktiviert werden muss, müssen Sie die Webserver-Konfiguration ändern und den Webserver neu starten, damit die Änderung in Kraft tritt.

  • Wenn Probleme bei einem einzigen virtuellen Host auftreten, müssen alle virtuellen Hosts neu gestartet werden.

Sie können die standardmäßige Apache-Instanz wie gewohnt ausführen:

sytemctl start apache2

Hiermit wird die standardmäßige Datei /etc/sysconfig/apache2 gelesen. Falls die Variable APACHE_HTTPD_CONF in der Datei nicht festgelegt wurde oder die Datei ganz fehlt, wird stattdessen die Datei /etc/apache2/httpd.conf gelesen.

Zum Aktivieren einer anderen Apache-Instanz führen Sie Folgendes aus:

systemctl start apache2@INSTANCE_NAME

Beispiel:

systemctl start apache2@example_web.org

Standardmäßig verwendet die Instanz /etc/apache2@example_web.org/httpd.conf als Hauptkonfigurationsdatei. Diese kann durch Festlegen von APACHE_HTTPD_CONF in /etc/sysconfig/apache2@example_web.org überschrieben werden.

Das nachfolgende Beispiel zeigt, wie Sie eine weitere Instanz von Apache einrichten. Alle Befehle müssen dabei als root ausgeführt werden.

Vorgehen 32.4: Konfigurieren einer weiteren Apache-Instanz
  1. Erstellen Sie eine neue Konfiguration auf der Grundlage von /etc/sysconfig/apache2, beispielsweise /etc/sysconfig/apache2@example_web.org:

    cp /etc/sysconfig/apache2 /etc/sysconfig/apache2@example_web.org
  2. Bearbeiten Sie die Datei /etc/sysconfig/apache2@example_web.org und ändern Sie die Zeile mit

    APACHE_HTTPD_CONF

    mit dem YaST-sysconfig-Editor auf

    APACHE_HTTPD_CONF="/etc/apache2/httpd@example_web.org.conf"
  3. Erstellen Sie die Datei /etc/apache2/httpd@example_web.org.conf auf der Grundlage von /etc/apache2/httpd.conf.

    cp /etc/apache2/httpd.conf /etc/apache2/httpd@example_web.org.conf
  4. Bearbeiten Sie die Datei /etc/apache2/httpd@example_web.org.conf und ändern Sie

    Include /etc/apache2/listen.conf

    mit dem YaST-sysconfig-Editor auf

    Include /etc/apache2/listen@example_web.org.conf

    Prüfen Sie alle Direktiven und passen Sie sie an Ihre Anforderungen an. Ändern Sie bei Bedarf

    Include /etc/apache2/global.conf

    und erstellen Sie für jede Instanz eine neue Datei global@example_web.org.conf. Es wird empfohlen,

    ErrorLog /var/log/apache2/error_log

    mit dem YaST-sysconfig-Editor auf

    ErrorLog /var/log/apache2/error@example_web.org_log

    zu ändern, sodass separate Protokolle für die einzelnen Instanzen geführt werden.

  5. Erstellen Sie die Datei /etc/apache2/listen@example_web.org.conf auf der Grundlage von /etc/apache2/listen.conf.

    cp /etc/apache2/listen.conf /etc/apache2/listen@example_web.org.conf
  6. Bearbeiten Sie die Datei /etc/apache2/listen@example_web.org.conf und ändern Sie

    Listen 80

    in die Portnummer, an der die neue Instanz ausgeführt werden soll, beispielsweise 82:

    Listen 82

    Wenn die neue Apache-Instanz über ein sicheres Protokoll ausgeführt werden soll (siehe Abschnitt 32.6, „Einrichten eines sicheren Webservers mit SSL“), ändern Sie außerdem die Zeile

    Listen 443

    beispielsweise in

    Listen 445
  7. Starten Sie die neue Apache-Instanz:

    systemctl start apache2@example_web.org
  8. Prüfen Sie, ob der Server ausgeführt wird. Geben Sie hierzu http://Servername:82 in den Webbrowser ein. Falls Sie den Namen der Fehlerprotokolldatei für die neue Instanz geändert hatten, können Sie ihn prüfen:

    tail -f /var/log/apache2/error@example_web.org_log

Beim Einrichten mehrerer Apache-Instanzen auf demselben Server sind mehrere Punkte zu beachten:

  • Die Datei /etc/sysconfig/apache2@INSTANZNAME kann dieselben Variablen wie /etc/sysconfig/apache2 enthalten, also auch Einstellungen für das Laden von Modulen und MPM-Einstellungen.

  • Die standardmäßige Apache-Instanz muss nicht ausgeführt werden, wenn andere Instanzen laufen.

  • Die Apache-Helper-Dienstprogramme a2enmod, a2dismod und apachectl werden für die standardmäßige Apache-Instanz ausgeführt, sofern in der Umgebungsvariable HTTPD_INSTANCE nicht anderweitig festgelegt. Im folgenden Beispiel

    export HTTPD_INSTANCE=example_web.org
    a2enmod access_compat
    a2enmod status
    apachectl start

    werden die Module access_compat und status in die Variable APACHE_MODULES in der Datei /etc/sysconfig/apache2@example_web.org eingefügt; anschließend wird die Instanz example_web.org gestartet.

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

32.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 Risiken, die, sobald es möglich ist, ausgeführt werden sollten. Die Sicherheitsankündigungen von SUSE stehen unter folgenden Adressen zur Verfügung:

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

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

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

32.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. Benutzern ist es allerdings nicht erlaubt, Option-Direktiven mit mod_userdir zu überschreiben (siehe hierzu die Konfigurationsdatei /etc/apache2/mod_userdir.conf).

32.9 Fehlerbehebung

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 des Subkommandos apache2.service:

Statt den Webserver mit der Binärdatei /usr/sbin/apache2ctl zu starten und zu stoppen, verwenden Sie das Kommando systemctl (siehe Abschnitt 32.3, „Starten und Beenden von Apache“). systemctl status apache2 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 dann systemctl restart apache2 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 32.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.

32.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.4/ können Sie auch im Web darauf zugreifen. SUSE-spezifische Konfigurationstipps finden Sie im Verzeichnis /usr/share/doc/packages/apache2/README.*.

32.10.1 Apache 2.4

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

32.10.2 Apache Module

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

32.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.4/developer/

32.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.suse.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.