ScriptBlogger

Wir haben es endlich geschafft, den neuen VPS bei Host Europe zu bestellen. Zugang haben wir schon. Die neue IP 46.163.115.119. Jetzt haben wir sieben Tage Zeit, die Projekte auf den neuen Server umzuziehen, bevor der alte Server automatisch offline geht.

Die neue Plesk-Oberfläche sieht ganz schick aus. Hoffentlich funktioniert sie auch. Mal sehen, ob wir die Ausfallzeiten für die Projekte (wegwerfemail.de, geblitztworden.de, kleinerlink.de etc.) so kurz wie möglich halten können.

Als Website-Betreiber ist man Webspace-Providern mehr oder weniger ausgeliefert. Man könnte wechseln, aber dann kommt man doch nur vom Regen in die Traufe. Und man hofft bis zuletzt, dass es sich bessert.

Bei 1&1 ist Hopfen und Malz verloren. Deswegen haben wir dort Kundenprojekte abgezogen und würden auch selbst dort keinen Managed Server betreiben.

Bei Domainfactory wären wir eigentlich ganz glücklich, wenn die nicht ständig die Server abklemmen und an einen anderen Ort bringen würden.. Das erste Mal sind die mit Sack und Pack von einem Rechenzentrum in ein anderes gezogen. Und heute kommt erneut eine Benachrichtigung, dass "[...] sich auch der physikalische Standort Ihres Servers im Rechenzentrum geringfügig ändern wird.". Angepeilte Ausfallzeit ist 30 Minuten.

Ich frage mich, wie oft die noch die Server durch die Gegend tragen wollen.

Nachdem es ständig Ausfälle bei dem Managed Server von 1&1 gibt und der Support frech, inkompetent und langsam ist, ziehen wir mit der Anwendung eines Kunden zu Domainfactory um. Gleichzeitig gibt es ein Hardware-Upgrade.  *freu*

Ein weiterer Grund für die Entscheidung war, dass Domainfactory 99,9% Uptime garantiert. Im Gegensatz zu den 99% von 1&1. Das heißt, Domainfactory garantiert, dass der Server nur halben Tag im Jahr offline ist. Bei 1&1 wären das schon dreieinhalb Tage.

In unserem News Script gibt es folgende Zeile:

$query = getenv('QUERY_STRING');

Auf dem Server des Kunden blieb $query jedoch leer. Die Ausgabe der Umgebungsvariable per echo funktionierte jedoch:

<?php echo getenv('QUERY_STRING'); ?>

Dank der Alternative $_SERVER['QUERY_STRING'] war das nicht weiter dramatisch. Merkwürdig ist es aber schon.

Letzte Woche haben wir Strato die Schnarchnase des Jahres genannt. Heute haben wir weitere Informationen. Scharchnase ist möglicherweise nicht ganz gerechtfertigt, aber mangels eines anderen Wortes bleiben wir erst mal dabei.

Bei Strato kann man über zehn Jahre alte PHP-Versionen verwenden. PHP 3 ist mit Version 3.0.18 immer noch verfügbar.

Als Standardversion ist nach wie vor 4.1.2 eingestellt. Alternativ kann man sie mit folgender Zeile in einer .htaccess aktivieren:

AddType application/x-httpd-php41 .php

Die letzte PHP-4-Version 4.4.9 lässt sich mit eine der folgenden Zeilen aktivieren:

AddType application/x-httpd-php4 .php
AddType application/x-httpd-php43 .php

Die aktuelle PHP-Version 5.2.8 erhält man mit:

AddType application/x-httpd-php5 .php

Alternativ kann man die PHP-Version für das gewünschte Verzeichnis über die Verwaltungsoberfläche des Web-Accounts auszuwählen. Zur Auswahl steht dann die jeweils aktuelle Version von PHP 4 und PHP 5.
Bei der Änderung wird dann in dem Verzeichnis eine .htaccess geschrieben, die der Datei-Endung .php dann zum Beispiel PHP 5 zuweist. Eine eventuell bestehende .htaccess wird .htaccess.bak umbenannt. Man muss also die Einstellungen aus der alten .htaccess in die neue .htaccess übertragen.

Warum die genaue PHP-Version von Relevanz ist? PHP hat mit Version 5 einiges an Funktionalität hinzubekommen und die Performance drastisch verbessert. PHP 4 wird nicht mehr gepflegt und ist hoffnungslos veraltet - was sowohl die Funktionalität als auch die Sicherheit angeht. Davon ist die letzte veröffentlichte PHP-Version 4.4.9 keine Ausnahme. Dann noch standardmäßig PHP 4.1.2 am Laufen zu haben, kann man einfach nur noch verantwortungslos nennen.

