Apache (voller Name: Apache HTTP Server) ist seit 1996 der populärste und am weitesten verbreitete Webserver.

Auch ich nutze ihn auf allen meinen Servern, im Netz wie zuhause, intensiv, mit PHP, Perl und anderen Sprachen - wenngleich ich mich mit ihm immer noch deutlich weniger gut auskenne als mit Mail- oder Newsservern. Trotzdem ist es an der Zeit, ein paar Informationen zum Umgang mit dem Apachen zusammenzutragen.

Aktuell sind Apache 2.4 und - noch, bis Dezember 2017 - Apache 2.2, die sich insbesondere in der Konfiguration von Zugriffskontrollen unterscheiden. Alle folgenden Texte gehen davon aus, dass Apache 2.4 als Debian-Paket (ab Debian Stretch) installiert wurde und die damit verbundenen "Debianismen" für die Konfiguration nutzt.

Diese Seite befindet sich erst noch im Aufbau und wird mit der Zeit ergänzt werden.

Installation und Konfiguration unter Debian

Installation

Installiert ist die aktuelle Apache-Version schnell:

apt install apache2 libapache2-mod-auth-plain

Das installiert zum einen den Webserver selbst - mit einigen Standardmodulen - und zusätzlich das Modul mod_auth_plain, das man für HTTP Basic Auth, also für einen einfachen Passwortschutz via .htaccess-Datei, benötigt.

Konfiguration

Alle Konfigurationsdateien für den Apache-Webserver finden sich unter /etc/apache2/.

Debian verwendet ein Konfigurationssystem, das es ermöglicht, Teile der Konfiguration, installierte Module und vorhandene Websites - virtual hosts - auf einfache Weise zu aktivieren und wieder zu deaktivieren. Alle Modulaufrufe, Website-Definitionen und Konfigurationsschnippsel befinden sich in den Verzeichnissen mods-available, sites-available und conf-available - in mods-available liegen dabei sowohl Konfigurationsdateien, die die jeweiligen Module einbinden (diese enden auf .load) als auch ggf. zur Konfiguration des jeweiligen Moduls (diese enden - wie auch alle Konfigurationsdateien in den beiden anderen Verzeichnissen - auf .conf). Aktiviert sind aber in allen Fällen nur die Module, Websites und Konfigurationen, die per Symlink in die Verzeichnisse mods-enabled, sites-enabled und conf-enabled eingebunden werden. Diese Symlinks können über Tools gesetzt und gelöscht - und damit die Module, Websites und Konfigurationen aktiviert oder deaktiviert - werden:

  • a2enmod modul aktiviert ("enabled") das Modul modul. Das Modul mod_rewrite wird also vermittels a2enmod rewrite aktiviert.

  • a2dismod modul tut das Gegenteil: es deaktiviert ("disabled") das Modul modul: für mod_rewrite also a2dismod rewrite.

  • a2ensite website und a2dissite website erfüllen denselben Zweck für Websites (bzw. virtual-host-Konfigurationen).

  • a2enconf config und a2disconf conf schließlich tun ebendieses mit Konfigurationsdateien in /etc/apache2/conf-available.

In jedem Fall ist es jedoch erforderlich, Änderungen vermittels systemctl reload apache2 (oder service apache2 reload) übernehmen zu lassen. Nach dem Aktivieren oder Deaktivieren von Modulen genügt ein bloßer Reload der Serverkonfiguration nicht; dann muss es ein Neustart des Servers sein: systemctl restart apache2 (oder service apache2 restart).

Module

Zu den Modulen, die man aktivieren bzw. deaktivieren möchte, gehören vermutlich u.a. mod_rewrite, mod_aliasund mod_userdir - die beiden ersteren möchte man regelmäßig, letzteres möchte man oft nicht:

a2enmod rewrite alias
a2dismod userdir
systemctl restart apache2

SSL/TLS

HTTP ist gut, HTTPS ist besser …

Wie man das beim Apache einrichtet und konfiguriert, beschreibe ich einstweilen in einigen Blogbeiträgen:

Scriptsprachen und CGIs

Statische Webseiten sind schön, dynamische sind schöner …

Via Common Gateway Interface oder kurz CGI lassen sich dabei letztlich beliebige Programmier- oder Scriptsprachen mit dem Apache koppeln: der Webserver führt das Script aus und leitet dessen Ausgabe - die eine korrekt formatierte HTML-Datei sein sollte - dann an den Browser weiter.

Perl, Python und Co. via CGI

Zu diesem Zweck ist es in der Regel nicht erforderlich oder sinnvoll, spezielle Module wie mod_perl zu installieren. Im Regelfall genügt vielmehr die Installation bzw. Aktivierung von mod_cgi:

a2enmod cgi
systemctl restart apache2

Um die CGI-Scripts nicht unter der Nutzerkennung des Webservers laufen zu lassen - was ein Sicherheitsrisiko sein und andere Probleme nach sich ziehen kann -, sondern unter der des jeweiligen Benutzers, dem das Script "gehört", braucht es dann noch suexec, entweder in der Standardvariante, in der die zulässigen Pfade für CGI-Scripts einkompiliert sind, oder in einer Variante, in der diese Pfade konfigurierbar sind. Ich bevorzuge letzteres:

apt install apache2-suexec-custom
vim /etc/apache2/suexec/www-data
a2enmod cgi suexec      
systemctl restart apache2

Standardmäßig werden CGI-Scripts allerdings - schon aus Sicherheitsgründen - nicht ohne weiteres überall ausgeführt. Dementsprechend ist - allgemein oder nur für bestimmte Dateien oder Verzeichnisse - noch die Ausführung von CGI freizugeben und entsprechender Handler hinzuzufügen:

<Directory "/var/www/domain.example/cgi-bin">
  Options +ExecCGI
  AddHandler cgi-script .pl
</Directory>

Das erlaubt die Ausführung von auf .pl endenden Dateien im Verzeichnis /var/www/domain.example/cgi-bin/. Das lässt sich durchaus verallgemeinern oder auch auf Endungen wie .py oder - generisch - .cgi erstrecken.

PHP via PHP-FPM

Verbreiteter als Perl, Python und Co. dürfte dieser Tage PHP als Scriptsprache sein - das man heutzutage besser weder als Modul noch als reines CGI ausführt (letzteres vor allem aus Performancegründen). Ich nutze dafür PHP-FPM, den FastCGI Process Manager.

Dafür verweise ich einstweilen auf einen passenden Blogeintrag:

Performance-Tuning

Für das bei Debian defaultvermäßig verwendete Event-MPM (mpm_event) und PHP-FPM habe ich Konfigurationsmöglichkeiten in einem Blogbeitrag beschrieben:

Lizenz

Creative Commons-Lizenzvertrag Dieser Inhalt ist unter der Creative Commons-Lizenz BY-NC-SA 4.0 DE lizenziert; er darf unter Namensnennung des Autors nicht-kommerziell weitergegeben und auch bearbeitet werden, soweit das neue Werk gleichfalls wieder dieser Creative-Commons-Lizenz unterliegt. Die Einzelheiten ergeben sich aus dem Lizenzvertrag.