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.

Im Head-Tag jeder Webseite kann man das Charset/Zeichensatz festlegen, mit dem die Datei gespeichert wurde. Der korrekte Zeichensatz kommt dann zum Tragen, wenn es um Umlaute geht. ISO-8859-1 benötigt genau 1 Byte um alle enthaltenen Zeichen darzustellen, UTF-8 hat eine variable Länge bis zu 4 Byte. Daran lässt sich erkennen, dass UTF-8 mehr Zeichen darstellen kann, diese aber zum Teil auch eine andere Bytes- bzw. Bitkombination aufweisen als das selbe Zeichen in ISO-8859-1.

Neben der Übermittlung des verwendeten Zeichensatzes im Head-Tag, besteht auch die Möglichkeit den Zeichensatz im Header, der im Browser nicht angezeigt wird, sondern nur für die Kommunikation erforderlich ist, zu übermitteln.

Werden der verwendete Zeichensatz sowohl im Head-Tag als auch im Header übermittelt, so vertraut der Browser üblicherweise auf den im Header. Dieser muss allerdings nicht immer korrekt sein, schließlich ist sehr häufig ein Standardwert eingestellt, der nicht unbedingt mit dem tatsächlich verwendeten Zeichensatz übereinstimmt. Das Ergebnis sind dann Fragezeichen oder Quadrate anstelle von Umlauten.

Nun folgt noch, wie man die Charset-Einstellungen auf verschiedene Arten und Weisen setzen kann:

Im Head-Tag:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Header mit PHP-Skript setzen:

header("Content-Type: text/html; charset=utf-8");

In der php.ini:

default_charset = "utf-8"

In der Apache-Konfiguration oder in einer .htaccess-Datei (“AllowOverride FileInfo” muss hierfür erlaubt sein):

AddDefaultCharset Off

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');

Auf Servern, auf denen auch das CLI (Command Line Interface) von PHP als CGI-Version ausgeführt wird, kommt es beim Aufrufen der Datei “cli_dispatch.phpsh” von TYPO3 zum Fehler “Not called from a command line interface (eg. a shell or scheduler).”. Dieser kann recht einfach behoben werden, indem man die erste Code-Zeile der Datei ”cli_dispatch.phpsh” von

if (PHP_SAPI!='cli') {

auf

if (PHP_SAPI!='cli' && substr(PHP_SAPI,0,3)!='cgi') {

korrigiert. Zusätzlich muss man auch noch darauf achten, dass in der php.ini “register_argc_argv” auf “On” gestellt ist:

register_argc_argv = On

Wäre dies nicht der Fall, könnte PHP nicht auf die Variablen $_SERVER['argc'] und $_SERVER['argv'] zugreifen und das würde den Fehler “The first argument must be a valid key.” hervorrufen.