TYPO3 Hosting – Eigenheiten der ISPs

Für verschiedene Kunden – und auch für mich selbst – verwalte ich bei diversen Hostern Webhosting Pakete und auch Managed Server. Dabei kommt es, in Verbindung mit TYPO3, immer wieder zu Schwierigkeiten, auf die ich in diesem Artikel näher eingehen möchte.

Gab es früher häufig Probleme mit ImageMagick bzw. GraphicsMagick, so bietet mittlerweile jeder Hoster diese Software an. Probleme gibt es nun häufig bei Cronjobs oder in Verbindung mit htaccess. Außerdem sind aus Sicherheitsaspekten oft bestimmte PHP Funktionen deaktiviert, wie zum Beispiel Funktion „exec„, die TYPO3 an bestimmten Stellen einsetzt.

Hinweis: Teilweise sind die Beiträge in diesem Artikel schon etwas älter und sind daher evtl. veraltet. Im besten Fall funktioniert TYPO3 bei dem ein oder anderen Hoster mittlerweile besser.

Cloudflare: Aufklappen von Dateien fehlerhaft (Januar 2021)

Wenn man Dateien (Bilder, Medien, Dokumente) aufklappt, erscheint nur eine Checkbox mit Eingabefeld, anstatt die Informationen zur Datei (z.B. Titel oder Beschreibung):

Dies liegt an Einstellungen in Cloudflare, wenn man dort die Einstellungen für Minify deaktiviert, tritt der Fehler nicht auf.

Cloudflare: Ständiger Logout aus TYPO3 BE (April 2020)

Bei Cloudflare ändert sich die IP Adresse des Besuchers ($_SERVER[‘REMOTE_ADDR’]) öfters mal, das kann bewirken, dass man aus dem TYPO3 Backend (oder auch Frontend) herausfliegt. Mit der Einstellung „lockIP“ in der Install Tool Konfiguration kann man das verhindern.

jweiland: Server von DomainFactory (Juli 2018)

jweiland nutzt die Server von DomainFactory und scheinbar auch deren Server-Images, denn dort gibt es die gleichen Probleme wie bei DomainFactory.

jweiland schreibt zu „Einbindung der TYPO3 Sourcen mit Symlinks“:

SymLinks auf Verzeichnisse (TYPO3 Sourcen) ist kein Problem, SymLinks auf Dateien ist nicht möglich

jweiland schreibt zu „Setzen des Application Contextes“:

Unter dem CGI PHP werden durch das Suexec alle Umgebungsvariablen vor dem Ausführen entfernt. Dies ist jedoch bei der Verwendung von FastCGI nicht der Fall. Sie also unter FASTCGI die Umgebungsvariablen setzen

jweiland schreibt zu „HTTP/2“:

Auch bei uns kann die Random Content Problematik mit FASCGI und http/2 jederzeit auftreten. Wir starten den Apache neu und die Problematik ist behoben.
zu 97% funktioniert http/2 mit FastCGI, leider gibt es auch bei uns hin und wieder die Random Content Problematik

jweiland schreibt zu „32-Bit“:

die Server laufen auf Grund der älteren PHP Versionen noch auf einem 32 Bit System, wir planen die Umstellung auf 64 Bit im 1. Quartal 2019.

DomainFactory: HTTP/2 (Juli 2018)

Wenn man FastCGI und HTTP/2 einsetzt, kommt es zu Fehlern, es werden willkürlich Inhalte (HTML und Bilder) angezeigt.

DomainFactory schreibt:

Ihre Domain verwendet derzeit sowohl FastCGI, als auch das Protokoll HTTP/2. Hierbei kommt es auf unseren Servern jedoch leider zu einem Fehler, welcher „Random Content“ produziert. Sie können daher sinnvoll nur eines von beiden nutzen.

DomainFactory: Umgebungsvariablen in htaccess (Mai 2018)

Die Umgebungsvariablen in htaccess funktionieren nur, wenn FastCGI aktiviert ist.

DomainFactory schreibt:

Nach Rücksprache mit unserer Technik kann ich Ihnen mitteilen, dass die Ursache für die Nicht-Funktionalität an der PHP-Version liegt. Laut unserer Technik werden die Umgebungsvariablen nicht korrekt übernommen wenn die Domain kein PHP-FASTCGI nutzt.

Bestimmte Umgebungsvariablen funktionieren gar nicht in htaccess, z.B. %{ENV:DOCUMENT_ROOT}.

DomainFactory schreibt:

