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>

VirtHosts mit eigener Benutzerkennung

Mit dem Apache mpm-itk ist es möglich, einzelne VirtHosts 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 VirtHost-Config 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.