Eigentlich ist suPHP eine nette Sache. Das Apache Modul mod_suphp sorgt in Kombination mit einem SetUID Binary dafür, dass PHP-Skripte mit den Berechtigungen des Benutzers, dem sie gehören, ausgeführt werden. Damit das funktioniert muss man in Binär-Distributionen wie etwa Debian Linux nicht mehr tun, als dass Modul zu installieren, einen Blick auf dessen Konfiguration zu werfen und es anschließend zu aktivieren. Vielleicht ist es gerade diese Einfachheit (deren Preis die Starrheit ist), die es so beliebt macht.

Ein großes Problem tut sich aber dann auf, wenn man PHP-Caches wie APC, TurckMM oder eAccelerator verwenden möchte. Denn all diese Caches funktionieren nicht im Zusammenspiel mit suPHP. Zwar lässt sich eine solche Kombination verwenden, doch ist sie leider nutzlos, da nichts gecached wird.

Eine wundervolle Alternative zu der Verwendung von suPHP ist eine Kombination aus Apache, SuExec, FCGID und PHP-CGI. Mit dieser Kombination funktioniert auch das Caching problemlos. Eine Anleitung zum Aufsetzen dieser Kombination findet sich bei Hetzner.de.

Wer seine Websites nicht in dem von der jeweils genutzten Linux Distribution dafür vorgesehenen Verzeichnis ablegt sondern stattdessen beispielsweise in /home/*/public_html/ muss darauf achten, SuExec selbst zu kompilieren oder auf Debian-Systemen die gepatchte Version apache2-suexec-common zu verwenden. Aus Sicherheitsgründen erwartet SuExec bereits bei der Kompilierung den Pfad zum Docroot. Bei der Verwendung von apache2-suexec-common lässt sich das Docroot in der Datei /etc/apache2/suexec/www-data angeben.

Was ist mod_rewrite?

mod_rewrite ist eine Bibliothek für den Apache Webserver, die Adressen (URLs) umschreiben kann. Man kann sich das in etwa wie eine Verknüpfung vorstellen, die auch Parameter an das echte Programm mit dem echten Pfad übergeben kann.

Was bringt mir mod_rewrite?

Mit mod_rewrite wird Webmastern eine schöne Möglichkeit in die Hand gelegt für noch schönere URLs zu sorgen. So vermag mod_rewrite beispielsweise aus www.bla.de/blub.php?bla=bla&bla2=bla2 www.bla.de/blub_bla-bla2, www.bla.de/blub-bla-bl2.html oder etwa www.bla.de/blub/bla/bla2/ zu machen.

Dies hat den angenehmen Effekt, dass die URLs von Suchmaschinen perfekt verfolgt werden können und der Webmaster die URLs mit Keywords anreichern kann, die sein Ranking in den Suchmaschinen positiv beeinflussen. Außerdem ist es natürlich angenehmer für die Augen und vereinfacht Direktzugriffe von Stammgästen

mod_rewrite Konfiguration / Syntax

mod_rewrite handelt nach Regeln, die der Webmaster entweder in einer .htaccess Datei in dem entsprechenden Verzeichnis (bzw. einem darüberliegenden, da sie rekursiv vererbt werden) hinterlegt, oder direkt in die Konfiguration des Apache Webservers schreibt. Letzteres hat Performance-Vorteile, da der Apache keine .htaccess Datei einlesen muss. Die Syntax der Regeln entspricht Perls regulären Ausdrücken.

mod_rewrite Syntax Beispiele

Zu Beginn muss mod_rewrite aktiviert werden:

RewriteEngine On

Dann wird das Verzeichnis ausgewählt, auf das sich die Regeln beziehen:

RewriteBase /

Folgende Regel macht den Aufruf des PHP-Skriptes index.php mit den Parametern id und name auch via Aufruf einer URL möglich, die mit i_ beginnt und mit den beiden Parametern getrennt durch ein Minus weiter geht:

RewriteRule ^i_(.*)-(.*)$ index.php?id=$1&name=$2

Folgende Regel tut genau das gleiche, beschränkt die Zulässigen Datentypen der Parameter aber bei id auf einen String und bei name auf einen Integer – weichen sie ab findet kein Umschreiben statt.

RewriteRule ^i_([a-Z]*)-([0-9]*)$ index.php?id=$1&name=$2

Weitere Informationen zu regulären Ausdrücken finden sich hier. Mehr zu mod_rewrite gibt es auf Apache.org.

Ein Anonymizerservice von einem Freund und mir wurde vor kurzem von Bots u.a. für Trackback-Spam missbraucht. Was passiert war lag auf der Hand – 8 Trafficlimit Mails an einem Tag (ich hab mal ein tägliches Limit von 30GB vorgegeben). In den Logs wurden die schuldigen schnell gefunden.

Aber wie lassen sich Bots aussperren? Beim Apache Webserver funktioniert dies relativ leicht: in der Datei des jeweiligen VHosts bzw. in der httpd.conf / apache2.conf oder alternativ in der .htaccess Datei können Regeln aufgestellt werden, die Hosts anhand bestimmter Kriterien ausschließen. Zur Demonstration:

Folgender Eintrag in einer .htaccess Datei bewirkt, dass die Hosts mit den IP-Adressen 69.50.160.50 und 64.28.177.122 nicht mehr auf Inhalte des Apache zugreifen können:

order deny,allow
deny from 69.50.160.50
deny from 64.28.177.122


Folgende Einträge schließen alle Clients, die den UserAgent TrackBack/1.02 oder einen UserAgent, der mit “Java” beginnt haben (ein Bot mit dem UserAgent TrackBack/1.02 sorgte für Trackback-Spam und diverse Bots mit dem UserAgent Java hatten ganz offensichtlich auch nichts gutes vor), von dem Zugriff auf Inhalte des Apache aus:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Java
RewriteRule ^.*$ - [F]
RewriteCond %{HTTP_USER_AGENT} TrackBack/1.02
RewriteRule ^.*$ - [F]

Wer mehr über die dynamisch wirkenden RewriteConditions wissen möchte sollte sich mit regulären Ausdrücken beschäftigen.

Spätestens, wenn top ein CPU usage von 100% anzeigt oder sich die Maschine gar das erste mal verabschiedet muss sich Herr root die Frage stellen, was er tun kann, um das Problem zu beseitigen.

Sollte top zudem verraten, dass Apache bzw. PHP-CGI -Prozesse dafür verantwortlich sind muss man sich die Frage stellen, ob dies an der Execution time liegt, oder an externen Faktoren (z.B. wenn Bilder von externen Servern geladen werden).

Sollte das Problem tatsächlich lokaler natur sein, so verspricht APC Abhilfe. APC ist ein Modul für PHP, das bereits kompilierte PHP Skripte, bzw. genauer gesagt deren Bytecode cacht.

Die Installation von APC gestaltet sich simpel. Der Tarball muss nur von der Seite heruntergeladen werden, anschließend lässt er sich mit tar zxf APC-* entpacken. Es folgen das Ausführen von phpize (normaler Weise in /usr/bin/ bzw. /usr/local/bin/ beheimatet) sowie ./configure (genaue Parameter bitte der Datei INSTALL entnehmen), make und make install. Anschließend muss das Modul nur noch durch einen Eintrag in die php.ini geladen werden.
Der Performanceunterschied ist nicht gigantisch, jedoch deutlich spür- und sichtbar. Mehr dazu auf der offiziellen Seite.