Apache

Apache 2

• Unterschiede der verschiedenen Typen (event, prefork, worker, ITK)?

mpm-prefork

Arbeitsweise ähnlich Apache 1.3, unterstützt keine Threads, arbeitet langsamer als worker, aber stabiler (?). Erzeugt beim Start eine definierte Anzahl von Prozesses, die einzelne Anfragen abarbeiten. Unter bestimmten Bedingungen wird die Anzahl der auf Vorrat gestarteten Prozesse dem Bedarf angepasst.

mpm-worker

unterstützt Threads, nutzt aber auch das prefork-Modell. Jeder vorab gestartete Prozess enthält eine feste Anzahl von Threads für Clientanfragen. Die Anzahl der Prozesse wird wie beim mpm-prefork gesteuert. mod_php ist nicht threadsafe und kann daher hier nicht eingesetzt werden.

mpm-event

eine worker-Variante, die besser mit keepalive-Verbindungen umgehen kann. Hier wird der Thread nicht von der Verbindung festgehalten/blockiert. Die persistenten Daten werden zwischengespeichert und bei Bedarf einem beliebigen Thread zugewiesen.

mpm-itk

eine prefork-Variante ähnlich dem nicht mehr weiterentwickelten perchild-Modell. In diesem Fall können vHosts mit unterschiedlichen Benutzer/Gruppenrechten gestartet werden. Damit werden die vHosts besser voneinander abgeschottet. Damit können auch Apache-Module (z.B. PHP) unter den Rechten des Benutzers ausgeführt werden. (suexec für mod_php)

• Wozu ist apache2-suexec gut?

Ermöglicht die Ausführung von Programmcode (z.B. PHP, Perl) via CGI unter anderen Benutzerrechten. Kann als Alternative zum mpm-ITK in den Threaded-Apache-Modellen (worker, event) benutzt werden, um Programmcode mit Nicht-Apache-Benutzerrechten auszuführen.

• Unterschied zwischen libapache2-mod-php5 und -php5filter?

PHP-Filter-Module ???

Steuerung

apache2ctl start|stop|restart|graceful|graceful-stop|configtest|status|fullstatus

Ein-/Ausschalten von Modulen:

a2enmod <Modulname>
a2dismod <Modulname>

Ein-/Ausschalten von VirtHosts:

a2ensite <VirtHostConfigName>
a2dissite <VirtHostConfigName>

Konfiguration

VirtualHosts

Der Apache kann sowohl IP-basierte als auch namensbasierte virtuelle Hosts verwalten. Sobald mehrere VirtualHosts auf einer IP laufen sollen, muß NameVirtualHost (in der /etc/apache2/ports.conf) konfiguriert sein.

• pauschal für alle IP-Adressen des Servers:

NameVirtualHost *:80

• für einzelne IP-Adressen benannt:

NameVirtualHost xx.yy.zz.1:80
NameVirtualHost xx.yy.zz.2:80

Sollen später neben einer pauschalen auch benannte namensbasierte VirtualHost-Konfigurationen verwendet werden, so sind diese hier zusätzlich anzugeben.

Fehlt hier die Angabe, so wird von einem IP-basierten VirtualHost ausgegangen. Ein zweiter auf diese IP konfigurierter VirtualHost wird nicht funktionieren und mit einer der folgenden Warnungen quittiert:

VirtualHost xx.yy.zz.1:80 overlaps with VirtualHost xx.yy.zz.1:80, the first has precedence, perhaps you need a NameVirtualHost directive
VirtualHost www.domain-A.de:80 overlaps with VirtualHost www.domain-B.de:80, the first has precedence, perhaps you need a NameVirtualHost directive

Die Konfigurationen der virtuellen Hosts können wiederum pauschal, per IP oder DNS-Name erfolgen:

<VirtualHost *:80>
  ServerName www.domain-A.de
  ...
</VirtualHost>

<VirtualHost xx.yy.zz.1:80>
  ServerName www.domain-A.de
  ...
</VirtualHost>

<VirtualHost www.domain-A.de:80>
  ServerName www.domain-A.de
  ...
</VirtualHost>

Beim Laden der Konfiguration wird der DNS-Name entsprechend aufgelöst. Die Namensauflösung kann bei langsamen oder nicht verfügbaren DNS-Servern zu deutlichen Verzögerungen führen. Die daraus resultierende IP muß mit einer oben benannten IP übereinstimmen, falls NameVirtualHost nicht pauschal konfiguriert wurde.

Sobald eine IP in einer benannten VirtualHost-Konfiguration verwendet wird, funktioniert diese IP nicht mehr in einer pauschalen VirtualHost-Konfiguration.

Beispiel:

# Namensauflösung:
# www.domain-A.de => xx.yy.zz.1
# www.domain-B.de => xx.yy.zz.1
# www.domain-C.de => xx.yy.zz.2

