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.

Domainfactory: Einbindung der TYPO3 Sourcen mit Symlinks

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.

Begründung:

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

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.

Begründung:

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

DomainFactory: Langsame Datenbank

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

Begründung:

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.

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.

Autor:
Geändert: Donnerstag, 29. September 2016 11:29 Uhr
Erstellt: Dienstag, 24. März 2015 21:11 Uhr
Tags: , , , , , , , ,
Themengebiet: Web Entwicklung, Diverses, Web Entwicklung, TYPO3

Trackback: Trackback-URL LoadingZu Favoriten hinzufügen

Ein Kommentar

  1. 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.

Kommentar abgeben