Wir haben das Verhalten nun noch einmal ausgiebig getestet, hierbei konnten wir den Fehler reproduzierbar abbilden. Wir haben verschiedene Varianten getestet, auch auf externen Servern und mussten hierbei feststellen, dass der Fehler nur bei uns in dieser Form auftritt, da der DOCUMENT_ROOT nicht korrekt übergeben wird und somit die Regel nicht greift.[…]Ob und wann das Problem mit dem DOCUMENT_ROOT gefixt wird, können wir aktuell nicht absehen. Eine andere Alternative gibt es derzeit leider nicht.

DomainFactory: 32-Bit (Februar 2018)

Die Server (Managed Server) von DomainFactory laufen auf einem 32-Bit System (Stand Februar 2018).

DomainFactory schreibt:

Derzeit laufen alle Server (ausgenommen Jiffybox) mit einem 32-Bit System. Der Vorteil von 64-Bit ist, dass mehr Speicher adressiert werden kann. Derzeit arbeiten wir intern an einem 64-Bit Image und sobald dieses fertig ist, werden wir unsere Server entsprechend umstellen/aktualisieren. Leider kann ich Ihnen derzeit noch nicht mitteilen, wann dies der Fall sein wird.

Blöd nur, dass TYPO3 unter 32-Bit Probleme hat: ViewHelper f:format.date can’t handle unix timestamp > 2147483648

DomainFactory: Langsame Datenbank (Februar 2016)

DomainFactory setzt eine Konsistenzprüfung ein, die jeden Schreibvorgang in die Datenbank loggt.

DomainFactory schreibt:

Wir setzen auf unseren neuesten Server-Generationen das Dateisystem ext4 ein. Bei diesem Dateisystem ist eine Konsistenz-Prüfung (sogenannte „barriers“) aktiv, die jeden Schreibvorgang validiert. Dies erhöht die Datenintegrität und Datensicherheit, hat jedoch auf Auswirkungen auf die Schreib-Performance, die sich jedoch im normalen Betrieb kaum bemerkbar machen.
In Verbindung mit der MySQL-Tabellen-Engine InnoDB kommt es hierbei jedoch zu einer Verlangsamung der InnoDB-Schreibaktionen. In den Standard-Einstellungen, die von den Entwicklern empfohlen werden, wird jede InnoDB-Schreibaktion (UPDATE, INSERT) direkt auf das Log auf der Festplatte synchronisiert. Wenn hier nun viele solcher Aktionen durchgeführt werden, wie dies z.B. beim Import eines Dumps oder Änderungen im Backend eines CMS-Systems wie Typo3 der Fall ist, dann verlangsamt sich hier der gesamte Vorgang, da jeder einzelne Schreibzugriff eine geringe Verzögerung aufweist.

Diese „geringe Verzögerung“ betrugt bei mir, bei einfachsten UPDATE und INSERT Queries, laut Slow Queries Log bis zu 4 Sekunden.

Lösung:

DomainFactory hat folgendes vorgeschlagen:

Es gibt hier nun jedoch die Möglichkeit die Einstellungen des MySQL-Servers so anzupassen, dass nicht jede InnoDB-Aktion direkt einen Schreibvorgang auf der Festplatte auslöst. Im Detail handelt es sich um eine Anpassungen der Option „innodb_flush_log_at_trx_commit“. Der MySQL-Dienst kann durch Veränderung dieser Option auch automatisch alle 1-3 Sekunden im Hintergrund eine Synchronisation ausführen. Hierdurch wird die Verlangsamung der InnoDB-Aktionen dann stark geschwächt. Da es hierbei aber mit einer sehr geringen Wahrscheinlichkeit zu einem Datenverlust von wenigen Sekunden kommen kann, ändern wir die Einstellung des Dienstes hier nur mit der expliziten Zustimmung unseres Kunden.

Ob diese Einstellung Erfolg hat, muss ich noch prüfen.

Domainfactory: Einbindung der TYPO3 Sourcen mit Symlinks (März 2015)

Idealerweise legt man die TYPO3 Sourcen außerhalb des Web-Verzeichnisses ab und verweist darauf per Symlink. Bei der aktuellen TYPO3 Version wären das zwei Symlinks, einer auf das Verzeichnis „typo3„, einer auf die Datei „index.php„. Bei Domainfactory ist ein Symlink auf „index.php“ nicht möglich.

DomainFactory schreibt:

Symlinks sind bei uns aus Sicherheitsgründen nur auf nicht ausführbare Ziele wie z.B. Ordner oder Bilder möglich.

und

Symlinks auf ausführbare Dateien sind bei uns verboten, da dies bei bestimmten Konstellationen andere Sicherheitsmerkmale wie z.B. Quotas umgehen könnte.

Resultierende Probleme:

  1. Keine vollständige Einbindung der Sourcen möglich, die Datei „index.php“ muss in das Web-Verzeichnis kopiert werden.
  2. Warnungen im Install-Tool: „Path /index.php is not a link
  3. TYPO3 „Core Update“ aus dem Install-Tool heraus nicht möglich: TYPO3 verweigert das Update wegen den Warnungen (siehe 2.)

