Shared Hosting #

Diese Seite ist für Hosting-Anbieter, die Exponential auf Shared Hosting anbieten möchten: viele Kundenkonten auf einer Maschine, über ein Panel verwaltet, meist mit FTP und ohne Shell für den Kunden. Sie beantwortet, was dort laut den Quellen des Projekts funktioniert, was meist nicht, wie eine Website ohne Shell installiert wird und was pro Konto zu konfigurieren ist.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Inhalt #

1. Was die Quellen sagen
2. Auslieferung: Apache oder LiteSpeed mit .htaccess
3. Installation ohne Shell
4. PHP-Einstellungen pro Konto
5. Datenbanken auf Shared Hosting
6. Cronjobs
7. Abschottung zwischen Konten
8. Checkliste

Was die Quellen sagen #

• Ihr Hosting lässt Sie keinen lang laufenden Prozess ausführen. Shared Hosting tut das meist nicht. Apache oder LiteSpeed mit .htaccess ist dort die Antwort (README.md im Wurzelverzeichnis, Abschnitt dazu, wann ein klassischer Server noch die richtige Antwort ist).
• Velocity passt meist nicht zu Shared Hosting, weil er einen lang laufenden Prozess braucht; Apache mit PHP-FPM passt (Kapitel 8).
• Shared Hosting ohne Shell-Zugang: der Assistent. Er braucht nur einen Browser und FTP-Zugang (Kapitel 4).
• Hosts mit cPanel und DirectAdmin sind Stufe 3: Shared Hosting kann lang laufende Prozesse verbieten, sodass Velocity womöglich nicht erlaubt ist; nutzen Sie Apache oder LiteSpeed mit .htaccess (Stufe 3).
• Seit 6.0.15 arbeitet der Setup-Assistent nur mit Ihrer eigenen Datenbank: Er führt kein SHOW DATABASES mehr aus und öffnet die Systemdatenbank mysql nicht mehr, was Rechte bräuchte, die ein Shared Host nicht vergibt (Eine saubere Installation, die zu Shared Hosting passt).

Auslieferung: Apache oder LiteSpeed mit .htaccess #

Die Rewrite-Regeln liegen im Wurzelverzeichnis der Installation als .htaccess_root. Der Kunde (oder Ihre Bereitstellung) kopiert sie, sodass ein Update eine neue Version bringen kann:

cp .htaccess_root .htaccess
# oder, wo das Konto eine Shell hat, als Benutzer des Kontos:
php bin/php/console exp:setup:htaccess --apply

Der Konsolenbefehl übernimmt den Modus der Vorlage, weigert sich, eine abweichende .htaccess zu überschreiben (er zeigt den Diff; --force --apply ersetzt sie nach einer Sicherung in var/backup/setup/<zeit>/) und sagt ohne --apply, was er tun würde. php bin/php/console exp:setup:config --apply bringt config.php auf dieselbe Weise an ihren Platz. Ohne Shell legt der Dateimanager oder der FTP-Client die Kopie an. Siehe .htaccess und config.php von der Konsole einrichten.

Nutzen Sie stattdessen .htaccess_root_static (exp:setup:htaccess --static --apply) nur, wenn die Website einen erzeugten statischen Cache ausliefert. Für Apache muss der virtuelle Host .htaccess wirken lassen (AllowOverride All auf dem Document Root), und mod_rewrite muss an sein; ein 404 für jede Seite bedeutet, dass .htaccess nicht gelesen wird (AllowOverride) oder mod_rewrite aus ist (8.5 Apache mit PHP-FPM). LiteSpeed liest die Rewrite-Regeln von Apache in den meisten Fällen und ist Stufe 3 (Webserver).

