Blogix

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Wichtige Daten (z.B. Benutzername und Passwort, Daten der Bankverbindung,…) sollten immer über eine gesicherte SSL-Verbindung übertragen werden. Um eine verschlüsselte Verbindung zu erhalten, können mehrere Wege eingeschlagen werden. Ich möchte hier den Weg per PHP und den per .htaccess aufzeigen. Diese beiden Beispiele funktionieren im Gegensatz zu vielen anderen im Internet auch mit anderen als dem Standard-Port 993 für SSL.

SSL-Verschlüsselung mit PHP erzwingen

if (!isset($_SERVER['HTTPS']))
{
	header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . $_SERVER['QUERY_STRING']);
}

Wenn ein anderer Port als der Standard-Port verwendet wird, muss dieser noch eingefügt werden – z.B. “$_SERVER['HTTP_HOST'] . ‘:123′ . $_SERVER['REQUEST_URI']“, wobei “123″ mit dem gewünschten Port ersetzt werden muss.

SSL-Verschlüsselung mit .htaccess erzwingen

RewriteEngine On
RewriteCond %{HTTPS} Off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Auch hier muss noch der Port eingefügt werden, sollte dieser nicht Standard sein – z.B. “https://%{HTTP_HOST}:123%{REQUEST_URI}”, wobei auch hier “123″ mit dem gewünschten Port ersetzt werden muss.

Auf Shared Hosting-Umgebungen (mehrere Benutzer teilen einen Webserver) ohne suphp oder PHP im CGI-Mode kommt es zu dem Problem, dass der Apache-Webserver und PHP für alle Domains mit einem Benutzer (z.B. “www-data”) ausgeführt werden. Das hat zur Folge, dass von PHP erstellte Dateien dem Apache-Benutzer gehören und meist auch nur der Besitzer (Apache-Benutzer) schreibend darauf zugreifen darf. Shared Hosting-Kunden melden sich aber mit FTP-Accounts an, die ungleich dem des Apache-Benutzers sind. Das führt dazu, dass FTP-Benutzer die vom Apache-Benutzer angelegten Dateien überlicherweise nicht löschen dürfen.

Um die Dateien wieder ändern oder löschen zu können, hat man zwei Möglichkeiten:

1. Beim Erstellen führt man direkt ein chmod() oder chown() aus und gewährt dem eigenen FTP-Benutzer die notwendigen Berechtigungen.
2. Man schreibt ein Skript, das diese Aufgabe hinterher ausführt und ruft dieses mit einem Browser auf.

Ein derartiges Skript könnte wie folgt aussehen (in diesem Beispiel werden alle Dateien und Ordner aus dem Ordner “fileadmin” gelöscht, der sich auf der selben Ebene wie das Skript befindet):

function recursive_readdir($path)
{
	$handle = opendir($path);
	while (($file = readdir($handle)) !== false)
	{
		if ($file != '.' && $file != '..')
		{
			$filepath = $path . '/' . $file;
			echo $filepath.'<br />';
			if (is_dir($filepath))
			{
				rmdir($filepath);
				recursive_readdir($filepath);
			}
			else
			{
				unlink($filepath);
			}
		}
	}
	closedir($handle);
}

recursive_readdir('./fileadmin');

Heute wurde die (voraussichtlich) letzte Version von PHP 4 veröffentlicht, lediglich Sicherheitslücken werden noch bis 8. August 2008 geschlossen. Ein Upgrade auf die neueste Version wird im über die Mailinglist versandten E-Mail dringend empfohlen. Bereits im Juli des vergangenen Jahres wurde angekündigt, dass die Entwicklung von PHP 4 mit Ende des Jahres eingestellt wird, was nun heute (mit etwas Verspätung) geschehen ist.