Webspace-Provider deaktivieren und blockieren alle möglichen Dinge aus allen möglichen Gründen. Diesmal traf es einen Kunden unseres Wegwerf-E-Mail-Scripts. Bei abgeschaltetem JavaScript funktionierte noch alles bestens. Mit JavaScript und dadurch aktiviertem XML HTTP Request (oder auch Ajax, wenn es denn sein muss) gab der Server jedoch eine Fehlermeldung zurück:

HTTP Error Making Request: [406] Not Acceptable

Derselbe Aufruf manuell im Browser ausgeführt, funktionierte. Der Kunde fragte beim Server-Betreiber nach und meldete:

They do not support AJAX on their server they say.

Häh? Leider ließ sich der Webhoster zu keiner Begründung bewegen. Wir hätten wirklich gern gewusst, wass der Grund für diese Einschränkung ist.

Der Kunde hat kurzerhand die Reißleine gezogen und den Provider gewechselt.

Auf den meisten Servern sind Index-Seiten definiert, die angezeigt werden, wenn ein Verzeichnis ohne Datei aufgerufen wird. http://www.example.com/ zeigt automatisch den Inhalt von http://www.example.com/index.html an, sofern vorhanden. Genauso gut könnte man http://www.example.com/index.html direkt aufrufen. Das Ergebnis wäre inhaltlich dasselbe.

Nicht so leider für unser Kommentar-Script. Das, nämlich, unterscheidet sehr wohl zwischen den beiden oben genannten URLs. Wenn nun Besucher die Seite mal mit index.html und mal ohne aufrufen und einen Kommentar hinterlassen, hat der Betreiber am Ende zwei verschiedene Sätze von Kommentaren, die eigentlich zusammen auf der Seite angezeigt werden sollten.

Lösen lässt sich das mit Mod Rewrite und .htaccess.

Folgender Code leitet von http://www.example.com/index.html zu http://www.example.com/

RewriteEngine on
RewriteRule index\.html / [L,R=301]

Angenommen, man hat ein oder mehrere Unterverzeichnisse, ergänzt man einfach den entsprechenden Pfad. Folgender Code leitet von http://www.example.com/test/beispiel/index.html zu http://www.example.com/test/beispiel/.

RewriteEngine on
RewriteRule index\.html /test/beispiel/ [L,R=301]

Recht hilfreich ist diese Methode auch um zu verhindern, dass solche Seiten doppelt in den Suchmaschinen landen. Stattdessen kommt nur http://www.example.com/ in den Index und nicht auch noch http://www.example.com/index.html.

Nicht nur Strato-Server trumpfen mit merkwürdigen Pfaden auf. Auch Web-Server anderer Web-Space-Provider spielen ein doppeltes Spiel.

Unser Comment Script erstellt während der Installation automatisch eine Datei, welche den Server-Pfad zum Script enthält. Den Pfad bezieht das Script dabei aus der Umgebungsvariable DOCUMENT_ROOT.

Dass man DOCUMENT_ROOT jedoch nicht ohne Weiteres trauen sollte, zeigte sich auch im folgenden Fall. Das Script eines Anwenders meldete folgenden Fehler:

Warning: include(): open_basedir restriction in effect. File(/usr/local/apache/htdocs/comments/comment.php) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/c999999/public_html/comments/include.php on line 11

Zwei Dinge, die hier auffallen. Erstens, das Script befindet sich auf einer Shared-Hosting-Maschine. Ein Pfad wie /usr/local/apache/htdocs/ passt da aber nicht ins Bild. Es fehlt die Zuordnung zu einem Kunden.

Und zweitens, beide Pfade unterscheiden sich. Zumindest der vordere Teil des Pfades sollte gleich sein. Laut Fehlermeldung aber wurde das Script unter dem Pfad /usr/local/apache/htdocs/ (laut DOCUMENT_ROOT) und unter dem Pfad /home/c999999/public_html/ (laut Fehlermeldung) installiert. Ein Script mit gespaltener Persönlichkeit?

Wohl kaum. Das Problem war gelöst, nachdem der Anwender den falschen Pfad (der aus dem DOCUMENT_ROOT kam) durch den korrekten Pfad (der durch die Fehlermeldung preisgegeben wurde) ersetzt hatte.

Vielleicht ist es ja Absicht, aber auf jeden Fall ist es merkwürdig und auf keinen Fall ist es etwas, was man erwarten würde. Folgende Konstellation: Eine Kundin betreibt seit einiger Zeit Webpräsenz ABC-BEISPIEL.de. Der DOCUMENT_ROOT dafür lautet in etwa wie folgt:

/home/strato/www/a/www.abc-beispiel.de/htdocs

So weit so unspektakulär. Nun hat die Kundin eine weitere Domain (XYZ-BEISPIEL.de) hinzugefügt und auf ein Unterverzeichnis (/xyz-beispiel/) von Domain ABC-BEISPIEL.de geschaltet. Der DOCUMENT_ROOT dafür müsste eigentlich wie folgt aussehen:

/home/strato/www/a/www.abc-beispiel.de/htdocs/xyz-beispiel

Tatsächlich wird der DOCUMENT_ROOT jedoch wie folgt angezeigt:

/home/strato/www/x/www.xyz-beispiel.de/htdocs

Damit könnte man ja noch leben, wenn der Pfad auf das oben beschriebene Unterverzeichnis linken würde. Tut er aber nicht. Stattdessen zeigt der Pfad auf das selbe Verzeichnis wie:

/home/strato/www/a/www.abc-beispiel.de/htdocs

Es scheint, als würde Strato als Wert für den DOCUMENT_ROOT immer den Pfad zum Hauptverzeichnis des Webspace-Accounts eintragen, unabhängig davon, auf welches (Unter-)Verzeichnis die Domain wirklich geschaltet ist. Damit ist die Umgebungsvariable DOCUMENT_ROOT praktisch nicht mehr zu gebrauchen. Man muss sich also den korrekten Pfad selbst zusammenbasteln.

Dabei spielt keine Rolle, welchen Pfad man benutzt. Es funktionieren

/home/strato/www/a/www.abc-beispiel.de/htdocs/xyz-beispiel

und

/home/strato/www/x/www.xyz-beispiel.de/htdocs/xyz-beispiel

Da fragt man sich echt, was das soll.

Parallels hat sich mit Plesk 9 zurückgemeldet. Es gibt eine neue Wiederverkäufer-Ebene (Resellers Level) und eine integrierte Rechnungslegung (Billing solution). Außerdem wurde die Backup-Funktion verbessert und Postfix Mail-Server verfügbar.

Groß und breit wurde auch PHP over Fast CGI angekündigt; die Ausführung lässt aber zu wünschen übrig. Zwar kann man bequem per Plesk-Oberfläche den gewünschten Modus auswählen, nach dem Umschalten auf Fast CGI zeigte phpinfo() jedoch folgendes:

PHP Version 4.4.0

Und das, obwohl auf der Maschine bereits PHP 5 installiert ist und der Host vorher damit lief. Abhilfe schafft vermutlich, das in der Datei /conf/httpd.include konfigurierte Verzeichnis von php auf php5 zu ändern. :-[]

Ansonsten hat sich noch die Bedienungsoberfläche geändert. Die Standardoberfläche heißt "Vista" und kommt mit neuen Icons daher. Die sind gewöhnungsbedürftig, jedoch lässt sich die gewohnte Oberfläche wiederherstellen. Verschwunden ist allerdings der Menüpunkt "Server". Die bisher darin enthaltenen Funktionen wurden auf andere Menüs aufgeteilt. Also ist Suchen ist angesagt. So befindet sich die Verknüpfung zum Updater auf der Homepage im Bereich Hilfe & Support. :-O

Fazit: Plesk ersetzt immer noch nicht den Server-Admin, der per Kommandozeile Software aktualisieren und konfigurieren kann.

Ein Kunde unseres News Scripts schrieb, dass beim Aufruf des Scripts im Browser nichts angezeigt würde.

Eine kurze Recherche zeigte dann auch etwas ungewöhnliches. Normalerweise erstellt die Smarty-Template-Engine die vorkompilierten Scripte mit Dateinamen wie diesem:

%%83^83B^83B7EFCA%%layout.tpl.html.php

Beim Kunden sahen die aber so aus:

wrt490a1737906fe

Kein Wunder also, dass nichts ausgegeben wird, wenn die Template-Dateien nicht gefunden werden. Haben wir dem Kunden auch ausführlich so erklärt und empfohlen, sich an den Webspace-Provider zu wenden.

Darauf kam dann folgendes:

Do you have any idea's on where the problem is coming from?

Hm. Wir dachten eigentlich, es wäre offensichtlich, dass der Server da seine Finger zwischen hat. Hätten wir vielleicht explizit in der E-Mail erwähnen sollen.

Aber der Kunde war uns trotz allem wohlgesonnen, ...

I really feel your product is the best fit for us and I would like to get it to work.

... und konnte dann das Problem sogar selbst lösen:

I reset the permissions on the entire "events" folder to Read/Write & Execute. I also changed the permissions on the cache to Full Control. Since I am working off of an IIS server I checked to apply permissions to all child objects for both the cache folder and the "events" folder.

IIS. Das erklärt natürlich einiges. ;-)

Phpinfo() ist nützlich. Phpinfo() erfüllt keinen anderen Zweck, als nützlich zu sein. Warum ein Server-Betreiber phpinfo() manipuliert und unter anderem die Anzeige der Umgebungsvariablen verhindert, wird wohl für immer ein Rätsel bleiben.

Im vorliegenden Fall war der Grund für den Griff nach phpinfo(), dass der Aufruf von getenv('REQUEST_URI') folgendes produzierte:

/www;example.com/beispiel/pfad/datei.php

Der Domain-Name im REQUEST_URI? Ein Semikolon im Domain-Namen? Da ist ja wohl alles falsch.

$_SERVER['REQUEST_URI'] im Gegenzug hat den korrekten Wert angezeigt.

/beispiel/pfad/datei.php

Zum Glück war es nur eine Stelle im Script, die geändert werden musste.

Antwort vom Kunden:

I got Lycos as provider. They somethimes got very strange methodes. The first time i also got problems with oscommerce.

Was lange wehrt... Nachdem PHP 5 seit Jahren verfügbar und auf vielen Servern parallel zu PHP 4 installiert war und ist, bietet den Aussagen Parallels zufolge Plesk ab Version 9 die Möglichkeit, mehrere PHP-Versionen nebeneinander zu betreiben.

PHP over Fast CGI

Site applications based on PHP implementation will now be executed faster and safer with PHP running in the Fast CGI mode. This enhancement allows running several PHP versions simultaneously.

Großartig. Für die Kombination PHP 4/ PHP 5 kommt das Ganze zu spät, aber PHP 6 wirft ja bereits seine Schatten voraus. Bleibt noch die Frage, wie einfach oder wie aufwändig es sein wird, die zwei PHP-Versionen auf den Server zu bringen. Wir werden sehen.

Verwandter Artikel: Plesk 9 ist verfügbar - halbwegs

Drei Möglichkeiten, um zu verhindern, dass Suchmaschinen Seiten mit angehängter PHP-Session-ID in ihren Index aufnehmen:

ini_set() im PHP-Script

ini_set('session.use_trans_sid', false);

.htaccess

php_flag  session.use_trans_sid off

robots.txt

User-agent: *
Disallow: /*PHPSESSID  

Nachtrag:

Die erste Methode per ini_set funktioniert nur bis PHP 4.2.3. Bei späteren PHP-Versionen funktioniet es nur per .htaccess oder, wenn PHP als CGI installiert ist, per php.ini. Letztere kommt in das entsprechende Verzeichnis auf dem Server und hat folgenden Inhalt:

session.use_trans_sid = 0

Wir berichteten vor kurzem, dass die Handhabung der PEAR-Klasse Net_FTP im Zusammenhang mit dem passiven Modus nicht ganz eindeutig ist. Kommentator JR hat deshalb auf pear.php.net eine Funktionsänderung vorgeschlagen und siehe da: Nur wenige Tage später wurde die FTP-Klasse entsprechend erweitert.

Ein Blick auf die verschiedenen Versionen der Klasse zeigt, dass der Entwickler den Aufruf zum aktivieren einer passiven Verbindung¹ erst im zweiten Anlauf an der richtigen Stelle platziert hat. Nämlich nach dem Login und nicht bereits schon nach dem Herstellen der Verbindung. Waren also nicht nur wir verwirrt. ;-)

Jetzt ist die Fußangel allerdings (fast)² beseitigt. Man kann nun setPassive() vor dem Herstellen der Verbindung, nach dem Herstellen der Verbindung oder nach dem Login aufrufen - der Effekt ist derselbe.

1) Eine passive Verbindung aktivieren? Das ist ja wie laufen gehen (joggen). 

2) Momentan allerdings funktioniert nur die bisherige Methode, denn folgender Code verhindert den automatischen Aufruf in der Methode login().

if (!$this->_passv) {
    $this->setPassive();
}

Das Ausrufezeichen ist zu viel. Beim Aufruf von setPassive() wird $this->_passv = true gesetzt. $this->_passv dann aber später auf false zu Prüfen haut nicht hin. Interessanterweise ist das Ausrufezeichen erst beim Umzug des Codes von der Methode connect() in die Methode login() dazugekommen. Merkwürdig, merkwürdig.

Nachtrag: 

Auf unseren Hinweis hin wurden auch die übrigen Fehler korrigiert. Funktioniert jetzt alles bestens. Vielen Dank dafür an dieser Stelle.