NameVirtualHost *:80
NameVirtualHost xx.yy.zz.1:80

<VirtualHost xx.yy.zz.1:80>
  ServerName www.domain-A.de
  ...
</VirtualHost>

<VirtualHost *:80>
  ServerName www.domain-B.de
  ...
</VirtualHost>

<VirtualHost *:80>
  ServerName www.domain-C.de
  ...
</VirtualHost>

Domain-B funktioniert nicht, da die IP von Domain-A in einer benannten VirtualHost-Direktive verwendet wurde und führt zu folgender Warnung:

[warn] _default_ VirtualHost overlap on port 80, the first has precedence

Domain-C funktioniert jedoch, da diese IP nicht anderweitig verwendet wurde.

Unbenutzte NameVirtualHost-Direktiven werden beim Laden der Konfiguration ebenfalls mit einer Warnung quittiert:

[warn] NameVirtualHost xx.yy.zz.2:80 has no VirtualHosts

Fazit: Entweder werden alle zu einer IP gehörenden VirtualHosts mit *:80 konfiguriert oder keiner davon.

NameVirtualHosts funktionieren auch mit https, sofern der Client mitspielt:

[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

Hauptsächlich von der Einschränkung betroffen sind ältere Internet Explorer.

VirtualHosts mit eigener Benutzerkennung

Mit dem Apache mpm-itk ist es möglich, einzelne VirtualHosts abweichend vom Standardbenutzer des Webservers (www-data) mit eigenen Benutzerrechten laufen zu lassen.

Ausgehend von einem Account a0001:a0001 (User:Group) legen wir noch einen weiteren Account a0001-www:a0001 an.

Danach ist in der VirtualHost-Konfiguration folgende Zeile zu ergänzen:

<VirtualHost ...>
  AssignUserId a0001-www a0001
  ...
</VirtualHost>

Damit kann der Benutzer a0001 über die Gruppenberechtigung steuern in welches Verzeichnis der Webserver wie zugreifen kann. 'Others'-Rechte können somit entfallen, was die Sicherheit wieder verbessert. D.h. ein chmod 750 auf Verzeichnisse und 640 auf Dateien macht den Inhalt für den Webserver lesbar, ein 770 bzw. 660 gibt dem Webserver das Schreibrecht darauf.

mod_ssl --- Zertifikate mit Kennwort

Hat man SSL Zertifikate, die Kennwort geschützt sind, kann man entwerder das Kennwort aus dem Zertifikat entfernen, oder die SSLPassPhraseDialog - Direktive von buildin auf exec:Pfad zu script setzten. (http://httpd.apache.org/docs/2.0/mod/mod_ssl.html)

SSLPassPhraseDialog exec:/etc/ssl/sslpw.sh

sslpw.sh:

#!/bin/bash
echo Kennwort

Rewrites

Die RewriteRules zeigen in <Location> und <Directory>-Containern unterschiedliches Verhalten.

<Location> bezieht sich auf DocumentRoot, <Directory> auf den physischen Pfad im System.

DocumentRoot /var/www
<Location />
   ...
</Location>
<Directory /var/www/>
   ...
</Directory>

Alias /doku/ /usr/share/doc/
<Directory /usr/share/doc/>
   ...
</Directory>
<Location /doc/>
   ...
</Location>

Die Anweisungen beziehen sich auf dasselbe Verzeichnis und sind anscheinend gleichbedeutend.

In einer RewriteRule sind aber ggf. unterschiedliche Auswertungen nötig bzw. werden unterschiedliche Ergebnisse geliefert.

<Location />
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Location>
<Directory /var/www/>
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Directory>

In <Location> wird der physische Pfad als $1 weitergegeben, in <Directory> dagegen der Pfad ab DocumentRoot (nochmal validieren!).

<Directory /var/www/api/>
   ...
   RewriteBase /api/
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Directory>

RewiteBase korrigiert dies bei Unterverzeichnissen entsprechend. Standardmäßig gesetzt ist:

RewriteBase /

was sich dementsprechend bei <Location> auf den physischen Pfad / und bei <Directory> auf DocumentRoot bezieht.

Alias /doku/ /usr/share/doc/
<Directory /usr/share/doc/>
   ...
   RewriteBase /doku/
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Directory>

Bei einem Alias muß sich RewriteBase wieder auf den Pfad ab DocumentRoot beziehen, was die obige Vermutung bestätigt..

Ausgehend von dem Ergebnis bei <Location>, muß hier als RewriteBase der physische Pfad angegeben werden (validieren!.

<Location />
   ...
   RewriteBase /var/www/
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Location>
<Location /doc/>
   ...
   RewriteBase /usr/share/doc/
   ...
   RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</Location>