Hinweis Der Document Root des Kontos muss das Wurzelverzeichnis der Installation sein, das Verzeichnis, das index.php enthält. Die Sicherheit kommt vom Routing, nicht vom Verzeichnisaufbau: Nur eine feste Liste von Asset-Pfaden wird als Dateien ausgeliefert; alles andere geht an index.php (13.2). Eine allgemeine Konfiguration eines Panels „Datei ausliefern, wenn sie existiert“ würde settings/*.ini und die SQLite-Datenbank ausliefern; prüfen Sie einmal pro Server-Image, dass eine Anfrage nach /settings/site.ini eine HTML-Seite liefert, nie INI-Text.

Mehr: Apache mit PHP-FPM, LiteSpeed.

Installation ohne Shell #

Ohne Shell kann der Kunde Composer nicht ausführen, und ohne Composer, oder ohne dass es ausgeführt wird, fehlt vendor/, und die Website kann nicht starten (2.7 Composer). Daraus ergeben sich zwei praktische Wege:

1. Der Hoster stellt den Code bereit. Ihre Bereitstellung (ein Ein-Klick-Installer, ein Vorlagenkonto) legt einen Baum an, in dem composer install bereits gelaufen ist, und dann öffnet der Kunde den Setup-Assistenten im Browser. Siehe Ein-Klick-Installer.
2. Der Kunde bereitet den Code anderswo vor. Der Kunde führt Composer auf einer anderen Maschine mit derselben PHP-Version wie das Konto aus und lädt den ganzen Baum, einschließlich vendor/, per FTP hoch.

Dann erledigt der Setup-Assistent den Rest im Browser: Seine Seite Systemtest prüft PHP, die Erweiterungen, die beschreibbaren Verzeichnisse und die php.ini-Werte und gibt für jeden Fehler die Abhilfe aus (Der Setup-Assistent auf Shared Hosting, Kapitel 5).

Warnung Ein langer Schritt des Assistenten kann an die Zeitgrenze für Anfragen von PHP-FPM des Kontos stoßen. Die Notizen zur MongoDB-Portierung beschreiben, wie der Assistent durch das request_terminate_timeout des Pools abgebrochen wird, das set_time_limit() von PHP selbst nicht überschreiben kann (MongoDB-Unterstützung im Kernel). Wenn die Installationen auf Ihrer Plattform lange laufen, erhöhen Sie die Grenze für die Installation und senken Sie sie danach wieder.

PHP-Einstellungen pro Konto #

Der Setup-Assistent prüft diese (2.5 php.ini-Einstellungen):

Panels setzen open_basedir und disable_functions oft pro Konto. Der Assistent warnt nur bei open_basedir. Die Seite Cronjobs in der Administration braucht proc_open, um einen Job zu starten, exec, um die Crontab zu lesen, und posix_kill, um einen Job anzuhalten; ist eine davon deaktiviert, öffnet sich die Seite trotzdem und sagt, welche Funktion fehlt (Cronjobs, Bevor Sie beginnen).

Details: PHP-Einstellungen für Exponential, PHP-Auswahl und FPM-Pools.

Datenbanken auf Shared Hosting #

In der offiziellen Reihenfolge: 1. SQLite 3 (der Standard) · 2. PostgreSQL · 3. MongoDB · 4. MariaDB · 5. Oracle · 6. MySQL. Microsoft SQL Server ist derzeit bekanntermaßen mit zusätzlicher Arbeit möglich.

• 1. SQLite 3 braucht keinen Datenbankserver und kein Datenbankkonto: Die Datenbank ist eine Datei unter var/storage/sqlite3/. Auf Shared Hosting entfällt damit ein ganzer Bereitstellungsschritt. Es passt zu einer Website, die von einer Maschine ausgeliefert wird, was ein Shared-Konto ist.
• Ein Datenbankserver aus dem Panel (meist 4. MariaDB oder 6. MySQL, manchmal 2. PostgreSQL): Legen Sie Datenbank und Benutzer vor der Installation an; die Installer legen weder Datenbanken noch Benutzer an (2.6 Datenbanken). Legen Sie die Datenbank für MariaDB und MySQL in utf8mb4 an. Der Benutzer braucht nur Rechte auf die eine Datenbank (9.3 MySQL und MariaDB).

Siehe Datenbanken und Benutzer in Control Panels.

Cronjobs #

Geplantes Veröffentlichen, Benachrichtigungen und Bereinigung hängen von runcronjobs.php ab. Auf Shared Hosting plant der Kunde es meist über die Cron-Seite des Panels. Der Befehl muss dieselbe PHP-Version wie die Website nutzen; auf Maschinen mit mehreren PHP-Versionen heißt das den vollständigen Pfad zur richtigen Binärdatei (Kapitel 10, Cronjobs):

*/5 * * * * cd /var/www/vhosts/<domain>/<docroot> && /path/to/php runcronjobs.php -q -s site frequent >/dev/null 2>&1

Siehe Cron und Shell-Zugang.

Abschottung zwischen Konten #

Die Warnung aus dem README gilt auch für Shared Hosting: Ein Prozess, der mehrere Websites ausliefert, kann jede Datei lesen, die die anderen enthalten. Geben Sie jedem Konto einen eigenen Benutzer des Betriebssystems und einen eigenen PHP-FPM-Pool, der als dieser Benutzer läuft; das empfiehlt Kapitel 8, wenn mehrere Kunden auf einer Maschine voneinander auf Ebene des Betriebssystems abgeschottet sein müssen. Innerhalb des Kontos sollte alles, was var/ schreibt (der Pool, Cron, die Skripte des Kunden), als dieser eine Benutzer laufen (8.7.2 Ein Benutzer oder eine Gruppe). Siehe Trennung von Mandanten.

Checkliste #

• To do: PHP 8.0 oder später mit den erforderlichen Erweiterungen in der PHP-Version des Kontos (auch Velocity läuft unter 8.0).
• To do: Document Root = Wurzelverzeichnis der Installation; .htaccess aus .htaccess_root kopiert; mod_rewrite an.
• To do: Die php.ini-Werte oben pro Konto gesetzt; Entscheidung zu open_basedir dokumentiert.
• To do: vendor/ vorhanden, bevor der Assistent startet.
• To do: Eine Datenbank bereit (SQLite braucht nichts), in UTF-8 angelegt.
• To do: Eine Cron-Zeile für runcronjobs.php mit dem PHP des Kontos.
• To do: Ein Benutzer und ein PHP-FPM-Pool pro Konto.
• To do: Backups der Datenbank und von var/storage, settings/override, settings/siteaccess.

Verwandte Seiten #

• Ein Hosting-Modell wählen
• Control Panels: Überblick
• Der Setup-Assistent auf Shared Hosting
• .htaccess und config.php von der Konsole einrichten
• Kapitel 8: Die Website ausliefern
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.