Vorgestern war es mal wieder soweit. 1und1 hat seinen Managed Servern erneut eine kleine Frischzellenkur gegönnt. Hintergrund war wohl vor allem die bekannt gewordene PHP-Lücke, über die ich ja schon an anderer Stelle berichtet hatte. Aber auch der Apache-Server wurde schön aktualisiert. Nach dem Update hatte ich allerdings (und habe bei einigen Instanzen immer noch) mit etlichen Problemen zu kämpfen. Deshalb an dieser Stelle ein Beitrag, der etwas technischer wird und helfen soll mögliche Fehlerquellen zu lokalisieren und zu lösen.

Zu allererst

Etwas scheint sich seit meinem letzten Nörgel-Beitrag auch bei 1und1 geändert zu haben. Zum ersten Mal musste ich nicht mehr lange Zeit drauf warten, dass Jemand bei meinem Anruf im Service-Center abnimmt, und zum ersten Mal hatte ich einen kompetenten Ansprechpartner, der mit mir zusammen an der Lösung des Problems interessiert war. Schlimmer noch, der Mitarbeiter hat sich gut 45-60 Minuten Zeit genommen um mir zu helfen. Solchen Service bin ich nicht gewohnt gewesen. Das war vorbildlich!!! Weiter So!!! – Natürlich hab ich dem Mitarbeiter eine durchgehend sehr gute Bewertung gegeben. So Jemand gehört befördert!

Performance Server abgeschaltet

Der klassische Performance Server ist jetzt Standardmäßig aus. Damit ergeben sich aber auch einige Dinge, auf die man achten muss. Unter anderem sind jetzt PHP-Flags von Haus ausgeschaltet. Will man trotzdem einige Dinge vorgeben, dann muss man sie in eine php.ini Datei einfügen. PHP-Flags in .htaccess haben zudem zur Folge, dass die Seite oftmals einen 500er Server-Error meldet. Also Vorsicht vor dem Gebrauch in .htaccess!

Neue Imagemagick-Version

1und1 hat beim Update auch eine neue Version von Image-Magick eingebaut. Die Version 6 ist jetzt Standardmäßig aktiv. Dies bedeutet zwar einen Sprung in die richtige Richtung, allerdings kann es gerade deshalb auch zu Fehlern im Seitenaufbau kommen.

Einfaches Beispiel. Auf dem alten Server war der Pfad zu Image-Magick irgendwas mit /usr/bin/X1011/, jetzt ist der Pfad ganz einfach und richtig /usr/bin/. Das Problem ist, dass einige Leute natürlich bei ihrer Installation vor Urzeiten den falschen Pfad angegeben haben. Deshalb kann es passieren, dass Image-Magick gar nicht richtig funktioniert und vor allem im Backend keine Thumbnails erstellt werden, als auch im Frontend von Typo3 bestimmte Bild-Arten nicht angezeigt werden (z.B. bmp, gif).

Aus diesem Grund lieber im Install Tool anmelden und einmal den Grafik-Check erneut durchführen. Wenn ihr eine Fehlermeldung habt, dann prüft den Pfad zu Imagemagick unter All Configuration. Dieser sollte entsprechend der Server-Konfiguration nur noch /usr/bin/ lauten.

Ein weiteres Problem ist, dass auf Bilder-Intensiven Seiten, trotzdem die Angabe des richtigen Pfads nicht unbedingt zu einer Entlastung führt. Viele User berichten im Netz über Thumbnails die nicht generiert werden. In diesem Fall muss man auch (eigentlich sollte man es gleich tun) in die localconf.php (zu finden unter typo3conf) ganz am Anfang putenv('MAGICK_THREAD_LIMIT=1'); eingeben.

Damit wird sichergestellt, dass jedes Bild einzeln erzeugt wird, und das /tmp Verzeichnis mal wieder nicht vollläuft.

Verzeichnis-Berechtigungen prüfen

In einem sehr krassen Fall ist es leider dazu gekommen, dass die Präsenz gar nicht mehr richtig aufgebaut wurde. Erst der Rückgriff auf ein paar Ideen brachte dann die Lösung. Ich hatte nämlich den Eindruck, dass die Präsenz grundsätzlich nicht auf Dateien zugreifen konnte.

Zuerst wurde gesagt, dass Typo3Temp wäre nicht beschreibbar (Berechtigungen waren falsch) und dann prüfte ich ob überhaupt fileadmin erreichbar war von außen. Das Ergebnis war, dass statt 755 eine 750 eingetragen war in den Berechtigungen. CHMOD auf 755 von fileadmin brachte dann wieder alles zum Arbeiten.