42 Der HTTP-Server Apache #
Laut den Umfragen von http://www.netcraft.com/ und https://w3techs.com/ zählt der Apache HTTP-Server (Apache) zu den weltweit beliebtesten Webservern. Der von der Apache Software Foundation (http://www.apache.org/) entwickelte Apache-Server läuft auf fast allen Betriebssystemen. SUSE® Linux Enterprise Server enthält Apache Version 2.4. In diesem Kapitel wird beschrieben, wie Apache installiert, konfiguriert und bedient wird. Außerdem wird die Verwendung von zusätzlichen Modulen, beispielsweise SSL, und die Fehlerbehebung für Apache erläutert.
42.1 Schnelleinführung #
Dieser Abschnitt unterstützt Sie beim schnellen Konfigurieren und Starten von Apache. Zur Installation und Konfiguration von Apache müssen Sie root
-Benutzer sein.
42.1.1 Anforderungen #
Vergewissern Sie sich, dass folgende Voraussetzungen erfüllt sind, bevor Sie den Apache-Webserver einrichten:
Das Netzwerk des Computers ist ordnungsgemäß konfiguriert. Weitere Informationen zu diesem Thema finden Sie unter Kapitel 23, Grundlegendes zu Netzwerken.
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 38, Zeitsynchronisierung mit NTP.
Die neuesten Sicherheitsaktualisierungen sind installiert. Falls Sie sich nicht sicher sind, führen Sie YaST-Online-Update aus.
In der Firewall ist der Standardport des Webservers (
80
) geöffnet. Konfigurieren Sie hierzufirewalld
so, dass der Diensthttp
in der öffentlichen Zone zugelassen wird. Ausführliche Informationen finden Sie unter Section 23.4.3, “Configuring the firewall on the command line”.
42.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:
Starten Sie YaST, und wählen Sie
› .Wählen Sie
› und schließlich .Bestätigen Sie die Installation der abhängigen Pakete, um den Installationsvorgang abzuschließen.
42.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:
>
sudo
systemctl enable apache2.service
Weitere Informationen zu den systemd
-Zielen in SUSE Linux Enterprise Server sowie eine Beschreibung zu YaST finden Sie unter Abschnitt 19.4, „Verwalten von Diensten mit YaST“.
Über die Shell starten Sie Apache manuell mit dem Kommando systemctl start apache2.service
.
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:
Starten Sie einen Webbrowser und öffnen Sie http://localhost/.
Wenn Apache ausgeführt wird, wird eine Testseite mit der Meldung „It works!“ angezeigt.
Wenn diese Seite nicht angezeigt wird, lesen Sie den Abschnitt Abschnitt 42.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.
42.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.
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.service
neu oder verwenden Sie eine der in Abschnitt 42.3, „Starten und Beenden von Apache“ beschriebenen Neustartoptionen.
Wenn Sie Apache mit YaST konfigurieren, kann dieser Schritt automatisch ausgeführt werden. Stellen Sie dazu Abschnitt 42.2.3.2, „HTTP-Server-Konfiguration“ beschrieben.
auf ein, wie in42.2.1 ApacheKonfigurationsdateien #
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.
Die Konfigurationsdateien von Apache befinden sich in zwei verschiedenen Verzeichnissen:
42.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.
42.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 |- global.conf |- httpd.conf |- listen.conf |- loadmodule.conf |- magic |- mime.types |- mod_*.conf |- protocols.conf |- server-tuning.conf |- ssl-global.conf |- ssl.* |- sysconfig.d | | | |- global.conf | |- include.conf | |- loadmodule.conf . . | |- uid.conf |- vhosts.d | |- *.conf
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.
global.conf
Diese Datei enthält die allgemeine Konfiguration des Webserver-Hauptprozesses, beispielsweise den Zugriffspfad, die Fehlerprotokolle oder die Protokollierungsstufe.
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 42.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 Dateimod_mime-defaults.conf
hinzufügen.mod_*.conf
Dies sind die Konfigurationsdateien der in der Standardinstallation enthaltenen Module. Weitere Informationen finden Sie unter Abschnitt 42.4, „Installieren, Aktivieren und Konfigurieren von Modulen“. Die Konfigurationsdateien optionaler Module befinden sich im Verzeichnis
conf.d
.protocols.conf
Dies sind die Konfigurationsdirektiven für die Bereitstellung von Seiten über eine HTTP2-Verbindung.
server-tuning.conf
Diese Datei enthält Konfigurationsdirektiven für verschiedene MPMs (siehe Abschnitt 42.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
undssl.*
Diese Dateien enthalten die globale SSL-Konfiguration und die SSL-Zertifikatdaten. Weitere Informationen finden Sie unter Abschnitt 42.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 42.2.2.1, „Virtuelle Hostkonfiguration“.
42.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.
42.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 42.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).
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.
42.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.
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.
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>
42.2.2.1.2 IP-basierte virtuelle Hosts #
Bei dieser alternativen virtuellen Hostkonfiguration werden auf einem Computer mehrere IP-Adressen 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 IP-Adressen 192.168.3.101
und 192.168.3.102
befinden. Für jeden virtuellen Server wird ein eigener VirtualHost
-Block benötigt.
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.
42.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
Email-Adresse des Serveradministrators. 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>
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:
VirtualHost
-Konfiguration #<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>
42.2.3 Konfigurieren von Apache mit YaST #
Zur Konfiguration des Webservers mit YaST starten Sie YaST, und wählen Sie Abschnitt 42.2.3.2, „HTTP-Server-Konfiguration“.
› . Wenn Sie dieses Modul zum ersten Mal starten, wird der geöffnet und sie werden aufgefordert, einige grundlegende Entscheidungen zur Verwaltung des Servers zu treffen. Nach Fertigstellung des Assistenten wird das Dialogfeld geöffnet, sobald Sie das -Modul aufrufen. Weitere Informationen finden Sie im42.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.
42.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
, 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 , um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.Klicken Sie auf
, um mit der Konfiguration fortzufahren.42.2.3.1.2 Module #
Mit der Konfigurationsoption Abschnitt 42.2.3.2.2, „Servermodule“. Klicken Sie auf , um das nächste Dialogfeld zu öffnen.
aktivieren bzw. deaktivieren Sie die vom Webserver unterstützten Skriptsprachen. Informationen zur Aktivierung bzw. Deaktivierung anderer Module erhalten Sie unter42.2.3.1.3 Standardhost #
Diese Option betrifft den Standard-Webserver. Wie in Abschnitt 42.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 . Zum Hinzufügen neuer Direktiven klicken Sie auf . Zum Löschen einer Direktive wählen Sie die Direktive aus und klicken Sie auf .
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 desDocument 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 dieScriptAlias
-Direktive eine URL einem Speicherort im Dateisystem zu. Der Unterschied besteht darin, dassScriptAlias
als Zielverzeichnis einen CGI-Speicherort für die Ausführung von CGI-Skripten festlegt.Directory
Unter den
Directory
-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.Include
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 Konfigurationsdateiapache2-manual
eingeschlossen.Server Name
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.Server Administrator E-Mail
Email-Adresse des Serveradministrators. Diese Adresse ist beispielsweise auf den von Apache erstellten Fehlerseiten angegeben.
Klicken Sie am Ende der Seite
auf , um mit der Konfiguration fortzufahren.42.2.3.1.4 Virtuelle Hosts #
In diesem Schritt zeigt der Assistent eine Liste der bereits konfigurierten virtuellen Hosts an (siehe Abschnitt 42.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 DocumentRoot
) und . Unter 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 (Virtuelle Host-ID ändern) an.
Klicken Sie auf
, 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 42.6.2, „Konfigurieren von Apache mit SSL“. Mit der Option 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 stellen Sie den Inhalt der öffentlichen Benutzerverzeichnisse (~USER/public_html/
) auf dem Server unter http://www.example.com/~USER
bereit.
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.
42.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 Abschnitt 42.2.3.2, „HTTP-Server-Konfiguration“ beschriebene Dialogfeld öffnen.
ab. Zum Ändern bestimmter Einstellungen klicken Sie so oft auf , bis das entsprechende Dialogfeld angezeigt wird. Über können Sie hier auch das in42.2.3.2 HTTP-Server-Konfiguration #
Im Dialogfeld
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 schließen. Klicken Sie hingegen auf , so verlassen Sie das Konfigurationsmodul und Ihre Konfigurationsänderungen werden verworfen.42.2.3.2.1 Überwachen von Ports und Adressen #
Geben Sie unter 80
überwacht. Die Option 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 , um festzulegen, an welchen Schnittstellen die Ports geöffnet werden sollen.
Über die Schaltfläche Abschnitt 42.3, „Starten und Beenden von Apache“. Diese Kommandos sind sofort wirksam und ihre Protokollmeldungen werden auch sofort angezeigt.
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 unter42.2.3.2.2 Servermodule #
Über Abschnitt 42.4, „Installieren, Aktivieren und Konfigurieren von Modulen“.
können Sie Apache2-Module aktivieren und deaktivieren. Über 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 in42.2.3.2.3 Haupthost oder Hosts #
Diese Dialogfelder sind mit den bereits beschriebenen identisch. in Abschnitt 42.2.3.1.3, „Standardhost“ und Abschnitt 42.2.3.1.4, „Virtuelle Hosts“ beschriebenen Dialogfeldern.
42.3 Starten und Beenden von Apache #
Bei Konfiguration mit YaST, wie in Abschnitt 42.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 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 19.2.1, „Verwalten von Diensten auf einem laufenden System“.
systemctl status apache2.service
Überprüft, ob Apache gestartet wurde.
systemctl start apache2.service
Startet Apache, sofern es noch nicht läuft.
systemctl stop apache2.service
Stoppt Apache durch Beenden des übergeordneten Prozesses.
systemctl restart apache2.service
Beendet Apache und startet es danach neu. Falls der Webserver noch nicht gelaufen ist, wird er nun gestartet.
systemctl try-restart apache2.service
Stoppt Apache und startet es erneut, vorausgesetzt, es wird bereits ausgeführt.
systemctl reload apache2.service
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: Neustart von Apache in ProduktionsumgebungenMit diesem Kommando können Änderungen in der Apache-Konfiguration aktiviert werden, ohne dass die Verbindung unterbrochen wird.
systemctl stop apache2.service
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
undapachectl fullstatus
Erstellt einen Dump des kurzen oder vollständigen Statusfensters. Das Module
mod_status
muss aktiviert und ein Textbrowser (z. B.links
oderw3m
) muss installiert sein. Außerdem muss/etc/sysconfig/apache2
unterAPACHE_SERVER_FLAGS
das FlagSTATUS
enthalten.
Weitere Flags, die Sie mit den Kommandos angeben, werden direkt an den Webserver weitergeleitet.
42.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 42.4.2, „Aktivieren und Deaktivieren von Modulen“.
Apache-Module sind in die folgenden Kategorien gegliedert:
- Basismodule
Basismodule sind standardmäßig in Apache enthalten. In Apache in SUSE Linux Enterprise Server sind nur
mod_so
(zum Laden anderer Module) undhttp_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.
42.4.1 Installieren von Modulen #
Wenn Sie die in Abschnitt 42.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 apache
. Die Ergebnisliste zeigt nun neben anderen Paketen alle verfügbaren externen Apache-Module an.
42.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 (PHP 8 und Python) mit der im Abschnitt Abschnitt 42.2.3.1, „HTTP-Server-Assistent“ beschriebenen Modulkonfiguration aktiviert oder deaktiviert werden. Alle anderen Module werden, wie im Abschnitt Abschnitt 42.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.
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
.
42.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
undRedirect
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 mitmod_auth_digest
.mod_auth_basic
undmod_auth_digest
funktionieren nur gemeinsam mit dem Authentifizierungsanbietermodulmod_authn_*
(z. B.mod_authn_file
für die Authentifizierung auf Basis einer Textdatei) und mit dem Autorisierungsmodulmod_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_auth_openidc
mod_auth_openidc
ist die einzige zertifizierte Methode zur Verwendung von OpenID Connect mit dem Apache HTTP-Server. (Siehe https://openid.net/developers/certified/.)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 dieOptions
-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 dieDirectoryIndex
-Direktive bereit, mit der Sie festlegen können, welche Dateien bei Anforderung eines Verzeichnisses automatisch zurückgegeben werden (standardmäßigindex.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 einesExpires
-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 vonProtocols h2 http/1.1
in einemVirtualHost
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
den Zugriff auf diese URL.mod_info
wird unter/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. Mitmod_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_spelling
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. Ausführliche Informationen finden Sie unter Abschnitt 42.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
den Zugriff auf diese URL.mod_status
wird unter/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 dieUserDir
-Direktive angegeben sein. Dieses Modul ist standardmäßig aktiviert.
42.4.4 Multiprocessing-Module #
SUSE Linux Enterprise Server bietet zwei Multiprocessing-Module (MPMs) für Apache:
42.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.
In diesem Dokument wird davon ausgegangen, dass Apache mit dem Prefork-MPM verwendet wird.
42.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.
Nicht alle verfügbaren PHP-Module sind Thread-sicher. Von einer Verwendung des Worker-MPM in Verbindung mit mod_php
wird daher abgeraten.
42.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_php8
benutzt werden.Paketname: apache2-mod_apparmor
Weitere Informationen: Part V, “Confining privileges with AppArmor” mod_php8
PHP ist eine serverseitige, plattformübergreifende, in HTML eingebettete Skriptsprache.
Paketname: apache2-mod_php8
Konfigurationsdatei: /etc/apache2/conf.d/php8.conf
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/
42.4.6 Kompilieren von Modulen #
Apache kann von erfahrenen Benutzern durch selbst entwickelte Module erweitert werden. Zum Entwickeln von Modulen für Apache oder zum Kompilieren von Drittanbietermodulen ist das Paket apache2-devel
zusammen mit den entsprechenden Entwicklerwerkzeugen erforderlich. apache2-devel
enthält außerdem die apxs2
-Werkzeuge, die zum Kompilieren zusätzlicher Module für Apache 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:
>
sudo
cd /path/to/module/source>
sudo
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.
42.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 Skriptsprachen wie 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 42.4.2, „Aktivieren und Deaktivieren von Modulen“.
Die Zulassung der CGI-Skriptausführung auf dem Server ist ein Sicherheitsrisiko. Weitere Informationen finden Sie in Abschnitt 42.8, „Vermeiden von Sicherheitsproblemen“.
42.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 42.2.2.1, „Virtuelle Hostkonfiguration“) und Ihre CGI-Skripten in einem Host-spezifischen Verzeichnis ablegen möchten, müssen Sie das betreffende Verzeichnis entsperren und für CGI-Skripten konfigurieren.
ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"1 <Directory "/srv/www/www.example.com/cgi-bin/"> Options +ExecCGI2 AddHandler cgi-script .cgi .pl3 Require all granted4 </Directory>
Fordert Apache auf, alle Dateien in diesem Verzeichnis als CGI-Skripten zu behandeln | |
Aktiviert die Ausführung von CGI-Skripten | |
Fordert den Server auf, Dateien mit den Erweiterungen .pl und .cgi als CGI-Skripten zu behandeln. passen Sie diese Anweisung entsprechend Ihren Anforderungen an | |
Die |
42.5.2 Ausführen eines Beispielskripts #
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 42.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.
42.5.3 CGI-Fehlerbehebung #
Wenn Sie nach der Ausführung des CGI-Testskripten statt des Testskriptberichts eine Fehlermeldung erhalten, überprüfen Sie Folgendes:
Haben Sie den Server nach der Konfigurationsänderung neu geladen? Falls nicht, laden Sie ihn mit
systemctl reload apache2.service
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 mithttp://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.
42.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 TLS/SSL 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 TLS/SSL-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://
).
42.6.1 Erstellen eines SSL-Zertifikats #
Wenn Sie TLS/SSL 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.
Weitere Informationen über das Konzept von TLS/SSL und diesbezügliche Festlegungen finden Sie unter http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html.
42.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.
Verwenden Sie Dummy-Zertifikate niemals in Produktionsumgebungen, sondern nur zum Testen.
42.6.1.2 Erstellen eines eigensignierten 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.
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
Geben Sie Ihren Passwortsatz ein. | |
Wiederholen Sie die Eingabe (und merken Sie sie sich). | |
Geben Sie Ihren zwei Buchstaben umfassenden Ländercode ein, z. B. | |
Geben Sie den Namen des Bundeslands oder Kantons ein, in dem Sie leben. | |
Geben Sie den Namen des Ortes ein, z. B. | |
Geben Sie den Namen der Organisation ein, für die Sie arbeiten. | |
Geben Sie Ihre Organisationseinheit ein oder lassen Sie dieses Feld leer, wenn Sie keine Organisationseinheit besitzen. | |
Geben Sie den Domänennamen des Servers bzw. Ihren Vor- und Nachnamen ein. | |
Geben Sie Ihre geschäftliche Email-Adresse ein. | |
Lassen Sie das Challenge-Passwort leer; ansonsten müssen Sie es bei jedem Neustart des Apache-Webservers eingeben. | |
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.
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.keyGenerieren 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 365Kopieren 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
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.
42.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
.
42.6.2 Konfigurieren von Apache mit SSL #
Der Standard-Port für TLS/SSL-Anfragen auf der Seite des Webservers lautet 443. Es gibt keine Überschneidung zwischen einem „regulären“ Apache mit Überwachung des Ports 80 und einem TLS/SSL-fähigen Apache mit Überwachung des Ports 443. HTTP und HTTPS können sogar mit derselben Apache-Instanz ausgeführt werden. In der Regel verteilen separate virtuelle Hosts die Anforderungen für Port 80 und Port 443 an separate virtuelle Server.
Denken Sie daran, die Firewall für SSL-fähiges Apache an Port 443 zu öffnen. Verwenden Sie hierzu firewalld
, wie im Section 23.4.3, “Configuring the firewall on the command line” beschrieben.
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 42.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
42.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 42.2.2.1.1, „Namensbasierte virtuelle Hosts“ beschrieben konfigurieren. (Beachten Sie, dass für SSL Port 443
anstelle von Port 80
benötigt wird.)
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 im 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.
42.7 Ausführen mehrerer Apache-Instanzen auf demselben Server #
Das Ausführen mehrerer Apache-Instanzen auf demselben Server bietet mehrere Vorteile gegenüber dem Ausführen mehrerer virtueller Hosts (siehe Abschnitt 42.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:
>
sudo
systemctl start apache2.service
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:
>
sudo
systemctl start apache2@INSTANCE_NAME
Beispiel:
>
sudo
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.
Erstellen Sie eine neue Konfiguration auf der Grundlage von
/etc/sysconfig/apache2
, beispielsweise/etc/sysconfig/apache2@example_web.org
:>
sudo
cp /etc/sysconfig/apache2 /etc/sysconfig/apache2@example_web.orgBearbeiten Sie die Datei
/etc/sysconfig/apache2@example_web.org
und ändern Sie die Zeile mitAPACHE_HTTPD_CONF
zu
APACHE_HTTPD_CONF="/etc/apache2/httpd@example_web.org.conf"
Erstellen Sie die Datei
/etc/apache2/httpd@example_web.org.conf
auf der Grundlage von/etc/apache2/httpd.conf
.>
sudo
cp /etc/apache2/httpd.conf /etc/apache2/httpd@example_web.org.confBearbeiten Sie die Datei
/etc/apache2/httpd@example_web.org.conf
und ändern SieInclude /etc/apache2/listen.conf
zu
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
zu
ErrorLog /var/log/apache2/error@example_web.org_log
zu ändern, sodass separate Protokolle für die einzelnen Instanzen geführt werden.
Erstellen Sie die Datei
/etc/apache2/listen@example_web.org.conf
auf der Grundlage von/etc/apache2/listen.conf
.>
sudo
cp /etc/apache2/listen.conf /etc/apache2/listen@example_web.org.confBearbeiten Sie die Datei
/etc/apache2/listen@example_web.org.conf
und ändern SieListen 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 42.6, „Einrichten eines sicheren Webservers mit SSL“), ändern Sie außerdem die Zeile
Listen 443
beispielsweise in
Listen 445
Starten Sie die neue Apache-Instanz:
>
sudo
systemctl start apache2@example_web.orgPrü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:>
sudo
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
undapachectl
werden für die standardmäßige Apache-Instanz ausgeführt, sofern in der UmgebungsvariableHTTPD_INSTANCE
nicht anderweitig festgelegt. Im folgenden Beispiel>
sudo
export HTTPD_INSTANCE=example_web.org>
sudo
a2enmod access_compat>
sudo
a2enmod status>
sudo
apachectl startwerden die Module
access_compat
undstatus
in die VariableAPACHE_MODULES
in der Datei/etc/sysconfig/apache2@example_web.org
eingefügt; anschließend wird die Instanzexample_web.org
gestartet.
42.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.
42.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:
Web-Seite. https://www.suse.com/support/security/
Mailinglisten-Archiv. https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/
Liste der Informationen zur Sicherheit. https://www.suse.com/support/update/
42.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.
42.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 unter Abschnitt 42.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.
42.8.4 CGI-Skripten #
Interaktive Skripts in 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.
42.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
).
42.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 des Subkommandos
apache2.service
: Statt den Webserver mit der Binärdatei
/usr/sbin/apache2ctl
zu starten und zu stoppen, verwenden Sie das Kommandosystemctl
(siehe Abschnitt 42.3, „Starten und Beenden von Apache“).systemctl status apache2.service
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 DirektiveLogLevel
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: Ein einfacher TestSie können die Apache-Protokollmeldungen mit dem Befehl
tail -F /var/log/apache2/MY_ERROR_LOG
überwachen. Führen Sie dannsystemctl restart apache2.service
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 42.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.
42.10 Weitere 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.*
.
42.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.
42.10.2 Apache Module #
Weitere Informationen zu externen Apache-Modulen, die kurz im Abschnitt Abschnitt 42.4.5, „Externe Module“ beschrieben werden, finden Sie an folgenden Orten:
mod_apparmor
mod_php8
http://www.php.net/manual/en/install.unix.apache2.php
Ausführlichere Informationen zur
mod_php8
-Konfiguration finden Sie in der gut kommentierten Konfigurationsdatei/etc/php8/apache2/php.ini
.mod_python
mod_security
42.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
- Dokumentation für Apache-Entwickler
42.10.4 Verschiedene Informationsquellen #
Wenn Sie in SUSE Linux Enterprise Server Probleme mit Apache haben, werfen Sie einen Blick in die technische Informationssuche unter https://www.suse.com/support. Die Entstehungsgeschichte von Apache finden Sie unter https://httpd.apache.org/ABOUT_APACHE.html. Auf dieser Seite erfahren Sie auch, weshalb dieser Server Apache genannt wird.