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

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>