Domainfactory: Setzen des Application Contextes (Januar 2015)

In TYPO3 kann man verschiedene Kontexte definieren, z.B. „Development“ oder „Production“. Standardmäßig wird dieser Kontext über die htaccess Datei gesetzt:

RewriteCond %{HTTP_HOST} ^dev\.example\.com$
RewriteRule .? - [E=TYPO3_CONTEXT:Development]

Bei Domainfactory führt diese Anweisung aber nicht zu dem gewünschten Ergebnis, in PHP ist die Kontext-Variable leer.

DomainFactory schreibt:

PHP wird bei uns unter CGI ausgeführt und nicht als Modul des Webservers weshalb Umgebungsvariablen des Webservers nicht an PHP übergeben werden.

Domainfactory: Cronjobs

Einen Cronjob auf den „TYPO3 Scheduler“ funktioniert nicht wie von TYPO3 vorgesehen, mit der Anweisung „/typo3/cli_dispatch.phpsh scheduler„, sondern man muss den Umweg über eine .sh-Datei mit folgenden Inhalt gehen:

#!/bin/bash
env -i /usr/local/bin/php -f /kunden/kunden-id/pfad/zu/typo3/cli_dispatch.phpsh scheduler

Aktuell läuft bei Domainfactory noch PHP 4. Wenn man eine neuere PHP-Version einsetzen möchte oder ein höheres Memory-Limit benötigt, muss man dies beim Aufruf angeben:

#!/bin/bash
env -i /usr/local/bin/php5-55STABLE-CLI -d memory_limit=512M -f /kunden/kunden-id/pfad/zu/typo3/cli_dispatch.phpsh scheduler

Alfahosting: Cronjobs

Mit Cronjobs gibt es bei Alfahosting öfters Probleme. Teilweise findet der Support diesen Fehler schnell…

[…]der Cronjob ist aus leider unbekannten Grund „hängen geblieben“ und läuft ab sofort wieder.

…aber es kam auch schon vor, dass erst nach 14 Nachrichten im Ticket erkannt wird:

[…]nach nochmaliger Prüfung, stellte sich nun heraus, dass der Fehler beim Cron selbst lag, nicht am Script. Wir mussten als Workaround die Shebang komplett entfernen und den Interpreter auf PHP 5.4 stellen.

Man muss auch wissen, dass ein Cronjob bei Alfahosting deaktiviert wird, sobald er 10 Mal mit einem Fehlerstatus endet. Wenn man ihn im Konfigurationsmenü erneut abspeichert, ist er wieder aktiv.

Nicht verständlich ist mir, wieso bei Alfahosting Cronjobs (ebenso wie bei Domainfatory) standardmäßig mit PHP Version 4 ausgeführt werden. Man kann zwar in den Server-Einstellungen des Kundenaccounts eine andere PHP Version einstellen, das hat aber keine Auswirkung auf die PHP Version, die in der Kommandozeile genutzt wird.

[…]mit /usr/bin/php sprechen Sie nur PHP 4 an. Das ist nun einmal der Pfad auf dem Server.

Lösung: Shebang in Datei cli_dispatch.phpsh ändern auf

#! /usr/bin/php5.4 -q

Resultierende Probleme: Bei einem TYPO3 Update werden diese Änderungen überschrieben und der Cronjob wird wieder nicht funktionieren. Dazu schreibt Alfahosting:

Wenn Typo3 das Shebang beim Update überschreibt und dies ist kein gewünschter Vorgang, kann nur Typo3 das Problem lösen. Wir empfehlen, dazu einmal den Support von Typ3 zu kontaktieren. Eventuell gibt dort schon einen Workaraound zu dieser Problematik.

Mittwald: TYPO3 Caching

Auf einem Mittwald Server hatte ich bei einem großen TYPO3 Portal schon das Phänomen, dass bestimmte Seiten von TYPO3 partout nicht gecached wurden, nach dem Leeren des Caches hat es für bestimmte Seiten funktioniert (für die es zuvor nicht funktioniert hat), allerdings nur bis zum nächsten Cache-Leeren. Für dieses Problem habe ich keine Lösung gefunden. Nach einem Umzug zu Domainfactory hat es anstandslos funktioniert, auch bei mir in der lokalen Entwicklungsumgebung hatte ich keine Probleme.

Ein Kommentar zu “TYPO3 Hosting – Eigenheiten der ISPs”

  1. Meine index.php bei Domainfactory besteht aus einem

    include_once( ‚typo3_src/index.php‘);

    Diese Lösung vermeidet, dass man die index.php bei Updates kopieren muss.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.